Establishing a multilingual and/or multi-country Web presence to expand your business reach to a wider international audience requires an in-depth understanding of your target markets as well as international SEO knowledge to properly reflect your desired targeting in your site Web structure, technical configuration, content development, optimization, and promotion efforts.

The lack of expertise, in regards to the above elements, is why it is not that uncommon to see international SEO processes with a variety of issues, many of which can cause a sub-optimal user experience, and the international SEO process fails to obtain the desired results. 

Here are some of the most common issues and ways to fail at International SEO (and how you can avoid them):

1. Not Using Different URLs for Each of Your International Web Versions

It is fundamental that each of your language or country pages are shown through their own specific and accessible URLs so they can be crawled, indexed and ranked by Google. This option is better than relying on locale-adaptive crawling, which tries to identify a visitor's language and/or country and showing that content version through the same URL.

As Google mentions in its own official documentation: “Google might not crawl, index, or rank all your content for different locales. This is because the default IP addresses of the Googlebot crawler appear to be based in the USA. In addition, the crawler sends HTTP requests without setting Accept-Language in the request header.”

This is why you should establish an individual Web structure for each one of your international versions, whether using ccTLDs, sub-directories or sub-domains if you are country targeting, or using sub-directories or sub-domains if you are language targeting. All of them have pros and cons, and the options should be assessed to select the best international Web structure based on your own characteristics, goals, and restrictions.

