Almost every Croatian business website I have worked on needs at least two languages. Most need three or four. A restaurant in Split, a tour operator in Hvar, an apartment rental in Dubrovnik, a winery in Istria — none of them can survive on Croatian alone, and most of them shoot themselves in the foot trying to add the other languages on top of a site that was never designed for it.

This is the guide I wish more developers in Croatia would read before quoting a multilingual project. Done right, multilingual is part of the architecture from day one and adds maybe 15% to the build cost. Done wrong, it costs you twice — once to bolt on, once to fix.

Why Croatian sites are different

Most countries have one or two dominant languages. Croatia has Croatian as a base, English for international visitors, and then a long tail of guest languages depending on who your customers are: German for Austrian and German tourists, Italian for the Adriatic coast, French for the western European market, Polish and Czech for the late-summer crowd.

For a tourism-facing business, two languages is the bare minimum. Four is normal. Five is common. I have built sites with seven, and the maintenance overhead is real — but only if the architecture was wrong from the start.

The other thing that makes Croatia different is the EU border effect. A lot of business sites here also need to comply with EU consumer law in the language of the buyer (returns notices, terms, cookie banners). That is not optional. If you sell to a German consumer, the contract terms need to be available in German. The site architecture has to make that easy or it becomes a legal liability.

The four real languages, and the ones you might not need

The languages that actually move the needle for Croatian businesses, in rough order:

  1. Croatian (HR) — your home audience and the language Google serves locally.
  2. English (EN) — the universal fallback for everyone else.
  3. German (DE) — by far the largest tourism segment in Dalmatia and Istria.
  4. Italian (IT) — strong on the coast, especially Istria and Kvarner.
  5. French (FR) — smaller but valuable; high-spend segment.

Languages I see clients overinvest in: Russian (collapsed since 2022), Chinese (low conversion outside very specific niches), Spanish (small for Croatian tourism). Build them only if you have data showing those visitors are converting.

The decision should be data-driven, not aspirational. Look at your Google Analytics country breakdown for the last two summers. If Polish visitors are 1% of traffic and 0% of bookings, do not translate into Polish.

URL strategy: subdirectories, always

There are three ways to structure multilingual URLs:

  • Subdirectories: tonibarisic.com/en/, tonibarisic.com/hr/
  • Subdomains: en.tonibarisic.com, hr.tonibarisic.com
  • Query parameters: tonibarisic.com/?lang=en

Use subdirectories. Always. Subdirectories inherit your domain authority, are simpler to deploy, and Google understands them perfectly. Subdomains split your SEO authority across what Google reads as separate sites. Query parameters are a disaster — Google does not always crawl them as distinct pages, social previews break, and analytics get muddy.

The exception: if you have a fundamentally different brand or product per market (different prices, different inventory, different team), subdomains can make sense. For 95% of Croatian businesses, subdirectories are right.

Pick a default locale strategy and stick with it. Either the bare domain (/) serves Croatian and English lives at /en/, or the bare domain redirects to /hr/ and every locale has its own prefix. The second is cleaner and what I default to on new builds — every page has a locale prefix, no implicit defaults.

hreflang done right

hreflang tags are how you tell Google "this page is the German version, that one is the Italian version." Get them wrong and Google picks the wrong page for the wrong searcher.

The rules:

  • Every locale variant of every page lists every other variant in <link rel="alternate" hreflang="…"> tags.
  • Every page also includes a self-referential hreflang tag pointing to itself.
  • Include hreflang="x-default" pointing to your default fallback (usually English).
  • Use proper language codes — hr for Croatian, en for English, optionally with country (en-GB, de-AT) only if your content actually differs by country.

A typical set on a four-language Croatian site looks like this on every page:

<link rel="alternate" hreflang="hr" href="https://example.hr/hr/about" />
<link rel="alternate" hreflang="en" href="https://example.hr/en/about" />
<link rel="alternate" hreflang="de" href="https://example.hr/de/about" />
<link rel="alternate" hreflang="it" href="https://example.hr/it/about" />
<link rel="alternate" hreflang="x-default" href="https://example.hr/en/about" />

The single biggest mistake I see is missing hreflang tags on translated pages — the German page links to itself but not to the others. Google ends up treating each language as an island. Validate everything with Google's Search Console hreflang report after launch.

Translation workflow: human, machine, or hybrid

This is where most projects burn budget. Three options:

Human-only translation. Highest quality, slowest, most expensive. Right for hero copy, the about page, legal pages, anything customer-facing where wrong word choice damages trust. Budget €0.10–0.20 per word from a professional translator in a Croatian-language pair.

