Before You Redesign Your Website, Find Out What’s Actually Wrong

A website redesign often begins with a sentence that sounds like a diagnosis: “Our website isn’t working.”

Sometimes that means the business has changed and the website has not. Sometimes visitors cannot understand the offer. Sometimes a form is failing quietly. Sometimes the wrong people are arriving. And sometimes the website works reasonably well, but nobody has defined what “working” should mean.

Those situations deserve different responses. A new visual direction may be valuable, but it cannot, by itself, resolve an unclear service, a broken integration, or an unanswered customer question.

Before you redesign your website, identify what is failing, who it affects, and what needs to improve. Then choose the scale of change the evidence supports.

This guide explains how to investigate the problem, decide between targeted improvements, a phased redesign, and a full rebuild, and prepare a brief that gives the next investment a clear purpose.

Start With the Problem the Business Needs to Solve

“It looks dated” is a useful observation. It is not yet a complete project brief. Ask what that dated appearance is affecting. Does the website misrepresent the quality of the work? Does it describe services you no longer offer? Does the team hesitate to send prospects to it? Does a new audience need information the current structure cannot accommodate?

A visual redesign can be the right response when brand expression has fallen behind the business. The case becomes stronger when you can describe the mismatch and its consequences, rather than treating age as an automatic reason to rebuild.

Write a problem statement with four parts: the audience, the task, the obstacle, and the business consequence. For example: “Commercial prospects cannot tell which projects we take on, so our sales team spends initial calls correcting expectations.” That gives content and design a specific job.

Also record what works. Useful search landing pages, recognizable branding, dependable forms, valuable articles, and editing routines your team understands are assets. A redesign should carry forward the things that still serve the business.

Our website design process starts with those decisions because a deliverable has more value when the reason for creating it is clear.

Establish a Baseline Before Changing the Experience

Begin with the evidence you already have: website analytics, Search Console, inquiry records, customer questions, support requests, and conversations with the people who maintain the site. Each reveals a different part of the experience.

Choose a representative period and compare like with like. A seasonal business needs seasonal context. A recent campaign, a change in advertising spend, or a shift in service availability can alter results without the website being the primary cause.

Separate arrival, understanding, action, and business outcome. Are relevant people reaching the right pages? Can they evaluate the offer? Do they complete the intended next step? Does that action reach your team and become a worthwhile conversation?

A useful baseline might include inquiries by landing page and source, the proportion that fit your services, task completion on key journeys, delivery failures, and the time required for routine content updates. Define “qualified inquiry” with your sales team before reporting it.

Check the measurement itself. A button click is not the same as a completed inquiry. A successful form submission is not proof that a notification or CRM record arrived. Duplicate events, consent choices, and untracked phone calls can make a report incomplete.

With little traffic, avoid drawing firm conclusions from a handful of conversions. Combine the numbers with direct observation and customer feedback. Record uncertainty instead of making a small dataset sound decisive.

This is the connection between diagnosis and digital marketing and measurement: the report should help you choose what to investigate, rather than simply give the problem a more impressive chart.

One Symptom Can Have Several Causes

Consider three hypothetical service businesses that all report too few website inquiries. These are illustrative scenarios, not Averane client results.

The first has a message problem. Its service page uses broad claims but never explains who the service is for, what the engagement involves, or how scope is decided. Visitors can find the contact button; they lack enough information to know whether using it makes sense.

The second has a journey problem. The offer is clear, but navigation buries the relevant page and the mobile layout makes the next step difficult to find. Improving the route and the page hierarchy may address the immediate obstacle.

The third has a handoff problem. The form displays a confirmation, but the inquiry goes to an outdated destination. A new homepage would leave the underlying failure untouched.

The symptoms look similar in a monthly report. The work required to resolve them is different. Before treating a redesign as the answer, trace the path far enough to understand where the problem occurs.

Audit the Website Across Eight Connected Areas

A useful website audit looks at what customers experience and what the business must operate behind it. The areas below help you build that picture without assuming every issue requires a new platform.

1. Positioning, Services, and Brand Expression

Read the main landing pages as someone who has never heard of the business. Can you tell what it does, who it serves, where it operates, and why the approach is relevant? Are the claims specific enough to evaluate?

Review the relationship between words and visuals. A business selling careful, complex work may be poorly represented by generic imagery and interchangeable copy. A growing organization may still present itself as the smaller operation it used to be.

List the factual changes separately from the expressive ones. Updating service information and creating a new visual system are related decisions, but they require different inputs and approvals. Design is strongest when it gives an accurate message a distinctive expression.

2. Content, Evidence, and Information Structure

