Choose WordPress when the site is content you publish, and Drupal when the site is data you model — that one distinction settles most of these arguments before anyone mentions market share.
I build on Drupal and maintain contributed modules for it, so treat the rest of this as informed rather than neutral. What follows is the version I give clients who ask, including the parts where the honest answer is "use WordPress".
The distinction that actually decides it
Ask what your content is.
If it is posts and pages with a shared shape — a blog, a brochure site, a news section, a small shop — WordPress models that natively and you will spend nothing fighting it. If your content is a set of related things with different fields and rules that reference each other — courses that belong to departments that have staff who publish research that cites funders — then you are modelling data, and that is what Drupal's entity system is for.
Everything else, including the market-share argument, is downstream of that.
Where WordPress is genuinely the better answer
- Speed to a working site. The five-minute install is real, and it set an expectation the whole industry now works to.
- Unattended updates out of the box. Core, plugins and themes can update themselves with no intervention. This is not a small thing for a site nobody is paid to watch.
- Theme and plugin abundance at a low price point. A commercial theme marketplace means professional design without a design budget.
- Hiring. Far more people can maintain a WordPress site, and they cost less.
If a project is straightforward publishing on a modest budget with nobody technical on staff, recommending Drupal would be selling the client a maintenance obligation they did not ask for.
Where Drupal is genuinely the better answer
- Content relationships. Entity reference fields, revisions on content, taxonomy terms, media and blocks, and computed fields let you build a real model instead of stuffing structure into post meta.
- Multilingual. Content translation, interface translation and configuration translation are core subsystems, not a plugin you are trusting with the whole site.
- Granular access control. Per-bundle, per-role permissions with an editorial workflow behind them, without buying anything. Per-field access is the one that needs help: core exposes it to code rather than to the permissions screen, so in practice you add a small free contributed module.
- Caching that survives scale. Cache tags and contexts let you cache aggressively and invalidate precisely — see how that pairs with a CDN.
- API-first delivery. JSON:API is in core, so a decoupled front end is a configuration decision rather than a rebuild.
These are architectural advantages, not feature-list advantages. They show up in year three, when the requirements have changed twice and the site has not needed replacing.
The update story, stated precisely
This is where Drupal comparisons usually go wrong in Drupal's favour, so here is what I read on disk in Drupal 11.4.6 rather than what the marketing says.
Core ships package_manager, the API that stages Composer operations in a sandbox before applying them. Its own package_manager.info.yml carries lifecycle: experimental and hidden: true — it does not even appear on the module list. Core's Update Status module tells you a release exists; it does not apply it. There is no automatic_updates directory in core at all. Automatic Updates is a contributed module you install yourself, sitting on top of an experimental core API.
WordPress has had unattended updates since 2013. Drupal has not matched it, and pretending otherwise on a client call is how you lose the client later.
The reason for the delay is real, though. WordPress can overwrite files in place because plugins are largely self-contained. A Drupal site is a Composer project with a genuine dependency tree, so a safe unattended update has to resolve dependencies, stage the result somewhere isolated and roll the whole thing back on failure. That is what package_manager is built to do. It is a harder problem, and shipping it early would have been worse than shipping it late.
Practical consequence: if unattended security updates are a hard requirement, treat it as a build-time decision on Drupal — a maintenance contract, a managed host, or the contributed module — not something the platform quietly handles. If nobody is going to own it, that is an argument for WordPress.
If you are weighing this for a specific project rather than in the abstract, an architecture review costs a fraction of picking wrong and finding out in year two.
The costs each side under-reports
| Cost | WordPress | Drupal |
|---|---|---|
| Getting started | Low | Higher — Composer, config sync, a local environment |
| Complex requirements | Accumulates paid plugins, each a dependency you did not write | Mostly configuration and core APIs |
| Staying secure | Largely automatic | A job someone has to own |
| Major version moves | Usually smooth | Smooth since Drupal 8; Drupal 7 to 8 was a rebuild |
| Finding help | Abundant, wide quality range | Smaller pool, higher average rate |
The plugin row is the one clients feel. Five commercial plugins at renewal is a recurring bill and five upstream projects whose roadmaps you do not control. Drupal trades that for a higher entry cost and a maintenance obligation.
A checklist you can actually answer
- Do you have more than three content types that reference each other? → Drupal.
- Do you need more than two languages with translated interface and configuration? → Drupal.
- Does anything need a multi-step editorial approval? → Drupal.
- Will a front end other than this site consume the content? → Drupal.
- Is anyone contracted to apply updates? If no → WordPress.
- Is the whole budget under a few thousand and the site is a brochure? → WordPress.
Answer honestly. A Drupal build handed to an organisation with nobody to maintain it becomes an unpatched Drupal build, which is worse than a maintained WordPress one.
Common questions
Is Drupal dying because WordPress has more market share?
Share is a measure of the low end of the market, where WordPress is deliberately strong. Drupal's position is in government, higher education and complex publishing, and that has not moved. Different markets, not a league table.
Can I migrate from WordPress to Drupal later?
Content, yes — the migrate system handles it, though core ships no WordPress source, so you add a contributed or custom source plugin. Plugin behaviour, no. Anything a plugin was doing has to be rebuilt as configuration or a module, and that is usually the larger half of the job.
Is Drupal more secure than WordPress?
Drupal core has a strong security process and Twig auto-escaping removes a whole class of template vulnerabilities. But most real compromises on either platform are unpatched contributed code. A patched WordPress beats an unpatched Drupal every time.
What about Drupal CMS?
It is a distribution aimed squarely at the ease-of-use gap. It changes the starting experience; it does not change the entity model underneath, which is the reason to pick Drupal in the first place.
Which is faster?
Neither, inherently. Both are fast when cached properly and slow when they are not. Hosting, caching strategy and image handling decide it, not the CMS.
Next steps
If your answer came out "Drupal, but the migration worries me", the two pages worth reading next are the Backdrop CMS option for Drupal 7 sites and what the Drupal learning curve really costs.
If you would rather have the answer for your specific project than a general one, a Drupal architect can give you a platform recommendation with the reasoning written down, or describe what you are building and I will tell you plainly if Drupal is the wrong tool for it.
