WordPress to Next.js Migration: The SEO-Safe Checklist

A safe WordPress to Next.js migration preserves the job of every valuable page before it changes the platform. Build a page-parity ledger, keep URLs where possible, map one-to-one redirects where they change, verify the rendered HTML, test analytics and monitor Search Console after launch.

The dangerous sentence is: “The content has been migrated.”

Content is only one layer. The existing site also contains search history, external links, internal relationships, metadata, structured data, images, forms, analytics events and editorial habits.

A migration can produce a cleaner system and a weaker website if those signals are treated as WordPress details instead of business assets.

Checked 26 August 2026 · Based on current Google Search Central and Next.js App Router guidance

The migration in six gates

Do not launch because the homepage looks finished. Launch when all six gates have an owner and evidence.

Before the build: capture the current truth

Create three snapshots before changing templates or URLs.

Crawl snapshot

Record:

• every internal HTML URL and status code;
• titles, descriptions, headings and canonicals;
• index and follow directives;
• internal links and crawl depth;
• structured data;
• image URLs and alternative text;
• XML sitemaps and robots rules;
• redirects, redirect chains, 404s and soft 404s.

Search snapshot

Export page and query performance from Search Console. Mark:

• pages receiving clicks or impressions;
• branded and non-branded queries;
• queries where several pages already overlap;
• externally linked pages;
• pages included in rich results;
• seasonal landing pages that may look quiet today.

Search Console can hide low-volume queries, so page-level evidence matters too.

Conversion snapshot

List every useful action:

• form starts, validation and successful submissions;
• click-to-call and email links;
• bookings, purchases and account creation;
• downloads, calculators and important outbound clicks;
• consent states and campaign parameters;
• CRM, email or operational handover after submission.

The new website is not equivalent if it preserves traffic and breaks the enquiry.

Build the page-parity ledger

Give every current URL one row.

This ledger is the centre of the migration. The sitemap, redirects, QA list and monitoring report should all trace back to it.

Download the page-parity ledger template →

It keeps the inventory, page decision, redirect target and QA owner in one working file.

Keep URLs unless change creates clear value

Moving from WordPress does not require changing page paths.

Keep a useful, established URL when it still describes the page. Change it when the information architecture or intent genuinely changes—not to make every address look tidier.

Google's site-move guidance recommends accurate URL mapping and warns against sending many unrelated pages to one destination. A blanket redirect to the homepage creates confusion and may be treated as a soft 404.

For changed URLs:

• use a permanent server-side redirect;
• point directly to the final relevant URL;
• avoid chains and loops;
• keep query parameters only where they still matter;
• update internal links to the final address;
• keep redirects for at least a year, and preferably longer for useful old links.

Test the map with an automated request sweep and a manual sample of the highest-value pages.

Preserve the page job, not just the words

A migration often compresses several useful pages into a more fashionable long page. That can remove the specific answer each old URL provided.

For every important page, preserve or improve:

• the query and audience it serves;
• the main answer visible near the top;
• substantive copy, proof and media;
• a unique title, description and main heading;
• contextual links in and out;
• the next useful action;
• structured data supported by visible content.

Do not copy broken, outdated or duplicate content simply for parity. Record every merge or removal and give it the closest useful destination—or a real 404/410 when no equivalent exists.

Verify what Next.js actually renders

Inspect the HTML response and the rendered page.

Important public content should not appear only after a browser-side request or click. Check:

• title, description, canonical and robots directives;
• the main heading and body copy;
• navigation and contextual links as real anchor elements;
• image alternative text and dimensions;
• structured data matching visible facts;
• pagination and faceted routes;
• language or regional alternates where used;
• status codes for missing, redirected and unavailable content.

The Next.js Metadata API can generate metadata and special files. It does not decide the correct canonical, index rule or page intent for you.

Use the full Next.js App Router SEO checklist as a production gate.

Migrate media and downloads deliberately

WordPress media URLs often receive links and search visibility of their own.

Inventory images, PDFs and downloads referenced by valuable pages. Keep stable URLs where practical. When an asset moves, redirect the old address to the actual replacement—not to the page that happens to contain it.

Also check:

• image dimensions are reserved to prevent layout shift;
• responsive sizes do not send desktop files to small phones;
• filenames and alternative text remain useful rather than keyword-stuffed;
• PDFs intended for search remain crawlable and linked;
• old attachment pages do not become orphaned errors.

Rebuild forms and measurement before launch

Do not copy analytics tags and assume continuity.

Create an event parity table:

Keep campaign tagging, referral data and CRM handover visible through the journey. A thank-you screen is not proof that the right person received the enquiry.

Launch gate

The cutover is ready only when:

• the parity ledger has no unexplained high-value gaps;
• staging cannot be indexed and production can;
• the redirect map passes automatically;
• canonicals point to production URLs;
• robots and sitemaps use the production host;
• important pages return the expected status and content;
• internal links do not point through redirects;
• forms and downstream handover pass;
• analytics receives the expected events;
• mobile, accessibility and performance checks use real content;
• Search Console access and verification will survive the move;
• rollback criteria and owners are written down.

Where possible, avoid changing the domain, CMS, URL structure and whole visual identity in one step. Google's guidance recommends splitting major changes where that reduces risk.

The first 30 days

Launch day

• submit the new sitemap;
• inspect representative high-value URLs;
• watch 404s, server errors and form delivery;
• confirm analytics and consent behaviour;
• crawl the production site and compare it with the ledger.

Days 2–7

• review indexing and crawl reports daily;
• check redirect hits and unexpected old URLs;
• compare landing-page traffic and conversion with the baseline;
• fix parity defects before adding new features.

Weeks 2–4

• review query and page movement, allowing for normal reprocessing;
• check Core Web Vitals field data as it becomes available;
• update valuable external links you control;
• keep the old crawl and evidence exports available;
• record decisions so later changes do not undo the migration.

Google says medium-sized site moves can take a few weeks or longer to settle. There is no honest promise of zero fluctuation.

The migration is complete when the evidence matches

The new design being live is not the finish line.

The migration is complete when valuable pages resolve correctly, search systems can understand them, customer actions work, editors can operate the content and the team can explain any remaining movement.

If you need a team to own that whole boundary, see Ampliflow's UK Next.js development and migration work or US Next.js development company approach.

Related: Next.js vs WordPress · Choose a Next.js agency · Next.js performance audit