JavaScript SEO is the branch of technical SEO concerned with sites that rely on JavaScript to build their content, links or navigation, and with making sure search engines can still find, read and index those pages. It matters most for sites built with frameworks such as React, Vue or Angular, and for any page where important content appears only after a script runs.
How JavaScript SEO works
A traditional page arrives from the server as finished HTML. A JavaScript-heavy page often arrives as a nearly empty shell plus a bundle of code, and the browser builds the visible page from that code. This is known as client-side rendering.
Googlebot handles this in stages. It crawls the URL and reads the raw HTML first. The page then waits to be rendered by a headless version of Chrome, which runs the scripts and produces the final page. Only then can Google see content and links that the scripts added. Usually the wait is short, but on large sites or with heavy scripts it adds delay and room for failure: if a script errors, times out or is blocked, Google indexes whatever was left.
Not every crawler goes through that second step. Many other search engines, social media preview bots and several crawlers used by AI tools read only the raw HTML. For them, a client-rendered page may look blank.
The safest answer is to send meaningful HTML from the start. Server-side rendering and static generation build the page on the server, so the content is present before any script runs, and the scripts then add interactivity. Most modern frameworks support this. Dynamic rendering, which serves a pre-rendered version only to bots, was a workaround Google now describes as one it does not recommend.
Why it matters
A UK start-up can launch a fast, attractive React site and find, months later, that Google has indexed the homepage and little else. Typical reasons are internal links built as clickable elements rather than real links, product details fetched by scripts that time out, or every route returning the same title and description.
Even when Google does render the content, relying on rendering adds risk to every change. A plugin update that breaks a script can remove content from search without anyone noticing on the live site, because human visitors with modern browsers still see it.
Common mistakes
- Links without addresses. Navigation built with click handlers on buttons or divs, rather than <a href> links, gives crawlers nothing to follow.
- Hash-based routes. URLs like /#/services are treated as one page, because Google generally ignores what follows the hash.
- Blocking script or style files in robots.txt. If Google cannot fetch them, it cannot render the page as visitors see it.
- Identical titles and meta tags on every route. Single-page apps often set these once and never update them per page.
- Soft 404s. A missing product shows “not found” on screen but returns a 200 status, so the error page gets indexed.
- Content that needs a click. Text that loads only when a tab is clicked or the page is scrolled may never be rendered.
How to act on it
Compare the raw HTML with the rendered page. View the page source (not the inspector) and check whether the main text, headings, title and links are there. Then use the URL Inspection tool in Search Console to see Google’s rendered HTML and any blocked resources. A crawler run with and without JavaScript rendering shows the gap across the whole site.
If important content or links only appear after rendering, the long-term fix is usually server-side rendering or static generation for public pages, plus real links, unique titles per route and correct status codes. These changes touch the build itself, so I scope them with the developers as part of technical SEO work rather than as quick plugin fixes.