What exactly will your redesign change?

Write a separate decision for appearance, content, page addresses and the website platform. Google recommends making major changes sequentially. Its Change of Address guidance also warns that combining a move with content and URL restructuring can lead to traffic loss. Read Google's explanation before agreeing the scope.

A URL is a page's web address. A CMS, or content management system, is the system used to manage website content. For your project, replace those general terms with the actual pages and platform being changed.

Write a brief the team can check

• List the business problem the new design should solve.
• Mark which existing addresses should remain unchanged.
• Separate proposed content deletions from visual changes.
• Assign someone to approve the destination of each moved page.

Hypothetical example: a home cleaning company wants an easier booking journey. Set that as the first deliverable. Ask the team to justify any proposal to remove its separate service pages or change their addresses.

If a new domain is also involved, add the domain migration guide to the brief. Keep the domain decision visible instead of hiding it inside a general design task.

What should you save before work begins?

Build an inventory of existing pages and record their intended future. Google recommends finding important URLs through sitemaps, analytics, Search Console link data and the CMS. Include hosted images and downloadable documents in the migration plan. Google's inventory guidance provides the starting points.

A sitemap is a file listing page addresses for search engines. Google Search Console is Google's tool for examining a site's search presence. Confirm who has access and ask for the current page and search reports before development starts.

Create a working spreadsheet

Use columns for current address, page purpose, proposed address, decision, owner and test result. Record a decision even when a page will stay where it is. Mark unresolved destinations clearly and assign someone to settle them.

• Save the current page copy and headings for comparison.
• Record which pages support enquiries, orders or bookings.
• Keep a copy of existing search performance reports.
• Flag seasonal pages for a separate business review.

My recommendation is to discuss important pages with the person who handles customer enquiries. Ask which questions those pages need to answer after launch. Use that discussion to write acceptance criteria for the replacement content.

Review the XML sitemap guide with whoever maintains the site. Request the current inventory before discussing the replacement sitemap.

Where should each old page lead?

Match a moved page to a relevant replacement. A 301 redirect is a server response saying that a page has moved permanently; Google also recognizes 308 as permanent. Google's redirect documentation explains the distinction between permanent and temporary moves.

Hypothetical example: a small furniture shop is simplifying its catalogue. Use this decision table to discuss destinations before anyone configures redirects.

Google advises against sending unrelated old pages to the homepage. For removed content without a replacement, use a 404 or 410 response, indicating that the page is unavailable or gone. The migration guide covers these cases.

Review meaning as well as destination

Read each mapping as a customer: would someone seeking the old service find the right answer on the new page? Ask the business owner to approve ambiguous cases. A developer should not have to guess whether two services are equivalent.

Use the 301 redirect guide for implementation planning. Request a tested list of source addresses and final destinations as part of the handover.

What should you test before approving launch?

Compare representative pages with their existing versions. Choose a service page, a product or category page, an article and a contact page. Write down missing information and broken customer actions before reviewing cosmetic refinements.

Ask for specific technical checks

A canonical tag identifies the preferred page address. A noindex instruction tells search engines not to include a page in their index. Google tells migrating sites to check these settings and update internal links. Its preparation checklist explains the requirements.

• Confirm public pages have no leftover development indexing restrictions.
• Check that canonical addresses refer to the intended live pages.
• Follow menu and content links to their correct destinations.
• Compare important text, images and downloads with the inventory.
• Submit a test enquiry and have the receiving team confirm it.

Use the canonical tag guide if the developer's explanation is unclear. Ask for an example from your own site and a record of the checked setting.

For navigation review, use the internal linking guide. Walk through an actual customer task, such as finding a service and requesting a quote, then record where you get stuck.

Repeat the customer journey on a phone. The mobile SEO guide can structure that review. Make someone responsible for confirming that important information and actions remain usable.

How should you organize launch day?

Choose a quieter trading period where possible. Google recommends timing migrations for lower traffic and preparing the new site thoroughly. Its launch guidance supports this approach.

1. Confirm the page inventory and destination decisions are complete.
2. Have the developer activate the site and planned redirects.
3. Open important old addresses and check their replacements.
4. Confirm public pages can be indexed and submit the updated sitemap.
5. Test an enquiry or purchase journey with the business team.
6. Record the launch time and assign every remaining issue.

Decide whether Change of Address applies

Use Search Console's Change of Address tool after moving and redirecting to another domain or subdomain. Do not use it for a visual redesign, paths changing within the same domain, HTTP to HTTPS, or a www variation change. Google's tool instructions list these boundaries.

For an eligible move, confirm ownership of both properties through the same Google account before using the tool. The ownership requirements are explicit.

Write the launch decision in plain language: who can approve it, which unresolved problems prevent it, and who remains available afterward. Treat a missing core service page or a broken booking journey as unfinished work.

What should you do if traffic drops?

Identify the affected pages before changing the design again. Google recommends monitoring old and new URL traffic, indexing and unexpected errors during a move. Its monitoring guidance describes what to examine.

Indexing means processing pages for inclusion in search. During URL migrations, Google may take a few weeks or more to replace old addresses for a medium-sized site. This is an estimate, not a recovery deadline. Google explains the timing.

Give each problem a concrete investigation

• Open the old address and check where it leads.
• Compare the replacement page with the approved content.
• Ask the developer to check indexing restrictions.
• Inspect the affected page in Search Console.
• Review old and new addresses together when assessing the move.

Hypothetical example: a consultant sees fewer visits to an old workshop page. Start by checking its replacement and the redirect. Do not label the redesign a failure from that old address alone.

Keep an issue log with the page, observation, owner, correction and next check. Agree a review schedule with the team. Use each review to close verified problems and decide what needs further investigation.