Remove redundant HTTP headers for canonical and short_link tags

Thanks for the patch sabina.h

So before the patch we have

if (isset($item[0]['#attributes']['href'])) {
    if (in_array($item[1], ['canonical_url', 'shortlink'])) { ... }
}

And with this patch it becomes

if (isset($item[0]['#attributes']['href']) && $item[1] === 'shortlink') { ... }

Which is the same logic, except that now canonical_url is excluded and only the shortlink is added in the by the metatag module.
So that looks good.

The effect is:
Before the patch this is added by metatag in HTTP-header:
<https://www.example.com>; rel="canonical", <https://www.example.com>; rel="shortlink"
After:
<https://www.example.com>; rel="shortlink"

We must also update the comment in the code.

      // Also add a HTTP header "Link:" for canonical URLs and shortlinks.
      // See HtmlResponseAttachmentsProcessor::processHtmlHeadLink() for the
      // implementation of the functionality in core.

to

  // Also add a HTTP header "Link:" for shortlinks.
  // See HtmlResponseAttachmentsProcessor::processHtmlHeadLink() for the
  // implementation of the functionality in core.

In the project I am checking this we got feedback from the SEO-people that we must remove canonical_url from the http-header.
What I am wondering... is this a new SEO practise? Because it was deliberately added to the http-header before.

Needs work for:
- Comment that must be updated

What's the rationale for doing this?

> What's the rationale for doing this?
Honestly I followed a directive from a client's seo advisory, without questioning why it's needed. So I can't answer this 🤷‍♂️

The only scenario I can see it being a problem is if the values were different, but given that they use the same string I don't see it being a problem. You might push back to the client's SEO consultants to explain why it's a problem. Especially when they didn't think there was a problem with "shortlink" too.

Will do. If we get an answer I'll post it here.
+1 for status Postponed

Update

Our SEO consultant answered:

As for the 'why' question: it is more error prone to have 2 canonical tags in different places. In addition, it is not necessary, only 1 self referencing canonical tag is sufficient.

It is true that as long as they both point to the same URL, there is no problem per se. But keep in mind that if they don't both point to the same URL at some point, Google may completely ignore the canonical instructions.

FYI we decided to remove this patch from our website.

Thanks DamienMcKenna

Thanks for the response. Given that the canonical plugin's value is used to determine both the meta tag and the HTTP string, I don't see any problem with how this currently works.

👌

#8

The only scenario I can see it being a problem is if the values were different, but given that they use the same string I don't see it being a problem.

Sorry to reopen this closed issue, but a large amount of response headers can be a real problem. See #2873648: With many languages, content_translation_page_attachments adds too many alternate links to the response headers crashing varnish (503) for an example.

The HTTP Link entity-header field provides a means for serializing one or more links in HTTP headers. It is semantically equivalent to the HTML
element.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Link

The first bytes in a response are important from a performance perspective. If Link response headers are semantically equivalent to the HTML <link> element, why should these links be available in both the response headers and HTML <link> elements?

Attached patch from the links from the response headers.

Sounds reasonable, thank you.

Committed. Thank you.