Next.js Launch Checklist: 33 Essential Steps

Execute `next build` and resolve every warning. TypeScript errors, missing dependencies, and deprecated API usage all surface here. A clean build log means fewer surprises in production.

Verify all required env vars are set in your hosting platform. Use `NEXT_PUBLIC_` prefix only for client-safe values. Never expose API keys, database URLs, or secrets to the browser bundle.

Choose between `standalone` (for Docker/self-hosted), default (Vercel), or `export` (static). The wrong output mode causes deployment failures or missing server-side features.

Set `reactStrictMode: true` in next.config.js. Strict mode catches unsafe lifecycles, legacy API usage, and side-effect issues during development that would cause bugs in production.

Search for `console.log`, `console.warn`, `debugger` statements and remove them. Use a proper logging library like Pino for server-side logs that you actually want in production.

Set `strict: true` in tsconfig.json. This enables strictNullChecks, noImplicitAny, and other flags that catch runtime errors at compile time. Fixing these before launch prevents null reference crashes.

Replace all `<img>` tags with the `next/image` component. Configure `sizes` prop for responsive images, set `priority` on above-the-fold images, and use WebP/AVIF formats via the built-in image optimizer.

Use `next/dynamic` with `{ ssr: false }` for client-only components like charts, maps, or rich text editors. This reduces initial bundle size and improves Time to Interactive.

Install and run `@next/bundle-analyzer` to visualize your JavaScript bundles. Look for unexpectedly large dependencies, duplicate packages, and code that should be lazy-loaded.

Use `next/font/google` or `next/font/local` to self-host fonts with automatic subsetting. This eliminates render-blocking font requests to Google Fonts and prevents layout shift from font swaps.

Use `revalidate` in fetch options or `revalidatePath`/`revalidateTag` for content that changes periodically. This gives you static-site speed with dynamic content freshness.

Achieve green scores for LCP (<2.5s), FID (<100ms), and CLS (<0.1). Use Chrome DevTools Lighthouse panel or PageSpeed Insights. Focus on the largest contentful paint element first — it has the biggest impact.

Use the Next.js Metadata API in each layout.tsx and page.tsx. Include unique title, description, and Open Graph tags per route. Dynamic routes should use `generateMetadata` to create page-specific metadata.

Add a `sitemap.ts` file in your app directory that exports a default function returning all routes. Include lastModified dates and priority values. Submit the sitemap to Google Search Console after launch.

Create a `robots.ts` file or static `robots.txt` in your app directory. Allow crawling of public pages, disallow admin routes and API endpoints, and reference your sitemap URL.

Set `alternates.canonical` in your metadata to prevent duplicate content issues. This is especially important if your site is accessible via www and non-www, or via HTTP and HTTPS.

Add Organization, WebSite, and page-specific schemas (Article, Product, FAQ) as JSON-LD script tags. Use Google's Rich Results Test to validate. Structured data improves click-through rates from search results.

Add headers for X-Content-Type-Options (nosniff), X-Frame-Options (DENY), Referrer-Policy (strict-origin-when-cross-origin), and Permissions-Policy. Use securityheaders.com to verify your score after deployment.

Define a strict CSP that whitelists only trusted script and style sources. Start with report-only mode to catch violations, then enforce. Use nonces for inline scripts via Next.js middleware.

Use Zod or Yup schemas in Server Actions and API routes. Never trust client-side validation alone. Sanitize HTML inputs with DOMPurify to prevent XSS attacks.

Use a library like `rate-limiter-flexible` or Upstash Redis to limit requests per IP on sensitive endpoints like login, contact forms, and API routes. This prevents brute force and DDoS attacks.

Enable HTTP Strict Transport Security header with a max-age of at least one year. Most hosting platforms handle SSL, but verify the HSTS header is present so browsers never downgrade to HTTP.

Configure GitHub Actions or similar to run lint, type-check, and tests on every PR. Block merges to main if any check fails. This catches regressions before they reach production.

Install `@sentry/nextjs` and configure both client and server error tracking. Set up source maps upload in your build step. Create alert rules for new errors and error spikes.

Implement Vercel Analytics, Google Analytics 4, or Plausible. Use the Next.js Script component with `strategy='afterInteractive'` for third-party analytics to avoid blocking page load.

Create `not-found.tsx` and `error.tsx` files in your app directory. These should match your site's design, provide helpful navigation, and include a way for users to report issues.

Use a service like UptimeRobot, Better Stack, or Checkly to monitor your production URL. Configure alerts via Slack, email, or SMS so you know within minutes if your site goes down.

Verify you can roll back to a previous deployment quickly. On Vercel, test the instant rollback feature. For self-hosted, ensure your Docker images or build artifacts are versioned and retrievable.

Submit every form, click every button, test every dropdown. Verify emails are sent, data is saved, and success/error states display correctly. Test on mobile devices, not just desktop.

Test at 320px, 375px, 768px, 1024px, 1280px, and 1536px widths. Check for horizontal overflow, overlapping text, and broken layouts. Use Chrome DevTools device toolbar for quick testing.

Check that your favicon displays correctly in browser tabs, and Open Graph images render properly when sharing on Twitter, LinkedIn, and messaging apps. Use tools like opengraph.xyz or the Twitter Card Validator to preview before launch.

Run a link checker like `broken-link-checker` or Screaming Frog against your staging environment. Dead links hurt SEO and frustrate users. Pay special attention to links in footer navigation, blog posts, and documentation pages.

Use Chrome DevTools Network throttling to simulate slow 3G and fast 3G connections. Verify that the page remains usable, loading states appear promptly, and critical content is visible within 3 seconds even on slow connections.