SEO Suite

Overview

Search engine optimization or SEO is a set of actions aimed at improving a website's positioning in the search results list from Google, Bing and other Internet search engines. SEO deals with technical aspects like optimizing the website's structure and metadata, but is also applied to its content, in order to make it more relevant to users.

The system as a whole is headless, i.e. it does not necessarily need a user interface, but in practice most Commerces have a graphic interface. Therefore, to meet the above-mentioned expectations a series of tools and strategies is provided to facilitate and simplify handling SEO.

Metadata

In general, the concept of "metadata" refers to data that give information about other data: what they are, what they are for and so on. On the Internet, HTML metatags indicate to search engines some of these metadata providing information about the content being viewed.

For the main content elements in the Commerce (areas, categories, products, pages, blog, etc.) the following metadata can be configured for each of the languages enabled (see the Languages section):

• Title: Text to be displayed as the title of the window including the content of the element being viewed.

• Description: Brief description of the element being viewed.

• Keywords: Set of words separated by commas that describe the content being viewed in the form of tags.

• Robots: Tells search engine indexing robots whether the content being viewed should be indexed or not (index or noindex) and whether the links included in the content should be followed or not (follow or nofollow).

The HTML tag used for images can have an attribute called "ALT" (alternate text), which contains a brief description of the image. Indexing robots use this attribute a lot and it can therefore be configured for each of the images.

The system has metadata bulk entry tools in place to simplify the process, as well as the corresponding block of metadata information in the section for each content element that exists in the BackOffice.

Languages

In general, a Commerce can be multilingual. This means that the same content can be viewed in different languages (there are different browsing languages). The number of languages available will depend on the type of Commerce and how it is configured.

The browsing language is one of the features the system stores internally and associates with the user to avoid having to report which language content is to be returned in for every request. Unless this is changed, the system returns content in the language stored. The change of language is implicit in the structure of the URL, i.e. the URL itself specifies the language in which the content is to be returned, either because it includes a specification of the language (see Language in URL) or because it is originally created for a specific language (see friendly URLs). When the browsing language is changed because there is a URL defined in another language, the system stores the new language and, in subsequent requests, serves content in this language.

In general, when a resource is requested from the system, it returns content in a particular language and automatically provides the URLs for this same resource in the other languages enabled. It does this so that the presentation layer knows how to call the resource in any of these languages. With this information, for example, a web presentation layer can create a language selector to enable the user to view a page in a different language.

Configuration

The list of languages available is very long. The Commerce must have at least one of them linked to it. The list is closed (though it can be added to if requested), so only the languages included in it can be linked. The languages linked can have one of these two statuses:

• Disabled: The language is linked to the Commerce and content can be provided in this language from the BackOffice, but it will not be available in the presentation layer (the system will not return content in this language).

• Enabled: Content can be provided in this language from the BackOffice and the system will return it as expected.

If content is requested in a language that is not linked or is disabled, a resource not found error will be returned.

One language from the list must be selected as the default, and this will be the one used by the system to return content while no change of language is specified.

Content

For the Commerce to be effectively multilingual, text for the content must be entered in each of the languages linked. Each content element must have a version for each language. The system provides content bulk entry tools to make this simple and convenient. However, the most usual way is to do it from the BackOffice, where each content element has its section, in which all its features can be edited, including those related to the language.

It is important for the content texts to be duplicated in all the languages enabled. If they are not, the content will be returned incomplete, leading to a poor user experience. The system has metadata bulk entry tools in place to make the job easier, as well as the corresponding block of metadata information in the section for each content element that exists in the BackOffice.

As well as the text of the content, a Commerce's presentation layer generally includes other texts such as messages, names of the elements displayed, text tags and so on. Texts of these kinds related to the presentation layer (of whatever type) will not be returned by the system, but must be managed from whatever presentation layer the Commerce has implemented.

The presentation layer must also pass on the error codes, whether information or alert codes, returned by the system. For example, if the system returns the error code indicating that a product could not be added to the shopping cart, the presentation layer must display a text of the type "The product could not be added" in all the languages linked and enabled in the Commerce.

Domains

In general, a Commerce is multi-domain. This means that its website (the collection of content offered by the Commerce) can have different versions, identified by the different domains.

Configuration

