How Much Does a Website Cost in 2026? A Quote Decoder for SMEs

Three quotes land on your desk for the same brief: 8,000 dollars, 22,000 dollars, 48,000 dollars. All three say "company website." That is a six-fold spread for what looks like the same product. The confusion is not your fault. Most website quotes are not written to be understood; they are written to be signed.

This article does one thing: it puts the 2026 price ranges, the real drivers behind the spread, the eight line items you must interrogate in any quote, and the three-year total cost of ownership on the same table. By the end you should be able to answer one question on your own: what exactly am I buying at this price?

One position up front, because it shapes everything else: cheap is not automatically bad, and expensive is not automatically good. Price in this market reflects three things — hours invested, responsibility assumed, and scope included. You are not shopping for the lowest number. You are shopping for the most of what you actually need per dollar.

What a business website actually costs in 2026

Direct answer: a small business website in North America typically runs 2,000 to 15,000 dollars, mid-size projects 15,000 to 60,000 dollars, and enterprise builds start around 50,000 dollars. Anything outside those bands is not automatically wrong, but you need to know what the extra money buys and what the missing money leaves out.

The ranges below are drawn from HubSpot analysis of website design costs:

The most important column is the third one. Two vendors quoting 12,000 dollars can be selling completely different products: one delivers five pages plus responsive design plus basic SEO plus a year of maintenance, the other delivers ten pages plus full copywriting plus product photography. Normalize column three first, then compare column two.

Page count is another honest anchor. The same analysis puts 1 to 10 pages at roughly 1,000 to 2,000 dollars, 10 to 50 pages at 2,000 to 6,500 dollars, and 150-plus pages at 6,500 to 10,000 dollars and up. If a vendor quotes a flat number without asking how many pages you need, they are guessing — and you will pay for that guess later in change orders.

Platform choice sits underneath all of this and quietly sets your cost structure for the next decade. W3Techs CMS usage statistics dated 6 September 2026 put WordPress on 40.7 percent of all websites and 58.9 percent of sites where a CMS is detected. There is a baseline trap worth defusing before you read any comparison: platform sizes only mean something when measured on the same ruler. On the CMS baseline, Shopify holds 7.7 percent, Wix 6.1 percent and Squarespace 3.6 percent, which puts WordPress at roughly 7.6 times the size of the runner-up. The tenfold gap you see quoted elsewhere comes from dividing the 58.9 percent CMS figure by Shopify's 5.3 percent all-sites figure. Those are two different rulers and the result is meaningless.

The direction of travel is real, and faster than most people assume. The W3Techs historical trend table shows WordPress at 62.9 percent of the CMS subset in early 2024, 62.0 percent in early 2025, and 58.9 percent in the September 2026 reading: 0.9 points lost across the first stretch, 3.1 points across the second, roughly 3.4 times faster. In the same table the open-source trio of WordPress, Joomla and Drupal fell from a combined 67.0 percent to 61.6 percent, a loss of 5.4 points, while the SaaS trio of Shopify, Wix and Squarespace climbed from 12.8 percent to 17.4 percent, a gain of 4.6 points. What open source lost, hosted builders picked up almost one for one. We break the platform decision down in WordPress versus SaaS website platforms.

Why three quotes for the same brief differ by five times

Direct answer: the spread almost never comes from margin. It comes from the product of four things — design hours, functional complexity, content scope, and depth of responsibility assumed. Interrogate the six variables below and three wildly different quotes usually collapse into the same order of magnitude.

Variable one: template versus custom design. Buying a theme and swapping colors versus drawing original UI from a blank canvas is a five-to-ten-fold difference in hours. Premium themes run 60 to 300 dollars; custom design is real person-days. Neither is wrong. If visual differentiation does not move your buyers, a template is the smart call. If you are asking a North American buyer to trust an unfamiliar supplier, custom usually earns its keep.

Variable two: revision rounds and how a round is defined. This is the most expensive invisible clause in any quote. "Unlimited revisions" either hides an internal hours cap or has already been priced into the total. And "three rounds" needs its own definition: is a round one consolidated batch of feedback, or does changing a single word burn one? Leave this vague and you will argue about it in month three.

Variable three: functional complexity. A contact form and a "multilingual plus product specification database plus quote cart plus member login" build are not separated by a few extra pages. They are separated by data modeling, permission design, and an entirely different test matrix. Manufacturers underestimate the product database most often: making 300 SKUs filterable and indexable is systems work, not design work.

