Website Redesign Strategy: A Practical Guide for Established Businesses

A website redesign is often treated as a visual project: choose a new look, replace the homepage, update the colours and publish. That approach can produce a more modern-looking site while leaving the underlying business problems untouched—or creating new ones. Important pages disappear, search traffic is disrupted, enquiries stop reaching the right people, and nobody is sure who owns the site after launch.

A stronger website redesign strategy begins with the business the website needs to serve. It connects customer needs, positioning, content, user experience, search visibility, technology and measurement before the design is finalised. This guide is for established businesses, professional-service firms and B2B organisations planning a redesign across South Africa, the UK, the United States, Canada and other English-speaking markets.

What a website redesign strategy should achieve

The purpose is not simply to make the site look newer. A redesign should make it easier for the right people to understand the organisation, evaluate its offer, find relevant information and take an appropriate next step. It should also make the website manageable for the people who maintain it.

Before discussing layouts or technology, agree on the business problems the project is meant to address. Depending on the organisation, these might include an unclear service offer, outdated information, difficult navigation, poor mobile usability, an inaccessible interface, a fragmented content structure, unreliable forms or a website that no longer reflects the organisation’s direction.

Refresh, redesign or rebuild: choose the right level of change

Not every underperforming website needs to be replaced. A complete rebuild can introduce cost, disruption and migration risk that a focused improvement would avoid. Start by identifying whether the problem is isolated, visual, structural or technical.

Project outcome	What it means in practice	Evidence to review
Clearer positioning	Visitors can understand who the organisation serves, what it offers and why the offer is relevant.	Customer questions, sales feedback, service-page engagement and enquiry quality.
Better journeys	People can find the right information and complete important tasks without unnecessary steps.	Navigation tests, form completion, task observation and support queries.
Protected search equity	Useful pages, URLs, links and search signals are not discarded casually during the rebuild.	URL inventory, Search Console data, backlinks, redirects and indexation checks.
Reliable operation	Forms, integrations, analytics, content editing and security responsibilities are understood.	Functional tests, access records, integration checks and maintenance ownership.
Measurable improvement	The organisation can compare the new experience with a meaningful baseline.	Pre-launch analytics, agreed success measures and post-launch reporting.

Option	Best suited to	Typical scope	Questions to ask
Fix	A small number of defects or bottlenecks.	Repair broken forms, navigation, layout issues, speed problems or outdated details.	Can the issue be resolved without changing the wider site?
Visual refresh	The structure and platform are sound, but the presentation feels dated or inconsistent.	Update typography, imagery, spacing, components and selected page layouts.	Will the refreshed design still support the existing content and user journeys?
Redesign	The organisation needs a clearer structure, stronger messaging or improved journeys.	Rework information architecture, page templates, content, navigation and interface design while retaining a suitable platform.	Which parts of the existing system should be preserved, improved or retired?
Rebuild or replatform	The current platform or architecture prevents essential changes, creates unacceptable risk or cannot support required functionality.	New technical foundation, content migration, integrations, redesigned templates and launch planning.	Is there a documented reason the current platform cannot meet the requirements?

A useful decision rule is to fix what is isolated, refresh what is mainly visual, redesign what is structural, and rebuild only when the underlying platform or architecture justifies it. Record the reason for choosing the level of change. That makes it easier to evaluate proposals and resist scope that does not solve the original problem.

1. Audit the existing website before changing it

The existing website contains evidence about what customers use, what search engines have indexed and what the organisation has already invested in. Begin with an inventory rather than assuming every old page is obsolete.

Review the business and customer evidence

• List the main reasons people visit the website and the actions that matter to the organisation.
• Review enquiries, sales questions, customer-service requests and recurring misunderstandings.
• Identify pages that explain complex services, answer objections or support a decision.
• Check analytics and Search Console data where available; record the period and limitations of the data.
• Ask people who use and maintain the site which tasks are difficult, repetitive or dependent on one individual.
• Review the site on mobile devices, desktop screens, keyboard navigation and common browsers.

Create a page and asset inventory

Record each important URL, its purpose, audience, owner, traffic or enquiry contribution where known, links pointing to it, and the action proposed for the redesign. Include PDFs, images, downloadable resources, forms and campaign landing pages. A page with modest traffic may still support an important sales conversation or contain information that customers cannot easily find elsewhere.

Do not delete pages simply because they are old, visually inconsistent or absent from the main navigation. Establish whether they have a business, search, legal, historical or customer-support purpose before deciding what happens to them.

2. Set measurable goals and a realistic project scope

Turn the audit into a short project brief. State the business problem, priority audiences, important tasks, pages in scope, required integrations, constraints, budget approach, decision-makers and launch dependencies. Define what the project will not include as clearly as what it will include.

