How Much Does a Website Cost in 2026? A Breakdown

No single number answers what a website should cost, and vendors who quote one before asking questions are guessing. Two projects with the same page count can differ several times over because of what those pages do, who writes the words, what systems they connect to, and who keeps the thing running afterward. The useful skill is not finding an average; it is learning to read a quote and see which costs are inside it and which are waiting outside.

Page count is the crudest measure, so look at page types instead. Ten pages built from two templates cost far less than ten pages that each need a custom layout, calculator, or interactive module. Ask every vendor to list the templates, components, and one-off pages separately. A quote that says fifty pages without naming the templates hides the work that actually drives design and development hours.

Design scope moves the number more than most buyers expect. Using an existing brand and a proven layout library is quick; a new visual identity with a design system, custom illustrations, motion, and multiple review rounds is a body of work in itself. Clarify how many concepts, how many revision rounds, and what happens when feedback exceeds them. Unbounded revision language is how fixed quotes become uncomfortable conversations.

The content management layer is a hidden cost when it is missing from the scope. A simple blog is cheap to configure; structured catalogs, team directories, case studies, locations, resources, and permissioned editorial roles all need content modeling, admin screens, and testing. If the quote does not mention custom post types, field structures, or editor training, the cost is either excluded or unaccounted for — both bad outcomes for the buyer.

Integrations are priced per connection, and each is a small project. A CRM form, payment provider, booking system, ERP feed, membership gate, or marketing automation flow needs field mapping, authentication, error handling, and tests. Ten integrations can rival the cost of the site itself. Ask for a list of systems in scope with what data moves in each direction, and be suspicious of a quote that treats integrations as a rounding error.

Copy and assets are the line item clients most often plan to absorb themselves, until the build stalls behind missing text. Someone has to write, edit, and approve every page; produce or license images; migrate existing articles; and prepare metadata. Professional copywriting is priced per page, migrations per record, and photo shoots by the day. If the budget does not contain any of that, either agree who does it internally or accept that launch will slip.

SEO and measurement should be in the original scope, not a phase two. That means a redirect map for existing URLs, crawlable structure, page titles and descriptions, structured data where relevant, analytics events that answer business questions, and consent handling. A site that launches without them pays twice: once to build, once to retrofit. When a proposal says search optimization is included, ask for the specific deliverables behind the phrase.

Then there is the cost after launch. Hosting, domain renewal, CMS licenses, premium plugins, form and email services, monitoring, backups, security work, and someone's time for updates and small changes. A website is closer to a subscription than a sculpture. Multiply the monthly figures by thirty-six and add expected improvement work; that total belongs next to the build price when comparing options. The cheapest build with the most expensive upkeep is not the cheapest website.

Pricing structures vary and each suits a different situation. Fixed-scope contracts are predictable but only as good as the scope document; hourly work is fair when the work is genuinely unknown; retainers fit ongoing improvement; and value-based pricing can be reasonable when the outcome is measurable. Most sound proposals start with a paid discovery that produces a specification, then a fixed price against that specification. That sequence protects both sides from inventing requirements mid-build.

When reading a quote, scan for six things: a deliverable list precise enough to check, assumptions and exclusions written plainly, revision limits, ownership of code and accounts, a payment schedule tied to milestones, and what triggers a change order. Ask what the client must provide and by when, because delay risk is real money. A quote missing any of those is not cheaper; it is incomplete.

Finally, compare like with like. Give every shortlisted vendor the same brief and ask them to mark what they would leave out at your budget rather than quietly shrinking quality. A proposal that names what it will not do is usually more trustworthy than one that promises everything. The lowest total that meets the real requirements over three years is the best price — not the lowest number on page one.

Budget a contingency line as well. Even well-specified projects discover something during build: an integration behaves differently than documented, a legacy page type is more complex to migrate than it looked, or a needed feature was simply missed in discovery. A reserve of roughly ten to twenty percent, stated openly in the quote rather than hidden in padding, keeps those findings from turning into scope fights. The same logic applies to the timeline: content and approvals usually decide the launch date more than development does, so treat client-side review capacity as a project resource that costs money when it is scarce.