Inventory important pages and assign each a purpose: explain a service, support a comparison, answer a practical question, establish credibility, or enable an action. Note whether it should be kept, updated, merged, removed, or created.

Look for missing decision information. Depending on the business, that might be scope, service area, timing, eligibility, product specifications, delivery details, or the factors that determine a quote. A page can sound polished while leaving the visitor unable to decide.

Check evidence as carefully as claims. Keep testimonials approved and relevant. Describe case studies accurately. Label concepts and hypothetical examples so readers can distinguish them from completed work and measured outcomes.

Google’s guidance on helpful, reliable content emphasizes usefulness to people. For a redesign, that makes content quality a planning responsibility: changing the layout should not conceal unanswered questions.

Review navigation with customer tasks in mind. Internal department names may be familiar to staff and meaningless to visitors. Map where different audiences need to go, including people arriving directly on an interior page.

3. Customer Journeys and Decision Support

Choose the journeys that matter most. For a service business, one might run from a search result to a service page, a relevant example, an inquiry form, and a received request. For another organization, the important action may be a purchase, donation, appointment, or information lookup.

Observe representative users attempting those tasks without coaching them through the interface. Ask what they expect, what they understand, and where they hesitate. Nielsen Norman Group’s introduction to usability testing describes this task-based observation as a way to identify problems and improvement opportunities.

Do not equate every longer visit with confusion or every shorter route with success. A visitor evaluating a consequential purchase may need detail, comparison, and reassurance. Someone retrieving urgent information needs a clear direct path.

Our article on intentional friction in web design explores that distinction. During diagnosis, ask whether effort helps the visitor understand the decision or merely makes the task harder.

Test entry points beyond the homepage. A campaign visitor may land on a specific offer without having seen your brand introduction. The page must provide enough context and a coherent next step on its own.

4. Mobile Use and Accessibility

Use actual phones as well as desktop previews. Check navigation, readable text, tap targets, form fields, sticky elements, and whether content remains usable when the on-screen keyboard appears. A layout fitting the screen does not establish that the task is comfortable to complete.

Try essential journeys using a keyboard. Inspect visible focus, logical order, meaningful labels, text enlargement, contrast, and whether motion preferences are respected. Include error states and third-party components in the review.

W3C’s Easy Checks for accessibility provides a useful starting point and explicitly explains that preliminary checks are not a complete evaluation. An automated score should not be treated as proof that everyone can use the site.

Agree the accessibility targets, evaluation scope, and acceptance criteria before estimating the work. Some barriers can be corrected in existing components. Others may reveal that the current design system or implementation needs broader changes.

5. Performance and Technical Reliability

Look at loading, responsiveness, and layout stability on representative pages and devices. Large media, unnecessary scripts, embedded services, and unstable components can affect the experience. Diagnose the contributing elements before assuming a different platform is necessary.

Google’s Core Web Vitals guidance focuses on loading performance, interactivity, and visual stability. Use those measures alongside observed task completion and actual user conditions. A single laboratory test is a useful investigation tool, not a complete account of every visitor’s experience.

Check broken links, error pages, downloads, internal search, and the behavior of essential integrations. Where relevant, review software dependencies, access controls, backups, and recovery arrangements with the people responsible for operating the site.

Separate an urgent reliability issue from a future design project. A failing checkout or inquiry route needs attention now, even if a broader rebuild is planned. Make the immediate intervention and the longer-term scope explicit.

6. Forms, Integrations, and the Work After Submission

Test from the visitor’s first input through the final destination. Use non-sensitive test information, identify it clearly, and confirm that the expected record reaches the appropriate person or system.

Include invalid entries, interrupted connections, unavailable appointments, and duplicate submissions where those states apply. Review what the visitor is told and how the business identifies a failure. Agree test conditions before interacting with payments or operational systems.

W3C’s form notification guidance explains the importance of clear error instructions and confirmation of task completion. The interface should accurately distinguish a request received from a booking confirmed or an order completed.

Document ownership of each connection: the form, email destination, CRM, scheduler, payment service, and follow-up process. An integration can be technically sound while its destination or business rules are outdated.

This is a core part of website support. A fix should be verified across the affected journey, including the handoff beyond the page.

7. Search Visibility and Migration Exposure

Before removing or replacing pages, identify which ones receive relevant search traffic, earn external links, or answer important customer questions. Check whether declining visibility relates to missing content, indexing problems, changed demand, or another factor that needs investigation.

Preserve useful material and page addresses when practical. If URLs must change, map old pages to relevant replacements, plan permanent redirects, update internal links, and check canonical URLs, sitemaps, and indexing settings.