Choose a small number of measures that reflect the actual purpose of the website. Depending on the business, these might include qualified enquiries, successful form submissions, appointment requests, relevant downloads, completion of a key task, reduced support requests or the proportion of visitors who reach an important service page. Establish a baseline before launch and do not invent a target if there is no evidence to support it.

Separate measures the website team can directly influence from broader business outcomes. A redesign can improve the clarity of an enquiry journey, but revenue also depends on pricing, sales follow-up, service quality, market conditions and other factors. Avoid attributing every commercial change to the website alone.

3. Build the new information architecture around user needs

Information architecture is the way pages and content are organised so people can understand where they are and where to go next. It should reflect how customers think about their needs, not only how the organisation is divided internally.

For a professional-services business, a visitor may need to understand a problem, compare a service, assess credibility, review the process and make contact. If the website is organised entirely around internal department names, the visitor may have to translate the organisation’s structure before finding the information they need.

Draft a sitemap and test it with people who resemble the intended audience. Ask them to find a service, locate a policy, understand who a service is for or identify how to make an enquiry. Watch where they hesitate. Rename, regroup or simplify sections when the evidence shows that the structure is unclear.

Keep navigation labels specific. Avoid using several labels that mean almost the same thing, and do not hide essential information behind clever but unfamiliar wording. Important pages should be reachable through descriptive internal links as well as navigation menus.

4. Rewrite content before polishing the design

Design cannot compensate for an unclear offer. If the organisation’s services, audience or value proposition are difficult to explain, settle the messaging before final page layouts are approved. This is also where a redesign can reveal that the business needs a positioning decision rather than a new colour palette.

For each priority page, define:

• Audience: who the page is intended to help.
• Intent: what the visitor is trying to understand or do.
• Main message: the most important point the page must communicate.
• Evidence: facts, process details, examples or credentials that can be verified.
• Next step: the most appropriate action for someone at that stage.
• Owner: who checks the content for accuracy and keeps it current.

Use customer language where it is accurate and appropriate. Replace vague claims such as “world-class solutions” or “innovative excellence” with specific explanations of the work, process, deliverables and boundaries. If the business makes a claim about experience, performance, compliance or results, make sure it can be substantiated and kept up to date.

Rainegy’s brand positioning strategy guide explains how audience needs, credible differentiation and evidence should shape the message. Its market research guide can help teams investigate customer questions and alternatives before rewriting important pages.

5. Design the experience for clarity, trust and accessibility

A professional website should make its structure and purpose easy to understand. Use consistent typography, spacing, colour, buttons and page patterns so visitors do not have to relearn the interface on every page. Make the main action visible without turning every section into a competing sales prompt.

Trust signals should be specific and relevant. Depending on the organisation, useful information may include clear contact details, the people responsible for the service, a transparent process, privacy information, verifiable credentials, documented policies and realistic explanations of what happens after an enquiry. Do not fabricate testimonials, client logos, awards or case studies to fill empty sections.

Accessibility should be considered during planning and design, not left until the final day. The W3C Web Content Accessibility Guidelines (WCAG) 2.2 provide testable criteria covering areas such as text alternatives, keyboard operation, focus visibility, contrast, target size and accessible authentication. The appropriate legal obligations depend on the organisation and jurisdiction; using WCAG as a design reference does not by itself establish legal compliance.

• Use semantic headings in a logical order and descriptive link text.
• Provide meaningful alternative text for informative images and empty alt text for purely decorative images.
• Ensure controls can be reached and operated by keyboard, with a visible focus indicator.
• Check colour contrast and do not rely on colour alone to communicate meaning.
• Make forms understandable, label fields clearly and explain errors in text.
• Test zoom, text resizing, touch targets and mobile layouts.
• Provide captions or transcripts for relevant audio and video content.

6. Plan performance and technical requirements early

Performance is influenced by the platform, hosting, page templates, images, fonts, scripts, plugins, third-party services and the way the site is built. A redesign is an opportunity to remove unnecessary complexity, but adding more animation, tracking scripts, embeds or large media files can make the new experience heavier than the old one.

Google’s web.dev documentation describes three Core Web Vitals used to assess real-world loading, responsiveness and visual stability. The current “good” thresholds are measured at the 75th percentile: Largest Contentful Paint (LCP) at or below 2.5 seconds, Interaction to Next Paint (INP) at or below 200 milliseconds, and Cumulative Layout Shift (CLS) at or below 0.1. These are diagnostic targets, not a promise of rankings or commercial results. See how the Core Web Vitals thresholds are defined.

