[META] Track 12: Proposal for SEO recipe

Having a single SEO recipe is misleading. SEO, like Accessibilty needs to be baked into all recipes that contain content structure.

Could we change this idea to be a "Sitewide SEO" recipe for clarity? We could then concentrate on items that could be set globally (think an XML Sitemap, HTML Sitemap, Performance settings, etc). That could also define the SEO best practices for content type recipes (Must have Metatag defaults, Schema.org Metatag defaults, etc)

Sure, the sitewide config is definitely the intention (e.g. XML sitemap, meta tags etc) so happy to change it for clarity.

In addition to a list of things we can do, we will need to define what should be always there (in the base recipe) vs what might be better as an opt-in (maybe there is nothing because it all should be there by default, I'm not sure).

This track is in need of a lead. See Dries' blog post for more info, read about the track lead position → , or just apply now!

Note that the xmlsitemap module itself has a lot of performance issues, and momentum seems to be moving to https://www.drupal.org/project/simple_sitemap → instead.

Simple sitemap has 120k modern Drupal installs, vs 60k for xmlsitemap.

I haven't used either module recently, but posting this based on discussions with multiple people who have.

In our preconfigured CMS we use the following contrib modules for SEO:

• https://www.drupal.org/project/schema_metatag →
• https://www.drupal.org/project/metatag →
• https://www.drupal.org/project/simple_sitemap →

We have the following modules enabled and configured out-of-the-box to go with the entity types we provide:

• drupal/metatag_dc
• drupal/metatag_dc
• drupal/metatag_open_graph
• drupal/metatag_views
• drupal/schema_metatag
• drupal/schema_article
• drupal/schema_organization
• drupal/simple_sitemap

Apart from providing information to search engine large parts are about the performance of the site in general.

This includes

• forcing editors to provide sensible data (like real alternative texts for images) for all content created,
• providing accessible HTML for screen readers,
• minimal HTML, CSS, JS for performance,

and much more.

For the above there are no modules you can install, but it is a mixture of good configuration of the editorial UIs and solid frontend engineering.

For accessibility we provide editors with the nice module https://www.drupal.org/project/editoria11y → .

Thank you @breidert!

I have applied to lead this track.

Hi,

Here are my thoughts about SEO in Drupal. As a background, I have been building Drupal websites for more than 15 years, and I'm SEO-certified in my country, regularly taking about that in Drupalcamps.

The only mandatory modules are Pathauto & Metatag. Metatag default configuration is ok, but pathauto needs a dedicated rule for content, at least something like [menu-link:parents:join-path]/[node:title] just so that the breadcrumbs follows the menu hierarchy. And for me, at least Pathauto should be included in core, because that's what other CMS do, but that's another issue entirely ;-)

Apart from that, Redirect is really nice to have, especially with the default configuration where a path (with pathauto) can change when the title of a content changes: that way, a redirect is automatically created, and even with user errors, the history SEO is kept.

All other modules are just depending on the strategy the website will have, and we shouldn't impose anything. That said, people will often looks for Robotstxt (possibly only for factories with lots of website on the same core), Simple Sitemap (smaller websites should not need that at all), Sitemap (in that case, we need the multilingual patches to be there as well), and Metatag Schemaorg (this one could be preconfigured for specific recipes like events, products, things that will have impact on search results). All these modules could be included or suggested in the recipe, but they shouldn't be enabled by default, this will just clutter the UI and enabling them could even be counter-productive if the users do not know how to configure them or use them.

Even Metatag Opengraph is now sometimes useless considering Google+ has shut down, a lot of people are leaving Facebook & X (Twitter) has said they don't always respect it. Basically, both Facebook & X will try to find a suitable picture themselves. So I don't know if we should have it enabled by default or not, especially considering this one needs configuration, while default Metatag core configuration works out of the box.

As I said in the survey earlier today, I am also quite happy with the Metatag module, maybe with a overhauled UX. Even with Starshot, SEO will be outsourced to SEO pros, who might be happy to have some "advanced" tab and a good redirection function.

BTW, In conversations with customers, I prefer the term "machine readable" instead of SEO. It is kind of a broader approach:-)

Assigning to track lead (co-lead with @_doyle_, picked first one alphabetically)

IMHO we're missing a trick by not using Schema Blueprints to automatically create data structures based upon schema.org's datatypes, and then auto-generating on-page microdata from the structures.

IMHO we're missing a trick by not using Schema Blueprints to automatically create data structures based upon schema.org's datatypes, and then auto-generating on-page microdata from the structures.

Thanks for your input Damien, it is always welcome, especially in this realm!

This track is for sitewide SEO. I am going to make recommendations to the track leads who are responsible for content types, but ultimately, the data structure is out of my control. I will ping @pameeela who is responsible for the base recipe to your comment here to review.

