JavaScript SEO: making a site indexable

How does Google process JavaScript?

Google describes three phases in its JavaScript SEO basics (updated on March 4, 2026): crawling, rendering, then indexing. Googlebot first fetches the HTML. Pages that respond with 200 then enter a render queue. There, a headless browser runs the JavaScript. The resulting content is finally indexed. All of JavaScript SEO follows from this process.

The key point fits in one sentence from Google: the page may stay in this queue for a few seconds, sometimes longer. Anything that only appears after the JavaScript runs is therefore discovered later than the initial HTML.

The rendering engine itself is up to date. Since May 2019, Googlebot has used a recent version of Chromium, upgraded regularly (announcement of the “evergreen” Googlebot, May 7, 2019). Modern frameworks can therefore be read. The risk lies in the delay and in what fails during rendering, more than in compatibility.

What risks does JavaScript pose for SEO?

• Content missing from the initial HTML: text loaded afterwards, invisible to any crawler that does not render the page.
• Uncrawlable links: Google only follows <a> tags with an href attribute (Google’s rules on crawlable links). An onclick on a button is not enough.
• Fragment-based navigation: URLs in #/page are not treated as separate pages. Google recommends the History API.
• Soft 404s in single-page applications: an error page served with 200 can be indexed as a real page.
• Tags changed by script: Google asks you not to use JavaScript to change the canonical URL declared in the HTML.
• Blocked resources: JS or CSS files disallowed in robots.txt prevent correct rendering.

Script weight also affects the experience. Heavy JavaScript degrades the responsiveness measured by Core Web Vitals, especially INP.

Do AI crawlers read JavaScript?

Most of them do not. Vercel and MERJ analyzed traffic on nextjs.org and the Vercel network (“The rise of the AI crawler” study, December 17, 2024). None of the major AI crawlers observed ran JavaScript. This covers OpenAI’s GPTBot, OAI-SearchBot and ChatGPT-User, Anthropic’s ClaudeBot, PerplexityBot, Meta-ExternalAgent and Bytespider. Two exceptions: Gemini relies on Googlebot’s infrastructure, and AppleBot renders pages.

The practical consequence: content that is visible only after JavaScript rendering is unlikely to be picked up by these assistants. The crawlers and their access are covered in detail in our guide to AI crawlers. This study dates from late 2024: behavior may have changed since.

CSR, SSR, SSG: which rendering mode should you choose?

Addy Osmani and Jason Miller wrote the web.dev article Rendering on the Web (updated on January 5, 2026). They recommend considering server-side or static rendering rather than full client-side rehydration.

Mode	Principle	How search engines read it
CSR (client-side rendering)	The browser builds the page with JavaScript	Depends on rendering; content invisible to crawlers that do not run JS
SSR (server-side rendering)	The server sends complete HTML for each request	Content readable from the initial HTML
SSG (static site generation)	HTML pages are generated when the site is built	Content readable from the initial HTML, fast pages
Hydration	Server HTML, then JavaScript that adds interactivity	Content readable; watch the script weight
Dynamic rendering	Pre-rendered HTML served only to crawlers	Workaround that Google advises against

On dynamic rendering, Google’s position (updated on December 10, 2025) is clear. It was a workaround, not a long-term solution. Google recommends server-side rendering, static rendering or hydration. For a decision-maker, the rule is simple. A site that aims for organic traffic does not launch a pure client-side rendered framework without planning server-side rendering.

How do you test the JavaScript rendering of your pages?

1. Compare source and rendering: view the source code (Ctrl+U), then the browser inspector. If the main text or links only exist in the inspector, they depend on JavaScript.
2. Disable JavaScript in the browser and browse the page: navigation, content and links must remain accessible.
3. Crawl twice with Screaming Frog, with and without JavaScript rendering. The gap in discovered URLs, words and links gives the diagnosis.
4. Check Google’s view in the URL Inspection tool of Search Console, with “View crawled page”: rendered HTML, screenshot and blocked resources.

Is a page missing from the results? Follow Google’s step-by-step procedure, Fix Search-related JavaScript problems. This diagnosis is part of any technical SEO audit.

Which JavaScript SEO best practices should you apply?

• Serve the title, meta description, canonical and main content in the initial HTML.
• Use <a href> links to real URLs, without fragments.
• Return real HTTP codes: 404 for a missing page, 301 for a moved page.
• Do not block the JS and CSS files needed for rendering.
• Name files with a version fingerprint, for example main.2bb85551.js. Googlebot caches resources aggressively.
• Place structured data in the initial HTML when possible, for all crawlers.

JavaScript SEO applies the checks of technical SEO to sites that build their pages in the browser. The overall framework is in our SEO guide.