Government portals, universities, hospitals, publishers, nonprofits. An honest map of the site types Drupal is built for, plus the ones where we would tell you to use WordPress instead.
Drupal's reputation problem is that people meet it at the wrong size. Someone needs a five page brochure site, an agency builds it in Drupal, and the client spends three years wondering why every text change needs a developer. That project should have been WordPress, and the CMS gets blamed for a decision nobody made carefully.
Drupal earns its complexity in one specific situation: you have structured content that repeats, several groups of people editing it, and rules about who may publish what. Course catalogs, service directories, multi-department government sites, research libraries, membership records. The moment your content has real fields and real relationships instead of a pile of pages, Drupal's content modelling stops being overhead and starts saving you money.
Below is our honest map of the site types where we recommend Drupal, the ones where we would send you to WordPress instead, and what changed in 2025 when Drupal CMS shipped with recipes that install a working site in minutes rather than weeks.
Where Drupal earns its keep. WCAG AA+ accessibility, audit trails and granular role permissions are in core, not bolted on with plugins. Public-sector sites run on it for that reason.
University portals live on structured content: course catalogs, faculty directories, department sites under one install with per-department editing rights. Drupal handles that hierarchy without custom hacks.
Editorial newsrooms with dozens of authors, real moderation workflows and deep taxonomies. Drupal's revision control beats WordPress once you pass a handful of writers.
Enterprise marketing sites with 5+ languages and translation governance. Multilingual is core in Drupal, so a 12-language site isn't 12 plugin licenses.
The threshold we use
Roughly: more than about fifteen people touching content, or more than three distinct content types with fields and relationships between them, or a permission rule that cannot be expressed as "editor and admin". Hit any one of those and Drupal is a serious candidate. Hit none of them and you are buying a permission system you will never use.
Is Drupal dying?
It is a fair question and the honest answer is that Drupal stopped chasing the small site market, which is most of the market, so it looks smaller than it is. Where it kept ground is government, higher education, healthcare and large publishers, and that ground is not eroding. Drupal 7 reaching end of life in January 2025 pushed a wave of sites off the platform entirely, which made the decline look steeper than the underlying trend. If your risk question is "will this be maintained in ten years", the security team and the institutional user base are the reassuring part.
What Drupal CMS changed
Drupal's old problem was the first two weeks. A blank Drupal install used to be a construction kit, and getting to something a client could look at meant assembling twenty modules by hand. Drupal CMS ships preconfigured recipes for common site types, so the starting point is a working site with editorial workflow and SEO already wired. It does not make Drupal simpler to extend, but it removes the argument that Drupal is slow to start.
Where we would pick something else
Content-led marketing sites where speed of publishing beats structure: WordPress. Straightforward online stores: WooCommerce or Shopify, since Drupal Commerce is excellent but wants a developer on hand. Anything where the whole team is already fluent in another stack, because switching cost is real and rarely shows up in the pitch.
Start with the closest fit
The pages worth reading first are the ones matching your organisation: Drupal for government covers accessibility obligations and multisite for departments, Drupal for education covers course catalogs and faculty profiles, Drupal for media and publishing covers editorial workflow at volume, Drupal for nonprofits covers membership and donation flows, and Drupal for corporate sites covers the multilingual and governance case. If none of them describes you, that is useful information too, and our Drupal development services page explains how we scope an honest second opinion.
Sites with structured content and many editors. In practice that means government portals, university and college sites, hospital networks, large membership organisations and publishers running several titles from one system. The common thread is not size for its own sake but content that has fields, relationships and rules about who can publish it.
Usually yes. If you have a handful of pages, one or two people editing, and no complicated permissions, WordPress will cost less to build and far less to run. We say this as a shop that builds both. The one exception is a small organisation with unusually strict content governance, such as a regulated body where approval chains matter more than page count.
Three things they need and most CMSs treat as add-ons: granular permissions and editorial workflow out of the box, accessibility taken seriously at the core level, and multisite so a hundred departments can share one platform without a hundred separate installs. Procurement also likes that it is open source with no per seat licence, which removes a recurring budget fight.
Yes, through Drupal Commerce, and it is genuinely good when the store sits inside a larger content site or has unusual product modelling. For a plain catalogue and checkout, Shopify or WooCommerce gets you there faster and cheaper. We would put a store on Drupal when the content is the harder half of the project, not the commerce.
For equivalent scope, expect Drupal to be more expensive up front because the content modelling is deliberate work rather than a theme choice. It tends to close the gap over the years on large sites, since changes stay contained instead of turning into plugin archaeology. On a small site the gap never closes, which is exactly why we do not recommend Drupal there.
Drupal 7 lost official support in January 2025, so you are running unpatched code on a public site. The realistic options are a rebuild on Drupal 10 or 11, or a move to another CMS if Drupal was the wrong fit in the first place. We audit both routes honestly, and we have told clients to leave Drupal when the site never needed it.
The editing experience is fine once a developer has configured it properly. The complaint people actually have is about site building, which in Drupal is a developer task rather than a click-together one. If your team expects to add new page types themselves without help, set that expectation with your build partner before you start.
30 minutes with a senior engineer. No salespeople. We respond within one business day with a brief outline.
Send a project brief →