Managing different websites for different regions

[dynambee]

Note: I'm writing this out in the hopes of gaining feedback, sharing ideas, and to help get my own thoughts on this subject straight in my mind.

Is anyone here running separate websites targeting different regions or different countries?

This is something I want to do for a few different reasons. The short version is accurate pricing across multiple currencies, seasonal product targeting across different hemispheres, different payment processors for different websites, and being able to locate the physical server in or close to the target country or countries for maximum site performance.

So I've been doing a little research about how to best go about this. Google has some info which is a good place to start.

For me I see three different ways to set this up, each with benefits and drawbacks:

1. Using subdomains such as au.mydomain.com and ca.mydomain.com to target different countries. This is one of the solutions that Google recommends and it is definitely the cheapest & easiest solution to set up. Trying to find a good name with domains available in a bunch of different extensions is a giant PITA so just using one domain with subdomains is quite an attractive idea. Cheaper, too.

On the downside it seems likely to be confusing for customers. If they make their account on au.mydomain.com and then try to log in to ca.mydomain.com or us.mydomain.com the login won't work. Worse, there is no easy way to notify customers that their login exists on another of the subdomains and that they should try there. If they end up making separate accounts on separate subdomains their order information won't be shared between the different accounts.

Another problem is how to direct customers to the appropriate website / subdomain. My original intention was to use IP geolocation to do this but Google specifically states that this is a bad idea:

Quote

Do not use IP analysis to adapt your content. IP location analysis is difficult and generally not reliable. Furthermore, Google may not be able to crawl variations of your site properly. Most, but not all, Google crawls originate from the US, and we do not attempt to vary the location to detect site variations. Use one of the explicit methods shown here (hreflang, alternate URLs, and explicit links).

 

2. Go with entirely separate but related domains. Ideally mydomain.au, mydomain.eu, mydomain.com, etc. However this is likely to be impossible to do cleanly so it will probably end up being more like mydomainaus.com, mydomain.com, mydomaineu.com, etc. It's often visually unattractive, and not necessarily hugely more effective at helping customers notice that the sites (and logins) are separate from each other. If someone remembers "mydomain" they might not necessarily remember exactly which "mydomain" they bought from.

 

3. Go with entirely different and completely separate domains. All domains would be related to the products being sold but would have separate branding. widgetdepot.com, widgetgalaxy.uk, bestwidgets.com, etc. This would be the cleanest overall solution visually and would avoid confusion between the different sites. The main downside to this is having to maintain separate brand identities for each website. No ability to share social media platforms, no global brand awareness, no shared logos, no shared email, etc. This was actually my original plan of action but I like it less and less the more I consider the various options.

 

Right now I'm thinking that option #1 is probably the best overall option. It allows for shared branding, shared social media, and yet keeps the sites separate. Customer confusion is a concern, but I have an idea that should help reduce that without screwing up the Google indexing process. I'll detail that idea in a separate reply below.

So, I'd love to hear from anyone doing this, or thinking about doing this. How did you solve the different site problem? How did you avoid causing problems with Google indexing?

 

[dynambee]

So, how to solve the issue with option #1 where customers have confusion between sites.

First would be a pop-up shown to guest customers who are likely visiting the "wrong" site. It would suggest that they would find better prices and have a faster shopping experience if they visit the site for their country or region. Customers would be able to choose to stay on the current site or change to the closer site.

Second would be during the login process and this would require site modification as well as some extra code in my custom automation system. Basically my automation system would regularly check for new customers on each of the subdomain websites. It would then maintain a database of email addresses and site IDs that would be shared between each of the subdomain sites. When a customer login fails on one site but the email address exists on another site the customer would be shown a message along the lines of, "Your login failed on us.mydomain.com but it looks like you might have an account on au.mydomain.com. Click here to be redirected to au.mydomain.com for login."

Likewise people would be blocked from creating accounts with the same email address on multiple subdomain sites. This would further help avoid cross-site confusion.

I think this sort of solution would probably remove most of the downsides of using subdomains for different countries.

Thoughts?

[datakick]

I can only comment from technical point of view. Using subdomains will significantly simplify the implementation. You will be able to share cookies, use cross-domain ajax requests, etc. If you use different domains then browsers will put a lot of security-related obstacles in front of you. They can be solved, of course, but it's a lot more work. 

[dynambee]

2 hours ago, datakick said:

I can only comment from technical point of view. Using subdomains will significantly simplify the implementation. You will be able to share cookies, use cross-domain ajax requests, etc. If you use different domains then browsers will put a lot of security-related obstacles in front of you. They can be solved, of course, but it's a lot more work. 