A Commerce can have a domain configured on 4 levels, from more general to more restrictive. The system will always assign the domain it considers most restrictive and, the higher the level number, the more restrictive it will be. Therefore, these are the established levels:

• Level 1: General level. A domain configured at this level is global for all versions and languages in the Commerce. At this level, the domain does not depend on any other feature.

• Level 2: Language domain. A domain is linked to a language in both directions, so that either of these two features determines the other; the domain determines a language and vice versa, the language determines a domain.

• Level 3: Country domain. A domain is linked to a country in such a way that the domain determines a country, but the reverse is not necessarily true (it depends on an additional configuration; see Country Domain ).

• Level 4: Language-country domain (most restrictive level). A domain is linked to a specific combination of language and country. This also works both ways, so that the domain determines a language and a country, and vice versa, a specific combination of language and country determines a domain.

The same domain can be linked to more than one element at the same level . For example, a Commerce could have www.domain.com linked to English and German, and fr.domain.com linked to French.

A domain can only work at one level. For example, if fr.domain.com exists at level 2 (linked to language), fr.domain.com cannot be used as a domain at level 3. Otherwise this would cause ambiguities when creating URLs and could consequently lead to duplication of content. The Commerce might have resources with the same domain for all languages. A typical example is the home page of the Commerce's presentation layer. This page cannot have a friendly URL (see Friendly URLs) because it is reached simply by typing a domain belonging to the Commerce in the browser. In cases like this, where the lack of language information can cause ambiguous behavior, the system automatically adds the language specification to the URLs returned by the resource for the rest of the languages enabled. For example, if the Commerce's domain is defined as www.domain.com and has English and German linked to it, when requested, the system will return the home page content in the default language, and also provide the following URLs for this home page:

www.domain.com/en

www.domain.com/de

The presentation layer can use these two URLs to disambiguate the home page when a selector to switch languages is set up.

Example: Imagine that the Commerce has a level 1 domain defined as www.domain.com, and 2 languages enabled, English (default) and German. The following situations could arise:

• A user with no browsing language (i.e. a new user) visits www.domain.com: The system returns the content in English because this is the default language and sets it as the browsing language.

• A user whose browsing language is English visits www.domain.com and selects German: As the URL is www.domain.com/de, the system sets German as the browsing language and redirects the user to www.domain.com.

• A user whose browsing language is German visits www.domain.com: The system returns the content in German.

Language Domain

If a domain is linked to a language this means that the URLs created under this language will use the domain in question.

Example: Imagine that the Commerce has a level 1 domain defined as www.domain.com, and 2 languages enabled, English (default) and German. German is linked to a level 2 domain set as de.domain.com. The following situations could arise:

1. A user with no browsing language visits www.domain.com: The system returns the content in English because this is the default language and sets it as the browsing language.

2. A user whose browsing language is English visits www.domain.com and selects German: As the language has a domain of its own linked to it, the system will have returned a URL with de.domain.com for German and will redirect the user to this domain (case 4).

3. A user whose browsing language is German visits www.domain.com: This domain is not associated with any language but cannot be displayed in German (because German has its own domain). The system returns the content in English because this is the default language and sets it as the browsing language.

4. A user whose browsing language is German visits de.domain.com: As the domain is linked to German, the content is returned in German.

5. A user whose browsing language is English visits de.domain.com: As the domain is linked to German, the system sets this as the browsing language and returns the content in the same language.

6. A user whose browsing language is German visits de.domain.com and selects English: The URL for this language is www.domain.com (there is no ambiguity because there are no other languages that share the domain). The system sets English as the browsing language, even though the domain is not linked to English, and redirects the user to www.domain.com (case 1).

Country Domain

When a domain is linked to a country it acts as a level 1 domain, but within a particular country. In other words, it is like setting the scope of the Commerce as a specific geographical area instead of the scope being global.

Unlike what happens with the language domain, there is no default browsing country as such; instead, the system always takes the user's country. The system deduces this from the user's IP using a geolocation tool. If the user is in a country within the sales areas, this will be the browsing country. This country can change, either because another is selected explicitly, because the user logs into the Commerce and their address is in a different country from the browsing one or because the user registers and their address is in a different country. This new country is set as the browsing country. If the user is not in a country within the sales areas, specific behaviors could be invoked depending on any GeoIP configuration the Commerce may have. If this condition is not taken into account, in general, the system will assign as the browsing country the country set as default by the Commerce. When there is a country domain, the browsing country assigned is the country linked to the domain, and not the default country. If several countries share the domain, the browsing country assigned is the first country linked to the domain.

