Website Redirect Map Template: Plan URL Changes for Redesigns, Content Cleanup, and Rebrands

Overview

A redirect map is a working document that matches each URL being changed with its intended destination. It is usually maintained in a spreadsheet, although a database or project-management tool can work for a large site. The map should be completed before pages are deleted, renamed, moved, or published at new addresses.

The basic objective is simple: when a visitor or search crawler requests an old URL, the server should provide a clear path to the most relevant current URL. A well-planned map also gives developers, editors, and SEO teams a shared source of truth during the URL migration plan.

Create one row for every important URL rather than relying on memory or a short list of recently edited pages. Useful discovery sources include the current XML sitemap, analytics reports, search performance data, internal links, navigation menus, backlink reports, and the existing redirect file. Include URLs that may not receive much traffic but still support conversions, rankings, customer journeys, or external references.

For background on related site operations, see the website launch and maintenance checklist and the website migration guide. A URL change is separate from a hosting move, but the same principle applies: document dependencies before changing the live environment.

Checklist by scenario

For a website redesign

• Export the current URL list before the redesign begins.
• Mark pages that will keep the same address, change address, merge, or disappear.
• Record the proposed new URL and confirm that its content serves the same user need.
• Update internal links, menus, breadcrumbs, image links, XML sitemaps, and structured references.
• Test redirects on a staging environment where possible, then repeat testing after launch.

A redesign often changes templates as well as URLs. Check that canonical tags, hreflang references where applicable, pagination links, and robots directives point to the new site structure rather than copied staging or legacy addresses.

For content cleanup or consolidation

• Group pages by topic and identify overlapping or outdated content.
• Choose one destination that best satisfies the original page’s intent.
• Redirect a retired page to a genuinely relevant replacement, not automatically to the homepage.
• Rewrite or remove internal links that still reference the retired page.
• Keep a record of the reason for each decision, especially when several pages are merged.

If no relevant replacement exists, do not force a redirect simply to avoid an error page. A page may need to return an appropriate non-success response instead, based on the site owner’s content and technical policy. The important distinction is relevance: redirects should help people reach the next useful destination.

For a rebrand or domain change

• Map every important old-domain URL to its corresponding new-domain URL.
• Use direct one-step destinations wherever possible.
• Update canonical tags, internal links, XML sitemaps, image URLs, feeds, and social profile links.
• Confirm that DNS, SSL, hosting, and email changes are planned separately from the URL redirects.
• Keep the old domain available and redirecting for as long as it remains operationally appropriate.

Do not treat a domain change as only a registrar task. DNS records control how services resolve, while redirects control how web requests move from old URLs to new ones. The DNS records guide can help separate those responsibilities, and the SSL certificate guide covers common HTTPS considerations.

For individual URL changes

• Record the complete old URL, including the path and relevant protocol or host variation.
• Confirm the new URL is final before publishing the redirect.
• Use a permanent redirect when the move is intended to last.
• Change internal links so they point directly to the new address.
• Check both the old URL and the destination in a browser and a crawler.

Build the redirect map

A practical redirect map template can use these columns:

• Old URL: the complete address requested before the change.
• New URL: the final, canonical destination.
• Redirect type: normally a permanent redirect for a lasting move, or a temporary redirect when the change is genuinely temporary.
• Change reason: redesign, consolidation, rebrand, migration, or correction.
• Priority: high, medium, or low, based on traffic, links, conversions, revenue, or strategic importance.
• Canonical target: the URL the page declares as its preferred version.
• Internal links updated: yes, no, or pending.
• Test status: not tested, passed, failed, or needs review.
• Notes: ownership, launch date, exceptions, or follow-up work.

Use full URLs in the working file even if the implementation system accepts relative paths. This makes protocol, hostname, trailing-slash, and subdomain differences visible. Normalize duplicate variants deliberately rather than allowing several versions of the same page to redirect in different ways.

In most permanent URL moves, the redirect should go directly from the old address to the final destination. Avoid sending a request through several intermediate URLs. Direct paths are easier to test and reduce the chance of redirect chains or loops.

What to double-check

Status codes and destination relevance

Confirm that the selected redirect type matches the intended duration. A permanent move and a short-term campaign or maintenance route are different situations. Also verify that the destination is relevant to the old page. A technically successful redirect can still create a poor experience if it sends users to an unrelated page.

Canonical tags and internal links

After a migration, the page’s canonical tag should not continue pointing to an old or redirected URL unless there is a deliberate technical reason. Internal links should point directly to the final address rather than relying on redirects. Review navigation, footer links, related-content modules, PDFs, downloadable files, and hard-coded links in templates.

Chains, loops, and variants

Test old URLs that already had redirects. A legacy URL may point to an intermediate address that now redirects again. Consolidate these paths where practical. Check HTTP and HTTPS versions, www and non-www hosts, uppercase paths, trailing slashes, query parameters, and common legacy filename patterns according to the site’s URL rules.

Launch and post-launch monitoring

Before launch, crawl the staging or preview site and test a representative sample of high-priority rows. Immediately after launch, test the highest-value URLs first, then review server logs, analytics, crawl reports, search performance data, forms, checkout paths, and login areas. Keep the redirect map updated with the result of every test.

Common mistakes

• Redirecting everything to the homepage: this removes useful context and may frustrate visitors. Map pages to the closest meaningful destination.
• Starting after the launch: discovery and mapping should happen before URLs change, not after broken links appear.
• Creating chains: point each old URL to the final destination whenever possible.
• Forgetting non-HTML assets: important PDFs, feeds, images, and downloadable resources may also have external links.
• Leaving internal links unchanged: redirects can mask the problem while adding unnecessary requests.
• Confusing DNS with redirects: DNS points a domain or hostname to a service; it does not replace URL-level redirect rules.
• Deleting the map: retain the file, decision notes, and test results so future migrations can account for older URL history.

When to revisit

Review the redirect map before every redesign, rebrand, content audit, CMS change, domain transfer, or hosting migration that may alter URLs. Revisit it before seasonal planning cycles if campaign landing pages or temporary routes are being retired. It is also useful to review existing redirects when crawl reports show errors, when analytics reveal traffic to obsolete URLs, or when a new content structure is introduced.

Tools and CMS workflows change, so confirm the current implementation method in the platform documentation before editing production rules. Keep a dated version of the map, record who approved changes, and schedule a post-launch review rather than treating the first successful test as the end of the project.

Action checklist: export the current URLs, fill in the old-to-new map, classify each change, remove chains, update internal links and canonicals, test priority pages, launch with monitoring enabled, and record every exception. That routine makes future website URL changes easier to plan and safer to reverse.