Variable four: whether responsive design and baseline SEO are included. In 2026, any quote still listing responsive design as a paid add-on can be discarded immediately. But "basic SEO" means wildly different things. Is it a plugin install, or actual heading structure, structured data, sitemap submission, and Google Search Console configuration? Are page experience thresholds part of acceptance? Google documents Core Web Vitals precisely enough that you can paste the targets straight into your specification, and web.dev publishes the current thresholds you can test against.

Variable five: whether content production is included. This is the single most common budget blowout we see. The quote says "copy provided by client," the owner reads that as savings, and four months later the site cannot launch because nobody had time to write twelve pages of product descriptions. Content is never free. The cost simply moved off the quote and onto your own staff.

Variable six: who is doing the work. Solo freelancers, three-person studios, and twenty-person agencies have structurally different cost bases. Freelancers are cheap but have no backup. Studios are flexible but vary enormously in project management maturity. Agencies bring process and handover documentation, and you pay a project management line for it. There is no universally right answer, only a principle: the bigger the project, the more you should be willing to pay for someone being able to take over.

The three dimensions behind a threefold spread: hours, liability, aftercare

Direct answer: collapse the six variables one more time and only three dimensions remain — how many hours of a human being you are buying, how much liability the vendor is willing to carry, and whether anyone answers the phone after launch. One grade of difference on each, multiplied together, is your threefold spread.

Dimension one: hours. You are buying days of somebody's attention. Every total on every quote decomposes into a rate multiplied by person-days. A five-page brochure site where the designer works from wireframes through visual comps to front-end build might be a dozen person-days. The same five pages configured on a bought theme might be three to five. Neither number is dishonest; they describe different products.

The crude test works well: divide the total by the person-days you think the job needs and see whether the implied day rate is plausible in your market. If a quote covers ten custom pages plus a second language at a day rate that would not cover one competent developer, the shortfall is not efficiency. Some slice of the work has simply not been priced — usually testing, revision rounds, or post-launch support. This is why asking "how many person-days have you allowed, and which roles" gets you further than asking for a discount. The first question forces assumptions into the open. The second just makes the vendor quietly remove days.

Dimension two: liability. Whose problem is it when something breaks. The second dimension is harder to see and more expensive than the first. Two vendors can both build a contact form. Vendor A's obligation ends when the form submits. Vendor B's obligation is that the form submits, the notification does not land in spam, bot submissions are filtered, and somebody investigates when you discover three months later that inquiries went missing. The extra hours are modest. The difference in liability is an entire grade, and that grade is what you are paying for.

On paper, liability shows up as a warranty clause: how long, what it covers, how faults not caused by the vendor are handled, and who is responsible for restoring data. A quote that commits in writing to fixing code defects free of charge for ninety days after launch is legitimately more expensive than one that says nothing about warranty. You are buying the portion of risk the vendor agrees to keep.

Dimension three: aftercare. Whether anyone is still there next year. The third dimension determines how the next three years feel. Launch day is the beginning: the CMS needs updating, plugins ship security patches, certificates renew, and sales will ask for a campaign page tomorrow morning. A quote with real aftercare states response times, what is in scope, and how out-of-scope work is billed. A quote without it means you discover the gap during your first outage — and hiring someone to inherit an undocumented website rarely costs much less than building it again.

One warning to close this section: only the first dimension is a legitimate place to negotiate. Cut liability or aftercare and the savings come back over three years in the form of nobody being available. The healthy way to reduce a quote is to reduce hours — fewer pages, no animation in phase one, one language at launch — not to ask the vendor to be responsible for less at the same scope.

Pricing traps: pages, assets, and the definition of a revision

Direct answer: three vague zones cause most quote disputes — nobody defined what counts as a page, nobody wrote down who supplies and licenses images and copy, and nobody defined what one revision means. These are rarely malicious. Both sides simply assumed different definitions, and the cost lands on you.

Trap one: pricing by page count without defining a page. The quote says eight pages. You picture home, about, products, case studies, news, contact. The vendor may be counting a product listing as one page with individual product pages excluded because they share a template — an assumption that quietly collapses when you turn out to have sixty products. Or the reverse: every product page is billed individually and your eight pages become sixty-eight.

Four questions settle it. How are listing pages and detail pages counted separately? Does the second instance of an existing template cost anything? Do form pages, thank-you pages, 404 pages and the privacy policy count toward the total? And is every page in the second language counted again? That last one is decisive for export-focused sites, because a bilingual site doubles page count by definition, and nine quotes out of ten never say what "second language billed separately" actually costs.

The safer fix is to change the unit from pages to templates. List the templates you need — home, content page, product listing, product detail, article listing, article detail, contact — and then state how many instances sit under each. Template count drives design and build hours; instance count drives content loading hours. Quote them separately and the argument about whether something counts as a new page never happens.

