Why do PageSpeed Insights and the mobile-friendly test provide contradictory results?

What is the technical difference between these two tools?

PageSpeed Insights relies on Lighthouse, an open-source tool from Google Chrome that analyzes client-side performance. It loads your page in a simulated testing environment, without going through the Googlebot infrastructure.

The mobile-friendly test directly employs Googlebot Mobile to retrieve and render the page. It strictly adheres to the rules set by robots.txt, noindex directives, and faithfully reproduces the rendering limitations faced by the actual crawler.

How does this distinction create discrepancies in results?

Googlebot can encounter blocked resources (CSS, JS) via robots.txt that Lighthouse will load without issue. A site can thus display an excellent PSI score while being poorly rendered by Google during indexing.

The reverse can also happen: a page might fail the mobile-friendly test due to blocking interstitial content or a poorly configured viewport, while achieving good Core Web Vitals metrics on PSI. These two tools measure different aspects within distinct execution contexts.

How does Googlebot actually process pages?

Googlebot Mobile executes JavaScript and renders pages, but with stricter time and resource constraints than a standard browser. If your JS takes too long to execute or if critical resources are blocked, the final rendering can differ significantly from what PSI sees.

The bot also respects HTTP directives (redirects, status codes, headers) that may block access or alter the content served. PSI, functioning as a browser, often overlooks these server intricacies.

• PageSpeed Insights simulates a Chrome browser and loads all publicly available resources.
• Mobile-friendly test uses the real Googlebot Mobile and respects robots.txt, HTTP headers, and rendering limitations.
• A high PSI score does not guarantee good indexing if critical resources are blocked for Googlebot.
• The rendering discrepancies between the two tools often reveal server-side configuration issues.
• To diagnose a mobile indexing problem, rely on the mobile-friendly test and the Search Console, not just PSI.

Is this distinction consistent with real-world observations?

Absolutely. The inconsistencies between PSI and actual rendering in the Search Console are a classic SEO diagnostic issue. I have seen sites with impeccable PSI scores (90+) being nearly invisible in mobile indexing because their CSS was blocked via robots.txt.

Google does not communicate this difference clearly enough. Many clients come with a green PSI report thinking their site is technically flawless, while the URL Inspection tool in GSC shows a completely broken rendering.

What nuances should we add to this statement?

Google simplifies it a bit. PSI uses Lighthouse with simulated network conditions (4G throttling, CPU capping), but these conditions remain more generous than the actual constraints for Googlebot in production. The bot may abandon rendering if the JS takes too long or consumes too much memory.

Furthermore, PSI now offers field data via CrUX (Chrome User Experience Report) in addition to lab tests. These field metrics reflect the actual user experience, but not necessarily what Googlebot sees. [To verify]: Google has never officially confirmed whether CrUX data directly influences ranking or if only Googlebot rendering counts for technical evaluation.

In which scenarios does this rule cause the most problems?

JavaScript-heavy sites (React, Vue, Angular in CSR) are the most affected. If the JS takes time to load or if critical bundles are blocked, PSI might still deliver the final content, while Googlebot abandons the request.

Complex server configurations (CDN with aggressive cache rules, server-side A/B testing, paywalls) also create discrepancies. PSI sees one version, while Googlebot sees another. If you experience unexplained discrepancies, systematically check server logs to compare user agents.

How can you verify what Googlebot actually sees?

The URL Inspection tool in Google Search Console remains your main ally. It shows you the final HTML rendering after JavaScript execution, exactly as Googlebot indexed it. Compare this rendering with what you see in your browser.

Also analyze the server logs by filtering for the Googlebot Mobile user agent. Check returned status codes, response times, and resources actually retrieved. Discrepancies between PSI and reality often hide there.

What technical errors cause these inconsistencies?

The blocking of critical resources via robots.txt is the number one issue. CSS and JS essential for rendering must be accessible to Googlebot. A simple Disallow: /*.css$ can ruin your mobile indexing without PSI detecting anything.

Excessive JS loading times are also problematic. If your app takes 8 seconds to hydrate the DOM, Googlebot may capture an intermediate snapshot, while PSI, being more patient, waits for the complete rendering. Optimize the critical rendering path and prioritize SSR or pre-rendering for critical content.

What testing strategy should you adopt concretely?

Never rely on a single tool. Use PSI for Core Web Vitals and user performance optimization, but always validate with the mobile-friendly test and URL Inspection for indexability.

Implement regular monitoring of Googlebot rendering through the GSC API. Automate alerts if key pages become invisible or if rendering degrades. Inconsistencies between tools often reveal technical regressions before they impact traffic.

• Test each strategic page with the GSC URL Inspection tool before and after deployment.
• Verify that the robots.txt does not prevent Googlebot from accessing critical CSS and JS.
• Compare the rendered HTML in GSC with the original source code to detect JS rendering issues.
• Monitor the server logs to identify Googlebot requests that fail or return 4xx/5xx status codes.
• Never consider a high PSI score as validation for mobile indexability.
• Prioritize SSR or pre-rendering for JavaScript-heavy sites to ensure consistent rendering.