The Next.js SEO Checklist I Use on Every Project

"We used Next.js, so SEO is handled" is the new "we have a Facebook page". Server rendering makes good SEO possible. It does not make it happen. This is the checklist I actually run on every project, including the site you are reading right now, with the reasoning behind each item so you can adapt it instead of copying it blindly.

1. Metadata that is per page, not per site

Every route gets its own generateMetadata: a unique title with a template, a description written for humans, and a canonical URL. Listing pages describe the collection. Detail pages are generated from the content itself.

The test is simple: if two pages could swap descriptions without anyone noticing, they are not descriptions, they are filler. Google increasingly rewrites weak descriptions anyway, so the ones you keep should earn their place.

export async function generateMetadata({ params }) {
  const post = await getPost((await params).slug);
  return {
    title: post.metaTitle || post.title,
    description: post.metaDescription || post.excerpt,
    alternates: { canonical: `/blog/${post.slug}` },
    openGraph: { type: "article", images: [post.coverImage] },
  };
}

One trap worth naming: canonicals that point at redirects. If your site serves from the apex domain, the canonical must be the apex, and www should permanently redirect. Mixed signals here quietly split your ranking equity in two.

2. Structured data on everything that has a shape

Search engines, and increasingly AI answer engines, consume schema.org data directly:

• Person or Organization site wide, with sameAs links to your profiles
• BlogPosting on articles, with dates and author
• BreadcrumbList on nested pages
• FAQPage where you genuinely answer questions
• CreativeWork or Product on portfolio and product pages

This is the difference between being indexed and being understood. When an answer engine can parse who you are, what you do and what each page covers, you become quotable. Quotable is the new rankable.

3. Dynamic sitemap and robots, generated from the database

A hardcoded sitemap is a lie waiting to happen. app/sitemap.ts should query your actual published content so every new post and project is discoverable the moment it goes live. robots.ts allows crawlers, blocks /admin and /api, and points to the sitemap.

Do not block AI crawlers unless you have a specific reason. GPTBot, ClaudeBot and PerplexityBot are distribution channels now. Being quoted by an answer engine in front of a potential client is worth more than most backlinks.

4. Instant indexing, not just discoverability

The sitemap tells engines what exists. IndexNow tells them the moment it exists. One POST request on publish announces the URL to Bing and Yandex, which feed ChatGPT search, Copilot and DuckDuckGo. Google ignores IndexNow, so for Google you pair the sitemap with Search Console's Request Indexing for important pages.

I wired this into my own admin: publishing a post fires the ping automatically. Set it up once and never think about it again.

5. OG images people actually click

Social shares live or die on the preview card. next/og generates branded images per page at the edge: title, your name, your colors. It is about 50 lines once, and every future post gets a professional card for free. Pair it with an RSS feed, which is still how developers subscribe, and syndication earns links on its own.

6. Core Web Vitals as a budget, not an afterthought

The parts that actually move the needle:

• next/image everywhere. Sizing, lazy loading and formats are solved problems, so let them be solved.
• next/font so text renders instantly without layout shift.
• Defer heavy client JavaScript. My 3D hero loads after the text paints, so the largest contentful paint is real content rather than a spinner.
• ISR with revalidate so pages are static fast but content fresh.

Test with Lighthouse on a throttled mobile profile, not on your dev machine. Your dev machine lies to you politely.

7. AEO: being the answer, not just the result

People increasingly ask ChatGPT, Claude and Perplexity instead of Google. Optimising for answer engines means:

• Clean semantic HTML: one h1, a real heading hierarchy, lists that are lists.
• Direct answers near the top of each page, then depth below.
• FAQ sections with genuinely useful, self contained answers.
• An llms.txt file: a plain text summary of who you are and what each page covers, served at the root for LLM crawlers.

None of this is exotic. It is the same discipline as classic SEO applied to a new reader that happens to be a machine quoting you to a human.

8. Close the loop with real data

Submit the sitemap in Google Search Console and Bing Webmaster Tools. Then, monthly, open the Performance report and look for one specific pattern: queries where you get impressions but few clicks. Those are pages that almost work. Sharpen their titles and descriptions and watch the click through rate move. This single loop outperforms most "advanced" SEO tactics because it is driven by your actual data instead of someone's guesswork.

What I skip on purpose

Keyword density tools, automated "SEO scores", and mass directory submissions. They optimise for dashboards, not for readers. Fifteen years of Google updates have all pointed the same direction: pages that genuinely answer a question, served fast, marked up clearly. That is the whole game.

SEO is not a plugin. It is about two days of engineering discipline that compounds for years.

Want this checklist applied to your product? Get in touch.