SEO for JavaScript Websites: Rendering Pitfalls
By CodexierPublished 4 min read
Modern websites are often built as JavaScript applications with React, Vue or similar frameworks. In a browser they look and work perfectly. To a search engine crawler, the first thing it receives may be an almost empty HTML page with a script tag. Google can run JavaScript, but not always immediately and not always completely, and many other crawlers, including most AI crawlers, do not run it at all. This guide explains where the gaps come from and how to close them.
How crawlers handle JavaScript
Googlebot fetches the URL and reads the raw HTML. Pages that need JavaScript go into a rendering queue, where a headless Chromium runs the scripts and captures the result. That second pass usually happens, but it costs Google resources, can be delayed, and fails if scripts error, time out or depend on things the crawler does not provide, such as user interaction or stored login state. Bing renders too, with similar limits. Social networks building link previews and most AI crawlers read the raw HTML only.
Client-side rendering risks
| Risk | What happens | Typical cause |
|---|---|---|
| Empty initial HTML | Crawlers without rendering see no content | Pure client-side rendering |
| Links crawlers cannot follow | Pages are never discovered | Navigation built with click handlers instead of real anchor tags with href |
| Wrong or missing meta tags | Same title everywhere, wrong canonical, no social preview | Tags set by JavaScript after load |
| Soft 404s | Missing pages return status 200 with a "not found" message | The server always returns the app shell |
| Content behind interaction | Tabs, accordions or "load more" content never indexed | Content fetched only on click or scroll |
Prerendering and server rendering
The fix is to deliver meaningful HTML on the first request. There are three main ways, and the right one depends on how often content changes and how many pages you have.
Static prerendering
Pages are rendered to HTML at build time. Ideal for marketing sites and content that changes with deployments. Fast and cheap to host.
Server-side rendering
HTML is generated per request on the server. Suits large catalogues and frequently changing content; needs a server runtime.
Hybrid
Frameworks such as Next.js and Nuxt mix both per route: static for marketing pages, server-rendered or client-side for the rest.
Dynamic rendering, serving a different version to bots than to users, was once recommended as a workaround but Google now describes it as a stopgap rather than a long-term solution. We prerender our own site's public pages for exactly these reasons.
Meta tags, canonicals and routing
- Each URL has its own title, description and canonical in the initial HTML.
- Internal links are real anchor elements with href attributes, not buttons with click handlers.
- Every page has a clean URL path; avoid hash-based routing like /#/services.
- Unknown URLs return a real 404 status, not the app shell with status 200.
- hreflang tags for Swedish and English versions are in the HTML, not injected later.
- Structured data is present in the rendered HTML; see structured data for business sites.
Testing what Google sees
- View the page source (not the inspector) and check that the main content and links are there.
- Use the URL Inspection tool in Google Search Console and look at the rendered HTML and screenshot.
- Compare indexed page count with the number of pages you expect.
- Fetch the page with JavaScript disabled or with a simple command-line request.
- Check social previews and a few AI assistants for how they describe your pages.
Rendering problems are among the most common findings in our technical SEO audits. When you do not need this: if your site runs on WordPress, Webflow or another server-rendered platform, rendering is rarely your SEO problem; look at content and links instead. If your JavaScript site is not getting indexed as expected, book a free call.
Frequently asked questions
Can Google index a React single-page app?
Often yes, but with delays and risks. Content that depends on user interaction, errors in scripts or slow data loading can leave pages partly indexed. Prerendering or server rendering removes most of the uncertainty.
Do AI search tools read JavaScript content?
Most AI crawlers read only the raw HTML. If your content appears only after JavaScript runs, it is likely invisible to them. Our guide to visibility in AI answers covers this further.
Is Next.js automatically good for SEO?
It makes server rendering and static generation easy, but only if you use them. A Next.js site that renders everything on the client has the same problems as any other single-page app.
Should we rebuild our site to fix rendering?
Usually not. Adding prerendering to an existing build, fixing links and moving meta tags into the HTML often solves the problem without a rebuild.
Is your JavaScript site invisible to search?
Send us your URL. In fifteen minutes we will show you what crawlers actually receive and what it would take to fix.
Book a free 15-minute call