What a Business Website Rebuild Actually Costs in 2026
Every few months a founder or a marketing lead asks me some version of the same question: what does a website rebuild cost, really? They usually follow it with a number they heard from somewhere else, a $6,000 quote from a freelancer, a $60,000 proposal from an agency, a $600 template site a cousin built over a weekend, and ask which one is real.
The honest answer is that all three can be right, for different projects. After 15+ years building on WordPress, and now running this site itself as a headless Astro frontend on Cloudflare Workers with WordPress underneath, I’ve priced rebuilds on both ends of that range and watched what actually separates a $8,000 project from an $80,000 one. It’s rarely the platform logo on the invoice. It’s five specific decisions, and most buyers never see the breakdown that would let them make those decisions with open eyes.
This is that breakdown. Ranges, not guesses, cost drivers you can actually control, and where I’ve watched budgets quietly evaporate on projects that were priced fine on paper.
Why “How Much Does a Website Cost” Is the Wrong First Question
A website rebuild isn’t a single product, it’s a bundle of separate decisions that each carry their own price tag: how many distinct page types you need, how much of the design is custom versus assembled from an existing system, which technical stack the site runs on, how much existing content has to move without breaking, and how fast and reliable the result needs to be under real traffic.
Ask “what does a website cost” and you’ll get answers that range 10x because the person answering is quietly assuming a scope you haven’t stated. Ask “what does a 12-page marketing site with a blog, one lead form, and a migration of 200 existing posts cost, built on WordPress with a page builder” and you’ll get answers that cluster within a sane range. Specificity is what makes pricing honest instead of arbitrary.
The Five Cost Drivers That Actually Move the Number
Scope and page count
This is the most obvious lever and the one buyers estimate worst. A “simple” business site is rarely five pages. It’s a homepage, an about page, three to six service or product pages, a team page, a contact page with a form, a blog index and template, a handful of legal pages, and usually two or three landing pages for specific campaigns nobody mentioned in the kickoff call. Each additional unique page type (not just a page, a type that needs its own layout logic) adds real design and build hours, even when the visual system is shared.
Design complexity and custom work
There’s a wide gap between “assemble a professional site from an existing, well-built theme or component library” and “design something nobody has seen before, then build it pixel by pixel.” Neither approach is wrong. A page builder or a solid theme is a legitimate, cost-effective choice for a business that needs to look credible and ship fast, it’s a trade-off toward speed and lower cost, not a mark of a cheap site. Fully custom design and build costs more because every component, every state, every breakpoint is being invented rather than configured. The right choice depends on how differentiated your brand needs to look and how much of that differentiation actually drives revenue.
Stack choice: WordPress, headless Astro + WordPress, or Laravel
This is the driver I get asked about most, and where I see the most confused pricing. Three stacks come up constantly for business sites:
Traditional WordPress (a theme or page builder, PHP rendering the page on request, usually behind a caching layer) is the fastest and cheapest way to a professional, editable site. It’s the right default for most businesses, and the ecosystem of plugins means most functionality you need already exists.
Headless WordPress with an Astro frontend (what this site runs on) keeps WordPress as the content editing backend but statically generates the actual pages your visitors see, deployed to edge infrastructure like Cloudflare Workers. It costs more upfront, you’re building and maintaining two systems instead of one, plus the deploy pipeline between them, but it buys meaningfully faster load times and a frontend that isn’t exposed to the plugin-vulnerability surface a live WordPress install carries. It’s the right call when performance or security posture is a genuine competitive factor, not just a nice-to-have, and the tooling behind that WordPress-to-Astro pipeline is a lot more mature than it was even a year ago, which is part of why the upfront cost has been coming down.
Laravel (a PHP framework, not a CMS) is for sites that are really applications wearing a marketing-site skin: custom booking logic, a proprietary dashboard, business rules that don’t map to any plugin. If your “website” is mostly content and forms, Laravel is more cost than the project needs. If it’s mostly custom logic, WordPress is the wrong tool no matter how many plugins you stack on it. I wrote a longer decision framework for choosing between WordPress, Laravel, or a hybrid build if you want to work through your own case.
Stack choice alone can shift a project’s cost by 30 to 100 percent, mostly because of what it does to the build line, not the design line.
Content migration
Everyone underestimates this one. Moving 40 blog posts with clean formatting is an afternoon. Moving 800 posts accumulated over a decade, with broken image links, inconsistent categories, embedded shortcodes from three retired plugins, and SEO equity riding on exact URL structure, is a project in its own right. Migration cost scales with volume and with how messy the source content actually is, and it’s the line item most likely to be quoted from a quick glance rather than an actual audit.
Performance and infrastructure targets
“Make it fast” means different things at different budgets. A well-configured WordPress install with a good host and a caching plugin gets most business sites into solid Core Web Vitals territory for a modest cost. Chasing the last stretch of performance, sub-second loads globally, resilience under traffic spikes, a CDN and edge caching strategy that’s actually tuned rather than defaults, costs more in both build time and ongoing infrastructure. Whether that last stretch is worth paying for is a real business question, not just a technical one, and I’ve written separately about why fast sites end up winning bigger clients if that’s the case you’re trying to make internally.
Honest Website Rebuild Cost Ranges for 2026
These are ranges I’d defend, not numbers designed to make any one option look best. They assume a US-based freelancer or small agency rate, not the lowest global bid you can find and not a large-agency retainer structure. Actual numbers move with page count, content volume, and how much custom design work is involved.
| Project type | Typical range | What drives it to the high end |
|---|---|---|
| Template or page-builder site, 5 to 10 pages, light content migration | $3,000 to $8,000 | Custom sections, more pages, a real content migration |
| Custom-designed WordPress site, 10 to 20 pages, blog, forms | $8,000 to $20,000 | Bespoke component design, integrations, larger migration |
| Headless WordPress + Astro rebuild, marketing site with blog | $12,000 to $30,000 | Larger page count, custom design layer, complex data models |
| Laravel custom application with marketing-site front end | $20,000 to $60,000+ | Depth of custom business logic, integrations, and admin tooling |
| Ongoing care (hosting, updates, monitoring) after launch | $150 to $1,500/month | Site complexity, uptime requirements, response-time SLAs |
Two things worth naming plainly: a quote well below these ranges usually means either a template with no customization or hours that quietly reappear later as change orders. A quote well above them, for a straightforward brochure site, is often paying for an agency’s overhead rather than your project’s actual complexity.
Where Rebuild Budgets Actually Get Wasted
I’ve watched the same three patterns burn budget on projects that were priced sensibly at the start.
Scope discovered mid-project instead of before it. The client didn’t have a real content inventory, so “migrate the blog” turns into discovering 200 more posts than anyone counted, three months in. An hour spent auditing existing content before a quote is issued saves multiples of that hour later.
Design approval cycles with no decision-maker in the room. Every extra round of “let me check with the team” on visual direction costs real hours, not because the design work changed, but because the project sits idle waiting on people who weren’t in the first conversation. Bring the actual decision-maker to the design review, every time.
Plugin or integration sprawl chosen for convenience, not fit. Bolting on five plugins to cover functionality a properly scoped build would have handled more directly usually costs more in the long run through conflicts, security patches, and slower pages, even though each individual plugin looked “free” at the point of installation.
None of these are villains. Page builders, plugins, template systems, all are legitimate tools that solve real problems for real budgets. The waste isn’t in choosing them, it’s in choosing them without knowing what they cost you downstream.
What Changes the Number Once the Project Is Underway
A few things reliably move a quoted number after the contract is signed, and it’s worth naming them before you’re surprised by one:
- A stack change mid-project. Deciding you actually want headless architecture after the WordPress build has started is close to a restart, not an add-on.
- A late decision to migrate more content than originally scoped. This is the single most common scope creep I see, and it’s almost always avoidable with an upfront audit.
- New integrations discovered during build, a CRM the sales team assumed was already connected, a booking system nobody mentioned in discovery.
- Performance requirements tightened after launch, usually after a competitor’s site gets noticed for being faster.
A Short Checklist Before You Request Quotes
Before you ask three agencies or freelancers for a number, get these answers first, it will make every quote you receive more comparable and more honest:
- Count your actual page types, not just pages, homepage, service pages, blog, landing pages, legal.
- Audit your existing content: how many posts, how messy is the formatting, does the URL structure need to survive the move.
- Decide how custom the design needs to be, and be honest about whether that’s a business need or a preference.
- Name every third-party system the site needs to talk to: CRM, booking, payments, email.
- Set a real performance bar, “fast” isn’t a spec, a Core Web Vitals target is.
Freelancer, Agency, or In-House Hire: How That Choice Changes the Number
The stack and scope questions above assume you already know who’s building the thing, but who you hire moves the number almost as much as what you’re building.
A skilled freelancer, working solo, usually lands at the low end of any range I’ve quoted, no account management layer, no separate design and development departments billing separately, just one person’s time. The trade-off is capacity: a solo freelancer can’t parallelize design and build the way a small team can, so timelines stretch even when the price doesn’t.
A small agency (two to eight people) typically prices in the middle of these ranges and can move faster because design, development, and content work happen in parallel rather than in sequence. You’re paying partly for that parallelization and partly for the project management overhead of coordinating it.
Bringing the work in-house only makes financial sense past a certain size, once you have enough ongoing web work to keep a hire genuinely busy, not just enough for a single rebuild. I’ve seen founders hire a full-time developer for a project that would have cost less, start to finish, as a contracted rebuild, simply because “in-house” felt more controllable. It usually isn’t, for a single project.
None of these is the objectively right answer. The right one depends on whether this rebuild is a one-time project or the start of an ongoing content and development cadence.
Get a Straight Answer for Your Project
If you’re staring at a range like the one above and want to know where your actual project lands, that’s a conversation, not a quiz. Bring me your page count, your content volume, and whatever stack question is keeping you up at night, WordPress, headless, Laravel, or some hybrid of the three, and I’ll tell you honestly where it falls and why. Reach out through my contact page and we’ll figure out the real number for your project, not a generic one.