JavaScript SEO: When Your Content Is Invisible
A site can look perfect in a browser and be nearly empty to a crawler. Modern frameworks make this less common than it was, and much harder to notice when it happens.
Google renders JavaScript, but in a second pass that can lag the initial crawl, and it will not interact with a page to reveal content. Anything requiring a click, a scroll or a slow API call to appear may never be indexed. Server-rendering or pre-rendering removes the problem entirely.
How Google Actually Processes a Page
Googlebot fetches your HTML first and indexes what is in it. Pages needing JavaScript go into a queue for rendering, which happens later. The gap between those two passes is where JavaScript SEO problems live.
In the first pass, Google sees the raw HTML the server returned. If that is an empty shell with a script tag, there is nothing to index yet and nothing to discover — including links, which means pages linked only from rendered content may not be found in that pass either.
The second pass runs the JavaScript and indexes the result. This usually completes, but not instantly, and the delay matters most for sites publishing frequently: content that is time-sensitive can be indexed after it stops being useful.
The critical limitation is that rendering is not browsing. Googlebot does not click, scroll, hover or fill forms. Content behind any interaction is invisible regardless of how well the JavaScript works — a distinction that catches out a lot of otherwise well-built sites.
The Patterns That Cause Problems
These are the specific implementations that lose content. Each is common, each looks fine in a browser, and each is straightforward to avoid once you know it matters.
Content revealed by clicking
Tabs, accordions and "load more" buttons where the content is fetched on click rather than merely hidden with CSS. Content already in the HTML and hidden with CSS is indexed normally; content that does not exist until a click does not exist to a crawler.
Infinite scroll with no linked pagination
If items load only as the user scrolls, the crawler sees the first batch and nothing else. Provide real paginated URLs alongside the scroll behaviour so every item is reachable by a plain link.
Navigation that isn't links
Menus built from click handlers on div elements rather than anchor tags with href attributes. Crawlers follow hrefs. If your navigation has none, your site has no discoverable structure.
Metadata set only by client-side JavaScript
Titles, descriptions and canonical tags injected after load are frequently missed. Anything a crawler needs in the head should be in the server's response.
Blocking your own scripts in robots.txt
If robots.txt disallows the JavaScript and CSS bundles, Google cannot render the page and sees the empty shell. An old habit from when blocking script directories seemed tidy, and actively harmful now.
Testing What Googlebot Sees
Do not assume — check. These take a few minutes each and give a definitive answer rather than an impression.
- 01
View source, not inspect element
View source shows the HTML the server sent; inspect element shows the DOM after JavaScript has run. The difference between them is exactly what depends on rendering. If your main content is missing from view source, it is second-pass content.
- 02
Use URL Inspection's rendered HTML
In Search Console, inspect a live URL and open the rendered HTML and screenshot. This is Google's own rendering of your page — the closest thing to ground truth available.
- 03
Disable JavaScript and reload
A crude but revealing test. Whatever remains is roughly what the first pass sees. If the page is blank, everything you have depends on successful rendering.
- 04
Search for a distinctive phrase
Take an exact sentence from deep in the page and search it in quotes with a site: filter. If it does not come back, that content is not indexed — regardless of what any tool suggested.
Choosing a Rendering Strategy
Most JavaScript SEO problems are solved by rendering choice rather than by patching symptoms. Modern frameworks make all of these routine.
| How it works | Best for | |
|---|---|---|
| Static generation | Pages built to HTML at build time and served from a cache | Marketing sites, blogs, documentation — anything not personalised. Fastest and safest for SEO |
| Server-side rendering | HTML generated per request on the server | Content that changes constantly or depends on the request |
| Client-side rendering | Browser builds the page from an empty shell | Logged-in application screens that should not be indexed anyway |
| Hybrid | Static or server-rendered shell, interactivity added after | Most real sites. Public content in the HTML, app behaviour layered on top |
Common Questions
What people ask about JavaScript and search.
Is React or Next.js bad for SEO?
No — the framework is not the issue, the rendering strategy is. A Next.js site using static generation or server rendering ships complete HTML and has no disadvantage at all. The same framework used purely client-side does.
Do other search engines render JavaScript?
Less reliably than Google, and AI crawlers vary considerably — several fetch raw HTML without executing scripts. If being cited by answer engines matters to you, server-rendered content is the safer choice.
Is hidden content in tabs penalised?
Content present in the HTML and hidden with CSS is indexed normally and treated as part of the page. The problem is only content that does not exist until an interaction fetches it.
How long does the second pass take?
Usually days rather than the weeks it once was, though it varies with site authority and crawl demand. For most sites it is acceptable; for anything time-sensitive it is a reason to render server-side.