WordPress to Next.js Migration for rendering and route architecture.

Some fluctuation during recrawl is normal even on a well-executed migration, and nobody can guarantee otherwise. Sustained loss is not random — it almost always traces to an incomplete redirect map, content that stopped being server-rendered, or metadata and structured data that were not carried across. Those three are controllable, which is why the inventory and parity checks matter more than any other part of the project.

Keep it when editors depend on the authoring workflow and publish frequently — they lose nothing and you gain the frontend. Replace it when the plugin surface is the problem you are trying to escape, or when operating two systems is not worth the editorial convenience. Headless means two hosting bills, two upgrade paths and two security surfaces, and that cost should be in the business case rather than discovered later.

Anything doing real work becomes your application code. Forms need handling and spam filtering, SEO plugins were generating titles, schema, sitemaps and redirects, and membership or commerce plugins are projects in themselves. The plugin inventory and a named replacement for each is done before build starts — discovering at launch that nothing is producing sitemaps is the classic failure of these migrations.

Start with REST for straightforward sites; it is simpler to operate and debug. WPGraphQL earns its complexity when payload size or query depth becomes the constraint — listing pages pulling embedded authors and media through REST get slow, and GraphQL lets you request only what the component needs. Note that deeply nested media queries in GraphQL can themselves return enormous payloads and need pagination or deferred fields.

Through Next.js draft mode connected to WordPress previews, so they see the real frontend rather than the old theme. This is the single most commonly deferred piece of a headless migration and the most common reason editors resist the new site. It belongs in the first release, not a later phase.

Only on redeploy if the caching is built carelessly, which is a frequent and avoidable failure. The correct pattern is on-demand revalidation: WordPress fires a webhook on publish, and Next.js revalidates the specific cache tags affected rather than rebuilding everything. That needs a shared secret on both sides, and rotating that secret without coordinating both environments silently breaks updates.

Cost tracks URL count, template variety, integration complexity and above all plugin dependency depth — not the visual design. A brochure site with clean URLs and a handful of templates is contained. A site with custom post types, page-builder layouts, forms, memberships and commerce is substantially more, because each of those needs a replacement decision and its own testing.

Not cleanly. Elementor, WPBakery and similar store layout in their own proprietary format, and exporting it produces markup that no other system understands. The realistic approach is converting content per template into the new component model, which is manual work proportional to how many distinct layouts exist rather than how many pages.

The build is rarely the long pole. Inventory, decisions and plugin replacement planning take real calendar time upfront, and content conversion plus parity verification take real time at the end. Expect the schedule to be driven by template variety and how much content needs manual conversion, and build in a monitoring period after cutover before the project is called finished.

Often yes, and it usually reduces risk. Common patterns are moving one section or template type at a time behind a routing layer, or running Next.js for new content while WordPress continues serving the archive. Both add temporary complexity — two systems live simultaneously, careful redirect handling — but they make each step reversible in a way a single cutover is not.

Treat it as a separate decision with its own scope. Headless commerce introduces checkout flows, payment callbacks, order state and stock accuracy concerns well beyond a content migration, and the WooCommerce Store API is a different integration surface to the content APIs. Many sites correctly move the content frontend to Next.js and leave the store on WooCommerce until there is a specific reason not to.

By comparison against the pre-migration crawl, not by impression. Every changed URL resolving in one hop to a live destination, rendered HTML matching on headings, copy, links, canonicals and schema, sitemaps regenerated, analytics and conversion events confirmed firing. Then several weeks of monitoring redirect hits, coverage reports and high-value queries with rollback still available.