@Aleyda Solis I hope you don't mind. I have an additional question about hardcoding the hreflang alternate URL in some pages, which i am a bit worried about. Example solution provided to us: Hardcode the hreflang tags in both the homepage and blog pages, as this cannot be content managed with a separate field. It can be manually edited for category pages and products.

Hardcoding is a bit worrying to me, in that if there is no alternate page for blogs, it will surface an error which isn't great for SEO, is that right? So, to me this is not an ideal solution. Is there an alternative? And, if the homepage is hardcoded with the hreflang, and content eventually does change over time, hopefully becomes different as we invest more resource, it makes the hreflang solution supurfluous, and need removal?! I have .com and .us websites (we cannot do sub-directory options!), both of which content is fairly similar, at the moment at least!

Just a quick note on hreflang only: if a page doesn't have an alternative version in another language/locale, then you should only self-reference it in hreflang, and you're done.

Also, there shouldn't be a language switcher on the page, not even for the alternate country's homepage.

The page should be by all means "geo-orphaned", but that's ok because that's exactly what you'll want to tell the search engines ("this page is just for this country only").

This in addition to all the other things said by @Aleyda Solis

I am going through a very similar set up, although .us and .com and we can't have subdomains due to tax/operational reasons and Shopify T&C's. I'd be interested to hear what eCommerce platform you are using @Ian Ferguson ? And, if you've had to add custom meta fields etc for hreflang? We are having to do this in Shopify as their global set up is pretty basic. Just worried it's going to get messy with manual adding.

Hi Ian! First, an observation based on the URL example gave for Ireland in the hreflang tags you added before: https://example.co.uk/ie/product-1 - I wouldn't recommend to use a .co.uk ccTLD to target Ireland, since the domain extension is geolocated to the UK by default, so it would be more difficult for Google to "catch" the subdirectory for Ireland in there is in fact targeted towards Ireland, despite the usage of hreflang. Geolocalization is about the alignment of many signals, rather than just a single configuration, so the more you provide consistent signals to Google about this, the better. I would then recommend instead to use a .com/ie/ subdirectory (see how you're using a gTLD for the domain) or a .ie ccTLD to target Ireland.

Then about your question: "what do I do to discourage /ie URLs, where the product is only available to people from Ireland, from showing up in UK searches and vice versa?" - by aligning all of the other signals Google tend to use into account, as specified here on "How Google determines locale" section: https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites#how-does-google-determine-a-target-locale - from adding the name of the country in the pages titles, meta descriptions, main description / content, country in the anchor text in the country selector menu, backlinks from the relevant country, etc. By aligning those signals Google should be able to identify that you're targeting Ireland with those group of pages.

Finally, from a user standpoint, what you can do as a backup is to identify users IP, and if you see that a UK user lands in the Ireland version of a page that exist in Ireland, to show a non-intrusive banner saying "This is the Irish version but we have this product in the UK, click here to go there." and if the product is not available at all for UK users, only to Irish, to show a message along the lines of "We see you might be coming from the UK, but this product is only available to be delivered in Ireland. Go here to see similar products for UK customers." I would recommend you to track these clicks/interactions by users to identify which products are most requested but not available there yet so you can enable them there in the future.

I hope this helps!