Welcome to the Q&A Forum

Believe none blindly :-), however, trust more people who do International SEO since ages like me or Aleyda or David Sottimano.

I see a lot of confusion in all the answers :-).

The .ie domain is never treated as a generic domain name by Google. It's the country code domain for Ireland. Stop.

A country code domain name is geo-targeted by default on its corresponding regional version of Google, but Google doesn't "block" its visibility also in others Google (i.e.: Google.com or Google.co.uk), however, a ccTLD will have more difficulties in ranking higher in another Google than its own.

In other words:

1. domain.ie is targeting by default Google.ie;
2. but, it can be shown in Google.co.uk too;
3. however, for ranking in Google.co.uk - because of its geo-targeted nature - it must have stronger signals like mentions and backlinks to justify its visibility than a domain.co.uk or domain.com.

That post on SEOChat, albeit correct in the basics, is frankly old (it still suggests to use Dmoz, which doesn't exist since at least 1 year).

I suggest you view this slide deck by Aleyda Solís: https://es.slideshare.net/aleydasolis/speaking-in-tongues-establishing-a-successful-international-web-presence-smxeast.

Ehmm... sorry to say that you're totally wrong... having 3 sites using the same language and using the same exact content, even if you geo-target them, they still are the best example of exact match duplicate content... and only implementing the hreflang you can avoid to see them filtered or 1 appearing in the wrong SERPs.

First of all, you must ask your client if she target different regions like continents for some reason related to her business.

If not, then going multilingual is the best solution that trying to geotarget countries... also because, as Gaston wrote already, you cannot geotarget anything but nations: no continents, no political or economic states unions (like the UE).

If there's some justified business reason why the client needs to specify different versions for different large areas, then things can be weird, but there's a way to do it: using as many hreflang annotations as they are the countries present in a bigger geo area and targeted by a specific website.

Remember, in fact, that an URL can be annotated with as many hreflang annotations as needed.

i.e.: the www.domain.com targets Italy, UK and France with its English version but not other states for whatever reason (so not able to use simply hreflang="en") and Spain with the Spanish one, then its hreflang will be:

<rel="alternate" href="https://www.domain.com/" hreflang="es-ES"></rel="alternate">

<rel="alternate" href="https://www.domain.com/en/" hreflang="en-GB"></rel="alternate">

<rel="alternate" href="https://www.domain.com/en/" hreflang="en-IT"></rel="alternate">

<rel="alternate" href="https://www.domain.com/en/" hreflang="en-FR"></rel="alternate">

(I know it would be better to create an Italian and French version too, but this was just an example to give you an idea of what I was saying).

Both the hreflang looks correct if your site is targeting only :

1. Spanish speaking users in Spain (hreflang="es-ES")
2. English speaking users in Spain (hreflang="en-ES"

If you are targeting English speaking users no matter the country, then you should use the hreflang="en" and not "en-ES".

You can create an hreflang with codes "en-es", because "es" also is the iso code of Spain as country, so the hreflang "en-es" is English in Spain (albeit would be better writing en-ES, but Google is not caps sensitive from what I know).

Second... you don't need to use the hreflang in every page, only in the ones that really need it.

For instance, if a page is canonicalized to another, the best way to avoid potential hreflang implementation mistakes (for instance, for not using the canonical URLs in the hreflang annotations) is not implementing it at all... because for its same canonicalized nature.

Hi John,

could you please give us a feedback and tell if any of the suggestions the community offered to you was of help?

Thank you.

I suspect you didn't understood the question.

MTBE was asking if schema.org structured data items must be in the language used in the subfolder.

For instance, in www.domain.com/en/, will be the items written in English and in www.domain.com/es/ in Spanish?

The answer is yes.

Albeit your answer is correct, Google itself states in its guidelines page about Multilingual and Multiregional websites that - due to the diffusion and mainstream use of cloud hosting - that the physical localization of a server is not anymore considered as a prominent geotargeting factor.

Therefore, I would consider having a server in a hosting located in the same country we are targeting, if the latency really may mean the difference between a slow and a fast website.

If it doesn't... I would not worry about its location.

Did you try to add a third hreflang annotation like this?

You can assign more than 1 hreflang annotation to an Url.

Maybe you could test this idea for a subfolder that you can easily track on Search Console.

Mmm... now I understand your question, and - yes - that sounds weird.

Sincerely, without knowing the site and for what keywords it doesn't rank with its English version in CZ for English queries, I cannot give an answer.

If the sites are in two different languages, then canonicalizing the CZ  version to the EN version is not only a mistake: it's stupid because you're telling Google: "Hey, this is the Czech version of the site, but I don't care... so show the English version to Czech people".

Even if the two sites have the same language but target different markets, it would be wrong cross-canonicalize one of them.

The use of the hreflang is a win-win also for this reason: avoiding duplicate content issues... so, if you cross-canonicalized the two sites, quit that canonicalization ASAP!!!

Then, regarding how the hreflang has been implemented by you, that is ok... albeit no positive response can be given in a Q&A without seeing the actual code.

Finally, regarding why your CZ subdomain is not ranking in google.cz as the English version does elsewhere... the answer is easy (at least in theory, as - I repeat - no real answer can be given without knowing the website): your cz subdomain is a separate website and probably doesn't have a strong link profile, at least not as strong as its competitors.

And, no: even if your english website has a strong link profile, it is not helping at all the cz subdomain.

I see that that product has two Urls:

1. http://www.key.co.uk/en/key/single-leg-wire-rope-slings
2. http://www.key.co.uk/en/key/0-4-tonne-wll-6mm-single-leg-wire-rope-sling-580a078n

The first one is the Url you indicate as canonical and the second one is the one that you canonicalized toward the first and where the mistake is flagged. I suppose the same happens in the .ie version.

Formally, I don't see any mistake in how the hreflang has been implemented in the 2nd url, because if you really mean to have it canonicalized toward the 1st, then is totally correct to use the canonical url in the self-referential url and the en-ie hreflang annotations.

I checked the Urls with Screaming Frog, setting it to crawl the hreflang's urls, and it doesn't show any error... so, if that kind of mistake is presented only by the SEMRush Audit... then that's a mistake of the SEMRush audit.

However, does this mistake appear in your Google Search Console?

Remember that you can implement Structured Data in AMP too.

Moreover, in some cases (i.e.: the recipe markup), Google obliges you to implement it on AMP if you want the Recipe rich result on mobile.

The same for the item list rich card, which may give you a wonderful rich result where all the items of a category page of yours are shown in a carousel in the SERPS.

Beware with LSI, which is mostly a myth.

As Bill Slawski wrote in Inbound.org back in 2014:

_Latent Semantic indexing was invented and patented in 1990 before there was the web. _

_It was developed to help index small (less than 10,000 documents) databases of documents that didn't change much (like the Web does). _

_There have been a number of companies that started selling LSI Keyword generation tools that promised that they could help identify synonyms and words with the same or similar meaning. _

Where those fail is that the LSI process requires access to the database (of documents) in question to calculate which words are synonyms - and the only people with access to Google's database to do that kind of analysis (which isn't possible anyway since Google's index is much too big and changes much too frequently) is Google.

A much better metric is TF-IDF, albeit always being conscient that it is still a metric... not the bibie.

Keyword Density is a myth as it has been demonstrated for several years !!! Please, don't spread myth in the Moz Q&A.

Some sources:

• https://moz.com/ugc/seo-myths-that-persist-keyword-density;
• https://moz.com/blog/keyword-targeting-density-and-cannibalization-whiteboard-friday
• http://www.alessiomadeyski.com/seo-myth-keyword-density/
• https://plus.google.com/+BillSlawski/posts/F9h4pVSXapT
• https://www.searchenginepeople.com/blog/how-search-really-works-the-keyword-density-myth.html
• http://resources.spyfu.com/4-seo-keyword-myths-you-shouldnt-buy-into/
• https://www.blackhatworld.com/seo/seo-myth-busting-01-keyword-density.961827/ (I mean, even black hats say it's a myth!)
• ....

This answer is good, because of the tools that are shared.

However... creating unique content doesn't mean your site will start earning links like crazy.

Umberto Eco once said that there are thousands of exceptional books that nobody ever read. The same can be told about all the "great content" published on the Internet. If you don't

If you don't put the same effort you put in creating your "quality content" into promoting it, then you're not going to obtain any backlink at all.

Therefore, more than thinking about what tool to use for creating content (please, don't confuse content with formats), I think it's better to suggest checking out the posts here on Moz under the Link Building category.

Social signals are not a ranking factor.

Moreover, it has been demonstrated by Buzzsumo that the theory of social media amplification = more backlinks is false, because, as that study says:

1. only a small percentage of all the blog posts published daily are able to obtain a minimum number of social share and
2. in order to obtain at least one backlink, thousands of social shares are needed.

The correct answer is

1. Quit geo-targeting in GSC
2. Implement hreflang annotations. Their same implementation will avoid the risk of Google considering the "duplicate" versions as duplicate
3. DON'T CANONICALIZE ALL THE VERSION TO ONE YOU CONSIDER CANONICAL. Doing that will screw all the hreflang implementation and the other countries will always see the canonical Url (for instance the US one in the UK).
4. Instead, work on canonicalization but version by version as if they were (and actually they are) different websites. This means self-canonicalization and/or canonicalization toward another url in case, you know, of parameters et al
5. Try the most you can to localize the different versions of English you're using. This will improve the localization signals for Google (and will  be appreciated by your users). However, if you cannot afford to do that, you're still safe because of the hreflang.
6. Remember that the href of the hreflang annotations must always present a canonical Url. So, if you implement the hreflang in a canonicalized Url, its href will need to present the canonical url of the canonicalized page the hreflang is being implemented. If you don't do this, you will see "no-return" error in Search Console, and Google won't consider your hreflang implementation and, yes, it will start considering your versions duplicated content.