Build the Redirect Map Before You Migrate, Not After

When should you build a redirect map for a site migration?

Before the new site is built, not after it launches. The redirect map is a content decision disguised as a technical task. It forces you to decide what each old page becomes, and that decision should shape the new site's structure rather than be retrofitted to whatever structure you happened to build.

Almost every migration I have been brought in to repair had the same sequence. The team designed the new site, built it, launched it, and then somebody asked about redirects. At that point the map is not a plan, it is damage control, and a meaningful number of old URLs end up pointed at the homepage because nobody can remember what they were for.

Pointing an old page at the homepage is the migration equivalent of throwing it away. So this piece covers what actually belongs in the map, which redirect types Google treats as permanent, and the specific reason your old URLs keep showing up in search after you thought the move was done.

What actually goes in a redirect map?

Every indexed URL on the old site, paired with its single best destination on the new one, plus a decision code explaining the pairing. The decision code is the part people skip and the part that makes the map reviewable by someone other than its author six months later.

Build the source list from more than one place. Your CMS knows what pages exist, Search Console knows which ones actually receive impressions, and your server logs know which ones get requested including the ones you forgot. These three lists never match, and the gaps between them are where the interesting URLs live, usually old campaign pages and posts that still earn links.

For each row, the destination should be the closest equivalent page, not the nearest category. Closest equivalent means a page that answers the same question for the same reader. If nothing on the new site does that, the honest options are to build the page, keep the old one, or accept the loss deliberately and record that you did. What you should not do is quietly send it to a category listing and call it a redirect.

Which redirect type should you use?

A permanent server side redirect, in almost every migration case. Google documents that with permanent redirects, Googlebot follows the redirect and the indexing pipeline uses it as a signal that the redirect target should be canonical, and it names HTTP 301 and HTTP 308 as the permanent status codes.

Google also ranks the methods. It presents redirect types ordered by how likely Google is able to interpret them correctly, and states that a server side redirect has the highest chance of being interpreted correctly. Its recommendation is explicit, that when you need to change the URL of a page as it is shown in search results you should use a permanent server side redirect whenever possible.

The temporary codes exist for a genuinely different job. Google lists HTTP 302, 303, and 307 as temporary, and explains that Googlebot follows them but the indexing pipeline does not use them as a canonicalisation signal. Its example is a service that is temporarily unavailable, where you want users informed without compromising the original URL in search results. A migration is not that situation.

Why do so many migrations use the wrong redirect type by accident?

Because the method you choose implies a type you did not think about. Google documents that an instant meta refresh redirect, triggering as soon as the page loads, is interpreted as a permanent redirect, while a delayed meta refresh with any number of seconds is interpreted as a temporary one. A five second delay quietly changes the meaning.

JavaScript redirects carry a different risk. Google states that you should only use them if you cannot do server side or meta refresh redirects, and gives the reason plainly. Google attempts to render every URL Googlebot crawled, but rendering may fail for various reasons, which means a JavaScript redirect might never be seen at all. A redirect that is invisible under failure is not a redirect you want carrying a migration.

Then there is what Google calls a crypto redirect, which is simply a link on the old page pointing to the new one with a short explanation. Google's own description is unusually candid, noting that like the Loch Ness monster its existence may be disputed and not all search engines may recognise it as an official redirect. Its guidance is to contact your hosting provider about other redirect types before resorting to this.

Why are your old URLs still showing in search after the move?

Because Google deliberately keeps both. Google documents that when you redirect a URL it keeps track of both the redirect source and the redirect target. One becomes the canonical and the other becomes what Google calls an alternate name, which is a different version of the canonical that users might recognise and trust more.

Those alternate names can surface. Google states that they may appear in search results when a user's query hints that they might trust the old URL more. If you moved to a new domain, Google says it is very likely to continue occasionally showing the old URLs even though the new ones are already indexed.

Google also says this is normal and that as users get used to the new domain name the alternate names will fade away without you doing anything. I am quoting that at length because it prevents a specific and expensive panic. Three weeks after a domain move, somebody searches the brand, sees an old URL, and concludes the migration failed. It did not. Check whether the new URLs are indexed, and if they are, wait.

How long do you keep redirects in place?

Longer than feels necessary. Google's own guidance on permanent redirects is to use them when you are sure the redirect will not be reverted, which frames them as durable infrastructure rather than a launch task. I treat a redirect as permanent in the ordinary sense of the word and plan never to remove it.

The pressure to clean up comes from maintenance, and it is usually misplaced. A redirect rule costs almost nothing to keep. An inbound link from six years ago that suddenly resolves to a 404 costs you that link's value and a visitor. The asymmetry is stark, and I have never once regretted keeping a redirect too long.

What is worth cleaning is chains. If a migration in 2022 pointed A to B, and this one points B to C, then A now takes two hops. Collapse those so that A points straight to C at the same time as you add the new rules. That is a genuine maintenance job and the only redirect tidying I would prioritise.

What does your platform make easy or hard here?

That depends on the platform, and it is worth checking before you design the map rather than after. Hosted platforms typically provide a redirects interface and may apply their own limits on how many rules you can store, whether wildcards or patterns are supported, and how those rules interact with the CMS. Check your platform's official documentation for current behaviour.

Webflow provides redirect management in site settings, and Google's documentation acknowledges this general pattern, noting that platforms may have built in redirect solutions and suggesting you search for platform specific help articles. Since limits and supported syntax change over time, I would confirm the current rules in Webflow's own documentation rather than trusting any blog post, including this one, on the specifics.

The strategic point survives whatever the platform allows. If your map has three thousand rows and your platform supports pattern matching, you will want to design URL structures that let patterns do most of the work. That is a decision about the new site's information architecture, which is exactly why the map belongs before the build. I covered the surrounding move in more detail in a WordPress to Webflow migration SEO guide.

What is the most common mistake in a redirect map?

Bulk redirecting a whole section to one page. It looks efficient in a spreadsheet and it destroys the thing you were trying to preserve. Forty old posts pointed at a category page tell search engines that none of those pages has an equivalent, and that is exactly what will be concluded.

The second most common is mapping by URL similarity rather than by content. Two URLs can look almost identical and cover completely different topics, particularly on sites where slugs were generated from titles that changed over the years. Match on what the page is about. This is slower and it is the actual work.

The third is forgetting the non page URLs. Feeds, sitemaps, image paths, PDF downloads, and old search or filter URLs all exist, some of them are linked from outside, and none of them will appear in a list of blog posts. Server logs catch these when nothing else does. Once the new site is live, your sitemap becomes the source of truth for what should be indexed, which is worth configuring deliberately, as I covered in controlling what gets indexed in a Webflow sitemap.

What should you do next?

Pull your three source lists before anything else. Export URLs from the CMS, export pages with impressions from Search Console, and pull a month of server logs. Deduplicate them into one column and count the rows. That number is the real size of your migration, and it is usually larger than the sitemap suggested.

Then map the top fifty by impressions by hand, with a decision code on each row, before you let anyone automate the rest. Doing fifty manually teaches you the patterns that make the automation safe, and it surfaces the pages that have no equivalent on the new site while there is still time to build them.

If the migration also involves rewriting content along the way, resist doing both in one step, because you will not be able to tell which change caused which outcome. Move first, measure, then improve, using something like the content refresh workflow I use for old posts. And if you are staring at a migration and would rather have someone check the map before launch than after, reach out and let's chat.