Before You Redesign Your Website, Build a Page Migration Ledger

A website redesign often begins with a conversation about how the new site should look. The risk is that the existing site already does jobs nobody has written down. A service page answers a particular question. An old link sits in a customer email. A quote form sends work to a real inbox. A case study is the proof a customer needs before making contact. Change the site without recording those jobs and the new design can quietly lose them.

Before commissioning a redesign, build a page migration ledger: one working record of every current address, its purpose, its replacement and the evidence that it still works after launch. It is a simple tool, but it changes the discussion from whether the new website looks better to whether it serves the business better.

Start with the pages people can actually reach

Make a list of current URLs, not just the pages visible in the navigation. Include service and location pages, older articles, work examples, campaign landing pages, contact and thank-you pages, downloadable documents and pages linked from printed material. Look at the XML sitemap and internal links, but do not assume either is a complete inventory. Check analytics and Search Console where available, and ask staff which links they regularly send to customers.

For each address, record the current page title, intended audience, main customer question and next action. A page with little search traffic may still be commercially useful if it is used in quotes or follow-up emails. A page that is getting visits may still be confusing customers. Traffic is one input, not the decision.

Use a seven-column migration ledger

A spreadsheet is enough. Give it seven columns: current URL; purpose and evidence; decision; new URL; content owner; redirect or technical action; and post-launch test. Each row should describe one address, not one design component. This prevents an attractive homepage from hiding the loss of a useful service page.

For example, a current page about vehicle graphics might have a clear purpose: show recent finished work and get a quote enquiry. The decision could be keep and improve. Its new destination might use the same URL. The content owner must check that its images, service details and enquiry link survive. The launch test is not simply that the page loads; it is that a customer can still see the work and request a quote.

Another row might be an old promotion page that has served its purpose. The decision could be retire. But if its old address is still linked from emails or other websites, decide what genuinely relevant replacement exists. If there is no equivalent, do not automatically send visitors to the homepage and call the job finished.

Give every page one of four decisions

Keep: retain the URL and improve the page if its job remains valuable. Merge: combine overlapping content into a genuinely better destination, then map each old address to that destination. Replace: introduce a new page when the customer need remains but the structure has changed. Retire: remove a page with no continuing purpose, checking links and external dependencies first.

The test for a merge is whether the replacement actually answers the old page's question. Two services may look similar to a designer but represent different buying decisions. If one customer needs vehicle graphics and another needs a building sign, merging everything into a generic page may make the site tidier while making the business harder to understand.

Separate content changes from URL changes

Changing copy, hierarchy, photography and layout does not always require changing a URL. Where an existing address already makes sense, keeping it can reduce avoidable work and disruption. If the URL must change, document its exact replacement and test the resulting redirect. Avoid loops, chains and destinations that are only vaguely related to the original.

A redirect is not a substitute for content. If an old page answered a specific practical question, the new page must still answer it. Review page headings, calls to action, visible business details, forms, contact routes and any supporting documents. The ledger should show who is responsible for checking each one.

Run the customer journey test before signing off

Choose five real customer tasks and complete them on both the old and the proposed website. For example: understand a service, compare examples of work, establish where the business operates, find an answer to a common objection, and send a meaningful enquiry. Ask someone unfamiliar with the project to try them without guidance.

Record what happens, not what the designer intended. Could the person find relevant proof? Did the page explain the offer in language they recognised? Was it clear what would happen after submitting a form? Did they reach the right service or fall back to a generic contact page? These observations are more actionable than a debate over which visual treatment feels modern.

Make launch acceptance evidence based

Before launch, agree who will test the sitemap, old-to-new URL mappings, page titles, canonical addresses, forms, mobile navigation and key internal links. After launch, check actual HTTP responses and sample important redirects, not merely the on-screen appearance. Confirm that the new pages intended for search can be indexed, and that deliberately private or duplicate pages are handled appropriately.

Keep the ledger open during the first weeks after launch. Record unexpected missing pages, misdirected enquiries, broken links and customer feedback. The person responsible for fixing each issue should be named. Launch is a milestone, not proof that the migration is finished.

A simple sign-off rule

A redesign is ready to sign off when every important old address has an intentional outcome, every key customer task still works, and the business knows who owns the unresolved issues. If the ledger is mostly empty, the project is not yet a website migration plan, however convincing the mock-ups look.

For businesses deciding what kind of rebuild is actually needed, the starting point is the current site and its customer journey. Our website design work begins with that practical question rather than a predetermined template. If the bigger problem is unclear ownership of the website, the related Thought Hub guide on whether to manage your own business website helps frame that decision. If enquiries are being lost after visitors arrive, the trade website contact test offers another useful check.