For a small-business owner, in-house marketer, solo founder, or agency account manager, this website redesign checklist is for an existing site that no longer matches the business. The decision is not "Does the site look old?" It is "Do we redesign now, repair the highest-risk pages first, or rewrite the site around a changed buyer?"
Maintenance note: Search guidance, Core Web Vitals, structured-data eligibility guidance, analytics terminology, and accessibility standards change over time. Use the Sources section to verify current documentation before turning audit results into launch requirements.
Quick decision framework
- Redesign now when positioning, service structure, proof, CTAs, templates, performance, accessibility, and measurement all point to the old business.
- Repair key pages first when the brand still fits but the homepage, main service pages, or conversion path are creating avoidable risk.
- Rewrite around the new buyer when the design system is usable but the words, proof, and next step describe the customer you used to serve.
An existing website usually becomes inaccurate because the business changed, not because the color palette got old. The brand matured. Services shifted. Customers changed. Pricing moved. The sales process became more consultative. The old site may still load, but it may now send Google, buyers, and your sales team the wrong version of the company.
In redesign audits, the breakage is usually practical: the menu names a service the team no longer sells, the top CTA sends enterprise buyers into a generic contact form, the case studies prove the old offer, and analytics still rewards the wrong action. Those mismatches are easier to miss than a slow page or dated typography because each one used to be true.
Before opening design files, compare the live site with current search, performance, accessibility, proof, and conversion expectations. Use primary sources when an audit finding affects a launch decision, but keep the planning conversation centered on what changed in the business.
Start with positioning
If the audience changed, the homepage and service pages need new positioning before anyone chooses layouts. Do not only swap logos, colors, or photos. Rewrite the primary message around the current buyer, the problem they recognize, the decision they are trying to make, and the outcome the business can now prove.
For search and for buyers, use the words people would use to look for the service and place them where decisions happen: title, H1, opening copy, alt text, navigation labels, and CTA text.[1] For a redesigned service page, that means the page title, main heading, opening paragraph, navigation label, and CTA should use the buyer’s language, not the internal team name for the offer.
Example: a firm that used to sell "tax preparation" but now sells "fractional CFO advisory" should not keep a homepage that leads with seasonal filing help. The new page needs to name the advisory buyer, explain the business decision they face, show the current service model, and route high-intent visitors to a consultative next step.
A redesign without positioning work preserves the wrong story in a cleaner template. If the buyer, offer, or buying motion changed, rewrite the core message before approving the visual direction.
Re-map services
Service changes often break old navigation. New packages, discontinued offers, bundles, industries, locations, or pricing models can make the menu inaccurate even when every page still returns a valid status code.
Inventory the current pages before drawing a new sitemap. A crawler such as Screaming Frog SEO Spider can export URLs, page titles, status codes, canonicals, headings, and redirect chains.[5] Add a human column for the current business decision: keep, rewrite, merge, redirect, or remove.
| Current page situation | Redesign decision | Rule to apply |
|---|---|---|
| The service still exists and attracts the right buyer. | Keep and rewrite. | Update the positioning, proof, CTA, title, H1, and internal links. |
| The service exists, but the buyer or package changed. | Rewrite around the new decision. | Do not leave old offer language in the navigation, pricing copy, FAQ, or schema. |
| Two pages now answer the same buyer question. | Merge into one stronger page. | Pick one canonical destination and update internal links to that page. |
| A discontinued service has a close current replacement. | Redirect to the closest useful page. | Use a permanent redirect when the move should last.[6] |
| A page is obsolete and has no useful replacement. | Remove it from the active journey. | Do not use robots.txt as a hiding tool; blocked URLs can still be discoverable and the page remains active for users.[7] |
The buyer should not have to understand your departments to choose a service. If the menu contains labels your current prospects do not use on sales calls, the information architecture is still describing the old company.
Update proof
Old proof can point to the wrong market. A testimonial from an early customer may be good history but weak evidence for an enterprise buyer, a regulated buyer, or a higher-ticket advisory service. Review proof by matching each item to the current offer, buyer type, objection, and page where it appears.
Use a simple proof matrix: testimonial, case study, screenshot, metric, review, certification, founder credential, before-and-after example, or named client permission. Then mark whether each item supports the current buyer. If proof only explains what the company used to sell, move it to an archive, rewrite the surrounding context, or replace it.
One common audit pattern is a homepage that claims a larger, more strategic offer while every proof point still shows small one-off projects. That gap makes the redesign feel polished but unearned. The fix is not more animation; it is proof that answers the current buyer’s risk questions.
Structured data should follow the same rule. Schema.org gives the vocabulary, but Google’s structured data guidelines require the markup to match visible page content and do not guarantee rich results.[8][9] If the redesigned page claims a service, location, review, or organization detail in JSON-LD, the visible page should support that claim.
For a local or regional service business, check whether the home page and location pages still describe the correct legal name, address, phone, service area, opening hours, and primary offer. Use Organization or LocalBusiness structured data because it fits the page, not because it sounds more impressive.[10][11]
Change calls to action
If the sales process changed, the CTAs need to change too. A simple contact form may be wrong for a demo motion. A free consultation may be too broad for a higher-ticket advisory service. A newsletter signup may be too soft for a high-intent service page that should lead to a call, quote, audit, or account creation.
Measurement has to change with the CTA. In GA4, important actions are key events, so the redesign brief should define which actions prove the new model is working: booked calls, qualified form submissions, account creation, quote requests, or checkout starts.[12]
For implementation planning, name the event before the design is built. A lead-generation site might track a form submission as a key event. A product-led site might track account creation. A consultative service site might track booked calls. Google Tag Manager uses tags, triggers, variables, and the data layer, so the redesign brief should say which page action fires which measurement event.[13]
| Business change | Old CTA risk | Better redesign decision |
|---|---|---|
| Sales moved from quick quote to consultative discovery. | "Contact us" gives no context. | Use a page-specific booking or inquiry CTA with qualifying fields. |
| Product now has a self-serve account path. | "Learn more" delays action. | Give high-intent visitors a direct account or trial path. |
| Service is now higher-ticket. | "Free consultation" may attract poor-fit leads. | Set expectations with fit criteria, proof, and a stronger inquiry form. |
The CTA should match the next real step in the current sales process. If the sales team no longer wants the leads a page creates, that page is part of the redesign problem.
Retire outdated content
Old blog posts, service pages, landing pages, and FAQs can keep sending visitors to the wrong version of the company. The cleanup decision is not "keep everything for SEO." It is "keep, rewrite, merge, redirect, or remove based on current usefulness and search intent."
Start with pages that describe discontinued services, old pricing, retired locations, outdated process claims, old team credentials, or unsupported guarantees. If a page still attracts the right audience, rewrite it. If it competes with a stronger current page, merge it. If it has a close replacement, redirect it with a permanent server-side redirect. If it has no current buyer purpose, remove it from the active content plan and update internal links.
The common failure pattern is not deletion; it is silent survival. Old pages stay indexable, remain in internal links, keep attracting leads for a retired offer, and then get blamed on the redesign when reporting becomes noisy. Decide what each important URL should do before migration, then make redirects, canonicals, navigation, XML sitemaps, and internal links agree.
Content cleanup belongs in planning, not in the last week before launch. A redesign that moves old confusion into new templates can make reporting harder, split canonical signals, and leave sales teams explaining pages that should have been retired.
Build the redesign brief from change
The best redesign brief names what changed and what the new site must do differently. Without that, the project becomes visual preference, and the team debates fonts while outdated offers, weak proof, poor performance, missing accessibility checks, and wrong CTAs stay in place.
Use this mini-workflow before approving a redesign scope:
- Audit the current live site and note the pages that deserve manual review.
- Write one sentence for what changed in brand, buyer, services, proof, and sales process.
- Run the homepage, main service page, and primary conversion page through PageSpeed Insights on mobile and desktop.[3]
- Record Core Web Vitals, accessibility issues, indexable pages, outdated proof, and current CTAs before choosing layouts.
- Create a page decision table with keep, rewrite, merge, redirect, or remove for each important URL.
- Define launch acceptance criteria for SEO, performance, accessibility, analytics, and conversion tracking.
Working through an existing site? Run the current domain in Deep Digital Ventures Website Advisor after the first page inventory, then use the output as a discussion starter for the pages that deserve manual review.
The performance criteria should be explicit, but not performative. For the main templates, use Core Web Vitals as launch acceptance checks: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint at 200 milliseconds or less, and Cumulative Layout Shift at 0.1 or less at the 75th percentile.[2] If only one key template fails, repair that template before turning the whole project into a full redesign.
PageSpeed Insights is useful because it combines field data with Lighthouse lab diagnostics, but treat it as evidence, not the whole brief.[3] A score cannot tell you whether the offer, proof, or CTA is still right for the buyer.
Accessibility needs the same specificity. WCAG 2.2 organizes conformance into Level A, Level AA, and Level AAA. For most small-business redesign briefs, Level AA is the practical target to discuss with designers and developers because it includes Level A and AA success criteria and is widely used as the working accessibility benchmark.[4]
A useful redesign brief should end with acceptance checks, not mood words. Name the pages that must rank, the pages that must convert, the proof that must be visible, the analytics events that must fire, the redirects that must exist, the schema that must match visible content, and the Core Web Vitals and WCAG targets the build team is expected to test.
FAQ
Do we need a full redesign if only the services changed?
Not always. If the visual system still works and the problem is mostly service language, navigation, CTAs, and proof, a focused rewrite plus information architecture cleanup may be enough. A full redesign makes more sense when positioning, templates, conversion paths, performance, and accessibility all need work at the same time.
Should we redirect or delete old service pages?
Decide by current buyer purpose. Rewrite pages that still match demand. Merge pages that duplicate a better current page. Use a permanent redirect when there is a close replacement. Remove pages that create confusion and have no useful successor, then update the internal links that used to point there.
What should be tested before launch?
Test the pages that matter most to ranking, selling, and measurement. That usually means the homepage, core service pages, location pages, high-traffic legacy URLs, primary forms, booking paths, account paths, redirects, structured data, Core Web Vitals, accessibility checks, and analytics events.
Sources
- Google Search Essentials: baseline guidance for making content findable and understandable. https://developers.google.com/search/docs/essentials
- web.dev Web Vitals: Core Web Vitals definitions and thresholds. https://web.dev/articles/vitals
- PageSpeed Insights documentation: field data and Lighthouse lab diagnostics. https://developers.google.com/speed/docs/insights/v5/about
- W3C WCAG 2.2: accessibility conformance reference. https://www.w3.org/TR/WCAG22/
- Screaming Frog SEO Spider user guide: crawler exports for URL inventory. https://www.screamingfrog.co.uk/seo-spider/user-guide/
- Google redirect guidance: permanent redirect handling. https://developers.google.com/search/docs/crawling-indexing/301-redirects
- Google robots.txt introduction: what robots.txt can and cannot block. https://developers.google.com/search/docs/crawling-indexing/robots/intro
- Schema.org: structured data vocabulary. https://schema.org/
- Google structured data guidelines: visible content and rich result eligibility guidance. https://developers.google.com/search/docs/appearance/structured-data/sd-policies
- Google Organization structured data: organization markup guidance. https://developers.google.com/search/docs/appearance/structured-data/organization
- Google LocalBusiness structured data: local business markup guidance. https://developers.google.com/search/docs/appearance/structured-data/local-business
- GA4 key events documentation: marking important actions as key events. https://support.google.com/analytics/answer/13128484
- Google Tag Manager overview: tags, triggers, variables, and data layer planning. https://support.google.com/tagmanager/answer/6103657