Motta Industries Blog

A redesigned website can look excellent while sending returning customers to missing pages. An old service link in a customer’s saved email, a product address shared by a supplier, or a search result pointing to yesterday’s page still needs somewhere sensible to go.

That is the job of a redirect map. It records what should happen to each important old address when the new site launches. For an owner, it is also an accountability document: you can review the decisions before launch instead of discovering them through complaints afterward.

No redirect plan can promise unchanged rankings. A redesign may alter content, navigation, and customer behavior as well as addresses. The practical goal is to manage those changes deliberately, preserve useful journeys, and make problems easier to diagnose.

Decide whether the addresses need to change

A new visual design does not automatically require a new address for every page. Before approving new URLs, ask which changes are necessary and what each one improves for customers or staff.

Google’s explanation of site moves distinguishes changes to underlying infrastructure from moves that change visible URLs. That distinction is useful even when your project is called a redesign rather than a migration. A hosting change and a complete address restructure are not the same job.

Have the developer list proposed address changes early. Renaming a service, combining two sections, moving to a different domain, or replacing an old store can create different mapping decisions. Do not leave those decisions until someone is preparing the launch checklist.

For your website redesign, treat address planning as part of scope. Ask who creates the inventory, who approves destinations, who implements the rules, and who tests the results. “Redirects included” should describe real work rather than an assumption nobody owns.

Preserve useful addresses where practical

If an existing page still serves the same purpose, retaining its address may be the simplest option. Do not rename it merely to make the project feel new. Where an address must change, record the reason so the next person maintaining the site understands the decision.

Build an inventory that goes beyond the menu

Start with the pages and files currently available on the site. Then compare that list with information from search reporting, analytics, existing sitemaps, and links your team uses in everyday work. Ask your developer to explain what each inventory source might miss.

Include documents, campaign landing pages, old product addresses, and pages reached through email templates. A page missing from the main menu is not necessarily unused or unimportant. Your office staff may know about a frequently shared link that a design review never encounters.

Do not treat every address as equally urgent. Mark pages that support inquiries, sales, customer instructions, or other essential tasks. Use available evidence to prioritize, while keeping the full inventory for decisions and testing.

Record the exact old address rather than an abbreviated label. Small differences can matter to implementation. Have the developer review variants involving the hostname, protocol, trailing slash, and relevant query parameters instead of assuming that a row labeled “services” covers every request.

Keep a copy of the inventory before editing it. You need a record of what existed, not a spreadsheet that gradually forgets the pages nobody has decided how to handle.

Give every important address a decision

A useful map can be a plain spreadsheet. Include the old address, current purpose, proposed new address, planned action, reason, priority, approver, and test result. Add notes for unresolved questions rather than making a guessed destination look final.

The main decisions are straightforward: keep the address, move equivalent content, combine it into a relevant page, or retire content that no longer belongs on the site. The difficult part is judging whether a destination really satisfies the original visitor’s need.

Google’s dated guidance on moving a site recommends page-to-page redirects and warns against sending everything to the new homepage. It also recommends similar content where a direct match does not exist. That is a useful owner-level review test, not just a server configuration instruction.

If someone follows an old repair-service link, a broad homepage may leave them starting over. A new page explaining the same repair is a more defensible destination. If you no longer offer that repair, do not disguise the change by sending them to an unrelated service.

Separate retirement from replacement

Ask how genuinely removed material will be handled. A helpful missing-page experience can explain the situation and offer relevant navigation, while the server returns an appropriate status. Your developer should justify that choice rather than treating every missing address as something to conceal.

Understand the rule without writing it yourself

A redirect tells a requesting browser or other client to use another address. In a permanent move, ask the developer which response is appropriate and why. You do not need to approve unfamiliar code, but you should understand the intended behavior.

The HTTP Semantics standard, RFC 9110, defines 301 as Moved Permanently and 308 as Permanent Redirect. It also distinguishes how these responses handle request methods. That matters when a route does more than display a page, such as receiving a form submission.

Have the developer inspect forms, checkout actions, integrations, and other functional endpoints separately from ordinary page visits. Do not apply a broad rule to them solely because it worked when someone clicked a link in a browser.

