A Technical SEO Checklist Before Launching a Next.js Website

By Furkan Esen | Web Development & Technical SEO

You've finished building your Next.js website. The layout works, the animations look good, and the production build completes without errors.

Does that mean it's ready to launch?

Not necessarily.

A website can work perfectly in the browser while still having technical problems that make its content difficult for search engines to discover, render, or index.

I've always found it more useful to treat SEO as part of the development and release process rather than something to handle after deployment.

This checklist focuses on seven areas worth reviewing before launching a Next.js website using the App Router:

1. Rendering and crawlable HTML
2. Page metadata and canonical URLs
3. Robots directives and indexing
4. XML sitemaps
5. Redirects and HTTP status codes
6. Internal links and URL structure
7. Post-deployment verification

The examples use TypeScript and Next.js App Router conventions.

1. Check What Search Engines Actually Receive

One of the first things I would inspect is the HTML response.

Next.js supports server-rendered and statically generated content, which can make important page information available without requiring a browser to execute additional client-side JavaScript.

However, using Next.js doesn't automatically guarantee that every important piece of content is present in the initial HTML.

Imagine a product page where the main description is fetched only after the browser loads.

The user may eventually see everything correctly, but the initial response might contain very little meaningful content.

Google can render JavaScript, but relying on client-side rendering for all important content creates unnecessary dependencies.

For public, search-oriented pages, inspect whether essential headings, descriptions, links, and other relevant information are available in the server-rendered output.

You can begin with:

curl -L https://example.com/products/widget

Then inspect the returned HTML.

This is a useful initial check, although it isn't a complete rendering test.

For pages where the content changes based on a route parameter, consider using Server Components to fetch public content on the server.

// app/products/[slug]/page.tsx

export default async function ProductPage({
  params,
}: {
  params: Promise<{ slug: string }>
}) {
  const { slug } = await params

  const product = await getProduct(slug)

  if (!product) {
    notFound()
  }

  return (
    <main>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
    </main>
  )
}

This is a simplified illustration. In a real application, getProduct and notFound need to be imported or implemented appropriately.

The important principle is to make essential public information available without unnecessary client-side dependencies.

2. Verify Metadata and Canonical URLs

Next.js provides a Metadata API for titles, descriptions, canonical URLs, Open Graph information, and other page-level metadata.

For static routes, you can export a metadata object.

// app/about/page.tsx

import type { Metadata } from 'next'

export const metadata: Metadata = {
  title: 'About Example Company',
  description:
    'Learn about our team and what we build.',
  alternates: {
    canonical: 'https://example.com/about',
  },
}

For dynamic pages, use generateMetadata.

Before launch, verify that:

• Every important page has an appropriate title and description.
• Dynamic pages generate metadata for the correct content.
• Canonical URLs use the intended production domain.
• Canonical URLs don't accidentally reference staging.
• Duplicate or alternate URLs are handled consistently.

Canonical tags are especially important when the same or substantially similar content is accessible through multiple URLs.

For example:

example.com/products/widget

and

example.com/products/widget?ref=campaign

may display the same product information.

In that situation, a canonical URL can help indicate the preferred version.

A canonical is a signal, not an instruction guaranteeing which URL Google will select.

Also, avoid treating canonical tags as substitutes for proper redirects or URL management.

Reference: Next.js Metadata API

3. Review Robots Directives Before Production

It's common to prevent staging environments from appearing in search engines.

The problem occurs when those restrictions accidentally reach production.

Check for unexpected noindex directives in page metadata, HTML, and HTTP response headers.

For example:

<meta name="robots" content="noindex">

This tells compatible crawlers not to index the page.

Next.js also supports generating robots.txt through its file conventions.

// app/robots.ts

import type { MetadataRoute } from 'next'

export default function robots(): MetadataRoute.Robots {
  return {
    rules: {
      userAgent: '*',
      allow: '/',
      disallow: '/admin/',
    },
    sitemap: 'https://example.com/sitemap.xml',
  }
}

This is only an example. Your own rules should reflect which routes are public and which should remain excluded from crawling.

Remember that robots.txt and noindex serve different purposes.

A robots.txt disallow directive restricts crawling. It doesn't reliably prevent a URL from appearing in search results if that URL is discovered elsewhere.

A noindex directive requests that an accessible page not be indexed.

For private information, neither mechanism replaces authentication or access controls.

One practical deployment check is to inspect both the public robots.txt file and representative pages after the production deployment.

Don't assume that development, preview, and production environments share identical indexing settings.

4. Generate a Sitemap That Reflects Real URLs

An XML sitemap helps search engines discover important URLs.

Next.js makes this relatively straightforward using app/sitemap.ts.

// app/sitemap.ts

import type { MetadataRoute } from 'next'

const baseUrl = 'https://example.com'

export default function sitemap(): MetadataRoute.Sitemap {
  return [
    {
      url: baseUrl,
      lastModified: '2026-11-01',
    },
    {
      url: `${baseUrl}/about`,
      lastModified: '2026-11-01',
    },
    {
      url: `${baseUrl}/services`,
      lastModified: '2026-11-01',
    },
  ]
}

The dates here are illustrative. Production values should reflect meaningful content updates.

For a dynamic website, generate entries from your actual published content.

