Website Redesign: How to Plan, Run, and Launch Yours

A website redesign is a rebuild of an existing site's structure, content and interface, usually carried out on the same domain and with the old addresses mapped across so the search visibility survives the move. That last clause is where most projects come apart.

The visual part of a redesign is the part everyone plans for. The parts that decide whether the project pays for itself are less photogenic: what the current site is actually ranking for, which pages earn the leads, where every old URL is going to land, and who signs off before the switch is flipped.

This guide covers the full cycle in seven steps, plus the three questions people ask before committing: what a redesign includes, what agencies charge for one in 2026, and how long it takes.

A redesign in 2026 covers four layers at once: the information architecture, the content, the interface, and the technical foundation underneath. Rebuilding one layer and calling it a redesign is what produces a prettier site that performs exactly like the old one. The scope question is settled by which layers you touch, not by how different the homepage looks.

Information architecture. The page inventory, the navigation, the URL structure and how pages relate to each other. This is the layer that moves search rankings, and it is the layer most redesign briefs forget to mention.

Content. Not a copy-paste of the old text into new templates. A redesign is the natural moment to retire pages nobody reads, merge three overlapping service pages into one, and rewrite the value proposition that has drifted since the last rebuild.

Interface. Layout, typography, component library, responsive behaviour, accessibility. The visible layer, and the one clients judge the project by.

Technical foundation. Hosting, CMS, rendering approach, performance budget, analytics, form handling, tracking. Changing this layer is the difference between a redesign and a replatform, and it carries the most risk.

Three things are commonly called redesigns and are not. A theme swap changes the interface only. A content refresh changes the copy only. A replatform moves the technical foundation while keeping the design, which is a migration project with its own risk profile. Each is a legitimate piece of work. None of them will fix a site that is losing enquiries for structural reasons.

You need a full redesign when the problem is structural, and a refresh when the problem is cosmetic. The practical test: write down what is failing, then ask whether fixing it requires changing the page inventory or the navigation. If it does, that is a redesign. If new photography and tighter copy would close the gap, a refresh will get you there in a fraction of the time and budget.

Signals that point to a full redesign: the site cannot support pages you now need to sell, navigation has grown by accretion and nobody can find anything, mobile behaviour is patched rather than designed, the CMS blocks the marketing team from publishing, or the technical foundation makes performance work impossible. Signals that point to a refresh: dated visuals, stale copy, weak calls to action, thin service pages.

The costly mistake runs in both directions. Redesigning when a refresh would do burns budget and resets search equity for no reason. Refreshing when the structure is the problem produces the familiar outcome where a site looks better for a quarter and converts the same as before.

A website redesign costs between €6,000 and €80,000 in 2026, and the band you land in is set by three things: how many pages change, how much copy has to be written rather than migrated, and whether other systems connect to the site. Small corporate rebuilds on an existing CMS start around €6,000. Mid-size B2B projects with new structure and new commercial pages run €15,000 to €35,000. Platform changes, several languages or CRM integration push past €35,000.

Those bands assume your content already exists and is approved, which is the single assumption that moves a quote most. The line-by-line breakdown of what a quote should contain, why two suppliers price the same brief threefold apart, and how to compare three offers is in our guide to website redesign cost.

A website redesign takes four to twenty weeks depending on scope. Small corporate sites run four to six weeks, mid-size B2B rebuilds six to ten, and projects with integrations or e-commerce twelve to twenty. Add two to six weeks per additional language.

Content readiness moves this number far more than design or development speed: a project with copy already written and approved runs at the bottom of every band. The full schedule by phase, with the forty checkpoints that hang off it, is in our website redesign checklist.

Step one is deciding what the redesign is supposed to change in the business, in numbers. Step two is finding out what the current site already does well, so you do not destroy it by accident. Both steps happen before anyone opens a design tool, and skipping them is the most expensive shortcut available in the whole process.

Step 1: business goals. A usable goal names a metric and a direction: qualified enquiries from the site, cost per lead, the share of visitors who reach a service page, the time it takes marketing to publish a new page. Goals like a modern look or better user experience cannot be tested after launch, which means the project can never be declared a success or a failure.

Write down the current value of each metric before the project starts. If you cannot measure it today, the redesign cannot improve it, and the first task is instrumentation rather than design.

Step 2: the audit. Three inventories, all of which feed later steps:

• Search. Which URLs are indexed, which queries they rank for, which pages earn organic entries. This becomes the redirect map in step seven, so export it now rather than after the old site is gone.
• Behaviour. Which pages get traffic, which convert, where sessions end. Pages that convert get protected, whatever the design team thinks of them.
• Technical. Performance against Core Web Vitals, accessibility, mobile rendering, broken links, index bloat.

Our website audit guide walks through the full procedure. According to Google's guidance on Core Web Vitals, these field metrics reflect real user experience rather than lab conditions, which is why a redesign should record them before and after rather than trusting a synthetic score.

Content and structure are the two steps that decide whether the new site sells, and they are the two steps clients most often try to run in parallel with design. They cannot be. A designer building templates without a page inventory is guessing at what the templates need to hold, and the guess gets discovered during build, at the worst possible moment.

Step 3: content. Start from the inventory produced in the audit and assign every existing page one of four verdicts: keep as is, rewrite, merge into another page, or retire. Retiring is the decision people avoid, and it is usually the highest-value one. A site with sixty pages where twelve earn everything is easier to navigate, cheaper to maintain and clearer to search engines once the other forty-eight are consolidated.

