Modern websites rely heavily on JavaScript, and search engines have become much better at handling it. Google renders pages with an up-to-date version of Chrome. But "can render" isn't the same as "will reliably see everything, quickly". Many AI crawlers don't run JavaScript at all. If your important content, links or metadata only appear after scripts run, you're taking an unnecessary risk. This guide explains how rendering works and how to make JavaScript sites search-friendly.
How Google processes JavaScript pages
- Crawl: Googlebot fetches the URL and receives the initial HTML.
- Render: when resources allow, Google runs the page's JavaScript in a headless browser to see the final content.
- Index: Google indexes what it found, including content added by JavaScript.
The catch is step 2. Rendering takes resources, can happen later than crawling, and fails if scripts error, time out or are blocked by robots.txt.
Rendering strategies compared
| Strategy | What the crawler receives | SEO risk | Good for |
|---|---|---|---|
| Client-side rendering (CSR) | A mostly empty HTML shell; content built in the browser | Higher | Logged-in apps and dashboards |
| Server-side rendering (SSR) | Complete HTML generated per request | Low | Dynamic, personalised or frequently changing pages |
| Static site generation (SSG) | Complete HTML built ahead of time | Lowest | Marketing pages, articles, documentation |
| Incremental static regeneration (ISR) | Static HTML, refreshed in the background | Low | Large catalogues and content sites |
| Dynamic rendering | Different HTML for bots and users | Medium | A legacy workaround, no longer recommended |
Frameworks such as Next.js, Nuxt and SvelteKit make SSR and static generation straightforward, which is a big reason they suit marketing and e-commerce sites.
Common JavaScript SEO problems
Content that only loads after interaction
Text hidden behind "load more" buttons, tabs that fetch content on click, or infinite scroll without paginated URLs may never be seen.
Links that aren't links
Search engines follow <a href="..."> links. Navigation built with buttons or click handlers that change the page with JavaScript can leave pages undiscovered.
Metadata set too late
Titles, meta descriptions and canonical tags injected by client-side scripts may be missed or read inconsistently. Render them on the server.
Blocked resources
If robots.txt blocks the JavaScript or API endpoints a page needs, Google can't render it. Test with our robots.txt tester.
Errors and timeouts
A single script error can stop the page building. Heavy bundles can time out during rendering.
Soft 404s
Single-page apps sometimes return a 200 status for pages that don't exist, showing a "not found" message only in the browser. Return a real 404 status.
A JavaScript SEO checklist
- Important content is present in the initial HTML (view source, not just inspect)
- Every page has a unique URL that loads directly
- Navigation uses real
<a href>links - Titles, descriptions, canonicals and structured data are server-rendered
- robots.txt doesn't block required scripts or APIs
- Missing pages return a 404 status
- Pagination has crawlable URLs, not only infinite scroll
- JavaScript bundles are split and lazy-loaded to stay fast
How to test your pages
- View the source of the page. If your main content isn't there, it depends on client-side rendering.
- Use URL Inspection in Google Search Console to see the rendered HTML and screenshot Google produced.
- Run the Rich Results Test to check structured data in the rendered page.
- Check indexability with our free indexability checker: status code, robots meta, canonical and robots.txt in one go.
- Disable JavaScript in your browser for a rough idea of what non-rendering crawlers see.
Don't forget AI crawlers
AI assistants are becoming a source of traffic and recommendations. Many of their crawlers fetch raw HTML and don't execute JavaScript reliably. Server-rendered content is far more likely to be read and cited. Check which AI crawlers you allow with our AI crawler check.
Performance matters too
Heavy JavaScript slows interaction, which hurts Interaction to Next Paint, one of the Core Web Vitals. Ship less JavaScript, defer non-essential scripts and avoid hydrating parts of the page that don't need interactivity.
Framework notes
| Framework or setup | Default rendering | SEO notes |
|---|---|---|
| Next.js | Server or static rendering available per page | Strong choice for SEO; use server components and metadata APIs |
| Nuxt (Vue) | Server rendering available | Similar strengths to Next.js |
| SvelteKit | Server rendering by default | Good SEO defaults |
| Create React App or Vite SPA | Client-side rendering | Riskier; consider pre-rendering or migrating key pages |
| Angular | Client-side by default; server rendering available | Enable server rendering for public pages |
| WordPress with heavy JS widgets | Server-rendered HTML plus scripts | Check that widget content is in the HTML if it matters for SEO |
A quick diagnosis workflow
- Pick a page that isn't ranking or indexed.
- View source: is the main content and title present?
- URL Inspection: does Google's rendered HTML include the content? Any blocked resources?
- Check status codes: does the page return 200, and do missing pages return 404?
- Check links: can the page be reached through normal
<a href>links? - Check speed: are large scripts delaying rendering or interaction?
- Fix the root cause, usually by server-rendering the page, then request reindexing.
Most JavaScript SEO problems trace back to one of these steps, and server rendering fixes the majority.
How we build it
Our sites are built with server rendering or static generation by default, with metadata, structured data and sitemaps generated on the server. If your current JavaScript site has indexing problems, our technical SEO team can diagnose and fix them.
The short version
Google can render JavaScript, but it's slower and more fragile than reading HTML, and many AI crawlers don't render at all. Use server-side rendering or static generation for pages that need to rank, use real links, render metadata on the server, don't block resources, return proper status codes and test with URL Inspection.
