Things to consider before redesigning your website

Before redesigning a website, settle four things: whether you actually need a redesign rather than a set of fixes, what specific outcome would make it a success, what your current site already does well enough to be worth preserving, and how existing search traffic will survive the move.

The fourth is where redesigns most often cause real damage. A site can launch looking far better and lose a third of its organic traffic in a fortnight, because the redesign was treated as a design project when it was also a migration.

First: do you need a redesign at all?

Redesigns are expensive, disruptive, and frequently commissioned to solve problems a redesign does not address. Work out which situation you are actually in.

Signs a redesign is genuinely warranted

• The site cannot be made to work on phones without effectively rebuilding it — a fixed-width layout with no responsive foundation, or a separate mobile site that has drifted out of sync.
• The structure no longer matches the business. Navigation built for services you no longer lead with, or a hierarchy that has accumulated pages nobody can place.
• The platform is a genuine constraint. Unsupported CMS, unpatched security, or a stack where every change requires a developer.
• Every fix breaks something else. A theme overridden so heavily that CSS changes have unpredictable effects is a maintenance trap, and the cost compounds.
• The brand has genuinely moved on — not simply that the site feels stale internally, but that it misrepresents what you now do.

Reasons that do not justify one

• "It looks dated to us." Your team sees the site daily; visitors see it once. Internal fatigue is not a user problem.
• A new marketing lead wants to make their mark. A common and expensive driver, rarely stated aloud.
• A competitor relaunched. You have no idea whether theirs worked.
• Conversions are down. Usually structural or traffic-quality, and a redesign is an unfocused way to address it. Diagnose first.
• Traffic is falling. Establish the cause. If it is an algorithm update, a technical fault or a lost backlink profile, a redesign will not fix it and may worsen it.

If your problem is specifically that the site fails on phones, it is worth checking whether fixing mobile on the existing site is viable first. That is often weeks of work against months, and it carries none of the migration risk.

Define what success means before anyone designs anything

"A modern, professional website that better reflects our brand" cannot be evaluated. Nobody can say afterwards whether it was achieved, which is precisely why it is the most common brief.

Replace it with statements that could turn out false:

• Enquiries from the site increase, measured against the same quarter last year
• Organic sessions are maintained within 10% through the migration and recover fully within three months
• The team can publish a new service page without developer involvement
• Mobile conversion rate reaches parity with desktop
• Core Web Vitals pass on mobile at the 75th percentile

Write these down before design begins and agree who checks them and when. A redesign with no defined success criteria always succeeds, because the criteria get written afterwards to match whatever happened.

Protecting search traffic is the highest-risk part

This is the section most redesign briefs omit entirely, and it accounts for most of the serious damage.

Your existing site has accumulated something you cannot buy back quickly: indexed URLs, backlinks pointing at specific pages, and years of ranking history. A redesign that changes URLs without carefully mapping them discards that.

Map every URL before launch

Crawl the current site and export every URL that returns 200. Pull the pages with organic traffic from Search Console and the pages with backlinks from whatever link tool you use. For every one, decide: does it survive at the same URL, move to a new URL, get merged into another page, or genuinely go away?

Every URL that moves or merges needs a 301 redirect to the closest equivalent page. Not to the homepage — redirecting everything to the homepage is treated as a soft 404 and throws away the value you were trying to preserve. Google's site move documentation is explicit about this.

Keep the URLs you do not have to change

The safest redesign changes no URLs at all. If the structure genuinely needs to change, change what must change and leave the rest. A slug being old or slightly awkward is not a reason to move a page that ranks — you are trading real accumulated equity for a cosmetic improvement nobody searches for.

What else moves with the pages

URLs get the attention, but several other things are routinely lost in a rebuild:

• Page titles and meta descriptions that were deliberately written, replaced by templated ones
• Structured data that was implemented and then not carried across
• Internal links inside body content, dropped when content is reflowed into new templates
• Image alt text, lost when images are re-uploaded
• Analytics and conversion tracking, silently broken so you cannot measure the outcome
• The XML sitemap, left pointing at the old structure

