JavaScript SEO: How Google Renders Your Site

The most expensive technical problems I find are not crashes. They are pages that load perfectly for a customer and barely exist for a crawler.

I have been doing this for 13 years, and the pattern is always the same shape. A site gets rebuilt on a modern framework, everything looks better to the people paying for it, and somewhere in that rebuild the content moves out of the HTML and into a script that not every visitor runs.

This is written for the owner or marketing lead who has been told their site is JavaScript heavy and does not know what that means for search. It covers what Google actually renders, what sits in the HTML before any script runs, where client side rendering hides pages, and how to test what a crawler receives.

What JavaScript SEO actually means

Crawling, rendering and indexing are separate steps

Three things happen in sequence, and treating them as one is where most of the confusion comes from. Crawling is fetching the URL and reading the response. Rendering is running the page the way a browser would, including its scripts, to see what the finished document contains. Indexing is deciding what to do with what was found.

Google does render JavaScript, and that rendering happens in a queue after the initial fetch. Per Google's JavaScript SEO documentation, "Googlebot queues all pages with a 200 HTTP status code for rendering, unless a robots meta tag or header tells Google not to index the page." The same page makes the double step explicit: "Googlebot queues pages for both crawling and rendering."

So there are two opportunities for something to go wrong, and only one of them is visible when you open the site in your own browser.

Why this is not a developer versus marketer argument

Rendering problems get framed as an argument, and they should not be. A developer is optimising for a user with a current browser on a fast connection. A marketer is optimising for a crawler that may not run every script, or may run it much later than a person would.

Both concerns are valid, and the overlap is small and specific. Make sure the things that matter are in the response, and make sure the scripts you genuinely need are not blocked.

What Google sees before it renders your page

The initial HTML response

Fetch any URL from your site and read the response before anything runs. You will see whatever the server sent. On a well built site that includes the headings, the body copy and the internal links. On a client rendered site it often includes very little of any of them.

That initial response is what gets read first, and it is the version that matters when rendering is delayed, queued behind other work, or fails.

What exists only in the rendered document

Compare that response with what you see in a browser. If your navigation, your product grid, your prices or your article text appear in the browser but not in the response, they are being produced by script.

Some of that is unavoidable and harmless. Some of it is the difference between being found and not being found at all.

The weight of script is worth keeping in perspective. Per the Web Almanac 2024 JavaScript chapter, "In 2024, this upward trend resumed, with the median JavaScript payload rising by 14%, reaching 558 kilobytes on mobile and 613 kilobytes on desktop." More script means more that has to download, and more that has to run before anything depending on it exists.

How Google renders your pages

The rendering queue and what it means for timing

Rendering is a second queue, so a gap can open between the fetch and the render. Anything you need seen should not depend on a script running correctly at the right moment in that queue.

That is why link discovery is the first thing I test on a script heavy site. If a link only becomes clickable after the page has finished hydrating, then the discovery of the page behind it is conditional on everything else going right.

Resources the rendering service chooses to skip

The renderer makes choices about which resources to fetch. Scripts and stylesheets can be skipped or time out for a range of reasons, and when that happens the rendered document is not the document your customers see.

Robots rules are the blunt version of the same problem. Per the same Google documentation, "Google Search won't render JavaScript from blocked files or on blocked pages." One line in a robots file can turn a whole section of a site into an empty shell, and no browser will ever show you that.

Where client side rendering hides your content

Links that only exist after the page hydrates

Link discovery is the part I would protect first. If your navigation, category links or related content links are created by script, they are absent from the response, and discovery now depends on the render succeeding.

For a small site that is survivable. For a site with thousands of pages it is the difference between a section being crawled and a section nobody ever finds. The failure is quiet, which is what makes it expensive.

Titles and directives added by script

The same applies to the head of the document. If the page title, the canonical link or a robots directive is inserted by script, a rendering failure changes what search systems believe about the page. A missing canonical instruction is a duplicate content question nobody asked for.

The good news is how rarely rendering changes the meaning of those directives overall. Per the Web Almanac 2024 SEO chapter, "0.4% of desktop and 0.3% of mobile pages saw the directives' values changed by rendering." That is a small share, so this is not the norm. The question worth asking is whether your pages are in the small share where it happens.

The fix is usually unglamorous. Put the parts that must always be present into the server response, and keep the script driven approach for the interaction that genuinely needs it.

Blocked files, blocked pages and silent failures

Robots rules that stop rendering entirely

A blocked JavaScript file is the most common serious fault I find, and it is invisible from a browser because browsers ignore robots rules. Everything works perfectly for the customer while the crawler receives a shell.

