A redirect to another domain can be intentional, for example during a website move. Before release, establish who controls the destination and what content it serves.
List destination hosts separately
Fictional example: an imported redirect spreadsheet contains an old agency test host among many entries for the new main domain. Without a host summary, that single outlier is easy to miss.
Group destinations by host and protocol. Check each different domain against the agreed migration plan. A responding host does not prove ownership or responsibility.
Inspect public destinations without sending real form content or credentials. Form endpoints need a separate review because some redirect statuses preserve the method and submitted data.
Confirm that content, language and purpose match the old page. Follow subsequent redirects too: a correct initial host may lead to another domain on the next step.
If the application accepts return destinations from parameters, it needs server-side restrictions on allowed targets. A link displaying the site’s own brand is not evidence that its destination is approved.
Record confirmed responsibility and purpose for external targets. Keep unresolved rows out of the import. A short list of open cases is more useful than claiming “All redirects work” based only on successful network responses.
Related check: Prioritise a redirect mapping.
If hosts and redirect layers are unclear, the Technology and stack review offers a defined assessment of the technical structure.