Doesn't Next.js handle SEO out of the box?

Only when the page is a Server Component or uses getServerSideProps / getStaticProps in Pages Router. Plenty of Next.js apps in production use 'use client' at the page level, fetch data with SWR or react-query in the browser, and ship a near-empty initial HTML. Next.js gives you the tools, but it doesn't enforce them - and a real codebase with deadlines often ends up with mostly client-rendered routes.

What about the App Router Metadata API?

The Metadata API works perfectly when it runs in a Server Component. The trap is that any 'use client' boundary upstream forces metadata into client-only territory, where it loses access to runtime params and gets emitted after hydration. If your title is dynamic and depends on a fetched value, and that fetch happens in a Client Component, the title is invisible to most crawlers.

Will switching to Server Components fix it?

Mostly yes - if you can. React Server Components emit their HTML on the server before the response goes out. The catch is that any component that uses state, effects, browser APIs, or third-party UI libraries that haven't adopted the pattern needs to live behind a 'use client' boundary. For mature codebases that means weeks or months of refactor. PageGlass works on whatever shape your routes have today.

Does ISR or SSG help with this?

Incremental Static Regeneration and Static Site Generation only help if the data the crawler needs is in the static build. They don't help with personalised dashboards, search-result pages, or any route that hydrates with client-fetched data after first paint. For those, you still ship an empty shell to the crawler unless you also prerender on the request.

What about next/head and SSR meta tags?

next/head works at request time when used in a Pages Router page that runs server-side. The failure mode is using next/head inside a 'use client' component, where it's deferred until after hydration. If you're seeing missing tags on Page Speed Insights or in Search Console, that's almost always the cause.

Will Vercel's edge runtime change anything?

Edge runtime affects where your code runs (closer to the user) but not when. A route running on the edge that still client-renders its content has the same crawler-visibility problem as one running on Node. The fix is moving rendering to the server side of the boundary, regardless of which runtime hosts it.

Next.js SEO: keep your routes indexed even when you ship Client Components

Next.js can serve fully-rendered HTML, but the moment a route is marked 'use client' or fetches data with useEffect, Googlebot reads an empty shell. Hydration takes seconds; crawlers don't wait.

This is a known problem, and the fix is simpler than you think.

100+ bots supportedPre-rendered by PageGlassFive-minute setupBuilt on Cloudflare's edge

Paste your Next.js site's URL above to see what Googlebot sees on the first request, before hydration.

Don't want an external tool? We understand.

If you're prepared to refactor every interactive route into a Server Component, move data fetching into loaders, and rebuild any state machines that assume the browser exists, that's the right long-term answer. PageGlass is the five-minute bridge for the routes you don't have time to rewrite.

Fix this in three steps

Run a free Next.js scan. Confirm the bot visibility gap caused by Next.js client component rendering - the scan takes ten seconds and needs no signup. You get exactly what Googlebot, Bingbot, and the AI crawlers see when they hit your URLs today, side by side with what your users see.
Add one CNAME record. Point your Next.js site's domain through PageGlass in your DNS provider. The change takes thirty seconds and is fully reversible. Zero code changes, no deploy, no impact on the bundle your real users download.
Next.js content is now indexable. Bot traffic now receives fully-rendered HTML for every URL on your Next.js site, while human visitors keep getting the exact same dynamic experience as before. Come back to PageGlass and run the scan again to confirm the fix.

Where Next.js SEO actually breaks

Next.js gets credit for being SEO-friendly, and it deserves it - but only for the parts of your application that are Server Components or use the Pages Router data-fetching APIs. The moment you mark a page or layout with 'use client', every component below that boundary renders in the browser. Googlebot still receives HTML, but it's the App Router's streaming shell, not your content.

The most common pattern that breaks is dashboards or detail pages that load data with useEffect + fetch or with useSWR. These run after the React tree mounts, which means the crawler sees the loading skeleton, not the data.

Common Next.js fixes that don't actually work

Setting metadata via useEffect. The effect runs after hydration. Crawlers reading the initial HTML never see the title or description you set this way.
next/head inside a 'use client' component. Deferred until hydration. Same outcome as the useEffect pattern.
Server Component with a client-only child that owns the data. Looks server-rendered in the parent, but the heading, list, or table that crawlers care about is filled in only after the client child fetches and renders. The shell is server-rendered; the content isn't.
Trusting Search Console URL inspection. The inspection tool runs Google's full rendering service, which executes JavaScript. A page can pass URL inspection and still be invisible to the first-pass crawler that decides whether to render at all.

What actually works

Three paths: (1) refactor each affected route to a Server Component with server-side data fetching, which is the official answer but a real time cost; (2) move to generateStaticParams + ISR for routes with stable data, accepting that personalised routes still need another solution; or (3) use PageGlass to detect bot user-agents at the edge and serve a fully-rendered HTML version of every route - including Client Components - without touching your application code. The third option is what most teams actually choose when the rewrite isn't on this quarter's roadmap.