Trap two: whether images and copy are actually included. The second trap hides inside one sentence: "copy and images supplied by client." Nothing is wrong with the sentence. What is wrong is that it moves an entire production workload onto your side of the table while never appearing as a line on the quote. Break it into four questions: who writes the copy, and how many pages of it? Who shoots or buys the product photography? How many years does the stock license run, and does it cover social media and printed catalogs as well as the website? And who holds the commercial license for the typefaces?

Licensing is where the consequences are most asymmetric. For images pulled off the web, fonts of unknown provenance, or nulled themes and plugins, rights holders pursue the site owner — you — not the contractor who built it. The clause worth adding is simple: require an asset inventory listing every image, font, plugin and theme with its source and license terms. Free assets should name the license explicitly (the differences between the Creative Commons license variants matter, and Google Fonts documents its licensing clearly). Paid assets should name the account that holds the license, the expiry date, and the permitted uses.

Worth noting: WordPress core is GPL licensed (the official license page sets out the terms), but commercial themes and plugins attach their own terms, and updates plus support are usually tied to an annual renewal. Ask for years and renewal prices, not just "is it licensed." A lapsed license rarely breaks a site immediately; it stops the security updates, which is when risk starts accumulating silently.

Trap three: what "one revision" means. The third trap detonates late in the project. "Three rounds of design revisions" sounds unambiguous, but a round has at least three common definitions: one consolidated batch of feedback, one screen changed, or one individual change request. The gap between the first and the third can be tenfold, and both parties sign believing their reading is the obvious one.

Write three things into the contract. First, the counting unit — use rounds, where a round is everything you submit in one consolidated batch. Second, how many rounds each stage gets, typically two or three at design and one or two during build. Third, how additional rounds are priced, hourly or per item, with the rate agreed in advance. Then hold up your own end: collect feedback and send it once. Drip-feeding one change a day will be counted as many rounds no matter what the contract says, and the vendor will be right.

Two smaller traps are worth writing down while you are at it. The first is a contract that treats launch and acceptance as the same event, which hands over your leverage at exactly the moment you need it. The second is recurring costs buried in a footnote — "hosting and domain included for the first year, billed separately thereafter" with no figure attached. The first costs you negotiating power, the second surfaces as a budget hole in year two. Both are avoidable with one email before signature.

The eight line items to interrogate in any quote

Direct answer: the real risk in a quote is never the total. It is the eight fields that almost no vendor volunteers — domain ownership, source code delivery, hosting portability, revision definition, maintenance pricing, asset licensing, SEO and acceptance criteria, and payment milestones. Send these eight questions to three vendors and the quality of the replies is itself the best filter you will get.

Print the table and take it to the meeting. What makes it bite, though, is knowing exactly what happens when each item is left vague.

Leave item one vague and you end up locked inside someone else's asset. The usual sequence: the vendor registers the domain on their own account, and three years later you want to change suppliers, but the contact has left, the company dissolved, or the emails simply stop. You are then choosing between waiting months for the registration to lapse — with the risk of somebody else claiming it — and launching on a new domain, which resets every ranking and inbound link you accumulated. Registering the domain yourself through an accredited registrar costs a few dollars a year and is the cheapest insurance in the entire contract.

Leave item two vague and changing vendors means building twice. "That is our proprietary asset" sounds reasonable until the next agency has to recreate the site from the outside because they cannot see the code. You pay a full build a second time, and if the URL structure of the new site does not map to the old one, rankings take a second hit. Three things belong in the contract: what is delivered (source code, a database export, editable design files), when it is delivered (at acceptance, not "if you ever need it"), and the license granted (the right to modify it yourself and to hand it to anyone else).

Leave item three vague and you have no leverage at renewal. A site tied to a vendor's own servers makes every renewal a one-sided conversation, because the cost and risk of moving sit entirely with you. The worse version is the vendor ceasing operations while you cannot even retrieve a complete backup. The minimum protection is hosting opened under an account in your company's name, with the vendor added as a collaborator. Requesting that before signature takes one sentence; fixing it afterwards can take a day of downtime.

Leave item four vague and the last month of the project becomes an argument. The previous section covered how to define a round. The practical consequence is worth stating separately: mismatched definitions never surface at revision one. They surface at revision five, in the week you most need to launch, and under that deadline pressure most owners pay to make it go away. That payment was avoidable with one sentence at signature.

Leave item five vague and three-year costs double with nobody accountable. Maintenance is typically priced three ways: a monthly retainer with an hours allowance, an annual flat fee, or per-ticket billing. All three are legitimate, but insist on specifics. Does it cover CMS and plugin updates? Daily backups and tested restores? Is response time measured in hours or days? Do content edits — swapping an image, rewriting a paragraph — count? A maintenance fee without a written service level buys reassurance, not service.

