Check this page with an assistantOpens a chat asking it to summarise this article and name the evidence behind each claim.
Claude opens with the prompt on your clipboard: Anthropic does not support prefilled prompts on the web, and we would rather copy it than ship a button that drops it.
Mobile Is the Indexing Source, Not a Smaller Presentation
Google predominantly uses the mobile version crawled with its smartphone agent for indexing and ranking. A polished desktop page cannot compensate for a mobile response that removes the main explanation, supporting links, product details, author information, or structured data.
“Mobile-friendly” and “mobile equivalent” are not the same test. A page may fit a narrow screen while delivering half the content and links. Conversely, a complete page can still be frustrating because text is tiny, controls overlap, layout shifts, or a modal hides the first screen.
Treat mobile SEO as three connected outcomes: Google can access the intended assets, the mobile version carries the same meaning and signals, and a real person can complete the task comfortably.
Choose a Configuration You Can Keep Equivalent
| Configuration | How it works | Main risk |
|---|---|---|
| Responsive design | Same URL and HTML adapt through CSS | CSS visually hides or breaks important elements |
| Dynamic serving | Same URL returns different HTML by user agent | Faulty detection or missing Vary behavior |
| Separate mobile URLs | Desktop and mobile use paired URLs | Redirect, canonical, alternate, or parity drift |
Google recommends responsive design because it usually has the lowest maintenance burden, not because the CSS pattern earns a special ranking advantage. Dynamic serving and separate URLs can work, but every template, state, locale, and release creates another parity check.
Run a Mobile Parity Audit by Signal
| Signal | What must survive on mobile |
|---|---|
| Primary content | Same purpose, facts, products, headings, and descriptive text |
| Internal links | Important discovery paths and descriptive anchor text |
| Metadata | Equivalent title, description, robots directives, and canonicals |
| Structured data | Same eligible entities, required properties, and visible facts |
| Images and video | Useful quality, stable crawlable URLs, alt text, captions, and context |
| Technical state | Equivalent HTTP status, robots access, hreflang, and error behavior |
The wording and layout do not have to be pixel-identical. Mobile can use accordions, shorter navigation, and reordered components. The information and crawlable relationships should remain equivalent. Compare rendered page text and link graphs by template instead of judging screenshots alone.
Audit the image and video implementations separately. Tiny thumbnails, unstable asset URLs, missing captions, or a video moved far away from its supporting copy can change what Google understands.
Do Not Make Primary Content Depend on Interaction
Google does not click, swipe, or type to reveal content. Lazy loading should be tied to visibility or normal rendering behavior rather than a user action. Essential product details, article copy, category links, and images should become available when the mobile page loads and renders.
Tabs and accordions are acceptable for layout when their content is present and renderable. Problems arise when a tap starts a separate API request that Google never triggers, when infinite scroll has no crawlable pagination path, or when a client error leaves only an app shell. Compare the raw response, rendered DOM, and network behavior using the JavaScript SEO guide.
Keep CSS, JavaScript, images, and other rendering resources crawlable. Blocking them can prevent Google from recognizing the layout and content it is supposed to index.
Make the First Screen Useful, Not Hostile
An intrusive interstitial that covers the main content immediately after arrival makes the page harder to use and understand. Prefer a compact banner for app promotion, newsletter signup, language choice, or a nonessential offer. Do not redirect visitors to a separate consent page or hide the destination behind an unrelated full-screen promotion.
Legal requirements can justify dialogs, including age verification, privacy consent, or a paywall for nonpublic content. Implement them so the underlying page context remains present where possible and search crawlers can still access the content they are eligible to see.
Check sticky headers, chat bubbles, cookie controls, ad slots, and install prompts together at small heights. Individually acceptable components can collectively leave no usable reading area.
Treat Performance and Usability as Template Work
Test real-user Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift by device and template. Field data reveals how actual visitors experience the page; lab tools help reproduce a slow hero, long JavaScript task, or unsized media slot.
- Deliver the primary content without a long client-side rendering chain.
- Size images and ads so later loading does not move the page.
- Keep taps responsive and avoid main-thread work after interaction.
- Use readable text, adequate spacing, and controls sized for touch.
- Preserve visible keyboard focus and logical reading order.
Page experience is evaluated across multiple signals, and no single tool score guarantees ranking. Use the Core Web Vitals field note to move from a failing URL to the shared template cause.
Handle Separate Mobile URLs With One-to-One Discipline
If desktop and mobile have different URLs, each desktop page should identify its corresponding mobile version with rel=alternate, and each mobile page should point to its desktop counterpart with a canonical. Keep hreflang links between equivalent URLs in the same device family.
Do not redirect many desktop pages to one mobile homepage. Send users and Googlebot to the corresponding mobile destination, and allow access to the desktop version when requested. Return the same error status on both versions; a missing mobile page should not silently become a 200 homepage.
Avoid fragment-only mobile routes and keep redirects out of loops. The hreflang field note and HTTP status-code guide cover the two most common failure classes.
Use a Repeatable Mobile Release Test
- Open representative templates around 390 pixels wide and at a short viewport height; check horizontal overflow and obstruction.
- Compare desktop and mobile titles, directives, canonicals, schema, headings, text, links, media, and HTTP responses.
- Inspect raw HTML, the rendered DOM, console errors, and resources fetched by the page.
- Use Search Console URL Inspection to review the Google-selected canonical, crawl state, rendered screenshot, and detected data.
- Test real touch, keyboard, orientation, zoom, slow network, consent, logged-out, empty, and error states on physical devices.
- Monitor Search Console indexing, rich-result eligibility, and device-segmented field performance after release.
Automate the parity fields that can be compared reliably and keep human review for readability, meaning, and task completion. A viewport screenshot is one check, not the whole audit.
Questions About Mobile SEO
- Does Google index the desktop or mobile version?
Google uses the mobile version of a site’s content, crawled with the smartphone agent, for indexing and ranking. If mobile omits important text, links, metadata, structured data, or media, the desktop version does not reliably make up for that gap.
- Is responsive design required for SEO?
No. Google supports responsive design, dynamic serving, and separate mobile URLs, but recommends responsive design because it is generally the easiest to implement and maintain. Whichever configuration you use must preserve equivalent content and signals.
- Can important content stay inside mobile accordions?
Yes. Google says content placed in tabs or accordions for mobile usability is acceptable. The content still needs to exist in the mobile page and be accessible to the crawler; do not fetch essential copy only after a click, swipe, or other user interaction.
- Are Core Web Vitals a mobile-first indexing requirement?
Core Web Vitals and mobile-first indexing are different concerns. Mobile-first indexing determines which version supplies content and signals, while Core Web Vitals measure page experience. A page can have complete mobile parity and poor performance, or fast rendering with missing mobile content. Test both.