Google’s site migration guidance recommends preparation, URL mapping, redirects, and monitoring. It also notes that rankings can fluctuate while changed URLs are recrawled and reindexed. A redesign proposal should account for that transition.

Review the requirements for machine-readable information and dependable actions alongside human use. Our guide to preparing a website for AI agents explains why clear content and reliable interactions remain useful foundations. An emerging technology should have a defined purpose before it becomes a rebuild requirement.

8. Editing, Ownership, and Platform Fit

Ask the team to demonstrate a normal update. Can they change a service description, add an article, replace an image, or correct a repeated business fact without breaking the layout or waiting indefinitely for help?

Inventory domain ownership, hosting, administrator access, licenses, integrations, content responsibilities, and support arrangements. Record who can approve changes and who responds when something stops working.

Then compare the current platform with actual requirements. Consider content relationships, editorial roles, commerce, integrations, accessibility implementation, maintainability, and expected growth. A familiar platform name does not settle those questions.

Distinguish a platform limitation from an implementation problem. An awkward editing experience may come from how a site was built. Conversely, repeated workarounds may reveal that essential requirements exceed what the current setup can sensibly support.

Our web design and development approach considers both visitors and the people maintaining the site. A successful new experience needs a workable operating model.

Decide Between a Targeted Fix, a Phased Redesign, and a Full Rebuild

The decision should follow the findings, dependencies, and cost of addressing them. Use the options below as a framework for discussion rather than a score that automatically selects a project.

Choose Targeted Improvements When the Problem Is Specific

Targeted work makes sense when the underlying structure supports the business and the obstacle can be isolated. Examples include rewriting an unclear service page, correcting a form destination, improving mobile navigation, repairing a reusable component, or optimizing a particularly slow page.

Define the affected journey, the change, and how it will be checked. A narrow scope still needs testing where other parts of the site depend on the same component or integration.

Also ask whether the fix is durable. A repair that repeatedly fails because of a deeper constraint may be a temporary measure, not the long-term answer. Document that distinction.

Choose a Phased Redesign When Several Areas Need Coordinated Change

A phased approach may suit a business whose foundation is usable but whose content, navigation, and design have drifted apart. It allows the team to prioritize important journeys while spreading content production and approvals over manageable stages.

Plan a shared design and content direction first. Without that, separately improved pages can become a collection of inconsistent experiences. Clarify which components are reused, which URLs remain, and how old and new sections will coexist.

Order phases by customer impact and dependency. A clearer service structure may need to precede new landing pages. A reusable form pattern may support several subsequent improvements. Each release should have its own acceptance criteria and measurement plan.

Choose a Full Rebuild When the Foundation Blocks the Requirements

A full rebuild becomes more persuasive when fundamental requirements cannot be met sustainably: an unsuitable content model, deeply coupled templates, unsupported dependencies, inaccessible interaction patterns that permeate the site, or integrations that cannot support necessary workflows.

It may also be appropriate when the business has changed substantially enough that repairing the old structure would preserve the wrong assumptions. The case should explain those constraints and compare the realistic alternatives.

Estimate the whole transition. Include content, design, development, migration, integration work, testing, training, and ongoing care. A rebuild that looks economical only because those responsibilities are omitted is not a meaningful comparison.

Prioritize Findings Without Losing the Bigger Picture

For every finding, record the evidence, affected audience, severity, confidence in the diagnosis, proposed response, dependencies, owner, and acceptance criteria. This turns a long list of observations into a plan someone can act on.

Address failures that prevent essential tasks before cosmetic refinements. Then weigh the impact of broader improvements against effort and dependencies. A missing service explanation may be more consequential than a dated illustration; a broken delivery route may be more urgent than either.

Mark whether the proposed work is a verified repair or a hypothesis to test. “Requests are sent to the wrong address” supports a specific correction. “This headline may create uncertainty” needs investigation or an experiment.

Keep one accountable owner for coordinating the priorities. Marketing, operations, sales, and technical teams may each hold part of the evidence. The plan should make their dependencies visible before work begins.

What a Useful Redesign Brief Should Include

A brief does not need to prescribe every screen. It should give the team enough shared context to propose an appropriate approach.

• Business context: what has changed, what the website needs to support, and why the work matters now.

• Audiences and tasks: who the site serves and what each group needs to understand or complete.

• Evidence and baseline: observed failures, useful existing assets, measurement limitations, and current performance.

• Content responsibilities: what must be written, verified, approved, migrated, or retired, with named owners.

• Functional requirements: forms, commerce, bookings, search, integrations, permissions, and business rules.

