WordPress is still the largest CMS, but its lead is narrowing. W3Techs puts it on 39.5% of all websites and 58.3% of sites with a known CMS (29 October 2026), while its own trend table shows 43.3% in October 2025. So the first hiring question for a WordPress web design agency is not which agency to pick. It is whether the project should use WordPress at all. Start with that platform decision (before anyone drafts a pitch), then judge agencies with a ten-point scorecard, watch for the red flags that justify walking away, run a fair buying process, and know what to ask a headless studio if the answer is no.
What a WordPress web design agency actually delivers
The label covers more than design. A proposal usually bundles four things, and it's worth pulling them apart because each can be bought separately.
- The build. A ready-made theme adapted to your brand, or a custom theme written for you. The WordPress handbook is blunt that the theme has a huge impact on performance: a fast lightweight theme beats a heavy, graphic-laden one.
- The editing layer. A page builder, or the native block editor. W3Techs reports Elementor on 31.5% of WordPress sites, WPBakery on 7.3% and Beaver Builder on 1.0%, so a builder is the common case, not the odd one.
- Hosting. Sometimes the agency resells it, sometimes you buy it directly. Both work. What matters is who holds the login.
- Care after launch. Updates, backups, security checks, small changes. Sometimes a monthly plan, sometimes nothing at all.
A freelance WordPress web designer can deliver all four jobs too. The agency difference is usually cover (meaning someone else picks up the work when the lead developer is away) rather than superior skill. A good freelancer beats a mediocre agency every time. But you still need to know which parts you are buying, because the parts nobody names are inevitably the ones that cause arguments later.
W3Techs describes WordPress as an open source content management system based on PHP. And open source genuinely matters here. Nothing an agency builds should trap you at the platform level (intentionally or otherwise). If it does, that was their decision, not something WordPress requires.
Before you brief anyone: does this project need WordPress?
Most agency pages skip this question, because the answer touches their revenue. I'd rather you asked it.
The share figures give you a useful prompt. W3Techs' trend table has WordPress falling from 43.3% (1 October 2025) to 39.6% (19 October 2026), while sites with no detected CMS rose from 28.6% to 32.1%. I would not read a cause into that. Third-party write-ups quote 40.2%, 41.2% or 41.9% because they use different dates and denominators (a routine sleight of hand in tech commentary), so always ask what a number means before you treat it as evidence. But what the figures do show is that plenty of sites run without a CMS.
When WordPress clearly fits
- A large editorial team used to wp-admin. Retraining a dozen writers has a real cost, and roles, drafts and workflows are things WordPress already does.
- A WooCommerce store. W3Techs reports WooCommerce on 19.7% of WordPress sites, which means plenty of agencies and plugin vendors know it well.
- Plugin-dependent features. The plugin directory lists over 77,000 free plugins. If memberships, bookings or a course platform exist as a mature plugin, building them from scratch elsewhere is rarely sensible.
When a static or headless build fits better
- A brochure site that changes a few times a year.
- Speed-critical landing pages. WordPress can be fast (the handbook says caching plugins can improve performance several hundred times over for fairly static pages), but a static build starts from pre-rendered files with nothing to configure.
- Sites with one or two editors who are happy in a lighter editing tool.
A five-question decision list
- Do more than a handful of people edit content regularly, and do they already know wp-admin? If yes, lean WordPress.
- Are you selling online with a catalogue, stock and shipping rules? If yes, price WooCommerce against a hosted shop platform (Shopify sits at 5.3% of all sites in the W3Techs table) and compare the two on the same terms.
- Does a feature you need exist as a mature plugin that you would otherwise pay to build? If yes, lean WordPress.
- Is the site mostly fixed pages, edited by one or two people a few times a year? Then a static or headless quote is worth requesting.
- Is the speed of a few landing pages the whole point? Same answer: ask for a static quote alongside the WordPress one.
If you answered yes to any of the first three, stay with WordPress. But if only four or five apply (and the rest leave you cold), ask both kinds of studio for a proposal and compare like for like.
When staying on WordPress is right
If you already run WordPress and the site is only slow, dated or hard to edit, a platform move is rarely the cheapest repair. The handbook lists the usual causes of slowness (the hosting environment, WordPress configuration, software versions, and the number and size of images). And almost all of those can be fixed inside WordPress. A new theme, fewer plugins, better images and sensible caching often beat a full replatform.
If you are seriously weighing an exit, the guide to leaving WordPress sets out what that involves. And both the WordPress alternatives overview and the WordPress stack advisor are well worth reading (before pen touches paper on a new brief).
The ten-point scorecard
Put these ten questions to every agency, preferably in writing. The answers matter, but their precision matters more. And vague answers before signature (however charming the pitch) invariably stay vague afterwards.
| # | Question to ask | What a good answer sounds like | Red flag |
|---|---|---|---|
| 1 | Who owns the domain and hosting account? | In your name, with the agency added as a user. They name the hosting tier and the access you get. | Accounts in the agency's name, with no transfer terms. |
| 2 | Who holds the admin accounts and the code? | You get an administrator login on day one. Code sits in a repository you can reach. Two-factor is on for every admin. | The agency keeps the only admin login and promises to add you later. |
| 3 | Page builder or native blocks, and why? | A reasoned choice tied to who edits the site and what it does to performance. Licences in your name. | 'We always use X', with no reason. Licence held by the agency. |
| 4 | How many plugins will the site run, and what does each one do? | A named list with a purpose for each. Fewer than you expected. | One plugin per small feature, or nobody can list them. |
| 5 | What performance targets will you commit to? | A written budget (page weight, Core Web Vitals thresholds) checked on real pages before launch, plus a caching plan that suits the hosting. | 'We'll optimise it', with no figures. |
| 6 | How do you handle accessibility? | Names a WCAG conformance level, tests with keyboard and screen reader, builds colour contrast into the design stage. | An overlay widget offered as the whole answer. |
| 7 | If you're replacing a site, how will you protect SEO? | Crawl of current URLs, a redirect map, a metadata check, Search Console monitoring after launch. | Redirects never mentioned. |
| 8 | What do handover and training include? | A walkthrough your editors can rewatch, a written editing guide, a live session, a staging site. | 'It's intuitive, you'll figure it out.' |
| 9 | What are the care-plan terms? | Written scope: update cadence, backups with restore tests, response times, what counts as extra work, notice period. | Vague 'maintenance', a long lock-in, no mention of restores. |
| 10 | What are the exit terms? | You can leave with files, database export, theme, licence keys and documentation, at no punitive fee. | Proprietary theme, exit fee, or 'we'll hand over the site' without the code. |
A few notes on the answers
Hosting. No hosting type is inherently wrong. The handbook describes shared hosting as the most common option, with very little control over server settings but usually SFTP and a control panel. Managed hosting is more locked down to a set of software stacks, and users typically do not need file system access. But VPS and dedicated servers give you the whole file system and SSH. Each can be fine (depending on who manages it). You need to know which one you are on, what access you hold, and whether you can export everything.
Plugins. The handbook says the number of plugins and their performance has a huge impact, and that deleting unnecessary ones is a major way to improve speed. It also says too many autoloaded options can slow a site, and suggests generally keeping them under 800kb. A good agency will know what that means in practice (and will have a view on it). So ask whether they check it.
Builders. Elementor, Bricks, Beaver Builder and the native editor can all produce a good site, and the right choice depends on your editors. The page builder comparison walks through the trade-offs. So watch for the agency that can give you a reasoned argument (grounded in your team's workflow), not just repeat a habit.
Red flags in proposals
The scorecard catches problems in conversation. These ones show up in the document itself.
- A proprietary theme you can't take with you. A custom theme is fine. A custom theme that only runs on the agency's framework, licence or hosting is a dependency you'll pay for forever. Ask what happens to the design if you leave.
- Plugin stacks for simple features. A sticky header, an accordion or a basic form rarely needs a separate plugin each. The handbook's advice on contact forms is to use a form plugin with an external mailing service rather than running a mail server on the WordPress host. That's one plugin with a sensible setup, not five.
- No performance budget. If the proposal talks about 'blazing fast' and gives you no thresholds, you can't hold anyone to anything.
- Hosting you can't access. Not having file system access can be perfectly normal on managed hosting. Not having an account, an invoice or a way to move the site is not.
- Beta software on a live site. The Gutenberg plugin is listed in the directory's beta section, described as a way to test features before their official release. Great on staging. Ask why it's on production.
- Credits you didn't agree to. The directory's plugin guidelines (last updated 15 March 2024) say plugins may not embed external links or credits on the public site without asking the user's permission. An agency footer link deserves the same courtesy.
- A price with no scope. If the quote doesn't say what's excluded, the excluded things will arrive as change requests.
Check the agency's own working habits too. They should use two-factor on admin accounts. The Two Factor plugin supports time-based one-time passwords, email codes and backup codes, so there is no good excuse (none at all). And they should also know what the WordPress Performance Team's Performance Lab plugin does, not because you must install it, but because someone who builds WordPress sites for a living should have an opinion on it.
What a fair process looks like
The stages matter more than the names. A competent agency will map the work to something like this (whatever terminology they prefer), and will tell you what they need from you at each stage.
- Discovery. Goals, audience, the content you already have, the integrations you rely on. This is where the 'does it need WordPress?' question gets answered on paper. If the agency never asks it, that tells you something.
- Design. Layouts for the templates, not just the homepage. You should see how editing will work, including the mobile view and the awkward pages.
- Build. On a staging site you can visit. Code in a repository. Plugins chosen against the list you agreed.
- Content. Whose job is it to write and load it? This stage slips more than any other, and it delays launch more than the code does. Settle the owner early.
- Launch. A checklist covering redirects, forms, analytics, backups, admin accounts and the performance budget. Launch day should be dull.
- The first 90 days. Monitoring search performance, fixing broken redirects, a first update cycle, a check against the performance budget, and a refresher for your editors. The care plan, if you have one, should start here and not before.
None of that needs an arbitrary number of weeks. But it does need a dated plan, with the dependencies on your side written down as plainly as the dependencies on theirs (where delays almost always start).
If the answer was not WordPress: what to ask a headless or Jamstack studio
The same discipline applies. Just different questions.
- How do I see changes before they go live? Look for preview deploys: a private URL for each change, so you and your team can check work before it's published.
- Who edits content, and in what? 'Developers, via pull requests' is a legitimate answer for a ten-page site and a terrible one for a marketing team that publishes weekly. If there's a separate editing tool, ask to log into a demo of it.
- How are forms handled? A static site has no server to process submissions. The principle in the WordPress handbook (use an external mail service rather than running your own mail server) carries over: there will be a form service, and you'll want to know who pays for it and who holds the account.
- What does a change cost? Adding a page, a new layout or a landing page variant. If every change needs a developer, price that in over three years, not just at launch.
- What do I own on exit? The same question as row ten above. Repository, build pipeline, hosting account, content in a portable format.
- Why not WordPress? A good studio will answer that fairly, and will say when WordPress would have been the better pick. A studio that only criticises WordPress is selling, not advising.
There is also a middle path where editors keep wp-admin and the front end is built separately. But that adds moving parts (and extra failure modes), so give it the same scrutiny. If you want to see where each platform sits, the alternatives overview is a sound place to start.
FAQ
Should I hire an agency or a freelance WordPress web designer?
Choose based on cover and scope. A freelancer is often cheaper, more direct and just as capable, but you carry the risk of one person being unavailable. An agency adds process and backup (along with a fair bit of overhead). So run the same ten-point scorecard on both. The answers on ownership, handover and exit matter far more than team size.
Is WordPress still a safe bet if its market share is falling?
The fall is real but modest, and WordPress is still the largest CMS. W3Techs has it on 39.5% of all websites and 58.3% of sites with a known CMS (29 October 2026). Those are two different denominators, and people often quote them as if they were interchangeable. But market share is a weak reason to choose or avoid a platform (vanity metrics rarely build good sites). Fit for your editors and features is a better one.
Who should own premium plugin and builder licences?
You should own the plugin licences, or at least the licence should be transferable to you. A paid plugin tied to the agency's account can stop receiving updates the day you part ways (a nasty surprise six months later). So ask for licence keys, renewal dates and the account holder's name, then check the vendor's own terms for what happens at renewal.
How do I know the WordPress version and update policy are sound?
Ask which version the site will launch on and who applies updates afterwards. W3Techs reports version 7 on 67.5% of WordPress sites (29 October 2026), with 4.7% still on version 5 and 2.0% on version 4. A separate W3Techs history page shows 65.7% on version 7 at 14 October, so the figure moves. But an agency with a proper update routine will tell you how often it runs (and how it checks changes before they go live), rather than leaving patching to chance.
The most useful fact here is that the first decision is the platform, and the second is who holds the logins. And if an agency cannot put in writing who owns the hosting, the admin accounts and the theme (plainly, on day one), nothing else on the scorecard matters.