Introduction: the question that opens every enquiry
“What does a WordPress website cost?” is the first question of almost every enquiry, and nobody can honestly answer it with a single number without staying silent about everything behind it. That is not evasion. It is the precise description of an estimation problem: two projects with an identical page count can differ severalfold in the amount of work involved, because the work does not live in the pages. It lives in the templates, the integrations, the failure paths, the language versions and the acceptance criteria.
This article walks the path in reverse. Instead of guessing a number, we explain every cost driver individually, honestly and without marketing polish: scope, custom development versus theme configuration, integrations, content production, performance and security, accessibility, project management, and the entire ongoing layer after launch. Then comes a framework for writing a requirements document that actually makes quotes comparable. And at the end we name the only source from which concrete numbers may be quoted: the current price list. Anyone who still asks what a WordPress website “costs” afterwards will be asking with better words.
Why the WordPress software is free and the project still is not
The WordPress.org software is open source and free to use. That is a genuine structural property, not a sales line: there is no licence fee to a vendor, no usage cap tied to traffic, and no edition that hides “commercial features” behind a paywall. Much of the ecosystem of tools — from the block editor to thousands of plugins — is openly available too.
Which is exactly why the software is the wrong reference point for cost estimation. What a client buys is never WordPress. What is bought is work: information architecture, design decisions, implementation, migration, integration, testing, operations and accountability. The software is the freely available material this work is made of — comparable to bricks being relatively cheap while a house is not. The question “What does a WordPress website cost?” is therefore really the question “How much work is in my specific project?” — and that is answered only by scope, never by the product name.
Cost driver: scope, templates and the content model
The most visible cost driver is scope, and it is almost always counted wrongly. It is not the number of pages that determines the work, but the number of distinct templates. A website with forty subpages that all fall back to three layouts is a smaller project than a website with twelve pages that require twelve individual layouts. Every additional template means design work, implementation work, editorial tooling for exactly that layout, and testing across every language version.
Alongside the page count comes the content model. Which content types exist — posts, references, job listings, events, locations, products? How do they relate, which archive and detail views do they need, which taxonomies? A cleanly planned content model makes later extensions cheap, because new content falls into existing templates. A chaotic model turns every extension into bespoke work. And it includes migration: anyone carrying over existing content needs a URL map, redirects and a decision on which content is migrated, rewritten or retired. Migrated content is work, even when it “already exists”.
Cost driver: theme configuration or custom development
The second major fork is technical: will a ready-made theme be configured, or will a custom frontend be developed? Both paths are legitimate, but they cost differently and carry different risks.
Theme configuration is the faster route to launch. A well-maintained premium theme ships with layouts, blocks and settings, and the work concentrates on adaptation, content and polish. The price is not the licence; it is the fit: sooner or later every off-the-shelf theme hits the point where the content model demands something the theme does not provide. Then the compromise phase begins — or the purchase of a page builder that promises flexibility and delivers loading time, maintenance complexity and vendor lock-in with it.
Custom development costs more upfront and pays back over operating time. A block theme tailored to the content model, with custom blocks and patterns, fits the content exactly, survives updates because it carries no third-party design dependencies, and makes editors more productive because the building blocks mirror their reality instead of generic layout galleries. The extra work is real; the saving arrives later, in every additional year of operation. The honest middle ground: for a compact business website with a clear layout, configured work is often the economically right choice. For anything that needs to grow, integrate or live long, custom implementation is almost always the cheaper decision over the total period.
Cost driver: integrations — ERP, CRM and payments
Integrations are the cost driver most frequently underestimated in sales conversations. Connecting a payment provider sounds like “a form that forwards data” — it is not. The happy path of a checkout is the small part of the work. The large part is the failure paths: refunds, abandoned payments, double-delivering webhooks, timeouts between shop and provider, currency and tax edge cases. Every one of these path variants wants to be understood, implemented and tested before a real customer finds it in a real cart.
The same applies to ERP and inventory connections. Once stock levels, prices, orders or customer data flow between WooCommerce and an ERP system, a small project forms inside the project: reconciling data models, defining synchronisation direction, setting conflict rules, and writing test cases for the night the ERP does not answer. A CRM connection has different risks but the same structure. The practical consequence for budgeting: list every interface by name — system, direction, data types, frequency. A quote that contains “connection to your CRM” as a lump sum is not a quote; it is an assumption with a price attached.
Cost driver: content — copy, imagery and translations
Content production is the cost factor that often never appears in the project budget at all, because “the client does it”. That is a legitimate approach, but it should then be stated in the quote as such — as a client-side deliverable with a deadline and a definition. Because content is not a side matter: a template without text is a shell. Search visibility comes from content quality, and the conversion of a landing page happens in the copy, not the layout.
Concrete line items: copywriting or copy revision per page and language, photography or image licensing, technical preparation of media, and for multilingual projects, translation with local adaptation rather than literal transfer. Add the migration work on the content itself: moving existing copy into the new structures, carrying over metadata, compressing images, checking internal links. Whoever does not plan this work pays for it later as a launch with empty pages or as an unforeseen change request. A good quote actively asks about the state of your content and prices the gap.
Cost driver: performance and security
Performance and security are the items a frugal quote cuts first and an honest quote discloses first. Both are invisible while nothing goes wrong, and both are more expensive in an incident than during the build.
On the performance side, a solid project includes: an agreed performance budget as an acceptance criterion, a caching concept, an image pipeline that delivers modern formats at correct sizes, and an edge setup that carries real traffic spikes. The alternative is the familiar sequence: launch with a pretty Lighthouse score on an empty staging site, then the sobering reality under real traffic and real media, then rework that costs more than correct implementation would have cost at the start.
On the security side, the question is not whether measures happen, but which ones and at what depth. A mature baseline includes hardened configuration, an access and role policy with two-factor authentication for administrator accounts, a web application firewall, monitoring with an alert channel a human actually reads, and backups that do not merely exist but are demonstrably restorable through documented restore exercises. Everything else is security theatre. This work is paid for in the project or in the maintenance contract — or in the incident, and then with a multiplier.
Cost driver: accessibility as real project scope
Since June 2025, the European Accessibility Act applies across the EU, implemented in Germany as the Barrierefreiheitsstärkungsgesetz (BFSG), and accessibility for many B2C offerings is no longer a matter of taste but a legal requirement. For the cost frame this means: accessibility work is a distinct project scope with its own evidence, not an implicit side effect of “good design”.
What goes into it concretely: semantic structure and keyboard operability across all interactive elements, contrast ratios and focus states, labelled forms and error messages, operability of modals and menus with assistive technologies, including document types such as PDFs. The effort scales with the number of custom components — one more argument for building few, reusable blocks properly instead of many special cases. Important for planning: retrofitting is more expensive than integrating. Whoever embeds accessibility in design and frontend from the start pays once; whoever audits after launch pays twice — once for the audit and once for the fixes.
Cost driver: project management, alignment and training
Project management is real work and should be visible in the quote, not hidden as an administrative flat fee. It includes the kickoff and requirements phases, the scope document, deadline coordination between your deliverables and the development work, preparation and follow-up of demos, change-order management and acceptance organisation.
A seemingly soft factor with hard impact is the number of decision-makers on your side. Every additional stakeholder layer lengthens feedback loops, and feedback loops are the most expensive production factor in a web project because they unlock already-built work. One named person who decides on substance and carries acceptance measurably lowers project costs — without the scope changing at all. Project management finally includes training the editorial team and the handover documentation. Whoever does not plan for it buys a website that remains dependent on the service provider after go-live, because nobody in-house knows how it works.
The ongoing layer: hosting, maintenance, updates and licences
Up to this point the article has been about the project. Afterwards begins the second cost layer, more durable than the first: operations. It starts with the infrastructure items that accrue independently of any provider — domain, hosting, transactional email, CDN — and the licences for premium plugins and themes, usually billed annually. For operations in Europe, add EU hosting with a proper data processing agreement, configured log retention, and a data layer that will not become a surprise in an access request or audit.
On top sits maintenance, the item many cut first and which pays for itself most reliably. A maintenance scope with substance includes update management for core, plugins and PHP with staging tests and a rollback path, tested off-site backups, monitoring, defined response windows for incidents and a monthly report. Updates without testing are not update management — they are dice-rolling with production downtime; backups without a restore exercise are a belief system. How maintenance offers differ in substance, and what to measure them against, we describe in detail under WordPress website maintenance.
Orientation: the numbers we quote
After so many qualitative factors, the obvious question: where are the actual figures? The only source we quote concrete values from is our official overview. According to the current price list, a company or business website sits in an indicative range of €890 to €2,900, a WooCommerce shop between €1,800 and €6,900, and ongoing maintenance starts at €69 per month. These values come from the price list and are published there as market ranges for budget planning — not package prices, and no substitute for a quote.
Why we write no further numbers into article text follows from the logic of this article: any number quoted without scope is false precision. The spread within a project type is exactly the distance between theme configuration and custom development, between a payment connection and an ERP synchronisation, between one language and five. Which is why the path to a binding figure is not “read the price table” but “document the scope, then request a quote”.
Where money gets wasted
An honest cost discussion must also name the waste. Four patterns repeat in rescue projects with striking regularity.
First: over-customisation. Custom development is a tool, not a status symbol. When a standard contact form is built as bespoke work, a simple archive as a custom component and a simple intro paragraph as a dynamic feature, the project pays for flexibility nobody uses. The counter-question before every custom build: which future scenario genuinely needs this freedom?
Second: plugin sprawl. Every additional plugin brings licence costs, update risk, loading time and another interface to look after. Ten small plugins each solving one detail are more expensive than one clean concept that handles the same tasks structurally. A plugin inventory with regular pruning is one of the cheapest tools in all of operations.
Third: redesign without measurement. A relaunch that goes live without the existing site having been measured cannot answer afterwards whether it improved anything. Without a baseline for traffic, search terms, conversion paths and the strongest pages, design decisions are matters of taste — and in the worst case, the old site’s working pages are destroyed without anyone noticing.
Fourth: missing handover documentation. When documentation of the setup, the credentials, the licences and the decisions is not delivered, the client remains structurally dependent. Every later provider change becomes more expensive, every small change must be bought from the original provider. Undocumented projects are not finished projects.
Where spending pays back
The flip side of the waste list is short and clear. Maintenance pays back because it prevents incidents that later cost a multiple — and because a well-kept site does not become a security story that hits reputation and revenue simultaneously. Performance pays back because loading time is a direct factor for conversion and visibility, and because every saved second applies on every page. Measurement pays back because decisions without data get repeated and decisions with data get corrected — the difference between guessing and steering.
Two further items pay back quietly but reliably. First, documentation, because it caps dependence on the provider and cheapens every future switch. Second, accessibility work from the beginning, because it simultaneously improves code quality, structure and usability for everyone and reduces legal risk. The common denominator: investments that reduce risk or improve decisions are the only line items that are never wrong in hindsight. Everything that only raises appearance without changing what the website does is the first candidate for the cut list.
Budgeting: the requirements document that makes quotes comparable
The most effective step towards cost control happens before any quote exists: a requirements document that you send to every provider unchanged. It needs no jargon and no tools — only honesty and completeness. Six blocks have proven themselves.
First, the page and template inventory: which page types exist, how many instances of each, which layouts genuinely differ? Second, the content state: what exists, what will be migrated, what rewritten, in which languages, and who delivers? Third, the integration list: every system with name, direction and data types — payments, ERP, CRM, newsletter, shipping, applicant management. Fourth, the must-have criteria: a performance budget as a measurable acceptance criterion, accessibility requirements — for instance where the European Accessibility Act applies — and the legal frame such as GDPR with EU hosting. Fifth, the organisation: who decides, who accepts, what start date, and why. Sixth, the budget frame as an order of magnitude, not a number with decimal places.
With this document, three things happen at once. The quotes become comparable, because they price the same scope. The figures become more reliable, because the provider has less uncertainty to price in. And your own position becomes clearer, because the most common cause of budget explosions is not the provider but a scope that was never written down. If you need support with the comparison, our guide on choosing a WordPress agency lists eight verifiable criteria and the questions behind each of them.
Why the cheapest quote is rarely the cheapest project
The total cost of a WordPress project accrues over years, not over the quote number. That total-cost-of-ownership view is the reason the lowest offer statistically does not win as the most economical project. A low quote is almost never a sign of more efficient work; it is usually a sign of a smaller scope that nobody tendered.
The typical deferrals can be named. Excluded test depth becomes manual bug-hunting after launch. Missing staging parity becomes production outages during updates. Overlooked failure paths in integrations become incidents discovered by the customer. Unplanned content work becomes schedule debt. And a missing scope document becomes a permanent negotiation space where every follow-up question turns into a change order. The bill never leaves the budget — it just leaves the quote.
Add the structure of warranty and accountability. A quote that cleanly defines acceptance criteria, handover scope, response obligations and ownership arrangements is more expensive on paper and cheaper in reality, because it gives the client enforceable claims instead of a number without substance. The right question to ask of any cheap quote is therefore not “how can you be so cheap?” but “what exactly is not included?” — and the answer should arrive in writing.
Contract models: fixed price, hourly rate or retainer
The choice of contract model is a cost decision that is often underestimated because it looks like a formality. It decides who carries which risk.
The fixed price works when the scope is genuinely frozen: a fully specified undertaking with no integrations at its core, a written scope, clear exclusions and named acceptance criteria. In that configuration, a fixed price is fair to both sides. In any other configuration it becomes a trap: as soon as the scope breathes, every change becomes a change order with negotiating pressure, and after a few of those cycles both parties work against each other instead of with each other.
Time-and-materials with structure is the more honest form for projects whose scope only clarifies during the work: openly billed effort, but with a weekly hour cap, regular demos and an explicit go or no-go at every decision point. The gates prevent what gave open billing its bad reputation: running invoices without visible progress. For operations after launch, the retainer is the normal case — a monthly frame with a defined service scope and an allowance for small improvements. Which model fits which project, and what to watch for when switching providers, we cover separately in the article on maintenance contracts and provider switches and in the trade-off between agency and freelancer.
Buying across borders: what DACH procurement culture teaches
The DACH market — Germany, Austria, Switzerland — has its own procurement culture, and for cost planning it is a frame, not a detail. It includes the written-scope culture: in DACH it is expected that services, exclusions, acceptance and warranty are documented, and invoices are issued against agreed milestones rather than against trust. For clients this is an advantage, because the documentation creates the comparability that looser markets lack. Contract language and currency are usually EUR; for cross-border B2B engagements within the EU, the reverse-charge procedure handles VAT, which makes working with providers outside your own border administratively straightforward — provided both sides operate valid VAT identification numbers.
Second, data protection and accessibility are genuine budget items. A data processing agreement with the host and the maintenance provider, EU data residency, a cookie consent mechanism that actually respects consent, documented subcontractors — all of that is work someone pays for, and it either appears cleanly in the quote or dirtily in the rework. The same applies to the European Accessibility Act: whoever falls within its scope buys compliance not as an optional extra but as mandatory scope with an audit. These items are not a discrimination against the provider with the higher price; they are the difference between a website that passes an audit and one that does not.
Conclusion: from price to scope
The question “What does a WordPress website cost in 2026?” is too important to answer with a number that does not belong to the person asking. The honest answer has three steps. First: understand the cost drivers — scope and templates, configuration versus custom development, integrations, content, performance and security, accessibility, project management, and the ongoing layer of hosting, maintenance and licences. Second: write down your scope, using the requirements document from this article as a template, and send it to several providers unchanged. Third: compare scope, exclusions and acceptance criteria — the bottom line is the last value you sort by, not the first.
If you are looking for concrete orientation figures, you will find them in the official overview: the price list names the current market ranges for business websites, WooCommerce shops and maintenance and explains how a binding quote follows — from a written, documented scope, not against a price table. Once your requirements document stands, we look forward to your enquiry through the contact form.