Leave item six vague and the infringement notice arrives at your office. Stock libraries and type foundries pursue the site owner rather than the contractor, and settlements typically run far above what the license would have cost. An asset inventory naming every source and expiry date is the cheapest possible prevention, and doubles as one of the most useful handover documents when you eventually change vendors.

Leave item seven vague and retrofitting means rebuilding. Responsive design is not a plugin you add later; it is the layout structure itself. Accessibility is the same — the W3C WCAG standard is about semantic structure, keyboard operability and contrast, not an overlay widget bolted on at the end. Multilingual is the most structural of the three: URL structure, hreflang annotation and per-language titles all have to be decided during the build, and Google documents the required markup for localized versions clearly enough to attach to a specification. Retrofit any one of the three and you may be paying for a second front-end build.

Leave item eight vague and the vendor disappears the day the final invoice clears. Sensible milestones split into three or four stages: deposit at signature, design approval, build complete and entering test, final payment on acceptance. The critical detail is that the final payment attaches to acceptance, not to launch. A site can be live while the contact form fails to deliver mail, the mobile layout breaks, and no handover documentation exists. None of that is acceptance. Write the criteria as specifically as you can: which browsers, which device widths, what page experience targets, which form scenarios get tested, which documents are delivered — all of it as a contract annex. How to write that specification is covered in website RFP specification and acceptance checklist.

Items one and two are the two you never concede. Once the domain and the source code sit outside your control, your negotiating power is permanently zero: a renewal price hike, a vendor going out of business, or a relationship breaking down all force you to start over. The other six are negotiable — but negotiate them before signature, not before launch.

The costs that never appear on the quote

Direct answer: a website is not a one-time purchase, it is a subscription asset. Domain renewal, hosting, SSL, backups, and plugin or theme licenses together run roughly 15 to 25 percent of the initial build cost every year, and that bill starts in year two whether you planned for it or not.

Published component ranges from the same HubSpot cost breakdown give you a sanity check:

A few notes on where the range actually lands. Basic domain-validated certificates are available free and auto-renewing through Let's Encrypt, and that is genuinely sufficient for most small business sites — so if a quote lists SSL as a fixed annual expense, ask why. Backups are worth a second look too: many vendors do backups but never test restores, and an untested backup is not a backup. Commercial plugin licenses usually renew annually; letting one lapse rarely breaks the site immediately, but unmaintained plugins are exactly the risk vector the WordPress security documentation calls out.

The line nobody ever quotes is internal content maintenance. Somebody has to write the new case study, update the specification sheet, and refresh last year's photos. If your budget only covers the build, you have budgeted roughly sixty percent of the three-year cost.

Three-year total cost of ownership: stop comparing year one

Direct answer: compare build cost plus three years of operating cost, not first-year quotes. A 5,000-dollar option can end up more expensive by year three than a 12,000-dollar one, because hitting its ceiling early forces a premature rebuild.

The table below is not a quote. It is arithmetic on the ranges already cited, using 20 percent of build cost as the annual operating estimate — the midpoint of the 15 to 25 percent band — with internal content time excluded.

Two principles for using this table. First, price in the risk of a premature rebuild. If scenario A has to be thrown away in year two because you now need multilingual pages and a product database, your real three-year cost is 8,000 dollars plus an entire new build — worse than choosing B on day one. The inverse also holds: if your business model is still unproven, A has low sunk cost, and that is a feature. The rebuild-versus-refresh judgment call is laid out in website redesign versus rebuild.

Second, count the traffic cost in the same budget. A website nobody visits is a very expensive business card. If the goal is having buyers find you, then search and content investment belongs in the same spreadsheet as the build, not in a conversation you have six months after launch. The Moz beginner guide to SEO covers the fundamentals, and the manufacturer-specific version is in our B2B manufacturer website SEO checklist.

A second comparison: cheap template build versus mid-priced custom build

The table above compares three different orders of magnitude. The decision owners actually agonize over is narrower: the same requirement, quoted as a 6,000-dollar template build or a 15,000-dollar custom one. Putting both on the same timeline, with the same 20 percent operating estimate, makes the trade-off legible.

