Structuring a Multilingual Website for Adriatic Property and Hospitality

Almost every property developer, hotel and clinic on the Adriatic coast sells to more than one language group. The question is rarely whether to run a multilingual website, but how to structure it. These decisions are easy to make badly and expensive to reverse: the wrong URL architecture or a broken hreflang setup can quietly split your search visibility across versions of the same page for years.

This is a practical walk-through of the choices that matter, in the order you should make them.

Step one: decide which languages actually earn their place

Adding a language is not a one-off cost. Every language you publish has to be maintained, updated when prices or offers change, and supported by someone who can reply to enquiries in it. A half-abandoned German section with last season's rates does more damage than no German section at all.

Base the decision on evidence you already have rather than assumptions:

• Enquiry history — what languages do people actually write to you in, and which of those enquiries convert?
• Search Console country data — where does existing organic traffic come from, and for which queries?
• Your sales reality — can your team handle a call in that language within a working day? If not, the page generates frustration, not revenue.

For most Montenegrin businesses, English is the working baseline because it serves buyers and guests from many markets at once. Beyond that, the sensible shortlist is usually drawn from Russian, German, Serbian/Montenegrin, and increasingly Turkish, Polish or Arabic depending on the segment. Start with two or three done properly rather than seven done thinly.

Step two: domain strategy

Three options come up repeatedly.

One domain for everything

This is the right answer in the large majority of cases. All your authority, links and brand recognition accumulate in one place, and you only maintain one technical stack. Use it unless you have a specific reason not to.

A .me domain versus a generic one

The .me extension is a country-code domain for Montenegro, but it has been marketed globally as a vanity extension for years, so search engines treat it loosely rather than as a strict local signal. It works perfectly well as a brand domain. If your market is primarily international buyers and guests, a .com is marginally safer; if your audience and operations are local, .me is fine and often more memorable. What matters far more is that you do not scatter content across both.

Separate domains per market

Only justified when you genuinely operate separate legal entities, brands or sales teams per country. It triples the SEO workload.

Step three: subfolders, subdomains or parameters

Use subfolders: example.com/en/, example.com/de/, example.com/ru/. Subfolders inherit the authority of the main domain, are simple to host, and are easy to report on in analytics. Subdomains (de.example.com) behave more like separate sites and need their own authority built up. URL parameters (?lang=de) are the worst option — they are fragile, ugly to share, and prone to duplicate-content problems.

Two related rules:

• Do not auto-redirect visitors by IP address. A German buyer sitting in a Budva hotel lobby does not want to be forced into the Montenegrin version, and search engine crawlers can end up seeing only one language. Detect the browser language, then suggest the alternative with a dismissible banner.
• Decide what lives at the root. Either redirect example.com to your default language folder, or serve a genuinely neutral landing page. Avoid having the same content accessible at both the root and a folder.

Step four: hreflang, implemented properly

Hreflang tells search engines that several URLs are the same page in different languages, so the right one is shown to the right user. The implementation rules are unforgiving:

1. Every page must list all language versions, including itself (self-referencing).
2. References must be reciprocal — if the English page points to the German page, the German page must point back.
3. Use correct codes: de, ru, en; add a region only when you genuinely have separate regional content (en-GB and en-US), not for decoration.
4. Add an x-default entry pointing to the version you want shown when no language matches.
5. Never point hreflang at a URL that is canonicalised elsewhere, redirected, or blocked in robots.txt.

The most common failure we see is hreflang tags that point to pages which were never translated — or which were deleted during a redesign. Audit the set after every significant site change.

Step five: handling partial translation honestly

Most sites translate the core pages and leave blog articles or technical documents in one language. That is fine. Simply do not declare hreflang relationships for pages that do not have a counterpart, and do not use automatic machine translation to bulk-fill the gaps. Thin, awkward translations of fifty blog posts dilute quality signals and embarrass the brand in front of exactly the buyers you want.

Where a page must exist in a language you cannot fully support, a short, well-written summary with a clear call to contact your team beats a long machine-translated article.

Step six: translate more than the words

Localisation, not translation, is where multilingual sites win:

• Translated URL slugs where the language uses Latin script — /de/immobilien-budva/ rather than /de/properties-budva/. Keep Cyrillic transliterated.
• Unique meta titles and descriptions per language, written for how that market actually searches, not translated from English.
• Local terminology and units — square metres throughout, prices in euros, and the right legal vocabulary for notaries, property transfer tax and residency rules.
• Market-specific content — a buying guide written for German purchasers answers different questions than one written for buyers from the Gulf. These pages should be originals, not mirrors.
• Forms and documents — if the contact form is in German, the auto-reply, brochure and follow-up sequence should be too.

Step seven: make the language visible in your data

Capture a language field on every form submission and pass it into your CRM. Without it, you cannot tell which language versions generate qualified enquiries, and you will end up justifying translation budgets on traffic alone. In analytics, segment by language folder; in Search Console, filter by country and page path. Those two views together tell you whether a language is earning its maintenance cost.

A sensible rollout order

Launch the default language fully. Add the second language across core commercial pages only — homepage, offer or listing pages, about, contact, one buying or booking guide. Verify hreflang and indexing. Only then expand depth, and only then consider a third language. Breadth without depth is the pattern that quietly costs Adriatic businesses both visibility and credibility.