“Next.js is SEO-friendly” is true, and also not automatic. It gives you the tools to ship fully-rendered HTML — it doesn’t stop you from writing a component that quietly undoes all of it with one misplaced useEffect. This is the React and Next.js-specific playbook: what to use by default, what the Metadata API actually fixed, and the exact code patterns that break indexing.
1. Plain React SPA vs. Next.js: Pick Your Starting Point
A plain React app built with Vite or Create React App renders entirely client-side by default — Googlebot’s first pass sees a near-empty HTML shell, and everything depends on the render queue catching up later. (For exactly how that queue works, see our JavaScript SEO Guide — this piece assumes that context and goes straight to React-specific fixes.) Next.js exists precisely to remove that dependency: its App Router defaults every component to a Server Component, meaning HTML is generated on the server or at build time, before any client JavaScript runs at all. That single default is why Next.js — not plain React — is the practical standard for anything that needs to rank.
2. Server Components vs. Client Components: The Core SEO Decision
Every file inside the app/ directory is a Server Component unless you explicitly opt out. Server Components fetch data and render to HTML on the server — search engines receive complete content with zero JavaScript execution required. Add "use client" at the top of a file only when you genuinely need interactivity: state, event handlers, browser-only APIs.
One nuance worth getting right: Client Components are not purely client-rendered. Next.js still pre-renders them to HTML on the server during the initial request — the “use client” directive controls where the component becomes interactive, not where it first gets its HTML. The SEO risk isn’t using Client Components; it’s putting your actual content-fetching logic inside one.
“use client”;
import { useEffect, useState } from “react”;
export default function BlogPage() {
const [posts, setPosts] = useState([]);
useEffect(() => {
fetch(“/api/posts”).then(r => r.json()).then(setPosts);
}, []);
return <PostList posts={posts} />;
}
export default async function BlogPage() {
const posts = await getPosts();
return <PostList posts={posts} />;
}
The first version ships an empty <div> in the initial HTML — the post list only exists after the browser runs JavaScript and the fetch resolves. The second version ships the full content in the very first response, no render queue required.
3. The Metadata API, and Why It Replaced next/head
The old Pages Router pattern, next/head, was itself a client-side component — it injected title and meta tags after hydration. That created a genuine race condition: Googlebot could crawl and index a page before the correct title and description had actually been injected, especially under any rendering delay. The App Router’s Metadata API removes the race entirely by generating metadata on the server and streaming it inside the initial HTML <head>, before a single byte of client JavaScript executes.
import { Metadata } from “next”;
export async function generateMetadata({ params }): Promise<Metadata> {
const post = await getPost(params.slug);
return {
title: post.title,
description: post.excerpt,
alternates: { canonical: `https://example.com/blog/${params.slug}` },
openGraph: { images: [post.ogImage], type: “article” },
};
}
Set a shared metadataBase and title template once in your root app/layout.tsx — every page’s generateMetadata then inherits sensible defaults and only needs to override what’s actually unique to that page. And one 2026-specific correction: viewport configuration now lives in its own separate viewport export, not bundled into the metadata object — a leftover pattern from earlier Next.js versions that will throw a build warning today.
4. File-Based SEO Conventions in the App Router
The App Router replaces several manual SEO tasks with file conventions the framework generates automatically:
app/sitemap.ts— exports a function returning your URL list; Next.js serves it as/sitemap.xmlautomatically, and it can pull dynamically from a database or CMS rather than being hand-maintained.app/robots.ts— generates/robots.txtprogrammatically, useful for environment-specific rules (blocking staging, allowing production).app/opengraph-image.tsx— generates a per-page Open Graph image dynamically instead of maintaining static image assets for every route.
5. React/Next.js SEO Code Checklist
- ✅ Content-critical components are Server Components (no
"use client"above them) - ✅ Every dynamic route has a
generateMetadatafunction, not a static export copied across pages - ✅ Canonical URLs set via
alternates.canonical, not omitted or hardcoded incorrectly - ✅
viewportexported separately frommetadata - ✅ Open Graph images are 1200×630, absolute URLs, unique per page
- ✅ Structured data uses JSON-LD (a script tag with
type="application/ld+json"), not microdata attributes - ✅
sitemap.tsandrobots.tsexist and resolve correctly in production - ✅ No admin, staging, or account routes leaking into the generated sitemap
6. Fixing a Plain React SPA (No Next.js)
Not every React app can migrate to Next.js on demand. If you’re maintaining a Vite or Create React App SPA, you have two realistic paths:
- react-helmet-async for managing per-route
<title>and meta tags client-side — better than nothing, but still subject to the same render-queue timing risk covered in our JavaScript SEO Guide, since it’s still injecting tags via JavaScript after the initial HTML loads. - A prerendering or static export step at build or deploy time, generating real HTML snapshots for your key routes so crawlers don’t depend on client-side execution at all for the pages that actually need to rank.
Neither fully matches what Next.js gives you by default — treat them as harm-reduction for an existing app, not a long-term substitute if SEO is a real priority for the product.
7. Common React SEO Mistakes
- Marking a high-level layout component
"use client". The directive cascades to everything rendered beneath it in the tree — putting it too high accidentally converts far more of your app to client-rendered than intended. - Leftover
next/headcalls after migrating to the App Router. It’s a Pages Router API; in App Router files it silently does nothing useful, and pages end up with no real metadata at all. - Static, identical metadata across dynamic routes. Copy-pasting one
generateMetadatareturn value without actually using the route’s params produces duplicate titles and descriptions across an entire dynamic section. - Injecting JSON-LD from a Client Component. It can work, but it inherits the same rendering-delay risk as any other client-injected content — prefer generating structured data in a Server Component wherever the data is available there.
8. Core Web Vitals for React Apps
Two React-specific levers matter most: keep the client-side JavaScript bundle small by defaulting to Server Components and using dynamic imports for anything genuinely heavy, and use next/image (or an equivalent optimized image component) rather than raw <img> tags, since automatic sizing and lazy-loading meaningfully affects both LCP and layout stability. Remember that INP replaced FID as the responsiveness metric — a component tree that hydrates late or handles clicks with a heavy synchronous handler will show up there specifically. The full Core Web Vitals fix list is in our Mobile SEO guide.
Frequently Asked Questions
Is Next.js required for React SEO, or can I stay on plain React?
It’s not strictly required, but it removes the single biggest risk factor by default — fully client-rendered content. A plain SPA can be made to work with prerendering or react-helmet-async, but it takes deliberate extra effort Next.js gives you for free.
Do Client Components hurt SEO?
Not by existing — they’re still pre-rendered to HTML on the server for the initial request. They hurt SEO when the content itself is fetched or generated only after hydration, inside a hook like useEffect.
Should I use the Pages Router or App Router in 2026?
For new projects, the App Router — it’s where the Metadata API, Server Components, and current file conventions live. The Pages Router still works but is increasingly the legacy path.
How is this different from a general JavaScript SEO guide?
A general guide explains how Google’s rendering pipeline works for any JS framework. This one is the implementation layer specifically for React and Next.js — the actual code patterns, APIs, and file conventions you’ll use to work with that pipeline rather than against it.
Not sure if your React app is shipping the HTML you think it is?
Navoto audits Server/Client Component boundaries, metadata implementation, and rendering output as part of our technical SEO audits.
