Migrating from WordPress to Next.js: A Step-by-Step Playbook

A migration looks like a website rebuild, but it is really three parallel deliverables: content moved with its meaning intact, engineering that preserves the existing functionality, and SEO work that keeps search engines pointing at the right places. If any of the three is treated as an afterthought, the site pays for it after launch.

The disciplined way to start is to separate them in the plan: a content inventory, a route and URL map, and a feature list. Each one becomes a checklist that drives the actual build.

The three streams also need one owner. When content, engineering, and search each report to a different person, decisions like whether to keep a page or drop a slug stall, so a single migration lead who can arbitrate is worth the overhead.

Before writing code, inventory what exists: every page, post, image, document, and metadata field on the WordPress site. Record which pages matter commercially, which ones perform in search, which are duplicates or outdated, and which redirects already exist in the WordPress configuration.

The audit answers the question too many teams skip: does this page deserve to exist in the new site? Keeping dead content alive preserves old problems, while dropping important pages breaks search performance. Each page should get a deliberate decision rather than a status quo default.

As a first pass, mark every page as keep, merge, or remove, and assign a reason. The reasons themselves become useful documentation, and the keep list becomes the true scope of the migration, which is usually smaller and clearer than the raw page count suggested.

URLs are an asset. Search engines and visitors have bookmarked, linked to, and ranked the current permalinks, so the new site should keep the URL structure where possible and map every changed URL with a permanent redirect.

A clean mapping table is the most valuable artifact in the whole project: old URL, new URL, and status for every page. Export the WordPress permalink structure, align the Next.js route structure to match where practical, and generate the redirect rules from the differences.

Test the redirects before launch, not after. Crawl the old site, replay the same paths against the new site's redirect rules, and confirm each one lands on the intended page without a chain. This single rehearsal catches the vast majority of post-launch 404 traffic.

Titles, meta descriptions, Open Graph tags, structured data, and image alt text are part of the site's search value. During the migration they should be treated as content fields, mapped into the new design system rather than regenerated from scratch, so the new site starts with the same visibility assets the old one earned.

The same applies to media. Changes to image URLs and metadata can break embedded content and cost image search traffic, so image paths, alt text, and featured-image logic all need explicit mapping.

If the site serves multiple languages, the map has to cover every locale. Each language path is a separate set of URLs and metadata, and a migration that handles only the default language silently drops the visibility of the rest.

Teams usually choose between two paths: move everything at once with a single cutover, or run the new site beside the old one and migrate sections incrementally. The incremental route is more work, but it is noticeably safer because each migrated section can be verified and, if needed, rolled back independently.

Given that both worlds can coexist during a transition, the practical default is a staged rollout. Migrate the highest-value sections first, verify behavior and search performance in production, then expand to the rest of the site.

Whatever the path, define the rollback before the launch day. Knowing the exact switch that sends traffic back to the old site, and having rehearsed it, turns a bad launch from a crisis into a routine decision.

The final phase is the one teams usually underfund. After launch, search traffic takes time to reassemble, and console data, 404 logs, and redirect chains reveal everything the plan missed. Budgeting the weeks after launch for cleanup is what separates a migration that preserves search performance from one that quietly loses it.

Make the first month a review cadence rather than a wait. Compare traffic and crawl coverage to the pre-launch baseline weekly, fix the emerging 404s as they appear, and retire the old site only when the data says the new one has absorbed its traffic.