One correction before comparing them: Google retired the standalone Mobile-Friendly Test tool (along with the Mobile Usability report and API) on December 1, 2023, redirecting that workflow to Lighthouse’s mobile-friendly audits. The comparison below is still useful for understanding what mobile-usability rendering checks for relative to the other two tools, treat any reference to “Mobile-Friendly Test” as the mobile-usability-check role now filled by Lighthouse rather than a currently-live standalone tool.
All three draw on Google’s own rendering infrastructure, broadly aligned with how Googlebot actually renders pages, but they are separate tools (or tool roles) built for separate purposes, running at different times against potentially different states of a page, which is why their results can conflict even when nothing appears to have changed from your side. The Rich Results Test focuses specifically on extracting and validating structured data from the rendered page. URL Inspection reflects Google’s actual, already-crawled and indexed state of that URL, including whatever was cached at the time of that crawl. Mobile-usability rendering (now via Lighthouse) focuses on mobile usability rather than structured data or indexing status. Conflicting results across them most often come down to timing differences, caching differences, or the tools’ genuinely different scopes, not fundamentally different rendering engines.
What each tool is actually built to check
The Rich Results Test renders a page (or accepts submitted code) and specifically evaluates whether structured data present on the rendered output qualifies for one or more rich result types, reporting validation errors and warnings relevant to schema eligibility. Its rendering step exists in service of that specific structured-data-extraction purpose; it’s testing “can Google’s systems find and validate rich-result-eligible markup here,” not primarily reporting on the page’s broader indexing status or general crawlability.
URL Inspection, accessed through Search Console, is different in kind: it reports on Google’s actual, already-established knowledge of that specific URL, based on Google’s most recent real crawl and index of it. This means URL Inspection can reflect a cached, potentially outdated view of the page if Google hasn’t recrawled it recently, which is a genuinely important distinction from the other two tools. URL Inspection also offers a “live test” option, which does trigger a fresh, on-demand render closer in spirit to what the Rich Results Test does, but the tool’s primary, non-live view is inherently backward-looking, reflecting whatever Google’s last actual crawl captured, not necessarily the page’s current live state.
Mobile-usability rendering, checked today via Lighthouse’s mobile-friendly audit rather than the retired standalone tool, is oriented around mobile usability specifically: viewport configuration, text sizing, tap target spacing, and whether content is genuinely usable on a mobile device, rather than structured data extraction or indexing status. It renders the page in a mobile context to evaluate that specific dimension, and its purpose doesn’t overlap directly with either of the other two tools’ core jobs even though all three are, at the rendering-engine level, drawing on related Google infrastructure.
Why conflicts happen: timing, caching, and scope, not different engines
Google’s own documentation for these tools acknowledges they may not always return identical results, and the most common real causes are mundane rather than mysterious. A page that changed between the time one test ran and the time another ran will legitimately show different results across tools, since each test reflects the page’s state at that specific moment of rendering, not a shared, synchronized snapshot. This is especially relevant when comparing a live, on-demand test (Rich Results Test, or URL Inspection’s live test option) against URL Inspection’s default cached view, which may reflect a page state from days or weeks earlier if Google hasn’t recrawled recently.
Caching and crawl-timing differences specifically explain a large share of apparent Rich-Results-Test-versus-Search-Console-report conflicts: a developer who fixes a structured data issue and immediately gets a clean pass in the live Rich Results Test may still see the old error persisting in Search Console’s structured data (Enhancements) reports for a period afterward, simply because Search Console’s reports are built from Google’s crawl history and haven’t yet reflected a fresh recrawl of the fixed page. This isn’t a tool malfunction or a sign the fix didn’t work; it’s the backward-looking nature of non-live reporting catching up to a live change.
Scope differences also produce results that look contradictory but actually aren’t measuring the same thing. A page can pass a mobile-usability check cleanly (good mobile usability) while showing structured data errors in the Rich Results Test (a schema problem unrelated to mobile usability), and neither result contradicts the other since they’re evaluating entirely different dimensions of the page. Treating any of these tools as a universal, single “is this page okay” check, rather than a purpose-specific diagnostic, is a common source of confusion when results don’t align.
A hypothetical walkthrough of a timing-driven conflict
Imagine a hypothetical developer working on a site called “Example Recipe Hub” who fixes a missing “recipeYield” field in the recipe schema and, minutes later, runs the live Rich Results Test and gets a clean pass with no errors. Hypothetically, if that same developer then checks Search Console’s structured data report for the same URL, they might still see the old “missing field” error listed there, not because the fix failed, but because Search Console’s report reflects Google’s last actual crawl of that URL, which happened before the fix went live. In this hypothetical, the two tools aren’t disagreeing about the page’s current state, they’re reporting on two different moments in time, the live render just now versus the cached crawl from before. The apparent conflict would be expected to resolve on its own once Google recrawls the page and Search Console’s report catches up, illustrating why checking timing first, before assuming a tool malfunction, matters.
Practical implication: use each tool for its actual purpose, and check timing before assuming a conflict
The practical response to apparent conflicts is to first check whether you’re comparing a live test against a cached report, since that timing mismatch resolves a large share of apparent discrepancies on its own; give Search Console’s non-live reports time to catch up after a fix, and use URL Inspection’s live test option specifically when you need an immediate, current read rather than relying on the default cached view.
Second, match the tool to the actual question you’re asking. Use the Rich Results Test when the question is specifically about structured data eligibility and validation. Use URL Inspection (both its cached indexed view and its live test) when the question is about a specific URL’s actual crawl and index status, including whether Google has successfully processed recent changes. Use Lighthouse’s mobile-friendly audit when the question is specifically about mobile usability rendering, not structured data or indexing.
| Tool | Primary purpose | Reflects |
|---|---|---|
| Rich Results Test | Structured data extraction/validation | Live render at test time |
| URL Inspection (default) | Actual crawl/index status | Google's last real crawl (cached) |
| URL Inspection (live test) | Current on-demand render | Live render at test time |
| Lighthouse mobile-friendly audit | Mobile usability rendering | Live render at test time |
Finally, when results genuinely conflict even after accounting for timing and scope, treat it as a signal worth investigating rather than dismissing, since Google’s own documentation for these tools does acknowledge occasional discrepancies exist; the honest position is that these are distinct tools with distinct jobs and distinct data freshness characteristics, not a single unified rendering report, and reconciling them requires understanding which one is answering which specific question.
