If you own a site that already gets leads, sales calls, quote requests, or support traffic, this is for the moment before you approve a redesign scope. The decision is not “new look or old look”; it is which pages deserve budget first because they affect search visibility, page speed, accessibility, and buyer confidence.
Short answer: this is for business owners and marketing leads deciding what a redesign should protect first. Homepage, service, pricing, proof, and contact pages usually move ahead of low-risk archive posts because they carry buyer intent, search exposure, or lead actions. Use the 8-point score as a planning filter, not a ranking formula: it tells you which URLs need redesign attention, which need a focused fix, and which can wait.
A redesign becomes risky when every page is treated as equally important. A homepage that fails Core Web Vitals, a service page with no proof, a pricing page that hides whether the offer fits the buyer, and a contact form that is not tracked in Google Analytics 4 do not create the same risk as an old low-traffic announcement post.
Start by entering the live URL on the Website Advisor home page, then collect four inputs: performance, search exposure, analytics, and crawl status. Google Search Essentials separates technical requirements, spam policies, and key best practices[1], so your redesign priority map should separate crawlability, content usefulness, speed, accessibility, and conversion path instead of treating “redesign” as one task.
Use this 8-point triage before design work starts: score each priority URL for business action, organic exposure, defect severity, and trust proof. Trust proof means evidence that makes a buyer feel safer: a case study, review, certification, customer result, local detail, author expertise, or support answer that reduces repeat questions.
| Factor | Score | Evidence to use |
|---|---|---|
| Business action | 0 to 2 points | 0 if the page is only informational, 1 if it supports a later decision, 2 if it asks for contact, booking, purchase, quote, account creation, or fewer support questions. |
| Organic exposure | 0 to 2 points | Use Google Search Console pages and queries. Give 2 points to pages with non-branded impressions or clicks tied to a service, price, help, or comparison search. |
| Defect severity | 0 to 2 points | Give 2 points for a hard defect such as a 404, accidental noindex, broken form, missing event tracking, poor Core Web Vitals, inaccessible navigation, or a redirect problem. |
| Trust proof | 0 to 2 points | Give 2 points when the page carries evidence: case study, review, certification, customer result, local detail, author expertise, or support answer that reduces buyer risk. |
For example, a homepage might score 7: 2 for quote and booking paths, 2 for non-branded category impressions, 2 for poor mobile LCP, and 1 for visible reviews but no recent case study. A core service page might score 6 because it gets comparison-search impressions, explains the offer, and has a thin proof section; an old announcement post might score 1 because it has no current impressions, no lead action, and no meaningful defect. That example puts the homepage and service page in the first redesign phase while leaving the announcement post alone or folding it into a more useful resource later.
Score 6 to 8 first in the redesign, score 3 to 5 as a targeted fix, and score 0 to 2 as defer, merge, redirect, or leave alone. For the performance part of that score, use the web.dev Core Web Vitals good thresholds at the 75th percentile of page loads: LCP at 2.5 seconds or faster, INP at 200 milliseconds or less, and CLS at 0.1 or less across mobile and desktop[3]. PageSpeed Insights documentation can help you read field and lab data correctly: field data reflects real users when available, while Lighthouse lab data is controlled and better for debugging[2].
INP replaced First Input Delay as a Core Web Vital on March 12, 2024, according to the Chrome team’s announcement[4]. Treat that as a template risk signal: a slow hero image, heavy script, or delayed button response can make a redesign look better while making the buying path worse.
Homepage redesign priority: make the offer clear
The homepage job is clarity. Before a mobile visitor has to scroll far, a buyer should be able to name the business, the audience, the offer category, one proof point, and the next step. If the hero image, video, slider, or script stack causes the page to miss the 2.5-second LCP good threshold, the template is a redesign risk before the color palette is discussed[3].
Audit the homepage like a front desk. The navigation needs crawlable links, a real HTML heading, alt text on meaningful images, visible contact or quote paths, and no pop-up that blocks the first decision. Google Search Essentials names crawlable links, words people use in prominent page locations, and helpful content as key best practices[1]; WCAG 2.2 defines conformance at Level A, AA, and AAA, with Level AA often used as the practical target for business sites[5].
If the homepage is unclear, do not compensate by adding more menu items. Move audience language, proof, and the primary CTA into the main path, then retest mobile PageSpeed Insights and a keyboard-only pass before approving design comps.
Service page redesign priority: help buyers decide
Service pages have decision-support priority because they match problem-aware searches and sales conversations. For a page such as “WordPress maintenance,” the copy should state what is included, what is excluded, response expectations, examples of issues handled, pricing context, and the next step; “we keep your site running” is too thin to audit or sell.
Use a crawl to catch service-page basics before redesign: status code, indexability, title, H1, canonical, internal inlinks, and response time. Then check the content against Google’s helpful-content questions: evidence of expertise, clear sourcing, and whether the reader can leave knowing enough to achieve the goal[6].
For structured data, use Google’s structured-data guidelines and Schema.org as checks, not as a place to add hidden claims[7][8]. Google says structured data should describe the content on the page it applies to, so do not mark up services, reviews, prices, or FAQs that visitors cannot see.
If service URLs change, use permanent redirects and test them before launch[9]. For a redesign, the acceptance rule is one old service URL mapped to one final replacement URL, with no redirect chain and no temporary move on a page you mean to replace permanently.
Proof page redesign priority: make claims believable
Case studies, testimonials, portfolio pages, reviews, and customer stories should reduce perceived risk. A usable proof page names the starting problem, the work performed, the result, the date or period, and the evidence type. If client confidentiality blocks a name, state what can be verified: industry, company size band, platform, before-and-after screenshots, or the exact technical defect fixed.
A vague testimonial is weaker than a short example that names the problem, work, and measured outcome. If the claim is about speed, attach the PageSpeed Insights or Lighthouse report; if it is about search, attach the Search Console export; if it is about leads, attach the GA4 key-event report or CRM record. Proof without a source becomes decoration.
Do not isolate proof on a single “case studies” page and expect high-intent visitors to go find it. Move one relevant proof unit onto each service page, pricing page, and contact path where a buyer is deciding whether the next step is safe.
Pricing page redesign priority: set expectations early
Pricing pages should answer whether the offer is within reach, what affects cost, what is included, and what happens if the visitor is unsure. If final quotes vary, show a starting package, a range, a sample engagement, or the cost drivers that change the quote. Do not force every qualified visitor into contact just to learn whether the offer fits their budget and need unless that is truly the sales model.
Use GA4 before and after the redesign. Google’s GA4 event documentation defines a key event as an action important to the success of the business, so pricing-page CTA clicks, booking clicks, phone clicks, and lead-form submissions should be measured only when they reflect real buyer intent[10].
Pricing redesign acceptance should include tracking, not just layout. Confirm that the pricing CTA fires, that the next page or form loads, that the confirmation state appears, and that sales or support staff know what expectation the page set.
Contact page redesign priority: make the next step safe
The contact page should make the next step feel safe. Prioritize only the fields needed to route the inquiry, such as name, email, service needed, and a short note, then add phone, email, location, booking, and support options only where they match how the business actually responds.
Before launch, test the contact flow as a user and as a measurement event. GA4 docs say Realtime shows triggered events from the last 30 minutes, and DebugView helps verify events and parameters[10]. If the redesign changes forms, modals, phone links, or booking widgets, retest the tag and event names before moving the new template live.
The confirmation state matters. Say whether the visitor should expect an email, a call, or a calendar next step, and give a fallback route if the form fails. For high-intent pages, send visitors to service or help content only after the lead action is confirmed, not before.
Blog and resource page priority: keep useful content
Blogs, resources, and help articles should be reviewed for relevance, search intent, internal links, and business support. Google’s helpful-content guidance says not to add or remove old content mainly because you believe it will make the site seem fresh[6]. Review each post by purpose: earning qualified search, answering a sales objection, reducing support load, or documenting expertise.
Technical inventory matters here, but keep it tied to page decisions. Use a crawl and Search Console to find orphaned posts, indexed duplicates, canonical problems, and articles that still get impressions but answer yesterday’s version of the question. If a technical issue is large enough to require sitemap, robots, or crawl-budget work, make that a separate launch checklist instead of burying it inside page design.
Use this cut list: keep posts that still answer a current customer question; update posts with impressions, links, or sales value but stale details; merge posts that compete for the same intent; redirect retired URLs with permanent redirects when there is a true replacement; leave low-risk archival posts alone if they do not waste crawl paths or confuse buyers.
FAQ
Which page should I redesign first?
Start with the highest-scoring page in the triage table, usually a service, pricing, homepage, or contact URL with both buyer intent and a measurable defect. A blog post with traffic can move ahead only when it supports a service decision or has a search issue the redesign can fix.
Should every old blog post be redesigned?
No. Update pages with current search demand or sales value, merge overlapping posts, redirect retired posts to a true replacement, and leave harmless archive posts alone. Do not bulk-delete content only to make the site look fresh.
Do Core Web Vitals decide the whole redesign?
No. Core Web Vitals are one page-experience signal set, and Google Search Essentials says meeting requirements and best practices does not guarantee Google will crawl, index, or serve a page[1]. Use LCP, INP, and CLS to find template risk, then weigh proof, content, accessibility, and conversion path.
What should an agency show before asking for design approval?
Ask for the page priority score, the source exports used, the redirect map for changed URLs, the PageSpeed Insights or Lighthouse findings, the WCAG 2.2 checks for key templates, and the GA4 or tag test evidence for lead actions. If those artifacts are missing, the approval is based on taste rather than risk.
What to do next
Choose the top 10 to 20 URLs before design work starts. Score them with business action, search exposure, defect severity, and trust proof; fix or redesign the 6-to-8 pages first; and keep a launch checklist for redirects, tracking, accessibility, and performance. A good redesign does not make every page new. It protects the pages that create confidence, then cleans up the rest with evidence.
Editor’s note
As of April 23, 2026, the Core Web Vitals thresholds, structured-data requirements, and accessibility guidelines above are summarized from Google Search Central, web.dev, and W3C WCAG[1][3][5]. Google periodically updates thresholds and ranking signals; verify the current docs before acting on audit results.
Sources
- Google Search Essentials — technical requirements, spam policies, and search best practices: https://developers.google.com/search/docs/essentials
- PageSpeed Insights documentation — field data, lab data, and Lighthouse reporting: https://developers.google.com/speed/docs/insights/v5/about
- web.dev Core Web Vitals — current good thresholds and 75th percentile guidance: https://web.dev/vitals/
- Chrome and web.dev INP announcement — INP became a Core Web Vital on March 12, 2024: https://web.dev/blog/inp-cwv-march-12
- W3C WCAG 2.2 conformance — accessibility conformance levels: https://www.w3.org/TR/WCAG22/#conformance
- Google helpful content guidance — content usefulness and self-assessment questions: https://developers.google.com/search/docs/fundamentals/creating-helpful-content
- Google structured data guidelines — visible content and structured-data policies: https://developers.google.com/search/docs/appearance/structured-data/sd-policies
- Schema.org — structured data vocabulary reference: https://schema.org/
- Google redirect guidance — permanent redirects and URL changes: https://developers.google.com/search/docs/crawling-indexing/301-redirects
- Google Analytics events and DebugView — key events, Realtime, and event testing: https://support.google.com/analytics/answer/9322688