Choose a URL for a multilingual site

When creating a website in multiple languages, the question of how to specify the language in the URL arises at one point. For the French version of a website, the choice will often be made between:

• https://mywebsite.fr : use a top-level domain
• https://mywebsite.com/fr : use of the access path
• https://fr.mywebsite.com : use of the subdomain

I will review these possibilities (knowing that there are others but these are for me the most representative) to present what they imply as interesting points and as points of vigilance, in order to guide you in your technical choices for a multi-language website.

1. Language as a 1st level domain (TLD)

This is a URL of type https://mywebsite.fr ("fr" is the TLD, the Top Level Domain).

Interesting points

• By using the TLD to specify the language, the site will truly be seen by search engines as a full-fledged website , and not a variation of an existing site, since it this is a different address. This can promote SEO, much like brands creating multiple entities for the same product.

• You can redirect each domain name to a physical server quickly. This server can thus be adapted (in memory, performance and disk capacity, etc.) according to the uses of the website. You can also deploy a site update or stop it without impacting other versions of the site. The other solutions can also lend themselves to this but require adaptation.

Vigilant points

• It will be necessary to reserve each domain name , and therefore to pay, with possible variations of amounts according to the extensions, and possibly unavailability of the domain name according to the TLD. You will also need an SSL certificate (for https) on each domain name , and therefore pay (unless you go through a free solution like Let's Encrypt).
• At the referencing level, a search engine can favor the TLD referring to the country of the user to first offer the sites that are geographically closest. For a Swiss, a ".fr" site could therefore weigh less than a ".ch" site.
• Also at the referencing level, as each version of the site is seen as independent from the others, it will be necessary to work on the referencing of each version .
• As the TLD represents a country and not a language , you have to think carefully about the targeted positioning. For a French site, taking https://mywebsite.fr seems to be justified if you say that fr = French, but for English, should you take ".us" or ".en "? Unless you create a site representing a country, for a brand for example, I think you should avoid using the TLD as a discriminator.

2. Language in the path

This is a URL of type https://mysite.com/fr ("fr" is the access path).

Interesting points

• There is no additional cost for reserving domain names and certificates : you only use one domain name and one certificate for all languages manage.
• This solution is apparently quick to set up because the access path is more flexible to handle than a domain name (everything obviously depends on the content management system you use ).
• You can choose to use whatever term you want to distinguish between languages: "fr", "fre", "french", "francais" ...

Vigilant points

• It is preferable to use here an international TLD (like ".com", ".org" ...). If the site has a ".fr" as TLD, we will have a French site with the URL https://mywebsite.fr/fr . It may look weird but does not interfere with the operation.
• The links on the site must start with "/ fr /" or "/ en /", in order to keep the information of the language used. All types of pages like articles, lists of articles, searches, Ajax calls, accounts will have to manage this syntax. This therefore makes the routing of the links more cumbersome because they include each time the different possible languages. If you are doing URL rewriting and depending on the number of different links available, this can add complexity in implementation and maintenance.
• You must redirect the home page to be in the user's language. Here is a method to put in the .htaccess file to retrieve the user's language and redirect to the correct home page:
  
  # Redirects according to the home page and the language of the user
  RewriteCond %{HTTP:Accept-Language} ^fr [NC]
  RewriteRule ^$ /fr/ [L,R=301]
  
  # English version for others
  RewriteRule ^$ /en/ [L,R=301]

3. Language as a subdomain

This is a URL of type https://fr.mywebsite.com ("fr" is the subdomain).

Interesting points

• This solution does not require several domain name reservations : you only use one domain name for your different versions of the site
• It is possible to reuse an SSL certificate (https) if it is of the wildcard type, i.e. it applies to all subdomains of the site. Otherwise, you will need a certificate per subdomain (which requires purchasing them and renewing when necessary).
• You can choose to use whatever term you want to distinguish between languages: "fr", "fre", "french", "francais" ...
• You can use global access paths to several versions of the site: https://fr.mywebsite.com/info and https: //en.mywebsite.com/info point to the same file.

Vigilant points

• You must create a subdomain per language . Very often, this management is done at the administration level of the server, by creating a type A DNS entry. This is a fairly quick operation, so it is not really a disadvantage.
• Care must be taken that the website cache system manages subdomains independently. Thus, for an article, if the access path is the same in between several languages, it is necessary to verify that the displayed text corresponds to the requested subdomain.
• You must create a sitemap file and an RSS feed per language and redirect them according to the requested language. For example, you can use the code below in an .htaccess file, which retrieves the subdomain and redirects to the correct sitemap and RSS feed (case of a sitemap_francais.xml and a sitemap_english.xml):
  
  # Creates a parameter retrieving the language according to the URL of the site
  SetEnvIf HOST ^(fr) url_sitemap=sitemap_francais.xml url_rss=rss_francais.xml
  SetEnvIf HOST ^(en) url_sitemap=sitemap_english.xml url_rss=rss_english.xml
  
  # **************** SITEMAP *****************
  RewriteRule ^sitemap\.xml$ /xml/%{ENV:url_sitemap} [L]     
     
  # **************** RSS *****************
  RewriteRule ^rss\.xml$ /xml/%{ENV:url_rss} [QSA,L]
• Attention should also be paid to cookies and their level of access. Depending on the configuration used to define a cookie, it may or may not be accessible from another subdomain: if the domain field does not contain a subdomain, a single cookie will be accessible from all subdomains.

Conclusion

From my own experience, the second proposition is at first glance the easiest to set up for a small website. However, as this one is enriched in functionalities, the rewriting of URL will be more and more complex and the 3rd proposal will present a saving of time.

As for the first proposal, it is in my opinion to be implemented for large-scale sites, in order to manage them independently. At this level, it will no longer be a question of managing languages but of localization according to countries.