There are many, many articles written about the right Top Level Domain (TLD) Strategy, most of them giving insights about the pros and cons of each possibility. Even Google itself are quite detailed about this one.
As SEOs we are drifting more and more into the tech area. This is where SEO came from, this is where it ends up again. It’s a big advantage to know technical details about what you’re doing, as it will save time and frustration when communicating with your dev team about tasks. That means, you should not only know WHY we chose a certain TLD strategy – you should also be aware of the technical setup that is needed.
Some words about server architecture
Let’s have a look at the different possibilites. Basically, there’s two main options:
- a) One server per country.
- b) One server that contains content from all countries.
When thinking about servers from an SEO’s perspective, the first thought will go to the server response time. The more time a page needs to answer a request, the slower your content is loaded, which in turns will increase a user’s probability to leave the page. No need to go more into detail why this should be avoided.
It makes sense that if a server is located far away from a user, the data will need more time to get from A to B. Therefore, in many cases the launch of a website in a new market is accompanied by setting up a server located in that specific area.
Now how is this influenced by the TLD strategy?
The following table gives an overview:
|TLD Strategy||Example||Server Solution|
|ccTLD||https://www.zalando.co.uk||1. One server for each country acting as own entity
2. One server containing content of countries that are located in small distance (e.g. for countries in central Europe)
|gTLD with Subdomain||https://uk.hotels.com||Same solutions as above can be applied.|
|gTLD with Subdirectories||https://www.ikea.com/gb/en/||1. Cloned servers in each country, that are synchronizing in set intervals.
2. One global server in one country & Reverse Proxies in each individual area. Those proxies could either contain a cached version of the complete domain and let a user decide which version they like to see, or they could work with redirects to the right subdirectory depending on the IP of the user.
One important thing here: For sure, there are many more ways how different TLDs can be handled in terms of server structure! The solutions above are just some possibilities. Have a look at the example pages to find out if they use the given solution or maybe something else.
To wrap it up, the TLD strategy will have an impact on the way how you’ll organize your servers, because you want your user to experience a fast loading time. It might lead you to rethink how you’re organizing your website as a whole, who you need to consult with to find the best suiting server architecture and how much budget you can allocate for the different solutions.
Got any input or your own experience to add? Let me know.