A Redirect Audit Checklist for After a Website Migration

A website migration can leave old URLs pointing to the wrong pages, passing through unnecessary redirects, or returning errors unexpectedly. Use this website migration redirect audit checklist after launch to test important URLs, review destination quality, and catch related issues in internal links, canonical tags, and sitemaps.

Key Takeaways

• Check that each important old URL reaches its intended new page—not merely that it redirects somewhere.
• Prefer a direct redirect to the final destination; investigate chains, loops, and irrelevant targets.
• Update internal links, canonical URLs, and sitemap entries to use the new URLs directly.
• Keep genuine removals as intentional 404 or 410 responses rather than redirecting them to unrelated pages.
• Prioritize high-value URLs, document findings, and treat the audit as quality control—not a guarantee of preserved rankings.

1. Prepare a URL list and expected outcomes

Start with the migration mapping: each old URL should have an expected destination or a documented reason it is being removed. Build the audit list from sources such as the old sitemap, analytics landing pages, search performance reports, backlink data, and important pages in your content inventory.

Prioritize URLs that receive traffic, have valuable external links, generate leads or sales, or represent key sections of the site. Include a sample of less prominent URLs too; high-value sampling helps prioritize work but does not prove every URL is correct.

Record at least these fields:

Preserve relevant URL details when comparing entries, including trailing slashes, capitalization, and query parameters. Decide how tracking parameters should behave; do not assume every parameter should be retained or discarded.

2. Test old URLs and inspect the redirect path

For each priority URL, request the old address and compare the observed result with the planned outcome. Check that the response leads to the intended, relevant page and that the final destination loads. A redirect response alone is not a pass if it points to the wrong content, an error page, or an unrelated homepage.

Use the TidyURLs Redirect Checker to inspect redirect behavior for URLs you are auditing. Review the observed status and destination, then confirm the final page itself is available. Do not assume the checker supports bulk imports, exports, or a particular reporting feature; if you have many URLs, use a workflow you can verify and keep the results in your audit log.

Look for:

• Missing redirects: an old URL returns an unexpected 404 or 5xx instead of its planned destination.
• Wrong destinations: the URL redirects to a page that does not serve the old page's purpose.
• Redirect chains: an old URL passes through one or more intermediate URLs before reaching the final page. Update the mapping or rules so it can redirect directly where practical.
• Redirect loops: URLs send requests back around without reaching a page.
• Unexpected temporary redirects: verify the configured redirect behavior matches whether the move is intended to be permanent or temporary. A permanent move commonly uses 301 or 308; temporary handling may be appropriate for a genuinely temporary change.
• Destination problems: the final URL has an error response, redirects again unexpectedly, or resolves to content that should not be the destination.

3. Check internal links, canonicals, and sitemaps

Redirects are a fallback for old links, not a substitute for updating the new site. Review important templates and pages as well as a sample of the whole site.

Internal links

Find links on the migrated site that still point to old URLs or redirecting URLs. Update them to point directly to the intended new pages. Check navigation, breadcrumbs, footer links, related-content modules, and high-traffic pages. This reduces avoidable redirect hops for visitors and crawlers and makes the new URL structure consistent.

Canonical URLs

Inspect the canonical URL on representative page types and on priority pages. Confirm it points to the intended, accessible new URL, uses the preferred hostname and protocol, and does not point back to an old URL or an unintended redirect. Canonical tags are signals about preferred URLs; they do not replace redirect rules or guarantee how a search engine will index a page.

XML sitemaps

Check that submitted sitemaps contain the intended new URLs, not old URLs that redirect. Confirm that listed pages are accessible and are the versions you intend search engines to discover. Remove entries for URLs that are intentionally gone, and avoid treating a sitemap as a complete redirect map.

4. Handle pages that should be removed

Not every old URL needs a replacement. If a page has been deliberately removed and there is no genuinely equivalent page, document that decision and confirm the old URL returns the intended error response, usually 404 (Not Found) or 410 (Gone). Do not redirect every deleted URL to the homepage or a broad category page simply to avoid errors; that can mislead visitors and obscure which content is actually available.

If a useful replacement exists, redirect the old URL directly to that relevant page. Make the choice based on the content and user need, not just on the fact that both pages belong to the same site.

5. Prioritize checks and track fixes

A practical post-launch audit can start with a prioritized sample, but sample size alone cannot establish that every URL is correct. Check all critical URLs where feasible, and expand coverage if you find a pattern such as a broken rule affecting an entire directory or URL type.

For each issue, record the old URL, expected outcome, actual status and destination, severity, assigned owner, fix, and retest result. Group related findings by likely cause—for example, a hostname rule, a missing path mapping, or an outdated internal-link template. Retest affected examples after deployment, then check whether the same rule could affect other URLs.

Common Mistakes

• Checking only whether a redirect exists. Verify that it reaches the correct, working destination.
• Ignoring intermediate hops. A successful final page can still be reached through an unnecessary chain.
• Redirecting deleted pages indiscriminately. Use a relevant replacement when one exists; otherwise, an intentional 404 or 410 may be appropriate.
• Leaving the new site dependent on old URLs. Update internal links, canonicals, and sitemap entries instead of relying on redirects indefinitely.
• Treating a sample as proof of complete coverage. Prioritize useful pages, then investigate patterns and expand testing where needed.
• Expecting the checklist to preserve rankings. A careful audit can catch implementation problems, but rankings depend on many factors and cannot be guaranteed by redirect checks.

Best Practices

• Keep the old-to-new URL map as the audit's source of truth and document intentional removals.
• Test destinations for relevance and availability, not just response status.
• Prefer direct redirects to final destinations and update internal references to those destinations.
• Check representative page types and URL patterns, including important query-string variants where they matter to the site.
• Save findings and retest fixes so the team can see what was checked and what remains unresolved.

Conclusion

A useful migration redirect audit compares planned outcomes with what visitors actually reach, then checks the new site's links, canonicals, and sitemap for consistency. Prioritize important URLs, record and retest issues, and treat the process as risk reduction—not a promise of unchanged search rankings.