6 SEO recommendations every international eCom website should implement

Do you own an International eCommerce website? 

In this article, we unpick some of the most common mistakes we see in a large number of International eCommerce setups, why they’re a problem, and how to fix/improve them. 

1. Hreflang
2. Geo-IP forced redirects
3. Relative internal linking
4. Country Selector (SSR)
5. Language localisation
6. Currency

Hreflang

It often sounds like a word from a different world, but it is not as scary (in most instances) as perhaps it may sound. 

What is hreflang? 

• Hreflang is a way in which we can inform search engines that a particular website should be served to a particular audience. The Hreflang format references language (en) (it) and then country (GB)(IT) etc. 
• Hreflang needs to be applied to all of your sites on pages that are mirrored across each storefront, e.g. you might have a US store, a GB store, an EU store, or an IT store – the homepage can easily be referenced, but if the categories and products are also mirrored, then you’ll also need to apply hreflang to all of these pages – which in most eCommerce stores, they are!
• When applying Hreflang, it’s critical that you reference all of the market variants in the hreflang code. It’s equallyimportant that the hreflang code on all of the other markets references the origin site back, too – this tells search engines that there are variants of the site that cater for different markets and different audiences. 

What problems do we often see? 

• If you create a like-for-like storefront with no URL changes based on language nuances (US English vs UK English) then you can use an automated rule, and this will often cover what you need it to. 
• However, the moment you throw URL variants into the mix or slight variants in the terminology used, you need to go through a process of aligning the sites so that each of the URLs references each other, even if there are variances in URLs.
• If you try to use an automated rule in the above instance, you’ll end up with a lot of 404s, which completely defeats the purpose of hreflang, to begin with – all hreflang tags should return a HTTP 200 status code, not redirect, and be indexable (not include a noindex tag).

What are the solutions? 

• Homepage – this is the simplest template to be able to map for hreflang.
• Category/Collection – this is often ‘simple’ too, as there are frequently a manageable number of categories to map manually or with a logic.
• Products – this is where it gets harder, especially when product URLs are different – if you have matching SKUs, we can map these for each site using the SKU as the common denominator. 
  • If a SKU is not available and you are using a PIM system, you can use that to map products. 

What does hreflang look like? 

Including a IP based pop-up (not forced IP redirects)

One of the most common issues we see is forced Geo-IP redirects when a brand has multiple stores. This causes customers who land on an incorrect store to be forced to the correct store based on their IP. However, this can have crawlable consequences for search engines. 

Why is it a problem? 

• Google predominantly crawls from the US, meaning if it tries to get to your UK site and you have a forced redirect, it could only ever see your US site, causing the UK site and any others to go without crawling, which would also impact crawling and indexability. 

How to fix it? 

• Remove the tool you are using and look to set up a country overlay that prompts customers who land on the incorrect store.
• The pop-up must not be an interstitial that blocks the content behind it, e.g. all links and content must still be crawlable.
• Based on their IP, customers are given an option of which store they should be browsing (but are not forced there without them choosing).
• Once a customer selects the appropriate store based on their location, a cookie is set. 
  • Should a customer visit the incorrect store again, they are then redirected due to the cookie being set – if the cookie expires, the process begins again. 

Relative Internal Linking

What is it? 

When you have multiple stores, all listing the same products – but perhaps without the IP overlay (or they may have ignored it), the customer experience for someone browsing your US shop from the UK will be poor if they get to the product they want to purchase, only to realise they are in fact on the wrong store altogether. 

OOTB functionality for most sites when you then change sites is to take you back to the homepage, forcing customers to restart their whole buying process again – and most likely bouncing from the site and shopping elsewhere. 

Why is it a problem?

• Impacts conversion – since customers are taken to the start of the funnel again.
• Frustrating usability.
• Reduces the ability to link products (similar to hreflang) between stores.

How to fix it? 

• Speak to your developers. Essentially, it’s important that all matching products can be linked together across stores, which in turn will allow for customers landing on a product on the incorrect store to be taken to the same product on the correct store once they make their decision.
• Ensure that the relative links found in the country selector are found in the HTML rather than reliant solely on a JS module to execute the action.

