Drupal Metatag configuration for SEO and social sharing

On a site with a handful of content types, the simplest approach is to set one pattern per entity type and bundle at the Metatag defaults level, then let each node inherit it. A pattern for the page title can combine the node title with the site name, and a description pattern can draw from the summary or body field with a length limit. Because there are few bundles, the team can read every pattern on one screen and confirm that each one makes sense for the content it applies to.

• Start with the node title and site name: Use the page title token and the site name token so every page carries a clear, unique title in the browser tab and search results.
• Set the description from a summary field first: Point the description pattern at a dedicated summary field where editors write one, and fall back to a trimmed body token only when no summary exists.
• Keep canonical URLs on the node URL token: Let the canonical pattern resolve to the node's own URL so each piece of content names one preferred address.
• Override only the front page and error pages: These pages rarely follow a content pattern, so set them by hand once and leave the rest to inheritance.
• Write the rules down: A short table of bundle, title pattern, description pattern and canonical pattern lets a second person review the setup without opening the configuration.

Before launch, create one node per bundle with the summary and body left empty and confirm the output still reads sensibly.

On an estate with many content types and bundles, the main risk is drift: each bundle gets its own pattern, small differences accumulate, and nobody can say which rule applies to a given page. A workable structure sets a broad default for each entity type, then adds narrow bundle patterns only where the content genuinely differs, such as events with a date or products with a price. Broad patterns keep the configuration short and predictable, while overrides handle the exceptions that a pattern cannot express cleanly.

• Set the broadest default that is still accurate: A single node default for title and description covers most bundles if the tokens resolve to meaningful text on each one.
• Add bundle patterns only for real differences: Event or product bundles can carry extra tokens for dates or prices, while bundles with the same fields should inherit the default.
• Limit hand-written overrides per node: Overrides on individual nodes fix one-off pages, but each one is a manual step that the next migration or content audit must find and preserve.
• Name patterns consistently: Use the same token order and punctuation across bundles so a change to the site-wide separator or name does not require many edits.
• Review overrides on a schedule: Export or list the nodes with custom meta values and remove those that no longer match the content.

Ask for a test matrix that covers every bundle with empty, short and long field values before any pattern change goes live.

Taxonomy term pages and user profile pages use different entities, so node patterns do not apply to them. Each needs its own entity type and bundle entry in Metatag, and each has fields that behave differently from node fields. A term may have a long description or none at all, and a user page may expose only a display name. Some of these pages also index poorly or duplicate content, so the pattern decision is partly an indexing decision, not only a formatting one.

• Configure term and user entities separately: Set title and description patterns for each vocabulary or group where term pages are public, using the term name and description tokens.
• Fall back when descriptions are empty: Term pages without a description need a pattern that produces a useful description from the term name and parent term rather than a blank tag.
• Decide which user pages should be indexed: Many profile pages hold little public content. Confirm the indexing policy with the business owner before writing patterns for them.
• Watch for duplicate paths: Taxonomy listing pages with filters or pagers can generate near-identical canonicals, so confirm which URL each pattern names as canonical.
• Keep private data out of tokens: Avoid tokens that expose email addresses or internal account fields in meta output.

Check the rendered head of a sample term page and a sample user page, and confirm with the content owner which of these pages should be indexed at all.

Every pattern is a trade-off. Broad patterns apply to thousands of pages with little maintenance, but they produce generic text when the source fields are thin. Hand-written overrides give precise copy for important pages, but they multiply the places where metadata can go stale, and they must be carried across upgrades and migrations. A sound configuration uses broad patterns as the floor and overrides as a deliberate, small set of exceptions with a stated reason.

• Use broad patterns for volume: Archive, listing and long-tail content usually performs acceptably with inherited patterns and needs no manual copy.
• Reserve overrides for high-value pages: Landing pages, product launches and key service pages justify hand-written titles and descriptions that editors maintain.
• Record why each override exists: A short note in the editorial workflow or content record explains the exception, so the next reviewer does not remove it by mistake.
• Check for conflicts: An override on a node can silently replace a pattern that a migration or a later module update relies on, so compare outputs after changes.
• Plan who edits what: Decide whether editors can override descriptions and canonicals or only titles, because canonical mistakes cause more harm than wording issues.

Ask the team to list the pages that carry overrides and to confirm that each one still matches its content.

Most metadata failures appear when a field is empty, not when it is filled. A title pattern that joins a missing subtitle with a separator can leave stray punctuation, and a description pattern that relies on a summary can output an empty tag on any node where editors skipped that field. Testing with realistic and deliberately empty content, before and after each pattern change, reveals these gaps early. The test should cover the rendered HTML head and the social preview output, not only the admin form.

• Build a set of test nodes: Create nodes per bundle with all fields filled, with optional fields empty, and with only required fields set.
• Inspect the rendered head: Check the title, meta description, canonical link and Open Graph and Twitter Card tags in the page source for each test node.
• Look for stray separators and blank values: Empty tokens can leave double dashes, trailing pipes or empty content attributes that validators flag.
• Repeat tests after configuration changes: Run the same set after updating patterns, Metatag, or the theme that outputs the head.
• Confirm with a social debugger: Preview shared links with the platform debugging tools the marketing team uses, since those tools cache results.

Ask the implementation partner for the test node list and the rendered output for each one before the pattern set is approved.