A website redesign checklist that protects useful URLs and customer inquiries

Start with the customer journey

A website can look dated and still contain pages that customers depend on. A service description may answer a recurring question. An old link in an email may bring someone straight to a quotation form. Before replacing the design, write down the journeys the new site must support: understanding a service, checking whether the business covers an area, calling, and requesting an estimate.

For a contractor or professional service business in the Antelope Valley or Santa Clarita area, a useful brief might be: a visitor on a phone can find the relevant service, understand the next step, and submit an inquiry without hunting through the navigation. That is an acceptance criterion the owner and developer can review together. “Make it modern” leaves too many important decisions unstated.

Record what is working as well as what needs improvement. If you have authorized access to existing search reports, traffic reports, or server logs, use them to identify frequently visited pages and entry points. Ask the people who answer the phone which website details create confusion. A visual redesign is also an opportunity to remove that confusion.

Inventory the URLs before drawing the new menu

Create a simple list of existing page addresses, their purpose, and their proposed destination. Include important PDFs, linked images, campaign landing pages, and contact pages. Mark each item as retained, improved, consolidated, or retired. This makes a content decision visible before it becomes a broken link.

Keep a useful address when the page still serves the same purpose. When an address changes, map it to the closest relevant replacement. Google’s site-move guidance recommends permanent server redirects, updated internal links and canonical URLs, and a new sitemap. It also warns against sending many unrelated old pages to the homepage. A redirect should help the visitor reach the answer they expected, rather than merely suppress an error. ^[1]

Some content has no replacement. Decide that explicitly and let genuinely removed resources return the appropriate missing-page response. Test the URL map with a sample of real old links, including links with query strings if those affect the business workflow. Keep the map with the project documentation so a later developer can understand the decisions.

Make content and layout agree

Build the page around a clear customer question. Explain what the service includes, what information is needed to estimate it, and how someone can contact the business. Use accurate descriptions of the service area. Do not hide important qualifications in tiny text or invent local projects to make a page sound more convincing.

Review headings, navigation labels, and buttons together. A button called “Get started” should lead to a clear next step. If a form asks for a budget or timeline, explain the choices in ordinary language. Give people an alternative contact method when they need to discuss something the form cannot capture.

Test with realistic content early. A design made around three short placeholder lines may not work with a detailed service description or a long business name. Check the actual text at narrow widths, with keyboard navigation, and with enlarged text. The best time to resolve content and layout disagreements is before launch.

Treat the inquiry form as a business process

Write down where an inquiry goes after submission. Is it stored in a database, delivered to an inbox, or entered into another system? Who reviews it, and what happens if delivery fails? A confirmation screen should reflect a successful server operation, not just a button click.

Use a clearly labeled test inquiry to verify the whole agreed path. Check required fields, invalid email input, duplicate submissions, and a temporary backend failure. Confirm that an error preserves the information already entered. Verify telephone and email links on an actual mobile device when the shared testing environment is available.

If reporting is part of the scope, define useful events such as completed inquiries or click-to-call actions and agree on privacy requirements. More tracking is not automatically more useful. The owner needs a small set of measurements they can interpret and a clear explanation of what each one represents.

Launch with a short, reviewable checklist

Before changing the live site, keep recoverable copies of the files and relevant data. Review the old-to-new URL map, metadata, mobile layout, contact workflow, and important integrations. Confirm that development-only indexing restrictions have been removed from pages intended to be public.

After launch, read the public pages back from the live domain. Check redirects, the sitemap, and the inquiry path again. Establish who will review errors and customer feedback during the first days. Search visibility can fluctuate when URLs change; a careful launch plan reduces avoidable mistakes but does not guarantee unchanged rankings. ^[1]

Bring your existing site address, the most important customer journeys, and a few examples of confusing pages to a redesign conversation. Full Blown can help turn those observations into a defined design and development scope.

Related services

• Website redesign
• Web design
• Technical SEO

Sources and further reading

• [1] Google Search Central: site moves with URL changes

Related reading

• A practical technical SEO checklist for a custom website
• Local SEO for service-area businesses: useful evidence before more city pages
• Website maintenance: an ownership and recovery checklist for business owners
• Explore all Insights