Website migrations and redirects

Identify what is actually migrating

Write a change statement before requesting a redirect spreadsheet. A hosting move with stable URLs mainly changes delivery and availability. A domain move changes the identity of every address. A CMS replacement can preserve addresses while altering rendered content, metadata and links. A redesign can change discovery even when the URL list stays identical. These are different problems and need different release evidence.

List the hostname, protocol, paths, content model, navigation, rendering method and infrastructure in separate rows. Mark each as retained, changed or undecided. Undecided items are dependencies, not permission to assume continuity. Where possible, sequence major changes so that a failed comparison has a manageable set of explanations. Use the migration checklist to turn that scope into launch gates with named owners.

Choose a quieter trading period where practical, but ensure the engineers who understand routing and deployment are available. A quiet overnight launch without support can leave a small fault unresolved for much longer.

Build evidence that survives the old platform

The useful baseline is a record of what visitors and crawlers can access, not just a traffic total. Export live URLs from the CMS, crawl the linked site, collect sitemap entries and review available landing-page and request data. Each source reveals a different part of the estate. Keep the original exports so later cleaning decisions remain auditable.

• Record response status, final URL, canonical, robots directives and content type.
• Save representative source HTML, rendered text, titles and internal links by template.
• Identify pages with enquiries, purchases, useful external links or specialist information.
• Document current exclusions, retired pages and known errors separately.
• Capture comparable search and analytics periods, including seasonal context.

This evidence checklist prevents a common argument after launch: whether a missing page ever existed. It also stops historical faults being mistaken for regressions. Preserve document and image locations where they serve meaningful search or customer journeys; an HTML-only inventory will miss them.

Choose destinations by the task they satisfy

For every old address, decide whether its content remains, moves, merges or disappears. A moved installation guide belongs with its replacement guide, not automatically with the product category. A merger is defensible when the receiving page actually answers the old question. If nothing suitable remains, an honest not-found or gone response is more useful than routing everyone to the homepage.

Use the redirect mapping workflow for individual decisions and rule exceptions. Maintain one authoritative mapping with the intended final destination, reason and review status. A list generated from matching slugs is a candidate map until somebody checks meaning.

Check the arrival experience as well as the address. A correctly routed visitor can still encounter missing specifications, an unavailable download or an untranslated page. Those failures are not repaired by a successful status code. For high-value journeys, ask an editor or product owner to confirm that the replacement serves the original need.

Make the new site internally consistent

The new address should be the destination used by navigation, contextual links, canonical annotations and current sitemaps. Redirects are a bridge for old references; they should not become the normal route through the new site. Contradictory URL references make diagnosis harder because each system appears to describe a different preferred page.

Permanent server redirects, commonly 301 or 308, suit permanent URL moves. Choose the response deliberately with engineering input where methods other than GET are involved. Retained pages should deliver substantive content successfully, and intended removals should not masquerade as ordinary articles with an error message inside a successful response.

Google recommends keeping migration redirects for at least a year; retaining useful old links longer may also serve visitors. Preserve ownership and working certificates for old hosts that must redirect. Cancelling old hosting is safe only when another maintained service takes responsibility for those requests.

A canonical annotation does not replace routing for a visitor following an old link. Equally, a redirect does not repair stale language annotations or a sitemap full of obsolete addresses.

Rehearse the release against explicit acceptance criteria

Test the intended public routing configuration, not merely the application preview. Redirects may live at a CDN, proxy, web server or CMS, and their combined behaviour matters. Include protocol and hostname variants, trailing slashes, encoded paths and queries that change the page. Keep private staging behind access controls; verify separately how production will remove temporary crawl restrictions.

Developer acceptance criteria should require every mapped source to reach its approved target without loops, every retained priority page to return the expected content, and all changed templates to expose the intended title, canonical and links. Require a real missing URL to return the agreed error status. Test forms and downloads independently of SEO checks.

Define which failures block launch. Missing commercial destinations, broad noindex directives and broken certificate coverage warrant a stop. An isolated description rewrite usually does not. Record exceptions with their impact and owner so acceptance does not become an undocumented compromise.

Illustrative example: separate a platform move from a restructure

Illustrative example: a training provider wants a new CMS, a new domain and shorter course URLs. Its existing course pages contain dates, venue information and downloadable syllabuses. Doing everything together would make a loss difficult to interpret: the cause could be routing, content removal, navigation or the new domain.

A practical plan first reproduces the course content and existing URLs on the new CMS. The team checks rendered dates, syllabus links and booking journeys against saved examples. Once that release is stable, it prepares the domain move with one-to-one page mappings. Shorter paths remain a separate decision rather than an automatic part of rebranding.

If sequencing is commercially impossible, record each change separately and add tests for their intersections. One acceptance case follows an old course URL through the redirect to the correct venue and downloadable syllabus. Another checks that the destination appears in the course listing without requiring a search form. These are illustrative checks, not evidence of a measured client outcome.

Use competing explanations when performance changes

A decline after launch is a reason to investigate, not proof that redirects failed. Start with three alternatives: measurement changed, delivery changed, or the page's search proposition changed. Analytics may miss visits after a consent update. A firewall may reject crawlers while staff see cached pages. A redesign may remove the comparison detail that previously answered a query.

Compare affected and unaffected templates, mapped URL pairs, countries and devices. Check live responses and logs before debating ranking explanations. If old URLs redirect correctly but new pages point canonicals elsewhere, investigate that contradiction. If search clicks remain steady while recorded sessions fall, test measurement before changing content.

The migration monitoring guide explains how to join these evidence streams. Search reports have reporting delays and aggregation limits. A single live inspection can establish current access, but cannot demonstrate how every URL has been processed. Avoid declaring success or failure from one dashboard.

Plan recovery without creating a second migration

Rollback needs an operational definition. Restoring a previous application build is different from reversing a domain move or changing DNS. Specify who can revert routing, which database writes must survive, how caches will be purged and what happens to new URLs already shared with customers. A backup without a tested restoration path is weak protection.

Prefer a narrow forward fix when the fault is understood and contained. Correcting one broken route or template directive usually creates less disruption than undoing all successfully moved pages. Consider rollback for severe, widespread availability or transaction failures when repair cannot be delivered safely. Do not use a normal short-term search fluctuation alone as the trigger.

Close the project when ownership has moved into routine operations: redirect tests run after releases, old domains renew, unresolved mapping exceptions have owners and representative content remains discoverable. A redesign review is especially useful where the migration also changed navigation or page modules. Launch completion and search processing are separate milestones.