Every Drupal team building on Canvas has hit this: a landing page goes live, and its link preview comes back blank, no image, no description. The fields aren't missing. Canvas's builder form just never exposes the Metatag data already sitting on the page entity, the same field type every other Drupal page type uses.
Drupal Canvas is Drupal's newer, component-driven page builder, built for speed over templates. That speed hides almost every SEO and social field behind one "SEO title" box. Canvas Page Metatag reopens those fields and fixes a real Form API bug along the way - work that matters to developers and content teams managing Canvas pages alike.
Key Takeaways
- Canvas Page Metatag restores the Metatag fields that Drupal Canvas’s builder form hides, bringing back meta description, robots, Open Graph, Facebook, and Twitter Card controls.
- Every Canvas page already carries a full Metatag field. The module only restores
#access to it, so it doesn’t introduce a second metadata system.
- It also fixes a Form API bug: Canvas’s React UI submitted Robots checkboxes with corrupted values, which made Canvas page saves fail whenever that field was enabled.
- Site admins choose which of five Metatag groups (Basic Tags, Advanced, Open Graph, Facebook, Twitter Cards) editors can see, from one settings page.
- Standard Metatag configuration at
/admin/config/search/metatag stays exactly as it was. Canvas pages just plug into it.
What metadata does Drupal Canvas hide by default?
Every Canvas page has a Metatag field on its entity. This is the same field type that already gives full SEO control on nodes and taxonomy terms elsewhere in Drupal.
The problem sits in CanvasPageForm::form(), Canvas’s own edit form. It hides nearly all of those fields and leaves editors with a single SEO title box.
That creates a real gap on any site running Canvas pages in production:
- No meta description for search engine snippets.
- No way to configure “noindex” or other robots directives.
- No Open Graph image for social sharing.
- No control over Facebook-specific metadata.
- No Twitter/X Card configuration.
Canvas Page Metatag module fixes this by restoring access to existing fields, rather than bolting on a separate metadata system.
What fields does Canvas Page Metatag restore?
Nothing here is a new metadata UI. Every field the module exposes already belongs to the Metatag field type and already works elsewhere in Drupal. The module’s job is to restore #access on the fields Canvas’s form suppresses.
| Canvas out of the box |
With Canvas Page Metatag |
| SEO title only |
Full Basic Tags group |
| No description, abstract, or keywords |
Advanced group, including Robots and Referrer |
| No robots/indexing control |
Open Graph tags |
| No Open Graph metadata |
Facebook tags |
| No Facebook metadata |
Twitter Cards |
| No Twitter/X Cards |
Independent configuration for each group |
How do you configure which Metatag groups editors can see?
Administrators manage this from one settings page: /admin/config/search/canvas-page-metatag. All five groups are enabled by default.
This gives site owners a simple governance lever. A site that only wants Basic Tags and Open Graph, for example, can enable those two and leave Twitter Cards and the rest hidden from editors.
| Group |
Fields |
Why it matters |
| Basic Tags |
Description, abstract, keywords |
Gives editors direct control over the metadata search engines use most, instead of relying on the results snippet Google generates on its own. |
| Advanced |
Robots, referrer |
Lets teams keep staged, duplicate, or otherwise restricted Canvas pages out of search indexes without unpublishing them. |
| Open Graph |
Title, description, image |
Controls how Canvas pages appear when shared on Facebook, LinkedIn, and other Open Graph-aware platforms. |
| Facebook |
Facebook-specific tags |
Adds Facebook-specific metadata on top of the standard Open Graph configuration. |
| Twitter Cards |
Summary / large-image card |
Controls how Canvas page links appear when shared on X/Twitter. |
Why did Canvas page saves fail with the Robots field enabled, and how was it fixed?
Turning on the Advanced group surfaced a real incompatibility between Canvas’s React builder and Drupal’s Form API. It wasn’t an edge case: enabling the Robots field could make Canvas page saves fail outright.
Reproducing the bug
Metatag’s Robots field is a standard Drupal checkboxes element, with options like index, follow, noindex, nofollow, and other robots directives.
Canvas’s React UI submits every checked box using the generic boolean value 1, instead of the actual option key. When that value reaches Drupal core’s Checkboxes::valueCallback() uncorrected, it produces a corrupted value shaped like '1' => '1'. Drupal then rejects the submission during validation, with an error along the lines of “The submitted value 1 in the Robots element is not allowed.”
The fix
The module adds a small #after_build callback scoped specifically to the Robots field. Rather than trust the already-corrupted #value, the callback reconstructs which checkboxes were selected using $form_state->getUserInput().
The raw user input still holds the correct per-option keys. They’re just paired with the wrong submitted values. The callback uses that raw input to rebuild the expected checkbox structure before Drupal validates and saves the form.
Verifying the fix
The fix was checked against Canvas’s actual save path, ClientDataToEntityConverter::convert(), rather than a synthetic test double. Two behaviors were confirmed:
Without the fix, Canvas submission fails, and Robots validation rejects the submitted value. With the fix, the Canvas page saves successfully, and the exact combination of selected Robots options is preserved.
Does this affect other checkbox-based fields?
Possibly. The value-corruption pattern isn’t necessarily unique to Robots. Any other Metatag field built on a composite checkboxes element could hit the same Canvas/Form API mismatch. The fix here gives a pattern that can be generalized to those fields if the same issue turns up.
Why does this matter more on Canvas sites?
Page builders tend to trade some SEO depth for building speed. Drag-and-drop interfaces usually focus on layout and content, not the metadata depth available on traditional Drupal content types. Canvas follows that same pattern.
What’s notable here is that the Metatag field was already sitting on the Canvas page entity the whole time. Canvas’s form was just the thing standing in the way. Restoring access to it delivers three concrete benefits.
Search and social parity
A Canvas landing page can now carry the same metadata capabilities as a traditionally built Drupal page. Editors can set a specific meta description instead of relying on search-engine truncation, write a dedicated Open Graph title and description, choose a dedicated social-sharing image, and set explicit robots directives.
Editorial control without a ticket
Marketing and content teams can make SEO and social-sharing changes directly inside the Canvas editing experience. They no longer need to file a development request just to add or change a meta description, keep a page out of the index, swap a social-sharing image, or adjust Open Graph metadata.
One governance switch instead of multiple patches
One configuration page decides which metadata groups are available to Canvas editors, site-wide. The team responsible for SEO or content governance makes that call once, rather than handling it page by page.
How does Canvas Page Metatag work under the hood?
The implementation is intentionally small. It leans heavily on functionality Drupal and Metatag already provide.
How does the form alter hook work in Canvas Page Metatag?
CanvasPageMetatagFormHooks.php implements hook_form_canvas_page_form_alter(). The hook detects the Metatag field on the Canvas page form, checks which groups are enabled in configuration, restores #access for enabled groups, and keeps disabled groups hidden. It doesn’t build a replacement Metatag form.
How does the settings form work in Canvas Page Metatag?
SettingsForm.php provides the admin configuration interface. The five group settings live in canvas_page_metatag.settings, exposed through /admin/config/search/canvas-page-metatag.
How does Canvas Page Metatag render metadata?
The module doesn’t implement its own <head> rendering logic. Canvas pages are normal fieldable, routed Drupal entities, so Metatag’s existing rendering mechanism handles metadata output the same way it does everywhere else. That keeps the module lightweight and avoids duplicating what Metatag already does.
Technical summary
| Item |
Details |
| Module |
Canvas Page Metatag |
| Purpose |
Restore Metatag controls to Drupal Canvas pages |
| Configuration |
/admin/config/search/canvas-page-metatag |
| Configuration key |
canvas_page_metatag.settings |
| Form alter |
hook_form_canvas_page_form_alter() |
| Main form hook class |
CanvasPageMetatagFormHooks.php |
| Settings class |
SettingsForm.php |
| Robots fix |
#after_build callback |
| Rendering |
Native Metatag rendering |
| Module path |
web/modules/canvas_page_metatag |
How do you install and configure Canvas Page Metatag?
- Enable the module. Its declared dependencies pull in the Canvas and Metatag functionality it needs, including Metatag, Open Graph, Facebook, and Twitter Cards.
- Open the configuration page. Go to Configuration → Search and metadata → Canvas Page Metatag, or visit
/admin/config/search/canvas-page-metatag directly.
- Configure the groups. Choose which metadata groups Canvas editors should see. All five are on by default; turn off whichever don’t fit your site’s SEO or social-sharing strategy.
- Edit a Canvas page. Open any Canvas page for editing. The groups you enabled now show up as their own collapsible sections, alongside Canvas’s existing SEO title field.
The module requires: canvas, metatag, metatag_open_graph, metatag_facebook, metatag_twitter_cards.
Does this module change existing Metatag configuration?
No. Canvas Page Metatag doesn’t replace or interfere with standard Metatag configuration. Site-wide and per-content-type Metatag defaults are still managed from /admin/config/search/metatag, exactly as before. Canvas pages simply become reachable through the same Metatag system every other fieldable Drupal entity already uses.
Final thoughts
Drupal Canvas speeds up page building, but its default form leaves most of Metatag’s SEO and social controls out of reach. Canvas Page Metatag restores the full Basic Tags, Advanced, Open Graph, Facebook, and Twitter Card groups, and lets admins choose which of those five groups editors get to see.
Canvas handles the page. Metatag handles the metadata. This module connects the two, without asking editors to learn a second SEO system. Check out the module.
Canvas is still new, and gaps like this one tend to surface mid-project. If you would rather have a team close them for you, our Drupal development services cover custom module work, SEO configuration, and editorial UX. Talk to our Drupal experts about what you are building.
Frequently Asked Questions
What does the Canvas Page Metatag module do?
Canvas Page Metatag restores the Metatag fields that Drupal Canvas’s builder form hides by default, including meta description, robots directives, Open Graph, Facebook, and Twitter Card controls. It works by reinstating #access on fields that already exist on the Canvas page entity. No new metadata system gets added.
Why can’t I add a meta description to a Drupal Canvas page out of the box?
Canvas’s own edit form, CanvasPageForm::form(), hides nearly every Metatag field and exposes only a single SEO title box. The Metatag field itself is already present on the Canvas page entity; Canvas’s form just doesn’t grant access to most of it. Canvas Page Metatag restores that access.
Why does my Canvas page fail to save when I turn on the Robots field?
Canvas’s React UI submits every checked Robots checkbox as the generic value 1 instead of the actual option key, which Drupal’s Form API rejects during validation. Canvas Page Metatag fixes this with an #after_build callback that rebuilds the correct checkbox values from $form_state->getUserInput() before the form saves.
Does Canvas Page Metatag replace the Metatag module?
No. It depends on Metatag and simply exposes fields Metatag already provides on the Canvas page entity. Standard Metatag configuration at /admin/config/search/metatag, including site-wide and per-content-type defaults, stays untouched and continues to work exactly as it did before.
Which Drupal modules does Canvas Page Metatag require?
It requires five modules: canvas, metatag, metatag_open_graph, metatag_facebook, and metatag_twitter_cards. These are declared as dependencies, so enabling Canvas Page Metatag pulls in the Metatag functionality it needs to expose Open Graph, Facebook, and Twitter Card fields.
Can I control which Metatag fields Canvas editors are allowed to see?
Yes. A single settings page at /admin/config/search/canvas-page-metatag lets administrators enable or disable each of five Metatag groups, Basic Tags, Advanced, Open Graph, Facebook, and Twitter Cards, independently. All five are enabled by default.
Is the Robots checkbox bug specific to the Robots field, or could it affect other fields?
The #after_build fix in this module targets the Robots field specifically, but the underlying value-corruption issue isn’t necessarily unique to it. Any Metatag field built on a composite checkboxes element could hit the same Canvas/Form API mismatch, and the same fix pattern could be applied if that happens.
Where do I configure Canvas Page Metatag after installing it?
Go to Configuration → Search and metadata → Canvas Page Metatag in the Drupal admin UI, or visit /admin/config/search/canvas-page-metatag directly. From there, you choose which of the five Metatag groups appear on the Canvas page edit form.