(The figures are arithmetic on the published ranges already cited in this article, not any vendor's quote. "Year two needs expansion" is a scenario assumption used to compare risk structures, not a prediction.)

Read the last two rows, not the third. If you are confident that within three years you will not add a second language, will not load a product database, and will not integrate anything, option X is the right answer — and the money saved usually earns more in content and advertising than it would in a nicer layout. If you already know an English site launches next year and 300 SKUs are going online, then the 9,600 is a deposit rather than a total: the real number is 9,600 plus an entire second build plus the ranking loss a migration causes, and option Y turns out to be the cheaper option.

So the deciding variable is never price. It is how certain you are about the next twenty-four months. When certainty is low, low sunk cost is a genuine advantage and option X lets you be wrong cheaply. When certainty is high and requirements are known, getting the foundation right the first time is what actually saves money. This is also why writing the requirement down before negotiating matters so much: the moment the requirement is explicit, you can tell which side of this table you are standing on.

Builder, freelancer, agency, or in-house: comparing cost structures

Direct answer: the four delivery models differ less in headline price than in where the risk sits. Builders shift risk to your time, freelancers to key-person availability, agencies to your budget, and in-house to your hiring. Choose the one whose failure mode you can actually absorb.

A website builder subscription at roughly 25 dollars a month looks unbeatable until you count the hours your team spends configuring it, and until you hit a structural limit the platform will not cross. It is the right answer when your requirements are genuinely simple and your team has time.

A freelancer at 25 to 49 dollars an hour gives you direct communication and low overhead. The failure mode is availability: one person cannot be sick, on holiday, and shipping your launch simultaneously. Mitigate it contractually — source code delivered, documentation written, hosting in your own account.

An agency at 100 to 149 dollars an hour buys you process, redundancy, and someone whose job is to answer the phone. You pay a project management line for that. It is worth it when the project has multiple stakeholders, hard deadlines, or integration work.

In-house looks cheapest on paper and rarely is, because a single web generalist salary usually exceeds a mid-size agency build in year one alone. It becomes rational when the website is a continuous product rather than a project — daily publishing, frequent campaigns, live catalog changes.

How to set the budget, and three mistakes to avoid

Direct answer: a common starting benchmark is allocating 0.5 to 2 percent of annual revenue to website build and digital marketing — the upper end if you are launching or entering a new market, the lower end if you are stable and mostly maintaining.

That percentage is a starting point, not an answer. The real questions are three: what commercial job does this website have to do (capture inquiries, build trust, support the sales deck); what is the minimum functionality that does that job; and what result, looking back in three years, would make you feel the money was well spent. Write those three answers on one page before you request quotes, and the quality of the quotes you receive will change completely.

Mistake one: comparing totals instead of scope. Put three quotes side by side and your eye jumps to the last line. But a low total usually means a narrow scope — no content, no SEO, no maintenance, or nobody who picks up the phone. Normalize scope with the eight-item checklist first, then compare prices.

Mistake two: shifting cost onto yourself without counting it. "We will write the copy." "We will take the photos." "We will load the content." Every one of those sentences moves cost off the quote and onto your admin and sales staff. If they are already at capacity, the result is not savings — it is a three-month delay, and delay is a cost.

Mistake three: cutting to the bone in year one and rebuilding in year two. This is the most expensive way to save money. When budget is tight, the better move is narrowing scope rather than lowering quality: build five pages properly instead of fifteen pages badly. Pages can be added later; foundations get paid for twice. To judge whether your current site needs repair or replacement, start with a common technical problems self-check.

One last practical note: the best moment to negotiate is after your requirement is written down, not before. Ask for a discount while the brief is still vague and the only thing a vendor can do is quietly narrow the scope — the two thousand dollars you think you saved comes back three months later as "we assumed that was included." A precisely specified project, by contrast, carries less uncertainty premium, because the vendor no longer has to reserve budget against risks they cannot see. That is the version of saving money that both sides can live with.

What to do next

You should now have enough to take three concrete actions.

First, send the eight-item checklist to every vendor you are talking to and ask for written answers. Vendors willing to answer line by line are already a lower-risk bet. Vendors who dodge the domain and source code questions can be removed from the list.

Second, recalculate every quote as a three-year TCO rather than a first-year total. Build cost plus three years of operating cost at 15 to 25 percent annually, plus an honest estimate of the content hours you will contribute. That number is the only fair basis for comparison.

Third, settle the platform direction before you settle the price. The platform determines your maintenance cost structure, how hard it is to change vendors, and whether your own team can update content. That question matters far more than one vendor being two thousand dollars cheaper.

A website is one piece of a wider digital footprint. If your goal is selling into North America, read building an export website from zero to launch next, along with should an SME update its website and adopt AI. More website and search material is collected on the website and SEO topic hub.

HappyCXO Studio publishes this series with one simple aim: let you understand what you are buying before you spend the money. Once you can read a quote, the outcome improves regardless of who you eventually hire.