Machine translation (DeepL). Fast, cheap, good enough for FAQ pages, blog posts, terms of service drafts, product descriptions where small errors do not break the deal. DeepL handles Croatian-to-German and Croatian-to-English far better than Google Translate. It is not perfect but it is a good first pass.

Hybrid (what I actually recommend). DeepL for the first pass, then a human native speaker reviews and fixes the parts that matter. This is 80% of the quality of pure human translation at 30% of the cost. For most Croatian businesses, the math is overwhelming.

Whatever you choose, never let a developer hand-translate. Developers are not translators. The output reads exactly like a developer who used Google Translate, and your German guests will close the tab.

Where translations actually live

Translations need to live in a structured place that the developer, the business owner, and the translator can all access. The three patterns I use:

JSON files in the codebase. Simple, version-controlled, fine for small static sites. One JSON file per locale (hr.json, en.json, de.json) with the same key structure. Limitation: every change is a developer task and a deploy.

Headless CMS (Sanity, Storyblok, Payload). Locale-aware out of the box. The owner can edit copy in any language without involving a developer. Right for sites with frequent content updates, multiple authors, or marketing teams. Adds €30–80/month in tooling cost.

Database-backed (Supabase, Postgres). Translations as rows with locale columns. Right for product catalogues, booking inventory, anything with structured content. This is what I use for clients who have an admin panel anyway.

What you do not want: hardcoded strings in templates, copy-pasted HTML pages per language, or a translation plugin that lives inside WordPress. Those are the patterns that lock you into expensive maintenance forever.

I cover the broader stack choice — particularly why I default to Next.js for multilingual builds — in How I Use Next.js to Build Fast Business Websites. Next.js has built-in i18n routing that handles a lot of the multilingual plumbing automatically.

SEO across locales

A multilingual site is really four separate SEO efforts. The fundamentals from my SEO checklist apply per locale:

  • Sitemap must list every locale variant of every page, with xhtml:link alternates.
  • Canonicals point to the same locale, not the default. The German /de/about canonicalises to itself, not to /en/about.
  • Meta descriptions and titles are translated, not copy-pasted with English.
  • Structured data (Organization, LocalBusiness, Product) is in the locale of the page.
  • Internal links stay within the same locale — your German page links to the German contact page, not the English one.

The Croatian-language version usually ranks easiest because there is less competition. The English version is the hardest — you are competing globally. German is somewhere in between but is the highest-value tourism language.

The fiskalizacija footnote

If your site sells anything online to Croatian buyers, you need to issue compliant fiscal receipts. Fiskalizacija is not just a backend concern — it changes the checkout flow. Required fields, the receipt format, the JIR/ZKI codes, the invoice numbering scheme. None of it is hard, but it has to be designed in from the start.

For multilingual sites this also means the receipt itself needs to render in Croatian (always, by law) regardless of what language the buyer used to checkout. If your developer has not mentioned fiskalizacija in the discovery call, ask why.

Common mistakes I see in Croatian sites

The patterns I keep finding when I audit existing sites:

  • English page is the only one with proper SEO. The Croatian and German pages have no meta descriptions, no schema, no proper titles.
  • Language switcher loses the page. Click the German flag, end up on the homepage instead of the German version of the page you were on.
  • Auto-redirect by IP. Croatian visitors from Germany get sent to German. Bad — they came expecting Croatian. Let users pick, remember the choice in a cookie.
  • Mixing locales mid-page. German hero, English buttons, Croatian footer. Always a sign of unfinished translation.
  • Untranslated form errors. "This field is required" stays English on every locale because the developer forgot validation messages are also content.
  • No hreflang back-references. German page lists no alternates; Italian page lists only itself.

Fixing each of these is small work in isolation. Fixing all of them on a site that was not designed for multilingual from day one is a rebuild.

Build it in, do not bolt it on

The single most important thing in this post: if you know the site needs more than one language, design the architecture for it on day one. The cost difference between a site built multilingual from the start and a single-language site that gets multilingual added later is roughly 15% versus 80%. The 80% is mostly because you are touching every component, every page template, every form, and every URL.

If you are a Split or Croatia-based business planning a multilingual site — or you have one that is groaning under maintenance pain — I would be glad to take a look. Email info@tonibarisic.com or use the contact form. For more on hiring locally, see Hiring a Web Developer in Split, Croatia. For the SEO fundamentals that apply per locale, the realistic SEO checklist is the place to start.