The browsing country serves to apply filters, for viewing content and for prices. A particular country might therefore affect the content (displaying more or less) and product prices. It can also have, among other things, specified languages enabled for this area (changing the default language and changing the list of languages enabled). As the domain determines the country (with its particular features), it may appear to be out of the user's control. To avoid this impression, there is a Redirect due to country domain parameter that allows the user to be warned that the domain they wish to visit is for users in another country. The parameter can have three values:

• Informative:The system returns that a message is to be displayed warning the user that they are in country A but they are trying to visit the version for country B. This option also returns a URL for the version for country A so that the presentation layer can offer the user the possibility of choosing between switching to the version for country B or going to the version for country A.

• Strict:Choosing this option means that the user is automatically redirected to the version for country A, i.e. they are automatically taken to the version relevant to their geographical location.

• Off:No action is taken, either warning or redirection.

Example: Imagine that the Commerce has a level 1 domain defined as www.domain.com , and 2 languages enabled, English (default) and German. German is linked to a level 2 domain set as de.domain.com. Germany is linked to a level 3 domain set as www.domain.de. Also, for Germany the default language is specified as German and English is disabled (in Germany, only German). The following situations from 1 to 9 can arise, taking into account that:

• The Redirect due to country domain parameter has been activated and set to the value Strict.

• If the parameter were set to Informative, the cases would be the same, but without explicit redirection. A message would be displayed, and it would be up to the user to decide.

• If the parameter were set to Off, browsing would not be affected by redirections or warnings.

• "Country A" means any country except Germany.

1. A user browsing in country A visits www.domain.com: The system returns the content in English because this is the default language and sets it as the browsing language.

2. A user browsing in Germany visits www.domain.com: As the country has a domain of its own linked to it, the system redirects the user to www.domain.de (case 8).

3. A user browsing in country A visits www.domain.com and selects German: As the language has a domain of its own linked to it, the system will have returned a URL with de.domain.com for German and will redirect the user to this domain (case 4).

4. A user browsing in country A visits de.domain.com: As the domain is linked to German, the system sets this as the browsing language and returns the content in the same language.

5. A user browsing in country A visits de.domain.com and selects English: The URL for this language is www.domain.com (there is no ambiguity because there are no other languages that share the domain). The system sets English as the browsing language, even though the domain is not linked to English, and redirects the user to www.domain.com (case 1).

6. A user browsing in Germany visits de.domain.com: As the country has a more specific domain (level 3, with a higher priority than level 2), the system redirects the user to www.domain.de (case 8).

7. A user browsing in country A visits www.domain.de: As this domain belongs to Germany, the system will redirect the user to one of the other two domains. If the user's browsing language is German, they will be redirected to de.domain.com (case 4). If their browsing language is English or they do not yet have a language (in which case they will be assigned English by default), they will be redirected to www.domain.com (case 1).
   Important:If, in this case, the parameter were set to Informative and the user decided not to switch domains, or the parameter were set to Off, as the domain has a country linked to it, the system would force the browsing country to be Germany. This means that the system will apply all the features specific to the country, and therefore return the content in German because this is the default language for Germany. The user would not be able to switch language because no other language is enabled for Germany.

8. A user browsing in Germany visits www.domain.de: The system applies the features specific to this country and therefore returns content in German because this is the default language for Germany.

9. A user browsing in Germany visits www.domain.de and tries to switch to English: They cannot do so because in Germany the language is restricted to German.

Configuration of Sales Areas in Countries

The possibility of linking a domain to a country, along with all the other features associated with a country, means the domain can be considered a substore within the Commerce. This substore might need to sell only to a subset of the countries that make up the Commerce's sales areas. For this reason, when configuring the country, it is possible to redefine the list of countries so that it only affects the country in question. For example, the Commerce's sales areas consist of 10 countries, among them China, which is linked to the domain www.domain.cn. But China has its own market and can only sell to its users. Specifically to China, the list of sales areas can be redefined to include China only. Like this, in the shopping process, users of the domain www.domain.cn only have China available, i.e. their own market. As all other countries have the normal sales areas, the Commerce can be considered to have two stores: one global and the other specific to China.

