Website Migration Redirect Maps: A Practical Guide for Small Businesses

A redirect map is the handoff plan between the website people already know and the website you are preparing to launch. It should preserve useful journeys, document intentional removals and give the launch team a testable source of truth.

Separate a website rebuild from a URL move

A redesigned page does not automatically need a new address. If a current URL is readable, accurate and already used in bookmarks, ads, emails, directories or search results, keeping it can remove an entire class of migration risk. Change a URL when the new information architecture creates a real customer benefit—not merely because the new content management system prefers a different default.

A host change with the same public URLs requires a different checklist from a domain change or a rebuild that reorganizes paths. Google’s current site-move documentation distinguishes infrastructure changes from moves that change URLs and recommends changing one major variable at a time when practical.

The website redesign planning guide helps define what each page should do before rebuilding it. The website migration service covers the wider platform, host, domain and ownership work. This guide focuses on the redirect map that connects the old and new public page sets.

Build the old-URL inventory from several sources

Do not treat the current XML sitemap as a complete inventory. It may omit pages that still receive visits, links or campaign traffic. Combine evidence from the content management system, existing sitemap, analytics, Search Console, server logs, internal crawl and any lists maintained by marketing or operations.

Include more than HTML pages. Images, downloadable forms, PDFs, campaign landing pages and other files may have been linked from emails, customer portals, partner sites or printed materials. Google specifically recommends including embedded-content URLs in migration planning and reviewing traffic and link evidence when assembling the old list.

A useful inventory can contain these columns:

• old URL and current HTTP status;
• page title, type and owner;
• customer purpose and primary action;
• recent visits or search activity, when available;
• known internal and external links;
• replacement decision and proposed new URL;
• redirect type, implementation owner and test status;
• notes for campaigns, profiles, downloads or integrations.

The purpose column matters. Metrics can help prioritize testing, but a low-traffic warranty form or payment instruction may still be operationally important.

Classify every old URL before choosing a destination

Give each URL an explicit disposition instead of assuming everything should redirect. Four practical outcomes cover most cases:

• Keep: the page and URL continue to serve the same useful purpose.
• Move: the useful content has a new, equivalent address.
• Consolidate: several overlapping pages become one stronger destination that genuinely contains their continuing value.
• Retire: the content has no relevant replacement and the old URL should return an honest not-found or gone response.

The content audit guide provides a keep, improve, consolidate or remove decision process. Apply that editorial decision before writing server rules. A redirect cannot make an irrelevant destination useful.

Map to the closest useful replacement

A visitor following an old link should arrive somewhere that fulfills the same intent or clearly continues the task. A former service detail page might map to the corresponding rebuilt service page. Two overlapping articles can map to a consolidated guide only when that guide actually carries forward their useful information.

Avoid sending large groups of unrelated old URLs to the home page. Google warns that irrelevant redirects can confuse users and may be treated as soft 404s. If no meaningful replacement exists, an accurate 404 or 410 response is clearer than a forced detour.

Record the reason for every many-to-one consolidation. That note makes later testing easier and helps content owners distinguish a deliberate merge from an accidental catch-all rule.

Use permanent server-side redirects for permanent moves

When a move is permanent, Google recommends server-side permanent redirects such as HTTP 301 or 308 when the platform supports them. Its redirect guidance explains the signals Google uses for permanent and temporary moves.

Point each old address directly to the final destination. Redirect chains add latency and make diagnosis harder. They can also form loops when old rules are copied into a new environment without a full map. Preserve query parameters only when the destination uses them safely; discard obsolete tracking or application parameters deliberately rather than by accident.

The implementation may live in a hosting configuration, edge rule, framework, CMS or application. The spreadsheet is not the redirect—it is the controlled specification that the implementation and tests must match.

Make the destination page internally consistent

A successful redirect is only one signal. Each new page should use its final preferred URL in the canonical link, navigation, body links, structured data, hreflang annotations when relevant, sharing metadata and sitemap entry.

Google’s canonicalization guidance explains that redirects, canonical annotations and sitemap inclusion can all indicate a preferred URL. Conflicting signals create avoidable ambiguity. A new page should not redirect visitors to one address while declaring a different canonical or linking internally through the old path.

The internal linking guide helps rebuild useful hub-and-spoke paths. Update the site’s own links to the final URLs instead of relying on redirects for ordinary navigation.

Prepare staging without carrying launch blocks into production

