How to Check What Google Actually Sees: JavaScript Rendering Explained

When you open a page in your browser, you see the finished product. When Googlebot fetches the same page, it gets the raw HTML first and only renders the JavaScript later, sometimes much later. Whatever your JavaScript is responsible for, Google might not see it on the first pass, or at all.

This matters more than most people realise. I regularly audit sites where the main navigation, the product descriptions or the canonical tag only exist after JavaScript runs. The owners have no idea, because everything looks fine when they load the page themselves.

The quick check: view source vs inspect

The simplest test costs nothing. Right click on a page and choose View Page Source. That is the raw HTML Google receives. Then open DevTools and look at the Elements panel. That is the rendered version, after JavaScript has run.

Now pick something that matters: a paragraph of body copy, a set of category links, your canonical tag. Search for it in the source. If it is there, Google sees it immediately. If it only exists in the rendered DOM, it depends on Google completing the render, which introduces delay and a chance of failure.

This is not a perfect test, but it takes ten seconds and it will catch the obvious cases, like a page that is essentially an empty div until JavaScript fills it.

URL Inspection in Search Console

The more accurate version is the URL Inspection tool in Search Console. Inspect a URL, view the crawled page, and look at the screenshot and the HTML tab. That HTML is what Google actually processed, not an approximation of it.

Do this on a few templates, not just the homepage. Templates behave differently. A product template might render fine while a faceted filter page renders as a shell. It is the templates with problems that quietly suppress thousands of URLs.

Crawling with JavaScript enabled

For a site-wide view, Screaming Frog can crawl with JavaScript rendering switched on, using Chromium under the hood. Run two crawls: one with rendering off, one with it on. Then compare word counts, title tags, canonicals and internal links per page.

The differences tell you exactly what your JavaScript is responsible for. If the rendered crawl finds hundreds of internal links the raw crawl missed, your internal linking depends on rendering. If canonicals only appear after render, Google has to render before it can consolidate signals. Each dependency adds delay and fragility.

Why the delay matters

Google renders in a queue. Pages can wait days or weeks in that queue, and low-value URLs may never get rendered at all. Every piece of content that depends on JavaScript is content Google has to do extra work to see. On small, well-linked sites this usually resolves itself. On large sites, or where rendering regularly fails, it becomes a genuine constraint on what gets indexed.

There is also a crawl budget angle. Rendering is expensive for Google, so pages that force it are crawled less eagerly than pages that serve complete HTML.

What to do about it

If the gaps you find are important, the fix is usually one of three things. Server-side rendering, where the HTML arrives complete. Static rendering or prerendering, where a complete version is built ahead of time. Or dynamic rendering, where bots get a prerendered version while users get the JavaScript app.

The first two are proper fixes. The third is a workaround Google tolerates but does not love. Which is right depends on your stack, and that is a bigger conversation, but it starts with knowing what is actually invisible. Most teams never check. Now you can, in about a minute, for free.