Should I redesign my website? A decision framework for founders

Should I redesign my website? Only if the problems are structural: your platform cannot do what the business now needs, your brand has moved and the site has not, or years of patches have left it slow in ways no plugin fixes. If every complaint you have is about a page, a paragraph, or a load time, you need a refresh, not a rebuild, and a rebuild would be the more expensive way to get the same result. This article gives you a scored self-diagnosis that lands on one of three outcomes, explains what actually drives the cost of each path, and covers the migration risks that most redesign advice leaves out.

Most traffic and conversion drops are not design problems

Before you blame the design, rule out the causes that have nothing to do with it. A redesign is the most expensive possible diagnostic, and founders reach for it because the site is the thing they can see. Spend an hour on these checks first.

• Open Search Console and look at the date the decline started. If it lines up with a known Google core update, you have a content and authority problem. A new layout will not fix it.
• Check that analytics tracking still fires. A cookie banner update, a tag manager change, or a consent-mode rollout can erase a third of your reported traffic overnight while real traffic is flat.
• Compare year over year, not month over month. Many B2B sites drop every August and December and recover on their own.
• Segment by landing page. If three pages lost 80% of the traffic and the rest held, you have three stale pages, not a broken site.
• Segment by device. A site that converts on desktop and fails on mobile has a specific fixable fault, not a design identity crisis.

If the decline survives all five checks and shows up across most pages and both devices, the site itself is a plausible cause. Now the redesign question is worth asking.

If every problem is a page or an element, a refresh is enough

A website refresh keeps the platform, the URL structure, and the information architecture. It changes what sits inside them: copy, images, spacing, a handful of templates, and the technical things that make pages slow. Most sites under four years old that feel tired belong here.

Refresh-scale problems look like this. The homepage headline describes what you sold two years ago. Images are oversized and the site scores badly on Core Web Vitals, but the fixes are compression, lazy loading, and removing two dead scripts. The contact form has too many fields. Mobile navigation hides the one thing visitors want. The typography and colour palette feel dated but the layout still makes sense. Individually these feel like a case for starting over. Together they are a fortnight of focused work on a site you already own.

The test is simple. Write down every complaint. If each one points at a specific page or a specific element, you can fix them one at a time without touching the foundations. That is a refresh, and it carries almost none of the risk described later in this article.

Three signals mean you have hit a rebuild, and no refresh will get you past them

A rebuild is justified when the problem is the foundation, not the finish. Three signals reliably mark that line.

• Platform ceiling. The business now needs something the platform cannot do without fighting it: gated content, a real integration with your CRM or booking system, multi-region pricing, a custom checkout, or motion and interaction that a page builder cannot express. When every new requirement turns into a workaround plugin, the platform is the problem.
• Brand shift. You have repositioned, moved up-market, changed the audience, or renamed. A refresh can restyle a site, but it cannot change what the site is about. If the structure of the navigation and the story the pages tell no longer match what you sell, you are describing a new site.
• Performance debt. The site is slow because of how it is built, not because of what is on it. Twelve plugins, three tracking suites, a theme that loads its entire library on every page, and a database of orphaned content. You can optimise images forever and the Largest Contentful Paint will not move. This is the one people misdiagnose most, because it looks like a speed problem and gets treated with speed plugins that make it worse.

Two weaker signals add weight without deciding the case on their own: the team is afraid to change anything because the last edit broke something, and you cannot find anyone who still supports the theme or framework you are on. These are the same ceiling problems that show up in software more broadly, and the reasoning in 5 signs your backend needs re-architecting applies to a marketing site just as well.

Ten yes-or-no questions settle the refresh versus rebuild decision

Score one point for each yes on questions one to five and two points for each yes on questions six to ten. The weighting is deliberate: the second group describes structural faults that a refresh cannot reach.

• 1. Is the main headline or offer out of date?
• 2. Do images, video, or fonts make the site fail Core Web Vitals?
• 3. Does the mobile layout hide or break a key action?
• 4. Have you tested your own forms this month and found one failing?
• 5. Does the visual style look older than your competitors' sites?
• 6. Has your positioning, audience, or name changed since the site launched?
• 7. Does a business requirement need a workaround plugin or a manual process because the platform cannot do it?
• 8. Is the site slow even after image and script optimisation?
• 9. Does the navigation or page structure no longer match what you sell?
• 10. Is the team afraid to edit the site, or is the platform or theme no longer supported?

Zero to two points: leave it alone and spend the money on content or distribution. Three to six points, with most coming from the first five questions: refresh. Any score where the second group contributes four or more points: rebuild, because two structural faults rarely resolve without changing the foundation. A high score made entirely from the first group is still a refresh, however uncomfortable the site feels day to day.

Cost is driven by scope and content volume, not by the word redesign

Kaev does not publish pricing and neither should this article pretend the market has one number. What can be said honestly is what moves the cost, and the drivers differ sharply between the two paths.

A refresh costs mostly time, and the time scales with how many templates need attention. Copy rewrites, image replacement, and performance work on an existing platform sit at the low end of any agency or freelancer price list. The risk is scope creep: a refresh that touches every template has quietly become a rebuild without the planning a rebuild deserves.

A rebuild cost has four drivers, and you control three of them.