Language-Country Domain

A language-country domain is the most restrictive of all. The domain determines the language and country associated with it and vice versa, a specific combination of language and browsing country will have the domain associated with them imposed. It is a mixture of language domains and country domains. The Redirect due to country domain parameter also affects language-country domains because the country is involved.

Example: Imagine that the Commerce has a level 1 domain defined as www.domain.com , and 2 languages enabled, English (default) and German. German is linked to a level 2 domain set as de.domain.com. Germany is linked to a level 3 domain set as www.domain.de. Moreover, German is specified as the default language for Germany instead of English, which is also enabled. The English-Germany combination is linked to a level 4 domain set as en.domain.de. The following situations from 1 to 11 can arise, taking into account that:

• The Redirect due to country domain parameter has been activated and set to the value Strict.

• If the parameter were set to Informative, the cases would be the same, but without explicit redirection. A message would be displayed, and it would be up to the user to decide.

• If the parameter were set to Off, browsing would not be affected by redirections or warnings.

• "Country A" means any country except Germany.

1. A user browsing in country A visits www.domain.com: The system returns the content in English because this is the default language.

2. A user browsing in Germany visits www.domain.com: As the country has a domain of its own linked to it, the system redirects the user to www.domain.de (situation 8).

3. A user browsing in country A visits www.domain.com and selects German: As the language has a domain of its own linked to it, the system will have returned a URL with de.domain.com for German and will redirect the user to this domain (case 4).

4. A user browsing in country A visits de.domain.com: As the domain is linked to German, the system sets this as the browsing language and returns the content in the same language.

5. A user browsing in country A visits de.domain.com and selects English: The URL for this language is www.domain.com (there is no ambiguity because there are no other languages that share the domain). The system sets English as the browsing language, even though the domain is not linked to English, and redirects the user to www.domain.com (case 1).

6. A user browsing in Germany visits de.domain.com: As the country has a more specific domain (level 3, with a higher priority than level 2), the system will redirect the user to www.domain.de (case 8).

7. A user browsing in country A visits www.domain.de: As this domain belongs to Germany, the system will redirect the user to one of the other two domains. If the user's browsing language is German, they will be redirected to de.domain.com (case 4). If their browsing language is English or they do not yet have a language (in which case they will be assigned English by default), they will be redirected to www.domain.com (case 1).
   Important: If, in this case, the parameter were set to Informative and the user decided not to switch domains, or the parameter were set to Off , as the domain has a country linked to it, the system would force the browsing country to be Germany. This means that the system will apply all the features specific to the country, and therefore return the content in German because this is the default language for Germany.

8. A user browsing in Germany visits www.domain.de: The system applies the features specific to this country and therefore returns content in German because this is the default language for Germany.

9. A user browsing in Germany visits www.domain.de and selects English: There is a level 4 domain for English-Germany that imposes itself over all others. The system will therefore redirect the user to en.domain.de (situation 10).

10. A user browsing in Germany visits en.domain.de: As it is a language-country type domain, the system forces the browsing country to be Germany and the browsing language English. The content is therefore returned in English and all the other features specific to the country are applied.

11. A user browsing in country A visits en.domain.de: As this domain belongs to Germany (as well as to the English language), the system will redirect the user to one of the other two domains. If the user's browsing language is German, they will be redirected to de.domain.com (case 4). If their browsing language is English or they do not yet have a language, they will be redirected to www.domain.com (case 1).

Important: If, in this case, the parameter were set to Informative and the user decided not to switch domains, or the parameter were set to Off , as the domain has a country and a language linked to it, the system would force the browsing country to be Germany and the browsing language, English. This means that the system will apply all the features specific to the country, but the content would be returned in English.

URLs

Though the system as a whole is headless, the most usual thing is for a Commerce to have some kind of web presentation layer to display the content. To be able to access any content or resource in a Commerce (and in general, in any website), the browser needs to be given a URL. This URL consists of a protocol (http or https), a domain (www.domain.com) and a third part that serves to identify the content, as well as additional parameters that can be included to filter or find elements, for example. To get to a product the following sample URL could be used:

