An old website can need replacing and still contain valuable assets: pages that bring in enquiries, links from relevant organisations and information that Google already understands. Those assets should not disappear simply because the design changes.

A rebuild therefore needs more than a visual brief. If pages move, content is removed or the structure changes, someone must decide what happens to the existing paths into the business.

No responsible migration plan can promise that rankings will never move. Search visibility can fluctuate while changes are processed. The aim is to protect what has value, remove avoidable mistakes and make any necessary move understandable to visitors and search engines.

Find out what the current site is doing

Before designing the replacement, record a baseline. Review organic visits over a meaningful period, taking account of seasonality where relevant. Look beyond the homepage to the pages people actually enter through.

Combine information from Search Console, analytics, enquiry records and a crawl of the site. Identify indexed URLs, pages receiving search visits, pages with relevant backlinks and pages contributing to enquiries. No single source provides the whole picture.

A crawl can reveal pages omitted from the main menu, older resources and existing redirects. Analytics can highlight a quiet-looking service page that still brings the right visitors. Enquiry records may show why a low-traffic page deserves to stay, even if its volume looks unremarkable.

Make a simple inventory with the current address, purpose, search activity, useful incoming links, proposed destination and decision owner. Record uncertainty explicitly. “We have not checked this page” is a better starting point than assuming it has no value.

Separate a new design from new URLs

The safest URL migration is often the one you do not need to make. A rebuild can change the design, underlying code and content management system while keeping useful page addresses intact.

Keep a strong, relevant URL where there is no good reason to change it. A preference for a different spelling or a tidier-looking folder is rarely enough by itself to justify moving an established page.

Where change is necessary, create an old-to-new URL mapping before launch. Google’s site-move guidance recommends preparing this mapping and monitoring the transition. It also acknowledges that rankings can fluctuate while Google recrawls and reindexes changed pages.

For illustration, an old page at /commercial-maintenance.html might move to /services/commercial-maintenance/ if the new structure requires it. The mapping should name that exact destination, rather than leaving the developer to guess where the page belongs.

A redirect needs a relevant destination

A 301 redirect tells browsers and search engines that a page has moved permanently. Google recommends permanent server-side redirects where possible for permanent URL changes; 308 is another permanent status code.

Prefer a direct, one-to-one route to the closest relevant new equivalent. Someone following an old link about a particular service should arrive at useful information about that service.

Sending every old address to the homepage does not achieve that. It interrupts the visitor’s task and can leave the original content without a meaningful replacement. If several genuinely overlapping pages are consolidated, the destination needs to cover their subject properly.

Avoid chains where an old URL redirects to another old URL before finally reaching the new page. Update existing redirect rules as part of the mapping. If content is permanently removed with no relevant replacement, a proper 404 or 410 response can be more honest than an unrelated redirect.

Protect useful content, not just addresses

Keeping a URL while deleting the information that made it useful is not really preserving the page. Review valuable copy, service detail, headings and relevant metadata before replacing them with shorter, vaguer material.

That does not mean retaining every old paragraph. Remove inaccuracies, improve the structure and clarify the offer. Keep the substance people need: what the service covers, where it is available, what evidence supports it and how someone makes an enquiry.

Understand internal links too. A guide may support a service page, and a project may provide evidence for it. Preserve those useful relationships in the new navigation and contextual links. A clear semantic structure helps the rebuilt page express that organisation.

This is especially relevant when the website has fallen behind the business. The goal is to correct the mismatch without treating everything old as disposable.

Check the new site before it replaces the old one

Review page titles and descriptions individually, rather than allowing every page to inherit a generic default. Check the main heading and the outline beneath it. Make sure links are ordinary, crawlable links to the intended destinations.

Canonical tags should identify the correct production URLs. They must not point back to a staging domain or to a different page through a copied template. Update relevant structured data so it describes the new visible content accurately.

Check indexability, robots directives and the sitemap together. A staging site may correctly discourage indexing, but those restrictions must not accidentally carry over to the pages being launched. Equally, keep the unfinished preview protected while the work is in progress.

Include important image and document URLs in the review where they receive links or search visits. Test their replacements as well as HTML pages. Review page performance with the real content loaded; a visually improved site should not introduce unnecessary delays or movement.

Treat launch as a checked transition

Keep a restorable copy of the old site and a record of the approved URL map. Agree who checks the live release and who can fix a problem. These practical arrangements matter when a missing rule is found after the deployment.

Test the old addresses against the live site, confirming their status codes and final destinations. Check that each new destination loads successfully, has the right canonical and is available for indexing. Test enquiries too: preserving visits is of limited use if the contact route breaks.

Submit or update the sitemap in Search Console. Monitor indexing, unexpected 404s, organic landing pages and enquiries after launch. Compare equivalent periods and account for other changes before attributing every movement to the rebuild.

A domain change adds another step

If the domain itself changes, review Google’s Change of Address tool alongside the redirects and property verification. It is for a move to another domain or subdomain, not a routine redesign or path change on the same domain. It does not replace the redirect plan.

Decide whether that domain move needs to happen during the rebuild at all. Combining changes makes it harder to isolate the cause of a problem. The scale of a redesign or rebuild should follow the business need, rather than the assumption that a fresh start requires every technical detail to change.

A careful rebuild improves the website while respecting the routes people already use to find it. Keep those routes where they work; map, test and monitor the ones that genuinely need to move.