Testing 301 redirects after a migration is a bulk job, not a spot-check: you take the complete list of old URLs, request every single one, and verify three things per URL, that it returns a 301, that it lands on the intended new page rather than a catch-all, and that it gets there in one hop. Sampling twenty URLs by hand catches nothing, because redirect failures cluster in the long tail, old blog posts, parameter URLs, image paths, that nobody clicks during launch week. The workflow below runs the full verification in an afternoon with free tools, and it is the same one we run at WPBuildAI on every migration, where the crawl-first inventory doubles as the test list: every URL the pre-migration scan recorded is a test case the post-migration check must pass.
Why redirect testing fails when done casually
The failure pattern repeats across almost every self-managed migration we audit. The team tests the homepage, the top ten pages, and the main nav, everything passes, and the migration is declared healthy. Weeks later, Search Console starts reporting 404s, rankings slide on pages nobody was watching, and the diagnosis reveals the standard trio: a redirect rule that covered pretty URLs but not the parameterized versions Google had indexed, a wildcard that sent hundreds of old posts to the homepage, and image URLs that were never mapped at all. Each of these passes a casual spot-check and fails the site, because Google treats a redirect to an irrelevant page much like a soft 404, and equity flows only through redirects that land somewhere genuinely equivalent.
The root cause is testing against memory instead of inventory: the pages you remember are the pages that were always going to be fine. The test list has to come from data, which is why the pre-migration crawl is the load-bearing artifact of the whole exercise, and why redirects preserve SEO only when their coverage is verified rather than assumed.
Building the test list: every URL that ever mattered
The complete test list merges four sources, deduplicated. The pre-migration crawl of the old site, every page, image, PDF, and asset URL a crawler could reach, which is the list a crawl-first migration produces before anything moves; at WPBuildAI this inventory exists before the rebuild starts, so the test list is a byproduct rather than a reconstruction. Search Console’s indexed and top-performing URLs, because Google’s copy of your site includes URLs your own crawl might miss, parameters, dated archives, legacy structures. Analytics landing pages over the past year, which add the URLs that earn traffic from anywhere, not just search. And the backlink targets from any link tool you use, since a redirect missing on a well-linked URL burns exactly the equity migrations exist to preserve.
If the migration already happened without a pre-crawl, the list is still recoverable: Search Console exports, analytics history, the Wayback Machine’s URL index, and the old sitemap files reconstruct most of it, imperfectly but far better than memory. That reconstruction is tedious enough to be its own argument for the checklist order: inventory first, always.
Running the bulk test, tool by tool
With the list in hand, the mechanics are simple and free. A desktop crawler in list mode, Screaming Frog’s free tier handles 500 URLs, takes your file of old URLs and reports each one’s status code, redirect target, and chain length in one run; for bigger lists, the paid tier or an open-source crawler does the same without the ceiling. For a quick command-line pass, a few lines of curl in a loop produce status and Location headers for every URL in a file, which is often the fastest route for developers and produces a diffable record you can re-run identically next quarter. Whichever tool runs it, export the results and grade every row against three pass conditions: status is 301 exactly, not 302 (temporary, passes equity hesitantly), not 307, not a 200 on a lookalike URL; the final destination equals the mapped target from your redirect plan, not the homepage, not a category page; and the hop count is one, because each additional hop wastes crawl budget and adds failure points, and chains longer than a few hops stop being followed at all.
The grading against the map is the step casual testing skips: a 301 that lands on the wrong page passes every status-code check and still loses the ranking, so the test compares destinations, not just codes. This is why the redirect map, the two-column old-to-new file, is the contract the test enforces.
| Check | Pass | Fail patterns to hunt | Verdict |
|---|---|---|---|
| Status code | 301 on first response | 302/307, 200 on a soft duplicate, 404, 500 | Non-negotiable |
| Destination | Equals the mapped target | Homepage catch-alls, category fallbacks | The quiet ranking killer |
| Hops | Exactly one | Chains via www/https normalization, loops | Flatten before launch |
| Coverage | Every inventory URL tested | Images, PDFs, parameter URLs, archives | Where audits find the losses |
| Speed | Redirect responds fast | Slow rules on an overloaded origin | Check once, then monitor |
The failure classes, and their fixes
Grading the export sorts failures into five fixable classes. Missing redirects, the 404s, get rules added, mapped to their true equivalents; a batch of 404s with no new equivalent is a decision point, redirect to the closest genuinely useful page or let them return a deliberate 410 rather than soft-redirecting everything to the homepage. Wrong-destination redirects, the homepage catch-alls, are the quiet ranking killers and get remapped page by page, priority by traffic. Temporary codes, 302s where 301s belong, are usually a platform default, one config change. Chains get flattened by pointing the first rule directly at the final URL, with special attention to the http-to-https-to-www stacking that turns one redirect into three. And loops or slow responses point at rule ordering and hosting, fixed at the config level, usually in minutes once seen.
Re-run the full list after the fixes, not just the failures, because redirect rules interact and a fix for one class occasionally breaks another. The afternoon this takes is the cheapest insurance in SEO: the same verification bought as ranking recovery six months later costs a quarter and rarely recovers everything.
One worked pass, end to end
A concrete run makes the abstractions land. A 340-URL brochure-and-blog site migrates; the inventory merges 289 crawl URLs, 41 extra Search Console rows (mostly parameterized and dated archives), and 10 backlinked PDFs. The bulk run reports 302 passing 301s, 21 chains, 12 homepage catch-alls, and 5 outright 404s. The chains all trace to https-and-www normalization firing before the migration rules, one config reorder flattens all 21. The catch-alls turn out to be a wildcard covering a retired product line, remapped to the closest surviving category pages in an hour. The 404s split three-and-two: three old event pages with no equivalent get deliberate 410s, two forgotten PDFs get uploaded to the new asset path and mapped. The re-run comes back clean, forty minutes of fixes total, and every one of those 38 failures would have shipped silently under a spot-check, because not one was in the navigation.
Monitoring after the test passes
A clean bulk test on launch week is necessary and not sufficient, because redirect health decays: platforms get reconfigured, rules get edited, and new 404s surface as Google recrawls the long tail. The standing routine is light. Search Console’s indexing report, weekly for the first month then monthly, watching the 404 and soft-404 lists for old URLs that escaped the map, each one a new row for the redirect file the same week it appears. The crawl-stats and page-indexing trends, confirming the new URLs are absorbing the old ones’s status. And a quarterly re-run of the bulk test on the original inventory, ten minutes of tooling, because the file exists and rerunning it is nearly free. Rankings through a well-redirected migration typically wobble and resettle over weeks, the pattern Google’s own site-move guidance describes; redirects left unverified convert the wobble into the new baseline, which is how platform moves cost rankings that the platform never took.
Keep the redirect map and the inventory as permanent site documents, versioned with the site itself, in the repository rather than in a spreadsheet someone owns personally. Every future restructure, and there will be one, starts from the same files, and redirects from the previous migration must survive the next one, chained flat to the newest URLs, for as long as the old links exist in the world, which is effectively forever.
Key takeaways: testing 301 redirects after a migration
Test in bulk against inventory, never by memory: merge the pre-migration crawl, Search Console, analytics, and backlink targets into one list, run every URL through a crawler in list mode or a curl loop, and grade each against three conditions, a true 301, the mapped destination rather than a catch-all, and a single hop. Fix by failure class, missing rules, wrong destinations, temporary codes, chains, then re-run the whole list, and keep Search Console’s 404 report and a quarterly re-test as the standing routine. The pre-migration inventory is the artifact everything depends on, which is why WPBuildAI’s crawl-first process produces the test list before the rebuild begins: verification is a byproduct of doing the migration in the right order.
Quick answers
How do I test 301 redirects after a migration?
In bulk, against a complete inventory: merge your pre-migration crawl, Search Console URLs, analytics landing pages, and backlink targets into one list of old URLs, run every one through a crawler in list mode (Screaming Frog’s free tier covers 500) or a curl loop, and grade each row on three conditions, status exactly 301, final destination matching your redirect map rather than a homepage catch-all, and one hop only. Fix by failure class and re-run the whole list. At WPBuildAI the crawl-first inventory doubles as this test list on every migration.
How many redirects should I actually test?
All of them, which is the point of doing it in bulk: failures cluster in the long tail of old posts, parameter URLs, images, and PDFs that no spot-check visits, and a twenty-URL sample tests only the pages that were never at risk. A full list run costs the same afternoon whether the site has two hundred URLs or ten thousand, because the tooling does the visiting. The scarce ingredient is the inventory itself, which is why building it before the migration is the step that decides the quality of everything after.
Is a redirect to the homepage good enough for old pages?
No: Google treats redirects to irrelevant pages much like soft 404s, so a homepage catch-all preserves neither the ranking nor the visitor’s intent, and it hides the failure from status-code checks because everything returns a healthy 301. Map each old URL to its genuinely closest equivalent, and where none exists, prefer an honest 410 or a redirect to the most useful related page over a blanket rule. The wrong-destination class is the quietest ranking killer in post-migration audits precisely because it looks green in every casual test.
What about redirect chains, do a few hops matter?
They matter more than they look: each hop spends crawl budget, adds latency and a failure point, and chains beyond a few hops stop being followed, so equity leaks at every link. The classic accidental chain is protocol and host normalization stacking, http to https to www to the new URL, three hops before your actual rule fires. Flatten by pointing the first redirect directly at the final destination, and re-test, because chain fixes are config-level changes that occasionally reorder other rules.
When should I stop maintaining old redirects?
Practically never, as long as the old URLs have links, bookmarks, or index presence anywhere: redirects are cheap to keep and expensive to drop, since removing one resurrects a 404 on every legacy link that still points at it. Keep the redirect map versioned with the site, flatten it through each future restructure so old URLs always reach the current pages in one hop, and let the quarterly re-test confirm the file still matches reality. Redirect maintenance is a permanent, tiny line item, and treating it that way is what makes migrations cumulative rather than lossy.
