The-seo-framework: Canonical & sitemap links point to wrong domain on a (multilingual) multi-domain site

[tnottu]

I have a multilingual site (using Polylang Pro) and each language has its own domain. For example:

| Language | domain |
| ---------|------------ |
| Finnish | example.fi |
| English | example.com |
| German | example.de |

The English and German canonical links and locations in sitemap.xml are now all incorrectly pointing to the default language domain, which in this case is Finnish. For example:

// Incorrect: English URL with .fi domain
https://example.fi/references/
// Correct: English URL with .com domain
https://example.com/references/

Probably because the get_home_host in Generate_Url class uses get_option( 'home' ) to get the host and that will return the home_url for the default language.

I'm not entirely sure if this is something that could be fixed in Polylang or The SEO Framework, but this seemed to be a more probable place to ask first.

Is there currently a way to modify the url host? If not, would it be possible to add a filter to the_url in Generate_Url class, or some other appropriate place?

[sybrew]

Related: https://github.com/sybrew/the-seo-framework/issues/69

[sybrew]

The issue is that Polylang determines the language through session cookies, this is something that Google can't work with regarding the sitemap output.

The only workaround would be to implement the related issue (69).

[sybrew]

Also keep this quote in mind:

Note that WPML and most other translation plugins [including Polylang] already correctly take care of this outside of the sitemap's scope, either through meta tags or HTTP headers.

Essentially, this means that the current sitemap's state shouldn't cause any issues for indexing or crawling.
In fact, Search Engines don't even require a sitemap to crawl your website. The sitemap is merely a tool to help Search Engines find new and updated pages.

[tnottu]

Thanks for replying so quickly!

The issue is that Polylang determines the language through session cookies, this is something that Google can't work with regarding the sitemap output.

I'm not entirely sure about this, but I don't think Polylang necessarily needs to use a cookie. As far as I know, WPML is more depended on it. In my case the language is determined from the domain anyway.

Essentially, this means that the current sitemap's state shouldn't cause any issues for indexing or crawling.
In fact, Search Engines don't even require a sitemap to crawl your website. The sitemap is merely a tool to help Search Engines find new pages.

Yeah, the sitemap isn't super important.

But currently the meta tags from The SEO Framework are also incorrect. For example:

// English pages with Finnish domain :(
<link rel="canonical" href="https://example.fi/references/" />
<meta property="og:url" content="https://example.fi/references/" />

Those are created by The SEO Framework, right? I think Polylang creates just the rel="alternate" meta tags (correctly).

This causes the links in Facebook shares to point to wrong domain for example. The URL is redirected to the correct permalink when user navigates to it, but I think it's still a bit bad thing to share/promote an URL with wrong domain to the target audiences in different countries.

Would that be something worth creating a new filter (or some other solution) for? Or is that merely a cosmetic thing not worth modifying? :) If there would be some filter when creating the_url, I could use some Polylang functions in the callback to determine the posts' language and return the correct domain for it.

I suppose anytime and anywhere this plugin calls get_option( 'home' ) it will be an incorrect URL for this multi-domain setup...

[sybrew]

This causes the links in Facebook shares to point to wrong domain for example. The URL is redirected to the correct permalink when user navigates to it, but I think it's still a bit bad thing to share/promote an URL with wrong domain to the target audiences in different countries.

That's a bug then 😮.

I suppose anytime and anywhere this plugin calls get_option( 'home' ) it will be an incorrect URL for this multi-domain setup...

Yes, it should be get_home_url(). But it was left out on some places to improve performance (especially in the sitemap). Now, we do cache it entirely in a method, so it shouldn't be an issue to use it.

Could you tell me the settings of your Polylang installation? Alternatively, send me screenshots confidentially over here.

[tnottu]

I sent a screenshot of the Polylang settings via the contact form. Though I now after I sent it, I realized that I probably shoud have included all the settings, not just the URL modifications part. Well, I suppose the other settings shouldn't matter much in this case. Except maybe for Detect browser language but that was disabled anyway. Let me know if you'd like some more info.

[sybrew]

The settings you sent were sufficient, cheers! 😄 I'll get on it ASAP.

[sybrew]

Hi @tnottu

I just tested it out with the free version, and all works fine! 😮 (aside from the admin placeholder URLs)

Are you using Translate Slugs (a pro feature)? If so, does disabling that extension make the URLs correct again?
If that's the case, I'll need to contact the plugin authors of PolyLang.

Cheers!

[tnottu]

Heya! Thanks for the info. Yes, I am indeed using the Translate Slugs -feature. I'll try disabling it when I get back to work next week.

[sybrew]

Hi @tnottu

I just implemented get_home_url(), and tested it will all plugins that want to rewrite URLs. It seems to work on everything, and it might just resolve your issue 😄

Is it possible for you to let me know before the end of the weekend? Or are you tied to working hours?

Thanks!

[tnottu]

Hi,

Sorry I didn't respond earlier. We had a national holiday, so I wasn't on the computer much. But now I'm back at work.

About the Polylang Translate Slugs -feature: That feature can't actually be disabled. Not from the admin at least. So, I don't know how to test without this feature at the moment...

I tried the new dev-version but the problem still exists :(

[sybrew]

@tnottu Thanks for checking! I'll contact the Polylang authors 😄

Edit: Hmm... I might be able to fix this internally 👍
Edit2: I was able to replicate this issue. Stay tuned!

[sybrew]

Hi @tnottu

Could you test the latest patch? 😄

Direct download:
https://github.com/sybrew/the-seo-framework/archive/4738ef25a61a1d4dc883fd2039a6066616d52b4b.zip

Note that the plugin's normally stored at /wp-plugins/autodescription/.

Thank you so much!

[tnottu]

This patch works! All the URLs (canonical, og:url, sitemap.xml) are showing the correct domain now :)

Except... On a Custom Post Archive page (e.g. example.com/references/) it still shows the incorrect domain for the canonical and og:url. Oddly, in the sitemap.xml the Archive URL is correct. On the single CPT pages the URL is correct also (e.g. example.com/references/some-project/). Any thoughts?

[sybrew]

Hi @tnottu

I believe it should now all work 👍

Another fresh copy:
https://github.com/sybrew/the-seo-framework/archive/956cb353603f014bd079ed3d68962e1bb7f8aa82.zip

Could you also test the alternative languages /sitemap.xml and /robots.txt output?

To be sure it's a fresh copy, temporarily disable the sitemap transient caching (setting is found under SEO -> General -> Performance).

Cheers!

[tnottu]

Yes, now all the links for all languages work in rel="canonical", og:url, robots.txt and sitemap.xml 👍 Thank you!

As a final detail I noticed that the Social Image Fallback still shows the default domain. Seems that the image URL is saved as an absolute URL with the default domain and not manipulated for output. (I only noticed this now because this site was made before your plugin had a setting for default og:image and I had some custom code doing that previously.)

[sybrew]

Seems that the image URL is saved as an absolute URL with the default domain and not manipulated for output.

That's true.

More specifically, it saves it in 2 parts: the input URL and the image ID (hidden field).

Notice it also won't output the sizes if the domain mismatches — that's because of an AJAX fail-safe implementation; as we can't be 100% certain that the ID field will be filled in correctly (although, it actually always does). The ID can create the domain-matching image URL, which as I understand you might prefer. But, that's an enhancement for the future 😄