Key takeaways
- JavaScript SEO is the work of making sure a crawler can reach, render and index content that a framework builds in the browser.
- Googlebot is Google's crawler, and it renders pages with a current version of headless Chrome, which means JavaScript content is indexed later and less reliably than content already present in the server's HTML response.
- If a page is never indexed it cannot rank, appear in a site search on Google, or be quoted in an AI answer, so an indexing failure is total rather than partial.
- You get Google to crawl a site by giving it discoverable anchor links, an accurate sitemap, unblocked resources and server responses fast enough to finish, not by resubmitting URLs.
- Almost every framework indexing problem traces to one cause: something important exists only after client-side JavaScript runs.
JavaScript SEO exists because a framework can build a page the browser understands and a crawler misses. Google renders JavaScript, but rendering is slower and more fragile than reading HTML, so anything that only appears after the render is at risk. This guide covers how the pipeline works, which rendering choice to make, the failures worth checking first, and how to tell what a crawler actually receives.
Where the diagnosis and the fix span server configuration, build tooling and templates, that is our technical SEO services work.
How Google Crawls, Renders and Indexes a JavaScript Page
Google handles a page in stages rather than one pass, and each stage can fail independently.
- Crawl. Googlebot requests the URL and receives whatever the server returns. Any content and links in that response are available immediately.
- Queue for rendering. If the page needs JavaScript to be complete, it joins a render queue. The Web Rendering Service runs a current version of headless Chrome.
- Render. Chrome executes the JavaScript, builds the DOM and produces rendered HTML.
- Index. Google indexes the rendered result and discovers any links that only appeared during rendering.
The old two-wave model, where Google indexed raw HTML first and rendered later, describes the shape of the problem accurately even though the queue is usually fast now. What has not changed is the ordering: the initial HTML is free, and everything after it depends on a render finishing. Under crawl pressure, on large sites, or when a script throws, that render is delayed or never completes.
Two consequences follow. Links added only by JavaScript are discovered late, which slows crawling on big sites. And if rendering fails, Google can index the raw response with your content missing, which looks like a thin page rather than an error.
Rendering Choices Compared: CSR, SSR, SSG and Prerendering
Your rendering mode decides how much of the page exists before any JavaScript runs. That single decision does more for indexing than every other item on this page combined.
| Mode | What the crawler receives first | Indexing risk | Best fit |
|---|---|---|---|
| Client-side rendering | An empty shell plus scripts | Highest, content depends entirely on the render queue | App screens behind a login that should not rank |
| Server-side rendering | Complete HTML per request | Low, content is in the first response | Pages that change often: listings, product pages, search results |
| Static generation | Complete HTML built at deploy time | Lowest, plain files from a CDN | Content that changes on a schedule: guides, marketing pages, docs |
| Incremental or on-demand regeneration | Complete HTML, refreshed in the background | Low | Large catalogues where a full rebuild is impractical |
| Dynamic rendering | Prerendered HTML for bots, the app for users | Medium, and two code paths to keep aligned | A legacy client-rendered app you cannot migrate yet |
The framework choices follow from that table. React sites reach for Next.js, Vue sites for Nuxt, Angular for its own server-side rendering, Svelte for SvelteKit. In every case the rule is the same: prerender or server-render each route you want indexed, and keep client-side rendering for screens that never need to appear in search.
How to Get Google to Crawl Your Site
Crawling is a supply problem and a discovery problem. Google needs to know a URL exists and needs to be able to fetch it without waste.
- Give every important page a real anchor tag with an href. Googlebot follows links; it does not click handlers that call the router.
- Keep a sitemap that lists canonical, indexable URLs only, and reference it in robots.txt. A sitemap full of redirects and noindex pages trains Google to trust it less.
- Unblock what rendering needs. If robots.txt disallows your script bundles, styles or the API routes that supply content, the render produces a broken page.
- Return the right status codes. A soft 404 that returns 200 with an empty shell wastes crawl requests and can get the URL classified as duplicate or thin.
- Reduce waste. Parameter permutations, infinite filter combinations and calendar pages consume the same budget as your real pages. Canonicalise or block them.
- Keep server responses quick under load. Crawl rate adjusts to how well your server holds up, so a slow origin quietly lowers how much gets fetched.
- Use URL Inspection to request indexing for individual new pages, and rely on internal links and the sitemap for everything else. Repeated resubmission does not raise priority.
Internal linking is the lever most teams underuse. A page reachable in two clicks from the homepage, with descriptive anchor text, gets crawled and recrawled far more readily than a page only reachable from a paginated archive on screen nine. Our pre-launch technical audit checklist covers how to crawl a site twice, once with rendering enabled and once without, and read the difference.
The JavaScript SEO Failures That Do the Most Damage
These are the issues that turn up repeatedly on audits, in rough order of how much they cost in lost visibility.
Blocked resources come first, because they break rendering outright. Check robots.txt for any disallow rule covering bundle directories or the endpoints that feed page content.
Content behind an interaction comes next. Tabs, accordions and sections that fetch data on click or on scroll are risky, since a crawler does not interact. Load the content into the DOM and hide it with CSS if you must; CSS-hidden text is still indexed, while text that does not exist until an event fires is not.
Then navigation that is not made of links. A div with a click handler is invisible as a path through the site. Every internal route needs an anchor with an href, even if the router intercepts the click.
Hydration mismatches follow. If the server output and the first client render disagree, some frameworks discard the server HTML and rebuild in the browser, which drops that page back to client-side behaviour. Common causes: reading window or localStorage during server rendering, timestamps, and randomised content.
Metadata set only in the browser is a quieter version of the same problem. Titles, descriptions, canonicals and structured data injected late may be missed, so define them where the server renders them and verify they appear in the response rather than only in the tab.
Last, slow data fetches. If the page renders a spinner while an API responds, a crawler can capture the spinner. Render something meaningful server-side instead of a loading skeleton, and treat rendering reliability and Core Web Vitals as the same project, since a lighter bundle both renders and measures better.
How to Tell Whether Your Content Is Client-Rendered
You cannot fix what you have not seen. Three checks settle it in about ten minutes.
View source against the rendered DOM. View Source shows the raw server response; the Elements panel shows the DOM after scripts run. Content present in Elements and absent from View Source is client-rendered, and that is your signal to move it.
URL Inspection in Search Console, live test. Open the rendered HTML and the screenshot, then ask three questions: is the main content there, are internal links present as anchors, and are the title, description and canonical correct. If content is missing here, it is not being indexed.
A crawl with rendering enabled, compared against a raw crawl. Pages that lose word count, links or titles between the two crawls are the ones exposed to rendering risk, and this is the only one of the three checks that scales past a single URL.
Test on mobile and on a throttled connection while you are there, since Google indexes the mobile render, and a bundle that renders comfortably on a workstation can time out on the rendering path.
A Fix Sequence That Works in Order
Sequence matters, because several of these fixes make the later ones easier to verify.
- Unblock scripts, styles and content endpoints in robots.txt.
- Move public, indexable routes to server rendering or static generation. Leave authenticated screens client-rendered.
- Convert JavaScript navigation to anchors with real hrefs.
- Put titles, descriptions, canonicals and structured data in the server-rendered head.
- Load important content on page load rather than on interaction.
- Re-verify with URL Inspection and a rendered crawl, and compare against the raw crawl you captured first.
If a front-end rebuild is already planned, fold this work into it rather than patching afterwards. Our guide to website redesign SEO covers the launch side, and the migration checklist covers URL mapping when the rebuild changes paths as well as templates.
Related terms
You may see this topic described with related searches like crawl budget seo, javascript seo audit, javascript seo guide, next.js seo, and render seo. Those phrases are useful when they clarify what the reader needs next, but they should still point back to one clear plan.
Related searches such as rendering seo, seo react, and spa seo are useful when they clarify what the reader needs next. They should support the same plan rather than pulling the page in several directions at once.
Frequently asked questions
What is a Googlebot crawler?
Googlebot is the program Google uses to fetch pages from the web. It requests URLs, reads the response, follows the anchor links it finds, and passes pages that need JavaScript to a rendering service running a current version of headless Chrome. It exists in smartphone and desktop variants, indexes the mobile render for most sites, and adjusts how fast it crawls based on how your server responds.
What happens if a website is not indexed?
It cannot appear in search results at all, so no ranking work applies to it and no AI system that relies on the index can cite it. Indexing is binary in that sense: a page that is crawled but not indexed produces nothing. The usual causes are a noindex tag left on after launch, a canonical pointing elsewhere, a blocked resource that breaks rendering, or content that only exists after a client-side render.
Does Google index content that appears only after a click?
Usually not. A crawler does not click tabs, expand accordions or scroll to trigger lazy loads, so anything fetched by those interactions may never enter the rendered DOM. The safe pattern is to include the content in the initial markup and control its visibility with CSS, which keeps it indexable while still hiding it from the reader until they ask for it.
Is dynamic rendering still a reasonable fix?
Treat it as a bridge with an end date. Serving prerendered HTML to crawlers and the client-rendered app to people means maintaining two outputs, and if they drift you have a cloaking problem as well as an indexing one. It is defensible while a legacy application is being migrated. It is not a destination, and server rendering or static generation is a shorter road than most teams expect.
How do I get Google to crawl my site?
Start by crawling the site the way a search engine would, then check which important pages are blocked, duplicated, canonicalized away, or missing from internal links. Fix the access problem before rewriting content.