Editors keep what they know
If non-technical staff publish weekly, headless WordPress keeps wp-admin exactly as it is. Moving the CMS and the frontend at once is two migrations charged as one.
Services / WordPress migration
Leave WordPress. Keep the URLs that earn.
Rankings attach to URLs, not to the software behind them. A WordPress migration goes wrong when permalinks change, /wp-content/uploads image paths break, or the canonical tags Yoast has been writing for years quietly disappear. All three are mapped before launch.
What the engagement covers
A focused scope with visible decisions.
The work is organized around outcomes and operating constraints, not a long list of disconnected features.
01
Full crawl joined against Search Console and the existing Yoast sitemap index
02
Permalink map covering posts, pages, categories, tags, date and author archives, and pagination
03
Image path plan for /wp-content/uploads so indexed and hotlinked media keeps resolving
04
Content path decided up front: headless WordPress, a different CMS, or content in the repo
05
Next.js templates carrying the canonicals, titles, and structured data Yoast previously emitted
06
Staging dry-run asserting every redirect row, then coverage checks at 48 hours, two weeks, and six weeks
Quality criteria
What gets decided before the details multiply.
Images are URLs too
/wp-content/uploads paths are indexed in Google Images and embedded on other people's sites. They get mapped in the same pass as pages, not discovered as a problem afterwards.
Replatform before redesign
Doing both at once makes any traffic movement impossible to attribute. Where traffic is worth protecting, the stack moves first on the existing design.
Delivery path
5 checkpoints from context to release.
- 01
Crawl the WordPress site
Full crawl joined against Search Console and the Yoast sitemap index. This is where the attachment pages, tag archives, and feed URLs nobody remembers surface — usually several times the page count the client expects.
- 02
Decide the content path
Headless WordPress so editors keep wp-admin, a different CMS, or content in the repo. Driven by how often non-technical staff publish, and settled before any template work.
- 03
Map every URL, images included
One row per indexed URL with destination, status code, and resolved canonical. /wp-content/uploads paths are mapped in the same pass rather than treated as an afterthought.
- 04
Rebuild templates with metadata attached
Canonicals, titles, and the structured data Yoast used to emit ship in the same commit as each template, so there is never a window where the new site is live and unlabelled.
- 05
Dry-run, launch, recheck
Assert every redirect row against staging, verify staging cannot be indexed, then launch and check coverage at 48 hours, two weeks, and six weeks.
WordPress-specific
Six URL types a WordPress migration usually forgets.
A WordPress install generates far more indexed URLs than its page count suggests. These are the categories that turn up in the crawl and surprise people, and every one of them is checkable before you go live.
- 01
/wp-content/uploads paths
Every indexed image lives here, and those URLs are hotlinked from anywhere that has embedded your content. They need to keep resolving or Google Images traffic disappears silently.
- 02
Attachment pages
WordPress generates a page per uploaded media file. Most sites have hundreds nobody knows about, some with inbound links. They need a decision each: redirect to the parent post, or retire deliberately.
- 03
Date, author, and tag archives
/2019/07/, /author/admin/, and /tag/whatever/ are all real indexed URLs on a default install. Some carry traffic, most carry none, and shipping without checking loses the ones that did.
- 04
Feed URLs
/feed/, /comments/feed/, and a feed under every category. Aggregators and readers still request them, and a 404 there quietly breaks subscriptions the business does not know it has.
- 05
Pagination
/page/2/ under the blog and every category and tag archive. Deep pagination is often where older posts are discovered from, so dropping it strands them.
- 06
Yoast canonical and schema output
Yoast has been writing canonical tags, Open Graph, and Article or Product schema on every page for years. Google expects that markup. It has to be reproduced in the new templates, not rediscovered after launch.
Questions
Useful answers before the first call.
Will moving off WordPress hurt my Google rankings?
Not if the URLs survive. Rankings attach to URLs, not to the software behind them. The damage in a WordPress migration almost always comes from permalink structure changing, image paths under /wp-content/uploads breaking, or the canonical tags Yoast used to output disappearing. Map all three before launch and a replatform is close to neutral, often positive once the site gets faster.
What happens to my images?
This is the step most migrations forget. Every image on a WordPress site lives under /wp-content/uploads/YYYY/MM/filename.jpg, and those exact URLs are indexed in Google Images and hotlinked from anywhere that has ever embedded your content. They either need to keep resolving through redirects, or the new site needs to serve the same paths. Silently changing them drops your image search traffic and breaks other people's embeds.
Do I lose the WordPress admin? How does my team edit content?
Only if you want to. Two options. Headless WordPress keeps wp-admin exactly as your team knows it and Next.js reads content through the REST API or WPGraphQL, so nothing changes for editors. Or content moves to a different CMS, or to files in the repo if the site rarely changes. Which one is right depends on how often non-technical staff publish, and it is decided before the build starts, not during.
What about WooCommerce?
WooCommerce is a bigger job than a content site, because product, category, and faceted-filter URLs multiply fast and checkout has to keep working throughout. Usually the storefront moves to Next.js while checkout and order management stay on WooCommerce behind the scenes, so nothing on the payments side has to be re-certified. That is scoped separately after the crawl shows how many product URLs actually exist.
How long does a WordPress migration take?
Four to eight weeks for a content or brochure site, longer for WooCommerce with a large catalogue. The first week is crawl and mapping and it is the week that determines whether the rest goes smoothly. Sites with years of accumulated plugins, tag archives, and attachment pages take longer to map than the page count alone suggests.
Is Next.js actually faster than WordPress?
Usually, but not automatically. A WordPress site with good caching can be fast, and a badly built Next.js site can be slow. The reliable gains come from serving static or incrementally regenerated HTML instead of rendering PHP per request, shipping images in modern formats at the size they are displayed, and dropping the plugin JavaScript that accumulates on most WordPress installs. Those are decisions, not a property of the framework.
Can you migrate without changing the design?
Yes, and on a site with traffic worth protecting it is often the better sequence. Replatforming and redesigning at once makes any traffic movement impossible to attribute. Moving the stack first on the existing design, then redesigning once the new platform is stable, is slower but far easier to diagnose if something moves.
Bring the current situation