Mobile SEO Checklist: Test the Page Google Sees

Direct answer: test the exact canonical URL on a real phone and through Search Console's URL Inspection tool. Compare Google's indexed crawl with the live Google test, then confirm that the mobile page contains the complete primary content, metadata, structured data, images, and crawlable links. Complete the page's real task with touch, a small screen, and the on-screen keyboard. A responsive layout or green Lighthouse score does not prove those conditions.

Google uses the mobile version of a site's content, crawled with its smartphone agent, for indexing and ranking. There is still one search index, not a separate mobile index. The practical consequence is simple: content or links missing from the mobile result may also be missing from the evidence Google uses to understand the page.

This checklist keeps performance in its own lane. If the issue is LCP, CLS, or INP, use the separate Core Web Vitals diagnosis. Here the question is whether the mobile page is complete, accessible, navigable, and able to finish the customer's task.

Use three views of the same URL

No single test shows the whole mobile experience. Audit one representative URL through these three views, then repeat the relevant checks on each important template.

View	What it can prove	What it cannot prove alone
URL Inspection live test	Google-InspectionTool can fetch the live URL, render it, and retrieve important resources	That Googlebot received the same result, the page is indexed, ranks, or works well for every customer
Browser device mode	Responsive breakpoints, overflow, DOM content, network failures, and common device sizes	Real touch behavior, keyboard effects, weak connectivity, or every mobile browser
Physical phone	Thumb reach, tap accuracy, menus, forms, calls, payments, and the actual business task	Exactly what Googlebot rendered or which resources it could crawl

Google retired the Mobile-Friendly Test, its API, and Search Console's Mobile Usability report on December 1, 2023. Mobile usability still matters. The useful replacement is a small test stack: URL Inspection for Google's fetch and render, browser tools for implementation evidence, and a real phone for the customer journey.

1. Define the page and task before testing

Choose a page that represents a valuable template or action: a service page, product, category, booking flow, local landing page, lead form, or article. Record the exact clean URL and the task a mobile visitor should complete.

URL: https://example.com/service
Template: service detail
Primary mobile task: understand the offer and request a quote
Secondary task: call the business
Test devices: Android Chrome / iPhone Safari
Google view: URL Inspection live test
Decision: PASS / FIX / INVESTIGATE

Test the whole route, not only the first screen. A restaurant page is not successful because its hero fits the viewport if the menu cannot be opened or the order button fails. An article is not complete if its comparison table or references disappear on a phone.

2. Confirm the same indexable page reaches mobile

Responsive design normally serves the same HTML at the same URL and changes the layout with CSS. Google recommends it because it is the easiest mobile pattern to implement and maintain. Dynamic serving and separate mobile URLs can work, but they create more places for content, metadata, canonicals, redirects, and links to diverge.

For the tested URL, confirm:

the phone reaches the intended final URL instead of an irrelevant homepage or mobile error page;
the response is successful and does not depend on a device-specific redirect loop;
the robots rules, canonical, title, and meta description remain equivalent;
the page includes <meta name="viewport" content="width=device-width, initial-scale=1">;
the layout fits the viewport without routine horizontal scrolling or forced zooming;
CSS, JavaScript, images, fonts, and API responses required for the primary content are not blocked.

A desktop-only page can still be indexed if Googlebot Smartphone can access it, but that does not make it usable. Conversely, a polished mobile shell can fail indexing when it carries a different noindex, canonical, empty render, or blocked resource.

3. Compare Google's indexed crawl with the live test

Open the exact URL in Search Console and compare the indexed information with the live test. The indexed view describes Google's last processed version and reports whether it was crawled as a smartphone or desktop. The live test uses Google-InspectionTool to fetch the current page. It is useful after a fix, but it is not the same crawler as Googlebot and its pass does not mean the URL is already indexed.

After the live test completes, inspect the screenshot, rendered HTML, and loaded resources. Search the rendered HTML for the H1, a distinctive sentence from the main content, important internal links, structured data, image alt text, and the primary call to action. The screenshot is a quick visual clue, while the HTML tells you whether the information exists in the render.