Country Selector (SSR)

SSR? That stands for Server-Side Rendering. SSR is important as it ensures critical content is housed in the source code rather than CSR (client-side rendered) content. CSR is problematic for SEO and Google as it can take up to 9x longer than HTML content to be crawled. Therefore, all of your critical links and content must be found in the HTML to avoid indexing issues. 

What does this have to do with country selectors?

Frequently, country selectors are created using a third-party app and are CSR – making the links crawlable only once the JS is rendered – which can take up to 9x longer than if the links were found in the HTML. 

How should the country selector work? 

The above example references all the market variants in the country selector – all SSR.

The links in this example are all CSR – meaning none of the links are actually included in the HTML. 

How to fix it? 

• Ensure that your market links are all included in the HTML of the country selector module. 
• This will likely require custom development – but it is worth doing and will also allow for the relative linking to be further enhanced.

Language Localisation

A simple and non-glamourous non-technical recommendation, but something so many brands that encroach into new markets often misses. 

What is localisation? 

Localisation is the act of updating terminology to better fit the way that the local language is spoken. When we compare GB English to US English, there are clear nuances in how people search – if this isn’t explored and fixed when expanding into new markets, you run the risk of not appearing for searches at all. 

Why is it a problem? 

If we compare the search in the US for “Men’s Trainers” vs “Men’s Sneakers”, it’s clear that there is a significant demand difference in terminology: 

This will impact your ability to appear for relevant searches to your brand’s product offering, e.g. if you’re expanding from the UK into the US but keep the content the same, you’ll likely only tap into the 1,900 average monthly searches vs the 110,000 monthly searches if you localised to “sneaker” based keywords. 

How to fix this?

• There are clear nuances between GB English to US English. Therefore, a lot of these changes can be completed before your new site goes live. You can run a find and replace in your product template and your category templates to ensure terminology is updated.
• Not everything will be as clear as the above example. You will need to carry out keyword research to ensure that you are tapping into keywords relevant to your market but also frequently used by local users – it’s not always as clear as “trainers” vs “sneakers”. 
• Leverage your keyword planner (if you’re running ads) to see what the locals are using when searching in the market of interest to you, and update your targeting on-site to hit those touch points. This will give you the best chance to rank for those keywords. 

Currency Issues (Shopify specific)

If you’re scaling your business and leveraging sub-domains in Shopify, you’ll want to read this! 

Why is it an issue?

When you scale your market capacities on one storefront (without Shopify Markets), you do so by replicating using your primary domain and leveraging something like Global-e to help with on-site dynamic currency conversion.  

If I was on a primary domain site, but want to change to USD, I’d get the same domain, but the currency on-site would all update (based on IP, or based on my selection). 

This allows you to scale your presence whilst only keeping one instance of Shopify (rather than going down the expansion store route (or using Shopify markets) where you would need multiple instances of Shopify – which is, of course, more costly). 

However, the issue with this is currency. Since you only have one instance of Shopify, you have a base currency, e.g. my primary store is in GB, but you’re using dynamic currency conversion which updates the primary store with its local currency based on IP, e.g. If you are in the US and land on the site, you’ll be shown USD.

This becomes problematic when looking at product schema, as when Google is crawling your primary store, it’ll see the USD currency (as Google crawls mostly from a US IP) – and show that in the USD in search results rather than the base currency – which in this case GBP. This would of course be wrong, since the base currency should be GBP, but due to crawling IP, this isn’t being delivered in search results. 

How to fix the issue? 

• Moving to Shopify Markets sub-folders will allow you to serve a static currency to your markets expansion store, and in doing so, your product schema will be crawled in the local pre-set currency rather than crawling GBP and showing USD in your GB listings.
• The alternate solution for this could be to remove the US from your primary domain site so that Google doesn’t crawl the US currency (due to the US IP Google crawls with) – this would make it essential to have hreflang and country pop-up in place effectively to ensure any US customers are shopping on US store.

If you want to find out more, contact me at .