Check the robots file against every script and stylesheet the page needs to load correctly. Not against what you assume the page needs, but against what is actually loaded when the page runs.

Analytics that never see the crawler

Client side measurement does not measure what it cannot run. Per Google's guide to fixing search related problems with script driven pages, "Client-side analytics may not provide a full or accurate representation of Googlebot and WRS activity on your site."

That means a healthy looking analytics report can sit on top of a crawl problem nobody has seen. If you are diagnosing a search issue, a browser based report is not the evidence you need.

Errors hide in the same place. Per the same guidance, "When a SPA is using client-side JavaScript to handle errors they often report a 200 HTTP status code instead of the appropriate status code." A page that should return a not found response but returns success is invisible in any report that counts status codes, and it is one of the more painful faults to find a year later.

Testing what Google actually gets

Raw HTML versus rendered HTML

The test I run first takes about ten minutes. Fetch the URL and read the response. Then open the same URL in a browser with scripts enabled and read the rendered document. Compare the headings, the body text and the internal links.

If the two match, rendering is unlikely to be your problem. If the response holds a fraction of the content, you now know exactly what the gap costs you, and that is a much better place to start a conversation about money than a hunch.

The checks I run before changing anything

I test three URLs at minimum. The homepage, a page from a section that matters commercially, and one recently published article. Then I check what scripts and stylesheets each page loads, whether any of them are blocked, and what the title and canonical instruction are in the response as well as in the browser.

That produces a scope before anybody prices a fix, which is what an SEO audit that tests rendering should give you rather than assuming the render works because the site looks fine.

Fixing the problems in the right order

Rendering fixes that come before content work

Fix discoverability before writing anything new. A content plan built on top of pages that cannot be crawled properly is money spent on top of a problem rather than on top of an opportunity.

The order I use. Unblock what is blocked. Get the essential content and links into the initial response. Confirm titles and canonical instructions are in the HTML. Then re-test the same three URLs and compare again.

When a rebuild is the honest answer

Sometimes the framework is the problem and a rebuild is the right call. That is true when the current architecture cannot serve crawlable content without breaking the product, or when a team has already spent two cycles failing to fix it.

More often the honest answer is smaller. Moving the critical render to the server, or changing how routing exposes links, fixes the search problem without discarding the build. Price a rebuild against that comparison rather than assuming it. The technical SEO checklist is a sensible place to record the before and after.

What this means beyond Google

Rendering matters to AI and answer systems too

If a page only assembles itself in a browser, any system that does not run that script sees less of the page. That is now a commercial question rather than a technical curiosity, because assistants and answer systems increasingly read sites on behalf of the people deciding what to buy.

Being readable to those systems starts with the most basic version of it: if the content is not in the response, it is not in the answer. That is being readable to AI search systems in its plainest form.

Keeping content readable to machines

The discipline does not change much from year to year. Important content in the HTML. Important links in the HTML. Nothing that matters hidden behind an interaction. Test the response, not just the render.

Where a site needs more than a rendering fix, that work sits inside the services I offer, and it always starts with a diagnostic on a handful of real URLs rather than a rebuild proposal.

Frequently asked questions

Does Google really render JavaScript now?

Yes, Google renders JavaScript, and it also queues rendering, which means rendering can happen after the initial crawl. The practical implication is that anything your page depends on being seen should not depend on a script running perfectly at the right moment.

How can I tell if my content only exists after JavaScript runs?

Fetch the URL and look at the response before any script executes. If the headings, body text and internal links are not there, they are being added by script. Compare that with what you see in the browser and the gap is your problem.

Our site is a single page application. Are we invisible to Google?

Not automatically, but the risk is real, and it concentrates in link discovery and in content that is loaded on interaction. If your navigation is rendered by script and your error handling returns a success response, both discovery and diagnosis get harder.

Is server side rendering the only fix?

No. Sometimes the fix is smaller, such as making sure key links exist in the initial HTML, ensuring important resources are not blocked, or changing how a framework handles routing. A full rebuild is worth considering only when the current approach cannot be corrected.

Does this affect how AI assistants see our site?

If a page only assembles itself in a browser, any system that does not run that script sees less of the page. Rendering discipline is now part of being readable to machines generally, not just to traditional search.

Will fixing rendering improve our rankings?

It can improve whether your pages are discoverable and whether their content can be assessed at all, which is a precondition for ranking rather than a guarantee of it. Anyone promising a ranking outcome from a rendering fix alone is guessing.