Symptom	Likely cause	Next check
Blank or incomplete screenshot	Blocked assets, rendering error, delayed app shell, or server response difference	Resource list, console, server logs, rendered HTML
Main copy absent from HTML	Content requires a click, swipe, typing, or later API request	Disable interaction and reload; inspect the initial and rendered DOM
Images or styles missing	robots.txt, CDN permissions, expiring URLs, mixed content, or incorrect paths	Open each failed resource and compare the mobile request
Wrong canonical or robots rule	Mobile template, edge cache, plugin, or environment drift	Compare response headers and rendered head across devices
Navigation links absent	Menu items injected only after interaction or removed at the breakpoint	Inspect rendered anchors and the mobile navigation source

Do not lazy-load primary content only after user interaction. Google documents that its crawler does not swipe, click, or type to reveal that material. Content can sit inside an accordion for a compact layout, but the information should already be present and available to the rendered page.

4. Compare mobile and desktop content parity

Content parity does not mean identical pixels or identical DOM order. The mobile design can stack columns, collapse supporting sections, or change image crops. It does mean that the same page job and important evidence survive the layout change.

Primary content: the answer, product details, service scope, prices or qualifiers, evidence, and next step remain available.
Headings: clear and meaningful headings still describe the same sections.
Metadata: title and meta description are equivalent across served versions.
Structured data: the same relevant entities and correct URLs are present in the mobile render.
Images and video: useful media, alt text, captions, and supporting context do not disappear.
Internal links: important discovery and next-step links remain in the rendered HTML.

Use a text or DOM comparison when dynamic serving or separate mobile URLs are involved. For a responsive site, resize the page and inspect CSS rules that hide or replace blocks. A visually hidden duplicate can also create confusion, so the goal is one complete, coherent mobile page, not two overlapping copies.

5. Test navigation without hover or guesswork

Open the menu with touch, follow each important route, use the browser Back button, and repeat with the phone rotated. The menu control should have a clear accessible name, visible focus, a correct expanded state, and a close path that does not trap the user.

Important destinations should use normal crawlable links such as <a href="/services">. A styled <div>, a click handler without a resolvable URL, or a desktop link removed from mobile navigation can make a page harder for customers and crawlers to find. Google says limiting the links in a separate mobile version can slow discovery because it indexes the mobile version.

Check the page beyond the global menu:

breadcrumbs or back paths remain understandable;
cards have a clear destination and do not require hover to reveal it;
pagination and load-more states expose crawlable page URLs where discovery matters;
sticky headers do not cover anchored headings or the first form field;
phone, email, map, and download actions open the expected handler.

6. Check tap targets, zoom, and overlays

Use a thumb, not a mouse cursor. Test menu icons, close buttons, filters, accordions, pagination, checkboxes, and calls to action near the screen edge. Look for accidental taps, controls that overlap, and actions that appear only after hover.

WCAG 2.2 Level AA sets a 24 by 24 CSS pixel minimum for pointer targets, with documented exceptions including sufficient spacing and inline text links. Its enhanced Level AAA target is 44 by 44 CSS pixels. Google's web.dev guidance recommends aiming around 48 device-independent pixels with space between touch controls. For frequent or consequential actions, the larger practical target is the better design goal.

Do not disable user zoom. A layout that only works by preventing pinch zoom hides an accessibility problem instead of solving it. Let the viewport fit naturally and let users enlarge content when they need to.

Dismiss every banner, consent dialog, chat launcher, and promotion at the tested breakpoint. A close icon must be reachable and remain visible when the on-screen keyboard opens. Google recommends banners that occupy a small portion of the screen instead of promotional interstitials that obscure the primary content.

7. Complete the form and business action

A mobile SEO check is incomplete until the page does the thing it promises. Submit a test lead, book a test appointment, add a product, start checkout, call the number, open directions, or download the file. Confirm the result arrives in the real destination without duplicate submissions.

For forms, verify:

