Next.js website migration checklist: protect search visibility

Define the migration before choosing the implementation

Begin by naming what will actually change: the content management system, rendering model, hosting, domain, protocol, URL paths, information architecture, design, analytics, or all of them. A rebuild from WordPress to Next.js can keep every public URL unchanged, while a modest-looking redesign can quietly replace hundreds of paths. These are different search risks and need different plans.

If the domain and paths remain the same, the task is primarily to preserve content, responses, metadata, links, functionality, and measurement while the underlying platform changes. If visible URLs change, it is also a site move: every valuable old URL needs an intentional outcome and Google must recrawl the old and new locations. Keep optional changes out of the launch where practical. A simultaneous rebrand, content rewrite, navigation redesign, domain change, and analytics replacement makes faults harder to isolate and recovery harder to judge.

Set acceptance criteria before building. State which pages, search landing pages, conversions, accessibility behaviours, integrations, tracking events, and performance constraints must survive. Give the migration a business owner, a technical owner, and a person responsible for search validation. Record who can approve launch, who can roll back, and which failures require an immediate pause.

• Classify the move as same-URL replatforming, URL-changing migration, hosting change, or a combination.
• Separate required changes from attractive additions that can follow after stability is proven.
• Define launch gates for content, search, accessibility, analytics, forms, and operational integrations.
• Agree a rollback route and the evidence that would trigger it.

Build a baseline and a complete URL inventory

A migration cannot preserve pages the team does not know exist. Combine the current XML sitemap, content-management export, analytics landing pages, Search Console pages and queries, internal crawl data, server logs, backlink data available to the business, paid campaign destinations, and operational records. Include images, documents, feeds, confirmation pages, and other assets that receive traffic or support a customer journey. A sitemap alone is not a complete inventory because it may omit old, orphaned, parameterised, or incorrectly configured URLs.

For each important URL, record its current response, indexability, canonical, title, description, main heading, content purpose, internal links, structured data, traffic or enquiry role, and proposed destination. Group pages by template so that a shared defect can be found before it reaches hundreds of routes. Mark pages that should stay, merge, move, or be removed. A removed page with no close replacement should normally return a real 404 or 410 rather than redirecting every obsolete URL to the homepage.

Take a dated baseline using consistent periods. Useful measures include organic clicks and impressions by landing page and query, indexed-page patterns, crawl errors, qualified enquiries or transactions, conversion steps, top referral pages, page speed field data where available, and server availability. Annotate campaigns, seasonality, outages, consent changes, and tracking gaps. The baseline is a diagnostic reference, not a promise that rankings or traffic will remain numerically identical.

Map old URLs to the closest useful destinations

Create the redirect map as a reviewed data set, not as an improvised launch-night list. Preserve high-value paths when there is no user or architectural reason to change them. Where a path must change, map it to the page that best fulfils the old intent. Many-to-one redirects can be appropriate when genuinely duplicate pages are consolidated, but unrelated redirects frustrate visitors and can be treated like soft 404s.

Plan server-side permanent redirects for lasting URL changes and point each old URL directly to its final destination. Google recommends permanent server-side redirects such as 301 or 308 for site moves and advises avoiding chains. In Next.js 16.3, permanent route changes can be expressed through the redirects configuration or permanentRedirect in the appropriate application flow; the correct mechanism depends on when the destination is known and how large the redirect set is. Test the deployed HTTP response rather than assuming a framework option produced the intended result.

Update every signal to agree with the new URL: internal links, self-referencing canonicals, hreflang where used, structured-data identifiers, XML sitemaps, navigation, breadcrumbs, campaign destinations, profile links, image references, and downloadable resources. A redirect is a safety net for old requests, not a reason to leave the new site linking through the old address.

• Keep an exact one-to-one URL where the page and intent remain the same.
• Redirect a changed URL directly to its most equivalent live destination.
• Return a genuine 404 or 410 when content is retired without a suitable replacement.
• Reject redirect loops, chains, broad homepage fallbacks, and destinations that return errors.

Verify the Next.js output, not only the React interface

