A useful website redesign checklist protects what already works before changing how the site looks. Save your current evidence, map pages and customer paths, build against an approved brief, prove the important functions, launch with a rollback plan, and watch real results afterward. For a service business, the first priority is keeping calls, forms, appointments, search visibility, and measurement working throughout the change.
That sequence can be remembered as Baseline, Map, Build, Prove, Launch, Watch. It turns a redesign from a collection of visual opinions into a controlled business project.
What Should You Save Before a Website Redesign?
Save the current site’s pages, performance evidence, lead paths, and access details before anyone removes or rewrites them. This baseline shows what deserves protection and gives you something concrete to compare after launch.
Begin with a complete list of public URLs. Mark each page’s purpose, owner, important links, and whether it receives useful search traffic or qualified inquiries. Include images, downloadable documents, thank-you pages, campaign landing pages, and old URLs that still receive visits. Do not assume the navigation contains everything worth keeping.
Export a recent baseline from analytics and Google Search Console. Record traffic and conversions for the pages that matter, but also record business outcomes your reporting may not show, such as qualified calls, booked estimates, and appointment requests. A form submission count is not enough if messages have been reaching the wrong inbox.
Inventory every customer path:
- Phone numbers and tap-to-call links
- Contact, quote, referral, and support forms
- Scheduling tools, payment links, chat, and customer portals
- Confirmation pages, emails, text messages, and internal notifications
- Analytics, advertising, call tracking, and consent tools
Finally, list who controls the domain, hosting, content management system, analytics, Search Console, integrations, and third-party accounts. Confirm that the business owns or can recover each account. A redesign can be technically finished and still be unsafe to launch if nobody can change domain settings or restore the previous site.
What Should Be in the Redesign Brief?
The redesign brief should define the business job of the site, the people it serves, the pages and actions it needs, and the evidence required for approval. It should also state what the project will not change.
Name the primary audience and the main action for each important page. A residential electrician’s service page may need to confirm the work offered, the area served, and the next step for requesting an estimate. Its job is not simply to look modern. If separate location content is planned, use a clear service-area page planning guide instead of creating interchangeable city pages.
Define these decisions before design work expands:
- Which current pages will stay, merge, move, or be retired
- Which offers, service areas, phone numbers, hours, and business facts are authoritative
- Who supplies copy, photos, credentials, and approvals
- Which forms and integrations must work at launch
- Which analytics events and advertising destinations must remain consistent
- Which accessibility standard and review process guide the build
- Who may approve design, content, technical readiness, and launch
Create a simple control record for every critical requirement. Give each item an owner, a test, acceptable proof, and an effect on launch. A screenshot can prove a layout review, but a submitted test lead with a matching inbox or customer relationship management record is better proof that a form works.
The World Wide Web Consortium describes the current Web Content Accessibility Guidelines around four principles: content should be perceivable, operable, understandable, and robust. State the target and how it will be evaluated. Avoid vague promises that one plugin or automated scan will make the whole site accessible.
If the brief itself is difficult to assemble, Website Genii’s website design and development work can help connect strategy, copy, development, forms, tracking, and launch testing around one plan.
How Do You Redesign a Website Without Losing SEO?
Preserve useful content and map every changed URL to its closest relevant destination before launch. No checklist can guarantee unchanged rankings, but careful mapping, crawl checks, and monitoring reduce avoidable losses.
For every current URL, choose one outcome: keep it, move it, merge it into a genuinely relevant page, or retire it. When a page moves, record the old and new addresses in one redirect map. Do not send every deleted page to the home page. Google’s site-move guidance recommends server-side permanent redirects when possible and warns against irrelevant destinations and redirect chains.
Preserve the substance people already value. A new layout does not justify deleting a useful answer, project example, title, or internal link. Update weak material when evidence supports the change, but keep a copy of the old version so the team can explain what changed.
Before launch, check that:
- Permanent redirects point directly to the final useful destinations
- Navigation and body links use the new URLs rather than relying on redirects
- Each page declares the intended canonical URL
- Page titles, descriptions, headings, and meaningful image alt text are present
- Temporary passwords,
noindexinstructions, and crawler blocks are removed from public pages - The XML sitemap contains the preferred live URLs
- Search Console ownership will still work after a platform or domain change
Google advises keeping site-move redirects for at least a year and says keeping them longer can help users who follow old links. Its redirect documentation also explains that permanent redirects are a signal that the new target should be treated as the canonical location.
Treat search preservation as part of the wider SEO and measurement plan, not as a launch-day plugin setting. If the domain, hosting, content system, URLs, and copy are all changing, separate the decisions where practical so a later problem is easier to diagnose.
What Must Be Tested Before Launch?
Test complete customer journeys on representative phones and computers, then retain evidence of the result. A page can look finished while its form, tracking, consent controls, or follow-up fails.
Start with real tasks. Ask a tester who was not closely involved in the build to find a service, confirm coverage, call the business, submit a quote request, schedule when applicable, and return to the home page. Use safe test data that staff can recognize and remove. Confirm both what the visitor sees and what the business receives.
For every lead form, verify required fields, validation, spam controls, consent text, successful delivery, confirmation messages, routing, and duplicate behavior. Test an integration outage or unavailable calendar if the workflow supports it. The site should not promise that a request was received when the connected system rejected it.
Check the technical surface too:
- Crawl the staging or launch candidate for broken links and missing files
- Test old URLs against the redirect map
- Confirm that error pages return the correct response instead of appearing successful
- Review page titles, canonicals, robots instructions, sitemap entries, and structured data
- Verify analytics and advertising events without counting internal tests as real leads
- Check phone numbers, email links, maps, hours, service areas, and social profiles
- Review keyboard use, focus visibility, headings, labels, contrast, zoom, and text alternatives
W3C’s Easy Checks offer a practical first review for issues such as image alternatives and keyboard access. W3C also makes clear that these checks are not a complete accessibility evaluation. Combine automated findings with human testing and qualified review appropriate to the site’s risk and audience.
Performance testing should use both lab checks and real-user evidence when available. The current Core Web Vitals cover loading, interactivity, and visual stability through Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. Use those measures to find experience problems rather than treating a score as proof that the site is effective.
Verify measurement independently. Google Analytics Help explains how Tag Assistant can confirm that the Google tag is present and sending events. Then confirm that the event name, destination, and business record match the intended action.
Who Can Approve Launch, and What Is the Rollback Plan?
One named decision maker should approve operational launch only after the required proof is complete. Design approval, content approval, and permission to replace the live site are different decisions.
Create a short launch record that names the release version, decision maker, technical lead, business contact, planned window, current backup, rollback steps, and conditions that stop or reverse the launch. A missing hero image may be repairable after launch. Broken quote delivery, incorrect phone routing, a site-wide indexing block, or an unavailable customer portal may justify rollback.
Keep the previous site, database, configuration, and redirect map available long enough to support recovery. Confirm that the backup can actually be restored and that the person on duty has permission to do it. Do not discover during an outage that the only administrator is unavailable.
Freeze avoidable edits near launch. If copy, integrations, tracking, and design all keep changing during final tests, the proof applies to an earlier version rather than the release. Record last-minute changes, retest affected paths, and require another launch decision when the risk changes materially.
What Should You Monitor After the Redesign Goes Live?
Watch availability, customer actions, measurement, and search discovery on a written schedule. Launch is the start of verification, not the end of the project.
During launch, test the home page, priority services, forms, phone links, appointments, redirects, analytics events, and error responses on the public domain. Check security certificates and the preferred version of the domain. Review server or platform errors before declaring the release stable.
During the first 72 hours, send fresh test leads through every important path and confirm that staff receive them. Look for broken links, missing images, slow pages, consent conflicts, duplicate notifications, and unexpected changes to business information. Compare live behavior with the control record instead of relying on memory.
Use Search Console’s URL Inspection tool to test important pages and investigate indexability problems. Review crawl and indexing reports for patterns, not just one URL. Search processing takes time, so separate confirmed technical failures from normal delay and short-term fluctuation.
For the first 30 days, compare the same business measures captured in the baseline:
- Qualified calls, forms, appointments, and wrong-fit inquiries
- Conversion-path errors and manual corrections
- Traffic and search visibility for priority pages
- Redirect use, not-found errors, and index coverage
- Mobile usability and real-user performance
- Staff or customer reports of missing information
Do not credit or blame the redesign for every change. Advertising, seasonality, staffing, demand, and tracking changes can move the numbers too. Investigate the path, evidence, and timing before drawing a conclusion.
Treat the Redesign as a Controlled Business Change
A redesigned site is ready when its important claims, paths, and controls have evidence behind them. Use Baseline, Map, Build, Prove, Launch, Watch to protect existing value while improving the experience. Keep one owner for each critical item, require proof before launch, and keep monitoring after the visual work is finished.
If you want an accountable plan for content, design, development, search, forms, and launch, plan your website redesign with Website Genii.