Google renders JavaScript. That sentence is true, it is repeated constantly, and it reassures a lot of teams into building sites that depend on it. What the sentence leaves out is that rendering is a rationed resource, and the sites most dependent on it are usually the ones least likely to get a generous share.
This post is about that rationing, which we find explains more real-world indexing problems than any amount of debugging a single page. For the symptom-level fix, fixing crawled, currently not indexed on JavaScript sites covers the ground.
What actually happens to a JavaScript page
Googlebot fetches your HTML. It indexes what is in that HTML immediately. If the page needs JavaScript to produce its real content, the page goes into a queue to be rendered later by a headless browser, and only after that second pass does the rendered content become available for indexing.
Two passes, not one. Google has said the delay between them is usually short, and that is fair. The problem is not the median case. The problem is that a queue is a place where your page waits, and what decides how long it waits is not under your control.
Rendering is expensive, so it is allocated
Fetching HTML is cheap. Running a browser is not. It means executing your scripts, waiting on your API calls, building a DOM and holding memory open, per page, across the web.
Anything that expensive gets allocated rather than given freely. In practice the allocation tracks the same signals as crawling generally: how important the site appears, how often it changes usefully, how fast it responds, how much of the crawl is being wasted. A large established site with strong demand gets rendered promptly. A new site with few external links does not, because nothing has told Google the expense is worth it yet.
This is where it becomes a compounding problem. A new site built entirely on client-side rendering needs the render pass to have any content at all. It is also exactly the kind of site that sits lowest in the queue. The sites that can most afford to depend on rendering are the ones that least need to.
If your crawl allowance is being spent on junk URLs, there is even less left over. Crawl budget explained covers where that waste usually hides.
The part that has changed, and it is the important part
For years this was a Google problem with a Google answer. That is no longer the shape of it.
A growing share of the traffic that matters comes from assistants, and most of the crawlers behind them do not execute JavaScript at all. They fetch the HTML, take what is in it, and move on. There is no second pass. There is no queue you are waiting in. If your content is not in the initial response, it does not exist for that system.
So the practical standard has tightened. It is no longer enough that Google will eventually see your content. The question is whether your content is present in the raw HTML, because that is what determines whether you are a candidate for the answers being generated today. We tested this directly in three versions of the same page.
The quickest way to see your own position is to compare what the raw response contains against what the rendered page contains. The script in rendered versus raw HTML does exactly that, and the gap it prints is usually larger than teams expect.
Where the budget gets wasted
Four patterns account for most of it.
- Blocking your own resources. A robots.txt rule that disallows a scripts or assets directory stops the renderer loading what it needs. The page renders blank or broken and gets indexed that way. This is still common and still silent.
- Content behind interaction. Anything that appears only after a click, a scroll past a threshold, or a hover is not seen. The renderer does not interact with your page. Tabs and accordions are fine if the content is in the DOM and hidden with CSS, and invisible if it is fetched on click.
- Slow or failing data calls. Rendering does not wait indefinitely. If your content depends on an API that is slow, rate-limited, or that fails for an unauthenticated client, the renderer sees the empty state. Your page then gets indexed as a page that says loading.
- Soft 404s at scale. A client-side route that returns a 200 with an empty shell, then shows a not-found message in JavaScript, teaches Google that your URLs return pages when they do not. Enough of those and the whole site is treated with more suspicion.
What to put in the HTML, in priority order
You do not have to server-render everything, and for application-like interfaces you should not. The useful question is which parts must be in the first response.
- The title, meta description and canonical. Non-negotiable. If these are injected by JavaScript, every system that does not render sees nothing or sees defaults.
- The H1 and the main body text. The actual content of the page.
- Internal links as real anchor elements with href attributes. This is how everything downstream gets discovered. A link that only works through a click handler is not a link.
- Structured data. In the initial HTML, not injected after.
- Anything a person would quote. The direct answer, the table, the numbers.
Below that line, interactivity, personalisation and dashboards can be client-side without consequence. Nobody needs your filter widget indexed.
The framework-specific mechanics for this are in JavaScript SEO for Angular and Vue and, for React, in the Next.js material on this site.
What is a waste of effort
Arguing about whether Google can render. It can. That was never the question.
Server-rendering an admin panel or a logged-in experience. Nothing is indexing it and you are paying for the complexity.
Dynamic rendering as a long-term plan. Serving a different, pre-rendered version to crawlers was a documented workaround that Google itself has described as a stopgap rather than a recommendation. It is two codepaths that drift apart, and the day they diverge you have a cloaking problem you did not intend. Fix the rendering instead.
Measuring success by whether the page eventually appears in the index. Eventually is doing a lot of work in that sentence. A page that takes weeks to be seen has lost whatever timeliness it had, and has been absent from every assistant answer in the meantime.
When you cannot change the framework
Most of the advice above assumes you can move rendering to the server. Often you cannot, at least not this quarter. The application is live, the team is committed elsewhere, and a rendering migration is not a decision a marketing request gets to make.
There is still useful ground between doing nothing and rebuilding.
Pre-render the pages that matter. You rarely need all of them. Your service pages, your highest-value landing pages and your article pages are usually a small fraction of the routes, and generating static HTML for those at build time is a contained piece of work with most of the benefit.
Put the metadata in the template. Even on a fully client-rendered application, title, description, canonical and structured data can usually be emitted server-side or injected at the edge without touching the application logic. This alone moves a page from invisible to legible.
Emit real links. Replacing click handlers with genuine anchor elements that happen to be intercepted by the router is a small change with a large effect on discovery, and it improves accessibility at the same time.
Add a plain fallback. A noscript block containing the main text and the links is unfashionable and it works for every crawler that does not execute JavaScript, which is most of them.
None of these is as good as rendering on the server. All of them are better than waiting for a rewrite that keeps being deferred.
Speed is part of the allocation too
One factor that sits underneath all of this and rarely gets connected to it: how fast your server responds affects how much gets crawled and rendered.
The logic is not complicated. A crawler working through your site at a fixed effort budget gets through more pages when each response is quick. Slow responses mean fewer pages fetched in the same window, and a site that is slow under crawl load will be crawled more gently to avoid harming it.
For sites on shared hosting with a database-heavy content system, this is frequently the binding constraint rather than anything about JavaScript. If your pages take a long time to begin responding, fix that before you optimise anything downstream of it, because every other improvement is gated behind it.
Check your response time for crawler requests specifically rather than for visitors, since caching layers often serve humans from cache and crawlers from origin.
How to diagnose your own situation
- Fetch a few important pages with a plain HTTP client, no JavaScript, and read what comes back. Title, description, H1, body, links. If they are missing, stop here and fix that.
- Compare that against the fully rendered DOM for the same URLs and measure the gap.
- Check your robots.txt is not blocking scripts, styles or API paths the page needs.
- Use the URL inspection tool on a page you suspect, and read the rendered HTML it reports rather than the screenshot.
- Look at your server logs for how often Googlebot actually requests your JavaScript bundles and data endpoints, not just your HTML. Log file analysis at scale covers the method.
- Check which other crawlers are fetching you, and whether any of them execute JavaScript. Most do not.
The short version
Treat rendering as a favour that may or may not be granted promptly, rather than a feature you can build on. Put the title, the content, the links and the structured data in the first response. Keep the clever parts for the things only humans will touch.
Sites that do this stop having an entire category of indexing problem, and they stop needing to care how long the render queue is.
If you want us to run the raw against rendered comparison across your site and tell you what is missing, get in touch.