SEO

Technical SEO Checklist for Next.js and Static-Export Sites

Most Next.js SEO problems are small configuration mistakes with large consequences. This checklist covers the ones we find most often.

By Prolificrew Engineering · · 4 min read

In this article
  1. 1. Give every page its own canonical URL
  2. 2. Remember that nested metadata objects are replaced, not merged
  3. 3. Use a real, static Open Graph image
  4. 4. Make the sitemap agree with your URLs
  5. 5. Keep robots.txt simple
  6. 6. Add structured data that matches the page
  7. 7. Write titles, descriptions and headings for people and queries
  8. 8. Fix internal linking and dead ends
  9. 9. Performance and mobile experience
  10. 10. Hosting, redirects and headers
  11. 11. Measure and iterate

Next.js makes it easy to build fast, crawlable pages, but it does not stop you from shipping the mistakes that quietly cost rankings: wrong canonical tags, missing social images, a sitemap that disagrees with your URLs. This checklist is what we run through on every audit. Examples use the App Router and apply equally to sites built with output: "export".

1. Give every page its own canonical URL

The canonical tag tells Google which URL is the master version of a page. The most damaging mistake we see is setting a canonical once in the root layout. Every page that does not override it then declares the home page as its canonical, and Google may treat those pages as duplicates and drop them from the index.

Set the canonical per page, in generateMetadata or the page’s metadata export:

export const metadata = {
  title: "Web Application Development",
  description: "Custom web applications built with Next.js and React.",
  alternates: { canonical: "https://example.com/services/web-applications/" },
};

2. Remember that nested metadata objects are replaced, not merged

If a child page sets openGraph, the whole openGraph object from the parent layout is replaced, including images and site name. The same is true of alternates and twitter. A page can then silently lose its social preview image. The fix is a small helper that builds the full metadata object for every page, so nothing is forgotten:

export function buildMetadata({ title, description, path, image = "/og-image.png" }) {
  const url = "https://example.com" + path;
  return {
    title,
    description,
    alternates: { canonical: url },
    openGraph: { type: "website", url, title, description, images: [{ url: image, width: 1200, height: 630 }] },
    twitter: { card: "summary_large_image", title, description, images: [image] },
  };
}

3. Use a real, static Open Graph image

Social platforms need an image URL that actually returns an image. Dynamic image routes (such as /api/og) do not exist in a static export, so a metadata entry pointing to one produces a broken preview. Create a 1200 by 630 pixel PNG or JPEG in public/, reference it from every page, and test it with the sharing debuggers from LinkedIn and Facebook.

4. Make the sitemap agree with your URLs

  • Match your trailing-slash setting. If trailingSlash: true, list URLs with the trailing slash, otherwise every sitemap entry triggers a redirect.
  • Generate the list from your data (services, blog posts) rather than typing it twice.
  • Use real lastModified dates. Stamping every URL with the build time teaches Google to ignore the field.
  • Skip changeFrequency and priority; Google does not use them.
  • Submit the sitemap in Search Console and check the indexed page count against it.

5. Keep robots.txt simple

Allow everything you want indexed, disallow only paths that exist and should not be crawled, and reference the sitemap. Remember that blocking a URL in robots.txt stops crawling but does not guarantee it stays out of the index; use noindex for that.

6. Add structured data that matches the page

  • Organization and WebSite sitewide, with logo, contact details and social profile links in sameAs.
  • BreadcrumbList on inner pages.
  • Article or BlogPosting on posts, with headline, dates and publisher.
  • FAQPage only where the questions and answers are visible on the page.
  • Service, SoftwareApplication or Product where they describe what the page really offers.

Render it as JSON-LD in a script tag, escape the < character in the JSON, and validate with Google’s Rich Results Test. Never mark up content that users cannot see.

7. Write titles, descriptions and headings for people and queries

  • One h1 per page that says what the page is about in the words people search for.
  • Titles around 50 to 60 characters, with the important words first. Avoid repeating the brand twice.
  • Descriptions of roughly 120 to 155 characters that promise a specific benefit.
  • A logical heading hierarchy (h2 under h1, h3 under h2) rather than choosing tags for their size.

8. Fix internal linking and dead ends

  • Every link in the header, footer and body must resolve. Crawl the site and fix any 404.
  • Link from home and category pages to every important page, using descriptive anchor text instead of “click here”.
  • Build hub pages (such as a services index and a blog index) so related pages link to each other.
  • Add a custom 404 page that links to your main sections.

9. Performance and mobile experience

Core Web Vitals are a ranking signal, and mobile usability matters because Google indexes the mobile version of your pages. Follow our Core Web Vitals checklist, keep text readable without zooming and make tap targets large enough.

10. Hosting, redirects and headers

  • Force HTTPS and choose one canonical host (with or without www). Redirect the other permanently.
  • Serve compressed responses and long cache lifetimes for fingerprinted assets.
  • Return a real 404 status for missing pages, not a 200 with an error message.
  • Add security headers such as X-Content-Type-Options and a sensible Referrer-Policy.

11. Measure and iterate

Verify the site in Google Search Console, submit the sitemap, and watch the Pages report for “Duplicate, Google chose different canonical” and “Crawled, currently not indexed” entries. Those messages point directly at the issues in this checklist. Expect changes to canonicals and content to take weeks, not days, to be reflected in search results.

Want a second pair of eyes? Our technical audit reviews all of the above, plus performance and code health, and ends with a prioritised fix list.