Website redesign: when it is justified and how to plan it

An ageing look is not, by itself, a reason to rebuild. A redesign becomes relevant when the site no longer represents the offer, makes an important task difficult, performs poorly on some devices, is hard to maintain or relies on systems that no longer fit.

Turn each issue into a testable objective: make information easier to find, simplify an enquiry, support multilingual publishing or let the team update content. This separates a business need from a visual preference.

Inventory pages, templates, forms, integrations, media and external accounts. Add available evidence about viewed pages, internal searches, errors and important actions, while respecting consent and privacy.

Classify every item as keep, improve, merge, redirect or remove. A redesign without this inventory can erase useful material or reproduce the same difficulties behind a new interface.

Where a URL changes, map the old address to the closest new resource. Redirects should not all lead to the homepage. Update internal links, canonicals and sitemaps as part of the same plan.

• Keep information that still answers users’ needs.
• A new layout cannot compensate for vague copy, generic headings or near-duplicate location pages.
• No migration process can guarantee that search positions will remain unchanged.

Validate the structure, key journeys and a few representative templates first. Test them with real content before producing every page; genuine headings, images, tables and forms expose constraints hidden by placeholders.

Include keyboard states, contrast, form errors, small screens and performance from the outset. Page experience is part of overall quality, but Google makes clear that it does not replace relevant content.

On a non-indexed staging version, verify priority journeys, forms, languages, metadata, structured data, redirects and analytics. Check missing pages, broken links and server responses as well.

Keep a backup and a practical rollback plan. Assign clear owners for content, technical and legal approval so that each area has an accountable final check.

The first signal is functional: an important task fails or takes disproportionate effort. The contact form no longer arrives, the booking page does not render on a phone, the restaurant menu is an unreadable image, or the team cannot change a price without calling someone. These situations have a daily cost, measurable in lost enquiries and hours spent working around the tool.

The second signal is technical: the CMS version is no longer maintained, a critical extension has been abandoned by its author, the hosting shows security alerts, or the site no longer serves HTTPS correctly. A site in that state is a risk before it is an image problem, and the redesign becomes a protective measure.

The third signal is strategic: the offer has changed and the site still tells the old story. A new activity, a new service area, a move to several languages, a discontinued service; once the gap between what the business does and what its site says becomes visible to customers, every visit works against you. A merely dated look, without one of these three signals, is often fixed by a visual refresh rather than a rebuild.

Export the full list of indexed pages from Search Console, complete it with the current sitemap and with a crawl of the site by a dedicated tool. The three sources never match exactly: the crawl finds orphan pages, Search Console reveals URLs Google still knows but nothing links to any more, and the sitemap sometimes lists pages that have disappeared.

For each URL, record the traffic of the last twelve months, the number of external links pointing to it if you have that information, and the decision: keep as is, rewrite, merge with another, redirect or remove. A page with no traffic, no links and no role can go; a rarely visited page cited by a directory or a partner deserves a precise redirect.

• The result is a two-column table — old address, new address — that becomes the redirect plan.
• It is prepared before development, tested on staging and verified on launch day, URL by URL.
• It is the least glamorous deliverable of a redesign and the one that prevents the most damage.

An incremental redesign keeps the technical base and replaces templates one at a time, starting with the most visited pages. It limits risk, spreads the workload and allows each step to be measured. It suits a site whose URL structure is sound, whose CMS is still maintained and whose content is broadly good.

A complete rebuild starts from a fresh base: new architecture, new code, often new technology. It is necessary when the current base is too fragile to improve, when the site depends on abandoned tools, or when the information architecture must change deeply. It costs more in one go but removes a technical debt that is otherwise paid on every intervention.

The choice is made after the audit, never before. A supplier who recommends a rebuild without having looked at what exists is selling their method; a supplier who promises an incremental redesign on a rotten base is selling time. In both cases, ask what was examined and what motivates the recommendation.

A redesign is the moment to reread every text with the simplest question: does this page answer what a customer came here for? Service pages written five years ago often talk about the company rather than to the customer, pile up adjectives and forget to say what is included, for whom, and how to request a quote.

• Use the opportunity to group what is scattered and remove what is redundant.
• Three pages saying nearly the same thing about three municipalities are better replaced by one solid page and a clear service area.
• A 2019 news item about a promotion that has ended can go without regret.

Finally, set writing rules that will outlive the launch: one main heading per page, subheadings that announce the content, short paragraphs, a clear action at the end of the page. These rules, written on one page and shared with those who publish, are worth more than the finest mock-up.

Launch on a day when someone can watch the site for several hours, never on a Friday evening. Immediately check redirects on a sample of old URLs, the contact form with a real submission, payments with a test order if it is a shop, the sitemap and the robots file, and the absence of a no-index tag inherited from staging.

In the following days, monitor crawl errors and not-found pages in Search Console; every new error points to a forgotten redirect. Also look at real performance data as soon as it is available, to confirm that the new site does better than the old one on the same templates.

Wait several weeks before drawing a conclusion on visibility. Google has to recrawl every page, reassess the redirects and recompute what it knows about the site; a temporary dip is not abnormal and an immediate rise is not guaranteed. Then compare equivalent periods and note every change made in the meantime, so as not to credit the redesign with what came from elsewhere.

Before changing the site, document a baseline: completed tasks, enquiries, errors, real-user performance and recurring questions. Observe the same measures after launch and segment them when the data volume supports it.

• A change is not automatically caused by design.
• Seasonality, campaigns, a changed offer and tracking faults may contribute.
• Use evidence to prioritise corrections, not to declare guaranteed success.