Spoke
JavaScript and rendering
Google can render JavaScript" is true, and it gets used to justify architectures that cause real problems. The useful questions are when rendering happens, how reliably, and who else is looking.
That Google renders JavaScript in a deferred second stage is documented by Google and linked below. That many other crawlers don't render is observable from what they fetch.
"Google can render JavaScript" is true. It also gets used to justify architectures that cause real problems.
The useful questions are when rendering happens, how reliably, and who else is reading.
Can search engines read JavaScript content?
Google can render JavaScript, but it does it in a deferred second stage rather than during the first fetch. So script-dependent content may be processed later than your HTML, and it's exposed to anything that goes wrong in between — a failed request, a timeout, a blocked resource.
Other crawlers are a different story. Many retrieval systems read the HTML they're served and never execute a script. To those, a page that needs JavaScript to have content is a page with no content.
Why deferred rendering matters
Fetch and render are separate. The HTML gets retrieved first. Rendering happens when there's capacity.
For stable content the delay is usually fine. It isn't fine where timing is the point — new pages, frequently updated content, anything where being processed promptly matters.
It also opens failure modes that don't exist in server-rendered HTML. The script can fail. A dependency can time out. A resource can be blocked by your own robots rules. The result is a page that renders beautifully in your browser and arrives empty.
The readers you're forgetting
Google's rendering ability gets cited as though Google were the only one looking.
Retrieval systems feeding AI answers, social preview generators, accessibility tools, assorted other agents — they read what they're served, and many don't run scripts at all.
A site whose content only exists after hydration is, to all of them, a site with nothing on it. That's an expensive thing to find out from an empty link preview.
This is the strongest current argument for server-rendered HTML, and it's got stronger as the number of non-browser readers has grown.
What to check
View source, not the inspector. The DOM in devtools shows what your browser built. The source shows what was served.
Turn JavaScript off and reload. Crude, fast, and immediately shows you what a non-rendering reader gets.
Use URL inspection to see the rendered HTML Google actually produced. That's authoritative for Google specifically.
Check your resources are crawlable. Blocking a script or stylesheet in robots.txt can stop rendering completing at all.
Patterns that cause trouble
Content that only loads on interaction — a tab, an accordion, a click. If it matters, it belongs in the HTML even when it's hidden.
Infinite scroll with no paginated URLs, so there's no address for anything past the first screen.
Routing that changes the content without changing the URL, so there's nothing to link to or index.
Blocking the resources needed to render. Self-defeating, and common.
The simple version
If the content matters, serve it in the HTML.
That's what we do here — static HTML with no JavaScript on content pages at all. Not a universal prescription; plenty of applications genuinely need client rendering. But for a content site it removes an entire category of failure for roughly nothing.
More in Technical SEO
Crawlability & indexing
Crawling and indexing are two different things, and a page can fail at either one. Most diagnosis goes wrong by treating them as a single step.
Architecture & URLs
How your pages are organized decides how they get found, how authority moves between them, and whether anyone can tell what the site is about. URLs are the visible shape of that decision.
Sitemaps & robots
These two files are where confident wrong advice concentrates, probably because they look simple enough that nobody bothers checking the documentation.
Structured data
Markup won't rank your page and won't make a claim true. Its job is to state outright what a machine would otherwise have to work out by guessing.
Core Web Vitals
Three metrics with published thresholds, measured on real visits rather than a test you ran once. No interpretation needed. You either meet them or you don't.
AI crawler access
Letting AI crawlers read your site is a real decision with a real trade-off. Most advice about it mixes up controls that do completely different jobs.