Understanding the construction of multi-regional sites
The problem of creating websites with different versions of languages and countries is by no means new, almost all major sites have long been faced with it. Each company chooses its solution, we briefly discuss the main options and see how to solve this problem in the best way.
Of course, there are more groups in life, for example, some sites store regional settings in cookies, while others pass by the parameter? Lang = ru, but these are unpopular decisions and the main ones are:
1. Version of the site on another domain:
')
2. Site version on the subdomain:
3. Site version in the subdirectory:
A frequently asked question, especially among administrators who are confronted with the task of creating a multi-regional site for the first time, is which approach to use to build a URL structure. It is impossible to give an unequivocal answer, too many different factors influence the decision, however, the subjective opinion is this: if your site for different countries and languages will work on the same engine, use the third option. It is much more convenient for a typical project, besides, such giants as microsoft, ibm, apple and many others work along the same lines. Detailed information on the construction of the URL structure is easily located on the websites of search engines, so it makes no sense to dwell on it in detail.
So, we want to create a site that will, let's say, work in Russia, Ukraine and the United States. The languages in which our site will operate will be Russian, Ukrainian and English. To build the URL structure, we take the third option.
Usually, Google and Yandex examples contain simple and limited schemes of work, such as: in the USA we show the site in English, in Russia - in Russian, in France - in French and so on:
However, in real life there are new questions. What to do for Ukraine, what language will we show? There are Russian and Ukrainian. Well, no problem, add a new bunch.
And if you want to run a version of the site also in Canada? Add more options with English and French:
In short, we find out what languages we will provide for the territory we need and add bundles “language - country”.
By this scheme, by the way, versions of the websites of the mentioned companies also work:
Microsoft: www.microsoft.com/home/en-ca/locale.aspx
Apple: www.apple.com/choose-your-country
IBM: www.ibm.com/planetwide/select/selector.html
It would seem, here it is, the ideal scheme of work, especially as the largest companies work on it - and there, smart heads are sitting, they have thought of everything. However, not all so simple. Although we are close to building a multi-regional site, we still have problems that will become more and more important in the light of growing cosmopolitanism and internationalization.
Let's return to our original example. It is obvious that many Russian-speakers live in the USA and many of them will prefer to work with the Russian-language version of your site. The option “let them go to the Russian version of the site, example.com/ru-ru/” is incorrect, because they want to see, for example, the prices on your site in dollars, see the American phone, address and other contact information, in general, see all the same as the visitors of example.com/en-us/, but at the same time everything should be in Russian.
Well, you can create another bundle of language with the country:
Yes, but there will be Ukrainian emigrants who will prefer to work on the American version, using the Ukrainian version of the site. Naturally, many at this stage will give up and say “they will be few, they will cost.” However, what is the point of reducing the convenience of working with the site, because the convenience of users is attachment to your site, if a person is more comfortable to read in Ukrainian, he will most likely prefer your site to a similar competitor site. Moreover, we already have a translation into Ukrainian, what problem is it to add? Well, we do another version:
So, stop, and there are those who moved from the USA to Russia, why not give them the opportunity to work in English? But there are still probably Ukrainian-speaking people living in Russia. All these examples lead us to the fact that the correct scheme of the site is obtained when I myself can choose the language and region.
Here, for example, the site of Microsoft. A simple analysis shows that we are offered 96 “language-country” bundles, with 38 languages and 93 countries. That is, you can choose another language for just a few countries, for example, for Canada (English and French). This is ridiculous, but with a huge number of Russian-speaking residents in Ukraine, you can only choose:
Russia russian
ї - ї
And that's it! There is simply no way to choose "Ukraine-Russian", despite the fact that most of the population speaks Russian. If Microsoft offered all possible languages for any country, it would have to place 93 × 38 = 3534 bundles "language - country" on the selection page. Naturally, finding the right page with such a sheet of text will be difficult.
A similar rigid structure works for those mentioned by Apple and IBM.
And the conclusion is very simple - do not create hard bundles of languages and countries. When you first enter the main page, we automatically determine the user's IP and country. Since in almost all cases it will be enough to determine only the country (we don’t need a city yet), you can use free databases provided by, for example, MaxMind. Based on the country of the visitor, we show him the version of the site in the most common language in this country. And then the users themselves will choose which language is more convenient for them to work.
Google and Yandex give the site owner the opportunity to explain to the search engine that the site works for different countries and languages, supporting the attributes rel = "alternate" hreflang = "x". Thus, if your site has a free choice of country and language, all possible options should be added to each page. This should help the search engine to figure out which page in the search results should be shown to the user. For our example, this would be:
upd. In the case of Microsoft, 3535 lines would have to be added to each page of the site. In order not to add so many tags to the page, it is better to place them in the site map . It looks like it only works for Google. The response to the request in Yandex is: “The indication of regional markup in the sitemap file is not currently supported by us.”
If you need mandatory support for both search engines, an acceptable option in this case is the closure of all pages from indexing, except for the main link "language - country". Then, for example, instead of the last three lines from the example above, only
Of course, this will lead to the fact that the Russian-speaking user in the United States will not see the page in the search results
Most likely, he will be offered one of these pages:
However, even in this case, we leave the possibility to change the language or country to the user’s right, therefore, ultimately, the localization problem will be solved.
Most of the sites suggest their work in several countries and a maximum of 3-4 languages, so you can safely donate the addition of a dozen lines with tags for all versions of the site. From Wikipedia you can get the correct codes of languages and countries .
URL construction options
Of course, there are more groups in life, for example, some sites store regional settings in cookies, while others pass by the parameter? Lang = ru, but these are unpopular decisions and the main ones are:
1. Version of the site on another domain:
')
example.com, example.ru 2. Site version on the subdomain:
ru.example.com, ua.example.com Very similar to the previous version, but easier to administer. These two options are easily implemented on physically different hosts, so they can be placed in different countries.3. Site version in the subdirectory:
example.com/ru/, example.com/ua/ The easiest way, but divided into different servers more difficult.A frequently asked question, especially among administrators who are confronted with the task of creating a multi-regional site for the first time, is which approach to use to build a URL structure. It is impossible to give an unequivocal answer, too many different factors influence the decision, however, the subjective opinion is this: if your site for different countries and languages will work on the same engine, use the third option. It is much more convenient for a typical project, besides, such giants as microsoft, ibm, apple and many others work along the same lines. Detailed information on the construction of the URL structure is easily located on the websites of search engines, so it makes no sense to dwell on it in detail.
The concept of a multi-regional site
So, we want to create a site that will, let's say, work in Russia, Ukraine and the United States. The languages in which our site will operate will be Russian, Ukrainian and English. To build the URL structure, we take the third option.
Usually, Google and Yandex examples contain simple and limited schemes of work, such as: in the USA we show the site in English, in Russia - in Russian, in France - in French and so on:
example.com/en-us/ example.com/ru-ru/ example.com/fr-fr/ However, in real life there are new questions. What to do for Ukraine, what language will we show? There are Russian and Ukrainian. Well, no problem, add a new bunch.
example.com/uk-ua/ And if you want to run a version of the site also in Canada? Add more options with English and French:
example.com/en-ca/ example.com/fr-ca/ In short, we find out what languages we will provide for the territory we need and add bundles “language - country”.
By this scheme, by the way, versions of the websites of the mentioned companies also work:
Microsoft: www.microsoft.com/home/en-ca/locale.aspx
Apple: www.apple.com/choose-your-country
IBM: www.ibm.com/planetwide/select/selector.html
It would seem, here it is, the ideal scheme of work, especially as the largest companies work on it - and there, smart heads are sitting, they have thought of everything. However, not all so simple. Although we are close to building a multi-regional site, we still have problems that will become more and more important in the light of growing cosmopolitanism and internationalization.
The problem with immigrants and highly mobile people
Let's return to our original example. It is obvious that many Russian-speakers live in the USA and many of them will prefer to work with the Russian-language version of your site. The option “let them go to the Russian version of the site, example.com/ru-ru/” is incorrect, because they want to see, for example, the prices on your site in dollars, see the American phone, address and other contact information, in general, see all the same as the visitors of example.com/en-us/, but at the same time everything should be in Russian.
Well, you can create another bundle of language with the country:
example.com/ru-us/ Yes, but there will be Ukrainian emigrants who will prefer to work on the American version, using the Ukrainian version of the site. Naturally, many at this stage will give up and say “they will be few, they will cost.” However, what is the point of reducing the convenience of working with the site, because the convenience of users is attachment to your site, if a person is more comfortable to read in Ukrainian, he will most likely prefer your site to a similar competitor site. Moreover, we already have a translation into Ukrainian, what problem is it to add? Well, we do another version:
example.com/uk-us/ So, stop, and there are those who moved from the USA to Russia, why not give them the opportunity to work in English? But there are still probably Ukrainian-speaking people living in Russia. All these examples lead us to the fact that the correct scheme of the site is obtained when I myself can choose the language and region.
Here, for example, the site of Microsoft. A simple analysis shows that we are offered 96 “language-country” bundles, with 38 languages and 93 countries. That is, you can choose another language for just a few countries, for example, for Canada (English and French). This is ridiculous, but with a huge number of Russian-speaking residents in Ukraine, you can only choose:
Russia russian
ї - ї
And that's it! There is simply no way to choose "Ukraine-Russian", despite the fact that most of the population speaks Russian. If Microsoft offered all possible languages for any country, it would have to place 93 × 38 = 3534 bundles "language - country" on the selection page. Naturally, finding the right page with such a sheet of text will be difficult.
A similar rigid structure works for those mentioned by Apple and IBM.
And what is the conclusion?
And the conclusion is very simple - do not create hard bundles of languages and countries. When you first enter the main page, we automatically determine the user's IP and country. Since in almost all cases it will be enough to determine only the country (we don’t need a city yet), you can use free databases provided by, for example, MaxMind. Based on the country of the visitor, we show him the version of the site in the most common language in this country. And then the users themselves will choose which language is more convenient for them to work.
And how will search engines respond to this diversity?
Google and Yandex give the site owner the opportunity to explain to the search engine that the site works for different countries and languages, supporting the attributes rel = "alternate" hreflang = "x". Thus, if your site has a free choice of country and language, all possible options should be added to each page. This should help the search engine to figure out which page in the search results should be shown to the user. For our example, this would be:
<link rel="alternate" hreflang="x-default" href="http://example.com/"> <link rel="alternate" hreflang="ru-ru" href="http://example.com/ru-ru/"> <link rel="alternate" hreflang="ru-us" href="http://example.com/ru-us/"> <link rel="alternate" hreflang="ru-ua" href="http://example.com/ru-ua/"> <ink rel="alternate" hreflang="uk-ru" href="http://example.com/uk-ru/"> <ink rel="alternate" hreflang="uk-us" href="http://example.com/uk-us/"> <ink rel="alternate" hreflang="uk-ua" href="http://example.com/uk-ua/"> <link rel="alternate" hreflang="en-ru" href="http://example.com/en-ru/"> <link rel="alternate" hreflang="en-us" href="http://example.com/en-us/"> <link rel="alternate" hreflang="en-ua" href="http://example.com/en-ua/"> upd. In the case of Microsoft, 3535 lines would have to be added to each page of the site. In order not to add so many tags to the page, it is better to place them in the site map . It looks like it only works for Google. The response to the request in Yandex is: “The indication of regional markup in the sitemap file is not currently supported by us.”
If you need mandatory support for both search engines, an acceptable option in this case is the closure of all pages from indexing, except for the main link "language - country". Then, for example, instead of the last three lines from the example above, only
<link rel="alternate" hreflang="en-us" href="http://example.com/en-us/"> Of course, this will lead to the fact that the Russian-speaking user in the United States will not see the page in the search results
example.com/ru-us/ Most likely, he will be offered one of these pages:
example.com/ru-ru/ if will search in Russian, and example.com/en-us/ if will search in English.However, even in this case, we leave the possibility to change the language or country to the user’s right, therefore, ultimately, the localization problem will be solved.
Most of the sites suggest their work in several countries and a maximum of 3-4 languages, so you can safely donate the addition of a dozen lines with tags for all versions of the site. From Wikipedia you can get the correct codes of languages and countries .
Source: https://habr.com/ru/post/177089/
All Articles