What it is also important is to be consistently showing the actual URL version of a page relevant to a language or country to visitors when they land, or when they select to go to that version. This strategy is better than doing what some sites like Entrepreneur do; in the example below, they choose to show the Spanish version of the home page through the same URL as the English one (https://www.entrepreneur.com/) when they identify that the user is using a browser in Spanish.  

This is unnecessary as Entrepreneur actually has a Spanish version of the home page shown through its own URL (https://www.entrepreneur.com/es), as can be seen below. This would be the relevant URL to show in this case to avoid giving a confusing experience, allowing Spanish speaking users to link or share it.

2. Automatically Redirecting Your Users to an International Web Version Without Giving the Option to Select It

Although you might want to refer your users to their relevant country or language version, it is not recommended to do it automatically by using redirects. These redirects can be a confusing and an intrusive experience to users that might have come to specifically see content that is in another language or a specific country version. 

A Quick Point About Google

At this point, most of Googlebot's IPs are still from the US; Google doesn’t crawl from all countries yet (the crawlers mostly come from the US and a few other countries). Therefore, if we redirect only to the website version for those countries, then the Googlebot will always be redirected and see only a few versions of our site, not all of them.

You are not just redirecting users but also the bots. That is why is better to allow not only the user to browse whatever international version they have landed at but also the Googlebot to crawl whatever version instead of redirecting it based on their IP.

Examples

An even worse experience is given when the redirect is done without even allowing users to switch to the international version that they wanted to access, by showing a very visible option; this can be experienced on some blogs or news sites, like Gizmodo, as shown below.  

Instead of the redirect, it is then recommended to allow users to access the originally selected international Web version while notifying them that there might be a more relevant language or country version for them based on their browser or country IP. You can do this in a non-intrusive and visible way, giving them the choice to either remain or change versions, as Autodesk does.

3. Not Localizing the Content of Your Different Web Country Versions

Even if you target different countries that speak the same language, you might think that you can reuse content across different versions of your website; you shouldn't. It is critical that the content that is featured in each one of them is localized, targeting a specific audience behavior in each country market. The content might be different even if using the same language. Things that could differ could be particular terms used to describe seasonality or different localized words to describe products or services. Despite the common language, preferences can change from country to country.

For example, we can see how in the US version of the Adidas site, there’s a “Soccer cleats” category that is called “Football Boots” in their UK version, since they have been localized to connect and address the way users search in each country — which is different in this case even if they speak the same language.

It is also critical to develop a full keyword list and do competitive research for each of your targeted countries. These should include the input, support, and validation of a native speaker from that specific market, in order to identify the specific search behavior of the audience in each one of them. You can then optimize your Web content, organization, design, and promotional actions based on those preferences.  

4. Using a Single ccTLD to Target Many Countries

Sites that start by targeting a specific country, usually their own, and use their specific ccTLD (country code top-level domains like .uk, .mx, .es, .fr or .de which is already geolocalized by default), might have a challenge when needing to expand internationally.

They won’t have the option to use that initial ccTLD to target other countries, as you can do with a gTLD (generic top-level domains like .com, .org, .net) that are not associated to a specific country. A gTLD domain can be used to target many countries by enabling sub-directories or sub-domains that can be geolocalized via the Google Search Console.  

Unfortunately, some businesses are not aware of these options and try to target other countries by enabling sub-directories for different regions they want to target under a ccTLD, that is already geolocated to another one. We can see this in the example below, with a US version in a subdirectory located under a .co.uk (ccTLD that is already geolocated by default to the UK).

Due to this, when expanding to new international markets, businesses that already have a ccTLD (instead of a gTLD) would then need to choose to target other countries by using country-specific ccTLDs. This option would require a lot of work to grow the individual popularity of each domain. Another option would be to migrate or additionally establish a new presence with a new gTLD that would help a business to target many countries more effeciently by enabling sub-directories that can be geolocated through the Google Search Console.  

5. Assuming That Google Supports Continent Targeting With .asia or .eu Domains or “eu” Values in Hreflang

Google doesn’t support (at least not yet) regional targeting at a continent level, whether by using regional top-level domains like .eu or .asia which are treated as gTLDs or by using regional values like “eu” for Europe in hreflang since Google supports ISO 3166-1 alpha-2 country codes for them.

It is important to take this into consideration when deciding whether to establish a presence with an .eu domain when targeting Europe; when instead it might be better to use a gTLD with specific sub-directories that can be geolocated through the Google Search Console and tagged with hreflang annotations to target specific European countries at an individual level.

6. Canonicalizing All of Your International Web Versions to One to Avoid Content Duplication Issues

Sometimes, even after going through a localization process, due to the nature of your business, you might end up having very similar content across different country versions that speak the same language (like English in the US, UK or Australia).

However, if these country versions are correctly geolocated to their relevant markets, the content of these pages shouldn’t be seen as duplicate since it is targeting different audiences, and need to be indexable in order to be effectively ranked in each country. You don’t have to put canonical on these pages to one of the country versions of the site because each one is considered to be unique since it is targeted at a different location.

Sometimes confusion might arise due to the cross-country canonicalization that can be seen in some well-known sites, like in the example of Airbnb below, in which we can see how they are canonicalizing their Mexican home page to their Spanish homepage version in the .com domain. Nonetheless, we don’t know the context in which the decision for this configuration was made, and on the other hand, we can see that in those markets where they have an active business and organic search presence like the UK, France or Spain they are self-canonicalizing it.

What it is recommended to do in this case, to effectively target and rank the pages of each country version to their relevant market, is to geolocate each one of them by using either ccTLDs or geotargeted sub-directories or sub-domains — to be specified in the Google Search Console — as well as using hreflang annotations to specify the language and country targeting for each page, and their alternate versions.

7. Implementing Hreflang Annotations Without Following a Process That Includes Validation

A whole post can be written about the mistakes that are usually made when implementing hreflang annotations. In fact, I have written and presented specifically about it in the past. From using non-supported values to specifying the country without the language value or forgetting to include the return tags or including non-indexable URLs, among many others.

In general, these errors usually happen though due to a lack of an hreflang implementation process that includes a validation, which would look something like this:

A. Assessing the Language and Country Implementation Scope

Identifying the languages and countries versions that need to use hreflang, especially those with identified international misalignment search results that might want to be prioritized.

B. Choosing the Implementation Method

Assessing the best fitting hreflang implementation method (tags in the HTML head, HTTP header or XML sitemap) based on the site and project requirements as well as restrictions.

C. Specifying the Hreflang Code Pattern

Define the hreflang tagging to be used in the implementation. You have as a reference Google's official specification for the chosen method, as well as the supported country and languages formats and values to avoid non-supported placements, tags, attributes or values.

D. Validating the Hreflang Implementation in a Test Environment

Crawling the tagged pages (through a site and alternatively, an XML sitemap crawl, if this was the chosen method of implementation) in a test environment before the launch happens, to identify any potential tagging errors.

E. Monitoring and Troubleshooting the Hreflang Implementation After Launch

Recrawling the tagged pages after launching them on the live site to identify any remaining issues and start monitoring them through the Google Search Console International Targeting report. Continuous monitoring should also be started to identify any problem when publishing new pages, as well as changing or eliminating existing ones. And, to identify any potential new languages and countries misalignment issues in Google's Search Results via the Google Search Console Search Analytics or the new Performance report.

F. Establishing Hreflang Best Practices Guidelines to be Followed

Documenting the hreflang implementation scope and rules that are to be followed to define good practices based so they can be taken into consideration whenever pages of the relevant languages and/or countries are published, or their URLs are changed or removed. This documentation is needed to ensure the hreflang annotations can be updated and validated accordingly.  

With this type of hreflang implementation process, errors should be minimized and if they happen, quickly identified and solved.

Hopefully, this post will help you to avoid these rather common international SEO issues, and if you are facing any of them at the moment, you will now know how to solve them.