Does mobile-first really work page by page or site by site?

Why does Google evaluate mobile compatibility page by page?

The logic is simple: each URL is a distinct entity in Google's index. The search engine doesn't think in terms of "site" but rather individual documents that it needs to rank for specific queries. A homepage might be perfectly responsive while an old product page remains broken on mobile.

This granular approach allows Google to accurately reward or penalize pages based on their actual quality. This aligns with the philosophy of mobile-first indexing: the primary index is based on the mobile version of each document, not on an average of the site. If your flagship product page is not mobile-friendly, it loses positions even if 95% of your catalog is in good shape.

What does this change compared to a global assessment?

A site-wide evaluation would create a smoothing average score that would obscure localized issues. You could have 80% of optimized pages and believe everything is fine, while your 20% of high-value pages suffer heavily in the mobile SERPs.

The page-by-page system is fairer but more demanding. It forces SEOs to thoroughly audit the entire heritage of pages, not just the main templates. A CSS bug that breaks mobile display on an entire category? Those specific pages will drop, while others will not.

How can Google technically apply this at scale?

Googlebot crawls and renders each page in its own context. The mobile compatibility signals are stored at the URL level in the index: configured viewport, font size, touch spacing, content readable without zooming, absence of Flash or outdated plugins.

These criteria are assessed during the page rendering. If tomorrow you fix a problematic page, it will be individually reassessed during the next crawl and rendering, without waiting for a "site-wide score" to update. This is pure document processing, not an aggregated metric.

• Each page is an autonomous document in Google's index with its own mobile signals
• A fix on one page benefits only that page, not automatically other URLs in the domain
• Mobile ranking variations can be very heterogeneous within the same site if technical quality varies
• The mobile audit must cover all types of pages, including old landing pages or rarely visited sections
• Tools like Mobile-Friendly Test or PageSpeed Insights must be used URL by URL for strategic pages

Is this statement consistent with what we observe in the field?

Absolutely. Ranking changes regularly show significant position gaps between pages of the same domain on mobile vs desktop. We see product pages dropping 15 places on mobile while the homepage remains stable, a classic symptom of a poorly responsive product template.

A/B tests on mobile compatibility also confirm this principle: fixing a specific page recovers its positions within days of re-crawl, without impacting other URLs. No "site-wide boost" observed, contrary to what could happen with a domain authority type signal.

What nuances should be added to this rule?

Google talks about "rankings" linked to mobile compatibility, but this is just one factor among hundreds of others. A desktop-only page can still rank if it massively dominates in relevance, backlinks, and topical authority. Mobile-friendliness is not a binary life/death situation.

Second nuance: some technical patterns structurally affect an entire site. A CDN issue that serves blocked content to mobiles, a JavaScript framework crashing on certain mobile browsers, a server configuration returning 5xx errors only on mobile user-agents... These "infrastructure technical" bugs will impact all pages even if the signal theoretically remains page-level. [To be verified] how far Google differentiates a one-off bug from a systemic issue in its processing.

When does this granularity pose a problem?

On large sites with tens of thousands of pages, a thorough audit becomes an operational nightmare. You cannot manually test 50,000 URLs. You need to script automated crawls with rendering, parse the responses to detect mobile-friendly violations, and then prioritize fixes based on traffic volume or business value.

Another trap: orphaned or rarely crawled pages. If Google does not re-render a page for 6 months, your CSS fix will not be considered until the next visit. On sites with a tight crawl budget, some strategic but deep pages can remain stuck with poor mobile signals for a long time. You then need to force re-crawl via Search Console or optimize internal linking to speed up discovery.

How to effectively audit the mobile compatibility of all your pages?

Forget manual tests beyond 100 pages. You need to crawl your site with a tool that simulates mobile rendering: Screaming Frog in "mobile Googlebot" mode, or cloud solutions like OnCrawl, Botify, Sitebulb configured with a mobile user-agent and viewport 375x667.

Then extract the key metrics: viewport tag present, minimum font-size respected (16px), tap targets spaced 48px CSS, content that does not overflow horizontally. Cross these technical data with your analytics to identify high-traffic pages that present violations. Prioritize fixes on URLs that generate revenue or conversions.

What common mistakes sabotage mobile compatibility page by page?

The classic trap: a correct global template but legacy editorial content that breaks everything. A too-wide HTML table inserted into a blog article, a fixed image of 1200px without max-width, a forgotten Flash video embed in a 2018 landing page... These one-off contents degrade their host page only.

Another frequent error: template variations by section. You optimized the blog and e-commerce but forgot the "news" or "technical documentation" section that still runs on an old CMS. These pages will individually underperform on mobile without you noticing if you only monitor the main sections.

What should be established to maintain compatibility over time?

A recurring automated monitoring is essential. Set up a weekly or monthly crawl according to the publishing frequency, with alerts if new pages violate mobile criteria. Integrate mobile regression tests into your CI/CD if you deploy code frequently.

Train your editorial and development teams on native responsive best practices: images with srcset, embeds in a 16:9 flex ratio, scrollable or pivoted tables in CSS, forms with appropriate input types. Mobile compatibility should be a production reflex, not a post-correction. If you publish 50 articles a month and 10% break on mobile, you accumulate a backlog of technical debt that eventually weighs on your overall rankings.

• Crawl the entire site with a mobile user-agent and rendering enabled
• Extract and analyze mobile-friendly violations by page (viewport, font-size, tap targets, overflows)
• Prioritize fixes on high-traffic or business value pages
• Establish recurring monitoring with alerts for new violations
• Integrate mobile regression tests into publication and deployment workflows
• Train editorial/dev teams on responsive standards to avoid regressions