40,000 contributed modules exist. You need about twelve. Here is our default Drupal 10 and 11 stack and the rule we use to keep it lean.
There are more than 40,000 contributed modules on Drupal.org. That number gets quoted as a selling point, but it is closer to a warning. Every module you bolt on is one more thing to patch, one more thing that can block your next major upgrade, and one more line in your attack surface. A good Drupal site is not the one with the most modules. It is the one with the right dozen.
So instead of another list of fifty modules you will never install, here is the set we reach for on almost every Drupal 10 and 11 build, and the rule we use to decide when something earns a place in the codebase.
No plugins listed yet for Drupal.
Start with the unglamorous plumbing. Token and Pathauto generate clean, consistent URLs from patterns instead of leaving editors to hand-type slugs. Redirect catches the old paths so a relaunch does not torch your rankings. Metatag handles titles, descriptions, and Open Graph tags, which is the closest Drupal gets to a Yoast-style SEO layer. Those four go in before anything else.
For the people who actually run the site day to day, Admin Toolbar turns Drupal's slow drop-down menus into something usable, Gin replaces the dated default admin theme, and Coffee gives editors a keyboard shortcut to jump anywhere. They sound minor. They are the difference between a client who logs in happily and one who emails you to change a phone number.
Then the content tools. Paragraphs is how we build flexible layouts without handing editors a page builder that breaks the design. Webform covers everything from a contact form to a multi-step application with conditional logic. Search API (usually with Solr) is what you use the moment the built-in search stops being good enough, which is sooner than people expect. For stores, Drupal Commerce is the answer, though that is a bigger conversation than a module install.
The rule we follow: use a maintained contributed module if a credible one exists, and write custom code only when nothing fits or the fit is bad. A contrib module with an active maintainer and a security-team cover gets you free patches and other people finding the bugs first. Custom code is yours forever, including the upgrade bill. We still write plenty of custom modules, but for behaviour that is genuinely specific to the client, not to re-solve something Pathauto already solved in 2011.
One more recent shift worth knowing. The 2025 Drupal CMS release ships with a curated set of these modules already configured, so a fresh install is far less of a blank canvas than it used to be. If you are starting new, that is a reasonable base. If you are inheriting an older site stuffed with abandoned modules, the bigger win is usually removing things, not adding them.
Need a module that does not exist yet, or a site audited for the ones that should not? That is what our Drupal development services are for. And if you are still deciding between platforms, the Drupal versus WordPress breakdown covers where this ecosystem pulls ahead.
For migration playbooks, cost breakdowns, and platform comparisons, see the Drupal blog.
Modules are packages of code that add or change what Drupal does, the same role plugins play in WordPress. Core ships with a base set, contributed modules come from the community on Drupal.org, and custom modules are written for a specific site. Most real builds use all three.
On nearly every build we install Token, Pathauto, Redirect, and Metatag for URLs and SEO; Admin Toolbar, Gin, and Coffee to make the admin usable; and Paragraphs, Webform, and Search API for content and forms. That short list covers most of what a typical site needs before you add anything specialized.
There is no fixed number, but every contributed module is something to patch and a potential blocker for your next major-version upgrade. We would rather run twenty well-maintained modules than sixty, including a few abandoned ones nobody dares remove. If a module has no recent releases and no security coverage, treat it as a liability.
Contributed modules on Drupal.org are free and open source. The cost is in configuration, maintenance, and the occasional paid integration or hosting service a module depends on, such as a Solr server for Search API. Budget for the upkeep, not just the install.
They mean the same thing in casual use. Drupal's own term is module. People coming from other platforms often say extension or add-on. Themes are separate: those control how the site looks rather than what it does.
Use a maintained contributed module when a credible one exists, since you get free updates and a wider pool of people catching bugs. Build custom only when nothing fits or the fit forces awkward workarounds. Custom code solves your exact problem but becomes your responsibility to maintain through every upgrade.
30 minutes with a senior engineer. No salespeople. We respond within one business day with a brief outline.
Send a project brief →