Translating a website helps explain your offer to people who speak another language. For search visibility, you also need to organise page URLs, connect corresponding versions, and investigate the queries customers use in each market.
Otherwise, visitors may land on an unsuitable version, the language switcher may send them to the homepage, and technical settings may suggest that several independent translations should be consolidated into one page.
This article explains how to plan a multilingual website structure, how canonical and hreflang differ, and what to check before publication. We will use Russian, English, and Czech pages on iuntsevich.cz as an example.
Russian, English, and Czech are content languages. The country where you provide services is a separate consideration. An English page may serve international customers or describe terms for a specific market.
Before development, clarify:
In hreflang, you can specify a language without a region: ru, en, or cs. For a version intended for a specific market, use a language-country combination, such as en-GB or cs-CZ. Do not add a region simply because your office is located there: first establish the page’s purpose.
Also consider the domain. Google treats country-code domains as a country targeting signal: .cz points to Czechia. This does not prevent you from serving international customers, but language folders and hreflang do not make a country-code domain geographically neutral. Discuss the domain choice alongside your market strategy; there is no need to change an existing address without assessing the consequences. See Google’s guidance on multilingual and multi-regional websites for the principles involved.
Each language version of a page should have its own accessible URL. Google recommends separate URLs instead of changing the language at one address solely through cookies or browser settings.
One possible structure uses language sections within the website. iuntsevich.cz uses /ru/, /en/, and /cz/. Articles have dedicated sections at /ru/blog/, /en/blog/, and /cz/blog/.
Language folder names and language codes serve different purposes. The /cz/ folder is a valid part of a URL, but the Czech language code for hreflang is cs, rather than cz.
You can keep the same short article slug across languages on one website. This makes the versions easier to match. URLs can also be localised where appropriate: the key is to maintain an explicit relationship between corresponding pages and avoid changing published URLs without a redirect plan.
For a new multilingual project, agree on the URL structure before design and content production. During multi-page website development, this allows you to plan language sections, page templates, and navigation rules in advance.
hreflang tells search engines which URLs are language or regional alternatives of the same page. It helps associate versions, but does not translate content or guarantee rankings or the display of a chosen URL.
For an HTML implementation:
Google also supports specifying alternatives through HTTP headers or a sitemap. Choose a suitable method and maintain it consistently. Implementing every method does not provide an additional advantage. The rules and supported language codes are explained in Google’s documentation on localised versions.
Consider three existing URLs for the multi-page website development service:
Below is an example configuration for this group of pages, rather than a statement about the website’s current code. For an HTML implementation, place the same set in the <head> of all three versions:
<link rel="alternate" hreflang="ru" href="https://iuntsevich.cz/ru/multi-page">
<link rel="alternate" hreflang="en" href="https://iuntsevich.cz/en/multi-page">
<link rel="alternate" hreflang="cs" href="https://iuntsevich.cz/cz/multi-page">A different service or article needs its own set of corresponding URLs. Do not add this group to a shared header in a way that repeats it unchanged on every page of the website.
x-default specifies a fallback for users who do not match any of the listed language or regional versions. This can be a language selection page or a suitable default content version.
It is not required to connect three language versions. If you use it, choose the URL deliberately: for a group of service pages, the fallback should also help visitors find that service. Read more in Google’s explanation of x-default.
canonical identifies the preferred URL among duplicate or very similar pages. hreflang describes the relationship between language and regional alternatives. These settings serve different purposes.
For independent pages with translated main content, a self-referencing canonical URL is usually appropriate. In our example, the Russian version points to /ru/multi-page, the English version to /en/multi-page, and the Czech version to /cz/multi-page.
Example element for the Russian page:
<link rel="canonical" href="https://iuntsevich.cz/ru/multi-page">On the English and Czech pages, change the URL in this element to the corresponding version. The hreflang set from the previous section remains shared across the group.
Do not point every translation’s canonical to the Russian page simply because it was created first. This conflicts with the objective of developing independent language versions.
Regional pages with similar content in the same language require a separate decision: first determine which URLs should remain independent and which are duplicates. When using hreflang, Google recommends choosing a canonical page in the same language where one exists. canonical is a signal; the search engine makes the final choice. Read more in the canonical URL guidance.
The switcher should take visitors from the current service or article to its corresponding version. Sending someone from a detailed resource to another language’s homepage forces them to find the information again.
Use clear language labels and ordinary links to pages. Keep manual selection available even if the website suggests a language automatically. Google recommends avoiding forced redirects between language versions: they may prevent visitors and crawlers from accessing the content they need.
If a translation has not been published, do not create a misleading association. You can temporarily omit that option from the switcher or explicitly offer another section. A Czech homepage does not become the translation of every Russian article.
For a regularly updated blog, maintain a mapping table with the article, language, published URL, and translation status. Switchers and technical markup can then be generated from verified data.
A translated list of Russian keywords is a starting hypothesis for another version, rather than completed research. Customers in a new market may use different service names, ask different questions, or expect a different kind of answer.
For each language:
Localisation covers the entire journey to an enquiry. Translate menus, buttons, forms, confirmations, and error messages. Check where service links lead and who handles enquiries in the selected language.
Prices, currencies, and terms must match the company’s actual offer. Do not add a local address, payment method, or timeline simply to make the page look local.
Google determines a page’s language from its visible content. Translating the header while leaving the main text in another language does not create a fully localised page. The hreflang attribute does not fix mixed-language or untranslated content.
Check the entire group of versions, as well as individual pages:
Check the published HTML and the settings visitors actually receive. If a template generates the markup, examine different page types: services, articles, and the homepage. An error in a shared element may affect the entire section.
After changing URLs, update the mapping table, internal links, alternate URLs, and canonical references. Redirect old URLs to the corresponding new pages according to an agreed plan.
To evaluate results, analyse pages and queries separately by language section and target market. The visitor’s country does not replace analysis of the page’s language. Compare equivalent periods and account for differences in publication history and content volume between new versions.
If you need help with keywords, structure, and technical settings for language versions, explore our SEO services. The scope is described in our SEO commercial offer; the specific plan should be agreed according to your languages, markets, and website’s current condition.
Multilingual SEO requires consistent work on URLs, content, and navigation. When each version serves a clear task and is correctly connected to the other pages, the website is easier to maintain and visitors can more easily find a suitable offer in their language.