JavaScript Framework SEO: Next.js, React and Vue Without Ranking Loss

JavaScript frameworks like Next.js, React and Vue make fast, interactive sites possible. But the same technology that makes your app feel smooth can quietly erode your rankings. The short answer: the framework does not rank, the rendering strategy does. The moment a search engine or AI crawler fetches your page and sees only an empty <div id="root">, you lose visibility that no amount of link building or content will win back. In this article you will learn where the framework-specific traps sit and how to avoid them.

Why JavaScript frameworks are an SEO problem

A classic server-rendered page returns ready-made HTML: a bot fetches the URL and immediately reads your headings, text and links. A typical single-page app does the opposite. The server sends a virtually empty HTML shell, and the content only appears once the browser has downloaded and executed the JavaScript bundle.

Google can render JavaScript, but it does so in a second pass, after the HTML has already been fetched. That rendering pass costs time and compute, and it is not guaranteed to run quickly for every page. Other crawlers, including some of the bots behind AI search engines such as ChatGPT and Perplexity, do not render JavaScript at all or do so far more sparingly. For a B2B site that wants to rank and be cited, that is a double risk: whatever is not in the first HTML simply does not exist for a large part of the search landscape.

This is not an abstract debate. It hits the core of SEO: can a bot read your content, understand it and follow the links to your service pages? Every technical audit we run starts there, because a framework choice that sabotages the first crawl weakens every other effort.

Hydration: the silent killer

Hydration is the process where your framework brings the static HTML sent by the server “to life” by attaching JavaScript event listeners to it. The problem: a page can look fully loaded while it is not yet interactive, because hydration is still running.

To users, that feels like a page briefly freezing. For your Core Web Vitals, it is more damaging. Heavy hydration shifts work onto the main thread and pushes your Interaction to Next Paint and Largest Contentful Paint in the wrong direction. And those are exactly the signals that feed into how Google judges the user experience of your page.

There is something subtler at play too: hydration mismatches. When the HTML the server renders does not match exactly what the client expects, the framework throws away the server version and re-renders from scratch on the client. The net effect is that you lose the SEO benefit of server rendering precisely on the pages where you need it. You rarely see these errors in your own browser, because it finishes everything neatly. A bot that fetches the page only once, and faster, often sees the half-finished version.

The practical lesson: sending less JavaScript to the client is almost always better for SEO than sending more. Every framework covered below offers ways to do that, but you have to choose them deliberately.

Next.js SEO: powerful, but configuration decides everything

Next.js is often recommended as “the SEO-friendly React choice”, and rightly so, provided you pick the right rendering mode per page. Next.js gives you a per-route choice between static generation, server-side rendering and client-side rendering, plus newer server components that run on the server by default and send less JavaScript to the client.

The trap is that this flexibility is also how things go wrong. A common mistake is loading content in a useEffect, which means it only appears after hydration and therefore falls outside the first HTML. A second is mishandling errors during server rendering: an uncaught error on the server makes Next.js fall back to client rendering, and your server-rendered HTML disappears without a sound. A third is metadata set dynamically on the client instead of server-side, which stops your title and meta tags from being picked up reliably by crawlers.

For B2B we generally recommend static generation or server rendering for anything that has to rank: service pages, knowledge articles, case pages. Save pure client-side rendering for what genuinely sits behind a login or an interaction. That keeps your commercial pages readable on the very first fetch.

React SEO: client-side by default, and that is the risk

A bare React app (think of a Create React App setup or a client-only Vite build) renders entirely in the browser by default. The server delivers an empty shell, and without executed JavaScript a bot sees no content. For a marketing site, that is the worst imaginable starting position.

React does not solve this on its own; you need a framework or rendering layer around it. In practice that means using React through a meta-framework such as Next.js or Remix, or adding server-side rendering with renderToString and your own server. Keeping React purely client-side means implicitly choosing pre-rendering or dynamic rendering as a band-aid, and those are extra moving parts that can break.

The heaviest signal: if your most important content only appears after an API call from the browser returns, you are betting that every crawler executes your JavaScript and waits for your API. That is a bet you do not want to take on your money pages. If you want to know whether your site has this problem, it helps to check whether Google is indexing your pages correctly and what the rendered HTML actually looks like.

Vue: the same dividing line, different names

Vue has exactly the same split. A standard Vue app renders client-side, with the same empty-shell problems as React. Here the solution is called Nuxt, the meta-framework that brings server rendering, static generation and hybrid rendering to Vue, comparable to what Next.js does for React.

The traps run in parallel: client-only data fetching that pushes content outside the first HTML, hydration mismatches when server and client state diverge, and metadata that is not set server-side. The names differ, the mental model does not. If you choose Vue, deliberately choose Nuxt with server or static rendering for everything that has to deliver visibility.

How to judge a framework on pipeline

A framework choice is not a matter of taste for the development team alone. The question that counts: can a bot read your commercial pages on the first fetch, without executing JavaScript? A simple test is to fetch a page’s source without rendering (for example via “view source” or a fetch without JavaScript) and check whether your core content, headings and internal links are in there.

A few rules of thumb we apply:

• Render everything that has to rank on the server or up front (SSR or SSG), not in the browser.
• Keep metadata server-side, so title, meta description and canonical are read reliably.
• Limit client-side JavaScript: less hydration means better Core Web Vitals and less chance of mismatches.
• Test with the real rendered HTML, not with what your own browser eventually finishes.
• Treat your redesign or migration as a risk moment, because a framework switch is exactly where rankings collapse after a website redesign.

The deeper point: for us, SEO is the acquisition layer of one steered growth machine, not a separate technical checklist. A framework that gives beautiful demos but makes your service pages unreadable for crawlers costs you pipeline, not just positions in a report. That is why we always fold the technical rendering choice into the broader strategy, alongside related decisions such as your headless CMS setup. And if you work without a fixed visiting address but still want to be found locally, your approach to local SEO without a physical address matters as much as rendering.

Wondering whether your Next.js, React or Vue site is readable on the first crawl, and whether your content is picked up by AI search engines too? Our SEO specialist maps out your rendering, hydration and indexing, and ties it to concrete growth. Get in touch and we will look together at where your visibility is leaking.