Implementation worksheet · 5 min read
How to Test Redirects After Replacing a Generated Website
Build the inventory before you launch, from three sources rather than one: your old sitemap, your analytics top pages for the last twelve months, and Search Console's indexed URLs. Map every old URL to exactly one new URL — or deliberately to a 410 if nothing replaces it. Then test six cases: a mapped URL redirects once with 301 to a 200; a URL with a trailing slash variant behaves the same; a query-string URL keeps or drops parameters as intended; a deliberately retired URL returns 410 rather than redirecting to the homepage; no redirect points at another redirect; and the new URL is the one in your sitemap and canonical tag. Redirecting everything unmapped to the homepage is the mistake that looks tidy and reads to a crawler as a soft 404.
When a generated site replaces an existing one, the new URL structure rarely matches the old. Everything the old site earned is attached to those old URLs, and a redirect map is the only thing that carries it across.
Put it into practice
1. Build the inventory from three sources
Sitemap, analytics (twelve months, so seasonal pages appear), and Search Console's indexed list. Any one source alone will miss URLs that still have links pointing at them.
2. Map one-to-one, or to 410 on purpose
Each old URL gets the single closest replacement. Where nothing replaces it, 410 is the honest answer — it tells crawlers the page is gone rather than making them discover a homepage that does not match the link they followed.
3. Test the status chain, not just the destination
curl with redirect-following off. One hop, 301, landing on a 200. Two hops means the map has a stale entry pointing at a URL that itself moved — common when a migration happens in stages.
4. Test the variants
Trailing slash, uppercase, and query strings. Generated sites often normalise differently from the platform they replace, and each variant is a separate URL with its own history.
5. Re-check after launch, then again in a fortnight
Crawlers revisit old URLs for weeks. A redirect that works on day one and breaks on day ten, because a route was renamed in a follow-up deploy, is a real and common pattern.
Redirect test cases
Copy this structure into your review document and record your observed result for each row.
| Case | Expected | Why it matters | Verified |
|---|---|---|---|
| Mapped URL | 301 once to 200 | preserves the signal | |
| Trailing-slash variant | same destination | separate URL otherwise | |
| Query-string URL | per policy | parameters can split or merge | |
| Retired URL | 410 | honest, not a soft 404 | |
| Chain check | no redirect to redirect | wasted crawl, lost signal | |
| Canonical agreement | new URL in sitemap + canonical | or you contradict yourself |
A failure worth checking
The homepage catch-all: every unmapped old URL 301s to `/`. It looks complete and it is treated as a soft 404, because the destination has nothing to do with the requested page. The pages that earned the links lose them, and the symptom — a slow ranking decline with no error anywhere — is unusually hard to trace back to launch day.
Common questions
How long should redirects stay in place?
At least a year, and indefinitely for URLs that still receive external links. Removing them later re-creates exactly the problem the migration solved.
Is a 410 ever better than a redirect?
Yes — when nothing replaces the page. A redirect to a loosely related page is worse for the user and reads as a soft 404 to a crawler. 410 is a clear statement and resolves faster.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.