Map old URLs before a website redesign

A website redesign can change addresses that visitors have bookmarked or other sites still link to. Before replacing the old site, list its existing URLs and decide what should happen to each one. A small redirect map gives the business owner and developer a shared record of those decisions.

Start this work while the current pages are still available. It’s easier to judge the purpose of an old page when you can read it than after every request has begun returning an error.

Collect the Addresses People Already Use

Begin with the website’s current page list and sitemap. Add URLs from any available analytics, search reporting, server logs and important external links. Each source can reveal a different part of the inventory. An old campaign page, for example, may still receive enquiries even though it no longer appears in the menu.

Record the full address, page title or purpose, and what you intend to do with it. Keep a note of where the address came from. For an enquiry page, check whether printed leaflets, social profiles or directory listings also use that URL. Those references may need an update even when a redirect is in place.

A redesign doesn’t require every address to change. If the service and page purpose remain the same, keeping a useful URL can reduce the amount of migration work. Agree proposed changes before building new links throughout the replacement site.

Map Each Changed Page to a Real Destination

This is an invented five-page example for a small service business. It’s a planning record rather than server configuration.

Current path          Decision       Destination
/                     Keep           /
/our-services.html    Move           /services/
/contact-us.html      Move           /contact/
/gate-repairs.html    Keep           /gate-repairs.html
/offer-summer-2022/   Review/remove  No relevant replacement

The services and contact pages have genuine replacements. The gate-repair page can keep its address while receiving a new design. The expired offer needs a content decision. A current offers page might be suitable if it meaningfully serves the same visitor need, but that needs checking.

Read the old and new pages side by side before accepting a match. A page describing a specific repair service shouldn’t automatically lead to an unrelated general page just because the new design has fewer pages. Google Search Central’s site move guidance warns against sending many old URLs to an irrelevant destination, such as the homepage.

Give unresolved rows an owner and a decision date. “Review” is useful while planning, but it must become a deliberate outcome before launch. That outcome may be a relevant replacement, retained content or a proper missing-page response.

Choose the Redirect and Check the Response

When a page has permanently moved, a server-side permanent redirect is the usual option. Google’s redirect documentation distinguishes permanent and temporary moves. Your developer should select the response that matches the intended behaviour and the hosting platform.

A 301 response identifies a permanent move and supplies the new address through its Location header, as explained in Mozilla’s HTTP reference. The important check is the actual server response. A page that looks different in the browser hasn’t necessarily redirected.

Check the Old Address and the Final Page

For a developer using the curl command-line tool, these illustrative commands inspect the response and then follow the redirects. Replace the reserved example domain with the real address being tested.

curl -sS -D - -o /dev/null https://example.test/our-services.html
curl -sS -L -o /dev/null \
  -w 'status=%{http_code} final=%{url_effective}\n' \
  https://example.test/our-services.html

The first command makes a GET request and prints the response headers. The second follows redirects and reports the final status and address. Confirm that the redirect points straight to the intended live page, rather than through a sequence of outdated destinations. Then open that page and check its content and navigation.

Forms and other requests that submit information need separate care. Redirect status codes can affect how a request method is handled. Don’t apply a brochure-page rule blindly to a payment route, login endpoint or enquiry handler.

Update the New Site and Keep the Map

Once the destination pages exist, update internal links to use their final addresses. Check menus, buttons, image links and contact details. Review the sitemap and any canonical references with the developer, particularly if the domain name changes as well as the paths.

Before launch, test every row in a small map. After launch, repeat the checks against the public site and review error reports and enquiries. For larger inventories, use a crawl or a scripted check and inspect exceptions individually. A successful response code still needs the right destination content.

Keep the map with the website records. Add the launch date, final decision and test result for each row. Search engines need time to process changes, and the reporting may fluctuate during a move. If a useful old address appears in the logs later, investigate its original purpose before adding another catch-all redirect.