every input has a persistent visible label and a useful error message;
email, telephone, number, date, and address fields invoke sensible mobile keyboards or pickers;
autofill and password managers do not overwrite unrelated fields;
validation does not clear correct values or jump to an invisible error;
the keyboard does not cover the active field, submit button, or error summary;
success is visible and the lead, booking, order, or message arrives once;
the action still works with a slow connection or a brief retry.

Record operational failures separately from indexation failures. A form can be fully crawlable and still lose every mobile lead. That makes it a critical business defect even when no SEO tool raises a warning.

8. Check responsive media and layout boundaries

Inspect the page at a narrow phone width, a larger phone, and at least one intermediate width. Breakpoints often fail between the devices a designer chose for screenshots.

text reflows without a fixed-width container pushing the page sideways;
tables wrap, scroll inside a labelled container, or transform without losing relationships;
images use an appropriate source for the viewport and retain meaningful crops;
video, maps, embeds, code blocks, and long URLs stay within the content column;
image width and height reserve the correct aspect ratio;
important text is real HTML, not trapped only inside an image.

These checks overlap with delivery, but this guide does not grade loading performance. If large media or scripts cause slow loading, layout shift, or poor interaction responsiveness, move that evidence into the performance workflow and validate the mobile task again after the fix.

9. Test more than one phone context

One device cannot represent the whole audience. Use analytics or business evidence to choose a small matrix, then include the riskiest context instead of chasing every model.

Context	Why it matters	Practical test
Small viewport	Exposes overflow, cramped controls, and sticky-overlay conflicts	Older or compact phone width
iOS and Android	Browsers, keyboards, date controls, and safe areas differ	Safari on iPhone and Chrome on Android
Slow or unstable network	Late assets and retries can break the task	Browser throttling plus one real cellular test
Text zoom or larger system text	Reveals clipped labels and fixed-height controls	Increase text size and repeat navigation and form tasks
Signed out or fresh session	Consent, location, login, and first-visit overlays change the page	Private window or cleared test profile

Prioritize representative templates and conversion routes. A page-level SEO audit can supply the intended query and page job; this mobile checklist then verifies that the same job survives the smaller screen and smartphone crawl.

What not to do

Do not use a Lighthouse score as the mobile audit result. It is useful evidence, not a content-parity, crawl, navigation, or conversion test.
Do not remove useful content just to shorten the mobile page. Reorganize it with clear sections or accordions while keeping it available.
Do not require a click, swipe, or search to load primary indexable content. Googlebot will not perform those interactions.
Do not block CSS, JavaScript, images, or API resources that Google needs to render the page.
Do not hide navigation behind non-links. Important routes need resolvable <a href> destinations.
Do not rely only on device emulation. It does not reproduce a real finger, keyboard, browser chrome, app handoff, or unreliable connection.
Do not cover the first screen with a promotional interstitial. Use a compact, dismissible banner when the message is necessary.
Do not change URLs during a responsive redesign without a real need. If a move is required, use the site migration SEO checklist.

Final mobile SEO validation record

Finish with observed evidence and an owner:

Canonical URL and response: PASS / FIX / INVESTIGATE
Indexed mobile render and live Google test: PASS / FIX / INVESTIGATE
Primary content parity: PASS / FIX / INVESTIGATE
Metadata and structured data: PASS / FIX / INVESTIGATE
Navigation and crawlable links: PASS / FIX / INVESTIGATE
Tap targets and overlays: PASS / FIX / INVESTIGATE
Form or business task: PASS / FIX / INVESTIGATE
Responsive media and overflow: PASS / FIX / INVESTIGATE

Highest-impact defect:
Evidence and reproduction steps:
Template or page owner:
Release date:
Post-release test:

Re-run the failed task after deployment on the public URL. Then use URL Inspection's live test to confirm the final Google render. For a redesign or platform move, include this record in the broader pre-launch and post-launch comparison so mobile parity does not disappear between environments.

Sources checked

Mobile indexing, rendering, responsive design, link, interstitial, and touch-target guidance was verified from Google, Chrome, web.dev, and W3C documentation on August 4, 2026.

Need the mobile failure traced to its source?

I can compare Google's render with the live customer journey, separate page defects from template problems, and return an ordered implementation list your developer can verify.

Request an SEO audit