Sunny greetings, dear reader!
Companies that plan to conquer the world with their products and services are usually asking themselves (hopefully), at a very early stage, what to do with their URLs. In this post, I will list the pros and cons, along with my own two Euro cents.
One major buzzword I always hear in discussions about localized URLs is SEO1. From deep within the marketing team, I can hear the urgent plea: “We need localized URLs for increased reach, traffic, conversions, and leads!”.
An URL needs to be trustworthy to users. However, it’s not just your audience that judges you by your URLs; search engines also evaluate your site and brand based on the structure and format of your URLs.
URL structure types for going global
We use the generic top-level domain name “gilt-ninjas” with the domain class “com” as our base – gilt-ninjas.com – and then think of a French audience adding the locale2 “fr”:
Country-code top-level domain (ccTLD): https://gilt-ninjas.fr
Subdomain: https://fr.gilt-ninjas.com
Subdirectory: https://gilt-ninjas.com/fr
Query strings: https://gilt-ninjas.com/help/3456?hl=fr
The company perhaps wants to distinguish between French flavors, like French Canada (fr-ca), French France (fr-fr) and French Belgium (fr-be). Alternatively, they may also want to differentiate between English Canada and French Canada.
Country-code top-level domain: https://gilt-ninjas.ca/fr
Subdomain: https://fr-ca.gilt-ninjas.com
Subdirectory: https://gilt-ninjas.com/fr-ca
Query strings: https://gilt-ninjas.com/help/addninjas/3456?hl=fr-ca
According to Google3, ccTLDs are strong indicators for users and search engines that the website is targeting a specific country. They seem to have some SEO advantages as well. However, it can be very costly for a company to buy all domains for their domain name. If a company goes this route, the question is: where to start and where to end with buying domains?
I am not yet diving into another decision: buying the most common TLDs like .org or .net. Additionally, there are plenty of new ones out there, such as .rocks or .sucks. While I would love to see GILT-Ninjas.rocks, the latter one I am not a fan of. As you can see, this becomes an endless spiral.
With ccTLDs, each one clearly states the country the content is targeting. Some countries require residency in the specific country to register the ccTLD. While everyone worldwide can register domains like .de or .es, there are certain restrictions for domains like .no or .us.
If your company uses subdomains based on the main domain, then only the subdomain changes. This is an easy and quick way to build multiple domains for different languages. Check out Wikipedia, they use the subdomain for different locales and they translate the path. However, subdomains might also be used as separate brands within the main brand, like forum.gilt-ninjas.com and news.gilt-ninjas.com. This approach can help users navigate through large company sites with many different brands. In such cases, it would make sense to add the locales as subdirectories. Keep in mind that subdomains have character limits, so you might need to factor that in as well.
Another solution is subdirectories. Many companies use this approach, and it might even be the most common one. With subdirectories, also known as subfolders, the domain does not change; instead, a subfolder is added. This makes the URL straightforward and easy to navigate. If the visitor of your website likes to change the language, it can be easily done in a heartbeat (and personally, I do it often – am I the only one?).
For example
Visiting the Canadian French page: https://gilt-ninjas.com/fr-ca/contact
Changing it to German is easy: https://gilt-ninjas.com/de-de/contact
Changing the locale parameter only works with languages that you support and have content for. If you start out by supporting only three languages, you can implement a fallback to your main language for all non-supported languages with the help of your trusted development team.
How about query strings? I have only seen query strings used for support documentation, such as articles and manuals. Query strings allow for a more refined search, which makes total sense if you have a support center or another hub for all your help documentation.
Let’s say you’ve opted for the subdirectory solution. Now, you’re considering implementing URLs in different languages. You might hear the marketing choir singing the SEO tune in the background … but let’s not go there. In my personal opinion, localized URLs are a logistical nightmare that eats up plenty of resources to maintain.
For example
https://gilt-ninjas.com/en-us/successstories/sales
https://gilt-ninjas.com/de-de/erfolgsgeschichten/vertrieb
In this way, we can’t simply change “en-us” to “de-de”; it becomes less intuitive not only for your users but also for your content writers who use URLs for linking within your content. You would need to maintain an entire database with all your URLs in all languages for your content writers and translators. Only then will translators and target content writers be able to use the correct URLs, for example, in a teaser or a sales pitch.
Automation and redirecting
Automation is what you want. You don’t want anyone but your automation messing with the URLs, not even your trusted translators. The more you leave your URLs out in the open to be altered, the more errors can happen. I understand the frustration – we all roll our eyes when a link doesn’t work as expected or the content fails to show up, instead displaying one of those funny error messages.
Have the locales automatically added into every URL; ask your developer to help you with that. You can also decide whether the content should be displayed based on the user’s language settings of the computer or browser. Just don’t enforce it; if the user wants to change the language, allow them to do so. There is nothing more annoying than trying to change the language and the system not allowing it. After all, who are we to determine what language the audience really wants at any given time?
If you have a platform where users need to sign in to access your content, you can have the backend register the user’s last used language and use it again the next time. However, ensure that users still have the option to change the language and don’t enforce it to the point where they have no way of doing so.
In researching this article, I’ve read extensively about SEO and URLs, and it seems that people are divided on which URL structure brings the best results. Please don’t view this post as an indicator of what to do. Personally, I believe that ccTLDs, subdomains, and subdirectories all have their pros and cons, and it’s up to each company to decide which route to take based on their preferences and needs.
Side note: A URL structure I have not mentioned yet is the cousin domain, also called a look-alike domain. Staying with our example, a cousin domain looks like this: https://gilt-ninjas-marketing.com or https://gi1t-ninjas.com. The cousin domain is a new domain but resembles domains that we trust and believe in. Cousin domains are often used for phishing attacks to steal confidential and sensitive data from users. It goes without saying, cousin URLs are not recommended at all.
Are localized URLs really worth it?
gilt-ninjas.com/es/ventas instead of gilt-ninjas.com/es/sales
They can make your presence more trustworthy and understandable for your audience, as it is more native to read; they might even make it more search engine friendly4. I’m hardly an SEO expert (people out there earn serious money with their SEO know-how), but from my perspective, which comes from the localization management side, I’ve experienced logistical nightmares when dealing with localized URLs.
In addition, consider this: on mobile experiences, you hardly see any URLs. So users couldn’t care less about seeing localized URLs when using their tablets or mobile phones. We also need to consider security aspects like phishing emails and websites. Creating trustworthy URLs makes it easier for backend systems to find and flag the devious ones.
What I’d like you to take away from this post is to think twice before localizing keywords in the paths of your subdirectories, slugs5, or subdomains. Look at the big players like Apple, Microsoft, and Google – none of them are using localized URLs. They must be on to something!
- Search engine optimization (SEO) is the process of improving the quality and quantity of website traffic to a website or a web page form search engines ↩︎
- Wikipedia knows what a “locale” is and if you are curious, the difference between locale and language ↩︎
- https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites#locale-specific-urls ↩︎
- URLs seem to play only a minor factor when it comes to search engines – moz.com and searchenginejournal.com – but geo-targeting can give you an advantage ↩︎
- A slug is part of the URL, often readable content and usually at the end part of the URL ↩︎