Search engines can miss content that only appears after your scripts run. Here is how to spot the problem and which rendering approach fixes it.
JavaScript SEO is the work of making sure search engines can find, render and index content that a site builds with JavaScript. If your pages load an empty shell and then fill it in with a framework like React, Vue or Angular, that is the problem JavaScript SEO solves.
Why JavaScript creates an indexing problem
Googlebot crawls in two waves. First it fetches the raw HTML. Then, when rendering resources free up, it runs the JavaScript and looks again. That second pass can happen minutes later or days later. Anything that only exists after the script runs sits in a queue until then.
Other crawlers are worse. Bing renders some JavaScript, but inconsistently. Most AI crawlers, including the ones behind ChatGPT and Perplexity, do not execute JavaScript at all. They read the HTML they are served and move on. If your product descriptions only appear after a client side fetch, those tools see a blank page.
What breaks most often
- Links built as click handlers. A div with an onclick is not a link. Crawlers follow href attributes on anchor tags, nothing else.
- Content behind user actions. If a tab, an accordion or a “load more” button triggers a fetch, the content underneath may never be indexed.
- Blocked script files. Disallowing /static/ or /assets/ in robots.txt stops Google rendering the page properly.
- Titles and meta set by script. Google usually picks these up, but the first pass sees whatever the shell contained, and other crawlers keep the shell version for good.
- Routing without real URLs. Hash based routes and state changes that never update the address bar give you one indexable page instead of fifty.
Rendering choices ranked
Server side rendering is the safest option. The server builds the full HTML and sends it, so every crawler gets the content immediately. Static generation is just as good and faster, if your content does not change per visit.
Dynamic rendering, where you serve prerendered HTML to bots and the app to people, still works but Google calls it a workaround. It adds a maintenance burden and a cloaking risk if the two versions drift apart. Client side rendering on its own is the weakest choice for anything you want ranked.
How to check your own site
Open a page, view source, and search for a sentence you can see on screen. If it is not in the source, it is coming from JavaScript. Then run the URL through the URL Inspection tool in Search Console, click Test live URL, then View tested page. That shows you the rendered HTML Google actually holds.
Compare the two. Anything present in the rendered version but missing from the source is at risk for every crawler that does not render. Our technical SEO team runs this check across the top twenty templates on a site rather than page by page, because rendering problems repeat by template, not by URL.
Related reading: our guides to indexability, mobile-first indexing and creating an XML sitemap.
Common questions
Does Google index JavaScript content?
Yes, usually. Googlebot renders pages and indexes what it finds. The catch is timing and reliability. Rendering happens on a delay, and pages with heavy scripts, timeouts or console errors can end up indexed in their unrendered state.
Is server side rendering worth the rebuild cost?
For sites where organic search drives real revenue, usually yes. If you are on Next.js or Nuxt already, switching a route to server rendering is a config change rather than a rebuild. For an older single page app the cost is genuine and worth costing properly before you commit.
How do I know if JavaScript is hurting my rankings?
Look for pages indexed with thin or missing content, a sudden drop after a framework upgrade, or a gap between the pages you have published and the pages Search Console reports as indexed. Those three patterns point at rendering.
Do AI search tools render JavaScript?
Mostly not. Treat them as plain HTML readers. If you want your pages quoted in AI answers, the content needs to be in the source that gets served.
See our glossary entry for JavaScript SEO.