https://www.domain.com/product1

Friendly URLs

This third element of the syntax of the URL might be a conventional identifier, such as /product/123, which might be hard to remember or even unintelligible to the user. To avoid this, semantic or friendly URLs are used. These are identifiers created using words related to the content to be displayed. URLs of this type allow the type of content to be identified better, are understandable to the user and are much easier to remember. Also, search engines tend to position content with friendly URLs better.

All the resources that can be accessed via the Commerce's URLs can use friendly URLs in each of the languages.

To define friendly URLs in the system it is not necessary to enter domain information. It is simply a matter of defining the third element, i.e. the semantic identifier.

Resources with no friendly URL will be identified with a conventional URL that has a specific structure for each content element. For example, product URLs are of the type: /product/[id], category URLs are of the type: /category/[id] and those for banners are of the type: /banners/[id], etc., where [id] is the internal identifier of the element in question.

The system has URL bulk entry tools to make the job easier, as well as the corresponding friendly URL field, in the section for each content element that exists in the BackOffice.

Friendly URLs cannot be repeated for any kind of resources, i.e. there cannot be two resources (product, category, area or of whatever type) that use the same friendly URL, as this could cause ambiguities and unexpected behaviors. For example, if a category uses the URL t-shirt and a product uses the same URL, when the t-shirt resource is requested the system would not know whether to serve a category or a product.

Moreover, as at first the system has no information about the language, if a content item uses the same URL for all languages, the system will not know in which language it should serve it. For example, if a product uses t-shirt in English and German, when the request is made the system would not know in which language to return it. To avoid this, friendly URLs must not be repeated under any circumstances.

As the friendly URLs are different for each language, when a content item is requested using a friendly URL the system knows which language to return it in. For example, if the current browsing language is English and a content item is requested using its friendly URL in German, the system returns the content in German, and also forces the browsing language to switch to German.

Language in URLs

While the language is a feature that is in principle hidden, it may be necessary (due to SEO strategies or for other reasons) to somehow show in which language the information is being served.

One of the strongest reasons to enable this feature, and which forms part of SEO strategies, is the good practice stipulated by the main search engines (including Google), which ask to be informed of the different language versions of a particular content item. A highly recommended way of doing this is to differentiate the URLs for each of the languages.

The See Language as a Subdirectory in the URL setting can be activated to add language information to the structure of the URL. When it is set, URLs look like this:

protocol://[domain]/[language]/[friendly URL/conventional URL]

where [language] specifies the language in ISO 639-1 format.

Language in URLs and Friendly URLs

It is compatible to have the language enabled in the URL and for the different content elements to have friendly URLs. As each friendly URL is associated with a language, the language to be shown in the URL will be the one that is linked. For example, if you have the friendly URL /product1 linked to English, the language specification to be included will be "/en/":

https://www.domain.com/en/product1

It is important not to mix friendly URLs with the wrong languages —this is only possible by generating the URL manually— to avoid undesired behaviors. If a user changes the sample URL manually and, instead of /en (English) writes /de (German), i.e. https://www.domain.com/de/product1, when the system receives the request it will understand that it has to return the content in German, but also that the friendly URL is in English. The system prioritizes the language linked to the friendly URL and, in this case, will therefore return the resource in English.

Language in URLs and Language Domains

When a domain is linked to a language and the setting to show the language specification in the URL has been enabled, if no other language has this same domain, the language code is not shown in the URL because it is assumed that the language is already represented in the URL by the domain. For example, a Commerce has two domains: www.domain.com and fr.domain.com. The first is linked to English and German, and the second only to French. In this case, the resources in English and German will contain /en/ and /de/ respectively in their URLs. However, as French has its own domain, the URL could be differentiated from the other languages and there is no need to include the language code in the URL: fr.domain.com.

If you have the See Language as a Subdirectory in the URL setting enabled, the complementary setting Force Language can be enabled. When this is done, the system will always show the language, even if it is not necessary. Continuing the above example, if this feature is set, resources in French will also contain /fr/ in their URLs: fr.domain.com/fr/.

Country in URLs

