WordPress to Next.js: headless first, or a clean move.

What transfers from WordPress to Next.js, and what does not?

Your posts, pages, categories, tags, media, and users move as data. Your theme, plugins, and shortcode output do not. Before you plan your build, check the REST API: it lists /wp/v2/posts, /wp/v2/pages, /wp/v2/categories, /wp/v2/tags, /wp/v2/media, and /wp/v2/users, and that tells you which content types actually return JSON.

Your layout layer stays behind. If your editors built pages with blocks or a page builder, your body field holds raw HTML or block markup that you must parse, such as into Portable Text in Sanity, while splitting visual layouts into structured fields. Forms and sliders require rebuilds, and so does markup from plugins. And your SEO metadata needs an export path too: WPGraphQL exposes Yoast titles and descriptions through its seo field.

Open /wp-json/ on your domain. Then inspect your page source, and you will have a list of your data gaps in minutes. The assessment parses these same public signals, recording your markup and headers, plus structured data, before you commit to code.

How do you plan the URL map and redirects so your search traffic survives?

Build your URL map by pairing each old URL with one new URL, then issue permanent server-side redirects so your search traffic follows your pages. Google asks you to map old URLs to new ones and avoid chained redirects. It also asks you to submit a new sitemap and track traffic on both ends. Skip the map and you are guessing.

In Next.js, write your rules in the redirects option of next.config.js. Test first. Setting permanent: true sends a 308 status that browsers and search bots cache indefinitely, so check each rule before you ship it. Path patterns match from the root, and '/old-blog/:slug' will not catch '/old-blog/a/b', so your nested URLs need explicit rules (the pattern is narrower than it looks).

Keep your redirects live for at least a year. Strip any noindex tags or robots disallow rules left on staging, and point your canonicals at the new URLs. If your headless backend discourages search engines, every post's seo field can return noindex, and your Yoast URLs may output your CMS host. Staging leftovers are the quiet way a launch goes wrong.

How is content moved from WordPress: export, API or crawl?

Migrate your content through the API once your site has more than a few pages, because the REST API returns your posts, pages, tags, categories, and media as JSON. Scraping rendered HTML is your fallback for data the endpoints omit. And you can copy Sanity's API pattern: run a CLI script that queries the REST API, writes documents, and paginates until the responses stop.

The media list returns 10 items per page by default, so your script must set page and per_page across a fetch loop. Sanity's tooling batches mutations. It runs dry by default and validates your documents against your Studio schema, so you catch errors before writing records. Make your script idempotent with deterministic IDs, and upload assets concurrently under a rate limit such as p-limit. A script you cannot safely rerun is a script you will fear.

If a page builder renders your markup, crawl the output, parse the HTML, and compare your record totals against your master URL list. Find the data gaps before launch, because after launch they are your readers' problem.

What do your editors get on Next.js compared with WordPress?

Your editors keep the WordPress admin if you go headless, and get a new Sanity Studio or Contentful editor if you move your content. In both setups, they lose the visual canvas of your theme and page builder. What they edit turns into fields: your editors fill forms rather than editing the page as it appears to your readers. That is a real change in how the work feels.

Previews are the first issue your editors will raise. Build a preview route in Next.js that pulls draft content, and test it with your slowest editor before launch. With ISR, the first request after your revalidate window still gets the stale page while regeneration runs, so tell your team what to expect (before they ask).

Plugins are the other loss you will feel. Your SEO, forms, and redirect plugins stop working on the new front end, so you rebuild each feature as a field, a service, or a routing rule. But the trade is real: you get a front end your editors cannot break with a plugin update.

How long does a WordPress to Next.js migration take, and what drives the effort?

Your migration takes as long as your URL count, content types, media library, integrations, and locales dictate. No public scan can promise you a date. What you can do is count each driver from the outside: your sitemap gives your URL count, your /wp-json/ routes show your content types, and your forms and scripts reveal your integrations. So count first, estimate second.

Each driver multiplies the others. Many URLs with one content type are mostly redirect work. Few URLs with many types are mostly schema modeling. If your media list pages at 10 items by default, a large library means thousands of requests, and additional locales multiply every URL you map. I plan and run moves like this one, and the pattern holds: the slow part is rarely the build. It is deciding what your content should become.

ISR lets you update cached static content without rebuilding the entire site. So your deploy times stop growing with your page count.

When should you not move from WordPress to Next.js?

You should not move when your site is in good standing, your editors work well in it, and you have no application, personalization, or editor problem a new front end would solve. Stay put until the evidence says otherwise. Run the free assessment first: if your score sits in the 80 to 100 band, your evidence shows the current build is not your bottleneck, and a rebuild would spend your budget and risk your search traffic for little return.

Headless WordPress is worth the intermediate step only when your editors must keep their admin and your front end is the problem. Otherwise you run two systems: WordPress for content and Next.js for pages. You also patch, host, and monitor both. If you do move, match the stack to your site: Astro for a content or marketing site, Next.js with Sanity or Contentful when you run an application, personalization, or a large editorial team. Each path gives up what your editors know: the visual canvas, plugins, and a hosted admin (all three, not one).

Questions, answered.

Your next read.

1. 01WordPress alternativesStay, go headless or move: judged by your pages.
2. 02WordPress to AstroPre-built pages, content in Markdown or a headless CMS.
3. 03Next.js SEO auditRendering mode, metadata, hydration cost.
4. 04Headless CMS SEO auditRendering, canonicals, previews, schema from the template.