For example, a blog sitemap might include every public article with its canonical URL and last meaningful modification date.

Before launch, verify that:

• The sitemap is accessible.
• URLs use the production domain.
• Entries represent public, intended canonical pages.
• Deleted or redirected URLs are not unnecessarily included.
• The dates reflect actual updates rather than being automatically changed on every build.

A sitemap is not an indexing guarantee. Submitting a URL doesn't mean Google will necessarily index it.

However, a clean sitemap makes discovery and troubleshooting easier.

Reference: Next.js Sitemap Documentation

5. Check Redirects and HTTP Status Codes

Website redesigns frequently introduce URL changes.

Maybe /old-services becomes /services, or an old product route is replaced with a new structure.

If existing URLs already have external links, search visibility, or returning users, those changes deserve careful handling.

Next.js supports redirects through its configuration and routing APIs.

For example:

// next.config.ts

import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  async redirects() {
    return [
      {
        source: '/old-services',
        destination: '/services',
        permanent: true,
      },
    ]
  },
}

export default nextConfig

This creates a permanent redirect using the framework's redirect configuration.

Use temporary redirects when the move is genuinely temporary.

Also check pages that no longer exist.

A deleted page should not return a successful 200 response with a generic "not found" message.

For App Router pages, Next.js provides notFound() for handling missing resources.

Before production release, test representative URLs and confirm their actual HTTP responses.

curl -I https://example.com/old-services
curl -I https://example.com/missing-page

Watch for redirect chains, unexpected status codes, and outdated destinations.

One particularly useful exercise is to export the old site's important URLs before a migration and compare them against the new route structure.

Reference: Next.js Redirecting Guide

6. Check Internal Links and URL Structure

A technically accessible page isn't necessarily easy to discover.

Internal linking helps users and search engines understand how pages relate to one another.

Next.js provides the Link component for navigation between application routes.

import Link from 'next/link'

export default function Resources() {
  return (
    <nav aria-label="Resources">
      <Link href="/guides/technical-seo">
        Technical SEO checklist
      </Link>
    </nav>
  )
}

For important navigation, use actual links with descriptive anchor text.

Avoid building critical navigation exclusively around interactions that search engines or users cannot easily follow.

Also review your information architecture.

A service page, supporting guide, and related technical article should have a logical relationship. Links should help readers find the next useful resource rather than exist simply to satisfy a numerical SEO target.

During a website development process, decisions about routing, navigation, rendering, and content structure are easier to address before launch than after hundreds of pages have been published.

Keep URL paths readable and consistent, and avoid changing existing URLs without a clear reason.

7. Verify Everything After Deployment

A successful production build tells you that the application was built successfully.

It doesn't guarantee that search engines can discover and index all intended content.

After deploying, run a short verification process.

Check the public response.

Open important URLs and inspect their status codes, HTML, title tags, canonical tags, and indexability directives.

Check the sitemap and robots.txt.

Make sure both are available at their expected production URLs.

Test navigation.

Follow internal links, examine important conversion paths, and look for broken destinations.

Inspect representative pages using Google Search Console.

Use URL Inspection to review how Google sees important pages. For newly launched sites, keep in mind that crawling and indexing take time.

Review mobile experience.

Use real devices where possible, and check performance metrics such as Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS).

Separate indexing from ranking.

This last distinction is easy to overlook.

A page being indexed doesn't mean it will rank well for the queries you care about.

Once a page is indexed, its search performance also depends on whether it addresses the right intent, communicates a useful answer, and fits into a coherent content structure.

For teams investigating this distinction, this guide to diagnosing indexed pages that aren't ranking covers additional content and search-intent checks.

Technical SEO is an important foundation, but it cannot replace useful content.

Final Pre-Launch Checklist

Before shipping, I would want to answer "yes" to these questions:

• [ ] Is important public content available in the rendered HTML?
• [ ] Do relevant pages have unique and appropriate metadata?
• [ ] Do canonical URLs point to the correct production URLs?
• [ ] Are important pages free from accidental noindex directives?
• [ ] Does robots.txt match the intended crawling policy?
• [ ] Does the sitemap include the correct public URLs?
• [ ] Do old URLs redirect appropriately?
• [ ] Do missing pages return suitable HTTP statuses?
• [ ] Can users and crawlers follow important internal links?
• [ ] Have key pages been checked on mobile devices?
• [ ] Have production URLs been inspected after deployment?

Closing Thoughts

Technical SEO is easier to manage when it becomes part of the development workflow.

You don't need to wait until a website loses visibility before checking rendering, metadata, redirects, or crawlability.

The objective is not to add every possible SEO feature to a Next.js application.

It's to make sure the architecture supports the pages that actually matter to users and the business.

Start with the fundamentals, verify the production output, and distinguish technical accessibility from actual search performance.

A clean deployment is a good start. A verified, accessible, and understandable website is a better one.

---

Author

Furkan Esen is the co-founder of Avexra Digital. His work focuses on web development, technical SEO, and digital experiences that connect technical implementation with business goals.

AI Assistance Disclosure

AI assistance was used in structuring and editing this article, as well as preparing illustrative code examples. The technical guidance is based on the referenced documentation. The author should review and validate the implementation details before publication.