While the country is a feature that is in principle hidden, it may be necessary (due to SEO strategies or for other reasons) to somehow show this element in the URL.

One possible reason would be that the strategy for the URLs being implemented is to focus on countries instead of languages. In this case, it will be necessary to inform search engines of the different country versions of a particular content item, and a highly recommended way of doing this is to differentiate the URLs for each of the countries.

The See Country as a Subdirectory in the URL setting can be activated to add country information to the structure of the URL. When it is set, URLs look like this:

protocol://[domain]/[country]/[friendly URL/conventional URL]

where [country] specifies the language in ISO 3166-1 Alpha 2 format.

This feature is only available in country configuration (like the Redirect due to country domain feature). This means that only countries with this feature enabled will be able to function in this way. Setting this parameter would be like having country domains for every one of the countries for which it is enabled. This ensures control over which countries the regional SEO strategy is focused on (this is especially important for generating hreflang attributes, as you will see below).

The See Language as a Subdirectory in the URL setting is compatible with friendly URLs.

Country in URLs and Country Domains

When a domain is linked to a country and the setting to show the country specification in the URL has been enabled, if no other country has this same domain, the country code is not shown in the URL because it is assumed that the country is already represented in the URL by the domain. For example, a Commerce has two domains: www.domain.com and www.domain.com.uk. The first of these is not linked to any country, but the second is linked to the United Kingdom and has the feature to show the country in the URL enabled. In this case, as the country has its own domain, the URL is already differentiated and there is no need to include the language code in the URL: www.domain.com.uk.

If you have the See Country as a Subdirectory in the URL setting enabled for a particular country, the complementary setting Force Country can be enabled. When this is done the system will always show the country, even if it is not necessary. Continuing the above example, if this feature is enabled for the United Kingdom, resources will also contain /gb/ in their URLs: www.domain.com.uk/gb/.

In relation to the language in the URL, a particular country might have just one language enabled. In this case, whether the country has its own domain, or it has the See Country as a Subdirectory in the URL setting enabled, its URLs will be differentiated from the rest. Therefore, even if the parameter to show the language in the URL is set, it will not be shown because it is not needed (the URL with the domain or the country code already makes it unique for this region as there are no other languages to show). The language will only be specified in the URL if the Force Language feature is enabled.

Imagine that we have the general domain domain.com. In India, for example, only one language is enabled, English. If the parameter to include country identification in the URL is enabled for India, the URLs will look like this:

domain.com/in

This URL is unique for India because it only has one language associated with it. Therefore, the language need not be shown in the URL, even if the parameter to do this is enabled. If it is forced, the URL will look like this:

domain.com/in/en

Hreflang

The tags used to inform search engines like Google of the different language versions of a web page are known as "hreflang tags" or simply "hreflang". If the hreflang tag is implemented correctly, it boosts usability and SEO strategy.

To create the hreflang tags for a particular resource, it is necessary to know all the versions of the resource that exist, taking into account all the languages enabled, i.e. all the language versions of this resource. As language-country domains can also be created, it will also be necessary to know the language versions per country.

Hreflang tags have two main attributes: a link attribute in which the URL of the resource is defined, and the hreflang attribute itself, consisting of a code that can be made up of the language (in ISO 639-1 format) and sometimes the country (in ISO 3166-1 Alpha 2 format) of the alternative URL. Imagine the Commerce has two languages, English, and German, and two domains: one general, www.domain.com and, for the English-Germany combination, it is linked to a level 4 domain defined as en.domain.de. This means that each of the content items that can be accessed has a version with the content in English for all users, a version with the content in German for all users and a version with the content in English for users in Germany:

When the system receives a request, it returns the content in a particular language, and also automatically provides the structure of the URLs and their corresponding hreflang codes to enable the presentation layer to inform search engines of all the alternative versions of a particular resource that exist.

As mentioned above, the number of domains the Commerce has and the elements to which they are linked are fundamental in generating the hreflang codes because of the role they play in the structure of a URL. However, as the See Language as a Subdirectory in the URL and See Country as a Subdirectory in the URL parameters affect the structure of the URL, they are also fundamental in generating the hreflang codes.

Some points need emphasizing regarding domains, their links and the above-mentioned parameters:

• A priori, a level 1 domain can only generate hreflang codes for language (unless the See Country as a Subdirectory in the URL parameter is set).

