WordPress to Next.js Migration Checklist for Content, Preview and SEO

A WordPress to Next.js migration is rarely just a move from one rendering stack to another.

It is usually a move away from years of accumulated editorial behaviour: posts, pages, categories, tags, media uploads, redirects, plugins, menu structures, custom fields, shortcodes, SEO fields, author archives, and a lot of small assumptions that people forgot were there.

Next.js may be the right front‑end platform. WordPress may remain the CMS. WordPress may be replaced by a headless CMS. Either way, the migration needs to preserve what matters: URLs, content meaning, editorial workflow, preview, metadata, and search equity.

The dangerous version is a visual rebuild that treats WordPress as a source of "content" in the abstract. Real WordPress sites are not abstract. They are messy, useful, historic systems with public URLs attached.

Start with a WordPress Content Inventory

Export more than the obvious page list.

You need to know about:

• posts
• pages
• custom post types
• categories
• tags
• authors
• media attachments
• menus
• reusable blocks
• custom fields
• SEO plugin fields
• redirect plugin rules
• shortcodes
• embedded forms
• embedded scripts
• archive pages
• feed URLs
• search pages

The WordPress REST API handbook is a useful starting point if WordPress is staying as the content source. If the project uses GraphQL, WPGraphQL may expose a cleaner query model, but the same inventory work still applies.

Do not assume that a post and a page are enough. Many commercially important WordPress sites hide key content in custom post types and plugin fields.

Decide What WordPress Still Owns

There are several valid migration shapes:

• WordPress remains the CMS and Next.js renders the public site.
• WordPress is used temporarily while content moves to another CMS.
• WordPress is retired and content is imported into a headless CMS.
• Some WordPress routes remain live while Next.js takes over priority pages.

Each shape has different risks.

If WordPress remains the CMS, you need reliable API access, preview, cache invalidation, media handling, and field governance. If WordPress is retired, you need content model mapping, editorial training, redirects, and a migration audit. If both run side by side, you need clear ownership of routing and canonical URLs.

This is why CMS migration planning matters before development begins. I covered the wider principle in de‑risking a CMS migration before it starts.

Preserve URL Intent Before Changing Structure

WordPress URL structures often carry history.

A site may use:

• date‑based post URLs
• category prefixes
• custom post type slugs
• author archives
• tag pages
• attachment pages
• trailing slashes
• mixed casing from old imports
• plugin‑generated redirects

Before deciding the new structure, crawl the current site and export Search Console landing pages. Identify which URLs earn traffic, links, conversions, or internal importance.

Then decide:

• keep the URL
• redirect to a direct equivalent
• consolidate into a better canonical page
• return 404 or 410 for genuinely dead content
• noindex thin archives that need to exist for users

Avoid collapsing old posts, category pages, or service pages into broad replacements. Redirects should preserve intent, not just status codes.

Rebuild Content Models Deliberately

WordPress encourages flexible editing. That flexibility is useful until a migration needs predictable rendering.

Map fields by template:

• title
• slug
• excerpt
• body content
• featured image
• image alt text
• SEO title
• meta description
• canonical override
• schema fields
• author
• publication and update dates
• category and tag relationships
• related articles or services
• call‑to‑action blocks

Shortcodes and embedded blocks need special attention. A shortcode that rendered a form, gallery, pricing table, or video in WordPress may become dead text if it is copied blindly into a new CMS or API response.

The same applies to media. WordPress media libraries can contain missing alt text, duplicate uploads, oversized images, and attachment pages that were accidentally indexable. A migration is a good time to fix those, but not by losing useful media references.

Plan Preview as Part of the Migration

Preview is not a luxury feature.

Editors need to see unpublished content in the new front‑end before it goes live. If preview is weak, people either stop trusting the platform or invent unsafe workarounds.

Check:

• can draft pages be previewed?
• can unpublished posts be previewed?
• does preview work for all content types?
• are preview URLs protected?
• do preview cookies behave on the production domain?
• does preview bypass stale cache correctly?
• are images and related entries visible before publication?
• does preview work in iframe‑based editorial tools if required?

The older preview mode with a headless CMS article covers the general shape. The WordPress migration version needs to include WordPress roles, draft status, revisions, and content API access.

Recreate Metadata and Schema, Not Plugin Settings

WordPress sites often rely on SEO plugins to generate metadata. During a migration, those fields may not come across cleanly.

Audit:

• SEO title
• meta description
• canonical overrides
• robots settings
• Open Graph fields
• Twitter card fields
• schema output
• breadcrumbs
• XML sitemap settings

Do not assume plugin output should be copied exactly. Some historic settings may be wrong. The point is to preserve intentional SEO decisions while removing accidental plugin behaviour.

For visible page structure, HTML markup for SEO is still a useful baseline. Metadata and schema should support the page the user can see, not describe a page that no longer exists.

Launch with Migration Evidence

Before launch, prepare the evidence you will need if traffic moves.

At minimum:

• old URL list
• new URL list
• redirect map
• sitemap comparison
• template metadata checks
• rendered HTML checks
• important page screenshots
• Search Console baseline
• analytics baseline
• crawl before launch
• crawl after launch

This is not theatre. If traffic drops, you need to know what changed. The worst migration recovery work starts with no baseline and an argument about whether the old site was really better.

Wrapping Up

A WordPress to Next.js migration can be a strong move, especially when the current site is slow, plugin‑heavy, difficult to maintain, or weak for structured front‑end work.

But the migration has to respect the existing content estate. WordPress may be messy, but it often contains years of editorial decisions and search signals. The job is not to copy that mess blindly. It is to preserve value, remove accidental risk, and give the new Next.js platform a cleaner foundation.

Key Takeaways

• Inventory posts, pages, custom post types, media, menus, taxonomies, and plugin fields.
• Decide whether WordPress remains the CMS, is retired, or runs alongside Next.js.
• Preserve URL intent with direct redirects and explicit canonical decisions.
• Treat preview as part of the migration, not a nice‑to‑have.
• Rebuild metadata and schema from page requirements, not plugin defaults.
• Capture Search Console, crawl, sitemap, and rendered HTML baselines before launch.