Mobile SEO checks should establish what the smartphone version contains, whether Google can access and render it, and whether visitors can use it. Keep those three questions separate in the audit record. A readable phone screenshot, a successful fetch and an indexed search result are different pieces of evidence.
Which version supplies the content?
Google uses mobile content crawled by its smartphone agent for indexing and ranking. The mobile-first indexing guidance makes the mobile content a practical starting point for an investigation into missing or incomplete search information.
Google describes responsive design as serving the same HTML on the same URL across device types. Ask the developer which configuration the site uses: responsive design, dynamic serving or separate device URLs. Keep that answer with the affected page reference. The guide explicitly distinguishes responsive pages from the additional parity work needed for separate mobile versions.
Choose a representative page with a clear purpose and write down its essential content. For a hypothetical training page, that might be a service description, its scope, a meaningful heading and an enquiry link. The examples below describe an assessment to perform, not a claim that the reader’s site has already passed it.
Record the exact URL, page revision and assessment date. If a problem is reported only on one device, retain that device and browser context too. This gives the developer a specific starting condition instead of a general instruction to “fix mobile SEO”.
Is the important information actually present?
Google advises equivalent primary content between separate desktop and mobile versions. Compare the task information on the intended desktop and mobile presentations. Record a missing section by its meaning and location, not just by the number of words lost. A shortened layout can still need the same explanation of who the service is for and what happens next.
Google says it will not load primary content that requires interaction such as clicking or typing. Ask how primary content reaches the page. Distinguish text already present in the document but presented inside a collapsible section from text fetched only after someone takes an action. Inspect the implementation and the rendered result rather than deciding from the visual control alone.
Use the training page to assess a meaningful section heading and the information beneath it. If the text is absent in the inspected rendering, identify the component or data dependency that should supply it. Keep the relevant observation with the issue so the next reviewer can see what changed after a repair.
Include images where they explain the task. Record the relevant image reference and the text that identifies its meaning. The audit should help the content owner understand which information is available to the reader, rather than treating media as an unrelated decorative check.
Can Google access the required resources?
For separate mobile versions, Google advises using the same robots meta tags as on desktop. Where separate versions exist, ask the developer to compare the actual directives and their intended purpose. Keep deliberate exclusions distinguishable from accidental differences. An intentionally private page should not be opened to indexing simply because it appears on an audit checklist.
Google says blocked pages or files will not have their JavaScript rendered by Google Search. The JavaScript SEO guide therefore provides a reason to inspect the resource path as well as the page URL. Ask which script or stylesheet is needed to produce the missing content and whether the relevant crawl rules permit access.
Google recommends meaningful HTTP status codes for missing or login-protected pages. Include one missing training URL in the proposed checks and record the response the implementation returns. Compare the visible error with its HTTP response, then ask the developer to resolve any contradiction according to the intended behaviour.
Keep the findings precise. “Resource blocked by this rule” is actionable when it includes the resource and rule. “Google dislikes the site” is not a diagnosis supported by a single failed request or a missing paragraph.
What does the rendered page show?
Google describes crawling, rendering and indexing as its three main JavaScript processing phases. Google uses rendered HTML to index a JavaScript page. This explains why inspecting the original response alone may leave an unanswered question on a JavaScript-driven page.
Google recommends inspecting rendered HTML with the URL Inspection Tool or Rich Results Test for web components. Use the appropriate tool to inspect a selected page, then record which version and test context the result represents. Locate the specific heading, text or link under investigation in the rendered output. Save the observation rather than substituting an assumption that all JavaScript behaves the same way.
Ask the developer to compare the affected page before and after the proposed correction using the same assessment method. If the rendered content is now present, record that bounded result. Keep any separate question about indexing status in its own issue so the evidence remains understandable.
For the visitor’s side of the assessment, repeat the intended task on a chosen phone. Read the essential explanation, follow the enquiry route and inspect any error or obstruction encountered. A content visibility check and a usable interaction should each have their own observation.
How should findings be prioritised?
Use this original mobile search-evidence worksheet to organise the work. Each row asks a different question and gives the relevant owner something concrete to investigate.
| Question | Evidence to retain | Next decision |
|---|---|---|
| Which version is served? | Exact URL and site configuration | Which parity checks apply? |
| Is primary information present? | Named section and observed content | Is a content or loading change needed? |
| Are resources accessible? | Resource URL and relevant crawl rule | Is the exclusion intentional? |
| Is the response meaningful? | Status code and visible page result | Does the route need correction? |
| What is rendered? | Tool context and inspected text or link | Has the specific rendering issue changed? |
| Can a visitor act? | Device, browser and task observation | Which usability problem needs attention? |
Prioritise issues that prevent the intended information or action from being available. Assign the content, development or search-analysis owner according to the actual problem. Retain the evidence used to close each issue so a later change can be compared with the same condition.
Finish the record with the questions still unanswered, not a promised search position. The useful outcome is a clearer account of the page’s content, access and usability, followed by corrections that can be inspected.
For the broader search scope, see SEO. For implementation support, see web development or send Spout an affected page and its observed issue.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.