Published September 4, 2026.
Redirects often begin as a casual request to “clean up” a URL. The consequences are less casual: lost links, redirect chains, irrelevant destinations, and reporting confusion. A redirect register makes the proposed mapping and its reason visible before anyone changes production.
Record the source and destination
Capture the full current URL, proposed destination, request reason, owner, traffic or backlink context, and desired timing. Check whether the source is actually live and whether another redirect already exists.
Test intent equivalence
A permanent redirect should lead to a page that satisfies substantially the same reader task. Sending every retired article to the home page hides the removal but does not preserve usefulness.
Check dependencies
Find internal links, sitemap entries, canonicals, campaigns, and external documentation that use the old URL. Plan updates so the redirect is a safety net rather than the site's normal navigation path.
Approve the smallest change
Some requests only need a canonical correction or internal-link update. If the original page remains useful, changing its slug may create work without reader benefit.
Verify the live chain
After release, request the old URL, confirm the expected status and single-hop destination, then check that the destination returns 200 with a self-canonical. Remove the old URL from sitemaps and update owned internal links.
BusinessGrowthAssistant can use this register as part of daily SEO maintenance while protecting established routes. Link it with the publishing rollback readiness routine.
Frequently asked questions
Should deleted pages always redirect?
Only when a genuinely equivalent destination exists. Otherwise an honest not-found or gone response may be clearer.
Are temporary redirects acceptable?
Yes for genuinely temporary moves. Record the review date so they do not become permanent by neglect.
Who approves a slug change?
The accountable SEO or site owner should approve it after impact review.