All resources
Note #011

Before you launch: a production checklist for Next.js sites

The development server hides a whole class of problems. What to check on the real production build and the real domain before the first visitor arrives — with commands to check it.

By Tenovates4 min read

Written 2026-09 · Next.js 16

The problem

A site can work perfectly on a laptop and still launch broken: pages that tell search engines the real address is somewhere else, a secret file shipped inside the server image, an error page in the wrong language, backups nobody has ever restored. None of it shows up in development, because development is forgiving and production is not.

This checklist is what to verify on the real production build, at the real address, before the first visitor arrives.

Why development hides it

The development server runs your code differently: it rebuilds on every change, reads environment files directly, serves files from disk as they appear, and ignores many caching and security settings. A production build freezes some values at build time, serves only what existed when it was built, and applies every header you configured. Problems live in that gap.

The checklist

1. Address and search engines

  • The site's public URL is set before the build — values meant for the browser are baked into the bundle when it's built.
  • metadataBase is set in the root layout, so relative canonical and sharing-image URLs resolve against the real domain.
  • Canonical tags on real pages point to the real domain, not localhost, not a staging address.
  • robots allows indexing in production — and staging or demo sites still say noindex.
  • The sitemap lists real pages only, on the real domain.

2. Secrets and what ships

  • Environment files are excluded from the build context (.dockerignore or equivalent) — otherwise they end up inside the image.
  • No secret is used in client code (anything the browser receives is public).
  • Error pages and logs don't expose stack traces or request bodies.

3. Headers and security basics

  • HTTPS everywhere, with Strict-Transport-Security.
  • A Content Security Policy — and a check, in a real browser, that the pages still hydrate and the console shows no violation.
  • X-Frame-Options (or frame-ancestors), X-Content-Type-Options, a referrer policy.
  • Forms that send email or create records are rate-limited.
  • Redirect parameters are validated by origin, not by prefix.

4. Pages when things go wrong

  • A branded 404 page, in the site's language, with a real 404 status.
  • A branded error page for server errors.
  • Loading states on slow, dynamic pages.

5. Files uploaded after launch

  • An image uploaded from the admin after the deployment is actually served. Depending on how the app serves static files, files added after the build may not be — test it on the live site.

6. Backups and recovery

  • Automatic backups of the database and uploaded files.
  • A copy stored away from the production server.
  • One restore actually tested. A backup that has never been restored is a hope, not a backup.

7. Knowing when it breaks

  • A health endpoint that checks the database and reports the deployed version.
  • Something outside the server watching it, and alerting a person.
  • Error tracking, or at least logs you know how to read.

8. Email and forms

  • Transactional email (confirmations, password reset) actually arrives — check the spam folder, and the sender domain's SPF and DKIM records.
  • Every form submitted once on the live site, end to end.

Commands to check

A few of these checks take one command each. Replace the domain with yours:

# 1. Which canonical does the home page declare?
curl -sL https://www.example.com/ | grep -o '<link rel="canonical"[^>]*>'

# 2. Which security headers are set?
curl -sIL https://www.example.com/ | grep -i -E 'strict-transport|content-security|x-frame|x-content-type'

# 3. Does a missing page return a real 404?
curl -sL -o /dev/null -w '%{http_code}\n' https://www.example.com/this-page-does-not-exist

-L matters: if your home page redirects (to a language, to www), without it you'd read the redirect instead of the page — and wrongly conclude there is no canonical. With it, an empty result is itself an answer: no canonical, or no security headers.

The take-away

Test the production build at the production address, not the development server. Most launch-day problems are invisible until then — and a checklist catches them in an hour instead of in front of your first customers.

Checklist

Before launch — production build, real domain
1. Public URL set before build · metadataBase · canonicals · robots · sitemap
2. Env files excluded from the image · no secrets client-side · no stack traces
3. HTTPS + HSTS · CSP checked in a browser · frame / nosniff / referrer headers
4. Branded 404 (real status) and error pages · loading states
5. A file uploaded after the deploy is served
6. Backups : database + files · off-site copy · one restore tested
7. Health endpoint · external monitoring with alerts · error tracking
8. Emails arrive (SPF / DKIM) · every form submitted once, live