Add Self-Referencing Canonicals?

[RVXD]

The MetaComponents method only adds a canonical if it is a VirtualPage.
Google Recommends to Always Use Self-Referencing Canonicals.
https://hallanalysis.com/2017/07/14/google-recommends-always-use-self-referencing-canonicals/
Would it be better to add it to every page as a Self-Referencing Canonical?

[lerni]

Wouldn't this result in relative URLs since SS doesn't know the "canonical domain"? I have doubts if relative canonical-links are valuable. There are modules available handling this.

[michalkleiner]

The CMS should know its canonical domain, it's what it uses when creating the final URL in Director::absoluteURL('some/relative/or/absolute/path').

[lerni]

@michalkleiner AFAIK it does not necessarily know it unambiguously. If multiple domains are living on same vhost without redirection to one single canonical domain, which domain should Director take? If it just takes the current one, it could result in canonical-links with different domains, which is bad and I think it’s against the intention of a canonical link-tag - at least in terms of SEO, but this is why people adding a cannonical-meta-tag after all.

[michalkleiner]

It takes the same one as it uses to produce the absolute URLs. If there's multiple domains without redirection, and no alternate_base_url or custom base provided to the absoluteURL call, then it will likely default to the current one, which would not create canonical to a different domain. I think there's no issue here and the self-referencing tag could be added.

[lerni]

It means for the same Page the canonical link could be different, depending on the domain it is accessed. Search engines 'll likely treat this as duplicate content. But isn't a canonical tag there, to prevent exactly this? If vhost is configured with domainAAA.com & domainBBB.com etc., each variant 'll have a different canonical link, given no alternate_base_url is provided or caught with a single domain redirection. alternate_base_url could be used as canonical domain, but it also means, it'll have a slightly new purpose - if I got it all right, it 'll become the setting for canonical domain.

[michalkleiner]

I'm working on the assumption that one content shouldn't be presented on two or more domains/URLs. If it is on, it is likely treated as duplicate content already, so it needs a redirection, or the canonical domain to be set somehow. IMHO it's not a concern for the link canonical tag.

[muskie9]

2 cents here, but would the vhost issue be outside of the params of this module (or I presume that's something the module could not/should not account for). If the framework is picking up an alternate vhost domain the canonical could be the least of the worries. I could be thinking about this incorrectly, but running a Silverstripe installation for any given domain I would expect any execution to persist the proper domain (within expected env/config params), otherwise wouldn't other areas have issues as well? Again, I may not be thinking about this correctly.

[muskie9]

I do think there is a need for this feature however. There are instances where you may have a form/filter on a page for a list of some kind. An out of the box canonical reduces the work to remember to add one for result actions/pages. It's not a terribly difficult thing to do, but if you have new devs working on a project, it's nice to have that taken care of (and it can be manipulated by an extension if need be).

[kinglozzer]

Yeah IMO if the exact same content is accessible on multiple domains, that’s a server configuration issue. FWIW we currently already add this ourselves in an extension, but it’s worth bearing in mind that this approach does have issues when you introduce pagination or the “dataobjects-as-pages” approach so we’d need to be careful with the implementation so we don’t introduce SEO issues for people upgrading

[lerni]

I agree the exact same content should ideally just have one single URL and with a multi-domain setup, best option is to handle redirection on webserver level. But this isn't always the case - for example, many standard setups come with and without www prefix/subdomains and in reality there are unfortunately circumstances for multiple domains. This is exactly where the canonical tag comes in and if set, it has to be ensured there is just one "canonical" version of it on all variants - otherwise it's better to omit it, since it then would add wrong information on top of "duplicated content".

• Wiki says, it helps webmasters prevent duplicate content
• moz.com states it a way of telling search engines that a specific URL represents the master copy of a page
• Google lists reasons like "To consolidate link signals for similar or duplicate pages"

In my view it just should be added, if a canonical domain can be assured (defined per alternate_base_url?) but not be set on "optimistic assumptions" on domain or protocol level.