Allow content created in Experience Builder to be used in meta tags and schema.org vocabularies

Created on 5 November 2024, about 1 month ago

Overview

In an Experience Builder slack meeting I asked if data created from within the experience builder should be available above just the presentation of the data on the page.

The underlying issue is the same with paragraphs and/or blocks in a layout, that the structured data of a particular page builder built page is not available at the node level to use as meta data for that node.

Some scenarios for search engine optimization (SEO) I can immediately see being an issue are:

1. A summary of the content of the page that could be used in description meta tags and schema vocabularies. When we just had a body field, the node:summary token was great. Once we componentized, it got a lot harder.

2. Images that are representative of the page. Used in social meta tags and schema.org vocabularies.

3. Schema.org vocabulary markup for individual components. This could be done inline in the component’s markup or bubbles up the the page. Breadcrumbs, Frequently Asked Questions. Search boxes, and other parts of the page can have their own schema markup.

Proposed resolution

In the past, Drupal has relied on the Token module to bubble up content pieces that can be used in meta tags, schema.org vocabularies, and pathauto patterns. That may be possible with Experience Builder (XB) and a ticket has been created for that: πŸ“Œ Investigate possible token syntax and support for XB data Active .

But there may be other solutions not yet created as XB is a new approach so I am opening this ticket as a feature request.

User interface changes

TBD

✨ Feature request
Status

Active

Version

0.0

Component

Page builder

Created by

πŸ‡ΊπŸ‡ΈUnited States thejimbirch Cape Cod, Massachusetts

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @thejimbirch
  • πŸ‡ΊπŸ‡ΈUnited States thejimbirch Cape Cod, Massachusetts
  • πŸ‡¬πŸ‡§United Kingdom longwave UK

    Someone can correct me if I'm wrong but I think the idea for handling this in XB is to do it the other way round, at least in some cases. For example for a summary text field or a specific image, you would add a field to the content type, and then map that field into an XB component via the UI, which would then also easily allow you to map the same field into the metatags. This should at least work for points 1 and 2, but not sure about 3.

  • πŸ‡¬πŸ‡§United Kingdom catch

    #3 is more about microdata for everything on the page.

    Let's say you have a movie content type, and then you have a reviews component. How would you be able to apply schema tags to the author , rating and publication for the review. That sort of thing?

    I think it is fundamentally the same underlying architectural discussion as 🌱 [META] Support alternative renderings of prop data added for the 'full' view mode such as for search indexing or newsletters Active and πŸ“Œ Refactor the XB field type to be multi-valued, to de-jsonify the tree, and to reference the field_union type of the prop values Active - e.g. if the components are populated by a field union, then the field union becomes a 'thing' which other code can reference using existing field API concepts, maybe a bit of new integration, to pull out that data into the JSON schema in modules like https://www.drupal.org/project/schema_metatag β†’ . It's not about view modes, but the overall need is similar. But if it's not possible to do it that way, how do you externally access that data outside of XB?

  • πŸ‡§πŸ‡ͺBelgium wim leers Ghent πŸ‡§πŸ‡ͺπŸ‡ͺπŸ‡Ί

    #3++

    But I think @catch in #4 is getting at "so then how can we consistently target the place in the XB component tree where that structured data is going to be presented" β€” is that right?

    That's how I interpret this:

    Let's say you have a movie content type, and then you have a reviews component. How would you be able to apply schema tags to the author , rating and publication for the review. That sort of thing?

    If so, the answer to that is IMHO 🌱 [later phase] [META] 7. Content type templates β€” aka "default layouts" β€” affects the tree+props data model Active . Which sadly is not being designed yet (which concerns me), and is not slated until after 🌱 Milestone 0.2.0: Experience Builder-rendered nodes Active .

  • πŸ‡¬πŸ‡§United Kingdom catch

    @Wim hmm I didn't think that's what I'm saying or maybe I'm misunderstanding your comment.

    I haven't really worked with JSON-LD , but:

    RDF - you had to add little snippets of RDF markup inline with the HTML for each thing you wanted to mark up (this is how we ended up with title_attributes and various template variables from Drupal 7 onwards.

    JSON-LD - you put all the schema.org data in a big json blob in a single meta tag.

    So it's more like:

    'given an XB-enabled content type, how I can configure which metadata applies to which component slot and then also extract the props so that I can put them into a JSON-LD array alongside the 'regular' entity fields?' - something like that.

Production build 0.71.5 2024