The analytics one deserves emphasis. If tracking breaks at launch, you lose the ability to tell whether the redesign worked at exactly the moment you need to know. Verify conversion tracking with a real test submission on the new site before launch, not after.

Audit the content before designing around it

Designing templates before knowing what content exists produces layouts that real content does not fit — the heading that was drawn for four words and receives fourteen, the case study grid built for nine entries when you have five.

List every page and decide: keep as is, rewrite, merge into another page, or remove. Base it on evidence — traffic, conversions, and whether the page still describes something you do — rather than on which pages people are attached to.

Most sites carry a substantial tail of pages that receive almost no traffic and serve no purpose. A redesign is a good opportunity to remove them, provided anything with backlinks is redirected rather than deleted outright.

Do this before design, not during build. Content decided late is the single most common cause of redesigns running over schedule.

Redesign or iterate?

The framing is usually "redesign or leave it alone", which is a false choice. Continuous improvement is often the better investment.

	Full redesign	Iterative improvement
Best when	Platform, structure or foundation is the constraint	The site works; specific pages underperform
Risk	High — everything changes at once	Low — changes are isolated and reversible
Learning	One large bet, evaluated after launch	Continuous, with each change measurable
Disruption	Months, with a launch cliff	Minimal
SEO risk	Significant, needs active management	Negligible

A reasonable test: if you can list the specific pages that underperform and say what is wrong with each, you probably need improvement rather than a redesign. If you cannot describe the problem except as a general feeling about the site, either the problem is foundational or it has not been diagnosed yet — and in the second case a redesign is a very expensive way to avoid diagnosis.

Decide what carries over from the old site

Redesigns are usually framed as replacement, which quietly assumes nothing currently works. That is rarely true, and starting from a blank page throws away information you already paid for.

Before design begins, identify what the current site does well enough to keep:

• Pages that convert. If a service page produces enquiries, understand why before redrawing it. The layout may be incidental, but the content order and the objections it answers usually are not.
• Navigation labels people actually use. Site search queries and click data tell you which words your audience uses. Replacing plain labels with clever ones is a reliable way to reduce findability.
• Content that earns links or traffic. Anything ranking or attracting links is doing work. Preserve it, at its URL, and improve it rather than replacing it.
• Anything customers reference by name. If sales regularly send people to a specific page, that page has a job.

Write this list down explicitly and hand it to whoever designs the new site as a constraint. Without it, the things that were working get redesigned away simply because they were on the old site, and nobody notices until the enquiry rate drops.

Watch for the launch-day regression

A specific pattern worth naming: the new site is genuinely better in most respects, but one high-value page loses a detail that was doing the persuading — a proof point, a price range, an FAQ that answered the common objection. Aggregate metrics look fine; that one page's conversion rate halves.

Guard against it by comparing the new version of each top-converting page against the old one, element by element, before launch. Ask of anything dropped: was that removed for a reason, or because it did not fit the new template?

A planning checklist

Settle these before design work starts.

Strategy

• Written success criteria that can be evaluated
• Agreed primary audience and the main task they come to do
• Decision on which parts of the current site are working and stay

Content

• Full page inventory with keep / rewrite / merge / remove decisions
• Named owner for producing new content, with dates
• Real content available before templates are finalised

Technical and SEO

• Full crawl of the current site, exported
• Top pages by organic traffic and by backlinks identified
• URL mapping document — old to new, page by page
• 301 redirects written and tested on staging
• Titles, descriptions, structured data and alt text carried across
• Analytics and conversion tracking verified on the new build
• XML sitemap regenerated for the new structure
• Staging environment blocked from indexing — and unblocked at launch

Project

• Named decision-maker for design sign-off
• Agreed scope, and what happens when something is added
• Clear split of design and development responsibilities
• Post-launch monitoring period with someone accountable

