Last updated: October 28, 2026
Automating redirect mapping after a site migration means turning an old URL inventory into a draft set of 301 redirects, then validating that each old URL lands on the right destination and does not create new 404 errors. According to Google Search Central, redirects should send users and crawlers to the most relevant equivalent page, and the workflow is most useful when a site has hundreds or thousands of URLs and the migration team needs a repeatable redirect mapping workflow instead of a manual spreadsheet grind. See: Google Search Central on site moves, Ahrefs on 301 redirects, and Screaming Frog on redirects.
Build the old URL inventory first
Start with a complete old URL inventory, because the automation can only map what it can see. Export crawl data from a pre-migration crawl, pull URL lists from analytics landing pages, and add any XML sitemaps, internal link exports, and server logs you can access. A clean inventory usually begins in a CSV with one URL per row and a second column for status codes or page type.
The goal is not a perfect archive. The goal is a working list of legacy URLs that deserve a decision: keep, redirect, retire, or consolidate. If the inventory is thin, the redirect map will miss orphaned pages, PDF files, and parameterized URLs that still send traffic. If it is bloated, you will waste time mapping junk URLs with no value.
A practical first pass is to normalize the list before matching. Strip session parameters, lowercase hostnames where appropriate, remove duplicate slash variants, and separate http from https if your site history includes both. That step matters because the same page can appear in three forms and should usually map to one canonical destination. A single stable source row is usually enough for one legacy URL, rather than three copies of the same row.
You should see a deduplicated file where each old URL appears once and obvious variants have been grouped. If you cannot reduce the list at all, the source data still needs cleanup before automation will help.
What should the redirect map match to?
The redirect map should match each old URL to the closest equivalent destination, usually the same topic, same intent, or same product path on the new site. That is the heart of the workflow, and it is also where automation is strongest and weakest at the same time.
Automation is good at pattern matches. It can replace /blog/2019/ with /resources/, map old category slugs to new category slugs from a lookup table, or send retired product pages to the nearest live product. It is weak at judgment calls, such as whether two thin pages should be merged into one better page or whether a discontinued article should point to a hub page instead of a sibling article.
A useful model is a three-column mapping sheet: old URL, proposed destination, and rule type. Rule type can be exact match, pattern match, lookup match, or manual review. That last column keeps the automation honest. If every row is forced into a rule, bad matches will slip into production and turn into hard-to-find migration errors.
For large migrations, I prefer a mapping logic that starts with exact matches, then applies pattern rules, then fills the remainder with manual review. Because of that order, broad rules are less likely to swallow URLs that deserve a specific destination; still, consult a professional or review the mapping carefully, and see Google Search Central’s site move guidance. For example, if /products/widget-a changed to /shop/widget-a, an exact rule should win over a generic /products/ to /shop/ rewrite.
A good output here is a draft URL map with most rows assigned and a smaller queue of unresolved URLs. If the unresolved queue is huge, the destination taxonomy changed too much and the mapping rules need to be rewritten, not just extended.
How do you automate redirect mapping after site migrations?
You automate redirect mapping after site migrations by combining crawl data, URL pattern rules, and a destination lookup table, then generating a draft redirect file for QA. The process works best when the site structure is regular and the team can define repeatable rules in 10 to 20 patterns instead of one-off decisions for every URL.
-
Export the old URL inventory into a CSV. Use one column for the source URL and one for page type, traffic, or priority if you have it. When this works, the file has one row per legacy URL and no obvious duplicates from trailing slashes or case variants.
-
Build a destination table from the new site. Crawl the new site and export live URLs, titles, templates, or slug fields into a second CSV. When this works, you have a lookup list of valid destinations instead of guessing from memory.
-
Create rule-based matches for obvious patterns. Map old folder paths to new folder paths, such as
/resources/to/guides/, or old product slugs to new product slugs using a formula, regex, or no-code automation tool. When this works, a large block of URLs fills in automatically and the same rule explains each match. -
Add exact-match and lookup logic for special cases. Use a join on slug, page ID, or article title where the structure is stable but the path changed. When this works, renamed pages land on the intended destination instead of a generic category page.
-
Flag low-confidence rows for manual review. Any URL with no match, multiple matches, or a weak semantic match should move to a review queue. When this works, the draft map clearly separates machine decisions from human decisions.
-
Export a redirect file in the format your platform accepts. Most teams use CSV, .htaccess rules, Nginx rewrite rules, or a CMS import template. When this works, the file can be loaded or deployed without reformatting every line by hand.
The trade-off is simple: the more automation you want, the more consistent your URL structure has to be. If the old and new sites use wildly different taxonomies, automation still helps, but it will only draft part of the map. In that case, the workflow saves hours, not all of them.
Use crawl data to catch the URLs humans miss
Use crawl data to catch the URLs humans miss, because redirect mapping fails fastest on pages nobody remembers until launch day. A crawl of the old site and a crawl of the new site should both feed the mapping workflow, and the delta between them is often where the surprises live.
The old crawl shows pages that need a destination. The new crawl shows what actually exists and what is live enough to receive traffic. If a row in the old inventory has no equivalent in the new crawl, that is a decision point, not a technical error. It may need a redirect to a parent page, a merged article, or a 404 if the page truly should not return.
This is also where canonicalization matters. If the old site exposed multiple URL variants for one page, the crawl may show duplicates that should not each get their own redirect. One old product page with five parameter variants should normally collapse to one canonical destination, not fan out into five different redirects. That keeps the map smaller and lowers the chance of redirect chains.
A useful validation rule is to compare source counts and destination counts by folder. If 400 old blog URLs map to 12 new guide pages, that can be right, but it deserves a closer look. Big many-to-one merges are where teams accidentally send users to the wrong hub page because the destination list looked “close enough.”
If this step works, the crawl data will surface unmatched URLs, duplicates, and odd parameter patterns before launch. If it does not, the redirect map will look complete on paper and still leak traffic into 404s after release.
Validate the redirect map before launch
Validate the redirect map before launch by checking that every old URL returns a 301 redirect to the intended destination and that the destination returns a 200 status code. That is the minimum technical test, and it should happen before DNS flips or the new site goes live.
A practical QA pass uses three layers. First, spot-check a sample of priority URLs by hand in a browser or terminal. Second, run a bulk check on the redirect file itself to confirm that the source URLs are unique and the destinations are live. Third, crawl the mapped URLs in a staging or prelaunch environment and watch for chains, loops, and accidental 404s.
The specific signs of success are easy to spot. A valid old URL should respond with 301, not 302. It should point directly to the destination, not bounce through an intermediate URL. The final landing page should be the content you expect, not a soft 404 or a generic home page that hides the missing page.
A redirect QA script or crawler should also confirm that the destination is indexable if it is meant to rank, and blocked if it is intentionally non-indexable. That matters because a redirect map can be technically correct and still send search equity into a page blocked by robots rules or stripped of important content.
One honest limitation: this validation catches technical errors more easily than business errors. It can verify that the redirect reaches the intended page, but it cannot prove the destination is the best editorial or commercial match. That judgment still needs a human pass for high-value pages.
What should you check after migration day?
You should check post-launch 404s, redirect chains, and landing-page matches within the first 24 to 72 hours after migration day. That window is where the mistakes show up fast, before search engines and users spend too long on broken paths.
Start by reviewing server logs or analytics for requests to old URLs that still end in 404 errors. Those URLs are the highest-priority fixes because they prove real users or crawlers are still hitting dead paths. Next, sort them by volume and source. A single typo in a navigation item can create a flood of misses, while an old PDF might matter only to a small but valuable audience.
Then run a crawl of the live site and inspect redirect chains. If one old URL redirects to another old URL and then to the final page, the chain should be collapsed. A two-hop chain is often tolerated by browsers, but it adds delay and creates fragile points in a migration. The clean version is one source, one 301, one destination.
You should also confirm that key templates still point to the right destinations. Menu links, footer links, and XML sitemap entries can expose stale paths even when the redirect map itself is correct. If those internal links keep pointing at redirecting URLs, crawl budget and user time both get wasted.
A good result here is a short exception list with clear fixes: add a missing redirect, replace an internal link, or correct a destination URL. If the exception list keeps growing after each crawl, the map was not reviewed against live behavior, and the migration QA process needs a tighter loop.
What automation gets wrong if you skip human review
Automation gets the biggest things wrong when you use it without a rule for exceptions. The most common failure is a destination that is technically related but commercially wrong, such as sending a discontinued service page to a generic services index instead of the nearest matching service page.
The second failure is over-redirecting. A team can be tempted to map every old URL to some live page just to avoid 404s, but that can erase useful signals and frustrate users. A low-value vanity page may deserve a 404 or 410 if there is no sensible replacement. Not every dead URL needs a forced home-page redirect.
The third failure is maintaining a map that nobody can audit. If rules are buried in a spreadsheet formula, a CMS import, and a separate automation tool, the team may not know why a URL landed where it did. The fix is to keep the logic visible in named rule groups, with a review status on every row. That makes migration QA possible during launch week and during the next site change.
This is also the point where a structured automation workflow earns its keep. It belongs inside a broader technical SEO process, not as a one-off spreadsheet trick. If the site will migrate again in 6 months or the content team keeps changing URL structures, the redirect mapping workflow becomes reusable infrastructure instead of emergency cleanup.
Key Takeaways
- Start with a deduplicated old URL list; automation cannot repair a bad source file.
- Match by pattern first, then by exact lookup, and send uncertain rows to manual review.
- Use crawl data on both sites so missing pages and duplicate variants show up early.
- Validate 301 status, final destination, and redirect chains before launch.
- After go-live, check 404s and stale internal links within the first few days.
- Automation saves the most time on structured sites; it is weaker when every URL is an exception.
FAQ
How do you create redirect maps automatically?
You create redirect maps automatically by combining a source URL inventory, a live destination list, and a set of mapping rules that can be applied in bulk. Exact matches, slug lookups, and path replacements handle most of the work. The remaining URLs need human review before export, especially when old and new site structures do not align cleanly. For implementation details, see Google Search Central and Screaming Frog’s redirect guide.
What is the workflow for migration redirects?
The workflow for migration redirects is source inventory first, rule-based mapping second, QA third, and post-launch monitoring last. That order keeps the map grounded in real URLs and makes it easier to spot bad destination choices. For larger migrations, a CSV-based process with a manual exception queue is safer than fully automatic bulk redirects.
How do you check redirects after a migration?
You check redirects after a migration by crawling the old URLs, confirming each one returns a 301, and checking that the final destination is live and relevant. Then review 404 logs and redirect chains during the first 24 to 72 hours. If important URLs still fail, fix the redirect map before the errors spread.
Drafted with AI; not yet reviewed by a person.