There are times when you as a site owner might want to cater to more than one language for your content. There are a lot of different ways to go about it. I’ve seen sites that essentially have two sites, prefaced by a country code. I’ve seen sites with different country code top-level domains. I’ve even seen sites that dynamically swap content via scripts when the user clicks a button.
The easiest way to establish a multilingual site is to have two versions of the site. The question is, though, how do you display those sites?
Third Things First
Before I address the specific question in the title, I want to point out that there’s a third option; country code TLDs. These are called ccTLDs, or Country Code Top Level Domains. Normal TLDs are the usual suite of .com, .org, .net, and so forth.
The BEST method to run a multilingual site is to create special versions of the site for each region. For example, if you have a US site, a German site, and a Japanese site, you would have three versions of your website. One would be in English, one would be in German, and one would be in Japanese. They would each have their own URL; www.example.com for the US site, www.example.de for the German site, and www.example.jp for the Japanese site.
You can use two methods of ferrying the appropriate users to the appropriate site. For one, you can have a script that loads on first view for the user, identifying their geographic location based on their IP address and redirecting them to the proper site. The other option is to simply display a map on your homepage that allows the user to choose to go to a different version of the site. Similarly, having a language selector works in a similar way.
There are two main drawbacks to using this method. The first is a matter of upkeep. When you’re maintaining all of these different sites, it’s a lot of work. Code needs to be pushed out for each of them. You need hosting or a CDN that works globally so people aren’t trying to load your site at trans-Atlantic speeds. It’s easy to end up with one site falling behind or breaking, and you might not know about it or fix it right away.
The second drawback is similar; you need to register the TLDs, which means they need to be available and affordable. It’s possible that your agency’s acronym means something else in German and has already been taken, leaving you to lose the symmetry of your branding. Plus, if you forget to keep your payments going for one of them, you can lose one of your sites.
In general, it’s easier but less effective to use a subdomain or subfolder. Both are valid options, and Google can parse them as intended just fine, it just loses a little bit of the cachet you get from mimicking the bigger multinational corporations.
Factors to Consider
Before you can decide whether a subdomain, subfolder, or ccTLD is right for your site, you need to analyze the factors that go into making your multilingual site.
- Are you targeting different countries/regions, or just a multilingual community?
- How many different languages are you targeting?
- Are you intending to translate content manually, or use a plugin to do the heavy lifting?
- How do you handle mobile sites?
- Are you handling global commerce, or just information?
Once you figure out the answers to these questions, you can begin to decide what format you want your site to take. So let’s go over each of them individually.
Are you targeting different countries/regions, or just a multilingual community?
These are two very different scenarios. For example, many areas in the United States have significant populations that speak Spanish as a primary language. In order to serve a community, city and state services might have multilingual sites that function in both English and Spanish. They don’t need to actually reach or target Spain, Mexico, or any of the other areas that speak Spanish in the world, since the information and purpose of the site is purely local. The same goes for many areas in Canada, where French Canadian is a language all it’s own.
You don’t need country codes to identify different languages; subfolders or subdomains will work perfectly fine. You can even name them something more local, rather than using country-based identifiers.
How many different languages are you targeting?
If you’re targeting two languages, like the above examples, you can use just about any setup you want. However, what happens if you want a truly global site that covers 10+ or 20+ different countries and languages? This happens for Europe-wide sites. Take a look at the site for the European union and the drop-down in the corner for language selection. Clicking a different language changes the subfolder of the site.
When you have that many languages, it’s often easiest to use ccTLDs. There are two reasons for this. For one, when you’re that large, you typically have offices in each of your regions, and can assign each region to manage their own site, with prime directives coming from your world headquarters. Second, it simply reduces clutter on the back end. It can get really messy managing a dozen or more distinct versions of a site all from the same hosting control panel.
Are you intending to translate content manually, or use a plugin to do the heavy lifting?
There are plenty of reasons not to go with an automatic translation. Automatic translations are how you end up with things like this. There’s also some evidence to suggest that Google specifically considers automatic translations to be the work of spammers and pushes them down in the search rankings.
That said, if you’re catering to a small bilingual community, you might be able to get away with an automatic translation via one of the translation plugins available with WordPress or whatever other CMS you’re using. For anything larger, though, you should probably avoid automatic translations. If you can’t afford a professional translator, you probably shouldn’t be trying to localize your business to another language.
How do you handle mobile sites?
This is a big one that people don’t often think about. The same subdomain/subfolder question comes up with mobile sites as well. If you have a subdomain for mobile, you can’t really do subdomains for languages, can you? You’d have www.m.eng.example.com and www.eng.example.com and www.m.fr.example.com and www.fr.example.com all at once, and that’s just a giant mess. The same problem comes up with using subfolders for both.
You could use both. www.m.example.com/eng and www.m.example/fr would be mobile versions of the two m-less example sites. It’s cleaner, but it still involves multiple overlapping parameters and means a lot more upkeep of both multilingual pages and mobile pages.
Of course, the best answer is to simply use responsive design for your mobile compatibility, but some people are obstinate and refuse to adapt to new things.
Are you handling global commerce, or just information?
When you’re running an actual business with global shipping and order processing there’s a lot more going on, and it definitely pays to have different teams for different regions. This is a case where using the ccTLDs will pay off.
Subfolders, Subdomains, What’s the Difference?
You know that subfolders are a /folder/ after the .com domain, and you know that a subdomain is a .sub.site.com element of the URL, but what are the actual differences, mechanically?
Subdomains are typically viewed as different websites. www.blog.example.com and www.store.example.com would, typically, be considered different websites. This means they will have different SEO values, different backlink profiles, and so forth. This is generally because of how sites like WordPress.com work, with subdomains given out to each user for their own site.
Subdomains can also be used to divide a site up by primary categories, in essence giving you microsites under the same domain. You could have a tech brand and have a cameras.website.com domain for camera content, a computers.website.com domain for laptop and PC content, and so forth. Each can rank individually, but can cross-link to share value.
Google is generally smart enough these days to identify whether or not subdomains are part of the same site or different sites. They can tell the difference between two unique WordPress.com pages and two subdomains on your blog. Generally, if it benefits you to lump the SEO value of two subdomains together under your domain as a whole, Google will do it.
Subfolders don’t have the split site issue, which is both good and bad. It means if you wanted to actually divide up your content, you wouldn’t be able to. However, it means if you would have issues with Google not parsing your elements as the same site, it would be forced to be the same site.
Subfolders are typically crawled more easily and more often, since that’s how the typical site structure adds new content to URLs. With a proper sitemap, this isn’t a problem, though. Google Analytics is also better at handling multiple subfolders as one site than multiple subdomains.
Which Should You Use?
So, the question becomes, which method should you use?
I generally recommend that you use the ccTLD method if at all possible. It’s easier to organize and it’s easier to hand off to other teams as you grow and expand. You can have dedicated teams with their own hosting access rather than requiring that everyone go through one host.
I do recognize, however, that there are plenty of situations where using ccTLDs doesn’t fit the bill. The geographically local community example is a prominent one where the ccTLD doesn’t work.
In these cases, you should almost always use subfolders. Subdomains lose a lot of power in terms of SEO, which makes a huge different with regards to marketing and search visibility. Moz has done repeated tests over the years and has determined that using subfolders is simply better SEO practice. Moving content from a subdomain to a subfolder, all else being equal, results in an improvement in ranking.
Subfolders free up the most common non-responsive mobile design space as well, which is the m. subdomain. I would venture to say that well over 90% of all mobile sites that are not responsive are themselves using a subdomain, which means if you have a mobile site, a subdomain is probably what you’re using, if it’s not dynamic. Subfolders fit in better this way.
The final option is to use scripts or code to dynamically change the language of the content on your site. I don’t recommend this for a few reasons.
- All of the content would need to exist on the page, which muddies the topic and geographical relevance of the page, making it harder for Google to rank you appropriately.
- There are not reliable ways to make sure all users, regardless of browser, script blocking, and cookie settings, get to the appropriate language without hassle.
- Automatic detection of language can be foiled by proxies or by device settings or location regardless of actual intent.
Of course, in some situations, best practices don’t matter. Government and Education sites in particular often have regulations set by bureaucrats who have no idea what they’re doing, and thus you have to make the best with what you’re given. You might simply have to match what has been used since 1998, and, well, good luck.
