- 1. Hreflang: No setup, partial setup or incorrect setup (and c.25 sub-issues)
- 2. URL/domain structures that limit visibility of market sites by limiting link equity and authority
- 3. Use of IP and/or browser language detection to redirect users (in such a way some pages or content can’t be indexed)
- 4 Use of SPAs or Web Apps to create market sites that have no indexable URLs for market or language specific content
Ok I have seen some sites have issues with every one of these technical SEO problems around International on their site, and wonder why their international SEO strategy isn’t working despite investing in content for each market.
I have seen most sites with at least one of these issues, sometimes site-wide, sometimes for specific markets.
Arguably this is Google’s fault for relying on Hreflang when it’s so easy for site owners (especially small business owners, but even big multinationals) to get wrong, or Google not having a fully effective way to tell them that your separate ccTLDs should be treated as one site.
But in SEO there’s little benefit in complaining about Google, though it can be cathartic, and we need to adhere to the best practice that will work around Google’s flaws, whether we like it or not (ok as an SEO I like the challenge that’s why I do the job, but I do feel bad for clients who I meet who have been scratching their heads as to why all their efforts have been wasted for years when it’s down to some small technical detail).
So here are the 4 mistakes that you may be suffering from right now and how to fix them:
Also just a note if you target 1 market and 1 language only still pay attention to 1 and consider the other 3 to futureproof your site for going global in future.
1. Hreflang: No setup, partial setup or incorrect setup (and c.25 sub-issues)
Ok so I happen to know of a great video of a certain Dave the SEO talking about this at Brighton SEO in Autumn ’23, all still valid as of Autumn ’24, so I’ve added this below.
But before you watch the video I want to iterate just how impactful good Hreflang can be, some of the biggest sites in the world have Hreflang that is missing or ignored and lose out on millions in sales every day, perhaps they can afford to lose that much but once you compound the drop in CTR and drop in engagement and CVR from people landing on sites for the wrong country and even in the wrong language you can be missing a significant chunk of sales and potentially losing potential customers forever who think you don’t serve their market, for example because they landed on your US, not your UK site, that told them you ship to continental US only (or Google just think you aren’t relevant to a market and don’t show you much there at all).
<link rel=”alternate” href=”http://example.com/en-us” hreflang=”en-us”/>
<link rel=”alternate” href=”http://example.com/en-gb” hreflang=”en-gb”/>
<link rel=”alternate” href=”http://example.com/en-gb” hreflang=”en”/>
Even if your current site has no way of adding Hreflang easily and you’ll either need a new module, to do it manually (there are tricks here to save time and map pages for a Hreflang sitemap) or you need a new site: it is worth doing a cost benefit analysis. A forecast of lost traffic and sales may surprise you just how much you are losing and make it a no-brainer.
I have written up a simple way to calculate the cost of international canibalisation, which Hreflang can fix, here
So I’ll now let this guy tell you more about Hreflang mistakes:
2. URL/domain structures that limit visibility of market sites by limiting link equity and authority
Amazon have separate ccTLDs (Country Code Top Level domains like .co.uk and .de) and don’t seem to struggle right? Well Amazon have had to build up link equity and topical authority in each site, though even with external links passing less value than internal links linking between their sites still has heft.
So if you are Amazon or a similar size you can probably ignore this, though I would argue you could still be getting better rankings with a sub-folder structure.
Ok before I continue I am going to point out some exceptions where ccTLDs do make sense for your domain structure but first a better introduction to the topic and why sub-folders on a gTLD (global top level domain) such as .com or .net are usually best for setting up your international site, and indeed your first/home site if you have dreams of expanding to other countries one day.
As I alluded to above Google treats links between pages on a site (internal links) and between pages on different sites (external links) differently and the link equity and other value, such as topical authority, passed by links is diluted more for external links than internal links. This is basically so pages on your site can still benefit even if they have no links, due to the links to other pages. I could go more into how link equity works overall and the concept of seed sites at this point, but I’m not going to.
Instead I am going to warn you that if you set up your international market and/or language specific sites on separate ccTLDs, such as:
example.co.uk,
example.fr,
example.de
They will be treated as separate sites and you will have far less link equity in your sites meaning pages won’t rank as well. You can boost your new example.al Albanian site by linking to it still of course but it will not get any where near the benefit of being within your main site.
This may seem obvious but what is perhaps less obvious is that sub domains aren’t treated as the same site either. So fr.example.com de.example.com and uk.example.com are separate sites (otherwise you could setup a site on mynewbadgerblog.wordpress.com, or similar, get one link from the main WordPress site and benefit from being part of the WordPress site with all of it’s links and link equity).
So subfolders or sub directories (different names same thing) are the best place to put your international sites
e.g. example.com/en-gb/,
example.com/fr-fr/,
example.com/de-de/
(As you can see I like them to match the Hreflang and this is a structure that is completely future-proofed, as if you setup example.com/de/ then what about when you want to setup example.com/be but might need a Dutch and French version).
I said there are exceptions so here it goes. You can, like Amazon, build up the link equity of each separate ccTLD, this is a lot more work but possible if you have the time and budget, so makes more sense for bigger companies and those that can get a load of PR just for launching in a new market, even if it is for what a bad job you did.
You might want to do this if you think that your customers will be more likely to click on and trust a ccTLD that they can see matches their market. In some industries though, and in my experience most B2B industries, a .com is more trustworthy as it indicates a global, successful business.
For some B2C products, especially where things like local customer service, being able to return within shipping half way round the world etc. are important a ccTLD might help, but it needs to really be impactful to counterbalance the impact of the loss of link equity. Also some countries this matters to more or they may trust global companies less, or .com may sometimes be seen as an indication of it being a US company though this is not the purpose of the .com TLD.
Exception 2 is any site in China or Russia, they are countries where a customer may trust ‘western’ brands less but it is actually that Baidu in China and Yandex in Russia show .cn and .ru sites respectively, it isn’t as hard and fast in Russia, and in China other search engines are taking share from Baidu, but if you are serious about these markets you need the right ccTLD.
3. Use of IP and/or browser language detection to redirect users (in such a way some pages or content can’t be indexed)
This one I will try to keep relatively short and succinct, don’t redirect users based on their location (using IP) or language (using browser language) it is not good for user experience, use a banner instead giving people the option. It is really bad for search engines too, why in a moment but first an exception.
Ok not quite as succinct as it could be then, but yes some sites for legal reasons can’t let users in one market go and see another market, often true for financial services, alcohol related sites etc. Or it could be that the offering, branding etc. is totally different, maybe you don’t want people to see what a great price people in the market you just launched in are getting compared to people in your home market (people will find ways around this with a VPN some of the time anyway).
Ok so if you have to use this functionality then make sure non-cookied users (those with cookies rejected or disabled) which includes Google and other search engines, don’t get redirected.
I have come across sites where Google just didn’t know that any site but the US site existed because they browse from the US and every time they followed a link to the UK site they get redirected back to the US.
And if you still think it is good for user experience, imagine you go to a page on the US site because you speak English but you’re in France and you get sent to the French site in French which you don’t speak. Or you want to read an article that is available on the US site but isn’t available in the German site but you can read English but you get sent to the German homepage whenever you try to access it, and of course then there are people using VPNs or on computers that have the wrong or a different browser language set.
4 Use of SPAs or Web Apps to create market sites that have no indexable URLs for market or language specific content
If you use Shopify there’s at least a 50% chance you have this issue, and if you don’t it’s probably only because you or someone else had to fix it. If you use a number of other platforms though this could also be an issue. I’m going to focus on Shopify as an example but basically check if the same is happening for your site.
Out of the box Shopify is setup where you can quickly add a load of currencies and have different prices for different markets, you can then start adding translations or localised content too. But if you don’t update your settings then Google will never see this.
If you want to check what is happening, and why, go to a page and choose a different language from the selector. What happened? Did the URL update? If it did, it could be a parameter like your-page/?lang=fr, or a sub folder e.g. /de-de/your-page, then there’s a URL there associated with the updated content that search engines can find, crawl and index. If the URL didn’t change, which on many Shopify sites it won’t, then you have a problem.
You have what is basically a Web App or Single Page Application, the content on the page updates as users interact with it without the URL changing, search engines like Google are setup to crawl and index pages where the content loads up and can then be saved and the next page moved on to.
So if you have this issue you need to change settings so that each page is indexable otherwise one version, the default or version shown to users in Mountain View California, is going to be indexed and everything else will be missed.
But even then you need to ensure that Web Apps aren’t hiding links to your international pages.
4.5 Language Selectors with no static links
A Bonus, related to number 4, but a bit different and common across many platforms, ok especially Shopify, particularly when you are adding language or market selectors with an add on (some add ons are good, some are bad, you may just need to choose a different one).
So many language and market selectors don’t have static links, the links to all of your different versions of a page therefore are hidden from search engines, you might see this doing a crawl in Screaming Frog or checking in Google Search Console.
You can also check the links themselves though.
- Hover over the link and see if the link shows at the bottom of the browser window, if it doesn’t you have a problem if it does check the next point too
- Check that the link doesn’t just generate when you interact with the language selector, e.g. you have to first choose a market and then get a list of languages and at that point the links show. Copy one of these links, empty the cache and reload the page, without clicking anything check the DOM code in Dev Tools (right click – Inspect) and search the code for the link: does it show and if so is it linked from the place in the page you expected.
4.5.5 Also make sure language selectors take people to the equivalent page
Ok really my last point now, if you have a language or market selector then send people to thr equivalent page, the one that should be mapped in hreflang. So someone accidentally landed on the top they were interested in buying, but on the US site and they’re in the UK, don’t take them back to the homepage when they move to UK English and force them to try and find it again.
This is mainly a UX issue, but also helps improve flow of link equity between equiavelent pages.
So there we are, you can now fix these issues and get on with the real work of localising your content and site to really meet your markets needs. If you would like further training though on International SEO or Technical SEO, check out the courses I offer.