A website redesign checklist should cover business goals, existing content, URLs, user journeys, accessibility, testing and post-launch ownership—not just the new visual design. Before changing a live site, agree on what must keep working and how you will verify it.
For a US service business, a redesign might need to make quote requests easier, clarify service pages or improve the mobile experience. A polished homepage will not solve those problems if forms fail, useful content disappears or visitors cannot find the right next step.
Use the checklist below as an acceptance plan with your designer, developer and marketing team. It is designed for a business website, not a full ecommerce migration. Checkout, subscriptions and customer-account migrations require additional specialist testing.
| Phase | Required output | Suggested owner |
|---|---|---|
| Plan | Goals, page inventory, scope and success measures | Business lead and marketing |
| Design | Approved content and tested page layouts | Designer and content owner |
| Build | Working staging site and migration map | Development and SEO |
| Verify | Documented functional and technical checks | QA and business reviewers |
| Launch | Approved release, backup and recovery plan | Release owner |
| Review | Issue log and performance comparison | Marketing and support |
Assign actual names rather than leaving responsibilities with “the agency” or “the business.” Every acceptance item needs an owner and evidence that it passed.
Write down the specific problem before selecting a theme or platform. “The site looks old” is a starting observation, not a complete project brief.
If the requirement includes customer accounts, permissions or complex workflows, confirm whether you are planning a website or a larger application. Our web app vs website guide explains that scope distinction.
Acceptance check: each major deliverable is connected to a business or user need. Features with no clear purpose stay outside the initial scope.
Save a dated record of the current site’s important pages, organic search activity and completed inquiries. Compare a representative period rather than choosing a single unusually strong week. Note seasonal campaigns and tracking changes that could affect later comparisons.
For a US audience, review US traffic separately where data supports it, but avoid overinterpreting tiny samples. Distinguish an actual completed inquiry from someone merely clicking a button.
Record qualitative evidence too: a confusing service description, an inaccessible menu or a form that users abandon. Those observations make the redesign brief more concrete.
Acceptance check: the team can explain how it will judge the redesign after launch without relying only on visual preference or total page views.
Create a page inventory containing the current URL, purpose, content owner and proposed action: keep, improve, merge or retire. Include important downloads and campaign landing pages, not just the pages visible in the main menu.
Flag content that supports sales conversations even if it receives little search traffic. A technical specification or procurement FAQ may matter to buyers without being a high-volume landing page.
Preserve accurate service information and substantiated proof. Do not introduce invented testimonials, client logos or office locations to make the redesigned site look more established.
Acceptance check: every important page has an agreed destination or a documented reason for retirement. No page disappears simply because it was absent from the new mockup.
Keep useful URLs when there is no reason to change them. If a page moves, map its old URL to the closest relevant new destination. Update internal navigation and links to the final URLs, rather than deliberately routing visitors through redirects.
Google’s site-move guidance recommends planning URL mappings, updating URL references and monitoring the move. It also warns that significant changes can produce temporary ranking fluctuations. A migration checklist reduces avoidable mistakes; it cannot guarantee unchanged rankings.
For permanent moves, use a supported permanent server-side redirect such as 301 or 308. Test the actual response and final destination, not just whether the browser eventually displays a page. Avoid redirect chains and loops. Google documents the available methods in its redirect guidance.
Acceptance check: the migration worksheet records each changed URL, expected destination and test result. Unrelated retired pages are not all redirected to the homepage.
Work with realistic copy early. A design approved around a three-word placeholder may break when the real service name is longer.
For US visitors, use familiar language and clearly named support time zones where relevant. Do not imply a US office or local presence unless it is true.
Acceptance check: content owners approve the actual copy, images and calls to action—not a layout filled with temporary text.
Ask someone unfamiliar with the project to find a relevant service and complete a test inquiry on a phone. Watch where they hesitate instead of explaining the interface to them.
Check keyboard navigation, visible focus, form labels, useful image alternatives and text readability. Review zoomed layouts and error messages. The W3C’s Easy Checks for web accessibility are a useful starting point, but explicitly cover only a limited review. Passing a few automated or manual checks is not a complete accessibility assessment.
Our UI/UX services guide provides additional questions for evaluating a design partner.
Acceptance check: the primary navigation and inquiry journey have been tested with keyboard access and representative mobile layouts, and unresolved issues have named owners.
Use a separate testing environment and restrict access appropriately. Keep confidential material and real customer data out of design demonstrations unless there is an authorized reason to use it.
Prepare an explicit production checklist for authentication, indexing controls, canonical URLs and environment-specific links. A staging setting accidentally copied to production can undermine an otherwise successful launch.
Acceptance check: the release owner checks the live configuration after deployment rather than assuming staging settings were replaced correctly.
Test representative service pages, articles and contact forms as well as the homepage. Large media, embeds and third-party scripts can make one template behave differently from another.
Google’s Core Web Vitals guidance covers loading performance, responsiveness and visual stability. Use those measures alongside real task testing. Good scores alone do not guarantee strong search rankings.
Record the device and test conditions so comparisons are meaningful. Review real-user data when available, and distinguish it from a single controlled test run.
Acceptance check: obvious regressions are investigated before launch, especially on the pages and devices your prospective customers use.
A success message is not proof that an inquiry reached the business. Submit a clearly labeled test through each important form and verify the full path.
If tracking is part of the scope, verify the agreed event using the site’s consent configuration and avoid duplicate firing. Do not send personal form contents into analytics events.
Acceptance check: someone in the business confirms receipt of the test inquiry and can locate its source.
Choose a release window when the required people are available. A time that is quiet for US visitors may fall outside the development team’s usual hours, so write the schedule in named time zones.
Confirm the backup covers the parts being changed and that the team knows how to restore them. Specify who can authorize a rollback and what happens to inquiries or content created after launch if restoration is needed.
Acceptance check: the launch plan identifies the decision-maker, support contacts, recovery steps and conditions that would delay release.
After deployment, test the public site without an administrator session. Check key pages, menus, images, forms and representative old URLs. Confirm the site is not displaying maintenance mode to ordinary visitors.
Review the sitemap and important page metadata. Inspect titles, descriptions and canonical destinations for accidental staging references. Verify that pages intended for search are accessible and not unintentionally marked noindex.
Acceptance check: the team records actual results from production. A successful staging test does not replace this step.
Use the following as an editorial project-review cadence, not a search-engine recovery deadline:
Investigate changes page by page. If inquiries fall, check tracking and form delivery before attributing the change entirely to rankings. If search visibility changes, examine affected URLs and indexing signals before commissioning another redesign.
Acceptance check: the project includes a review meeting and issue ownership after the visual launch is complete.
Mark each item pass, fail or not applicable, then add an owner and evidence. “Looks good” is not enough for a release decision.
Not automatically. A redesign can improve usability and technical quality, but it can also remove valuable information or introduce errors. Tie the work to identified problems and verify the result.
No. A visual change at the same URL does not by itself require a redirect. Plan redirects where content actually moves and verify the relevant destination.
There is no single dependable timeline. Content approval, integrations, migration complexity and review availability affect delivery. Ask for a phased plan with acceptance criteria instead of a date based only on page count.
Only if the benefits justify the migration work. Explain the current limitation first and compare configuration improvements with replacement. Keep the project manageable for the people who will maintain it.
A useful website redesign checklist connects design decisions to content, customer journeys and operational checks. Define success before development, test the exceptions and retain ownership after launch.
Techfusion Gear provides website design and development services. Share your current website and redesign priorities to discuss the scope, required checks and delivery plan.