• Quality requirements: accessibility targets, device coverage, performance expectations, and acceptance criteria.

• Migration and ownership: URL changes, access, hosting, backups, handover, training, and support responsibilities.

• Delivery constraints: budget range, dependencies, realistic review capacity, milestones, and scope-change procedures.

• Success measures: what should improve, how it will be evaluated, and who owns the review after release.

Describe the need before prescribing the implementation. “Our editors need to publish location-specific services with approval” is more useful than requesting a particular plugin before the workflow has been understood.

When comparing proposals, ask each provider to explain what it will preserve, what it will change, what evidence supports the scope, and what assumptions could affect cost or timing. Compare equivalent responsibilities and deliverables.

Plan the Launch and the Work Beyond It

Build the release plan while the project is being scoped. Content approvals, domain access, integration credentials, redirects, measurement, and staff training can all become launch dependencies.

Agree who checks critical journeys, who authorizes release, how issues are reported, and what happens if a critical dependency fails. Where applicable, establish backups and recovery procedures before making changes.

After launch, verify the important actions again in the live environment. Check relevant forms, notifications, purchases, downloads, links, redirects, and analytics events within the agreed scope. Monitor error reports and search visibility through the transition.

Evaluate results against the baseline with context. If traffic quality, advertising, pricing, or service availability changed at the same time, avoid attributing every difference to the redesign. For smaller audiences, customer conversations and task testing may provide useful early evidence.

Assign ongoing ownership. Content becomes outdated, integrations change, and new business needs emerge. An agreed review cadence and clear support route give the website a practical way to continue improving.

A Practical Checklist Before You Commission the Work

Use the following questions to prepare the first conversation. They are a starting point for diagnosis, not a substitute for a full technical or accessibility assessment.

• Can we describe the business problem without using the word “redesign”?

• Which audiences and journeys are most affected?

• What evidence identifies the obstacle, and what remains uncertain?

• Which pages, content, and systems are already useful?

• Can visitors understand the offer and find a relevant next step?

• Do important actions work on mobile and through appropriate input methods?

• Do submissions reach their intended destination, with accurate confirmation?

• Which content and search landing pages must be preserved or mapped?

• Can our team update the site, and do we control the necessary accounts?

• Does the current foundation support the requirements without repeated workarounds?

• Have we compared targeted improvements, phasing, and rebuilding on equivalent terms?

• Who owns content, approvals, testing, launch, and ongoing care?

• What will count as improvement, and when will we review it?

Common Questions About Website Redesigns

How Often Should a Business Redesign Its Website?

Use changes in the business and evidence about the experience to guide the decision. Review regularly, but do not treat a fixed anniversary as proof that a rebuild is needed. A well-maintained site may need focused updates; a newer site can still have fundamental problems.

Can We Improve Conversion Without Rebuilding?

Often there are opportunities to clarify content, improve a journey, or repair a handoff within the existing site. Whether those changes improve business outcomes depends on the diagnosis, audience, implementation, and follow-up. A redesign alone cannot guarantee more or better inquiries.

Does a Redesign Require a New Platform?

No. Establish what the current platform and implementation can support. A platform change needs a reason grounded in requirements and operating costs, including migration and training. A new design and a platform migration can be separate decisions.

Will a Website Redesign Improve SEO?

It can address content and technical problems that affect discovery, but improved rankings are not automatic. Removing useful pages, changing URLs without appropriate redirects, or carrying development indexing restrictions into launch can introduce new problems. Search preservation belongs in the scope.

How Much Should We Budget, and How Long Will It Take?

Both depend on scope, content readiness, templates, integrations, accessibility requirements, migration, and review capacity. Ask for an estimate with named assumptions, inclusions, exclusions, and dependencies. Include recurring licenses, hosting, support, and internal time when comparing options.

What If We Do Not Have Enough Analytics Data?

Start with the evidence available: customer questions, inquiry quality, observed task completion, technical failures, and the team’s publishing experience. Establish reliable measurement for the future. Lack of a large dataset is a reason to be careful about conclusions, not a reason to skip diagnosis.

Make the Next Investment a Considered One

A thoughtful redesign can change how a business is understood and experienced. Its value comes from connecting a clear purpose to the message, structure, design, technology, and care required to deliver it.

The useful starting point is an honest description of what needs to change. Sometimes that leads to a precise improvement. Sometimes it reveals an opportunity for a broader new direction.

At Averane, we bring those decisions into the same conversation. If your website has fallen behind your business, talk with us about what is changing and what is getting in the way. You do not need a finished brief to begin. You need a question worth answering.