Website Redesign Checklist: What Must Survive?
Use this website redesign checklist to preserve URLs, search visibility, forms, analytics, accessibility, accounts, and lead paths during a rebuild.
The question
What should a small business preserve during a website redesign?
Short answer: Preserve the URLs and pages that already earn visibility or leads, along with their useful content, metadata, internal links, forms, analytics, structured data, accessibility, account ownership, and integrations. Change a URL only for a clear reason, then send the old address to the most relevant new page with a permanent server-side redirect.
A website redesign should improve the experience without accidentally erasing the parts that already work. Before changing the layout, inventory the pages, search visibility, lead paths, measurement, integrations, and account access the current site depends on. Then decide what to keep, improve, merge, redirect, or retire.
SimpleLaunch plans service-business redesigns around preservation, testing, and accountable handoff so a visual improvement does not erase working search and lead paths.
If the business has not decided whether it needs a rebuild at all, start with the seven signs a business website is outdated and separate isolated repairs from problems that repeat across the site.
The safest rule is simple: preserve a useful URL unless there is a clear reason to change it. A cleaner menu or new content system does not require every page address to change. When a URL must move, map it to the closest relevant replacement and test the redirect before launch.
What should survive a website redesign?
A service-business redesign should preserve every useful page, URL, search signal, lead path, measurement tag, integration, account, accessibility feature, and recovery option that still serves customers or operations:
- Pages that receive qualified search traffic, referrals, calls, forms, or bookings.
- Public URLs, page titles, descriptions, headings, internal links, canonicals, and useful structured data.
- Contact forms, phone links, scheduling paths, downloads, payment links, and CRM handoffs.
- Analytics tags, conversion events, Search Console verification, consent settings, and campaign parameters.
- Domain, DNS, hosting, content, media, business profiles, and recovery access controlled by the business.
- Accessibility features, responsive behavior, readable content, keyboard access, labels, and error messages.
- A tested backup and a documented way to restore or roll back the site.
Not everything deserves to survive. Thin duplicate pages, outdated offers, unsupported claims, broken integrations, and inaccessible interactions may need to be replaced. The point of an inventory is to make those choices deliberately instead of discovering losses after launch.
1. Build an inventory before designing pages
Start with a spreadsheet or simple table. List every indexable URL, its purpose, the audience it serves, and the action a visitor should take. Add whatever evidence is available: search impressions and clicks, analytics traffic, form submissions, calls, bookings, backlinks, or direct feedback from staff.
Give each URL one decision:
- Keep: The URL and purpose stay substantially the same.
- Improve: The URL stays, but the content or experience changes.
- Merge: Multiple pages become one stronger page, with old URLs redirected to it when relevant.
- Move: The page needs a new address and a one-to-one redirect.
- Retire: The content has no useful replacement and should return a proper not-found response.
Do not judge a page only by last month's traffic. A seasonal service page, warranty explanation, client portal, or campaign landing page can be valuable even when it is quiet during the review period. Ask sales and operations which pages answer recurring questions or support work after the initial lead.
2. Keep URLs stable or create a redirect map
Google's current site-move guidance recommends preparing and testing the new site, mapping old URLs to their new destinations, using permanent server-side redirects, updating internal links, and monitoring both versions. A small or midsize site may still fluctuate while Google recrawls and processes the move.
For every changed URL, record the old address, the final new address, redirect status, responsible person, and test result. Avoid sending every retired page to the homepage. An old service page should point to the closest useful replacement; if none exists, a real 404 or 410 response is clearer than an irrelevant redirect.
Keep redirects in place long enough for people and search systems to learn the new locations. Google generally recommends at least one year and notes that keeping them longer can continue helping visitors who use old links. Update your own navigation and body links immediately so they point directly to final URLs rather than passing through redirects.
3. Preserve useful content and search signals
A redesign can change presentation without discarding the language customers use to find and understand the business. For each important page, compare the old and new versions for:
- The service, location, audience, or question the page addresses.
- Specific details that make the answer credible and useful.
- Title tag, meta description, main heading, subheadings, image alternative text, and canonical URL.
- Internal links into and out of the page, with descriptive anchor text.
- Valid structured data that still matches visible content.
- Spanish or other language alternates, including reciprocal language links.
Do not copy every old sentence merely to preserve rankings. Keep the intent, accurate facts, proof, and useful depth. Remove stale claims and consolidate repetition. If a high-performing page is changing substantially, save the old copy and screenshots so you can compare what disappeared if performance drops.
The related guide to a website design consultation explains which content, ownership, and migration questions should be resolved before work begins.
4. Test the complete lead path
A beautiful page is not finished if the inquiry never reaches the business. List every conversion path before the rebuild: contact form, click-to-call button, appointment calendar, estimate request, email link, payment page, download, live chat, and newsletter signup.
Test each path on the new site with realistic data. Confirm required fields, validation, consent language, thank-you states, automated replies, notifications, spam handling, calendar availability, CRM records, and owner assignment. Check that private form data does not appear in public URLs, analytics fields, or browser error messages.
Do not stop at a success screen. Confirm the business actually receives the submission and knows who responds. If automation routes the lead, test a normal case and at least one exception such as missing information, an out-of-area request, or a failed integration.
5. Carry measurement and verification forward
Record the analytics property, tag manager container, Search Console verification method, advertising pixels, consent platform, and conversion definitions before launch. The business should control the primary accounts and invite providers with appropriate access.
On the new site, verify that page views and important events arrive without duplicate firing. Google Analytics provides DebugView to inspect events and their parameters during testing. Compare form, call, booking, and payment events with their actual outcomes rather than trusting that a tag loaded.
Keep Search Console ownership intact, submit the current sitemap, and monitor indexing and query changes after launch. Google's sitemap guidance says a sitemap is a hint, not a guarantee of crawling or indexing, so it complements working links and crawlable pages rather than replacing them.
6. Preserve accessibility and real-device behavior
Accessibility belongs in the redesign plan, not in a last-minute overlay. W3C's guidance for planning and managing web accessibility recommends integrating accessibility throughout the process, assigning responsibility, evaluating early, and monitoring over time.
Retest keyboard navigation, visible focus, heading order, form labels, validation errors, color contrast, text resizing, link purpose, alternative text, captions, and reduced-motion behavior. Use automated checks to catch repeatable issues, then perform human checks for tasks a scanner cannot understand.
Test the priority pages and lead paths on actual small screens as well as a desktop browser. Check menus, sticky buttons, long headings, form keyboards, phone links, embedded calendars, and loading behavior on a slower connection. Preserve any current accommodation that helps customers complete a task, even if the new visual system implements it differently.
Before changing the header, use the service business website navigation guide to decide which services, locations, proof, resources, and contact action need a clear route on both desktop and mobile.
7. Confirm ownership, backups, and rollback
Before launch, name the owner of the domain registration, DNS, hosting project, repository or site account, analytics, Search Console, email delivery, booking tools, CRM, and paid applications. Record renewal contacts and recovery methods. Use individual invitations and multifactor authentication where available instead of sharing one password.
Take a recoverable backup of content, media, data, DNS records, redirects, and configuration before the cutover. A backup is useful only if someone knows how to restore it. Define the conditions that trigger a rollback, who can authorize it, and how long the old environment will remain available.
The guide to website design and hosting covers account control, backups, hosting changes, and a usable provider handoff in more detail.
8. Run a launch and post-launch check
Before switching traffic, crawl or manually inspect the new site for broken links, missing assets, redirect chains, accidental noindex rules, blocked resources, incorrect canonicals, and staging URLs. Test priority pages, language alternates, navigation, forms, phone numbers, booking routes, analytics events, and error pages.
Global components deserve their own review because one stale route or claim can appear across the site. Use the service business website footer checklist to verify business details, priority links, policies, accessibility routes, and the final contact action before launch.
After launch:
- Open every priority URL and test its main action.
- Test all planned redirects to their final destinations.
- Confirm robots rules, canonicals, language annotations, and the sitemap use production URLs.
- Watch server errors, Search Console, analytics, conversions, and staff reports.
- Compare the first days and weeks with a reasonable pre-launch baseline.
- Fix technical failures first; do not reverse the whole redesign because normal search fluctuation appears immediately.
If you are deciding between a self-serve platform and professional help, read the comparison of AI website builders and professional designers. Migration responsibility matters more than the tool used to draw the new pages.
Website redesign checklist summary
The parts that must survive are the ones that help customers find, trust, contact, and work with the business. Preserve useful URLs and content, map necessary changes, verify every lead route, carry measurement and account control forward, retest accessibility, and keep a rollback path.
SimpleLaunch plans and builds service-business websites around those operating requirements. Explore our website design approach to see how strategy, content, search foundations, testing, launch, and handoff fit together.