You are probably not shopping for a framework. You are tired of patching plugins, of a site that stays slow whatever cache you install, and of an admin nobody wants to open. Next.js fixes some of that permanently and hands you a different set of constraints in exchange. This page covers both: the redirect work that decides whether your rankings survive, and the cases where staying put is the better call.
Why your WordPress site stays slow whatever caching plugin you install
A full-page cache in front of WordPress fixes exactly one thing: time to first byte for anonymous visitors. It does nothing for the metrics that actually move Core Web Vitals, because those are decided in the browser. A typical five-year-old install ships jQuery, jQuery Migrate, and a separate CSS and JS bundle from every active plugin, on every template. Plugin authors cannot know which page you are on, so they enqueue everywhere. The theme adds one render-blocking stylesheet covering every layout it supports, most of which you never use.
Then there is the database side, which caching hides until it cannot. Autoloaded rows in wp_options accumulate quietly: install and remove thirty plugins over five years and the orphans still load on every request. wp_postmeta grows without a useful index once you have a real catalogue. admin-ajax.php is a general-purpose endpoint that bypasses the page cache by design. wp-cron fires on visitor requests, so your worst page load belongs to whoever happened to arrive when a scheduled job was due.
The failure mode is always the same. The cache holds beautifully in a synthetic test, then a session cookie appears (a logged-in user, a cart, a consent banner that varies the response) and every request falls through to PHP. That is why field data never matches the number you screenshotted. It is structural, not a misconfiguration, and no plugin fixes it.
What you gain, and what you genuinely give up
The gains are real and mostly permanent. You control the rendering path, so you decide per route whether a page is built once, revalidated on a schedule, or rendered per request. Images go through one pipeline instead of four competing plugins. The security surface shrinks to your own code plus your CMS vendor, which ends the weekly ritual of reading changelogs for plugins you installed once in 2021 and can no longer safely remove.
The losses are just as real, and people selling migrations tend to skip them. The reflex of solving a problem by installing a plugin disappears. A booking flow, multi-currency pricing, a members-only area, a form with conditional logic: each becomes a development ticket with a review and a deploy, not a purchase on a marketplace. Your marketing lead can no longer drop a tracking script into the site alone on a Friday afternoon, unless you wire up a tag manager for exactly that.
You also need a process you may not have today: a git repository, pull requests, preview deployments, and one person on your side who can say yes to a change. The cost structure moves too. Instead of one managed hosting bill and a few annual plugin licences, you pay for build and hosting infrastructure, a CMS plan if you use a hosted one, and developer time for things that used to be a checkbox. For a content site with a few forms, that trade is usually worth it. For a site held together by fifteen paid plugins doing real work, run the numbers before anyone writes code.
Three routes out: headless WordPress, a new CMS, or a frozen archive
Route one keeps WordPress as a headless backend and replaces only the front end. Next.js reads from the REST API or WPGraphQL, editors keep the admin they know, Advanced Custom Fields keeps working, and publishing triggers on-demand revalidation through a webhook. Lowest risk when the editorial team is large or the content model is genuinely custom. The catch: you still run PHP and MySQL, you still patch core, draft previews need an authenticated path of their own, and wp-admin belongs behind an IP allowlist or basic auth rather than on the open internet.
Route two extracts the content once into a modern CMS (Sanity, Payload, Strapi, or a git-backed MDX repository) and retires WordPress. Cleanest end state, most work up front. The WXR export is lossy in ways that only surface once you open the file: shortcodes arrive as raw text, and page builders are the real problem. Elementor, Divi and WPBakery store layouts as serialised data in postmeta rather than as HTML, so a naive export produces unusable content. The workable approach is to pull rendered HTML from the REST API, normalise it with a script, then fix the remainder by hand.
Route three freezes the old site: render the historic archive as static pages, keep every URL alive, publish everything new in the new system. That suits sites where ten years of posts still earn traffic but nobody will edit them again. Which route fits is mostly settled by two questions: how many people publish, and whether a page builder owns your layouts.
Redirects and URL families are where these migrations actually break
Rankings do not vanish because you changed framework. They vanish because a URL that earned links now returns a 404, or takes two hops to reach anything useful. Start from data, not from the sitemap: a full crawl of the live site, sixteen months of URLs out of Search Console, and server logs if you can get them. The sitemap will not contain the pages that quietly earn your backlinks.
WordPress generates URL families people forget. Archive pagination at /page/2/. Category, tag and author archives. Attachment pages, one per uploaded image, which some themes have let Google index for years. Feed URLs at /feed/ and /comments/feed/, still pulled by aggregators. Legacy permalinks such as ?p=123. Parameter noise such as ?replytocom=. And media under /wp-content/uploads/, hotlinked elsewhere and ranked in image search: keep those paths byte-for-byte identical if you can, because rewriting them is the easiest way to lose traffic you never knew you had.
Two details cause more damage than they should. Trailing slashes: WordPress canonicalises to a trailing slash, Next.js defaults to none, and if you do not decide explicitly, every inbound link becomes a redirect hop. Case sensitivity: an Apache origin often served /About-Us and /about-us alike, a Node origin will not.
Everything maps with a 301, never a 302, never a chain. Past a few hundred rules, hold them in a lookup table or at the CDN edge instead of one long ordered list in next.config, and read the 404 logs daily for the first two months.
When staying on WordPress is the right call, and when not to hire us
Some sites should not move. If you run WooCommerce with plugins handling tax rules, shipping logic, subscriptions or B2B pricing tiers, rebuilding that is a multi-quarter project with no guaranteed revenue on the other side. A hosted platform is often the honest answer: Shopify charges a monthly plan fee plus a share of each transaction, and at the time of writing the entry tiers are roughly a few tens of dollars a month, which usually beats owning the same logic in code.
If the real complaint is that the admin has become a mess, a cleanup can be far cheaper than a migration. Remove twenty plugins, rebuild the theme properly, move to better hosting. Similar outcome, a fraction of the work. If your traffic is modest and the site functions, a migration will not create demand: fix the offer and the content first. And if you publish dozens of times a day with editorial roles, embargoes and a newsroom workflow, WordPress tooling is mature and whatever replaces it will not be, at least not soon.
Do not hire us if nobody on your side can review a pull request or approve a deploy, and you have no plan to hire anyone who can. You would swap dependence on a theme developer for dependence on us, which is no improvement. Do not hire us if you want calls, video calls, standups or someone on site: we work in writing only, and that is policy rather than a scheduling preference. Do not hire us if you need a fixed price before scope exists, or if the site has to be live in ten days. Migrations with real URL history do not compress well.
Two people in Dijon, every decision in writing
Go To Agency is Robin Monteiro (full-stack, Next.js and React) and Florian Loppion (digital marketing), working from 9 rue Jean-Jacques Rousseau in Dijon, France. That is the whole company and the only office. There is no account manager between you and the person writing your redirect map, which is the main reason clients outside France work with us at all.
Everything happens in writing, by email, with a reply inside 24 business hours. No calls, no video calls, no scheduled slots. For an international client that removes the thing that usually makes remote work painful: nobody in California takes a 3am call, nobody in Bangalore waits for a European afternoon. Work continues while you sleep and a written answer is waiting when you start.
The second benefit shows up months later. Why did /blog/ become /insights/? Why is that category redirected to a page instead of an archive? The answer sits in a searchable thread, not in somebody's memory of a call. Approvals happen on a preview deployment: you get a URL, you click through, you reply with what is wrong.
What you do differently: batch your questions instead of firing them one at a time, send the actual artefact (the URL list, the credentials, the export file) rather than describing it, and accept that a message sent Friday evening Paris time is answered Monday. You own the repository, the hosting account, the CMS account and the domain from day one. Our client work, from Mediavocats and Vectosolve to Chouchou Ribeyre, Au Petit Detail and LB Athletic, runs on exactly this process.
