Website Redirect Mapping Checklist Before a Redesign

Build the URL inventory before approving the new sitemap

Start with every URL that may still receive a visit, a crawl, or a referral. Your current XML sitemap covers part of that set. It will miss retired pages, excluded pages, files, campaign URLs, and routes that other systems still reference.

Collect URLs from:

• Current and historical XML sitemaps
• Search Console page reports
• Analytics landing-page reports
• CMS exports
• Backlink data
• Paid campaign records
• Email sequences and sales enablement documents
• CRM templates and automated messages
• PDFs, images, and downloadable files
• Subdomains and legacy domains included in the redesign
• Existing redirect rules
• Server logs when your team has access

Normalize the list before making decisions. Remove fragments, standardize the protocol and hostname, separate query parameters from canonical paths, and flag duplicates caused by casing or trailing slashes.

Keep the raw exports. Build the working inventory in a separate file so you can trace each URL to its source.

Give every old URL a disposition

Each old URL needs one recorded outcome:

1. Keep: The URL and its content remain.
2. Redirect: The URL changes and has a relevant destination.
3. Merge: Several old pages consolidate into one stronger destination.
4. Remove: The content has no useful replacement.
5. Review: An owner must resolve the decision before implementation.

Do not force every removed page to the home page. A redirect should send the visitor to the closest page that satisfies the old intent. If no relevant replacement exists, document the removal and let the implementation return the correct response for that case.

Preserve a URL when changing it creates no clear business, editorial, or technical benefit. A cleaner-looking path carries migration risk without adding value.

Design the redirect map as implementation data

A two-column list of old and new URLs is too thin for a real migration. Your map should tell the developer what to build and tell the reviewer how to test it.

Include these fields:

Use absolute URLs during review when domains or subdomains may change. Developers can convert approved rows into the format required by the hosting layer, framework, server, or edge platform.

Store the map in version control or another system with change history. A shared sheet can support editorial review, but the approved implementation file should not depend on someone remembering which tab became final.

Map by intent, not by matching words

Path similarity can help teams find candidates. It cannot approve the destination.

A retired /platform/analytics page might belong under a new product page, an integration page, or a resource. The right answer depends on what the old page promised and what the visitor expects after clicking an old result or link.

Review these signals:

• Page title and primary topic
• Search queries tied to the page
• Internal links pointing to it
• External links and referral sources
• Campaigns or sales materials that use it
• The conversion action on the old page
• Product, regional, and audience context

Require a person who understands the content or offer to approve high-value mappings. Automation can identify candidate matches and broken rows. It should not decide where sales and product pages send buyers.

Set rules for patterns and exceptions

Large sites need pattern-based redirects. A product rename, locale change, or directory migration may affect hundreds of URLs. Write the broad rule, then list exceptions that require a different destination.

For each pattern, define:

• The source path structure
• The destination structure
• Parameter handling
• Locale behavior
• Case and trailing-slash behavior
• Excluded routes
• Specific URLs that override the pattern

Test the exceptions before the broad rule. Redirect engines often evaluate rules in order, and one loose pattern can catch routes intended for a more specific destination.

Avoid wildcard rules that send unrelated pages to one generic section. They make the spreadsheet look complete while giving visitors poor destinations.

Handle files, parameters, and external systems

Page routes get most of the attention. Files and system-generated URLs cause many launch defects.

Check:

• PDFs linked from sales decks or old articles
• Image URLs used by partners or documentation
• Form confirmation pages
• Calendar and booking routes
• UTM-tagged campaign destinations
• Search and filter parameters
• Language and regional paths
• Login, app, support, and documentation subdomains
• Vanity URLs used in print or events
• Links stored in CRM and marketing automation tools

Decide whether each query parameter affects content, attribution, filtering, or nothing. Preserve parameters that downstream systems need. Check campaign, analytics, and application requirements before removing or normalizing parameters.

If the redesign changes domains, include protocol, hostname, and certificate readiness in the launch plan. A path-level map cannot help if the old host stops serving requests.

Update internal links to final destinations

Redirects protect old entry points. They should not become the new site's internal linking system.

Update navigation, body links, buttons, canonical tags, hreflang references, structured data, sitemaps, and CMS references so they point straight to final URLs. This reduces redirect hops and makes future audits easier.

