# Drupal CMS recipes for faster site builds

Use Drupal recipes to add SEO, media and content types without a distribution lock-in. When YAML helps.

- Date: 2026-08-25
- Category: Drupal

Drupal CMS recipes are how I now add SEO, media, and content types to a Drupal 11 site without locking the project into a distribution I cannot unwind. I am Alan Vo, a Gold Coast web developer with 18 years on business and government-adjacent CMS work. In 2026 recipes are the install path Drupal CMS is built on. They are YAML and config, applied once, not a second core you have to fork.

This note is for people on Drupal 10 or 11 who still remember install profiles that owned the whole site. It is also for teams about to run a [Drupal CMS migration](https://alanvo.com/blog/drupal-cms-migration/) and who need to know what a recipe will and will not touch. The [Drupal recipes documentation](https://www.drupal.org/docs/extending-drupal/drupal-recipes) is the platform spec. What follows is how I use them on production catalogues of content, not a hello-world demo.

## Why Drupal CMS recipes matter in 2026

Drupal CMS recipes matter because distributions solved "start fast" and failed at "upgrade for five years". A profile that ships fifty modules, a theme, and a content model becomes a fork the day you change a field. Recipes are additive and, when they are written well, idempotent. You apply SEO Tools, you apply a blog, you apply a media type. You do not inherit a mystery `hook_install` that rewrites your user roles every update.

Drupal CMS 1.x shipped as a product on top of Drupal core with recipes as the packing format. Drupal CMS 2.x leaned harder into site templates, Canvas, and the same recipe pipeline. I still treat core Drupal as the runtime I must be able to explain in an incident. Recipes are config with a documented list of modules. If I cannot name what a recipe enabled, I do not apply it on a government or museum site.

YAML helps when the alternative is a 90-minute click path through Field UI, Metatag defaults, and sitemap inclusion. YAML hurts when someone pastes a recipe that enables modules you already configured differently. Apply on a clone. Read the config diff. Then apply on production with a maintenance window if the recipe touches roles or filters.

I have shipped Drupal for regulators, museums, and brand sites as contract development on an agency team. Those sites already have content types. A recipe that creates `article` again is not a gift. A recipe that only adds Metatag and a sitemap, or that you wrap so it maps onto `page` and `news`, is the useful shape.

![Drupal CMS recipes documentation open beside a laptop](../../images/blog/drupal-cms-recipes-1.jpg)

## How Drupal CMS recipes actually work

Drupal CMS recipes actually work as a folder of `recipe.yml` plus config to import, modules to install, and optional extra steps (content, actions). Drupal applies them through the installer, Project Browser, Drush, or `php core/scripts/drupal recipe`. They are not Composer packages in the old profile sense, though many live on Drupal.org and you require them with Composer so the files exist in the codebase.

A typical recipe will:

1. Declare dependencies (other recipes or modules).
2. Install modules if they are not already present.
3. Import default config: fields, form displays, Metatag defaults, sitemap settings.
4. Sometimes create a content type or media bundle.

Idempotent means applying twice should not explode. In practice, a second apply can fail on config that already exists with a different UUID, or it can skip. I never assume. I run on a database copy and watch the messages.

Recipes do not replace Composer. You still lock module versions. A recipe that says "enable Metatag" still needs a compatible Metatag in `composer.lock`. Security updates stay a Composer job. The recipe is how config and enablement get reused.

Site templates in Drupal CMS 2.x are opinionated starting points built from recipes plus a theme and Canvas components. Byte-style marketing templates are for greenfield brochure sites. They are the wrong default for a regulator with existing IA. I use the small feature recipes (SEO, privacy, blog) on existing sites. I use a full site template only when the brief is a new marketing Drupal CMS.

Wrapper recipes are how agencies should work: your `recipe.yml` lists community recipes you trust, then adds your fields and roles. You do not fork SEO Tools and then miss upstream fixes. You compose.

There is still no universal "recipe update path" that behaves like `hook_update_N` for every community recipe. That gap is why I treat recipes as day-zero and day-of-feature tooling, not as a forever patch train. If you need ongoing config, put it in your own install or update hooks, or in a custom recipe you own.

## Drupal CMS recipes for faster site builds in practice

Drupal CMS recipes for faster site builds only save time if you stop re-solving Metatag and media on every project. I keep a short list I actually apply:

- SEO Tools (or SEO Basic, then Tools) for Metatag, sitemap, redirects, checklist. Detail is in [Drupal SEO Tools recipe: what you actually get](https://alanvo.com/blog/drupal-seo-tools-recipe/).
- Media and image media type if the site is not already on media.
- Privacy / consent related recipes only after legal has a banner rule.
- A content-type recipe only when the type is new.

![Team workshop around a table planning a CMS rebuild](../../images/blog/drupal-cms-recipes-2.jpg)

Government and culture sites already have a content model. Faster there means "do not click sitemap settings for an hour", not "replace News with Article because the recipe said so". I open the recipe's listed modules and config names before I apply. If it creates bundles I do not want, I apply pieces by hand or I write a wrapper that only imports the config I need.

Drush on CI is how I keep staging honest. A human clicking Project Browser on production is how you get a recipe applied twice with two stories. The pipeline applies the recipe on a built artifact, then config export is committed so git remains the source of truth. Recipes that import config you then change must be exported. Otherwise the next apply fights your tweaks.

Multilingual sites need extra care. A recipe that sets English-only Metatag defaults will look fine until French pages ship empty descriptions. I apply, then immediately check language-specific config. ROM-style bilingual builds are not a demo recipe.

## Production checklist before you apply a recipe

1. Clone the database. Never first-apply on production.
2. Read `recipe.yml` and the module list. Note every content type and role it touches.
3. `composer show` the modules so versions match what you already run.
4. Take a config export snapshot so you can diff.
5. Apply with Drush or the core recipe command, not a mix of UI and CLI.
6. Export config. Commit only the intended delta.
7. Run `status-report` and cron. Check for missing module dependencies.
8. Click the new UI: Metatag defaults, sitemap inclusion, media widget on a real node.
9. If the recipe added a theme or admin theme, confirm Gin or your admin theme is still what editors use.
10. If the site uses Layout Builder, confirm the recipe did not switch view modes behind your back.
11. Write the recipe name and date in the project README. Future you will not remember.
12. Plan who is allowed to apply recipes in production. It should be the same people who deploy config.

I refuse recipes that enable a dozen "nice to have" modules with no owner. Each module is a security surface and an upgrade.

![Library stacks used as a stand-in for structured content](../../images/blog/drupal-cms-recipes-3.jpg)

## What breaks when Drupal CMS recipes go wrong

Drupal CMS recipes go wrong when they collide with existing machine names, when they enable a module you already customized, and when nobody exports config after a UI apply.

Failure modes:

- Duplicate `article` or `page` bundles, or a recipe that fails because the type exists.
- Text formats overwritten so a government HTML filter becomes Full HTML.
- User roles with extra permissions (administer meta tags for anonymous is the nightmare version).
- Pathauto patterns that fight an existing alias scheme and generate a second pattern.
- Search API or Solr config imported for a site that uses core search, or the reverse.
- Canvas or Mercury theme assumptions on a site that still uses a custom theme and Layout Builder.
- Partial apply after a fatal error: modules on, config half imported. Restore the clone. Do not "finish by clicking".

Distributions used to hide this inside an install profile. Recipes make it visible, which is better, if you look.

## How to measure whether a recipe earned its keep

Measure a recipe by time-to-baseline and by regressions, not by module count. Did Metatag, sitemap, and redirects exist and match the IA in one deploy instead of a day of UI? Did Search Console still receive the same sitemap URL? Did editors still have the same text format?

I also watch:

- Config diff size. A 400-file dump from one recipe is a smell unless you expected it.
- Status report errors after apply.
- Cron duration if the recipe enabled heavy search or XML sitemap rebuilds on a large node table.
- Content editor time to fill the new fields. A recipe that adds seven SEO fields nobody will complete is not SEO. It is form noise.

Do not claim organic traffic lift from applying a recipe. That is content and crawl work. The recipe only installed the tools.

## Related work on this site

Large Drupal IA is why I care about additive recipes instead of a new distribution. The [NDIS Commission site](https://alanvo.com/work/ndis-commission/) is Drupal for quality and safety information aimed at participants and providers. The [Royal Ontario Museum rebuild](https://alanvo.com/work/royal-ontario-museum/) is bilingual Drupal for exhibitions, membership, and visits. Both were contract development on an agency team. Those codebases cannot accept a marketing site template that recreates `page`. They can accept a recipe that only turns on Metatag, sitemaps, and a checklist, then maps onto the types they already have.

![Government-style office desks and screens](../../images/blog/drupal-cms-recipes-4.jpg)

## FAQ

### Are Drupal CMS recipes the same as install profiles?

Drupal CMS recipes are not install profiles. Profiles own a site at install time. Recipes add features to a site that already exists (or to a CMS install). You can still start from Drupal CMS and apply more recipes later. You should not expect a recipe to replace a full profile migration by itself.

### Can I use Drupal CMS recipes on a site that is "just Drupal 11"?

You can use Drupal CMS recipes on a standard Drupal 11 project if you Composer-require the recipe and its modules. You do not have to have used the Drupal CMS installer. You do have to accept the modules and config it wants, or wrap it.

### Do Drupal CMS recipes lock me in like a distribution?

Drupal CMS recipes should not lock you in if you export config and own Composer. The lock-in risk is applying a recipe you never inspect, then depending on bundles you did not design. Read the YAML. Keep git as the source of truth.

### Should every new feature be a Drupal CMS recipe?

Not every feature should be a Drupal CMS recipe. A one-line module enable can be Composer plus config. Recipes pay off when you repeat a bundle of modules and default config across sites, or when Drupal CMS already ships that bundle. Custom business fields still belong in your own config, not in a public recipe you cannot change.


![Editor typing in a CMS during Drupal CMS recipes work](../../images/blog/drupal-cms-recipes-5.jpg)


HTML version: https://alanvo.com/blog/drupal-cms-recipes/