Current asset	Decision	Reason to document
Service page that answers common buyer questions	Keep and improve	Preserve useful content and strengthen the next step.
Two pages covering the same subject	Consolidate if appropriate	Choose the most useful destination and map the old URLs carefully.
Outdated announcement with no continuing value	Retire or archive	Check for links, references and any replacement information first.
Download used by clients or partners	Keep or replace deliberately	Update links and make sure the file remains accessible.
Page with uncertain purpose	Investigate	Ask the content owner and check evidence before removing it.

Test on real devices and browsers used by the audience, including Safari on iPhone and Mac where relevant. A page that appears correct on a developer’s desktop can still have problems with mobile navigation, form fields, sticky headers, embedded content or touch controls.

7. Protect search visibility during the redesign

Search visibility can be damaged when useful pages are removed, content is weakened, internal links are broken, indexing controls are left in place or URLs change without a proper migration plan. The safest approach is to preserve valuable URLs when there is no strong reason to change them and plan every necessary change before launch.

Create an old-to-new URL map

For each existing URL, record whether it will remain, be updated, be consolidated into a relevant replacement or be retired. If a URL changes, map it to the closest equivalent new destination. Do not send unrelated old pages to the homepage simply to avoid a 404; the destination should make sense to the visitor.

Area	What to plan	What to test
Images and media	Appropriate dimensions, modern formats, compression and responsive delivery.	Image quality, loading behaviour, layout stability and mobile data use.
Fonts and styling	Limit unnecessary font files and avoid excessive visual effects.	Text rendering, layout shifts and readability at different sizes.
Scripts and plugins	Keep only components with a clear purpose and an owner.	Interaction responsiveness, errors and conflicts.
Hosting and caching	Confirm capacity, backup, security and caching arrangements.	Page response, availability and recovery procedures.
Forms and integrations	Document CRM, email, booking, payment and analytics dependencies.	Submission, validation, delivery, consent and failure handling.

Old URL (illustrative)	New destination	Action	Owner
/services/strategy-old/	/services/strategy/	Permanent redirect after confirming equivalent content.	SEO / developer
/insights/market-report/	/insights/market-report/	Keep URL and improve the page in place.	Content owner
/news/temporary-event/	No replacement	Retire only after checking links, references and user needs; return an appropriate status.	Content owner / SEO

Google’s site moves and migrations guidance recommends preparing and testing the new site, mapping old URLs to their new equivalents, implementing redirects and monitoring both sets of URLs. It also advises changing one major element at a time where practical. The detailed migration steps are especially relevant when the redesign changes URLs, the domain or the underlying platform.

Before launch, check that the new pages have appropriate canonical URLs, indexation settings, internal links and XML sitemap entries. Remove temporary noindex or crawl blocks from production where they are not intended. Update structured data where applicable, preserve useful image and document URLs where practical, and make sure the new site does not accidentally expose staging content.

Google’s SEO Starter Guide and guidance on crawlable links are useful references for descriptive page titles, understandable content, crawlable navigation and meaningful internal linking. SEO should be part of the project brief and quality assurance—not a final plugin setting added after design approval.

8. Set project ownership, scope and budget controls

Website projects become difficult to manage when responsibilities are vague. Identify one decision-maker, one day-to-day project lead, content owners, technical contacts and the person responsible for approving the final launch. Agree how feedback is collected and consolidated so the team does not receive conflicting instructions from several people.

When comparing proposals, compare the work included rather than the headline figure alone. Ask providers to separate strategy, research, information architecture, copywriting, design, development, content migration, SEO, integrations, testing, training and post-launch support. Clarify the number of templates and pages, who supplies content and images, revision limits, licensing, hosting, maintenance and what counts as additional work.

A transparent scope helps a business make a sensible decision about what to do now and what can wait. A focused improvement may be appropriate when the platform and structure are sound; a larger rebuild may be justified when technical limitations prevent the organisation from meeting its requirements. Neither option is automatically the better purchase.

Also confirm ownership and access. The organisation should understand who controls the domain, hosting, CMS administrator accounts, analytics properties, source files, licences, backups and third-party subscriptions. Arrange a handover so that the site does not become dependent on one person’s personal login or undocumented process.

9. Test the complete experience before launch

A visual review is not enough. Test the website as a customer, a content editor and an administrator. Use a launch checklist with a named owner beside every item that must be completed.