• Custom versus template. A templated build on a page builder is the cheapest tier. A fully custom design with engineered motion, like the cinematic websites Kaev builds, is the most expensive tier and only pays off where the site is doing the selling. The reasoning is covered in when cinematic design pays off.
• Content volume. Every page that must be migrated, rewritten, or redesigned adds cost. A 12-page site and a 400-page site with a blog are different projects even with identical designs.
• Integrations. CRM, booking, payments, gated content, and search each add engineering time and each add a place for the launch to go wrong.
• Your team's time. Content approval, stakeholder reviews, and asset gathering fall on you, and this is the cost founders most consistently leave out of the plan. Late content is the most common reason a rebuild slips.

For the general market ranges on custom work, see how much a custom website costs. Kaev scopes and quotes every project individually after a 30-minute call.

A rebuild can make results worse for months, and the risks are avoidable

Here is the part most redesign advice skips. A full rebuild is a migration, and migrations lose things. Sites that rank well and then relaunch with new URLs, a new platform, and no redirect plan routinely drop in search for weeks or months. That loss is not a design failure. It is a project management failure, and it is preventable.

• URL mapping. Export every indexed URL before the build starts. Every one of them needs a destination on the new site or a permanent redirect to the closest equivalent. Redirect chains and blanket redirects to the homepage throw away the ranking those pages earned.
• Tracking continuity. Analytics, conversion events, consent management, and ad pixels have to be rebuilt and tested before launch, not after. A relaunch with broken tracking means you cannot even measure whether the redesign worked.
• Content parity. Rebuilds tempt teams to cut pages that look unloved. Some of those pages are the ones AI assistants and long-tail search send traffic to. Check Search Console before deleting anything.
• Structured data and metadata. Titles, descriptions, schema, canonical tags, and the sitemap rarely migrate automatically. Each needs a checklist line.
• A monitoring window. Watch Search Console crawl errors, indexed page count, and conversion rate daily for the first month. Problems found in week one are cheap. Problems found in month three have already cost you a quarter.

One more modern reason to be careful, and also a reason a rebuild can be worth it. AI assistants increasingly answer commercial questions by quoting pages that state things plainly in the first paragraph and structure content as answers. A redesign that restructures your pages around clear, citable answers can improve visibility in those tools. A redesign that buries the answer under hero video and vague headlines can remove you from them. The mechanics are covered in what generative engine optimization is.

Results show up on a predictable timeline if you record baselines first

You cannot judge a redesign against a feeling. Before any work starts, record a baseline: organic sessions by landing page, conversion rate by device, Core Web Vitals scores, indexed page count, form completion rate, and the number of qualified enquiries per month. Take three months of history so seasonality is visible.

Then set expectations for when each metric should move. Performance scores change the day you launch. Conversion rate should show a direction within 30 days, once enough traffic has passed through. Search rankings are the slow one: a well-migrated site typically holds steady through a period of re-crawling and may take 60 to 90 days to settle, and a site that gained ground in search will usually show it by the 90-day mark. Compare each metric at 30, 60, and 90 days against the same period a year earlier, not against the month before launch.

If conversion rate is flat at 90 days on the same traffic, the redesign did not do its job, and the reason is usually that the content and offer did not change even though the design did. That outcome is common, and it is why the refresh path deserves more respect than it gets: a sharper headline on an old site often outperforms a vague headline on a new one.

Sometimes the right answer is to leave the site alone

The redesign is the wrong spend when the site is not the bottleneck. If you have fewer than a few hundred visitors a month, no design change will produce a measurable difference, and the money belongs in getting people to the site at all. If the site converts fine and the founder is simply bored of looking at it, that is a taste problem and not a business one. If the last redesign was under two years ago and the complaints are cosmetic, the pattern in why your MVP architecture will cost you later applies in reverse: you rebuilt too early last time, and rebuilding again will not fix a planning habit.

The strongest reason to wait is a pending business change. If a repositioning, a new product line, or a funding round is six months out, a rebuild now will be redesigned again in a year. Do the refresh, hold the structural questions, and rebuild once when the answers are known.

Common questions

How often should a website be redesigned?

There is no fixed cadence, despite the three-to-five-year rule that circulates. Redesign when a structural signal appears: platform ceiling, brand shift, or performance debt that optimisation cannot fix. A well-built site with regular content and performance refreshes can run well beyond five years.

What is the difference between a website refresh and a website redesign?

A refresh keeps the platform, URLs, and page structure and changes copy, imagery, styling, and performance. A redesign, or rebuild, replaces the foundation: new platform, new structure, often new URLs. A refresh carries almost no migration risk. A rebuild carries all of it.

Does redesigning a website hurt SEO?

It can, and often does when URLs change without a redirect map or when pages are deleted without checking what traffic they carried. A rebuild with full URL mapping, content parity, migrated metadata, and a monitoring window usually holds rankings and can improve them. The damage comes from the migration, not from the design.

How long does a website redesign take?

A refresh on an existing platform typically takes two to six weeks depending on how many templates are touched. A custom rebuild typically runs two to four months from scoping to launch, and content approval on the client side is the most common cause of delay. See the detailed breakdown in the article on how long a custom website takes to build.

Should I redesign my website myself or hire an agency?

If the score in this article says refresh and you are on a builder like Webflow, Squarespace, or WordPress, most of the work is within reach of a capable founder or a freelancer. If it says rebuild and the drivers are integrations, performance debt, or a brand shift, hire people who have migrated sites before, because the cost of the rebuild is small next to the cost of a botched migration.