A website redesign checklist before you start

Write a short list of the problems you can point to. The service list may be outdated, the phone layout may obstruct contact or the business may have outgrown its original offer. Keep each problem separate from the proposed solution. “People cannot find the renovation service” is a problem; “we need a new platform” is one possible response that needs justification.

Also list what should stay: a clear explanation, useful photographs, a recognizable identity or a working booking integration. If the problems are limited to a few parts of the site, a focused refresh may be enough. The diagnostic guide can help identify that boundary.

Collect the current page addresses, titles, purpose and next action in a simple document. Include useful pages reached from old emails, profiles, ads or printed materials, not just the ones visible in the menu. Where you have access to reliable search or traffic records, use them to identify pages and links that deserve attention. A lack of traffic data is not proof that a page is unused.

• For each page: URL, purpose, content to keep and proposed change.
• For each inquiry path: entry page, form or contact link, destination and responsible person.
• For each integration: what it does, which account owns it and who can manage it.
• For each asset: approved original, usage permission and useful caption or description.

Keep access details in the appropriate account tools. The project document needs an owner and a way to arrange access, not a list of passwords. Save a recoverable copy of the current site and confirm who can restore it.

A visual redesign does not require new page addresses. Keep useful URLs when they still describe the content. If an address changes, map it to the relevant replacement. Google recommends permanent server-side redirects, such as 301 or 308, for permanently moved pages. Sending unrelated old pages to the Home page does not preserve the information the visitor was trying to find.

For moved pages, update internal links, canonical URLs and the sitemap to the intended addresses, then test the mappings. Avoid unnecessary redirect chains. If content is removed without a relevant replacement, agree on an appropriate removal response rather than disguising it as a successful Home-page visit. Search visibility can fluctuate during a move; nobody should promise otherwise.

Mark each page as keep, revise, combine, add or retire. For revised pages, write down the missing customer question. For combined pages, check that useful detail has a place in the replacement. For new pages, explain what they help a visitor decide. This makes the content plan easier to review than a list of page names alone.

Gather the business facts that commonly delay a review: current services, service area, contact details, pricing rules, scope limits and approved examples. Ask the relevant owner to confirm them. A redesign is a good time to remove unsupported claims, but it is not a reason to invent stronger ones.

Changing platforms adds separate questions about accounts, content transfer, integrations and ownership. Keep an existing platform when it can support the agreed work; consider a move only when a specific requirement justifies it. My Services page explains how I approach work on existing websites.

A new form can look correct while pointing to the wrong destination. Write down the expected path: what the visitor enters, which fields are required, what happens after an error, what confirmation appears and where the business receives the request. Include useful context that should survive, such as the service selected on the previous page.

Check navigation and validation on the preview before launch. Then send one clearly marked test message and confirm the person who handles inquiries receives it and can reply. A success message alone does not show that a person can read and reply to the inquiry. Keep an alternative contact method available while investigating a failure.

Compare the proposed site with the brief on a phone and a larger screen. Check important actions with a keyboard, enlarge text, review the menu and make sure notices do not cover controls. Verify service names, page titles, contact destinations and the pages reached from existing external links.

• Name the person who approves content and the person who authorizes publication.
• List the exact pages, redirects and inquiry paths to check after release.
• Check that pages intended for search are crawlable and do not retain a preview noindex directive; keep private pages protected.
• Keep a recovery plan with an owner and a clear trigger for using it.
• Record the result of the checks and investigate differences before calling the release complete.

The final deliverable should have an agreed scope, accurate information and verified paths through the parts customers depend on. If you are still deciding how much to rebuild, use the scope comparison alongside the website planning checklist.