The sites are going to be functionally separate (no shared accounts etc) and will be hosted on separate servers in geographically diverse locations. The AU and NZ sites will be hosted in Sydney, the US site somewhere in the US, the UK site in London, etc. Apart from a drop-down where people can select the site to use there won't be too much connecting them together. At least, that's the intention currently.

[shoptechmedia]

On 9/19/2019 at 3:52 PM, dynambee said:

The sites are going to be functionally separate (no shared accounts etc) and will be hosted on separate servers in geographically diverse locations. The AU and NZ sites will be hosted in Sydney, the US site somewhere in the US, the UK site in London, etc. Apart from a drop-down where people can select the site to use there won't be too much connecting them together. At least, that's the intention currently.

We have developed websites like that.. they do it with the extension instead of the subdomain thing.. example mysite.dk for denmark and mysite.uk for UK.. the system automatically displays the correct website where the customer is located, unless he specified it.. but have not done it the way you mentioned like checking if somebody already have an account in other locale. It's a cool concept though..

[dynambee]

3 hours ago, shoptechmedia said:

they do it with the extension instead of the subdomain thing.. example mysite.dk for denmark and mysite.uk for UK..

I'd like to do it this way but trying to find a single domain that is available across so many different ccTLDs is extremely difficult. Add in that some countries (cough, Australia, cough) make it very difficult to buy domains with their ccTLD and it becomes even harder. So if I do go this route (which seems likely) I'll likely end up with the uk.mysite.com, eu.mysite.com, au.mysite.com, etc setup. The main site will be www.mysite.com and be priced in USD.

 

3 hours ago, shoptechmedia said:

the system automatically displays the correct website where the customer is located

How do you manage this? With IP geolocation? Google doesn't seem to like that and states that in some cases it can prevent sites from being properly indexed and properly displayed in search results. 

 

4 hours ago, shoptechmedia said:

but have not done it the way you mentioned like checking if somebody already have an account in other locale. It's a cool concept though..

Just trying to think of ways to make things as smooth and frustration-free as possible for customers, especially customers that might not be particularly tech-savy.

 

[shoptechmedia]

9 minutes ago, dynambee said:

How do you manage this? With IP geolocation? Google doesn't seem to like that and states that in some cases it can prevent sites from being properly indexed and properly displayed in search results. 

 

You set it in Localization .. Set language from browser.. The browser determines that according to your location.

Edited September 20, 2019 by shoptechmedia

[dynambee]

16 minutes ago, shoptechmedia said:

You set it in Localization .. Set language from browser.. The browser determines that according to your location.

I had thought about that too but Google recommends against it. Settings like that can prevent the Google bot from crawling some sites and they may not be able to crawl all the different language versions. That could result in people searching in (for example) German or French not seeing results for the German or French versions of the site.

[lesley]

I have several clients that do this. Some of them do it wrong and some of them do it right. If it were me doing it I would either rely on a sub domain for each store or a / for each store. like store.com/us, store.com/ca. One of those would be the best move.

Another important consideration is putting people from the right country in the right store. We started using the cloudflare api for that a while back, it is pretty solid on geolocation and is free. @datakick even ended up making a module for it.

 

The third thing I would do is make sure every store can ship to every location. That reduces the hassle of people traveling and not being able to order. 

[dynambee]

13 hours ago, lesley said:

I have several clients that do this. Some of them do it wrong and some of them do it right. If it were me doing it I would either rely on a sub domain for each store or a / for each store. like store.com/us, store.com/ca. One of those would be the best move.

Yup, I have settled on the idea of different subdomains for each store. It's the best overall solution for my situation and I only need to have one domain for each product line.

 

13 hours ago, lesley said:

Another important consideration is putting people from the right country in the right store. We started using the cloudflare api for that a while back, it is pretty solid on geolocation and is free. @datakick even ended up making a module for it.

How does that work with Google (et al) crawling the shops? Does it allow them to crawl shops in other countries? Pretty much all the google crawlers come from the US and Google says that forcing redirection based on geolocation is likely to result in their bots not being able to properly crawl all variations of a site. If Cloudflare doesn't force-redirect the various search engine crawlers it would be the ideal solution, especially since I'm already a very happy Cloudflare customer. 🙂  (And I'm glad to see you're more positive on Cloudflare these days too!)

 

13 hours ago, lesley said:

The third thing I would do is make sure every store can ship to every location. That reduces the hassle of people traveling and not being able to order. 

Absolutely! We have shipped to over 70 countries so far and will happily ship just about anywhere the post office will deliver to with tracking.