The useful part, first
  • Keep an inventory of useful content and existing URLs.
  • Map changes carefully and verify the live destinations.
  • Search fluctuations are possible; preserve a baseline and investigate.

You cannot guarantee a website redesign without any change in search performance. You can, however, reduce avoidable losses by preserving useful content, handling URLs carefully and checking the live site after launch.

Keeping customers finding you during a website move requires a concrete plan: which pages stay, which addresses change and how visitors reach the right information. This checklist covers what a small business and its developer should agree before replacing an existing website.

Establish the baseline before changing anything

Export the pages and queries currently bringing search visits, alongside a record of useful enquiries where available. Separate branded searches from searches for services. Keep the date range and any known seasonal effects with the export.

Build an inventory using more than the navigation menu. Include pages linked from other websites, downloadable documents, important images, campaign landing pages and URLs used in emails or printed materials. A page can matter even if it is not prominent in the menu.

Search Console’s performance report provides page and query data that can inform this baseline. It does not tell you whether a visitor became a suitable customer, so connect the search observations to your own enquiry records where possible.

Give every old URL a considered destination

Keep a migration sheet with four columns: old URL, current purpose, proposed action and new destination. Add an owner for any unresolved decision.

Existing page Sensible action What to verify
Still useful and accurate Keep the URL where practical Content and internal links remain correct
Replaced by an equivalent page Redirect to that replacement Destination answers the same underlying need
Combined with another page Review whether the combined page is a real substitute Important information has not disappeared
Permanently removed without a replacement Return an appropriate not-found status The removal is intentional and links are updated

Do not send every retired URL to the homepage just to avoid seeing errors. A visitor expecting a detailed service explanation needs an appropriate destination. Google’s site-move documentation describes URL mapping, permanent redirects and the need to monitor the move. It also notes that search fluctuations can occur during processing.

Protect meaning as well as addresses

Keeping the URL does not preserve the page’s value if the useful explanation is removed. Compare old and new content for service scope, location information, process details, evidence and answers to customer questions.

A redesign often compresses text to create cleaner layouts. Sometimes that improves clarity. Sometimes it removes precisely the information that made the page useful. Review the customer’s decision before cutting a section solely because it is long.

Preserve descriptive internal links between relevant pages. If the old site helped visitors move from a broad service to a specialist option, make sure the new structure still supports that journey. Avoid replacing meaningful link labels with identical “Learn more” text everywhere.

Test the review build before launch

Check representative templates and the highest-value individual URLs. Test response codes, titles, descriptions, headings, canonical references, internal links and the full enquiry journey. Confirm that images and documents still work where their URLs matter.

Staging restrictions need an explicit launch decision. A review environment may correctly block indexing. The intended public site needs the final agreed settings; copying a staging noindex directive into production can undermine the launch. Conversely, do not expose a draft simply to make a test tool happy.

Keep the review build and public domain clearly identified in the checklist. Ask the developer to show which settings change at publication and how they will verify the final result.

Verify the live site immediately

Run the redirect list against the live domain, checking both the response and the final destination. A redirect that technically works but lands on the wrong service is still a failed migration decision.

Check that priority pages are accessible, the sitemap contains the intended URLs, important links use the new destinations and enquiry submissions reach the business. Record the release time so later reporting can distinguish pre-launch and post-launch data.

If a problem affects the whole site, such as accidental indexing restrictions or broken navigation, prioritise it over cosmetic corrections. Agree in advance who can fix a launch issue and whether a rollback is available.

Monitor changes with context

Compare equivalent periods and examine pages separately. A change in total traffic can hide a gain in useful service searches or a loss concentrated in one important section. Low-volume sites need enough observations before conclusions become meaningful.

When performance changes, investigate in order: technical access, redirects, index status, content changes and then wider demand or competition. Do not immediately rewrite every page; that makes it harder to identify the cause.

Use a dated issue log with the evidence, proposed fix and result. Our guide to reviewing how customers find you provides a prioritisation method, and our website redesign checklist covers the wider customer and design decisions.

Behind the guide

Sources & further reading

Platform guidance checked on . The examples, worksheets and decision frameworks are Business Web Development’s editorial guidance.

Put the useful ideas to work.

We can help shape the pages, content and search foundations around your business.

Website development for your business ↗