Fetch and render: how Google sees your page
Google crawls a page, then renders it with a headless Chromium-based engine before indexing, so the indexed content is the rendered DOM, not just the raw HTML. The old standalone Fetch as Google tool has been folded into the URL Inspection live test, which shows the rendered HTML, a screenshot, and loaded resources. Differences between raw and rendered output explain many JavaScript indexing problems.
Crawl, render, index
Google's pipeline has three stages: crawling (fetching the URL), rendering (executing the page in a headless browser to build the DOM, including JavaScript), and indexing (storing the rendered content). Google has stated its rendering uses an evergreen, Chromium-based Web Rendering Service kept up to date with current Chrome.
Because indexing uses the rendered output, the question is not just what your server returned, but what the page looked like after scripts ran and resources loaded. Raw HTML and rendered HTML can differ substantially on JavaScript-driven sites.
Testing rendering today
The standalone Fetch as Google tool was retired and its capabilities moved into Search Console's URL Inspection tool. Run Test Live URL, then open the rendered HTML, the screenshot, and the list of page resources. Resources Google could not load — blocked by robots.txt, timed out, or erroring — are flagged, and any missing resource can mean missing rendered content.
Compare the rendered HTML against what you expect: if key text or links exist in the browser but not in the rendered HTML, Google likely is not seeing them, which explains why such content may not be indexed or followed.
- Google indexes the rendered DOM, not just the raw HTML
- Test with URL Inspection's live test: rendered HTML, screenshot, resources
- Resources blocked by robots.txt cannot load and can hide rendered content
Common rendering pitfalls
Blocking JavaScript or CSS in robots.txt is a frequent cause of incomplete rendering: if Google cannot fetch the scripts that build the page, it cannot render that content. Heavy client-side rendering that depends on slow or fragile requests can also fail within rendering limits.
Mitigations include keeping critical resources crawlable, ensuring important content does not depend solely on user interaction (clicks, scrolls) to appear, and considering server-side rendering or pre-rendering for content that must be reliably indexed. The live test is the ground truth for whether these efforts worked.
How it appears in analytics and logs
Because Google indexes the rendered page, content that only appears after JavaScript runs depends on successful rendering. If a resource fails to load or scripts error, rendered content can be missing even though the page looks fine in a browser.
Diagnostic use case
Verify what Google actually renders for a page — especially JavaScript-built content — using the URL Inspection live test, and fix gaps where rendered content is missing.
What WebmasterID can help detect
WebmasterID records which resources crawlers fetch server-side, helping confirm whether the scripts and assets a page needs to render were actually requested by the crawler.
Common mistakes
- Blocking JavaScript or CSS in robots.txt so Google cannot render page content.
- Assuming raw HTML equals what Google indexes — it indexes the rendered DOM.
- Hiding content behind interactions (click/scroll) that the renderer does not trigger.
- Looking for a standalone Fetch as Google tool that now lives in URL Inspection.
Privacy and accuracy notes
Rendering inspection concerns how a crawler processes a page, not visitor data. WebmasterID records crawler fetches without attaching them to any person.
Frequently asked questions
- Where did Fetch as Google go?
- Its functionality moved into the URL Inspection tool in Search Console. Use Test Live URL and view the rendered HTML, screenshot, and loaded resources to see how Google renders the page.
Related pages
- JavaScript rendering and crawling
Content injected by JavaScript is not in the initial HTML, so a crawler must render the page to see it. Rendering is more expensive than fetching HTML, and not all crawlers render. Server-side rendering (SSR) or prerendering puts content in the HTML directly, reducing dependence on the crawler's render step.
- Using the URL Inspection tool
The URL Inspection tool in Google Search Console reports, for one URL, whether it is indexed, when Google last crawled it, which canonical Google chose, and any coverage or enhancement issues. Its live test fetches the URL in real time and shows the rendered HTML, loaded resources, and any crawl errors — making it the fastest way to diagnose why a specific page is or is not in the index.
- Render-blocking resources and crawling
Render-blocking resources are scripts and stylesheets the browser must fetch and process before it can display a page. They slow the first paint for users and add work when search engines render pages to evaluate content. Reducing render-blocking — deferring non-critical JavaScript, inlining critical CSS, and minimising blocking requests — speeds rendering for both visitors and crawlers.
- Website observability
See which page resources crawlers fetched when rendering, recorded server-side.
Sources and verification notes
- Google Search Central — Understand the JavaScript SEO basics
- Google Search Central — How Google Search works (crawling and rendering)
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.