Website Migration: Map URLs, Test Moves and Monitor Errors

Inventory the resources before the move

Collect the actual old URLs rather than guessing paths from the new menu. Include important service pages, articles and assets that have independent references where applicable. Record the current purpose of each resource and any known dependencies. Preserve a copy of the old content and configuration. A migration map cannot establish equivalence if no one knows what the old destination answered or which media it relied on.

Assign each resource a decision: stays, moves, merges or retires. For a move, record the exact replacement. For a merge, identify the section preserving the useful answer. For retirement, document whether a genuinely relevant replacement exists. Do not hide unresolved cases inside a blanket homepage redirect. The map is an editorial decision record as well as a technical instruction, and should be reviewed by someone who understands the content.

Keep the change manageable

A domain change, major rewrite and navigation redesign can occur together, but each adds diagnostic complexity. Stage changes where practical and keep a dated record where staging is not possible. Define who can restore the prior deployment if critical functions fail. A rollback copy is only useful when the team knows what it contains and how to apply it. Check access requirements before the launch window rather than during an emergency.

Google recommends mapping old addresses to their new equivalents and using permanent server-side redirects for a permanent move. Update internal destinations, canonical preferences and the sitemap to reflect the new addresses. Consult the official migration instructions for the particular move, including relevant Search Console steps. A successful new homepage is not evidence that all those resource-level decisions were implemented correctly.

Test a representative prelaunch set

Select a service with incoming references, an older article, a deeply nested asset and a retired resource. Record the expected response for each. Check the old route, the final destination and the rendered resource. Test stylesheets, scripts and images from nested folders; relative paths may behave differently there. Inspect unnecessary redirect chains. Use the mapping as the acceptance source so the tester checks intended behaviour rather than merely reporting that some page opened.

Scenario: articles enter a blog directory

Imagine an article moves from the root into blog/. Its old address should reach the matching guide. The new guide needs working image and stylesheet paths, a correct preferred URL and updated internal references. Those are separate checks. A redirect can work while the cover is missing or the canonical still points to the old address. Include the guide in a controlled test before applying the same pattern to the entire article library.

Validate the production move

Repeat critical tests after deployment because environment-specific rules can differ from the prelaunch copy. Confirm that old routes behave as expected and new destinations are available directly. Test enquiry actions and important assets. Update business-controlled external references such as profile links. Maintain the old domain and redirect configuration long enough to support the move; do not remove them simply because the new design has appeared. Follow the official guidance for migration duration and monitoring.

Monitor against the preserved map

Review access errors and important landing-page behaviour, then investigate deviations using the original mapping. Compare moved resource groups rather than old URLs alone. Search processing can fluctuate, so separate a confirmed routing repair from an expected traffic outcome. Keep notes on subsequent changes and preserve the map after launch. It gives later reviewers a way to trace unexpected destinations, missing resources and stale references instead of reconstructing the move from memory.

Practical checklist

• Inventory real URLs and resource purposes.
• Approve move, merge and retirement decisions.
• Test redirects plus rendered assets.
• Keep a rollback and monitor production paths.

Frequently asked questions

Related Articles