The Next.js Launch Checklist After Converting a Framer or Webflow Site

A converted site can look perfect in a preview and still fail at launch. Production adds a real hostname, caching, analytics, form delivery, redirects, crawler rules, environment variables, and users who do things your happy-path test never covered.

Use this checklist after the visual conversion and before changing DNS. It is organized by failure impact so the team can stop a launch when a critical dependency is not ready.

1. Freeze the release candidate

Choose one commit as the release candidate. Record:

• commit SHA;
• build command;
• Node.js version;
• package-manager version and lockfile;
• required environment variable names;
• deployment target;
• database or CMS migration state;
• reviewer and approval time.

Do not keep editing the same deployment while QA is running. Every change creates a new candidate and invalidates some prior test results.

2. Prove a clean build

Build from a clean checkout with the lockfile honored. A developer's machine may have cached packages or generated files that hide a missing dependency.

Typical checks include:

npm ci
npx tsc --noEmit
npm run build

Use the commands required by your repository. The important property is reproducibility: another machine or CI runner can produce the deployment from the committed files and documented environment.

Review build warnings. A successful exit code does not make missing metadata, oversized client bundles, or unsupported APIs harmless.

3. Verify every route class

Create representative groups rather than testing only the homepage:

• homepage;
• static marketing page;
• dynamic CMS detail page;
• CMS listing and pagination;
• conversion or signup page;
• legal page;
• redirect source;
• not-found page;
• authenticated page, if present.

For each group, test desktop and mobile, direct navigation, client navigation, refresh, and a copied deep link in a private window.

If routes are generated from data, test a normal record, the longest title, missing optional media, special characters in the slug, and a nonexistent record.

4. Audit assets and fonts

Check the network panel for failed images, fonts, scripts, and media. Verify:

• assets do not reference a temporary host;
• image dimensions prevent layout shifts;
• large images are appropriately sized and compressed;
• SVGs render in light and dark contexts;
• videos have poster images and do not unexpectedly autoplay with sound;
• all required font weights load;
• fallback fonts do not break layout;
• asset licenses permit production use.

Test with cache disabled once, then with a warm cache. Both paths matter.

5. Finish metadata and social previews

Next.js supports route metadata and special files for icons, sitemaps, robots directives, and social images. The current metadata documentation explains the App Router conventions.

For every public page type, verify the rendered HTML contains:

• a unique, descriptive title;
• a useful meta description;
• the intended canonical URL;
• correct index/follow behavior;
• Open Graph and Twitter card fields;
• an absolute, publicly reachable social image;
• appropriate language information.

Paste a production URL into a social debugger or messaging draft. A working image in the browser does not guarantee the crawler can fetch it.

6. Generate robots and sitemap from real routes

The sitemap should contain canonical, indexable production URLs—not previews, redirects, or deleted drafts. Use absolute URLs. Next.js can generate a sitemap through its sitemap file convention.

Check:

https://your-domain.com/robots.txt
https://your-domain.com/sitemap.xml

Confirm the production hostname and protocol inside the sitemap. Review robots.txt for broad disallow rules copied from staging. Submit the sitemap in the relevant webmaster tools after launch.

7. Validate redirects and old URLs

A migration must preserve historical entry points. Build a redirect map before launch and test it automatically.

For each old URL:

• the first response is the intended permanent status;
• Location points directly to the final page;
• the final page returns 200;
• there is no loop or multi-hop chain;
• the canonical matches the final URL.

Google's site migration guidance recommends permanent server-side redirects, updated internal links, and updated sitemaps.

8. Test forms end to end

Every form needs more than visual validation. In the production-like environment, test:

• required and optional fields;
• malformed email or phone values;
• server-side validation;
• duplicate submissions;
• loading state;
• success and error messages;
• keyboard submission;
• spam controls;
• notification delivery;
• CRM or database arrival;
• consent capture;
• redaction of sensitive values from logs.

Use clearly synthetic data and delete it afterward. Confirm who receives failure alerts.

9. Verify analytics as events, not page views alone

Open a fresh private session with debugging enabled. Confirm:

