In this article I am going to show you a neat little trick by which we can override the static metatags of a given View with those that come from a potential dynamic filter.

Imagine the following: you have a View that lists Article nodes. And these nodes can be tagged with terms from the Tags vocabulary. Moreover, this View has an exposed filter on these tags so the user can filter by them. The end URLs look something like this:

• https://example.com/articles
• https://example.com/articles?tag=1

Using the Metatag module, you configured the View to have a title, description and whatever else you needed. However, when filtering the View, the resulting page would benefit from more specific metatags, potentially coming from the tags right? For example, the title to no longer be Articles (which makes sense when you list all of them), but instead, be Articles tagged with #Tag. Makes sense right? Or News from Africa. You get the point and I had a similar need.

My solution for this problem was to alter the metatags of the View and defer to the metatags of the Tags taxonomy terms if there was a filter applied. So how did I do this?

All I had to do is implement hook_metatag_route_entity() and tell the Metatag module to look at another entity when trying to determine the metatags of a given route. So something like this:

/**
 * Implements hook_metatag_route_entity().
 */
function module_name_metatag_route_entity(\Drupal\Core\Routing\RouteMatchInterface $route_match) {
  $route = $route_match->getRouteName();
  if ($route !== 'view.articles.display_machine_name') {
    return;
  }

  $tag_id = \Drupal::request()->query->get('tag');
  if (!$tag_id) {
    return;
  }
  $term = Term::load($tag_id);
  if ($term instanceof TermInterface && $term->bundle() === 'tags') {
    return $term;
  }
}

And that’s it. This hook is invoked when Metatag tries to determine the entity to use on a given route when generating the metatags. So all I had to do is check that the route is in fact that of my View and that I have a tag ID in the URL query (the View was being filtered). If so, I loaded the taxonomy term and returned it. Metatag did the rest.

Do note that depending on your module name, you’ll need to alter the order of the implementations of this hook to run before that of Metatag Views in order to take effect.

With this in place, the metatags on the View are now being inherited from the Tags taxonomy terms if there is an exposed filter applied on the View with the machine name tag. Otherwise, it isn’t doing anything and the metatags of the View are being used as expected.

Finally, in order for this solution to be useful, there is a critical assumption: the Tags taxonomy terms don’t really need/have a detail page and are only used to tag Articles in this context. Of course, this is quite unlikely but this example can be applied also with much more specific taxonomy vocabularies which are created with a single purpose in mind: to categorise one type of content and maybe act as a filter on a View.

Hope this helps.