In short
Build a redirect map by collecting URLs from crawls, sitemaps, CMS, analytics, Search Console, backlinks, and campaigns. Assign each old URL to keep, redirect, merge, or remove; map redirects to the closest intent-equivalent final URL; implement permanent server-side responses; then test status, destination, chains, and loops.
Collect more than the sitemap
Combine URLs from:
- current XML sitemaps;
- a full crawl;
- CMS export;
- analytics landing pages;
- Search Console pages;
- backlink data;
- paid campaigns and email;
- server logs where available;
- previous redirect rules.
Normalize protocol, hostname, trailing slash, case, and parameters carefully. Keep the source columns so valuable URLs missing from the current navigation are not dismissed as duplicates.
Use a working table
Recommended columns:
| Column | Purpose |
|---|---|
| Old URL | Exact requested address |
| Current status | 200, redirect, 404, error |
| Page type | Service, article, product, asset, campaign |
| Intent/topic | What the visitor expects |
| Evidence | Clicks, conversions, backlinks, campaign use |
| Decision | Keep, redirect, merge, remove |
| New URL | Final destination |
| Redirect type | 301 or 308 for permanent moves |
| Reason/owner | Why the mapping exists |
| Test result | Actual response and destination |
Decide page by page
Keep
The address and intent remain correct. This is the lowest-risk outcome.
Redirect
Content has moved to a direct equivalent. Map old to new.
Merge
Several overlapping pages become one stronger resource. Redirect each retired page only if the combined destination satisfies the original intent.
Remove
The content has no value, use, links, or equivalent. Return 404 or 410 intentionally rather than redirecting to an irrelevant page.
Match intent before words
An old “enterprise pricing” page should not redirect to a generic product homepage merely because both mention the product. Ask what the visitor expected and whether the destination completes the same task.
If no relevant replacement exists, create one when the old URL has material value—or remove it honestly.
Remove chains
Previous migrations create rules such as:
/old-service → /services-v2 → /capabilities/service
Update the first rule to point directly to the final URL. Test both the planned map and existing server configuration; a clean spreadsheet can still produce chains after deployment.
Handle patterns carefully
Rule-based redirects are efficient for predictable changes such as a directory rename. Test exceptions, case, encoded characters, query strings, files, language paths, and trailing slashes.
Do not let a broad pattern capture admin routes, assets, APIs, or genuinely removed pages.
Test before and after launch
For every row, validate:
- expected permanent status;
- exact final URL;
- no chain or loop;
- final response is 200 and indexable where intended;
- query behaviour;
- protocol and hostname variants;
- destination intent.
Manually review the highest-value URLs even when the complete set is tested automatically.
Common questions
Should every old URL be redirected?
Every old URL needs a decision, but not every URL needs a redirect. Use 404 or 410 for intentionally removed content without a relevant replacement.
Should deleted pages redirect to the homepage?
No. An unrelated homepage does not satisfy the original request and may be treated as a soft 404. Redirect only to a relevant equivalent.
Should I use 301 or 308 redirects?
Both communicate a permanent move. Choose the status supported consistently by the platform and test request-method behaviour for non-GET endpoints.
How long should redirects stay active?
Keep migration redirects at least a year and preferably indefinitely for URLs that may retain links, bookmarks, or campaign use.
Can I create redirects after launch?
You can correct gaps, but the map should be deployed with the migration. Launching without it creates avoidable broken requests and conflicting search signals.
