Cannoncial link-tags deactivated => still there

Hi Jugibur,

Under “WP Admin > Settings > Reading,” do you have “Your homepage displays” set to “Your latest posts”? Thanks to your input, I verified a bug here and created an issue to resolve in the next minor update: https://github.com/sybrew/the-seo-framework/issues/665.

But if you set this to a static page, Polylang should urge you to create a homepage for each language. When done correctly, TSF should output unique canonical URLs for these pages.

Hi Sybre,

yes, I have selected a static page as the start page and PolyLang creates the necessary canonical URLs itself. That’s why I wanted to be able to completely disable this functionality in TSF.
Thanks for the update!

Hi again!

Could you share the URL of the page you’re encountering this with? This shouldn’t be happening and is unrelated to the bug we found earlier.

Of course! Here is the header code of the site with the urls incuded (first three are from PolyLang):

<link rel="alternate" href="https://albatros-international.eu/de/" hreflang="de" /> <link rel="alternate" href="https://albatros-international.eu/en/" hreflang="en" /> <link rel="alternate" href="https://albatros-international.eu/de/" hreflang="x-default" /> <!-- The SEO Framework by Sybre Waaijer --> <link rel="canonical" href="https://albatros-international.eu/" />

In the TSF settings these three checkboxes are *not* check marked:

Add rel link tags to posts and pages?
Add rel link tags to archives?
Add rel link tags to the homepage?

I have purged the complete cache of the LiteSpeed plugin multiple times.

• This reply was modified 9 months, 2 weeks ago by jugibur.

Hello!

I understand now. Yes, you are still facing an issue, not with the rel tags, but with the canonical URLs, and I’ll inspect today why this is happening.

I also believe there’s a misunderstanding about the settings, and I’ll have that addressed, too. Thank you for your feedback on this.

To rectify the misunderstanding, please allow me to explain:

The rel="alternate" tags are outputted by Polylang, and those are required to tell search engines about alternative language versions of your site. I recommend keeping those. See https://developers.google.com/search/docs/specialty/international/localized-versions.

Those rel link tags settings of The SEO Framework apply only to rel="next", rel="prev". I see I should describe that better, perhaps only the title needs to change from “Link Relationship Settings” to “Paginated Link Relationship Settings.”

Lastly, you cannot disable rel="canonical" in TSF; it’s the most important tag of all. If it’s wrong, as it is in your case, something must be addressed, but the solution isn’t removing it — that would be the same as not using an SEO plugin at all.

Thanks for your explanations, Sybre!

In addition, here is the error message from Google PageSpeed Insights (translated to en):

?Document does not contain a valid rel=canonical element.
Points to the root URL (the start page) of the domain instead of an identical content page.“

Does this mean that the cannonical url generated by TSF should point to the actual start page, in my case with /de at the end?

And do I understand correctly that the canonical url of TSF in principle is only necessary if there are two pages with basically the same content? Even if they are written in two languages?

Thanks!

Hi Jugibur,

About the first point, that’s correct: TSF should point to the homepage with /de/ if the /de/ endpoint is requested, but it doesn’t with Polylang, and this must be resolved. I know how to fix this, but we require a compatibility change in Polylang to make this feasible. For the nerdy details, see https://github.com/polylang/polylang/issues/1422. Practically, its home_url() augmentation assumes everything is incompatible, so every plugin needs to register its compatibility (backward thinking…). However, Polylang allows this compatibility registration too late. We haven’t got this issue with WPML; everything “just works.”

And about the second point, yes: The canonical URL is only required when search engines land on the wrong page. However, we cannot accurately determine if the URL crawled is the intended URL. This concerns how PHP doesn’t restrict writing to global variables at runtime, so we take the best URL WordPress can give from its Rewrite API, clean it up, and output that. Whether we’re on the correct page or not. This should always work unless the URL is not registered with WordPress (looking at all LMS plugins…) or, in the case of Polylang, when we’re not given the correct URL due to a compatibility filter block.

Hi Jugibur,

TSF v5.0.5 resolved all the issues mentioned above. I’m sorry it took so long; Polylang’s authors are unwilling to acknowledge a bug in their software, so we hijacked their plugin to implement the proposed fix.

Thanks Sybre or your effort! It’s a shame that the PolyLang developers got in the way, but it’s great that you were able to fix it anyway!