That last technical item catches a genuinely common failure: staging sites are usually blocked from search engines, and the block is sometimes carried to production at launch. A site that launches with indexing disabled disappears from search until somebody notices.

Mistakes that cost the most

Changing URLs without mapping them. The most damaging and most preventable error in the list.

Redirecting everything to the homepage. Treated as a soft 404, and discards the equity of every page redirected.

Launching without checking analytics. You lose the ability to evaluate the project at the moment it matters.

Designing before content exists. Templates built for placeholder text break on real content, and the fix comes out of the build budget.

Removing content because it looks dated. Old pages are often the ones holding backlinks and long-tail traffic. Check before deleting.

Treating launch as the end. The first weeks after launch are when problems surface. Budget time for them rather than releasing the team the day after.

No named decision-maker. Design by committee produces compromise layouts and schedule slippage. One person should own sign-off. Understanding design and development responsibilities helps here, because a lot of redesign friction comes from unclear ownership of decisions rather than from disagreement.

What to expect on time and budget

Redesigns overrun for predictable reasons, and knowing them lets you plan around them.

Content is the usual bottleneck. Design and build run to schedule; the copy for eighteen pages does not arrive. Assign content owners and dates at the start, and treat missing content as a schedule risk rather than something that will sort itself out.

Scope grows quietly. A booking system, a portal, a calculator — each reasonable in isolation, each affecting the timeline. Agree how additions are handled before the first one is requested.

Approval cycles are slower than estimated. If four people must approve, plan for four people's calendars, not one.

Actual figures vary enormously by scope and market, and any single number quoted here would be misleading — the drivers and ranges are covered separately in what a redesign costs.

After launch

Plan the two weeks after launch as part of the project, not as a return to business as usual.

• Verify redirects resolve correctly, with no chains and no loops
• Confirm the new sitemap is submitted and the old one retired
• Watch Search Console for coverage errors and crawl anomalies
• Check conversion tracking is recording real submissions
• Expect some ranking fluctuation for a few weeks; treat sustained decline differently from short-term movement
• Keep the old site's analytics accessible for comparison

A degree of turbulence is normal while search engines recrawl and reassess. What is not normal is a sustained drop after a month, which usually points to redirects, lost content, or a technical fault rather than to the algorithm.

Frequently asked questions

What should I consider before redesigning my website?

Whether a redesign is genuinely the right intervention rather than targeted fixes; what specific, checkable outcome defines success; which existing content and URLs are worth preserving; and how search traffic will be protected through the migration. The last is the one most briefs omit and the one that causes the most damage.

What are the signs a website needs a redesign?

It cannot be made to work on phones without a rebuild; the structure no longer matches what the business does; the platform is unsupported or insecure; or every change breaks something else. Feeling that the site looks dated, on its own, is not a sign — that judgement usually comes from people who see it daily.

Will a redesign hurt my SEO?

It can, badly, if URLs change without being mapped and redirected. It does not have to. Keep URLs where possible, 301 everything that moves to its closest equivalent, carry titles, structured data and internal links across, and verify before launch rather than after.

How do I plan a website redesign?

Decide whether you need one, write checkable success criteria, audit content and decide what to keep, crawl and map every URL, then design against real content. Technical and content planning belong before design, not alongside build.

Should I redesign or improve the existing site?

If you can name the specific pages that underperform and say what is wrong with each, improve them — lower risk, faster feedback, no migration exposure. Redesign when the platform, structure or foundation is the constraint, because those cannot be fixed page by page.

Where to start

Before commissioning anything, do two things. Crawl your current site and list your top twenty pages by organic traffic. Then write one sentence describing what would have to be true in six months for the project to have been worth it.

Those two artefacts change most redesign conversations, because they replace a general sense that the site needs work with a specific list of what must not be broken and a definition of what success looks like.

If you want that migration handled by people who treat it as a search project as well as a design one, that is what our website redesign services are built around — URL mapping and redirect planning run alongside the design work rather than after it.