Improve individual pages when problems are local. Redesign shared templates or the enquiry journey when obstacles repeat. Rebuild only when demonstrated structural constraints prevent a reliable repair. This website redesign checklist helps you choose the smallest effective scope before commissioning work. Website age and dated styling alone do not justify replacing a working system.
Start with three possible scopes
- Page improvement: correct missing information, unclear instructions or isolated layout problems.
- Template or journey redesign: change repeated page layouts, navigation or the steps from product discovery to enquiry.
- Rebuild: replace the underlying website implementation because it cannot reliably support agreed requirements.
A redesign need not change the platform or page addresses. Local repairs limit disruption but can leave shared problems untouched. A journey redesign addresses repeated friction without replacing everything. A rebuild can remove structural limitations, but adds content transfer, testing, training and migration responsibilities. Ask suppliers which demonstrated constraint makes the larger scope necessary.
Audit customer tasks before discussing layouts
Choose realistic tasks: find a suitable product, check delivery coverage, understand ordering requirements or request a quote. Observe representative customers attempting them without coaching, using relevant devices and connection conditions. Record hesitation, missing information, errors and assistance needed. Small samples reveal possible obstacles; they do not establish how frequently every customer encounters them.
- Task: write the customer’s goal, such as finding packaging suitable for a particular load.
- Entry page: record where the attempt starts, including search landing pages rather than only the homepage.
- Required information: list specifications, availability, location coverage or other facts needed to decide.
- Next action and completion: define the intended action and evidence of success, such as a received quote request.
- Business owner: name who maintains the information and handles the resulting enquiry.
Classify each obstacle as page content, a shared component, information architecture, a platform or integration constraint, or an internal process. Information architecture means how content is grouped and labelled. Check representative mobile pages, forms, editing tasks and enquiry delivery. An unanswered sales inbox is primarily an ownership problem, not evidence that the website needs rebuilding.
W3C’s preliminary accessibility checks cover issues including headings, contrast, keyboard access, visible focus and form labels. They are a starting point, not proof of comprehensive accessibility. [1] Test whether people can understand and complete the actual journey as well; technically operable controls can still have confusing instructions.
Google’s good Core Web Vitals thresholds are LCP at most 2.5 seconds, INP at most 200 milliseconds and CLS at most 0.1. These measure loading, responsiveness and visual stability, assessed at the 75th percentile of field visits, separately for mobile and desktop. [2] They do not measure customer understanding or lead quality; sparse field data also limits diagnosis.
Use a decision table, not a redesign score
The following findings and responses are hypothetical editorial recommendations, not official thresholds. Do not count failures until a rebuild wins. Several missing descriptions may be straightforward repairs, while one unsupported business-critical integration may warrant structural change. Investigate the cause, then specify an acceptance test: the evidence that the proposed work has succeeded.
| Observed problem | Initial intervention | Evidence before escalation | Acceptance test |
|---|---|---|---|
| Missing product specifications | Improve affected content | Required fields cannot be maintained consistently | Buyers find necessary specifications without help |
| Confusing enquiry form | Repair labels, steps and confirmation | Existing form cannot support required behaviour | Customer submits; sales receives the correct details |
| Navigation fails across pages | Repair the shared navigation | Shared component cannot be repaired reliably | Representative routes work by touch and keyboard |
| Categories confuse buyers | Test new grouping and labels | Current structure cannot support the tested approach | Buyers locate suitable products without coaching |
| Poor performance | Diagnose shared assets and scripts | Feasible repairs cannot meet agreed requirements | Relevant field metrics improve without breaking tasks |
| Essential updates are difficult | Improve editing workflow | Required changes remain blocked or unsafe | Staff complete representative updates independently |
| Dated appearance | Consider a visual refresh | Evidence of a wider customer or operational obstacle | Visual changes preserve successful customer tasks |
| Broken tracking | Repair measurement | Verified measurement remains technically unsupported | Test actions produce correct, non-duplicate records |
Compare repair and rebuild estimates against equivalent requirements: content preparation, integrations, accessibility testing, measurement, migration, training and maintenance. Include internal staff effort and exclusions. A cheaper proposal may simply omit essential work. For the cost questions to ask, see What shapes the cost of a business website? at /insights/website-development-cost.
Hypothetical example: improve a Pune supplier’s quote journey
Assume a Pune industrial-packaging supplier uses a catalogue-and-enquiry website. Buyers cannot find dimensions or minimum order quantities. Its quote form loses product context, a floating contact button obscures mobile controls, and sales ownership is unclear. Assume the existing editing system supports structured product details and revised shared layouts. This is an invented scenario, not client work.
- Product details: add consistent material, dimensions, applications and ordering requirements.
- Quote context: carry the selected product into the enquiry and request information needed for the next sales action.
- Mobile controls: remove the obstruction and verify touch and keyboard access.
- Sales ownership: assign a recipient, confirm receipt and define what makes an enquiry suitable.
- Language needs: ask customers which languages they need, then confirm staff can maintain those versions.
The proportionate choice is a product-template and quote-journey redesign, not a rebuild. That recommendation changes if investigation demonstrates that required product data, safe editing or reliable enquiry delivery cannot be supported. Require evidence through representative tasks, not a supplier’s preference for another platform. No improvement or commercial result is assumed here.
Set a baseline and measure useful outcomes
Define measures before release and keep definitions stable. Agree how sales will identify and deduplicate qualified enquiries. Telephone and WhatsApp clicks indicate contact intent, not confirmed conversations or leads. Keep observed customer-task samples separate from site-wide rates, and record measurement gaps caused by consent choices, blocked tracking or missing sales records.
| Measure | Definition | Purpose |
|---|---|---|
| Observed task completion | Unaided successful attempts ÷ observed attempts; record counts | Check whether the obstacle remains |
| Confirmed form completion | Measured sessions with successful submission ÷ measured sessions starting the form | Assess the enquiry journey |
| Unique qualified enquiries | Deduplicated qualified enquiries; also divide by unique received enquiries | Track useful volume and suitability |
| Submission delivery | Test submissions received correctly ÷ test submissions sent | Verify delivery immediately after release |
| Field performance | LCP, INP and CLS at the 75th percentile, by device | Monitor real visitor experience |
| Maintenance effort | Staff time and failures for comparable updates | Check operational practicality |
Google documents generate_lead for generated leads and qualify_lead for leads meeting qualification criteria. [3] Our recommendation is to trigger them only at confirmed generation and agreed qualification stages. Verify event behaviour and parameters using Realtime or DebugView. [4] An arriving event proves that tracking fired, not that sales received a useful enquiry.
Set acceptance criteria before release, test enquiry receipt immediately and compare equivalent periods. Review landing pages, devices and channels; note campaigns, holidays, stock availability and sales-process changes. Before-and-after differences do not prove causation. Low traffic may not support a decisive short A/B test, so combine task observation, delivery checks and enquiry quality. Keep, revise or escalate based on that evidence.
If rebuilding is justified, require proof and plan the transition
Require a replacement prototype to demonstrate important customer and editing tasks before approving the full build. If URLs change, prepare old-to-new mapping, relevant permanent redirects, updated internal links and sitemaps, checks for unintended search blocking, and post-launch monitoring. Google’s migration guidance supports these precautions; it does not establish that rebuilding is necessary. [5]
Use the dedicated search-transition guide at /insights/website-redesign-seo-checklist when planning URL changes. Your next step is a one-page decision record: chosen scope, supporting observations, constraints, responsible owner and acceptance criteria. Ask suppliers to estimate against that record. This makes proposals comparable and gives the team a clear basis for reviewing the result.
Common decision questions
Does an outdated appearance matter if the website works?
It can matter when poor legibility, inconsistent presentation or missing current information undermines decisions. Investigate those effects rather than treating an old visual style as automatic evidence for a rebuild. A restrained refresh may be enough.
What evidence justifies rebuilding rather than repairing?
Documented inability to support essential customer tasks, safe maintenance or reliable integrations can justify considering a rebuild. Ask for a repair assessment and a replacement prototype against the same requirements. Compare ongoing maintenance as well as initial delivery.
What should we do if traffic is too low for a clear test?
Observe realistic tasks, verify submissions and review actual enquiry suitability. Report counts and uncertainty rather than impressive percentages from tiny samples. You can confirm that a broken form now delivers correctly without claiming a statistically proven conversion uplift.
Sources & further reading
Use the original guidance when checking details or planning implementation.
This research-assisted guide uses the primary sources linked above. Examples are illustrative unless explicitly identified otherwise. Check original documentation when implementing changes.
