Planning a Multilingual Website for Tourism Businesses
For a tourism business in Antalya, the sentence “let’s have the site in English too” looks as simple as a sentence. Yet a multilingual site means taking on the maintenance of more than one site. This article explains how to decide which languages to choose, what to watch in the technical setup, and why the cost is not just the translation.
How many languages? Let your markets decide
“The more languages, the better” is the wrong starting point. Every language is a permanent maintenance load: when a price changes, a service is added or a campaign runs, it has to be updated in every language. A language version that is not kept up to date turns into a page that gives wrong information to the guest who arrives in that language.
You already have the data you need for the decision:
- Guest nationality breakdown: Which countries did last year’s guests come from? Which three countries make up most of the volume?
- Booking source: From which markets do you get direct bookings, and from which through agencies? For a market that comes via agencies, your own site is less critical.
- Current site traffic: Your analytics data shows visitors’ browser language and country.
- Incoming messages: In which language do the enquiries arrive?
For most Antalya businesses, starting with Turkish and English and adding one or two markets with genuinely large volume is enough. Running three languages properly gives better results than launching with eight and leaving six of them unmaintained.
Translation is the small part of the job
When budgeting, usually only the per-word translation fee gets calculated. The real cost items are these:
- Translation: Translating the texts.
- Adaptation: A text written for Turkish can read oddly when translated word for word for another market. Adapting the emphasis, the examples and the calls to action to the target market is a separate job.
- Technical setup: Setting up the language structure, the URL scheme, the language switcher, and the ability to edit each language separately in the admin panel.
- Images: Images that contain text must be produced separately for each language.
- Formats: Date, time, currency, decimal separator, address and phone number formats.
- Continuity: Reflecting every content update in every language. In the long run, this is the biggest item.
Decide from the start who is responsible for which language. A language with no owner goes out of date within six months.
Should you use machine translation?
Machine translation tools are fast and cheap; with a plugin, the whole site can be translated in a few minutes. But on pages that sell, this comes at a price: when a piece of information such as a price, a cancellation condition, a room feature or a safety notice is translated wrongly, the responsibility stays with you.
The balanced approach is this: the pages that drive decisions and involve money — the home page, service/room pages, prices and conditions, contact — should be translated by a person, or at least checked by one. For blog posts and secondary content, machine translation can be a starting point, but it should be read before publishing.
Technical setup: Google’s recommendations
On a multilingual site, the search engine needs to know which version to show to whom. Google uses hreflang markup for this and offers three methods: link tags in the page’s head section, HTTP headers for non-HTML files, and markup inside the XML sitemap. Google states that these three methods are equivalent from its point of view and that you can choose whichever suits your site best.
On the URL structure side, Google does not recommend a specific scheme. It does point out one important thing: the language information in the address — a subdomain such as en.example.com, for instance — is not used to determine the target audience; you have to map the target audience explicitly yourself.
The common mistakes Google lists are also the ones most often seen in practice:
- Missing return links: If page X links to Y, Y must link back to X. One-way markup is not considered valid.
- Invalid language code: Using only a region code instead of a language-region combination.
- Wrong region code: Instead of non-standard codes such as “EU” or “UK”, the official ISO 3166-1 Alpha 2 format must be used.
Getting this setup right is the job of the software side, and it should be checked in Search Console after it goes live.
Redirecting visitors automatically
Looking at the location or browser language and redirecting the visitor automatically looks attractive, but in practice it causes problems: a German guest on holiday in Turkey lands on the Turkish page, a Turkish visitor abroad lands on the English page. And when a visitor shares a link, the other person may see a different page.
The safer route is to guide the visitor without forcing them: show a suggestion in the preferred language, but leave the choice to them, and keep the language switcher visible on every page. Writing the language switcher with language names (“English”, “Deutsch”, “Русский”) rather than flags also reduces confusion — one language is spoken in more than one country.
Points specific to tourism businesses
- Currency: Showing the price in the guest’s currency affects conversion. Where the exchange rate comes from, how often it is updated and in which currency the payment is collected should be clarified from the start.
- Date format: The day/month order in check-in and check-out dates varies by country. In a booking form, this confusion leads directly to the wrong date; showing the month name in words is the safest way.
- Distances and transport: The distance to the airport, the beach and the centre should be written clearly in every language. This is the information foreign guests ask about most.
- Contact: State which languages you can offer support in. Building a Russian page and then being unable to answer a question in Russian is worse than not building one at all.
- Legal texts: Cancellation and refund conditions must be correct in every language; a translation error here produces disputes directly.
- Season: Launch a new language version before the season starts, not in the middle of it.
Frequently asked questions
Do I have to translate every page into every language?
No. All of the decision-driving pages should be translated; blog and secondary content can be selected per market. Take care not to link to an untranslated page from within that language.
Should I get a separate domain?
Google does not recommend a specific scheme for the URL structure and does not use the language information in the address to determine the target audience. The decision is more about ease of management and budget; separate domains mean separate maintenance.
Is a plugin enough to make the site multilingual?
It depends on your platform. A plugin makes the setup easier, but you need to check that the hreflang markup is generated correctly, that each language can be edited separately and that the sitemap is built correctly.
Can we make my existing site multilingual?
In most cases, yes; but if the URL structure is going to change, a redirect plan is needed to protect the visibility of the existing pages. We covered this in our website redesign article.
How much does a multilingual site add to the cost?
It depends on the number of languages, the number of pages to be translated and who is responsible for the translation. We listed the cost items in our website prices article; multilingual support appears there as a separate item.
Which languages and which pages — let’s work it out together
Share your guest profile, which markets you get direct bookings from and your current site’s address; let’s work out together which languages are really needed and how the technical setup should be done. You can look at our web design and corporate website service and get in touch — we work in English or Turkish. For the booking side, see our hotel booking app article.