• Check the homepage, priority service pages, contact details and important resources.
• Test every form from submission to the actual receiving inbox or CRM.
• Check booking, payment, search, downloads, chat and other integrations where present.
• Review mobile navigation, buttons, menus, tables and long page layouts.
• Test keyboard navigation, visible focus, headings, labels, alternative text and error messages.
• Check spelling, dates, pricing, service descriptions, legal notices and contact information with the relevant owners.
• Test old-to-new redirects and confirm that they lead to relevant pages.
• Check canonical tags, robots directives, XML sitemap, analytics and consent settings.
• Check for broken links, missing images, placeholder text, staging references and console errors.
• Confirm backups, rollback responsibilities, security updates and administrator access.
• Test the site in current versions of major browsers and on real mobile devices.
• Record any known issue, its owner and whether it blocks launch or can be resolved afterwards.

Do not launch with a critical form, payment, booking or security issue simply because the visual design is finished. If a non-critical issue is accepted for later resolution, record the reason, owner and due date rather than leaving it undocumented.

10. Treat launch as the beginning of the improvement cycle

After launch, confirm that the live site is accessible, important pages can be crawled, redirects work and enquiries are being received. Monitor analytics, Search Console, error logs and customer feedback. A temporary fluctuation in search visibility can occur after significant changes while search engines recrawl and reprocess URLs; investigate specific errors rather than assuming every movement is caused by the design.

Period	Focus	Questions to answer
First 48 hours	Operational checks	Are pages loading, forms delivering, redirects working and tracking active?
Weeks 1–2	Technical and user issues	Are there crawl errors, broken journeys, missing content or recurring customer complaints?
Days 30–60	Early performance review	Which pages and journeys are being used? Where are visitors struggling?
Days 60–90	Prioritised improvement	Which changes are supported by evidence, and what should be tested next?

Keep a change log after launch. Record what was changed, why, who approved it and what happened afterwards. This makes future improvements easier to evaluate and helps the organisation avoid repeatedly redesigning the same problem without learning from previous decisions.

Common website redesign mistakes to avoid

• Starting with a mood board: visual direction is useful, but it should follow agreement on the business problem and audience.
• Removing content without an audit: a page that looks old may still answer an important question or attract valuable visitors.
• Changing URLs at the last minute: this creates avoidable redirect and internal-link work.
• Writing copy after the layouts are fixed: the design may not have room for the information users need.
• Ignoring accessibility: small interface decisions can make navigation and forms difficult for people to use.
• Adding features without owners: every integration, plugin and content component creates ongoing maintenance responsibilities.
• Launching without a baseline: the organisation cannot evaluate improvement if it never recorded the starting point.
• Confusing a launch with completion: the site needs monitoring, content ownership and a realistic improvement process.

Frequently asked questions about website redesign

How often should a business redesign its website?

There is no universal redesign interval. Review the website when the business changes, customer needs shift, the platform becomes difficult to maintain, accessibility or security issues emerge, or evidence shows that important journeys are not working. A focused improvement may be more appropriate than a full redesign.

Will a website redesign affect Google rankings?

It can. Risk increases when important content or URLs are removed, redirects are missing or irrelevant, internal links break, canonical signals are incorrect or the new site blocks crawling. Preserve useful URLs where possible and prepare a tested migration plan for necessary changes. No responsible provider can guarantee that rankings will remain unchanged.

How long does a website redesign take?

Timing depends on the number of page templates, content readiness, integrations, approval speed, technical complexity and migration requirements. Agree milestones for discovery, content, design, development, testing and launch rather than relying on a generic duration that may not fit the project.

Should we keep our existing website content?

Keep content that is accurate, useful and relevant to customer needs. Improve pages that have a sound purpose but need clearer messaging or structure. Consolidate overlapping material carefully and retire content only after checking its audience, search, legal and operational value.

What should be included in a website redesign brief?

Include the business problem, target audiences, priority user journeys, current-site findings, pages and functionality in scope, content responsibilities, SEO and migration requirements, integrations, accessibility expectations, decision-makers, budget boundaries, milestones and success measures.

How can a business control redesign costs?

Start with a clear scope, prioritise essential journeys, reuse content and components that still work, confirm who supplies copy and images, and document exclusions and change-control rules. Compare proposals on the same deliverables and consider whether a targeted improvement can solve the problem before commissioning a full rebuild.

Plan a website that supports where your business is going

A successful redesign is a coordinated business decision—not a contest to produce the most dramatic homepage. The organisation should understand what needs to change, what deserves to be protected, who will own the work and how the new experience will be evaluated.

Rainegy brings together brand and creative work, digital solutions, research and strategic communications. If your website needs clearer positioning, a more useful structure or a carefully scoped redesign, explore Rainegy’s services or contact the team to discuss the business need, deliverables and available resources. The right starting point may be a focused review rather than an unnecessary rebuild.

This article provides general planning guidance. Technical, accessibility, privacy and regulatory requirements vary by website and jurisdiction; obtain appropriate specialist advice for your circumstances.