SEO guide for JavaScript websites

As an SEO agency, we increasingly take on projects built with React, Vue, Angular, Next.js or Nuxt. They are fast websites with an excellent app-like experience, but they raise one very specific challenge: the search engine does not see the pages the way a user does. SEO for JavaScript-based websites is not a separate world with its own rules; it is the same principles as always, conditioned by how and when the content is rendered. If the HTML arrives empty and the content only appears after executing JavaScript in the browser, you are gambling with indexing. The good news is that this is solved with a deliberate rendering strategy. In this guide we explain how to approach SEO for JavaScript-based websites with no surprises in Google.

SEO for JavaScript-based websites:

• How Google crawls and indexes JavaScript
• Rendering models: CSR, SSR, SSG and ISR
• Hydration and its impact on SEO
• Common mistakes that ruin indexing
• Internal linking and navigation
• Metadata, canonical and structured data
• Core Web Vitals and INP
• Prerendering and dynamic rendering
• How to check what Google sees
• Conclusion: architecture decisions

How Google crawls and indexes JavaScript

Google processes JavaScript websites in two phases. First it crawls the initial HTML and extracts what it finds. Then the page enters a rendering queue where the Web Rendering Service executes the JavaScript and analyzes the final DOM. Time can pass between one phase and the other, and if the code is complex or fails, the content may remain invisible or be indexed in its skeleton state. This is the key to all of SEO for JavaScript-based websites: the more your content depends on executing on the client, the more room there is for something to be lost along the way. Other search engines and many AI crawlers render JavaScript worse than Google, so betting everything on client-side rendering is risky.

Rendering models: CSR, SSR, SSG and ISR

The most important decision is the rendering model. Client-side rendering (CSR) sends an almost empty HTML plus a JavaScript bundle that builds the page in the browser; it gives a great experience after the first load, but slows down and complicates indexing. Server-side rendering (SSR) generates the full HTML on each request, so the search engine receives the content ready without executing anything; it improves SEO and perceived speed at the cost of more server load. Static site generation (SSG) and incremental regeneration (ISR) pre-build pages at build time and refresh them as needed: very fast loads and solid SEO for content that does not change every second.

Our rule of thumb: use SSR or SSG/ISR for everything that must rank (marketing pages, product pages, articles) and reserve CSR for private areas that do not need to be indexed, such as dashboards or user areas. When in doubt, deliver meaningful HTML up front. Frameworks like Next.js, Nuxt or SvelteKit are designed for this from the ground up, which gives a custom-built site an advantage over solutions that add it after the fact.

Hydration and its impact on SEO

The most widespread hybrid approach combines SSR with client-side interactivity through hydration: the server delivers the HTML and then the JavaScript "reconnects" the components to make them interactive. It sounds ideal, but it is where many projects lose rankings. If the server HTML does not match what the client expects, the framework may tear down the DOM and rebuild it, doubling the rendering cost. And heavy hydration blocks the main thread, worsens interactivity and penalizes Core Web Vitals. The solutions involve code splitting, lazy-loading components that are not on screen and applying techniques like selective or partial hydration to send less JavaScript. Less code in the initial load is almost always better SEO.

Common mistakes that ruin indexing

In audits we always find the same failures. Important content or links that only appear after a user interaction, which the search engine never triggers. Meta tags and canonicals injected by JavaScript after load, when they should come in the initial HTML. Internal links implemented as event handlers (onclick) instead of real tags, invisible to the crawler. And huge bundles that exhaust the crawl budget and leave pages unindexed. The definitive test is simple: disable JavaScript and see whether the critical content, the links and the metadata are still there.

Internal linking and navigation

The crawler discovers pages by following links, and it only understands real links. Always use with crawlable URLs for internal navigation, never navigation governed exclusively by JavaScript state. Make sure the application routes have clean, unique URLs per content, not fragments managed only on the client. Good internal linking distributes authority towards the pages you want to rank and helps the search engine reach the whole site in few clicks. This is a technical SEO principle that does not change because you use JavaScript, but in an SPA it must be watched closely.

Metadata, canonical and structured data

Titles, meta descriptions, canonicals and structured data must be present in the HTML the search engine receives, not added late by JavaScript. With SSR or SSG this is resolved naturally. Each route must have its own unique title and meta description, its correct canonical and, where applicable, its schema markup in JSON-LD within the server response. In single-page applications you must ensure these elements are updated per route and remain in the served HTML. Check with "view source" that everything is where it should be.

Core Web Vitals and INP

Performance is ranking, and JavaScript is the main enemy here. Since 2024, INP (Interaction to Next Paint) replaced FID as the interactivity metric within Core Web Vitals, and it measures how quickly the page responds to user actions. Heavy bundles and slow hydration send INP soaring, while CSR delays LCP and makes layout shifts that worsen CLS more likely. All three metrics suffer with poorly managed client-side rendering. Prioritize: delivering meaningful content as soon as possible, splitting and deferring non-critical JavaScript, reserving space to avoid shifts and watching field data in Search Console, not just lab figures.

Prerendering and dynamic rendering

If you cannot migrate to SSR or SSG in one go, prerendering is a middle route: services that generate a static, pre-rendered version of your pages for search engines while the user keeps the dynamic experience. Dynamic rendering (serving plain HTML to bots and the JavaScript version to users) was a Google recommendation in its time, but today it is considered a temporary solution, not a long-term architecture. Use it as a targeted patch while you redesign the rendering model, not as a final destination.

How to check what Google sees

Do not take anything for granted: measure. The URL inspection tool in Google Search Console shows the rendered HTML that Googlebot sees and reveals what content is missing from the initial load. Complement it by disabling JavaScript to verify what remains, reviewing the browser console for hydration errors and using crawling tools that execute JavaScript to simulate rendering. Pages marked as "Crawled - currently not indexed" are usually a symptom of rendering or performance problems.

Conclusion: architecture decisions

SEO for JavaScript-based websites is won or lost in the architecture, not in last-minute tweaks. Choosing the right rendering model, delivering meaningful HTML up front, keeping links and metadata crawlable and controlling the weight of JavaScript solves the vast majority of problems. If you are building a new website, decide the rendering approach from day one; if your project no longer performs in search engines, a technical audit will identify where the content is being lost. In custom e-commerce or complex website projects, this planning is the difference between indexing well or not appearing at all. At our agency we can help you set the right architecture.