Website SEO migration: which URLs should you keep?

Keep useful existing URLs unless a real content or platform requirement demands a change. When an address must move, send visitors directly to a relevant replacement. For a website SEO migration, approve three things before launch: a URL decision ledger, a tested redirect map and a monitoring plan. Recent search traffic alone should not decide which pages survive.

Build the old-URL inventory before approving removals

Combine a crawl with content exports, existing sitemaps, analytics, Search Console and server logs where available. Google recommends using several discovery sources and including resources such as images and videos. A navigation-only crawl can miss orphaned pages: addresses that still exist but have no internal links. Include useful PDFs and parameters that identify different products or content. [1]

Use this copyable ledger structure, with one row per exact old address. Record indexability, meaning whether indexing is technically allowed, and the current canonical: the preferred address declared for that content. Assign an owner who can judge business usefulness, not just technical correctness. The sample row illustrates the format rather than a real website.

Ask sales, support and product owners what they still share. A low-traffic specification may help existing customers maintain equipment. A seasonal service page may attract enquiries only during one trading period. Review suitable historical periods and known incoming links before deleting anything. Record this evidence even when your analytics cannot measure its value.

Decide what to keep, move, merge or retire

Changing an address simply to make it look newer adds migration work without necessarily helping customers. Retaining it reduces that work, although a genuine restructuring may justify a move. Judge replacements by purpose: someone looking for a specific pump specification needs that specification, not merely another page containing the word “pump”.

Google warns against redirecting many unrelated pages to the homepage; these may be treated as soft 404s, meaning apparently successful responses that behave like missing pages. Genuine consolidation is different. For retired content, 404 means not found and 410 means gone. Google handles both as missing content. A helpful error page should retain the appropriate error status. [1][3]

Turn the decisions into a testable redirect map

For permanent moves, Google recommends permanent server-side redirects, including 301 and 308. Specify the complete journey: old URL → permanent redirect → relevant final URL → 200. Avoid chains through intermediate addresses. Google generally recommends keeping migration redirects for at least one year; that is not an automatic deletion date. Old links and customer bookmarks may remain useful longer. [1][2]

1. Confirm meaning: ask the content owner to approve each destination against the old page’s purpose.
2. Handle parameters: preserve values that identify products or materially different content; do not discard every query string.
3. Test rules: check broad patterns and their exceptions, including rule precedence.
4. Follow each journey: verify the final address, permanent status, working content and absence of chains or loops.
5. Record evidence: save the test date, actual result and unresolved failures in the ledger.

Make canonicals, internal links and the sitemap agree

Check that intended indexable destinations declare the correct production canonical, usually themselves. Update navigation, breadcrumbs and contextual links to point directly to final addresses. Include preferred canonical URLs in the new sitemap, not redirected or retired entries. Canonicals express a preference; Google ultimately chooses its canonical. They do not replace redirects for permanently moved pages. [4][5]

Keep staging private and production indexable

Protect private staging with authentication. A noindex instruction asks search engines not to index content; it does not restrict visitor access. Robots.txt controls crawling, not confidentiality. Google must crawl a page to read its noindex instruction, so blocking crawling can prevent that instruction being seen. Do not rely on robots.txt alone to keep staging out of search. [6]

Check both HTML meta tags and the X-Robots-Tag response header for noindex. Remove development restrictions only from intended public production pages, while keeping staging protected. Our recommended launch blockers include production-wide noindex, blocked key pages and canonicals pointing to staging. Removing one visible meta tag is insufficient if a server header still blocks indexing. [1][6]

Work through a hypothetical product-catalogue migration

Hypothetical example, not a client result: an industrial-pump manufacturer keeps its domain while redesigning an enquiry-led catalogue. Assume the replacement products are equivalent and the two chemical-pump pages genuinely overlap. These are same-domain path changes, so Search Console’s Change of Address tool is unnecessary. [1]

The product owner approves specifications and consolidation. The developer implements mappings, including the exact product parameter. A named tester checks responses, destination content and enquiry journeys. The project manager records approval. If every product redirects to a generic category, fail the test: a correct redirect status cannot compensate for the wrong destination.

Approve launch with evidence, then monitor the journey

Use the following release gate as a practical team recommendation, not a Google-mandated process. Save baseline reports, the approved ledger and existing configurations before release. For wider planning, use Plan the wider search transition during a website redesign alongside Check what must work before a website launch. This guide supplies the URL-level evidence those plans need.

• Mappings: approved old URLs reach the correct final pages or intentional error responses.
• Content: replacements retain required specifications, documentation and service information.
• Search access: key destinations are indexable, with production canonicals and consistent internal links.
• Sitemap: entries match preferred live destinations without redirects or retired pages.
• Enquiries: forms submit successfully and reach the responsible team.
• Ownership: monitoring, urgent fixes and rollback decisions have named owners.

Block launch for broken key mappings, missing essential content, indexing restrictions or failed enquiry journeys. Minor non-critical copy issues can have agreed follow-up dates. An adaptable monitoring schedule is launch-day retesting, daily technical checks initially and weekly performance reviews thereafter. Inspect unexpected missing pages, redirect failures and server errors promptly; Search Console reporting is not an instant launch test.

Compare corresponding old and new page groups as one content journey. Review indexing, clicks, impressions and enquiries against suitable seasonal baselines. Separate search declines from broken forms or missing tracking. If losses concentrate on moved pages, inspect their mappings and content first; broader declines require wider investigation. Google documents migration fluctuations but gives no guaranteed site-specific completion date. [1][7][8]

This research-assisted guide uses the primary sources linked above. Examples are illustrative unless explicitly identified otherwise. Check original documentation when implementing changes.