Schema Blueprints → received 3 mentions in our SEO Track survey, less than the 9 for the Schema.org Metatag. It also only has a little over 200 uses and only an alpha release.

I experimented briefly with the Schema Blueprints and unfortunately, my team found it complicated to use. The added entity layers seemed redundant and more complex compared to the solution the schema_metatag → module offers to gain the same end result. Why do you feel like it is needed?

I'm a big fan of Schema Blueprints, but I feel it's a little too opinionated for a generic recipe, which is not what we have been used to by Drupal. I would be very happy if we come to it one day, but it may be too early for that ;-)

I agree that the Schema Blueprints functionality, although very cool, feels a bit complicated for our target user. I think we should instead ensure that the shipped content type recipes provide the appropriate metadata.

Hi Team,

Thank you for that initiative!

We've been working on a SEO recipe as part of a company project. We created one with the idea that it will be reused in other websites, so what we've built is content type-agnostic set up.

Please find the implementation here

Here's the list of features that it provides:

• Metatags: basic and advanvced
• Schema.org
• URL alisases
• Redirects
• Robots.txt
• XML Sitemaps

The idea is that the SEO recipe will be applied prior to having any data model definition, so all of the above features come with a pre-defined configurations that are content type-agnostic.

If you think that might be useful for the Drupal CMS initiative, I am happy to move those features in the core SEO recipe

Hi @nikolabintev!

Nice recipe. It has similarities between what we have committed to Drupal CMS already.

We have a Basic SEO recipe that is applied by the base recipe:
https://git.drupalcode.org/project/drupal_cms/-/tree/0.x/drupal_cms_seo_...

And an Advanced SEO recipe that is meant to be installed after any content types are added:
https://git.drupalcode.org/project/drupal_cms/-/tree/0.x/drupal_cms_seo_...

A few notes about your recipe.
1. You don't need to copy and paste module config into your recipe's config folder. You can use config:import to import configs right from the modules. If you want to change any of those values, you can use config:actions.
2. Simple configuration is always imported from modules. You only need to import config entities. In your recipe you have

config:
  import:
    pathauto:
      - pathauto.settings
      - pathauto.pattern.content
      - pathauto.pattern.taxonomy_term
      - pathauto.pattern.user

Simple Config:
pathauto.settings

Config entities:

      - pathauto.pattern.content
      - pathauto.pattern.taxonomy_term
      - pathauto.pattern.user

You don't need to import pathauto.settings, metatag.settings, redirect.settings, simple_sitemap.settings.

3. On most of the modules, since you are importing all of the config you could use the * wildcard to bring in all.

config:
  import:
    metatag: '*'

4. Redirect module. You are not enabling the redirect_404 module, nor importing the views or action the module provides.

See https://git.drupalcode.org/project/drupal_cms/-/blob/0.x/drupal_cms_seo_... for reference

config:
  import:
    redirect:
    # Excludes optional language config: language.content_settings.redirect.redirect.yml.
    # If Drupal CMS is going to have translation on by default, change this to import all of redirect's config.
      - system.action.redirect_delete_action
      - views.view.redirect
    redirect_404: '*'

And later, we use config actions to remove 404s from the dblog since they are saved by Redirect 404.

config:
  actions:
    redirect_404.settings:
      simpleConfigUpdate:
        suppress_404: true

Thanks for sharing your recipe with us and your organization! Keep up the great work!

Hi @thejimbirch,

Thank you for the extensive feedback! It is much appreciated. I will adjust my recipe based on your recommendation. What I was missing is the advanced SEO schema, however, I have some comments on it. Is it a good idea to have the following modules included:

• dashboard
• field_group
• focal_point
• layout_builder
• shortcut
• tour

I'd categorize them editorial-related rather than SEO-related. Shouldn't they be moved in a separate recipe?

Great question! Thanks for asking.

The modules you list are definitely editorial in nature. However, they are dependencies of config entities I have added in the recipe. If a config file a recipe has in the /config folder has a dependency, it needs to be listed in the recipe.

Now I am just ensuring the module is enabled. Note that on the Tour module for example, I am not importing all of the Tours that exist in that module as config entities. That would be better for another recipe to do. I am just ensuring the module is enabled so my Tour can be used.

I will explain the dependency for each module:

dashboard, layout builder

This recipe creates an SEO dashboard that brings together links to all of the SEO tools. Layout builder is a dependency of dashboard.

field_group

This recipe adds 3 fields to any content type that exists at the time of application, and wraps them on the edit form in a field set provided by field_group.

focal_point

This recipe creates two image presets that are used in meta tags. Focal point scale and crop is used in those images.

shortcut

This recipe creates a shortcut content entity, a shortcut link to the SEO dashboard.

tour

This recipe create a tour for the SEO dashboard.

Part of the goal of our track was to make SEO easier in Drupal. By providing a better editorial experience aim to achieve that.