A staging site may need access controls or temporary noindex rules, but those controls require a removal checklist. Google identifies leftover robots.txt blocks and noindex directives as common migration problems. Do not assume a launch process will remove them automatically.

Before launch, test representative templates and every important destination for status, canonical URL, robots directives, visible content, forms, phone links, email links, analytics and structured data. The technical SEO audit guide adds checks for indexability, performance, accessibility and conversion paths.

Test the redirect map as data

Manual spot checks are useful but insufficient for a complete map. Run the old-URL list through an automated test and save the result. For every row, confirm:

• the old URL returns the intended redirect status;
• the location header matches the approved final destination;
• the destination returns a successful response;
• there is no redirect chain or loop;
• the destination is indexable when it is meant to be public;
• the canonical matches the preferred final URL;
• the page still supports the intended customer task;
• internal links do not point back to the old URL.

Test from outside the development environment and include alternate host variants, HTTP/HTTPS forms, trailing-slash patterns and common uppercase or parameter cases that the old system accepted. A technically correct rule on one hostname does not prove the complete route works.

Coordinate the launch order

The new pages, TLS certificate, analytics, forms and redirect rules should be ready before traffic is switched. Preserve Search Console verification and confirm that the team can access the registrar, DNS, hosting and source code. The website ownership and handoff checklist maps those controls and recovery evidence.

For a domain or subdomain move, verify the relevant old and new Search Console properties and use Google’s Change of Address workflow where it applies. That tool is not required for an ordinary path change on the same domain. Update high-use campaign, directory, social-profile and partner links so customers do not take an unnecessary redirect even when the old route remains supported.

Publish a sitemap containing the final URLs

The XML sitemap should list canonical, indexable destinations—not the retired addresses that now redirect. Google’s sitemap documentation describes a sitemap as a file that helps search engines understand important pages and files; it does not guarantee crawling or indexing.

Submit the new sitemap in Search Console after launch. Keep the redirect map separately as the historical record. The two files serve different jobs: one declares the current public set, while the other explains how earlier addresses reach it.

Monitor both customer journeys and search discovery

A migration is not finished when the homepage loads. Watch server errors, form completions, call and email actions, analytics, Search Console indexing reports and the use of old URLs. Compare the results against the approved map and fix unexpected 404s, loops, wrong destinations and blocked pages quickly.

Google advises expecting temporary search visibility fluctuations during a significant move while systems recrawl and reindex URLs. That is a planning expectation, not a guaranteed timetable. The duration depends partly on site size and server capacity.

Keep permanent redirects active for as long as practical. Google recommends at least one year for site moves and notes that keeping them indefinitely can continue helping users. Update the site’s own links and important high-volume external links to reduce latency and dependence on the old routes.

Assign owners and preserve a rollback path

Give one person authority to approve the map and separate owners for implementation, content validation, lead-path testing and monitoring. Record the last known working deployment, DNS values, redirect configuration, analytics setup and launch timestamp. A rollback should restore a coherent site, not only a visual template.

For Charlottesville and Central Virginia service businesses, locally visible profiles, sponsorship pages, chamber listings, vendor portals and seasonal campaign links may continue sending traffic long after a rebuild. Include them in the launch communication and monitoring plan without fabricating local relevance or duplicating city pages.

The website builds service connects migration planning to page architecture, accessibility, conversion paths and maintainable delivery. The SEO service connects the technical move to content, internal linking and ongoing measurement.

Website migration redirect-map checklist

• Define whether URLs, domain, host, CMS or design are changing.
• Keep useful existing URLs when change provides no customer benefit.
• Inventory pages and files from multiple sources.
• Give every old URL a keep, move, consolidate or retire decision.
• Map changed URLs to the closest relevant final destination.
• Use permanent server-side redirects for permanent moves.
• Remove chains, loops and irrelevant homepage redirects.
• Align redirects, canonicals, internal links and structured data.
• Remove staging-only crawl and indexing blocks.
• Test every mapped route and important customer action.
• Publish and submit a sitemap containing the final canonical URLs.
• Update important campaign, profile and partner links.
• Monitor errors, traffic, index coverage and lead paths.
• Keep the map, test evidence, ownership record and rollback plan.

The searchable STANDBY Knowledge Center connects migration planning with redesign, content decisions, technical SEO, internal linking and website ownership.

Credible external sources

• Google Search Central: How to move a site with URL changes
• Google Search Central: Redirects and Google Search
• Google Search Central: Canonical URL guidance
• Google Search Central: What is a sitemap?

Related services and guides