# How to write a redirect decision log before a service website relaunch

A redirect list is easier to maintain when it records why each old page should send visitors to a particular new one. The person making that decision may be thinking about search results, but the visitor could have opened a link from a quote, a supplier directory or a message sent months ago. Before the old website changes, prepare a small log that shows where those visitors should land, what they should find there and who can approve the change. The log gives the design and development teams a shared set of decisions to test.

# Start with links people have already been given

Gather the old website’s page addresses from its menu, sitemap and any link list the business maintains. Ask the sales and support teams to check the public links they routinely send. Include links on printed material if someone can type the address or scan a code to open it. A page can matter even if it is no longer in the menu. Someone may still rely on the steps for preparing a site visit or the explanation attached to an old estimate.

Record the address as a visitor would use it. Keep a separate note for variants that carry a language, location or booking reference in the address. Some parameters can be discarded without changing the page. Others may determine which branch or form opens. Ask the developer to identify those cases before the redirects are written. A list of paths alone may hide a difference that matters to the person following the link.

# Say what the old page let a customer do

For each address, write one sentence explaining the job the page performed. A visitor may have used it to compare two service packages, find the address of a branch or request a repair. Look at the page, rather than guessing from the last part of its address. A page called Support might have changed purpose over time. If its text or a button still leads people to a booking route, the replacement needs to account for that route.

Next, open the proposed destination and check whether someone can complete the same task there. A new services overview may be a poor replacement for a page about a specific maintenance visit if the overview never explains what the visit covers. A different page title can work as long as the needed information or action is easy to find. Put the reason for choosing the destination in the log so someone can recheck it when the page changes again.

# Handle retired services and combined pages explicitly

If a service has been renamed, write down how the new page explains the change. If two pages were merged, check that the new page answers the important questions from both. You may need to add a short section or an obvious link for visitors who arrive with a narrower question. Start with the information they need in the first few moments, rather than copying every paragraph from both pages.

A retired service may have no sensible replacement. Ask the business whether customers still need support, a record of old terms or a way to find the current alternative. A brief explanation may be useful when the business expects repeat visits. Where there is no replacement or relevant information to give, agree on the appropriate missing-page behaviour instead of sending the visitor to a home page that offers no explanation. Record the decision so nobody adds a redirect later merely to remove an error from a report.

# Test the addresses through ordinary customer routes

Ask a colleague to open a sample of the old links on a phone. Start from places the links really appeared, such as a saved estimate or a public profile. Check where the browser ends up and whether it can reach that destination without a chain of unnecessary redirects. Open a link with and without a trailing slash if customers have received both forms. If the business previously used more than one hostname, include the relevant addresses in the test rather than assuming the same rule covers them.

Repeat the test when a person needs a particular branch or language. A destination can load successfully and still be wrong. Note what the visitor first sees, whether the language matches the source and how they would reach the next step. Record the result on the same line as the old address. When a test fails, it should be clear whether the rule chose the wrong destination or the destination itself was missing the expected content.

# Keep the decision and its approval together

A small spreadsheet is usually enough. Give each row an old address, the task it supported, the proposed destination and a short reason. Add the owner, test result and date checked. For uncertain decisions, write down who needs to answer the question. If the team expects a page to remain offline only during a transition, mark that separately so an interim route is not mistaken for the permanent choice.

During a project involving web design services, share the log alongside the proposed page list. Ask for a demonstration using one straightforward redirect, one merged page and one retired service. Seeing those cases side by side helps the team agree who owns the decision when a page has to be rewritten, removed or moved again. Have someone review the rules and the destination content before launch. Each is a different part of the work, and one can be correct while the other still needs attention.

# Use the first week to catch decisions you missed

After launch, ask the staff who handle enquiries to flag reports of old links leading to the wrong information. Check the public routes that were hardest to test before launch. If a customer reaches a replacement page and asks the same question the old page answered, inspect what the replacement actually says before changing the redirect. Sometimes the address is right and the missing piece is a sentence, heading or clearer next step.

Keep the log with the site handover. A new member of staff should be able to tell which old addresses still matter and where a change needs approval. Give the team a regular point to review it alongside page changes. That way the next update can preserve decisions that still make sense and revisit the ones that no longer help customers.

Prepared by Blackstone Intelligence Sarawak. The service examples are illustrative.