A practical checklist for a website migration

A website migration becomes easier to manage when the team treats it as a set of explicit decisions about addresses and customer journeys. A new design may attract most of the attention, but an existing link still needs to take a visitor somewhere useful. This planning workflow focuses on URL changes and the people responsible for checking them. It is practical project advice; use current official documentation and qualified technical judgment for your particular setup.

Define the move before making the list

Write down what is changing: the domain, the URL structure, the hosting setup, the content, or several of those at once. Name the owner who can approve the scope. A request to refresh a homepage is very different from a project that changes thousands of product addresses. The migration plan should describe the actual project rather than inherit a generic checklist unchanged.

Separate required changes from optional improvements. If a team is already moving the domain, it should make a deliberate decision about whether a large content rewrite belongs in the same release. Each additional change adds questions to the follow-up. Sometimes combining work is practical, but the team should understand the resulting difficulty of explaining what happened.

Collect the addresses people rely on

Build an inventory from the sources your team is authorized to use. Include the published website, existing sitemaps, internal navigation, important campaign destinations, and pages the business considers essential. Ask customer-facing colleagues which links they send repeatedly. Their answers may uncover a useful page that receives little attention in the redesign discussion.

Treat the inventory as a working document with a named maintainer. Keep the original address intact and use separate columns for decisions. Avoid editing old URLs in place, because that destroys the reference you will need during testing. Flag uncertain entries for review rather than guessing where they should go. The person checking the mapping should be able to see which decisions remain open.

Give each address an intentional outcome

For each old URL, decide whether the content moves to a direct equivalent, is consolidated into a relevant page, or is intentionally retired. The decision should reflect what a visitor expects after following the old link. A catch-all destination may be convenient for a developer but confusing for a customer who was looking for a specific answer.

Google's site move guidance recommends preparing a mapping between old and new URLs and implementing appropriate redirects. It also discusses updating internal references and monitoring the move. Read the full guidance for its details and caveats. The project workflow here adds ownership and a way to review those choices before release.

Review the mapping with content owners

A technical mapping can be syntactically valid while making little sense to a reader. Ask someone who knows the content to review representative destinations. If three old service pages lead to one new overview, does the new page still answer the important questions? If a detailed guide is retired, is there a genuine replacement or should the visitor receive a clear unavailable response?

Record why a consolidation makes sense. That explanation helps future maintainers understand the decision and prevents a later teammate from accidentally recreating the old structure. It also reveals content work that must happen before the route can be approved. A destination listed in a spreadsheet is not ready merely because somebody has reserved its address.

Test a representative sample early

Choose examples from each important route pattern and test them before the entire site is ready. Include a straightforward page move, a consolidation, an intentionally retired page, and any unusual URL pattern your website uses. Early testing can expose a mistaken assumption about how the platform handles paths without requiring a complete release to discover it.

Write the expected result beside each test. The check should include the final destination and whether the relevant content appears there, not only whether a request returns a response. Where query parameters matter to the business, give them their own examples. Use the actual platform's documentation to decide what behavior is appropriate rather than assuming every address can be treated identically.

Prepare the customer journeys around the pages

Migration review should include navigation, important calls to action, downloads, and contact paths. A page that loads successfully may still leave a visitor at a dead end. Ask the owner of each critical journey to confirm it in the release candidate. Give them a short list of tasks that resembles how customers use the site, with enough context to recognize a wrong result.

Give the contact journey to the colleague who handles customer inquiries. Ask them to follow it as a customer would: find the contact link, read the instructions, send an agreed test message, and confirm that it reached the person who will answer. A migration can preserve every article while accidentally losing the path to a conversation. Include downloads and booking links in this same review when they matter to the business.

Agree on the release decision

Hold a short readiness review with the people who can resolve open items. List the unresolved mapping decisions, the tests completed, the checks still needed, and any limitations of the staging environment. A checklist full of ticks is less useful than a clear explanation of what each tick represents. Do not let a project date quietly turn an unknown result into an approval.

Decide how the team will respond if a critical route fails after release. The appropriate recovery plan depends on the platform and the change. Identify who can make that decision and how the team will contact them. A plan written before the release is easier to use than an improvised conversation while customers are reporting problems.

Observe the public result

After publication, check the real public addresses rather than relying only on the release candidate. Revisit the representative mapping sample and the important customer journeys. Record the time, environment, and result so another person can understand the evidence. If a content delivery layer or redirect service participates in the route, the public check is especially useful for revealing differences from local behavior.

Search-related follow-up belongs alongside these operational checks. Google's Search Console overview describes tools for monitoring how Google crawls, indexes, and serves a website. Assign someone to review the appropriate reports for the move, using the current official instructions rather than assuming that a successful deployment proves search processing is complete.

Keep the mapping useful after launch

The mapping is part of the website's ongoing record. Keep it available to maintainers, with the release date and the decisions that explain unusual cases. When a customer reports a broken link, the team can add the example, decide what should happen, and verify the correction. This is more reliable than treating the migration as finished the moment the new homepage appears.

Finally, schedule a review with the people who did the work. Ask which missing information slowed them down and which early test caught something valuable. Use those answers to simplify the next migration plan. Keep the next checklist close to the decisions the team actually needs to make about its important addresses.