Repair a website when a bounded change can meet the requirement. Consider a rebuild when verified requirements cannot reasonably be met within the existing structure. If the cause is unclear, investigate before choosing either.
A website can look dated and still do its job. It can also look polished while making a simple task frustrating. Before asking for a redesign, write down what a visitor needs to do and what prevents it. That turns a broad request into a decision you can test.
This worksheet helps you compare a targeted repair, replacement of a shared component, and a larger rebuild. Here, a redesign means changing presentation or interaction; a rebuild means replacing underlying structure. A project can involve both, but a visual change alone does not establish a need to rebuild. This is a scoping framework, not a diagnosis of your website or a promise of business results.
Start with one visitor task, not a new design
Choose a concrete journey: find a service, compare an option, request a conversation, or update an account. Write a sentence such as: “A visitor on a phone needs to find the service details and understand how to ask a question.”
Then record the failure without naming a solution. “The menu covers the contact link at this screen size” is useful. “We need a modern website” leaves the problem open. Include the page URL, device, browser, steps and what you expected to happen. Use synthetic details, not real customer records.
Separate what you observed from what you suspect. If inquiries seem quiet but you have no reliable records, write “cause unknown,” not “the design is losing customers.” A functioning page and a measured business outcome are different evidence.
Check shared components before counting broken pages
Ten pages with the same broken navigation may need one shared-component repair, not ten separate fixes. One checkout problem might involve several connected systems. Page count alone is a weak guide to scope.
Ask a developer to trace where the failure lives: content, a template, an interaction, an integration, or the underlying platform. Ask what else depends on that part and whether a bounded change can be tested and rolled back. A successful small repair can give you evidence for the next decision; it does not prove every other part is sound.
Include accessibility in the investigation. W3C’s Easy Checks covers starting points such as page titles, text alternatives, keyboard access, visible focus and form labels. W3C warns that these preliminary checks are not comprehensive or definitive; a page can appear to pass and still have significant barriers.[1]
Fill in the website repair-versus-rebuild worksheet
Use one row per observed problem. Record “unknown” where you do not yet have evidence, rather than giving the problem an optimistic score.
| Field | What to record |
|---|---|
| Visitor and task | Who needs to do what, on which journey? |
| Reproduction | URL, browser/device, steps, expected result and actual result. |
| Reach | One page, shared template, several journeys, or not yet traced. |
| Consequence | Task blocked, difficult, misleading, or mainly a visual preference. State the evidence. |
| Smallest candidate change | What could be corrected while preserving working parts? |
| Constraints | Platform support, editing needs, integrations and ownership; ask the developer to verify unknowns. |
| Proof required | A repeatable check showing the task works, plus nearby regression checks. |
| Migration exposure | URLs, content, data, integrations and reporting that would need to move. |
| Recovery | Who can restore the last known working version, and how will restoration be checked? |
| Decision | Repair, replace a shared part, investigate further, or plan a rebuild; explain why. |
Do not total these rows into a universal “rebuild score.” A blocked essential journey deserves investigation even if the rest of the site looks fine. An unsupported platform may change the decision, but verify its support status and your upgrade options rather than treating its age as proof.
When to repair, replace a component or rebuild
Repair a bounded problem
A targeted repair is a reasonable candidate when the failure is reproducible, its cause is bounded, and a change can meet the requirement without leaving a known critical constraint unresolved. Ask for the smallest proposed change and a repeatable acceptance check.
Replace a shared component
Replacing a shared part may fit when the same navigation, template or interaction causes failures across pages. Ask for a representative-page test and a list of every page using that part. Include checks for working behavior that the change must preserve.
Consider a rebuild against verified requirements
A rebuild becomes a candidate when the existing structure cannot reasonably meet verified requirements: for example, necessary editing or integration work would require extensive replacement anyway. Ask the supplier to show which requirements rule out a repair. “A new stack is better” is not that explanation.
If the cause is unclear, scope an investigation before committing to either option. Request findings, evidence, options and exclusions. Do not treat uncertainty as a reason to choose the largest project.
Two hypothetical repair-versus-rebuild examples
These examples illustrate the worksheet. They are not client stories, site audits or measured outcomes.
Example A: a service business reports that its mobile menu hides the next-step link. In this hypothetical investigation, a developer reproduces the overlap and traces it to one shared navigation component. A repair candidate would correct that component and check opening, closing, keyboard focus and the destination link on agreed representative pages. The scenario supports investigating a shared repair first, not a prediction about inquiry volume.
Example B: a team needs several staff members to manage structured service information, but its current editing arrangement does not support the required permissions or workflow. First verify what the platform can actually do. Compare a supported extension or upgrade with a replacement, including content migration and ongoing ownership. A rebuild is one option, not an automatic conclusion.
Compare performance evidence under the same conditions
If speed is part of the complaint, record the tested URL, tool, date, device and conditions. Keep controlled diagnostic tests separate from observations of real visitors. Do not present a single test score as proof of every visitor’s experience.
Google’s Web Vitals guidance describes loading, responsiveness and visual stability through Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). Its good targets are LCP within 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1, assessed at the 75th percentile with mobile and desktop segmented.[3] These are experience metrics, not a repair-versus-rebuild formula or a guarantee of search rankings.
Use a developer’s diagnosis to connect a poor measurement to a specific cause. Ask whether the proposed change addresses that cause and how the same conditions will be checked afterward. No performance or browser benchmark was run for this article.
Plan URL migration if a redesign changes addresses
If URLs will change, make an old-to-new URL map before launch. Identify what stays, what moves and what is intentionally retired. Google’s site-move guidance recommends changing one thing at a time where possible and warns that rankings may fluctuate while a changed site is recrawled and reindexed.[2] Its guidance concerns moves with URL changes; not every visual redesign is such a move.
Ask for checks of old links, permanent redirects for moved URLs, final destinations, canonical URLs, internal navigation and the sitemap, plus an agreed rollback plan. Google describes permanent redirects as part of implementing the URL move.[2] Keep working URLs where the project allows. A replacement proposal that excludes migration still leaves you with migration work to plan.
For either option, compare the full scope: diagnosis, implementation, content work, migration if needed, testing, launch, ownership and maintenance. Ask for inclusions and exclusions rather than choosing on an unsupported estimate of future return.
Copy this brief when asking a developer for options
“Our visitor needs to ____. At ____ on ____ we observed ____. We can reproduce it by ____. Please compare a bounded repair, any shared-component replacement, and a rebuild only where necessary. Explain the constraints, what stays unchanged, migration needs, acceptance checks, exclusions and recovery plan. Unknowns are ____. Please identify what needs investigation before estimating the work.”
If your requirement also involves internal processes, map the workflow before building an internal tool. The useful overlap is defining people, information and failure states—not treating every website problem as a software rebuild.
For a conversation about website work, you can prepare a project brief with CodeCanvasDigital. The helper lets you request an email draft; it does not submit an inquiry or confirm that an email app opened, a message was sent or the business received it.[4][5] Do not include passwords, access tokens or confidential customer information. No price, availability or delivery commitment is implied.
Sources
[1] https:
[2] https:
[3] https: