Signs your website needs a redesign (and when a refresh will do)

A website needs a redesign when its structure, technology or customer journeys stop it doing the job. That only counts if a smaller change can't reasonably fix the problem. Age or appearance alone isn't enough. Start with the failing task and its cause, then compare the cost and risk of each option.

Choose the amount of change the problem needs

There are four broad ways to respond to a website problem. Suppliers use these words differently, so here's how this guide uses them:

These are working definitions. They aren't fixed industry scopes or price categories. A redesign can keep your platform and much of your content. A rebuild replaces more of how the site is built. Neither has to mean a new domain.

Maintaining isn't free either. Hosting, renewals and support keep costing money while you wait. For the bigger picture, see what a business website needs.

Twelve signs and the smallest useful response

Each sign below covers what to check first and the smallest response worth trying. It also says when wider work starts to make sense.

The site no longer matches the business

Your services, audience or locations have moved on. The pages haven't. Compare what you sell now, and to whom, with what the site says.

Start by correcting the content. Look at wider structure only when the new offer can't fit clearly within the current one. A common mistake is choosing a new theme before working out what content the site needs.

Visitors can't quickly understand the offer

Ask a few representative people what you do, who you serve and what they can do next. If they hesitate, try clearer copy, labels and page order first. A quick first impression test is a prompt, not a universal usability standard. If clearer copy can't fix it because the structure buries the offer, look wider.

Traffic brings few useful enquiries or sales

First confirm your tracking works. Then test that enquiries actually arrive. After that, check whether the traffic suits the offer.

Pricing, friction in the task and your follow up matter too. A visual redesign won't automatically fix an acquisition or sales problem. Wider work fits only when testing shows the site itself blocks the task. Start with checking enquiry forms. For the wider picture, see diagnosing weak website conversion.

A common mistake is blaming the design before anyone has tested the form.

That's example wording, not a client observation. A specific problem gives you something to test and fix.

Mobile feels like a shrunken desktop

On the phones your customers use, test navigation and text resizing first. Then try forms, pop ups and the main actions.

Fix a shared component where you can. Consider wider template changes only if the same constraints repeat and can't be repaired sustainably.

The site feels slow

Find the actual bottleneck, whether that's images, scripts or hosting. Templates can be the cause too. Use field data from real visitors where it exists. Repeat lab tests, which simulate a visit, under recorded conditions.

Don't buy a new design because of one score. Wider work fits if the templates themselves are the bottleneck and can't be fixed sustainably. Our guide to finding the cause of a slow website covers the fixes.

Routine editing is painful

Ask the person responsible to make a typical edit in a safe test copy of the site. Check permissions, training and the workflow before replacing the CMS, the system you edit the site in. Include preview, approval and recovery in the test. Replace the CMS only if training and workflow changes still leave safe editing out of reach.

Our guide to how a CMS supports editing explains what to expect. If a platform limit is confirmed, our website platform comparison can help you weigh the options.

A success message on screen doesn't prove the request arrived. Check the last step every time.

The site is a collection of patches

Map the dependencies and the failures that keep coming back. Many affected pages may share one component. Compare a contained replacement with the burden and risk of keeping the current system. Wider work fits when the shared system is unsupported or the same faults keep returning after repairs.

Important services are buried

Ask people to find a service and enquire about it. Improve navigation, internal links and service content before assuming the platform must change.

Wider restructuring makes sense when the page structure no longer fits the business. See organising business website content.

The brand has changed

List the visual and content changes and where they appear. A refresh of shared templates or design styles may cover it. A rebrand alone doesn't create a technical reason to rebuild. Wider work fits if the new brand needs page types the current templates can't support.

Widespread symptoms don't prove you need a rebuild. One shared menu, template or form can break many pages. It may still need only one repair. It might still need replacing if it's unsupported or unsuitable.

The build gets in the way of search

Check that search engines can crawl and index your important URLs, meaning find and store them. Then review the content and internal links, plus the templates behind them. Diagnose the issue with whoever handles your SEO.

A ranking drop can have causes that have nothing to do with design. Wider work fits when the platform can't produce crawlable pages even after fixes. A common mistake is changing every URL during a redesign without a reason.

Essential tasks are inaccessible

Check the basics first:

• keyboard access and a visible focus outline

• labels, contrast and text resizing

• error messages and complete tasks from start to finish

Fix urgent barriers now. Then scope a wider review. Wider work fits when barriers are built into templates you can't repair. W3C's Easy Checks describe themselves as quick rather than definitive. A page can pass them and still have serious barriers.

Our quick check is a guided manual review, not certification or an automated scan. For the full picture, see website accessibility in Australia.

You're embarrassed by the site

Turn the feeling into evidence from customers, staff or sales. If tasks work and the site represents the business accurately, selective presentation changes may be enough. Personal taste isn't a cost benefit case. Wider work fits when evidence shows the site is losing trust or blocking a task.

A common mistake is paying for a visual refresh while a critical task stays broken.

How the signs play out

The same sign can need very different work. These are fictional examples, not Elev8d clients:

Use age as a review trigger

Age is a reason to review, not an expiry date. An older site that's supported and maintainable can still suit you. A brand new site can already be wrong for the business.

Age alone doesn't establish that kind of limit. Review the site when one of these happens:

• your offer or audience changes significantly

• the CMS, theme or plugins lose security support

• staff can't maintain the site safely

• customer tasks start failing

Unsupported software isn't the same as an unfashionable layout. An active compromise or serious vulnerability needs containment and technical help now. A future redesign isn't an incident response plan.

Check who owns the domain, hosting and key accounts. Check whether supported updates are possible and whether recovery has actually been tested. These can shape the scope. Account problems can often be fixed separately, though.

Waiting has costs too. Describe them honestly:

• known outages

• manual workarounds staff rely on

• unresolved barriers for customers

• upcoming renewals and commitments

If the impact is unknown, say so and gather evidence. Don't multiply an assumed conversion lift to manufacture a loss figure.

Run a 20 minute first screen

This screen is a first look using the access and evidence you already have. It can't replace a security or accessibility audit. Nor can it replace a full SEO or analytics review.

Work through the seven areas in order:

Score each check out of 2. Give 0 for a poor observed result and 1 for one that needs work. Give 2 for a strong result against a stated task. Mark U for unknown, and use NA only with a reason.

Not every business needs phone calls, reviews or team profiles. Don't manufacture irrelevant proof to earn points.

The maximum is 68 only when all 34 checks apply and have evidence. Otherwise, report known points out of the known maximum, plus how many checks you covered. Don't rescale to 68 or apply the bands.

For a complete screen, the bands give a rough steer:

Critical failures override a comfortable score. Examples include a failed checkout or an enquiry that never reaches staff. So do an essential task blocked for disabled users, misleading key information or signs of compromise. Respond to the actual issue promptly and work out its scope separately.

Take an incomplete screen with 24 items checked and 10 unknown. The known score is 35 out of 48, with 24 of 34 checks covered. Report exactly that.

Don't call it 49.6 out of 68 or give it a band. The arithmetic works, but nobody has validated that rescaled reading. The screen shows where to look next. For a fuller website audit, use our general website audit checklist.

Collect evidence before choosing scope

Before comparing options, write down what you're trying to fix and how you'll know it worked. Set the period and definitions before you compare anything. Capture a baseline that covers:

• business goals and the pages that matter most

• customer tasks, devices and traffic sources

• qualified enquiries or sales

• support workload and known faults

Don't fill unknown values with made up data. Leave them marked unknown.

Read analytics with care

Treat analytics and Search Console as partial evidence. Use them alongside real enquiries, customer feedback and technical checks. Missing analytics is a measurement gap. It isn't proof of zero demand or a reason to replace the site.

Search Console doesn't show everything either. Google anonymises rare queries. Their query text is missing from the data. For setup, see setting up Search Console.

In GA4, counting events and counting sessions tell different stories. Google's key event counting can count every time an event fires, or once per session.

Take a 100 sessions with 8 enquiry events spread across 6 of them. Counted by session, that's 6%. Counted by event, it's 8 per 100 sessions. Check which one a report shows, and remember neither proves six qualified prospects. Our guide to defining website measurement in GA4 covers the setup.

Compare before and after fairly

For a before and after review, record what else changed:

• traffic mix and advertising

• season and prices

• staffing and the offer itself

• the tracking setup

A better number after launch doesn't prove the redesign caused it. With few outcomes, watch for longer and pair the numbers with task testing.

PageSpeed Insights field data and lab tests do different jobs. Field data covers the previous 28 days. It can fall back to the whole site.

Record the URL, the device mode and whether the data is page or site level. Missing field data doesn't mean a page passed or failed. A 28 day window won't reflect a launch from yesterday.

Google says Core Web Vitals are used by its ranking systems. It also says there's no single page experience signal. Good scores don't guarantee top rankings either. For the metrics themselves, see understanding Core Web Vitals.

Compare the full cost of the options

Compare options on what they'll cost from here, not on the quote alone. For context, here are our own published build ranges:

Our web design page lists those ranges and says builds typically take 4 to 8 weeks. They're published build ranges, not a redesign quote or a guaranteed schedule. Hosting, the domain and maintenance are separate. These need a scoped quote of their own:

• migration of content and data

• new or rewritten content

• integrations with other systems

• fixing old problems along the way

For broader budgeting, see website cost planning and ongoing website maintenance costs. Once your assumptions are clear, the website cost estimator can help.

Here's a fictional 24 month comparison in AUD, excluding GST. The figures are made up for teaching, not Elev8d quotes or market averages:

The formula is: future cost = new supplier cost + internal time + monthly ongoing cost × 24.

These scopes don't deliver the same outcome. Keeping the current site only counts as an option if it stays acceptable and supported. In a real comparison, include known incident and repair costs rather than pretending they're zero.

Look at GST and cash timing separately from the cost comparison. Deposits and milestone payments land at different times from renewals. Overlap costs matter too, like paying for two hosts or training staff while both sites run. A common mistake is treating money already spent on the old site as a reason to keep it.

One simple hurdle helps. In the example, the redesign costs $11,200 more than the patch over 24 months. That's $466.67 a month, the extra needed just to cover the difference before any discounting. It isn't a sales forecast, a full ROI model or evidence the redesign will earn it.

Understand the risks of changing the site

Every change carries risk. The point is to manage it, not to assume the worst.

The detailed delivery steps live in planning and delivering a redesign. Plan for the main ones:

Treat each one as a risk to manage, not an inevitable result. The owners and recovery steps are planning fields, not test results.

Before changing URLs, find the pages that attract traffic, links or important tasks. Keep useful URLs where you can. Google's site move guidance warns against redirecting many old URLs to one irrelevant page, like the home page. Detailed redirect work belongs in protecting SEO during a migration.

Keep the old and new versions available until acceptance and the agreed recovery window finish. A backup file alone isn't a rollback plan. Someone must know how to restore service and how long it takes. They also need to know what happens to orders or submissions made since the backup.

Our guide to backups and tested recovery covers the detail. Record who approves launch. Note who can change hosting and the DNS settings that point your domain at it. List which integrations need retesting and how incidents get escalated. Don't cancel the old service until dependencies and data have been checked.

Choose and stage the right amount of change

Match the amount of change to the evidence:

• maintain when the site is accurate, supported and handles the tasks that matter

• patch a bounded fault

• refresh content, navigation or presentation when the foundation still suits

• redesign or rebuild when proven constraints make smaller changes unsuitable or uneconomic

Then check each option against the same factors:

Don't add these up into a weighted total. Unlike risks don't trade off neatly. Name the constraint that rules an option out instead.

Other examples include staff updating a service page without a developer. Another is a keyboard user completing a booking. A perfect score or a vague modern look isn't an acceptance test.

Then stage the work so each step earns the next:

Trial a shared component in a safe copy of the site before committing to a full replacement.

Check your own capacity too. Someone on your side has to:

• supply copy and images

• arrange any legal review

• approve and sign off the work

Your team also has to respond during the project and maintain the result. The most ambitious option isn't automatically the most workable one.

A launch deadline can justify a temporary repair now and a migration later. That can be safer than a rushed replacement, because the migration gets proper testing.

A redesign won't fix an unclear offer, unsuitable traffic or poor follow up. Equally, don't use that to dismiss real design barriers. Look for the bottleneck and what each change can realistically contribute. If testing is the next step, website conversion testing is how we'd run it.

Ask ten questions before approving a proposal

Ask every supplier the same ten questions:

Use it alongside the questions. It doesn't replace a properly scoped proposal. For choosing who to hire, see choosing a web designer. When launch gets close, the website launch checklist covers the final checks.

What we recommend at Elev8d

Frequently asked questions

Next steps

Pick the situation that fits.

Written by Ajay K.Co-founder, Elev8d

Ajay is the co-founder of Elev8d and writes most of what you will read here. Psychology grad turned marketer, which is a fancy way of saying he cares about why people click, not just where things rank. Every guide is written in plain English for Australian businesses, tested on real campaigns before it earns a spot on this site.