Keep the map independent of the implementation. The spreadsheet says what should happen; the server or application configuration makes it happen. If the hosting setup changes later, the business decisions should still be available in a readable form.

Ask whether a proposed rule is exact or pattern-based. A pattern can simplify a large move, but it needs representative tests and exceptions. Have the developer demonstrate both a matching address and one that should not match before you accept it.

Test the destination, not just the jump

A redirect can lead to a page that is missing, blocked, irrelevant, or unable to complete the intended task. Test the full journey from the original address through to the final destination and the customer’s next action.

For each important row, record the response at the old address, the final address reached, and whether the destination works. Check the content and purpose as well as the technical response. An automated report can show movement without deciding whether it makes sense.

Look for chains and loops. A chain sends the visitor through intermediate addresses; a loop fails to reach a usable destination. Ask the developer to simplify avoidable intermediate steps and explain any that must remain.

Check links from your new site’s navigation and content. Update them to the intended new destinations rather than deliberately relying on old addresses and redirects. Review email templates, downloadable documents, and staff instructions under your control as separate items in the launch plan.

This is where user experience review belongs beside technical testing. Can a returning customer recognize the destination? Does it answer the question implied by the old link? Can they continue without searching the whole website again?

Review the awkward rows together

Set aside time with the people who understand your content for a review of uncertain destinations. A developer may know how to implement a rule without knowing whether two services are genuinely interchangeable. An owner or department lead needs to answer that business question.

For a discontinued product, consider what an existing buyer may still need: instructions, compatibility information, or a support route. Do not choose a replacement solely because its price or photograph looks similar. If the old page contains useful support material, decide explicitly whether that information should remain available.

For downloadable documents, ask whether the replacement contains the same instructions and whether the links within it still work. Review important brochures, specifications, and forms as documents, not just addresses ending in a particular file extension.

For addresses with query parameters, ask which values affect the content or customer task and which are simply tracking details. Have the developer define the handling, then test representative cases. Avoid putting private customer details into a shared mapping spreadsheet when a safe fictional example will do.

Keep an unresolved category until someone can make the decision responsibly. A blank test result is a question to answer, not permission to launch an arbitrary destination. Give each open row a named reviewer and a deadline for review.

Make launch approval evidence-based

Before launch, ask for a test report tied to the redirect map. You should be able to see which rows passed, which remain unresolved, and who has accepted any deliberate exceptions.

Test the proposed rules in an appropriate preview environment where possible. Then repeat essential checks on the live addresses after launch, because the final domain, hosting, and application configuration may differ from the preview setup.

Agree on a launch window and a rollback decision process. Who watches the important customer journeys? Who can approve a correction? What evidence would cause the team to pause or reverse a change? Keep these responsibilities understandable to the owner who must make the decision.

Avoid launching several unrelated changes without documenting them. If you are also rewriting service content, changing the domain, and replacing your store, record those changes separately. Otherwise, a later traffic change becomes harder to investigate because several explanations fit the same date.

Plan monitoring before the celebration

Choose what the team will review after launch: important old addresses, error reports, search visibility, customer inquiries, and key sales or service journeys. Set review points and assign someone to investigate exceptions rather than assuming that silence means success.

Keep the redirect configuration under active ownership. A later hosting move, plugin change, or cleanup should not remove it accidentally. Ask how the rules will be documented, backed up, and checked when the infrastructure changes.

Do not choose a retention period by guessing what will be sufficient for search engines. Review the requirements of the move, ongoing visits to old addresses, and applicable current guidance with your developer. Important saved links and external references may remain relevant long after launch week.

Keep a short change log

Record when a mapping decision changes and why. If a destination is later retired, revisit the older addresses pointing to it. A redirect map is easier to maintain when it remains connected to the content decisions it represents.

Use the map to make a better redesign brief

Before commissioning custom website design, bring the developer a list of the pages customers rely on and the addresses your team shares most often. Ask them to explain how those journeys will survive the redesign.

You do not need to review every technical rule personally. You do need visibility into the important decisions, unresolved exceptions, testing evidence, and maintenance responsibility. A readable redirect map gives you that visibility before a new design replaces the old site.