Search what a website redesign costs and Google will show you Reddit threads. Four of them, plus Quora, plus a couple of Facebook group posts where a business owner is asking strangers to guess. Then a run of agency articles with price ladders in them.
That is not Google failing. That is Google correctly reporting that the professional answer to this question is worse than the amateur one. The agency pages publish tiers that were written before anyone looked at your site. The Reddit threads at least contain people describing what they actually paid for work they can describe.
So here is the version I would want if I were buying. Not a price list. The variables, in roughly the order they move the number, and what to ask before you believe any figure.
The short version, if you only want one thing from this page. Most people asking what a redesign costs are about to buy the wrong thing. The expensive mistake is not overpaying for a rebuild, it is buying a rebuild when the problem was a repair, which is roughly sixty percent of the requests that reach us. Run your site through the scanner and you will know which conversation you are in inside a minute, before anyone quotes you anything. Then come back for the variables.
And one disqualification up front, so nobody wastes an hour: if you want a firm number today without anyone looking at your site, we are not the firm. Several results on this page will give you one. What they are quoting is a guess with a decimal point in it, and you will renegotiate it in month two.
Why we do not publish a price for this
We rebuild two to four sites a year, one client at a time. Every one of those has been priced after a scoping conversation, and the range across them is wide enough that publishing a midpoint would mislead most of the people reading it.
There is a version of this page that puts three tiers in a table with checkmarks. It converts better in the short run. It is also a promise made before anyone has seen your content inventory, your integration list, or the four things your team does manually every week that nobody mentions until week three. I would rather lose the lead that wanted a number in ten seconds than win it and renegotiate in month two.
What follows is everything that would go into producing that number for you.
What actually moves the number
Template count, not page count
The single most common estimating error, made by buyers and by agencies. A four hundred page site with six templates is a smaller build than a forty page site with nineteen templates. Pages are content. Templates are engineering. When someone asks "how many pages is your site" as their first scoping question, they are estimating the wrong quantity.
Count your distinct layouts: home, service detail, location detail, team bio, blog index, blog post, case study, contact, and whatever one-off marketing pages have accumulated. That number is the closest single proxy to build cost that exists.
Content migration volume, and its condition
Moving content is not the expensive part. Moving content that has to be restructured is. If the old site put location hours in a free-text blob and the new one needs them as structured data so they can drive schema and a store locator, every location is a small manual job. Multiply by however many you have.
The question that separates cheap migration from expensive migration: does the new structure match the old structure? If yes, migration is close to scripted. If no, someone is reading every page.
Integrations, counted honestly
CRM, marketing automation, booking, payment, inventory, a members area, whatever the sales team has running in the background. Each one is a variable with its own risk profile, and the risk is usually not on our side. It is whether the other system has an API that does what its documentation claims, and whether someone at your company has admin credentials for it.
The integration that blows up a timeline is almost never the complicated one. It is the simple one that turned out to be owned by a vendor who takes three weeks to answer email.
Whether the site needs a real data layer
Some sites are documents. Some sites are applications wearing a document costume. A locations module that a developer hand-codes each time a store opens is the second thing. Once you need content that is queried rather than typed, you are building something with a different cost structure, and it is worth it precisely because the ongoing cost of the alternative compounds.
Original photography
A real shoot with a location, art direction, and color grading to the brand palette is a meaningful line item and it is the one clients most often cut and most often regret. The alternative is stock, and stock is why so many sites in the same industry look like each other. This is a genuine choice with a real price attached, not an upsell.
Compliance load
Accessibility conformance targets, HIPAA adjacency, and anything in a regulated vertical change the testing burden more than the build burden. If your industry has a compliance answer, it belongs in the first conversation, not in QA.
Platform
Last on this list on purpose. The platform decision matters enormously for what the site can do over five years, and it matters much less for what the initial build costs than most buyers expect. Anyone leading their estimate with platform is selling what they already know how to build.
What moves it less than people think
Design revision rounds. Everyone negotiates these. They are rarely where projects go over. Projects go over on content and on decisions nobody was empowered to make.
Total page count. See above. It affects migration effort and almost nothing else.
Whether it is "custom." The word has been diluted to uselessness. A themed site with the colors changed gets called custom. So does a bespoke template system. The word predicts nothing about price. The template count and the data layer do.
Timeline, which is the one thing I can state as a fact
For a build we run, eight to ten weeks, plus about a week on location if photography is in scope.
The Aussie Grill rebuild for Bloomin' Brands is the concrete version. Eight weeks of build, one week on location shooting actual food at an actual location, art directed and color graded to the brand palette. Nine weeks elapsed from kickoff to live deploy. The site went from failing Core Web Vitals on mobile to Good across every template, with the locations module moved onto a real data layer instead of a developer hand-coding each opening.
When redesigns run long, the cause is nearly always one of three things, and development speed is not among them:
- Content that was not written. The single most common delay. Design can proceed on placeholder. Launch cannot.
- Stakeholders who are not available. A two-day decision that waits nine days for a calendar is a seven-day slip, and they accumulate.
- A third party's schedule. See integrations.
A firm that promises a date without asking who writes the content and who signs off is promising a date it does not control.
How to read an estimate
An estimate is real when it can answer these without going back to the office. If a bid cannot, the number in it is a placeholder wearing a decimal point.
- How many distinct templates did you count, and what are they?
- Which pages are migrating as-is, and which are being restructured?
- What is the integration list, and who owns credentials for each system?
- What content are we writing versus what are you supplying, in writing?
- What is the approval chain, and who has final sign-off?
- What happens to our existing URLs, specifically?
- What is explicitly out of scope?
- What is the change process when scope moves, and what does a change cost?
- Who is doing the work, and are they employees or subcontractors?
- What does the site cost to run and maintain after launch?
- What happens if we want to leave, and what do we own?
Question six is the one I would not compromise on. A redesign that drops the redirect map is how a business loses rankings it took years to build, and it is invisible until about six weeks after launch when the traffic report arrives.
Question eleven separates vendors from landlords.
If you are writing an RFP
The reason bids come back with a five-times spread is almost never that one firm is five times better. It is that they are pricing five different projects, because the RFP described an outcome instead of a scope.
The minimum an RFP needs for bids to be comparable:
- The template inventory. Not page count. The list of distinct layouts.
- The content inventory, with a column for whether each item migrates as-is or gets restructured.
- The integration list, with the system owner named for each.
- Who writes copy. State it explicitly. This one line moves bids more than any other.
- The approval chain, with names.
- Your must-keep URLs, or at minimum a statement that a redirect map is required and will be tested.
- Launch constraints. Fiscal year, trade show, seasonal peak, whatever is real.
- What you will consider out of scope, so nobody has to guess generously.
You do not need a template for this. You need those eight things written down. An RFP that contains them will get you bids you can actually compare, which is the only thing an RFP is for.
If you are producing a proposal on the other side of this, the same list is the outline. A proposal that opens with the firm's history and gets to scope on page nine is a proposal that has not done the work yet.
The honest summary
Most sites do not need a redesign. Roughly sixty percent of the redesign requests we get describe a problem that is fixable in plumbing for a fraction of a rebuild, and we turn most of those down, because spending a client's budget on a rebuild that does not move their number is the wrong work regardless of who books the revenue.
The ones that do need it need it for structural reasons: the platform cannot support what the business now does, performance fails in a way that cannot be patched, positioning has moved and the site still sells the old thing, or the team has started routing around its own CMS.
If you are trying to find out what yours would cost, the fastest honest path is not a price list. It is a look at what is actually wrong with the site you have, which tells you whether you are pricing a rebuild or a repair. Those are very different numbers, and most people asking the first question turn out to need the second.
Run your site through the scanner. It takes about a minute, it checks performance, structure, functionality and design against what Google actually measures, and it will tell you which of those two conversations you are in before anyone quotes you anything.