How to protect useful Google traffic during a website redesign

Before replacing a website, identify the pages people already find, decide what happens to their addresses, and agree who checks the transition. A redesign can improve the experience without treating the existing site as disposable.

An old service page can look unremarkable and still help people reach your business. An article may attract relevant searches. A project page may be linked from a partner's website. A download may sit inside a proposal that someone is considering now.

Changing those pages affects more than the appearance of the site. It changes what happens when a person or search engine follows an existing address. The owner does not need to implement the technical work personally, but someone needs to account for it before launch.

This is a practical guide for a small service business planning a redesign. It focuses on the decisions to bring to your web partner. It cannot guarantee unchanged traffic: demand, competition, content changes, and search systems also affect what happens after a launch.

Find out what is worth protecting

Start with the pages that matter to the business. Which ones explain an important service? Which receive enquiries or help a prospective client decide to get in touch? Which are linked from profiles, newsletters, documents, or other sites?

If Search Console and analytics are available, ask your partner to review useful landing pages and relevant search queries over an appropriate period. Keep the reporting dates and any tracking changes with the notes. A quiet week does not establish that a page has no value, especially in a business with an irregular buying cycle.

Data can help prioritize the work, but it does not replace a content decision. A low-traffic contact page may still be necessary. A popular article about a broad design topic may have little connection with the services you now sell. Record both the observed use and the business purpose before deciding to keep, improve, combine, or retire a page.

If you do not have reliable history, say so. Use the content inventory, known external links, sales materials, and team knowledge as a starting point. Do not fill a missing measurement with an invented traffic estimate.

Give every important address a decision

Make an inventory of the old URLs, which are the addresses people can follow. Keep the full address and enough information to recognize the page. Add the proposed destination and the decision behind it.

For a page that still serves the same purpose, keeping a useful existing URL may be the simplest option. A new design does not require a new address. When content moves or several pages become one, identify the closest useful destination. When material is intentionally removed, record that decision rather than allowing the page to disappear unnoticed.

Google's site-move guidance recommends preparing a mapping between old and new URLs, testing the new site, and monitoring the change. It also warns that search visibility can fluctuate while Google processes a significant move. That is a reason to plan and check the transition, not a promise that planning eliminates every change.

Original explanatory visual by Studio FLACH. Open the image to view it at full size.

The useful output is a decision for each important old address. A list of new pages alone does not account for people following old links.

Work through a small fictional migration

Imagine a consultancy with two overlapping service pages: /team-workshops and /leadership-workshops . It is replacing them with a more useful service page at /services/leadership-workshops . It also has a well-used article at /insights/preparing-your-team-for-change that will retain its address.

This is a fictional example, not a client project or a report of search results. Its purpose is to show how an owner can make the decisions visible.

The two old service addresses need an agreed treatment because people may still follow them. The new service page must actually cover the relevant work; a similar-sounding title alone does not make it an appropriate replacement. The retained article should still open at the same address and link to the appropriate current service.

An old event announcement is different. If the event is finished and there is no useful replacement, the team should decide whether it has archival value or should be removed. Automatically sending every retired page to the homepage can leave visitors searching again for the information they expected.

Your migration record could read:

• Keep the team-change article at its current address and update its service link.
• Move the two workshop pages into the agreed service page, with technical redirects implemented and checked by the web partner.
• Review the event page separately; do not invent a relevant replacement.
• Check any sales documents, profiles, or emails that your team can update directly.

Ask your partner to specify the redirect approach. Google's redirect documentation distinguishes permanent and temporary changes and explains how they are interpreted. Your role is to clarify the intended move; the implementer should choose and test the appropriate technical response.

Put search continuity in the project scope

“SEO included” does not tell you whether old URLs will be reviewed. Ask who prepares the inventory, recommends destinations, implements redirects, updates internal links, and checks the important paths after launch.

Also ask who reviews titles, descriptions, index settings, and the preferred page address reported by the site. These tasks are connected, but they are not interchangeable. A new sitemap does not tell you whether an old sales link now reaches a useful page.

Our redesign preparation checklist helps gather the wider project materials. Add the URL record to that preparation. Your proposal comparison should make the migration responsibilities explicit rather than assuming that a visual redesign includes every historical content item.

AI-generated illustrative photograph.

Illustrative generated photograph. The migration plan helps someone following an old route reach the information they need.

Make launch approval a short set of real checks

Select a practical set of important journeys before the launch date. Include a main service page, a frequently shared article, a changed URL, a download if relevant, and the enquiry route. Record who checks them and what a successful result looks like.

On the staging site, review the content and links in context. Does the combined service page still explain the work people expected? Have any useful qualifications or limitations disappeared during editing? Can a visitor follow the current next step? This is also the moment to notice a new navigation label that hides an important service.

At launch, have the implementer check the technical transition on the live domain. The owner can check the visible journeys, while the person responsible for development checks the underlying responses and search settings. Do not remove staging protections casually; confirm that the public site is being launched with its intended settings and that private test material remains private.

Original explanatory visual by Studio FLACH. Open the image to view it at full size.

A named person and a recorded result make a launch check more useful than a general statement that the site has been tested.

Watch what happens after the site changes

Keep the launch date, final URL decisions, and any significant tracking change together. They help you interpret later reports. If numbers change, first establish whether the measurement still works and whether you are comparing equivalent periods and pages.

Review the important old paths directly, check enquiries are arriving, and ask your partner to review search reporting as data becomes available. A drop in one report is a reason to investigate the page, query, technical response, and timing. It is not enough to prove that the design itself caused the change.

Agree how problems discovered after launch will be reported and handled. The person who prepared the redirect record should be able to explain the decisions later; it should not exist only in a temporary conversation.

If you are discussing True Space , bring the history of the site along with your plans for the new one. A useful scope accounts for the experience you want to create and the existing routes people already use to find you.