WordPress to Next.js Migration
WordPress to Next.js migration, without losing the traffic you already have.
You’ve decided to leave WordPress and you’ve picked Next.js. The question left is whether the swap costs you your organic search traffic. This page is about that risk: how the redirect map gets built, what gets checked before cutover, and what happens to your editors on the Monday after.
If the framework is still open, or you’re building something new rather than moving something old, start at our Next.js web development service instead. This page assumes the decision is already made.
Engineering position
Six things that decide whether this goes well.
The redirect map comes out of the database, not a spreadsheet
A WordPress install serves far more URLs than its sitemap admits. Posts and pages are the easy part. Underneath sit category, tag, author and date archives, an attachment page for every image ever uploaded, feed endpoints hanging off most of them, and a /page/2/, /page/3/ tail on each archive carrying most of the internal links that point at your older posts.
So the map gets generated from the permalink structure, then reconciled against a crawl and against Search Console impressions. Anything that survives all three gets a destination. Attachment pages, thin tag archives and replytocom parameters were never meant to exist in the first place, so they get a 410 or a redirect to their parent, and that’s a decision somebody made rather than an oversight.
Trailing slashes are a site-wide redirect nobody budgets for
WordPress serves /about/ with a trailing slash. Next.js, by default, serves /about without one. Miss that and every URL takes an extra hop before it renders, on top of whatever redirect the migration itself needed, and a two-hop chain is how a clean 301 turns into a crawl-budget problem. Keep the slashes or drop them. What you cannot do is leave it to whichever default happens to win.
The same bug hides in the old rules. A site that’s run a redirect plugin for five years holds rules pointing at URLs that have themselves since moved. We flatten those chains to a single hop against the final destination. Skip that step and you ship three-hop redirects on your best-linked pages.
Parity gets checked before cutover, because afterwards there’s nothing left to compare against
Most rebuilds port the title tag and the meta description and quietly drop everything else. An SEO plugin on a mature WordPress site emits a canonical, an Open Graph block, a Twitter card, and a JSON-LD graph with Article, BreadcrumbList, WebPage and Organization nodes wired together by @id. Rebuild without reproducing that and you haven’t migrated a site, you’ve published a new one.
Pagination is the other quiet casualty. When /blog/page/2/ becomes an infinite scroll that renders nothing on the server, the internal link path to every post older than six weeks disappears, and those posts start behaving like orphans. So we diff old against new, URL by URL, while both are still standing.
Headless WordPress is a real answer, and so is leaving
Keeping WordPress behind WPGraphQL is right more often than replatform enthusiasts admit. A trained editorial team and a genuine ACF content model aren’t the problem; the theme layer is. WPGraphQL with the ACF extension gives you typed fields, and you cache at the render layer rather than per request, because a deeply nested query against a large wp_postmeta table is slow and always will be. You also inherit PHP, MySQL, and a wp-admin that now needs locking down harder than before, not less.
Move content into Payload or Sanity when the existing model is a page builder’s soup of one rich-text blob per page. Somebody has to remodel that content before it’s useful in any front end, and the migration is the only moment anyone will pay to do it.
Either way, somebody rebuilds the editing experience rather than assuming it. Once the CMS stops rendering the site, Preview is dead until draft mode is wired to a preview route, and Publish no longer means live: it means a webhook fired and a revalidation ran. From an editor’s chair, a webhook that quietly stops firing looks exactly like a broken CMS.
Next.js is not the thing that makes you fast
Deleting the fourteen plugins that each enqueue their own copy of jQuery makes you fast. Serving images that were resized rather than the 4000-pixel originals in the media library makes you fast. If your pages ship several hundred kilobytes of render-blocking CSS because a page builder emits a stylesheet per widget, porting the same DOM into React changes the logo on the invoice and not much else.
A well-built WordPress theme behind full-page edge caching is genuinely quick. If that’s already where you are, the case for migrating is maintainability and the product surfaces a theme layer cannot reach, and it is not Core Web Vitals. Next.js earns its keep where the dynamic and the cacheable are tangled together, because you can finally draw the render path per route instead of per plugin.
Don’t change your information architecture in the same release
The most expensive migration failure has nothing to do with code. It’s shipping a replatform and a new URL structure in the same week. Traffic moves for two or three weeks either way, and with two candidate causes you can’t tell them apart, so a month goes into arguing instead of fixing.
Migrate first, on the structure you already have, and let it settle until the crawl stats flatten. Then restructure, with a second redirect map you can reason about on its own. The same holds for a rebrand and for a content prune. Do all three at once and you’ve paid us to flip a coin.
How it runs
What we hold to, and what a migration price turns on.
Your repo, your cloud, from commit one
The migration happens in your GitHub organisation and your hosting account. The redirect map, the parity report and the runbook are files in that repo, not attachments buried in an email thread.
A staging URL by the end of week one
The new front end is deployed and clickable long before the content is finished. Every Friday you get a build, a short note on what changed, and what’s queued next.
Decisions in writing
Every URL that doesn’t map one to one is recorded with its destination and the reason for it. When rankings move six months from now, you won’t be reconstructing that from memory. It’s in the repository.
Fixed scope, quoted before kickoff
Change requests are priced and confirmed in writing before anyone starts them. Every migration grows a tail of small discoveries. We quote that tail rather than absorbing it quietly and billing for it later.
We don’t publish a per-page migration price, and you should be suspicious of the calculators that do. A form with six fields cannot know how many of your URLs need a decision rather than a rule, and that is the largest variable in the estimate. What we publish is a rate card: marketing sites start at $7,500, platforms at $28,000, and the minimum for a build is $7,500. Those figures are estimates in US dollars, not quotations; the quote that follows scoping is fixed in writing before kickoff. Once we’ve crawled the site, your migration gets quoted against whichever of those it resembles.
The biggest single variable is how many URLs need an individual decision rather than a pattern. After that, whether the content model gets remodelled or lifted as it stands, then the plugin surface, where forms, membership and commerce do most of the damage. Design changing in the same release moves the number again, and so does how much of the old stack keeps running afterwards. Same argument we make about what an MVP actually costs. The estimate follows the decisions, not the page count.
Send the domain and we crawl it before quoting, so the first thing back is a URL count, the archive and pagination surface, the plugin list, and a straight read on whether headless WordPress or a content move suits you better. Send us the URL and get a fixed quote, or read the rest of what we build in Next.js if the migration is only phase one.
Send the domain. Get the redirect map first.
We crawl before quoting, so the first thing you see is the URL surface you’re actually migrating. Fixed scope, fixed price, start date within two working days. Email edgebrainstudios@gmail.com or call the number below.