Redirects and URL Continuity

Redirects and URL Continuity

The Redirects sheet is a focused project register for URLs that matter to migration acceptance or launch. It helps SEO, content, and technical owners agree on the intended destination, implementation responsibility, observed behavior, and any approved exception without mixing URL evidence into a general task list.

Track the URLs that carry material search, campaign, customer-journey, contractual, or operational value. The Toolkit is not intended to become an exhaustive crawl export when a separate SEO system already owns that dataset.

Record the intended URL behavior first

Field group	Fields	How to use them
Identity	Redirect ID, Related Validation / Decision IDs	Give the URL decision a stable reference and link it to the evidence or approval it supports.
Route	Source URL or Path, Target URL or Path, Content Type	Record the old and intended new location and what content the route represents.
Priority and decision	Priority, Redirect Required?, Intended Behavior / Method	State how important the route is and whether continuity requires a redirect, preserved URL, external routing, or an approved no-redirect decision.
Responsibility	Owner, Environment	Identify who controls the implementation and where it must be verified.
Implementation and test	Implemented?, Tested?, HTTP Status, Final Destination, Chain / Loop, Test Result, Test Date	Record the observable behavior, not only the intended configuration.
Evidence and readiness	Evidence / Exception, Readiness, Notes	Link proof or an approved exception and use the calculated readiness to identify the next action.

Understand Redirect Readiness

The workbook calculates a compact Readiness state:

Condition	Readiness
Redirect Required? = No	Not required
Redirect Required? = To be confirmed	Decision required
Required redirect is implemented, tested, passes, and has no chain or loop	Ready
Test Result = Fail	Blocked
Required work remains incomplete or untested	Pending

Not required still needs a reason when the URL matters

A priority URL can legitimately require no redirect when the URL is preserved or when retirement is explicitly accepted. Link the relevant evidence or Decision ID so the absence of a redirect is intentional rather than unexplained.

Test the source route, not only the destination

A destination page loading successfully does not prove that an old source URL reaches it correctly. For priority redirects, record the source path, observed HTTP behavior, final destination, and whether a chain or loop occurs.

Use Validate Content, URLs, and Redirects for the complete validation procedure and pass conditions.

Resolve a blocked redirect

1. Confirm the intended destination and required method. Make sure the row still represents the approved business requirement.
2. Identify the implementation owner and environment. A target-platform redirect, external routing rule, and preserved URL can have different owners.
3. Correct the route outside the evidence row. Use the appropriate target platform, routing, or migration procedure.
4. Retest from the source URL. Record the status, final destination, chain or loop behavior, test result, date, and evidence.
5. Update the related validation or decision record. A launch blocker should not disappear from the project trail merely because the URL row has been corrected.

Do not hide an exception in Notes

If the project accepts retirement, an alternate destination, or another limitation for a material URL, record the authorization in Decisions & Sign-off and reference the Decision ID from the redirect row.

Next Steps

Record approvals, accepted exceptions, and launch-blocking URL choices in Decisions and sign-off.