Then write what is missing. Most redesign briefs discover at this point that the service pages have never explained pricing, that there is no proof beyond a logo strip, and that the value proposition on the homepage describes the company rather than the customer's problem.

Step 4: structure. The page inventory becomes a navigation tree and a URL scheme. Two rules save a great deal of pain later: keep the existing URL wherever the page survives unchanged, and decide the URL of every new page before templates are built, not after. Our guide to planning website structure covers how to build the tree, and website architecture and search visibility covers why the shape of that tree affects what ranks.

Design and build are where a redesign becomes visible, and where the earlier steps either pay off or fail loudly. If the content is written and the structure is agreed, this phase is mostly execution. If they are not, this is the phase where the project discovers it, and every discovery here costs more than it would have cost in step three.

Step 5: design and prototype. Templates rather than pages. A corporate site typically needs six to ten: homepage, service page, case study, blog article, listing, contact, legal, and whatever the business specifically requires. Each template gets designed once and reused, which is what keeps the build predictable.

Prototype the flows that matter before development starts. The path from a service page to a submitted enquiry is worth testing with real people while it is still cheap to change. So is the mobile navigation, which is where most corporate sites quietly lose people.

Step 6: build. Development against the approved templates, content loaded, forms and tracking wired, performance budget enforced as pages are built rather than audited at the end. Accessibility belongs here too: retrofitting contrast, focus states and semantic structure after launch costs several times what building them in does.

One decision in this phase has search consequences well beyond the build. According to Google Search Central, Googlebot renders JavaScript, but rendering is deferred and resource-dependent, so content that only exists after client-side execution is at greater risk of being missed. If the redesign moves to a JavaScript framework, server rendering for content pages stops being a preference and becomes a requirement.

Going live is a search event, not just a deployment. Every URL that changes has to point somewhere deliberate, and the mapping has to be built before launch day rather than reconstructed from 404 reports afterwards. This is the single step where the difference between a careful redesign and a careless one shows up in traffic within weeks.

The order that works:

1. Freeze the URL inventory. Indexed URLs from Search Console, a full crawl of the current site, the current sitemaps, pages with organic entries or conversions, and pages with external links pointing at them.
2. Map every one of them. Each old URL gets a decision: keep, redirect, consolidate into another page, or remove deliberately.
3. Implement permanent redirects in a single hop. According to Google Search Central, a permanent redirect signals that the move is permanent, and chained redirects waste crawl budget. Redirect old to new directly, never old to interim to new.
4. Regenerate the alternates. If the site is multilingual, hreflang annotations have to point at the new canonical URLs and reference each other in both directions. Google's documentation on localized versions sets out the requirements.
5. Verify on staging, then again in production. Staging must be blocked from indexing before the work starts and unblocked at go-live. Getting that pair of switches backwards is one of the more common ways to lose a month.
6. Keep the redirects. Google advises keeping them for at least a year, and there is no reason to remove them after that if the old URLs still receive traffic or hold links.

Two things worth stating plainly, because most redesign checklists get them wrong. A temporary redirect does pass signals; the reason to use a permanent one is that it declares the move permanent, not that the alternative leaks value. And Google publishes no number for how long a dip lasts after a move, only that fluctuation should be expected while signals consolidate. Any article quoting a fixed recovery window is quoting a vendor's experience, not documentation.

The full procedure, including the mapping table specification and what to monitor afterwards, is in our guide to redesigning without losing SEO.

Redesigns fail for a small number of repeated reasons, and almost all of them are decided before launch. In our experience the pattern is consistent: the projects that go wrong are the ones where design started before the content and the URL inventory existed, so every later step inherited an unfinished decision.

The four failure modes worth naming:

• Design led the project. Templates were approved before anyone knew what would go in them, and content was squeezed to fit the layout instead of the reverse.
• The old site was treated as worthless. Pages that were earning enquiries were retired because they looked dated, and nobody checked the analytics first.
• Migration was scoped as an afterthought. The redirect map was assembled in the last week, from an incomplete list, by whoever was free.
• Nothing was measured before. No baseline means no way to tell whether the new site is better, which means the next redesign will start from the same guesswork.

Pre-launch checklist. Nothing on this list should be ticked on launch day itself:

1. Every indexed URL appears in the mapping table with a decision recorded against it.
2. Redirects are implemented, resolve in one hop, and have been tested against the live list.
3. Internal links point at final URLs, not through redirects. Check content bodies as well as navigation and buttons; they are usually stored separately and the second pass is the one people forget.
4. Canonical tags reference the new URLs, and hreflang annotations reference each other.
5. Staging is noindexed; production is not. Verify both after deployment, not before.
6. Sitemaps regenerated and submitted, with accurate last-modified dates.
7. Analytics, goals and form tracking fire on the new templates. Verify a real submission.
8. Performance and accessibility measured on the new pages against the pre-launch baseline.
9. Titles and headings preserve the meaning that made pages rank; wholesale rewriting of every title changes what the page is relevant for.
10. A monitoring plan exists for the weeks after launch, with someone named as owner.

After go-live the work is not finished, it changes shape. Our guide to post-launch optimization covers what to watch and in what order. If you would rather have the whole cycle run by a team that does it regularly, that is what our corporate website work consists of.