• one page view per navigation;
• no duplicate script installation;
• campaign parameters survive the landing flow as intended;
• conversion events fire once;
• event names and properties match the analytics specification;
• consent choices affect tracking correctly;
• internal/admin traffic can be filtered;
• the production property receives the data.

Compare important events with backend truth after launch. A form-success event without a stored submission can conceal a broken integration.

10. Test accessibility manually

Run automated checks, then cover what tools cannot decide:

• navigate every interactive element with a keyboard;
• verify visible focus;
• open and close menus and dialogs without a mouse;
• confirm focus returns to a sensible place;
• listen to headings and control names with a screen reader;
• zoom to 200 percent;
• test reduced motion;
• check error messages are announced and associated with fields;
• ensure color is not the only signal.

Converted markup often preserves visual order while creating a confusing focus or heading order. Test the experience, not just rule counts.

11. Measure representative performance

Test more than the homepage. Choose the heaviest marketing page, a CMS page, and the primary conversion route.

Inspect:

• server response time;
• largest above-the-fold asset;
• layout shifts caused by fonts or media;
• long client-side tasks;
• third-party scripts;
• unused JavaScript and CSS;
• cache headers;
• image delivery;
• behavior on a slower mobile profile.

Lab tests help reproduce issues. Real-user monitoring shows what visitors experience across devices and networks. Keep the two separate when reporting results.

12. Review security and privacy

At minimum:

• no secret is shipped in client-side JavaScript;
• preview and admin routes require authorization;
• server actions and APIs validate the authenticated user and target resource;
• user-controlled HTML is sanitized;
• file uploads restrict type, size, and destination;
• cookies use suitable security attributes;
• error pages do not expose stack traces or credentials;
• third-party scripts are intentional and documented;
• privacy policy and consent behavior match actual data collection.

Search the built client output for test keys and staging URLs. Environment variable naming alone does not protect a value if code sends it to the browser.

13. Prepare DNS, domains, and certificates

Before cutover:

• add and verify the production domain at the host;
• record the current DNS values;
• understand whether the apex and www redirect or both serve content;
• decide the canonical host;
• confirm automatic certificate issuance requirements;
• lower TTL in advance if useful;
• document who controls the registrar and DNS provider;
• schedule a change window with the needed people available.

After the change, test from a network that did not visit the preview. Verify the certificate chain, hostname redirects, and both IPv4 and IPv6 behavior if configured.

14. Define rollback before launch

Rollback is a decision process, not just a button. Document:

• the last known-good deployment;
• how to restore DNS or reassign the production domain;
• whether content written after launch can be preserved;
• who can authorize rollback;
• thresholds for errors, failed payments, or failed forms;
• how customers will be informed if needed.

Practice rollback on a preview environment. A procedure that nobody has executed is an assumption.

15. Watch the first hours and days

Create a launch dashboard that answers:

• Are error rates increasing?
• Are top landing pages returning 200?
• Are old URLs redirecting correctly?
• Are forms, signups, and purchases reaching the backend?
• Is organic traffic reaching the new canonical URLs?
• Are crawlers encountering unexpected blocks?
• Are real-user performance metrics materially worse?

Check logs for high-volume 404s and fix legitimate missed mappings. Avoid reacting to isolated bot requests for files your site never had.

Stop-ship conditions

Do not launch if any of these remain unresolved:

• clean production build cannot be reproduced;
• primary routes or assets fail;
• a money or lead form is unverified;
• authentication exposes another user's data;
• production secrets appear in client output;
• important old URLs lack approved behavior;
• canonical, robots, or sitemap data points at staging;
• there is no tested rollback path.

Cosmetic differences can be scheduled. Data exposure, lost submissions, broken routes, and destructive migrations cannot.

A concise sign-off record

Record the result in one release note:

Release commit:
Production URL:
Build verified by:
Route QA:
Forms/integrations:
SEO and redirects:
Analytics:
Accessibility:
Performance:
Security/privacy:
Rollback tested:
Final approver:

This document makes ownership clear and gives the next release a starting point. The conversion creates the code; the launch checklist turns it into an operating website.

Official references

• Next.js: metadata and Open Graph images
• Next.js: sitemap file convention
• Google Search Central: site moves and migrations
• Google Search Central: build and submit a sitemap