A page that looks correct after client-side interaction may still launch with missing initial content, conflicting metadata, or the wrong status code. Inspect the production-like HTML and the rendered page for each important template. Confirm that the main content, descriptive internal links, title, meta description, canonical, robots directives, language, headings, and structured data accurately describe the visible page. Test with JavaScript constrained as a diagnostic, while recognising that the intended rendering approach may legitimately use server, static, and client components together.

Use the current Next.js Metadata APIs consistently. Static metadata can live in a metadata export and route-specific values can come from generateMetadata in Server Components. Confirm inherited layout metadata does not create a duplicate or unintended title, canonical, or social description. If content is generated from a CMS, test missing, unpublished, duplicate, and stale records as well as the happy path. Unknown routes must produce a meaningful not-found response rather than a branded page with a successful 200 status.

Render structured data as a native JSON-LD script and keep it in parity with what visitors can see. Carry forward relevant organisation, article, product, service, breadcrumb, or other supported markup only when the new page contains the required information. Validate representative pages, but do not mistake schema validation for an indexability test or a guarantee of a rich result.

Check links and navigation in the generated output. Google can discover links reliably when they are real anchor elements with href values. Buttons that reveal content, fragment-based pseudo-routes, or event handlers without crawlable destinations should not replace the links that connect important pages. Confirm pagination, filters, faceted URLs, locale handling, trailing-slash behaviour, query parameters, and case conventions match the migration plan.

Rehearse the launch on production-like infrastructure

Protect a public staging environment from indexing with access controls where feasible and an explicit noindex rule when it must be reachable. Do not rely on robots.txt alone to remove an already known staging URL from search. At launch, verify that production has the intended robots.txt and that every temporary noindex directive, authentication gate, firewall rule, or crawler block has been removed from pages meant to appear in search.

Run the same automated crawl and manual journey tests against a production-like deployment. Test representative old URLs, new URLs, canonicals, response codes, navigation, forms, checkout or booking, search, downloads, consent, analytics, CRM notifications, email delivery, and error states. Compare page counts and template fields with the inventory. Sample the long tail rather than checking only the homepage and three flagship pages.

Test performance under realistic traffic and cache conditions. A migration can pass local tests yet fail when the origin, CDN, image service, third-party scripts, or data source receives production demand. Confirm cache behaviour, invalidation, security headers, TLS, DNS preparation, environment variables, rate limits, and monitoring. Keep the old platform and configuration recoverable until the new service is demonstrably stable.

Prepare a timed cutover checklist with named owners and evidence fields. It should include the final content freeze or reconciliation, database or CMS sync, build identifier, DNS or deployment action, redirect activation, robots and noindex checks, sitemap availability, Search Console verification, live transaction tests, monitoring dashboards, stakeholder communication, and rollback decision point. A rehearsal should reveal missing access and slow manual steps before customers do.

Monitor search, users, and operations after launch

Immediately after release, crawl the live site and test a prioritised sample from the redirect map. Confirm that old URLs reach the expected final page in one hop, new pages return successful responses, canonicals are self-referencing, internal links use final URLs, and the sitemap contains only canonical pages intended for indexing. Inspect priority URLs in Search Console and submit the new sitemap. Use the Change of Address tool only when its documented domain-move conditions apply; it is not needed for every redesign or path change.

Watch server logs, uptime, error reporting, crawl statistics, page indexing, Search Console performance, analytics, conversion events, enquiries, sales, and support reports. Compare page groups and templates rather than relying on one site-wide total. A fall isolated to a template suggests a different cause from a domain-wide outage; stable impressions with falling clicks suggests a different investigation from pages disappearing from the index.

Expect changed URLs to take time to be recrawled and reindexed, and avoid reacting to every daily movement. Google notes that ranking fluctuations can occur during a site move. That does not justify waiting through clear faults. Escalate sharp increases in server errors, blocked crawling, unintended noindex, wrong canonicals, missing content, soft 404s, redirect failures, or broken conversion journeys as soon as evidence appears.

Keep redirects and the old-domain controls in place long enough for users, crawlers, bookmarks, and external links to transition. Update important external links where the business has a relationship with the publisher. Record issues, fixes, and dates so performance changes can be interpreted. Once stability is established, compare the outcome with the baseline, close residual gaps, and schedule optional design or content improvements as separate, measurable work.

A practical Next.js migration plan

What a migration checklist cannot guarantee

Related Clicknex resources