A redirect connects an old address to a new destination. It should preserve the expectation of someone opening a saved link, search result or email reference. A technical response alone is insufficient: the destination needs to fit the original purpose.
Plan before renaming or removing pages. Collect existing URLs from the site inventory and add known downloads, campaign pages and important older addresses. A list drawn only from the main menu often misses content still used outside navigation.
Decide what happens to each relevant address
Record the old purpose and intended destination beside each URL. Distinguish unchanged pages, genuine moves, merged content and removed material without an equivalent replacement. These cases should not all receive one blanket rule.
For a genuine move, the task remains broadly the same. A maintenance-conditions page may receive another path while continuing to provide those conditions. For a merger, check that the new content actually includes the useful information from the old pages.
If no relevant replacement exists, an arbitrary redirect is not automatically better than correctly handling a removed page. Someone expecting a particular instruction gains little from a general homepage. Agree the technical treatment with the site maintainer and record the decision.
Establish permanence and implementation
Google's site-move documentation recommends server-side permanent redirects for permanent changes where possible, including HTTP 301 and 308. The configuration depends on the server and publishing system.
Distinguish a permanent move from a temporary situation. A temporarily unavailable offer need not be treated like a permanently merged page. Base the decision on the content plan, not merely on whichever setting is easiest to select.
An HTML file cannot itself configure arbitrary server responses. A static upload may therefore need separate server rules. Establish responsibility and access early so redirects do not emerge as an unfinished task only after the website has been replaced.
Avoid chains and loops
If an address moved previously, another change can create a chain from old to intermediate to new. Where possible, plan a direct route to the final relevant destination. This is easier to inspect and requires fewer intermediate steps.
A loop occurs when rules lead back to the starting address. It can arise through interactions between domain, language and path rules. Test the actual journey with all server behaviour, not only individual entries in isolation.
Consider trailing slashes, capitalization and file extensions where they occur in the existing system. Do not invent an unlimited set of hypothetical variants. Begin with real addresses and known server rules.
Update internal references directly
Point navigation, article links and listings at the final destinations. Redirects remain important for old external references but should not unnecessarily define ordinary navigation within the new site. Update the sitemap and canonical information too.
For multiple languages, preserve both the subject and language where possible. An old German article should lead to its relevant German successor. Sending every language to one homepage loses the original context.
Review links in email templates, PDFs and regularly distributed documents. They cannot always be changed retrospectively, but future versions can be corrected. Record important older sources that cannot be edited so their redirects are not removed casually.
Verify the old route, not only the new page
Test each planned mapping by requesting the old URL. Check the response, intermediate steps and final content. Opening the new destination alone does not establish that the old route works. Include an unmapped path to inspect normal error handling.
Record the configuration version tested. After release, repeat important checks on the actual production address, since local or staging environments may use different rules. Report those scopes separately rather than treating a prepared configuration as a verified live result.
A useful completion record lists the old address, expected destination, observed outcome and unresolved differences. That makes failures actionable. Simply saying all pages moved is too vague when it does not establish whether saved customer links still reach the information they promised.
