Multilingual websites done right: TR, EN and NL

The foundation of a well-built multilingual website is giving each language version its own permanent URL and connecting those versions with hreflang annotations. On top of that come titles, descriptions and slugs written separately for each language. Even with correct technical setup, a site without a translation workflow will drift out of sync between languages over time.

URL structure per language

For search engines to recognise each language as a distinct page, each needs its own URL. There are three common options:

• Subdirectories: /tr/, /en/, /nl/. The easiest to manage under one domain and the most common choice.
• Subdomains: en.example.com. Useful when separate infrastructure is required.
• Country domains: example.nl, example.com.tr. A strong local signal, but heavier to run and maintain.

Avoid set-ups that switch language only via a cookie or a parameter such as ?lang=en. All languages then share one address and search engines cannot reliably distinguish the alternates.

hreflang and x-default

hreflang tells search engines which URL holds the same content for which language and region. The core rules in Google's documentation are:

1. Each language version lists all alternates, including itself.
2. Links must be reciprocal: if the TR page points to EN, the EN page must point back to TR.
3. Language codes use ISO 639-1 (tr, en, nl), optionally followed by an ISO 3166-1 Alpha-2 region code (for example nl-BE).
4. x-default names the fallback page shown when no version matches the visitor's language, typically a language selector or the main international version.

hreflang can be supplied in one of three ways: link elements in the page <head>, HTTP headers (for non-HTML files such as PDFs) or the XML sitemap. Whichever you choose, apply it consistently and let the CMS generate the annotations rather than maintaining them by hand. The page's HTML lang attribute should also match the content language, which matters for screen readers and browsers.

Each language version's canonical tag should also point to itself. Canonicalising every language to one version can cause the others to drop out of the index.

Translated slugs and metadata

Translating the body text is not enough. Each language needs its own:

• URL slug (/tr/hizmetler/ versus /en/services/)
• Page title and meta description
• Open Graph title and description
• Image alt text
• Text inside structured data

That is why storing content per language in translation tables is far more robust than duplicating pages by hand. The language switcher should also take visitors to the equivalent page in the other language, not back to the homepage.

Content workflow

The real difficulty begins after launch. When a service page is updated in Turkish but left unchanged in English and Dutch, different markets receive different information. A simple, effective routine: define a source language, flag every change as "awaiting translation" in the other languages, have a native speaker review it, and only then publish. Machine translation can produce a draft, but it should pass human review before going live.

Common mistakes

• Automatically redirecting visitors by IP or browser language; Google recommends offering a language choice instead.
• One-way hreflang links, or annotations pointing to pages that do not exist.
• Publishing untranslated pages under another language's URL.
• Turkish menu, button or form labels left on English pages.
• Identical titles and meta descriptions across languages.

How Grafikare approaches it

On multilingual projects we first define the URL structure and a per-language content model, and we let the system generate hreflang and canonical tags automatically. We then set up a workflow that makes missing translations visible, so that a new language such as Dutch can be added without disturbing the existing structure.