International Technical SEO

Editor's Notes

• #2: Structuring a site correctly for technical SEO can be tricky at the best of times, so when you have to handle multiple languages or country-specific websites, this can add a whole new level of complexity. Getting the technical elements of your international website wrong can have fairly serious ramifications such as search engines not finding all your content, ranking content in the wrong markets, or perhaps even hitting you with a duplicate content penalty because it’s found multiple version of the same piece of content. Today I’m going to run through some of the different ways you can structure your content for international SEO, ensure that Google is serving content to the correct users, and also avoid some of the common pitfalls of expanding your site into international markets.
• #4: Different ways of structuring your website and your content, with some pros and cons of each approach Exploring the hreflang tag and making sure search engines serve the correct content to users in specific markets Some of the functionality in Google Search Console that can help with your international plans Finally some common errors that can arise through this process, and how to avoid them
• #5: In terms of structuring your website, there’s three main approaches you could typically take Firstly, a ccTLD which stands for country code top level domain A sub-folder approach Or a sub-domain approach, some examples of which are shown in brackets here There’s no real right or wrong answer to this. Each approach has it’s pros and cons and one will be more suitable for specific sites and specific markets Let’s explore some of these in a bit more detail now
• #6: Firstly, the ccTLD. A brand that utilises this approach is Coca Cola, as you can see their country-specific websites in the top right here The biggest advantage of this approach is by far the strong location signal that it offers to search engines. Having a .co.uk site is a very strong signal as to which audience you want to target (UK), as is .fr or .de for France and Germany. This will certainly give you a ranking boost over sites that do not take this approach It can also increase the level of trust amongst your audience and result in a better CTR from the SERPs. Users in France are notoriously swayed by .FR websites and will be more likely to click on these than generic domains such as .com In terms of drawbacks, there is increased promotional efforts required for each site. Because they are set up and hosted separately, there’s no sharing of link authority of any parent top-level domain. So in essence, you’re building up the link authority of these sites from scratch, which can make it harder to rank. Finally there is the small disadvantage of buying each domain, setting up and maintaining a site on it. It can be quite time consuming and if you are a major brand, you might have difficulty purchasing your country domain if someone else already owns it and wants to hold you to ransom!!
• #7: An alternative approach would be to utilise sub-folders, as Apple does with these examples here. The main benefit of this approach is the shared link authority of the top-level domain. Any links built across all the country sites will benefit each subsequent site because that link authority is held within the top-level domain, in this example it would be Apple.com. This can have a real ranking benefit for all your regional sites, even if they are relatively new. A secondary benefit to this approach is the lower set up and maintenance cost, comparatively to the previous approach we ran through What holds back this approach is that it has a lower trust element compared to the ccTLD – especially in certain markets and certain industries. You may not see the strong CTR benefit that you would do if you took the ccTLD approach. Finally, it is a much weaker location signal to search engines compared to ccTLD. In fact from the three different approaches you can take, it is the one with the weakest location signal. There are things you can do in Search Console to improve this, which we’ll go into in more detail later on
• #8: Finally the sub-domain approach, which is one that is used by Wikipedia This approach sort of sits in between the other in two in terms of pros and cons. It doesn’t really have the full benefits of either, but similarly it doesn’t suffer from some of the restrictive drawbacks that some of them offer. Firstly, there is a degree of location signal given to search engines because you can host separate sub-domains in separate countries, which could potentially give you a ranking boost in that country. There is the lower purchase and maintenance cost because you can set up sub-domains to your hearts content without having to buy any new ccTLDs Finally there is some sharing of the authority of the main domain, but certainly not as much as you would see with the sub-folder approach So this leads us onto the drawbacks. There’s still some increased promotional and linking activity required because as I say, you won’t benefit from all of the link authority of the TLD And the location signal offered by the server locations is nowhere near as strong as you would get with a unique ccTLD
• #9: So we’ve gone through how you might want to set up your site, I suppose something else to consider is the content you’re going to host on those sites. You’re likely to come up against two certain situations… Firstly, multiple single-language content targeting different locations, so in the example here we’ve got 4 pages of English content targeting these four different countries. Secondly, you might have fully translated content that targets different languages, so here we may have 4 pages of content one for English, one for French, one for Italian and one for Spanish Adopting either of these approaches gives you potential issues with regards to SEO, so there’s ways that we can give search engines more information about our content so that it ranks correctly, every time.
• #10: This leads us on nicely to hreflang. Hreflang is a HTML tag that you can add directly to the source code of a page and it indicates to search engines the language of the content and also whether there are any alternate versions for other languages or specific locations. The main purpose is to help search engines understand the language of a piece of content and therefore can help it serve it to the correct users in the correct market There’s two main ways in which this tag will be used, and they are when you’ve got duplicated content in one language targeting multiple locations. Small variations might include pricing, use of currency, delivery options etc. Secondly, if you have fully translated content for different languages – you still need to use the hreflang code to give Google as much information as you can to ensure the content is ranked correctly.
• #11: So just to visualise those two scenarios. Here we’ve got 4 versions of our widgets page and they’re set up to target users in different countries. The problem is, they’re all in English. Googlebot is met with a bit of a conundrum because it doesn’t know which of these it should be ranking in which market for the keyword ‘widgets’
• #12: Googlebot is likely to react like this, and just pick one of the pages and rank it in all markets, which is not what we want. Or, a more extreme reaction might be that it doesn’t rank any of our content and instead gives preference to our competitors – definitely not what we want!
• #13: Googlebot is likely to react like this, and just pick one of the pages and rank it in all markets, which is not what we want. Or, a more extreme reaction might be that it doesn’t rank any of our content and instead gives preference to our competitors – definitely not what we want!
• #14: So we can use the following hreflang code to make sure this doesn’t happen, and that Google understands the setup of our content correctly. This is how the code breaks down. We tell Google that there’s alternate versions of this piece of content We give them the location of these alternate versions We tell them the language of the content Finally we say for which country location they are relevant Now Googlebot likes us again, and has enough information to rank all the content correctly. One thing to say about this code is that hreflang’s primary function is to indicate the language of a piece of content, so this part of the code is necessary Specifying a country is only optional, but obviously in this case it was needed because all our content was in English anyway
• #15: The second situation I gave was translated content in multiple languages, so again let’s look at an example. We’ve got four pages all targeting the keyword widgets – or a localised version of the keyword – and each piece of content is translated into a local language. This doesn’t necessarily give Googlebot enough information to rank the content correctly, especially if say we’ve hosted all this on a generic .com domain
• #16: So again we can use the hreflang code to give Google the information it needs. We’ve got the exact same setup here but we’re specifying different languages. Here we’re clearly stating the language in which each piece of content is written, showing Google how it should rank this content. We could be even more specific by adding a country identifier as well, but as mentioned before, this isn’t always required. Google has all the information it needs now to rank the content accordingly in each market for each language query
• #17: Another way to use hreflang is for any piece of content that doesn’t specifically target one particular language or location. This is call the X-Default tag. Common usage would be on country-selector pages or any kind of catch-all content. It’s to identify content that is for languages that aren’t satisfied by the other alternate versions that we’ve stated elsewhere. So if you have a visitor from some far-out pacific island for whom you don’t have a specific site, you would want to land them on this country selector page or a generic homepage.