Our guide to what a hotel website should look like gave multilingual setup a single paragraph; this article is the detailed version. English, German and Russian are in the title because they are the trio hotel owners ask us about most often. But your own guest data, not general assumptions, should decide which languages your site needs.
1. Choose languages from guest data, not guesses
Every new language means translation, maintenance, guest messaging and measurement. Build your list from the data you already have, not from what the hotel next door offers:
- Booking engine and property management system: export past reservations by country or nationality, and look separately at who stays and who books direct.
- OTA reports: for example, the Booker insights report in the Booking.com extranet shows which countries your guests book from.
- Google Analytics 4 and Search Console: in GA4, Country shows where visitors are and Language shows their browser or device language. In Search Console, group the Performance report by country.
- Guest conversations: the languages your front desk hears on WhatsApp and the phone reveal demand no report shows.
Two traps: a country is not a language; a visitor from Germany may browse in Turkish, one from Switzerland in French. And if you have no page in a language, you will not see direct bookings in it either. Read the sources together and start small; three languages done well beat eight done halfway.
2. Give every language its own URL
Google is clear: language versions should not switch on the same address via cookies or browser settings; each language needs its own URL. The four structures Google compares:
- Country-code domain (example.de): clear targeting, but expensive and limited to a single country.
- Subdomain (de.example.com): easy to set up, but users may not recognise the targeting from the URL.
- Subdirectory (example.com/de/): easy to set up and low maintenance on a single host.
- URL parameter (example.com?lang=de): not recommended by Google.
For a hotel, subdirectories usually make the most sense: /en/, /de/, /ru/. You are targeting a language, not a country; a German-speaking guest may just as well come from Austria or Switzerland. Google also recommends words in your audience's language in URLs, transliterated where needed. Cyrillic URLs need percent-encoding, so a slug like /ru/nomera/ is more practical for Russian pages.
3. Set up hreflang correctly
hreflang tells search engines which pages are the other-language versions of a page, so Google can show guests the one in their language. But Google detects a page's language from its visible content, not from hreflang or the lang attribute: hreflang is a routing signal and will not rescue a poor translation. Google's rules for hreflang on a hotel website:
- Self-reference: each version lists itself as well as all the others.
- Reciprocity: in Google's words, if two pages don't both point to each other, the tags are ignored. Missing return links are one of the most common mistakes.
- Fully qualified URLs: include https://; relative paths such as /de/rooms don't count.
- Correct codes: ISO 639-1 for language (en, de, ru), ISO 3166-1 Alpha 2 for region. A region alone is invalid, and the United Kingdom is en-GB, not en-UK. If content doesn't change by country, just use de; it covers Germany, Austria and Switzerland together.
- x-default: the fallback when a visitor's browser language matches no version; for hotels usually the English version or a language selection page.
- Canonical in the same language: with hreflang, Google asks for a canonical page in the same language. Don't point the German page's canonical at the Turkish homepage.
For Yandex, the sitemap is not enough
For Google, putting the annotations in the head, in HTTP headers or in the sitemap is equivalent. But some Russian-speaking guests use Yandex, which supports hreflang yet states that it no longer supports sitemaps for language versions and recommends on-page markup. The safest route is to put the tags in the head of every page.
4. Why an auto-translate widget is not enough
Most widgets that swap text in the browser don't create a separate URL; the “German version” is really a script running on top of the Turkish page. Google wants a crawlable URL for each language, and without one hreflang is impossible.
On machine translation, Google's position targets quality, not the method. The scaled content abuse definition in its spam policies covers generating many pages through automated transformations such as translating when they add little value for users. In June 2025 Google removed a section from its documentation about blocking automatically translated pages with robots.txt. What works in practice: machine translation as a first draft, a native speaker reading the text, and a glossary for room names, cancellation terms and payment steps. Don't translate only the menu; Google recommends a single language for content and navigation on each page.
Guests don't count how many languages your site speaks; they judge how much trust the page in their own language gives them.
5. Localise the booking flow, room names and policies
Everything a guest reads before paying should be in their language:
- Booking engine: the button on the German page should open the engine in German, including the payment page, error messages and confirmation email. A screen that changes language mid-flow breaks trust at the worst moment.
- Room names: a sea view room is Sea View Room in English, Zimmer mit Meerblick in German and Номер с видом на море in Russian. For board types, use the terms guests know from tour operators, and keep names identical on the site, the engine and OTA listings.
- Policies: cancellation, check-in and check-out times, child and pet policies. Have your legal adviser approve translated legal texts.
- Currency: state which currency the charge is made in; if you show converted prices, label them as approximate.
- Dates and numbers: 03/04 is 3 April to a British guest and 4 March to an American; German and Russian use a decimal comma. Writing the month name avoids confusion.
6. Language switcher: offer, don't redirect
Redirecting everyone from Russia to /ru/ by IP may look clever, but Google advises against redirecting on a guessed language and against IP location analysis. Googlebot's default IPs also appear to be US-based and it sends no Accept-Language header, so automatic redirects can hide your other versions from Google. Instead:
- Put the switcher at the top of every page, visible on mobile too.
- Name each language in itself: English, Deutsch, Русский. The W3C advises against flag icons for languages; a flag stands for a country, not a language.
- Link to the same page in the other language: tapping “Deutsch” on the family room page should open the German family room page, not the German homepage.
- If the browser language differs, show a small dismissible suggestion rather than switching the page.
- Declare the language on the html tag. Google doesn't use it for detection, but screen readers rely on it to load the right pronunciation rules.
7. Local signals: contact and payment
Google lists currency, addresses and phone numbers alongside language as signals of who a site is for. For guests, these details answer “will this hotel understand me?”:
- Contact: write the phone number in international format with +90, add a WhatsApp link, and say when someone who speaks that language is available. A guest writing from the German page shouldn't get an automatic reply in Turkish.
- Payment: card acceptance can vary by market. Visa, for example, announced in March 2022 that transactions with Russian-issued cards would no longer work outside the country. Confirm with your bank which options are legally and technically possible today, and say so clearly on the Russian page.
- Consistency: address, phone and policies should match in every language, on your Business Profile and in OTA listings; see Google Business Profile for hotels.
The goal is for international guests, too, to finish booking on your site rather than an OTA; we covered channel mix in our article on direct bookings.
8. Measure each language separately
- Search Console: a URL-prefix property only covers URLs starting with that prefix. Add separate properties for /de/ and /ru/ to track each language's clicks and queries on their own.
- hreflang checks: Search Console's International Targeting report has been deprecated; Google still uses hreflang, but there is no ready-made error report. Check with a crawler, and use URL Inspection to confirm that the Google-selected canonical for each language page is the page itself.
- GA4 and the booking engine: split page paths by language folder, but the real measure is bookings. Check whether your engine can report reservations by language. The advertising side of measurement is in Google Ads for hotels.
- Yandex Webmaster: if the Russian version matters, add the site there too and check that the Russian pages are in search.
Common mistakes on multilingual hotel websites
- Automatic redirects based on IP address.
- One-way hreflang: the German page points to the Russian one, but not back.
- Pointing every language version's canonical tag at the Turkish page.
- Translating the menu but leaving room descriptions and policies in Turkish.
- A German site with an English booking engine and confirmation email.
- Flag-based language menus, or a switcher that always returns to the homepage.
- Updating prices and policies on the Turkish page only.
- Launching more languages than you can maintain.
Turning a multilingual site into a sales channel
A well-built multilingual hotel site has clear parts: languages chosen from data, subdirectories, reciprocal hreflang, text checked by a native speaker, a booking engine in the guest's language, and per-language measurement. Next comes search visibility in each language, including researching keywords per language rather than translating them; see our hotel SEO guide. At our Studio we build these pieces together for hotel websites; examples are on our Work page.
Sources
- Google Search Central: Managing multi-regional and multilingual sites
- Google Search Central: Tell Google about localized versions of your page (hreflang)
- Google Search Central: How Google crawls locale-adaptive pages
- Google Search Central: Spam policies for Google web search
- Google Search Central: Latest documentation updates (11 June 2025 entry)
- Google Search Central: How to specify a canonical URL
- Google Search Central: URL structure best practices
- Search Console Help: The International Targeting report is deprecated
- Search Console Help: Add a website property (URL-prefix properties)
- Analytics Help: [GA4] Demographic details report
- Booking.com for Partners: Understanding your Analytics space
- Yandex Webmaster: Indexing localized pages
- W3C: Authoring HTML: Language declarations
- W3C WAI: Understanding WCAG 2.2, Language of Page
- Visa: Visa Suspends All Russia Operations (5 March 2022)
Ready to grow your brand?
Let's bring strategy, design, performance and content together — under one roof.
Get a Free Quote →