The most expensive SEO mistake we get called in to fix isn’t a missing keyword or a slow page. It’s a redesign that shipped without redirects. A company rebuilds its site, changes its URL structure, launches, and two weeks later organic traffic has fallen off a cliff because every page Google had indexed now returns a 404. The rankings didn’t move to the new URLs — they evaporated, because nothing told Google the old URL is now the new one. Next.js gives you three clean ways to redirect, and a migration done right loses almost nothing. This is how to do it, sized for your team.
The three ways to redirect, and when to use each
Next.js offers three redirect mechanisms, and picking the right one matters for both correctness and performance. The redirecting guide lays them out; here’s the short version.
- next.config redirects — a static list of from/to rules in your config. Best for known, permanent URL changes: /old-page to /new-page. They’re evaluated before rendering, so they’re fast, and they’re the right home for a migration map.
- Middleware redirects — code that runs on every request and can redirect conditionally. Best when the decision depends on the request: auth state, locale, A/B cohort, or a database lookup of legacy URLs too numerous to list statically.
- The redirect() function — called inside a Server Component or Server Action to redirect during rendering. Best for in-flow decisions: after a form submit, or when the data says this record moved.
// next.config.ts — the migration map lives here
import type { NextConfig } from "next";
const config: NextConfig = {
async redirects() {
return [
{ source: "/old-services", destination: "/services", permanent: true },
{ source: "/blog/:slug/amp", destination: "/blog/:slug", permanent: true },
];
},
};
export default config;The migration playbook that keeps your rankings
A URL migration is a mechanical process, and the sites that survive it are the ones that treat it that way. Here’s the sequence we run on every FH replatform.
- Export every indexed URL before you touch anything. Pull them from Google Search Console and your current sitemap. This is your source of truth for what must not break.
- Map old to new, one for one. Every old URL gets a destination on the new site. If a page is genuinely gone, map it to the closest relevant page, not the homepage — a homepage redirect for everything tells Google the old page had no specific replacement, and you lose its ranking.
- Implement the map as permanent redirects. For a bounded list, next.config redirects. For thousands of legacy URLs, a middleware lookup against a redirect table.
- Preserve or update canonical tags so the new URLs are self-canonical and no old URL is still claiming to be canonical.
- Launch, then immediately re-crawl. Submit the new sitemap in Search Console and use the URL Inspection tool on your top pages to confirm they resolve and redirect correctly.
- Watch for 404s and crawl errors for 30–60 days. Search Console’s coverage report will surface any old URL you missed. Add the redirect the moment you see it.
Common ways redirects go wrong
- Redirect chains: /a → /b → /c. Each hop dilutes signal and slows the user. Always redirect straight to the final destination.
- Redirect loops: /a → /b → /a. Ships a broken page and a crawler error. Test the map before launch.
- Redirecting everything to the homepage. The laziest option and the most damaging — it throws away every page-specific ranking you had.
- Temporary redirects for permanent moves, so signals never transfer.
- Forgetting query strings, trailing slashes, and www/non-www and http/https variants, each of which is a distinct URL a crawler may have indexed.
301, 308, 302, 307: the status codes and what they signal
Redirects aren’t all the same to a search engine, and the difference is the HTTP status code they return. The two that matter are permanent and temporary. A permanent redirect (301, or its method-preserving modern equivalent 308) tells Google the move is final and the ranking signals should transfer to the new URL. A temporary redirect (302/307) says the original will be back, so keep indexing it. Next’s `permanent: true` emits a 308; `permanent: false` emits a 307. Google treats 301 and 308 equivalently for consolidating signals, as their redirects and Google Search documentation confirms. The practical rule: a redesign, a rebrand, a merged page, a changed URL structure — all permanent. Use a temporary redirect only for something genuinely temporary, like a page down for maintenance. The classic, expensive mistake is using a temporary redirect for a permanent move, so the old URL never hands its authority to the new one and the migration never fully recovers.
A worked example: changing your URL structure
Say you’re moving from `/services/roof-repair` to a location-aware structure like `/plano/roof-repair`, across forty service-and-location combinations. Here’s the sequence. First, export all forty existing URLs from Search Console. Second, build the map — each old URL to its exact new counterpart, never to the homepage. Third, because the pattern is regular, you can express it compactly with a dynamic segment in the redirect rule rather than forty hand-written lines. Fourth, launch and re-submit the sitemap. Fifth, inspect your top five pages in Search Console to confirm each old URL 308s to the right new one. The whole thing is an afternoon of careful mapping, and it’s the difference between keeping forty ranking pages and losing them.
// next.config.ts — a pattern, not forty lines
async redirects() {
return [
{
source: "/services/:service",
destination: "/:service", // if location is inferred elsewhere
permanent: true,
},
];
}Middleware for legacy maps too big to list
When the redirect map runs to thousands of URLs — a large catalog replatform, years of accumulated old permalinks — a static list in `next.config` stops being practical. That’s the case for middleware: store the old-to-new mapping in a database or edge key-value store, and let middleware look up each incoming request and 308 it if there’s a match. The lookup runs before rendering, so it’s fast, and the map becomes data you can update without a deploy. The trade-off is that the map is now production data that needs testing and monitoring like any other — but at the scale where you need it, that rigor is exactly what a migration of that size demands. Whichever mechanism you use, the SEO contract is identical: every old indexed URL resolves, permanently, to its best new home.
The 60-day watch, and the traffic curve to expect
The work isn’t done at launch; it’s done sixty days later when the data confirms the migration held. Here’s the curve a healthy migration follows so you can tell a normal dip from a real problem. In the first days after cutover, expect a small wobble as Google reprocesses your redirects and re-crawls the new URLs — impressions and clicks jitter, and that’s normal. Over the following two to four weeks, Google follows the 308s, transfers the ranking signals, and swaps the new URLs into its index in place of the old ones; traffic returns to its prior level, often with a lift because the new site is usually faster and better structured. If instead you see a sharp drop that doesn’t recover after a couple of weeks, that’s the signal something is wrong — a chunk of URLs without redirects, a redirect chain, or temporary redirects where you needed permanent ones.
The monitoring is concrete. Watch the Page Indexing report in Search Console for a spike in “Not found (404)” or “Redirect error,” which surfaces exactly the old URLs you failed to map — add the redirect the day you see them. Watch your top twenty pages by pre-migration traffic specifically, because those are where a miss costs the most. And keep the old sitemap’s URLs discoverable long enough for Google to process every redirect; pulling the old URLs out of existence too fast can strand redirects Google never got to follow. Sixty days of light attention is cheap insurance on a project that put your entire organic channel at risk, and it’s the part that separates agencies who run migrations from ones who launch and hope. If you want a second set of eyes on a migration before you flip it, that verification is exactly the kind of thing we do on a fixed scope.
What this means for your business
The mechanism is the same; the stakes and the process scale with how much traffic and how many URLs you’re moving.
For agencies
Every replatform you sell is a redirect project whether the client knows it or not, and the redirect map is the deliverable that protects both the client’s traffic and your reputation. Make “crawl current URLs, build the redirect map, verify post-launch” a non-negotiable line in every migration statement of work. The horror stories in this business are almost all launches that skipped it — and the client remembers who was driving when their traffic disappeared. Turn it into a strength: a documented, tested redirect map is a tangible artifact you can show a nervous client, and post-launch monitoring is a natural retainer hook. Pair it with the platform move itself, which we cover in our Next.js migration playbook.
For micro businesses (1–5 people)
If you’re redesigning your own small site, the redirect map is the single thing you cannot skip. You may only have a dozen pages, but if any of them rank for anything, a 404 on that URL after launch throws away the traffic. Before you launch, list your current pages, note which new page each becomes, and add a redirect for each. If your old site is on a different platform, at minimum redirect your top few pages by hand. When in doubt, this is exactly the kind of high-stakes, low-effort task worth having us verify before you flip the switch — a bad launch is far more expensive than the check.
For small businesses (SMEs)
You have enough ranking pages that a migration needs a real map, not a guess. Export your indexed URLs from Search Console, map them, and implement the list in next.config — a few hundred rules there is fine and fast. Budget for the 30–60 days of post-launch monitoring; that’s when you catch the URLs you missed, and catching them quickly is the difference between a blip and a slump. If you generate location or service pages, be especially careful that the URL pattern change is fully mapped, because that’s where the largest number of ranking pages usually lives.
For mid-size companies
At your scale a migration is a program, not a task. You likely have too many URLs for a static list, so the redirect map lives in a database and middleware resolves it per request — which means the map itself needs to be tested, versioned, and monitored like any production data. Stage the migration, validate the redirect map against your full URL export in a lower environment, and plan a phased cutover with rollback. Watch crawl stats and 404 trends daily for the first month. A mishandled migration at your traffic level is a board-level revenue event, so the redirect map deserves the same rigor as any other launch-critical system.
How we run this at Frontend Horizon
We never launch a replatform without a complete, tested redirect map built from the client’s indexed URLs, implemented as permanent redirects, and monitored for at least a month after cutover. It’s the least glamorous part of a rebuild and the part that decides whether the rebuild helped or hurt. If you’re planning a redesign and want to protect the rankings you already have, run a free discovery and we’ll scope the migration properly. Related reading: sitemaps and robots.txt for getting the new URLs crawled fast, and the performance angle on why the new site should also be faster.
