A redesign becomes an SEO migration when URLs, domains, protocols, or site structure change. Search engines and users need a direct path from each old resource to the closest equivalent new page. Sending everything to the homepage, creating chains, leaving staging noindex rules active, or publishing only the new sitemap can break that trail. The redirect map is the shared contract between content, development, analytics, and search monitoring.

VISUAL LESSON

What you will learn

  1. 01Inventory old URLs and classify their search and business value.
  2. 02Build and test direct server-side redirect mappings.
  3. 03Update internal signals and monitor the migration after launch.
An old website architecture passes through a one-to-one redirect map into a new site while broken chains are flagged
A migration preserves meaning when every old URL has an intentional equivalent, an honest removal response, or a documented exception.

ILLUSTRATIVE 500-URL MAP

Every old URL needs one documented outcome

One-to-one replacementsDirect permanent redirects
360
Consolidated into stronger pagesClosest relevant destination
80
Removed with no replacementReturn 404 or 410
40
Unresolved before launchLaunch blocker
20
Hypothetical migration—not a Google benchmark. Real distributions depend on the site, redesign, and content decisions.

MIGRATION WORKBOOK MAP

Test the redirect contract end to end

Inventory01Export and classify old URLs

Combine crawl, sitemap, analytics, Search Console, backlink, product, campaign, and server-log sources; preserve status, canonical, traffic, links, and owner.

Map02Assign the closest destination

Match search intent and content purpose, choose permanent server-side redirects for durable moves, and mark true removals separately.

Verify03Crawl old and new paths

Check status, target, chain length, canonical, noindex, robots, internal links, sitemap, analytics, structured data, and mobile rendering before and after launch.

Conceptual interface map. Hosting controls and Search Console labels differ; validate actual HTTP responses and rendered destinations.

THE MIGRATION CONTRACT

Inventory → map → redirect → update → test → monitor

MapPair each old URL with intent
TestRemove chains, loops, and blocks
WatchMonitor crawl, index, and traffic

THE LEAD ATLAS METHOD

After an organic migration clarifies which markets the new site serves, Lead Atlas Data can research a business-contact list tailored to those locations, categories, and campaign priorities for a separate outbound program.See how custom list research works ↗
01

Build the old-URL inventory

Combine the current XML sitemap, a site crawl, analytics landing pages, Search Console pages and queries, backlink exports, paid campaign destinations, product or service databases, server logs, and URLs supplied by content owners. No single source contains every address people or crawlers use.

Record current status, canonical, title, content type, organic traffic, conversions, links, business owner, and planned disposition. Freeze the inventory before launch while allowing a documented exception process.

02

Map by intent and equivalence

Send an old page to the closest new page that satisfies the same purpose. A discontinued service with no replacement should not be redirected to an unrelated homepage merely to avoid a 404.

Use direct permanent server-side redirects for durable moves where possible. Mark one-to-one, consolidated, removed, unchanged, and unresolved. Review high-traffic and high-link URLs manually.

03

Prevent chains, loops, and soft errors

Test the old URL, intermediate hosts, HTTP and HTTPS versions, www and non-www, case and trailing-slash variants, query parameters, and locale paths. Each intended move should reach the final canonical destination efficiently without a loop.

Return a proper 404 or 410 for content that is intentionally removed with no equivalent. A page that displays not found while returning 200 can become a soft error and confuse both monitoring and search systems.

04

Update the entire signal set

Change internal links, navigation, canonicals, hreflang where used, structured data URLs, media references, feeds, XML sitemaps, analytics, consent, forms, ad destinations, email links, and third-party integrations to the final URLs.

Remove staging robots or noindex controls from the production pages. Preserve Search Console verification and verify relevant old and new properties or variants according to Google’s move guidance.

05

Complete the launch and monitoring plan

Crawl the redirect map before launch, run a sample from external networks, and verify server capacity because Google may temporarily crawl the new site more heavily. After launch, monitor not found errors, indexing, sitemap processing, traffic, conversions, logs, and destination quality.

Deliverable: frozen URL inventory, approved redirect map, high-value manual review, prelaunch crawl, launch checklist, Search Console property list, issue owner, daily first-week review, and longer-term rule for keeping redirects in place.

THE TAKEAWAY

Create one-to-one server-side redirects where a real replacement exists, return honest errors for removed content, update every internal signal, and monitor both old and new URLs after launch.

OFFICIAL REFERENCES

Check the platform’s current instructions.

Platform labels, eligibility, and workflows can change. These official help pages were used to validate this lesson.