A website redesign should protect the paths that already help visitors understand an offer, contact the business, or complete another meaningful action. Begin by documenting those paths before changing layouts, copy, navigation, or technology. A redesign can improve clarity and usability, but it can also remove information people rely on, break forms, lose useful URLs, or make a familiar task harder to complete.
This checklist is for founders and teams planning a substantial website update. It is not a guarantee that every commercial outcome will improve. Enquiries and sales depend on many factors beyond a website. The practical objective is simpler: keep the working journeys visible, testable, and accountable while the team makes deliberate improvements.
Inventory the journeys before discussing new pages
List the actions a visitor can take today. Common examples are reviewing a service, reading a case study, requesting an audit, submitting a contact form, downloading a resource, or finding an address and phone number. For each path, note the entry page, the information someone needs before acting, the action itself, the confirmation they receive, and the internal destination of the request.
Do not rely on memory or a design workshop alone. Walk the current site on a phone and a desktop. Ask the people who receive enquiries which details are often missing and which pages they use to answer questions. If analytics or Search Console access is available to the responsible team, use it to identify important pages and search traffic patterns. If it is not available, document that limitation instead of inventing a performance narrative.
The inventory should include the routes that seem unglamorous. A contact page, a service detail page, or a support email link may carry more practical value than an elaborate home-page feature. The goal is to protect the route a visitor actually uses, not just the page that looks most central in a presentation.
Define what must remain true after launch
For every important path, write a plain acceptance statement. A service visitor should still be able to understand the offer and reach the relevant services overview. A person requesting help should still be able to find the contact page, complete the form, and receive a meaningful acknowledgement. A visitor researching the business should still be able to reach the portfolio or documented work without encountering an unexplained dead end.
These statements are more useful than a generic instruction to “preserve conversion.” They can be tested before launch and used to decide whether a design change is ready. They also expose ambiguity. If a team cannot describe what the existing journey does, it is not ready to claim that a replacement journey is equivalent or better.
Include accessibility in the acceptance criteria. Visitors must be able to navigate with a keyboard, understand headings, operate controls, and receive clear feedback. A visually improved page that removes labels or makes the primary action hard to find is not an improvement for everyone.
Map old URLs to a deliberate destination
A redesign often changes information architecture and page slugs. Before launch, create a URL mapping for pages that will move, merge, or retire. Each old URL needs an intentional destination or, where the content no longer exists and has no useful replacement, an appropriate not-found response. Do not send every retired page to the homepage. That can leave people confused and fails to explain the relationship between the old request and the new site.
Google Search Central’s site-move guidance recommends preparing mappings and using server-side permanent redirects for lasting URL changes. The same guidance advises avoiding redirect chains and testing a move thoroughly. This does not mean every design refresh needs a migration project. It means URL changes require a controlled plan, especially when a site has existing links, search visibility, or materials shared in email and social posts.
Keep the map in a format that the developer or hosting owner can use: old URL, new URL or response, reason, owner, and test result. Treat query parameters and trailing-slash behaviour carefully where they matter to the existing site. A clean-looking new structure is not a reason to discard a path people can still reach.
Keep redirects direct and reviewable
A visitor should reach the final relevant page without being sent through a series of old locations. Direct redirects reduce avoidable delay and make failures easier to diagnose. Test the old URL, final destination, page title, important internal links, and the action the visitor is expected to complete. A redirect is only part of the journey. The destination still needs to answer the original need.
Where an older page has a useful audience but the exact topic is no longer offered, consider writing a concise explanation and a relevant route instead of pretending an unrelated new page is a match. Accurate boundaries are better than an apparently tidy report with hidden broken expectations.
Protect forms, contact routes, and internal notifications
Forms are conversion paths, but their working state is not visible from a design file. Test every field, validation message, consent mechanism, notification, and recipient route in a staging environment where possible. Confirm that a real submission reaches the right inbox or system and that the acknowledgement shown to the visitor is accurate. If the form includes an option for a free digital audit, check that its wording and handoff still match the service process.
W3C guidance on forms emphasises clear labels, instructions, and feedback. During a redesign, those elements are easy to lose when a form is rebuilt with new components. Do not rely only on colour, placeholder text, or a decorative icon to communicate a requirement or error. Test on a phone, with keyboard navigation, and with the browser zoomed. A request path is not protected if only a mouse user at one screen size can complete it.
Document who owns the final test. A designer can check visual hierarchy, a developer can check technical delivery, and the person who handles enquiries can check whether the notification contains useful context. Each view catches a different failure. The final sign-off should record what was tested and what remains outside the scope of the launch.
Review content and navigation against visitor intent
A redesign can accidentally turn clear content into decorative copy. Compare the old and new opening sections for essential facts: who the service is for, what it addresses, what happens next, and any meaningful limitation. Preserve or improve that clarity. A new visual system should not make visitors search for the words that help them decide whether to enquire.
Check navigation labels with the same discipline. Internal terminology may be concise for the team but unclear to a first-time visitor. The working process and service pages should be reachable through language a prospective buyer recognises. Keep a direct path to useful evidence, including the case study library where it is relevant and accurate.
Content changes should retain the original promise unless the business has deliberately changed it. If the offer, target audience, or primary conversion action changes, record that as a strategic decision. Do not let it happen by accident because a new layout had less room for a supporting explanation.
Stage the release and prepare a recovery path
Where the technical setup allows it, test on a staging environment before changing the public site. Review pages, forms, navigation, redirects, metadata, and media in conditions close to production. Make a release checklist that identifies the deployment owner, the time window, the tests to run immediately after launch, and the recovery method if a material path fails.
Change one connected group of things at a time when possible. Google’s guidance on significant site changes recommends avoiding multiple unrelated changes together because it becomes harder to understand the source of a problem. A website team may not always be able to separate every change, but it can still distinguish a content decision, a URL change, and a hosting change in its plan and monitoring.
A recovery path does not require assuming failure. It is a practical responsibility. Know how to restore the previous release or re-enable a critical route, who has the access to do it, and where the test notes are stored. This makes a team more willing to fix a real problem promptly instead of debating whether the launch caused it.
Monitor the paths that matter after launch
Immediately after launch, re-test the documented journeys. Open old URLs, follow important internal links, submit test enquiries where authorised, and verify contact information. Over the following days, review reported errors, support messages, and any available search or analytics signals with appropriate context. A temporary change in data is not proof of success or failure, but a recurring broken route requires attention.
Keep a small issue log with the page, path, observed behaviour, impact, owner, and resolution. This gives the team a shared view of what has been fixed and avoids duplicate work. It also helps separate a genuine conversion-path problem from a preference about colours, spacing, or a headline.
The right finish line for a website redesign is not that every new element looks polished in isolation. It is that important visitors can still find relevant information, understand the offer, use the contact path, and complete the actions the business depends on. Protecting those journeys gives a redesign a solid operational foundation for later improvement.
