That's good to know. Thanks for the update Shawn.

Since the initial discussion took place several Google reps. have publicly stated that there is no PageRank loss between redirects and rel ="canonical" tags. This seems to substantiate their claim.

The biggest issue with these is when giving conflicting instructions to user agents, such as a redirect to a page that rel canonicals back to the URL from which it was redirected, thus closing an infinite loop. For example, if you redirected from HTTP to HTTPS, but then the HTTPS version had a rel ="canonical" tag that was hard-coded to the HTTP version.

The above issue doesn't apply because you're redirecting from HTTP to HTTPs, which shows a relative path rel canonical tag for the HTTPs domain.

I'll mark this as answered and will head over to the newer thread.

Fabrizo,

It was a good point for you to bring up. The truth is, I don't know what Google's stance is on stuff like this these days because they constantly change it and you can read opposing things straight from Google in two or more different places. Also, I don't think Google cares about the user as much as they say when it comes to our sites because they make it difficult for us to rank well while also providing rich JS-based, interactive experiences. So thinking of the users on a big affiliate site, the best UX would be to show them the domain they're about to visit (e.g. Amazon.com) but Google doesn't like sites monetized this way (it seems) so we have to obfuscate what we're doing, which is B.S. since obviously the users like the site or they wouldn't be using it. This is all about Googlebot not keeping up with web dev technology. Maybe they should spend less time on self-driving cars and VR goggles and more time on that.

Personally, I would not have a bunch of href links on my site pointing to an internal folder that is blocked in the robots.txt file. I "may" use javascript links and then obfuscate the javascript somehow, but Googlebot doesn't like when you keep it from rendering JS and you'll start to see errors come up in GSC and elsewhere that you're blocking content from being rendered. Does that impact rankings? Hard to tell.

Hello Localwork,

By "product attributes" do you mean URLs associated with product variants, like color and size? From the context of your question, I'll assume for now you mean that each product attribute / variant appears on it's own URL (e.g. /?color=red and /?color=blue) and you want to know whether these should be included in the sitemap.

As Andy mentions below, more information is needed before prescribing a best practice specifically to your situation. However, in this case you should probably only have the one "canonical" version of the product URL (e.g. without variants). There are many ways to handle this and I recommend Googling "SEO for product variants" to familiarize yourself with the pros and cons of each.

To answer your question about sitemap segmentation, yes it is a good thing to do for several reasons, most important of which is easier diagnoses of crawl issues, such as which "sections" of your sites have indexation problems. It also helps on large sites with issues reaching URL limits in sitemaps, and is a more logical tree-like structure for people and machines to follow than having every URL in one sitemap.

Hello Benjamin,

This is an interesting problem. I'm going to provide my opinion, but I highly recommend studying up on International SEO, which you can do at the links below:
https://cloudz.click/learn/seo/international-seo
http://www.aleydasolis.com/en/

I don't know what the plugin does, but if it generates a new URL (e.g. adds ?loc=ca or something like that) for the location change you'll want to use rel="alternate" hreflang="*" tags, which would look something like this:

Google recommends putting one language per page, so that would be a different URL for each version, as highlighted in red here.

**However, it sounds to me like all of this is done client-side using JavaScript, and that the URL doesn't change, only the content.** If this is the case - as long as you are serving the same content to Googlebot crawling in Canada as you are to a visitor in Canada you probably won't have any issues, as described here: https://webmasters.googleblog.com/2008/06/how-google-defines-ip-delivery.html .

For the situation you described, it seems like you could put both keyword variations in the content and that would be good enough. But then you don't want to spell specialising with an S in one line and specializing with a z in the next.

Another thing to look into is whether both versions of the content appear in the code, or just one or the other. You definitely don't want to have multiple versions of the content in the source code. But you also don't want to hide both versions via JavaScript, only to load one or the other client-side. That creates even more problems.

One would think there would be a Vary: Location response header, similar to how responses are provided when content varies by user-agent or cookie: https://www.fastly.com/blog/best-practices-for-using-the-vary-header . Alas, I can't find any use cases of this and it's not a "thing". I'm not sure why this is, but maybe an International SEO Expert like Alayda Solis would know. I'll ping her into the thread if she has time.

Fabrizo,

I was suggesting going through an intermediate domain, as opposed to just an intermediate page. There is more protection there.

Alphonse it sounded like they were just waiting for the sitemap to launch. Other than that, I couldn't think of anything else to add because the sitemap should solve their issue. However, I have marked this as "Discussion" again.

I know it's possible depending on your host, but in the case of a Shopify-hosted website if they're saying in their own forums that it can't be done then they can't (or won't) do it. At that point either using Shopify's blog or subdomain (not recommended) are your choices. If you have an existing blog and need to import the posts to Shopify you can use: https://apps.shopify.com/blogfeeder .