Include links inside migrated rich text and reusable CMS modules. Developers often update template links while old URLs survive inside imported content.

Run an internal crawl against staging. Flag any link that returns a redirect, error, or unexpected host. Review intentional exceptions instead of ignoring the whole report.

Test the map before and after launch

Test every approved redirect with automation. Review important paths by hand.

Your automated test should confirm:

• The source returns the expected status
• The location header matches the approved destination
• The final destination returns a successful response
• No chain adds an intermediate hop
• No loop sends the request back to an earlier URL
• Query parameters behave as specified
• Hostname, protocol, casing, and trailing slashes follow the approved rules
• Locale rules reach the right regional page

Run the test against staging when the environment can reproduce production routing. Run it again on the live domains after launch. Save both results with timestamps.

Sample high-value paths by hand. Open old search results, campaign links, sales links, and external referrals. Confirm the destination still matches the promise that earned the click.

A successful status code does not prove a good mapping. A redirect to the wrong page can pass a technical test and fail the visitor.

Coordinate redirects with the rest of launch SEO

Redirects interact with other launch controls. Review them alongside:

• Canonical URLs
• XML sitemaps
• Robots.txt rules
• Index and noindex directives
• Internal links
• Hreflang references
• Structured data URLs
• Analytics and conversion events

The new sitemap should contain final URLs, not old URLs that redirect. Canonical tags should point to the intended final pages. Robots rules should not block the old routes before search engines can process the redirects.

Google Search Central documents site moves and redirect methods. Use its current guidance when your team chooses implementation details for domain changes or complex migrations.

Put redirect ownership in the redesign scope

Name one owner for the redirect map. Content, SEO, development, sales, and analytics teams can contribute, but one person must control approval status and the final source of truth.

The scope should state who handles:

• URL collection and normalization
• Destination decisions
• Technical rule generation
• Staging deployment
• Automated testing
• Manual review
• Launch deployment
• Production verification
• Post-launch monitoring and fixes

Set deadlines before development ends. Destination decisions can affect navigation, CMS relationships, migrated content, and page production.

Define how the team handles URLs discovered after the initial inventory. New rows need the same approval and testing process as the first batch.

Use acceptance criteria that protect the launch

“Redirects included” leaves too much room for interpretation. Ask for evidence tied to the approved map.

Useful acceptance criteria include:

• Every inventoried URL has a disposition
• Every redirect row has one approved destination
• No unresolved review rows remain at launch approval
• The project’s maintained configuration contains the rules
• Automated staging and production tests cover the full approved map
• Tests report chains, loops, errors, and destination mismatches
• Internal links point to final destinations
• Sitemaps and canonicals use final URLs
• High-value campaign, sales, and organic entry points receive manual review
• A named owner receives the production test report

Keep the redirect map after launch. Your team will need it when a partner reports an old link, a campaign resurfaces, or another migration starts.

Ask agencies these questions before signing

Use the redirect plan to compare proposals:

• Which data sources will you use to build the inventory?
• Who approves destinations?
• How do you handle pages with no relevant replacement?
• Where will the redirect configuration live?
• How will you test rules in staging and production?
• Will you update links inside migrated CMS content?
• How do you detect chains, loops, and wildcard mistakes?
• Who owns fixes after launch, and for how long?

An agency should connect redirect work to content migration, CMS architecture, custom development, analytics, and launch QA. Treating it as a last-minute SEO spreadsheet leaves the hardest decisions outside the build.

Virdis plans redirects as part of the website system. We define the URL inventory, content decisions, implementation rules, and launch evidence before the new site replaces the old one.

Frequently asked questions

When should your team create a redirect map?

Start during discovery, before the team approves the final sitemap and development scope. Finish destination decisions before the team locks content migration, CMS structure, and launch QA.

Should every deleted page redirect to the home page?

No. Send an old URL to the closest relevant replacement. If no useful destination exists, document the removal and use the correct response rather than sending unrelated visitors to the home page.

Can redirect mapping be automated?

Tools can collect URLs, suggest matches, generate rules, and test results. A content or business owner should approve important destinations because matching path names does not confirm matching intent.

How long should redirects stay in place?

Keep migration redirects in maintained infrastructure and review them during future platform changes. Removing them without checking old links, referrals, campaigns, and search use can break entry points that still matter.