Changing Website URLs? Prepare a Redirect Mapping Sheet First

Conceptual illustration of matching old URLs to relevant new destinations.

Illustration of reviewing an exception before website migration.

Conceptual illustration of a direct redirect to the final destination.

Before changing website URLs, create a mapping sheet that records every affected old address, its intended destination and the action required. Then test the implemented behaviour against that sheet. A redirect plan is most useful when it makes exceptions visible before launch.

This applies to a small service-page restructure as well as a larger migration. Moving a page from an old address to a new one changes how existing bookmarks, external references and saved campaign links reach your content.

Collect addresses from more than the menu

A navigation menu rarely represents the whole website. Start with the content inventory and sitemap, then consult relevant analytics, Search Console and server records where available. Include useful downloads and other assets that are also moving.

Record full addresses in the working sheet, including the hostname and protocol. Two pages with similar names may have different roles. An old enquiry page should not be matched to a new guide merely because both contain the word “installation”.

Give every row an owner. If the content team cannot decide where a page belongs, mark the decision as unresolved rather than letting the developer guess during deployment.

A worked mapping example

These paths belong to a fictional business and are not links to existing Tralionex pages.

• Old: /office-fitout.html
  New: /services/office-fitout/
  Decision: Same service, new address; implement a permanent redirect and test the destination
• Old: /installation-faq/ and /assembly-questions/
  New: /guides/installation-questions/
  Decision: Redirect both only after confirming the new page preserves their useful answers
• Old: /downloads/specification-v1.pdf
  New: /downloads/specification-current.pdf
  Decision: Product owner must confirm the replacement is appropriate before mapping
• Old: /discontinued-service/
  New: None agreed
  Decision: Exception requiring editorial and technical review

The mapping sheet should also contain current response, expected response, destination checked, implementation status, test date and reviewer. Keep “decision approved” separate from “redirect tested”. Approval of the plan does not prove the live implementation works.

Handle exceptions deliberately

A discontinued offer may have no suitable successor. A download may have a newer version that is unsuitable for existing customers. A page may need to remain available as an archive. These situations require individual decisions rather than a blanket rule.

Google's site-move guidance recommends permanent server-side redirects where possible, direct routes to final destinations and avoiding irrelevant redirects to a homepage. Where content is removed without an appropriate replacement, its guidance discusses 404 or 410 responses. It also recommends keeping redirects for as long as possible, generally at least a year.

Ask your developer how the approved decisions translate to your actual hosting and content system. A sample mapping sheet is not a server configuration, and copying unfamiliar redirect rules into a live website can affect unrelated addresses.

Make launch testing a separate sign-off

1. Request each old address and inspect the actual response and final destination
2. Confirm the destination contains the expected content and its important actions work
3. Check that one old address does not travel through unnecessary intermediate addresses
4. Update internal links, relevant canonical references and the sitemap to use the intended new URLs
5. Check that temporary development restrictions have not unintentionally remained on public pages
6. Record failures with the exact address, observed result and responsible owner

Use browser checks for the reader experience and appropriate technical tools for response codes. A page appearing to load successfully does not, by itself, tell you which redirect status was returned.

After launch, keep reviewing the affected pages and traffic sources. A short initial test cannot establish that all historical links are covered. Retain the mapping and results so a later error can be traced to an actual decision.

Turn the mapping into acceptance criteria

A row saying “redirect the old page” leaves important questions unanswered. Write what a successful test would demonstrate. For the fictional office-fitout page, the acceptance criteria might be: the old address returns the approved permanent redirect; it reaches the agreed service page directly; the service description is present; and the enquiry action works.

Add separate criteria for downloadable files. A browser opening a PDF is not enough if the file contains the wrong product revision. Ask the content owner to verify the document name, relevant version and intended audience as part of the destination check.

Keep a place for the observed result rather than recording only a pass or fail. “Ends at the general services page” is a useful diagnostic note. “Broken” forces the next person to repeat the investigation before understanding the issue.

Work through a troublesome address before launch

Imagine an old campaign address, /office-fitout-offer/, that still appears in a printed brochure. The new website has an installation service page, but the old campaign included an offer that has ended. A mechanical match based on shared words could mislead someone who scans the brochure later.

First, ask the business owner what the old offer promised and whether any readers still need an explanation. Second, decide whether the destination should contain an accurate notice about the ended promotion. Third, have the developer implement the approved response and test it from the exact printed address.

This example illustrates why the mapping is a joint content and technical document. The developer can make an address resolve, but the business must decide which explanation is accurate. Record that approval beside the row so a later reviewer can understand the choice.

Separate launch blockers from follow-up work

Before deployment, sort open issues by their effect on the agreed customer journeys. An important enquiry page reaching an unrelated destination is a different problem from an optional archive note awaiting polish. Let the responsible owners agree which issues prevent release.

• Content dependency: The replacement page has not been approved
• Technical dependency: The redirect has not been implemented or returns an unexpected response
• Journey dependency: The destination loads but the quotation form fails
• Ownership dependency: Nobody has authority to decide what happens to an old offer

Give each blocker a decision owner and a test that will close it. “Ask the developer” is not a complete resolution when the missing decision concerns a discontinued service.

If the migration also involves a new layout, bring the mapping into the website development brief. This keeps page construction, content approval and URL behaviour connected without assuming that one sign-off covers all three.

Keep a practical post-launch issue log

Retain the approved mapping as a baseline. For every later issue, record the old address, where it was found, expected behaviour, actual behaviour, owner and correction date. Distinguish an omitted historical URL from a redirect that was correctly mapped but incorrectly implemented.

Check representative journeys from saved emails, printed QR destinations and important external references where you can access them. Do not send requests to third-party site owners merely because a row says their link is old; any outreach needs its own agreed recipient and purpose.

Finally, preserve the launch notes. If several changes happen together, the record helps the team investigate a problem without assuming that every traffic movement came from the URL change. A careful issue history is more useful than declaring the migration finished because the homepage looks right.

Redirect planning questions

Can all old pages redirect to the homepage?

That is rarely a useful mapping. Match the reader's intended content where a relevant replacement exists, and review genuine exceptions individually.

Does changing a page title require changing its URL?

No. Decide whether the address itself needs to change. An editorial title update can often leave an established URL intact.

Will a migration preserve every ranking?

No plan can guarantee that. Google's guidance notes that search visibility can fluctuate during a move; careful mapping reduces avoidable implementation mistakes.

Plan your next project with Tralionex

Bring the old URL inventory, proposed destinations and unresolved exceptions before a migration begins. Review Tralionex’s SEO services and use the mapping sheet to discuss the checks and responsibilities your project requires.

Discuss your project with Tralionex