Audit what your Next.js site ships to search.

What does a Next.js SEO audit check?

Your audit checks what each sampled route on your site ships to a crawler: the HTML in your response, the tags in your head, your indexing signals and the weight of your scripts. Open view-source on your homepage and search for your main heading. Found it? Your server sent it. But if all you see is an empty div and a script bundle, a common sight, your content is waiting on JavaScript.

The assessment reads your response headers, markup, structured data, headings, script and image weight, and robots and canonical signals across your homepage and up to eight sampled pages. Those readings feed eight weighted pillars in your score, among them architecture at 15%, performance at 15%, search at 12% and schema at 10%. It never opens your repository. So each finding tells you what a crawler gets from your site, not which file caused it. Search never sees your code either, which makes this the view that counts for you.

Does the rendering mode change what Google receives?

Yes. Your rendering mode decides whether the first response holds your content or only a shell that Google must render later. Fetch one of your article URLs and check your HTML for your body text. With Static Rendering, you build that HTML ahead of time and cache it, while with Dynamic Rendering you build it per request. Either way, you send markup (and that is the point).

Your trouble starts when you rely on client-only fetching. Force a page into 'use client', or load your content inside useEffect, and Googlebot can see 'Loading…' instead of your copy. Next.js picks a strategy for each of your routes. Call one dynamic API such as cookies or headers, and you change that route's mode. So you may run a mixed site that you never decided on.

Google renders your JavaScript, but it queues your pages after the initial 200 response, so the wait can run past a few seconds. Its docs still tell you server-side or pre-rendering is a great idea. And not all bots run JavaScript, so you cannot count on them to run your scripts. The assessment checks what your response holds, route by route, so you see each route you ship.

How does the Metadata API decide your titles, canonicals and Open Graph tags?

Your head tags come from the metadata object or generateMetadata function you export in a layout.js or page.js file. Open the head of one deep page on your site and look for your title, your canonical link and your og:image. You are reading your exports. Whatever you find there is exactly what the assessment sees on your page.

Your generateMetadata function can fetch data and read your parent's metadata, so you can extend a shared Open Graph image rather than replace it. Set alternates.canonical and Next.js writes your canonical link; set openGraph.images and it writes your og:image. Your image URLs must be absolute, so you set metadataBase with new URL(...). Your title.template applies only to child segments. It skips the page in the segment where you define it, which surprises people. So if your titles look wrong, check where you set it.

Static metadata shows up as the same title on many routes, a missing canonical, or a relative og:image. The assessment lists these on your sampled pages, and you can match each gap to the export behind it. Then open your file for that route and check what you exported. Every gap leads back to an export you wrote (or forgot to).

Why do Next.js sites fail Core Web Vitals?

You fail Core Web Vitals on your Next.js site when your field data shows LCP over 2.5 seconds, INP over 200 milliseconds or CLS over 0.1. Vercel states that on pages where the LCP element was an image, 35% of those images had source URLs that weren't discoverable in the initial HTML. Check yours. Find your largest above-the-fold image URL in your initial HTML.

Script weight and hydration drive your INP, which replaced FID in March 2024. Vercel says that when you wrap your major page blocks in Suspense, they hydrate independently, which improves your INP. Your CLS has plainer causes: images you ship without dimensions, content you inject, and web fonts you load. Check your templates for all three.

The assessment reads script and image weight on your pages but gives you no field data. Google ranks your pages in search on field data over a 28-day window. A clean Lighthouse run does not settle it, and a good lab score can still hide a bad month. So run the Core Web Vitals test next and check your own field data.

Which App Router mistakes hide pages from search?

You hide pages from search when you render content only on the client, set noindex by mistake, block crawling where you wanted noindex, or leave duplicate URLs without canonicals. Open your robots.txt and check whether you block JavaScript or CSS paths. View your key page's head and look for a robots meta tag. One stray line there can undo everything you did (and it rarely announces itself).

In your App Router, you set page-level noindex with a metadata export: robots: { index: false, follow: false }. Keep that URL in your sitemap and you send mixed signals. Block it in your robots.txt as well, and Google may never fetch your page, so your noindex goes unseen. The two controls cancel each other out.

Confirm your staging environment is not indexed. The assessment reads your robots and canonical signals on your homepage and sampled pages, so your report shows any stray noindex, missing canonical or client-only shell. But it cannot see routes outside that sample. Check your other routes yourself.

How do you check a Next.js site from the outside in two minutes?

Run the free assessment on your URL and enter your work email. In about two minutes you get a score out of 100, with the evidence behind each of your pillars. Paste your homepage first. Then compare what your report says about rendering and head tags with view-source on one of your deep routes. Your email gets you the report link once. You can run three checks per hour per connection.

Read your band before your number. 80 to 100 is good standing, 60 to 79 constrained, 40 to 59 at risk, and 0 to 39 legacy condition. Then read your evidence for each pillar and note which findings name rendering, canonicals or script weight. Those point you at the fixes with the most reach on your site.

Your next checks sit outside this read. The assessment sees your public pages only, so it cannot confirm your field performance data or your source. Want timing? Run the Core Web Vitals test. Want to know how your pages read to AI systems? Run the AI SEO audit.

Questions, answered.

Your next read.

1. 01Astro SEO checkIslands, content collections, schema, vitals.
2. 02Headless CMS SEO auditRendering, canonicals, previews, schema from the template.
3. 03Core Web Vitals testLCP, INP and CLS from what the page ships.