• A priori, a level 2 domain can only generate hreflang codes for language (unless the See Country as a Subdirectory in the URL parameter is set).

• A level 3 domain means the focus is placed on a country, so language-country hreflang codes are always generated .

• A level 4 domain means the focus is placed on a country (and a language within a country), so language-country hreflang codes are always generated .

• A priori, setting the See Language as a Subdirectory in the URL parameter can only generate language hreflang codes (unless the See Country as a Subdirectory in the URL parameter is set for any country).

• Setting the See Country as a Subdirectory in the URL parameter means the focus is placed on the country, so language-country hreflang codes are always generated.

• Hreflang has a record called x-default which is used when a user's browser settings do not match any language or region indicated. In these cases, the system uses the generic domain.

Setting the See Country as a Subdirectory in the URL parameter places the focus on the countries in which it has been enabled. Therefore, as the hreflang code to be generated is of the language-country type, this means a URL will be generated for each of the countries for which it has been set and for each of the languages enabled for these countries. If the Commerce has many countries with this feature enabled and also has many languages active, literally hundreds of URLs may be generated. This can have highly negative unforeseen consequences, so it is important to take care over configurations of this kind.

Examples of hreflang Creation

Let us suppose that the Commerce has an international SEO strategy with certain regional foci and these domains:

• domain.com: Primary Commerce domain (level 1)

• domain.fr: Domain associated with a country, in this case, France (level 3)

• domain.es: Domain associated with a country, in this case, Spain (level 3)

The Commerce has the following languages enabled:

• English (default language)

• French

• Spanish

As shown by the domains, the Commerce aims to concentrate primarily on two countries, though it is also interested in some in the Americas and Asia, namely the following:

• Europe:

  • France

    • Languages available:

      • French (default)

      • English

  • Spain

    • Languages available:

      • Spanish (default)

• Americas:

  • Mexico

    • Languages available:

      • English

      • Spanish (default)

  • Canada

    • Languages available:

      • English

      • French

  • Colombia

    • Languages available:

      • English

      • Spanish (default)

  • Argentina

    • Languages available:

      • English

      • Spanish (default)

  • Chile

    • Languages available:

      • English

      • Spanish (default)

• Asia:

  • India

    • Languages available:

      • English

• Rest of the world

  • Languages available:

    • English

    • French

    • Spanish

The configuration by country would be as follows:

Let us suppose that the Commerce has a URL for a resource in the following languages:

• /product1 (English)

• /produit1 (French)

• /producto1 (Spanish)

The system generates the following hreflang for this resource:

If the parameter to show the language as a subdirectory in the URL is enabled, the system generates the following hreflang:

If the Force Language parameter is set, the system generates the following hreflang:

If the Force Country parameter is also set, the system generates the following hreflang:

Sitemaps

A sitemap is a file with a special structure (https://www.sitemaps.org/protocol.html) containing a list of the URLs of the content accessible in the Commerce. They are commonly used by the indexing robots of search engines as a guide to the content available for indexing.

Configuration

There is an index file of sitemaps (sitemap.xml), which contains the collection of different sitemaps of the Commerce. The number of sitemaps contained in this index will depend on how it is configured. You can do the following:

• Divide it into different languages:This means there will be a sitemap for each language enabled in the Commerce.
  If it is not divided into languages, the structure will contain secondary entries of the type <xhtml:link> with all the language and/or language-country variants of each of the URLs (hreflang structure).

• Divide it into different types:This means there will be a sitemap for each content element you decide to include, which can be the following:

  • Categories

  • Products

  • Pages

  • News

  • Blog posts

If it is divided into languages and types, this means the number of elements will be multiplied by the number of languages enabled in the Commerce. For example, if categories, products and pages are included, and there are 2 languages enabled, this means that 6 (3 x 2) different sitemaps will be generated: 2 of categories (one per language), 2 of products (one per language) and 2 of pages (one per language).

As content is changed fairly frequently, sitemaps can be updated every x hours, days or weeks, depending on the configuration. This updating is done through an automated process in the background. Moreover, as they can generally contain many records and, as a result, be fairly large in terms of bytes, the system can compress sitemap files to make them easier to handle and faster to download.