How to Diagnose Website Rebuild Decision Before Commissioning a Redesign

A website rebuild is a change to a revenue system, not only a visual project. It can alter URLs, page roles, forms, analytics, internal links, sales routing, and the evidence used to judge demand. Before commissioning a redesign, identify the first broken layer and test whether a smaller repair can solve it. The decision should follow evidence, not frustration with an old interface.

State the business decision

Write the decision in one sentence: “We need to increase qualified consultations,” “we need to support a new market,” or “we need to retire an unmaintainable platform.” Avoid starting with “the site looks dated.” A visual concern can be valid, but it does not tell you whether the limiting factor is trust, messaging, performance, crawlability, form routing, or sales follow-up.

Collect the current URL, template, form, analytics, CRM, and ownership map. Record the pages that carry organic demand, paid traffic, partner referrals, and sales enablement. Include downloads, redirects, subdomains, and local or language variants. A page that looks unimportant in navigation may still hold a valuable query or a sales path.

Separate the symptom from the layer

Use this first-pass table before requesting a scope:

| Observed symptom | First layer to test | Smaller repair to consider | | — | — | — | | Visitors do not understand the offer | Message, audience, or page role | Rewrite the decision page and test the path | | Leads arrive but sales cannot use them | Form, routing, or CRM | Repair fields, ownership, and handoff | | Traffic falls after a template change | URL, indexing, or content continuity | Reconcile canonicals, redirects, and intent | | Pages load slowly or shift | Front-end, hosting, or assets | Remove bottlenecks and measure field experience | | Teams cannot edit safely | Governance, CMS, or ownership | Define components, permissions, and release rules | | Conversion data is contradictory | Instrumentation or definitions | Rebuild the measurement contract first | | Content is duplicated or orphaned | Information architecture | Consolidate, link, or retire pages deliberately |

The point is not to avoid a rebuild. It is to make the rebuild solve a demonstrated problem and to preserve what already works.

Inspect performance without turning one score into a verdict

Review real-user and lab evidence by page type, device, and business path. Google’s Core Web Vitals guidance describes metrics for loading performance, responsiveness, and visual stability, including LCP, INP, and CLS. These metrics help locate experience problems; they do not by themselves prove that a full redesign will increase pipeline.

Compare a representative set of landing pages, service pages, articles, forms, and checkout or booking paths. Note whether a poor result is caused by a shared template, a third-party script, an image, an interaction, or the hosting layer. If one script is responsible for a problem, replacing the whole site may add risk without removing the cause.

If the visible URLs will stay the same but the infrastructure will change, use Google’s separate hosting-change guidance. It calls for testing the new infrastructure, removing temporary crawl blocks at launch, monitoring both systems, and waiting for evidence before shutting the old one down. That is a different risk profile from a URL migration and should be scoped separately.

Inspect search and URL continuity

Build a URL map with current URL, intended destination, page role, organic impressions or clicks, internal links, canonical, index state, and proposed action. Mark every URL as keep, change, merge, redirect, or retire. Do not let the future CMS generate a new URL list without a mapping owner.

Google’s site move and migration guidance recommends preparing the new site, mapping old URLs to new ones, using appropriate redirects, and monitoring old and new URLs. It also advises changing one material variable at a time where possible. A redesign that changes the CMS, URL structure, content, tracking, and navigation in one release makes diagnosis difficult.

Check staging controls as well. A development noindex or blocked crawler can be correct before launch and disastrous after launch if its removal is not assigned and tested. Treat sitemap, canonical, redirects, robots rules, and internal links as one migration system.

Inspect the demand and sales path

Replay the top customer journeys from the first page to the next commercial action. Ask:

• Can a buyer state what the company does and for whom within the first screen?
• Does each important page have one primary decision and a clear next step?
• Are forms asking for information the sales team actually uses?
• Does the CRM receive the source, consent, context, and owner?
• Can sales distinguish a request for information from a qualified opportunity?
• Are important routes usable on mobile and with keyboard navigation?

Use a controlled test record to verify the entire path. A form’s success message is not proof that the CRM record is complete, nor is a page-view conversion proof of revenue. Capture the request, record ID, routing, response, and downstream state.

Decide between optimize, redesign, and rebuild

Use three decision states:

• Optimize: the architecture and ownership are sound; a focused message, content, UX, performance, or routing repair can test the hypothesis.
• Redesign: the structure can remain, but page roles, components, navigation, or visual hierarchy prevent the intended experience.
• Rebuild: the current platform, governance, data path, or technical constraints make a controlled repair impractical, and the replacement has a verified migration and rollback plan.

The Website Rebuild Decision Ledger should document the evidence for each state. Record the problem, affected pages, business impact, alternative explanations, proposed intervention, owner, dependency, measurement, and stop rule. If the evidence supports more than one explanation, run the cheapest discriminating test before approving the largest scope.

Define migration gates before a brief

If a rebuild remains justified, put these gates into the brief:

1. complete URL and asset inventory;
2. page-role and internal-link map;
3. form, CRM, consent, and source-field contract;
4. redirect and canonical map with an owner;
5. staging crawl, accessibility, mobile, and performance review;
6. analytics event and conversion reconciliation;
7. launch-day rollback path and monitoring window;
8. post-launch review of old and new URLs, leads, and revenue evidence.

Specify what is not changing in the first release. A phased move is easier to interpret than a release that combines every desirable improvement.

Set stop rules

Pause the project when no one owns the URL map, when baseline data cannot be reconstructed, when the proposed design has no defined page roles, or when the sales path has not been tested. Do not approve a rebuild to hide unresolved offer, audience, or measurement decisions. A larger surface area will not make those decisions disappear.

The correct outcome may be “rebuild later; repair the evidence path now.” That is not a failure of ambition. It is a way to protect search continuity, working demand, and the budget needed for the change that is actually justified.