Redirect mapping is where most website migrations fail. Not the design. Not the build. Not the CMS setup. The redirects.
A website that has been live for years has accumulated search equity across hundreds or thousands of URLs. Every page that ranks, every URL that other sites link to, every PDF that shows up in search results. That equity is real. It took years to build. And a poorly planned migration can erase it in a single deployment.
We have seen it happen. A company launches a beautifully redesigned site, and within two weeks, organic traffic drops by 40%. The culprit is almost never the new design. It is the redirect map that nobody treated as a priority.
Why do redirects matter during a migration?
Every URL on your current site that receives traffic or has backlinks pointing to it carries what Google calls “ranking signals.” When that URL stops working, those signals have nowhere to go. Google has to re-evaluate the entire site, and there is no guarantee it will reach the same conclusions.
A 301 redirect tells search engines that a page has permanently moved to a new location. The good news: Google has confirmed that 301, 302, and other server-side redirects do not cause a loss in PageRank. The equity transfers. But only if the redirect is in place. A missing redirect means Google hits a 404, and that equity is gone.
This is not theoretical. Every migration we run through the Essential Launch Framework includes a redirect strategy as part of Phase 1, before any design or development work begins. We treat it as a first-class deliverable, not a last-minute checklist item.
What does a proper redirect strategy look like?
A proper redirect strategy is systematic. Here is how we approach it, step by step.
Step 1: Crawl the existing site. Use a tool like Screaming Frog, Sitebulb, or Ahrefs Site Audit to crawl every URL on the current site. Not just the pages in the navigation. Every URL. That includes blog posts, landing pages, PDFs, images, paginated archive pages, and any URL that returns a 200 status code.
Step 2: Identify URLs with value. Not every URL needs a redirect. Pull data from Google Search Console and your analytics platform to find URLs that have impressions, clicks, or backlinks. These are the ones that carry equity. Prioritize them.
Step 3: Map old URLs to new URLs one-to-one. This is the tedious part, and it is the part that matters most. Every high-value URL on the old site needs a corresponding URL on the new site. If the content exists on the new site, map to it directly. If the content has been merged into another page, map to that page. If the content has been removed entirely, map to the closest relevant page.
Step 4: Handle structural changes. Migrations often involve URL structure changes. Maybe /blog/my-post becomes /articles/my-post. Maybe /services/web-design becomes /services/website-design. Document every pattern change and create rules that handle them systematically, not one URL at a time.
Step 5: Implement 301 redirects server-side. Client-side redirects (JavaScript redirects, meta refresh tags) are unreliable for SEO. Implement all redirects at the server level. In Astro, Netlify, or Vercel, this means configuration files or middleware. In traditional setups, it means .htaccess or server config rules.
Step 6: Test before launch. Run the full crawl list against the new site and verify that every redirect resolves correctly. Automated testing is essential here. Manually checking hundreds of redirects is how things get missed.
What are the most common redirect mistakes?
After running multiple migrations, we see the same mistakes repeatedly.
Blanket redirects to the homepage. This is the most common and most damaging mistake. Redirecting every old URL to the new homepage tells Google that all of your content has been replaced by a single page. Google treats mass homepage redirects as soft 404s. The equity does not transfer.
Redirect chains. A redirects to B, B redirects to C, C redirects to D. Google can follow up to 10 hops in a redirect chain, but recommends direct redirects. Every hop adds latency and reduces the reliability of the signal transfer. Always redirect from A directly to D.
Forgetting query parameters. If your old site uses URLs like /products?category=shoes, those URLs may have traffic and backlinks. Your redirect rules need to handle query parameters, not just the base path.
Not handling trailing slashes. /about and /about/ are technically different URLs. If your old site used trailing slashes and your new site does not (or vice versa), you need redirects for both variants.
Ignoring non-HTML assets. PDFs, images, and downloadable files can have significant backlink profiles. If your old site hosts a whitepaper at /downloads/report-2024.pdf and other sites link to it, that URL needs a redirect too.
Removing redirects too early. This is where patience matters. We will cover timing in the next section.
How long should redirects stay in place?
Google’s official recommendation is clear: retain control of your old site domain for at least 180 days. This applies to domain changes, but the principle extends to URL structure changes within the same domain.
In practice, keep redirects permanently. The cost of maintaining a redirect rule is negligible. A few kilobytes of configuration. The risk of removing redirects is real. There is no way to know for certain that every backlink has been updated, that every crawler has processed the change, or that some niche directory still points to the old URL.
According to SEMrush’s migration research, medium-sized websites take a few weeks for most pages to move in the index. Larger sites can take three to six months. But “moved in the index” does not mean “safe to remove redirects.” External backlinks do not update themselves. They persist for years.
The only scenario where removing a redirect makes sense is when the old URL pattern conflicts with new functionality. Even then, weigh the trade-off carefully.
What should you monitor after launch?
The redirect strategy does not end at deployment. Post-launch monitoring is what separates a successful migration from one that looks successful for two weeks and then falls apart.
Google Search Console indexing report. Watch for pages that drop out of the index or show “Page with redirect” errors. The Coverage report (now called Pages) will show you exactly which URLs Google is having trouble with.
Crawl errors. Set up monitoring for 404 responses on your new site. Any spike in 404s after launch likely means a redirect was missed. Catch it early, before Google removes the page from the index entirely.
404 spike detection. Use your server logs or a monitoring tool to track 404 response rates. A healthy migration shows a brief spike that quickly drops. A sustained increase in 404s means your redirect map has gaps.
Organic traffic benchmarks. Compare organic traffic week-over-week and month-over-month against pre-migration baselines. A temporary dip of 10-20% is normal during the transition period. A sustained drop of 30% or more signals a problem with redirects, indexing, or both.
Backlink monitoring. Use Ahrefs or SEMrush to check that your most valuable backlinks are still resolving correctly through the redirects. If a high-authority backlink is hitting a 404, fix the redirect immediately.
The redirect strategy is part of the migration strategy
Redirects are not a technical detail to figure out the week before launch. They are a core part of the migration strategy that should be planned, documented, and tested from the very beginning of the project.
At Essential Code, redirect mapping is a deliverable in Phase 1 of every migration we run. By the time we start building, the redirect strategy is already approved. By the time we launch, it has been tested against the full URL inventory.
If you are planning a migration and have not started thinking about redirects yet, the first step is understanding what you are working with. A Headless Audit maps your current site, identifies the technical and content challenges, and gives you a clear picture of the migration scope, including the redirect work. That is the right starting point before committing to a full migration.