23 Jun 2026
Drupal.org aggregator
Aten Design Group: Drupal Metatag Module Basics for Content Editors
Drupal Metatag Module Basics for Content Editors
Helping your website content be found, shared, and understood clearly and responsibly.
When you publish website content, the work does not stop at the page itself. Search engines, social platforms, and browsers all rely on behind-the-scenes information to understand what your content is about and how it should appear to people looking for it.
In Drupal, the Metatag module gives content editors a way to shape that understanding. You do not need to be a developer to use it effectively as part of your day-to-day content work. Editing and reviewing metatags is generally straightforward for content editors.
Installing the module and establishing site-wide defaults typically requires a developer or someone with Drupal experience. Tasks such as adding the module, enabling it, and defining default values are usually handled during site setup. Once that foundation is in place, content editors can focus on the quality and context of their content rather than technical implementation details.
This article explains the most common Metatag settings you will encounter, what they do, and when they matter.
What the Metatag Module Does
The Metatag module lets you manage information about your content that is not visible on the page itself, but is visible to:
- Search engines such as Google and Bing
- Social media platforms such as Facebook, LinkedIn, and X
- Web browsers and assistive technologies
You can think of metatags as context. They help external systems understand your content and present it accurately to people who depend on those systems to find trustworthy information.
Metatags on Content Edit Screens
As a Drupal content editor, the metatag fields you will work with most often appear directly on the content editing screen alongside the rest of the page fields.
You will typically see them:
- On content edit screens for pages, articles, events, and similar content types
- Grouped under a Metatag or SEO section
Many of these fields are pre-populated using defaults established during site configuration.
These fields control how a specific piece of content appears in search results and social shares. You will not need to adjust them for every page. Understanding what they do helps you make informed decisions for high-visibility content, time-sensitive information, or pages likely to be shared widely.
Metatag Configuration
You may also hear references to "Metatag settings" or "Metatag configuration." These live in the Metatag module's administrative settings rather than on individual content pages.
This configuration is used to:
- Define site-wide defaults for titles, descriptions, and social previews
- Control which metatag fields appear for different content types
- Set fallback values when editors leave fields blank
Because these settings affect the entire site, they are typically managed by developers or site administrators. Content editors generally do not need to interact with this area as part of their regular workflow.
Understanding this distinction helps establish clear ownership: developers maintain the framework, while editors focus on content quality and accuracy.
Core Metatags You'll Use Most Often
Page Title
What it is
The page title appears in browser tabs and is often used as the main headline in search results.
Why it matters
This is one of the clearest signals search engines use to understand what a page is about. It is also the first thing many people see when deciding whether to click.
Best practices
- Keep it clear and specific
- Put the most important words first
- Aim for roughly 50 to 60 characters
Example
Summer Programs for Kids | City of Example
Meta Description
What it is
A short summary that often appears below the page title in search results.
Why it matters
While it does not directly affect rankings, it helps people decide whether a page is relevant to them.
Best practices
- Write in plain language
- Be accurate and inviting
- Aim for roughly 150 to 160 characters
Example
Explore fun and educational summer programs for children ages 5-12. Registration now open.
Canonical URL
What it is
The canonical URL tells search engines which version of a page should be treated as the primary one.
Why it matters
This helps search engines identify the authoritative version of content when similar or duplicate pages exist.
For editors
In most cases, this is handled automatically. You usually will not need to change it.
Robots (Index / Follow)
What it is
Instructions that tell search engines whether they should:
- Include the page in search results (index)
- Follow links on the page (follow)
Common settings
- Index, Follow: Appropriate for most public-facing pages
- No Index: Used for pages that should not appear in search results
Why it matters
These settings help ensure that search engines surface the right content while excluding pages that may be temporary, incomplete, or intended for limited audiences. Used thoughtfully, they support clarity, trust, and consistency across the site.
When "No Index" is appropriate
- Temporary or time-limited pages
- Confirmation or thank-you pages
- Internal-only content
Social Sharing Metatags
These settings control how your content appears when it is shared on social media. Clear, accurate previews help people quickly understand what they are being asked to read or click.
Open Graph (Facebook, LinkedIn, and Others)
Open Graph Title
What it is
The headline shown in social previews when the page is shared on social platforms.
Helpful tip
This does not have to match the page title exactly. You can use more conversational language if it helps provide useful context.
Open Graph Description
What it is
A short summary shown beneath the title in social previews.
Helpful tip
Focus on clarity and relevance. This text helps people decide whether the content is useful to them.
Open Graph Image
What it is
The image displayed alongside the title and description in social feeds.
Why it matters
A clear, relevant image helps your content stand out and be understood at a glance.
Best practices
- Choose an image that reflects the content honestly
- Use high-quality images without small or difficult-to-read text
- Avoid images that feel generic or misleading
Advanced Metatags
You may notice additional fields that are rarely needed on a page-by-page basis. These metatags are typically managed at the site level rather than by individual content editors.
In most Drupal sites, advanced metatags are:
- Configured centrally in the Metatag module settings
- Applied automatically using site-wide defaults
- Maintained by developers or site builders as part of the site's overall configuration
This approach promotes consistency across the site while reducing the risk of configuration drift and unintended changes.
As a content editor, you generally do not need to edit these fields. They are managed for you so you can focus on creating and maintaining clear, useful content.
Keywords
Modern search engines largely ignore this field. You can usually leave it empty unless your organization has a specific reason to use it.
Content Language
The Content Language metatag communicates the language of the page to search engines, browsers, and assistive technologies.
This is usually set automatically based on the site's configuration. During site setup, a developer or site builder defines the site's default language and any additional supported languages in Drupal's language settings.
Drupal applies the appropriate language metadata to each page based on:
- The site's primary language
- Whether the site supports multiple languages
- How a specific piece of content is configured or translated
You typically do not need to manage this field directly. It is handled automatically to help ensure content is interpreted and presented correctly across devices, platforms, and accessibility tools.
Site Verification, Geo Tags, and Custom Tags
These fields are often used for:
- Search engine verification
- Analytics and monitoring tools
- Organization-wide integrations
They are usually managed globally rather than by individual editors.
Want to Go Deeper?
For teams responsible for Drupal configuration, governance, or ongoing platform maintenance, the following resources provide additional detail:
Drupal Metatag module documentation (Drupal.org)
Official documentation covering available metatag types, defaults, and configuration options:
https://www.drupal.org/docs/contributed-modules/metatag
Working with images in metatag fields
A helpful explanation of how metatag image fields work with Drupal Media and tokens:
https://mark.ie/blog/adding-tokens-for-metatag-image-fields-when-using-drupal-media-entity
These resources are most useful for developers and site builders, but they can also provide helpful context for editors interested in understanding how content is presented across platforms.
Key Takeaways
Most Drupal sites provide sensible metatag defaults, which means editors rarely need to complete every field. Even so, it is worth reviewing metatags for key landing pages, high-traffic content, major announcements, and pages that are likely to be shared externally.
Before publishing, take a moment to confirm that:
- The page title clearly reflects the content.
- The meta description accurately summarizes the page.
- Social sharing previews make sense when viewed outside the context of the website.
- The page is intended to appear in search results.
Metatags are not a substitute for clear content, good information architecture, or strong governance. They are supporting metadata that helps search engines, social platforms, browsers, and assistive technologies interpret content consistently. When paired with well-structured content and thoughtful editorial practices, they help ensure information is represented accurately wherever people encounter it.
23 Jun 2026 8:38pm GMT
Palantir: Freedom is Not Free: A Model for Open Source Sustainability
Freedom is Not Free: A Model for Open Source Sustainability 
demet
How to align public policy and procurement to support the costs of our shared digital infrastructure
The modern world runs on open source software-trillions in economic value, and growing more essential to digital sovereignty by the day. Yet, beneath this foundation, the projects producing it are starved of capital. Open source simply does not have the structural resources it needs to be sustainable. The code is free, but the human and technical infrastructure required to maintain it is not.
A project like Drupal is no longer just a code repository; it is a full-scale utility provider. We deliver supply chain security, product management, and continuous integration pipelines. Our licenses waive all warranties and responsibilities-and yet enterprise scale demands we provide these services anyway, because no one else will. The core failure of our current model is that open-source funding is completely disconnected from these operational cost centers.
Because we lack a built-in mechanism to capture the value open source creates, we have accidentally engineered an extractive system. The Takers who consume open source without paying their fair share of its operational footprint are not acting out of malice; they are simply doing exactly what the market currently incentivizes them to do.
It is not inevitable that open source must be extractive. That is an architectural choice. To change the outcome, we must change the incentives. Using regenerative system design, we must re-engineer open-source models to capture enough resources from our outputs to continuously sustain our inputs. We must ensure that supporting open source the right way becomes both the easy way and the expected way.
Right now, supporting open source the right way is almost impossible for our largest users. Public procurement systems are designed to buy structured services from single vendors. They cannot write open-ended checks to decentralized communities. To bypass this "charity trap," we must transition to an operational cost framework and move the operating costs of open source off the donation sheet and directly into core operating budgets as a predictable, line-item consumption expense.
To make the easy way possible, open source foundations must clearly quantify and communicate our true technical and human costs. In Drupal, we know part of it. We provide $10 per site per year in consumable technical infrastructure, but our revenues only fund $7.50. The remaining $2.50 is pushed off as technical debt to the future. That gap says nothing about the release managers and security teams whose essential work is still mostly donated-that burden sits entirely outside this number. We must turn these technical and human maintenance costs into a transparent, billable utility, giving institutions a clear, legally compliant way to pay for what they consume.
But once we make it easy to pay for this utility, how do we make it the expected way?
That requires establishing two clear standards.
For the vendor ecosystem, we need a sustainable participation standard. In Drupal, we have a contribution credit system to visibly recognize our Makers, those who invest real capital, code, and labor into the project. This system also helps us to identify the Fakers, organizations that use sponsorship and marketing to signal commitment while funding and doing little-to-none of the actual work.
For public institutions and enterprise users, we need a sustainable use standard defined by three practices:
- One, select vendors who sustainably participate in the projects they use.
- Two, include an explicit open source maintenance line item in every contract-a cost-recovery expense that shifts the burden off pro-bono maintainers.
- Three, require timely upstream release of all non-sensitive bug fixes and features.
With these standards in place, Open Source Program Offices can work with procurement officers to differentiate the true Makers from the Takers and Fakers at the point of purchase. And, the market-making power of public purchasing operationalizes "Public Money, Public Code" into the norm.
Open source cannot thrive on the margins of volunteerism, but it doesn't have to. Once public policy acknowledges open source maintenance as an operational cost rather than a charitable act, everything else follows. That's regenerative system design in practice: change the incentives, and the system begins to fund itself.
Adapted from a June 23, 2026 presentation by Tiffany Farriss at the Sovereign Tech Agency's Breakfast Reception during United Nations Open Source Week. Photo by Mike Gifford, licensed under CC BY-SA 4.0.
23 Jun 2026 4:49pm GMT
Dries Buytaert: Drupal's role in agentic workflows
When we started working on the Drupal AI initiative in June 2025, I assumed most AI features would live inside Drupal.
By my DrupalCon Chicago keynote in March 2026, my thinking had changed. I framed the shift as "inside-out" versus "outside-in" and concluded that not every AI capability belongs inside Drupal. Some work is better done outside the CMS, where AI tools can move faster and connect back to Drupal when needed.
Last week, I explored these ideas in more detail in "AI and the great CMS unbundling". That post argued AI is making the CMS less central as a creation tool, but more important as a control layer: the place where content is structured, governed, reused, and published with trust.
This post picks up from there. If Drupal's role as the control layer is becoming more important, it needs to support AI-driven workflows that run inside Drupal, start outside Drupal, and move across both: external workflows that call into Drupal, and Drupal-native workflows that outside systems can safely rely on.
Drupal joins workflows beyond the CMS
First, Drupal needs to work well with tools outside the CMS: coding agents like Claude Code and Cursor, and orchestration platforms like Salesforce Agentforce, n8n, and Activepieces.
I actually showed what this could look like in my DrupalCon Vienna keynote in October 2025. Here is a short clip of that:
It was a proof of concept demo, and we had some fun with it. But the pattern behind the demo mattered more than the demo itself: an external tool drove the work and handed tasks to Drupal, while Drupal returned structured content and state.
Watch the demo, and it will be easy to imagine the same pattern in a real marketing use case. Campaigns usually begin with a marketing brief and span many tools and channels: email, website landing pages, social media, paid media, and more.
An external agentic platform could generate campaign copy and ask Drupal to build a landing page. Drupal could map the copy to the right structured content type, place it into approved components with Drupal Canvas, save a draft, and flag any fields, metadata, or translations still missing before it can publish.
If Drupal reports a missing hero image, the agentic platform could search the digital asset management system (DAM), find an approved campaign image, and hand it back. Drupal could then attach it through its media model, supply or verify the required alt-text, confirm the page meets its requirements, and advance the draft through the editorial workflow.
This is a pattern that Drupal will need to support well. External platforms can coordinate work across the broader digital stack, but Drupal should remain the system that assembles, validates, governs, and publishes the content.
External workflows call Drupal-native workflows
While the larger campaign workflow may live outside Drupal, there is an equally important case for Drupal-native workflows.
External agents are good at coordinating work across systems. But once a workflow needs to act on Drupal content or data, it should use Drupal's native content model, permissions, validation rules, moderation states, revisions, and publishing workflows rather than recreate them outside of Drupal.
That is where projects like ECA, FlowDrop, and Maestro become more important. They let Drupal turn site-specific processes into repeatable, multi-step workflows that outside systems can call.
For example, any of these three systems could power a single Drupal workflow that validates a draft, coordinates translations in five languages, assigns reviewers, and publishes the content only after all required approvals are complete.
Depending on the task, these internal Drupal workflows can be deterministic, AI-assisted, or fully agentic. Drupal can support that today.
An external agent should not have to manipulate Drupal from the outside, field by field or function by function. It should be able to ask Drupal to execute a Drupal-native workflow through a single external API call.
That is the other half of what I showed in the demo video above. Drupal was not just exposing content to an external agent. It was exposing custom Drupal-native ECA workflows that an external automation tool called.
That was powerful last fall at DrupalCon Vienna, but as agentic workflows become more common, this pattern will only grow in importance.
The best end-to-end experience will win
There is a natural tendency to debate what should live where. Should AI happen inside Drupal, or outside of it? Should workflows be Drupal-native, or managed by external platforms?
Those are useful questions, but the answer is not universal. AI and workflows should live where they create the best end-to-end experience. Sometimes that will be inside Drupal, sometimes outside Drupal, and often across both.
What "best" means depends on the use case, the user, and the requirements for speed, reliability, security, governance, cost, and human review. There will be best practices, but no single approach fits every case.
Who is doing the work shapes what "best" looks like:
- A developer may prefer an external coding agent like Claude Code.
- A marketer may prefer a Drupal-native experience that keeps them close to previews, translations, moderation, and publishing.
- A campaign manager may need an external workflow that coordinates email, social media, analytics, DAM, and CMS.
Work will move across systems and people. The best end-to-end experience will come from doing each step where it can be done best, while making the handoffs feel invisible.
A head start is not a plan to win
Understanding Drupal's role in these future workflows gives us clarity about where Drupal needs to go. Drupal needs to get better at supporting external orchestration, Drupal-native workflows, and the real-world hybrids that combine both.
What makes Drupal interesting is that it already has so much of the hard, unglamorous infrastructure these workflows need: structured content, granular permissions, revisions, rollback, JSON:API, and plenty more. These are exactly the capabilities agents need, and they're genuinely difficult to build well from scratch or retrofit.
Conceptual clarity and a strong foundation are wonderful things, but they are not enough to win.
When I asked whether AI coding agents would recommend Drupal, the issue was not Drupal's capability. It was whether agents could get from prompt to a working Drupal site quickly and easily enough. As I wrote in "Friction, abstraction and verification", agents tend to choose the path that gets them to a real, verified result with the least friction.
For experienced Drupal teams, the challenge is different. They have already chosen Drupal. They do not need an agent to recommend it. They need agents that help them build, validate, and ship quality work faster.
To turn Drupal's advantage into adoption, we need to improve both paths: helping agents choose Drupal for new builds, and helping existing Drupal teams ship better work faster. Both depend on making it easier for agents to work with Drupal from start to finish.
That means Drupal needs to expose the best practices, site context, tool definitions, constraints, and precise validation agents need to take the right actions and verify the result.
A lot of this is already underway across Recipes, Site Templates, Drupal AI, Drupal Canvas, ECA, FlowDrop, Maestro, MCP, and CLI improvements, to name a few.
But the goal is bigger than any one project. Drupal needs these efforts to add up to a clear, coordinated path for agents: from setup to connection, context, governed action, validation, recovery, and launch.
Special thanks to James Abrahams, Jürgen Haas, Randy Kolenko, Scott Falconer, and Shibin Das for their review and contributions to this blog post.
23 Jun 2026 1:47pm GMT