Building a Multilingual Website: A Guide to URL Structure, hreflang and Content Management

In brief: A multilingual website serves the same content in different languages; but “translating the text” is not enough. Three decisions determine your site's fate: 1) the URL structure (a subdirectory /en/, a subdomain en.site.com or a country domain site.com.tr), 2) telling search engines how the language versions relate (hreflang and a self-referencing canonical for each page), 3) how users choose their language (a visible language switcher and explicit, separate URLs instead of automatic redirects). For most businesses the subdirectory structure (/en/) is the most practical start in terms of maintenance and SEO. Every language version should have its own address, its own title and description, only translations that are ready should be indexed, and the translation process should be managed together with content updates. Google's documentation on multilingual and multi-regional sites is the core source for these principles.

Last updated: October 2026

Multilingual versus multi-regional sites

• Multilingual: Content is offered in more than one language (Turkish, English).
• Multi-regional: There are different country versions of the same language (e.g. US and UK English; different currency, prices, products).
• Both together: Combinations of language and country (en-US, en-GB, tr-TR).

Most businesses start with multilingual. The structure is extended when regional differentiation (price, tax, shipping, legal text) is needed.

Decision 1: URL structure

Practical advice: For a language-based structure, a subdirectory is the right start for most businesses. If country-based differentiation (different price/stock/law) is needed, a ccTLD or subdirectory + country code (e.g. /de/, /de-at/) can be considered. Keeping the addresses of the default language (for example Turkish) unchanged is the safest way to preserve existing rankings; the new language is added under /en/.

What to watch in URLs

• Every language version must have its own permanent address; content must not change on the same URL based on a language cookie or browser setting. Otherwise the search engine sees only one language.
• If possible use translated, readable addresses in URLs (such as /en/services/…). A translated address looks more trustworthy and understandable to a user who speaks that language.
• Keep a mapping table between language versions: which Turkish page corresponds to which English page?

Decision 2: hreflang and canonical

hreflang tells the search engine “this page has equivalents in other languages too;” it helps show the right language to the right user.

Basic rules

1. Reciprocal. If page A points to B, B must point to A. One-way annotation is generally ignored.
2. Include itself. Every page also lists its own language equivalent (self-reference).
3. Use the right language/region codes: ISO 639-1 for language (tr, en), ISO 3166-1 for region (tr-TR, en-GB).
4. x-default (optional) indicates the default page for users whose language cannot be determined; it is usually a language selector or the main version.
5. Each language version must have its own canonical: the English page shows its own address as canonical, not the Turkish one. Making language versions canonical to each other drops the translation from the index.
6. Use full URLs (including https and the domain); relative addresses raise the risk of errors.
7. You can provide hreflang in the HTML <head>, in the HTTP header or in the XML sitemap; whichever you choose, be consistent.

Example (HTML)

<link rel="alternate" hreflang="tr" href="https://www.example.com/hizmetler/web" />
<link rel="alternate" hreflang="en" href="https://www.example.com/en/services/web" />
<link rel="alternate" hreflang="x-default" href="https://www.example.com/hizmetler/web" />
<link rel="canonical" href="https://www.example.com/hizmetler/web" />

(On the English page, the canonical must show its own /en/… address.)

No translation, no hreflang

If a page's equivalent is not ready, do not add hreflang for that language and do not publish that language page. Half-translated or empty pages mislead the user and the search engine. Only “fully translated and ready” pages should be offered as language versions.

Decision 3: Language selection and automatic redirects

Redirecting users automatically to another language based on location or browser language looks tempting; but it creates problems:

• Search engine bots often arrive from certain locations and with certain language settings; automatic redirects can prevent the bot from ever seeing the other language versions.
• If a user clicks a link in a particular language and is sent to another language, that is a bad experience.
• Location does not always give correct information about the user's language (a Turkish-speaking user living abroad, multilingual countries).

A safer approach:

1. Offer a separate, directly accessible URL for each language.
2. Put a visible language switcher (in the top menu, on every page, leading to its equivalent).
3. If you do automatic redirection, apply it only on the home page and on the first visit, by browser language and making the user's preference persistent; do not redirect deep pages (/services/...).
4. Instead of redirecting, showing a suggestion banner in the right language (“This page is also available in English”) is the least risky option.
5. The language switcher should go to the page's equivalent where possible, not just throw people to the language home page.

Google's guidelines also warn that automatic redirection by language or location can prevent all versions from being crawled; see the document above for detail.

Content: translation or localization?

Translation carries the text over grammatically. Localization adapts it to the audience:

• Idioms, examples and emphasis change with the target culture.
• Currency, units of measure, date format, phone and address formats are localized.
• Legal and regulatory texts (KVKK/GDPR, terms of use) are prepared appropriately for the country; get legal support for these.
• Keywords are not translated directly; research what people in that language actually search for. The search patterns for “yazılım geliştirme” and “software development” can differ.
• Images and graphics containing text should be translated or be language-independent.

Machine translation and the human eye

Machine translation and AI are fast and cheap for a first draft; but technical terms, brand tone, legal wording and sales copy need human review. Publishing automatic translation directly, without checking, is risky for both quality and search engines. A practical flow: machine draft → someone who knows the field reviews → publish.

Content management on the technical side

For a multilingual site to be sustainable, the content structure must be planned from the start:

• Data model: For each content item (page, post, service, product), a main-language record and a translation record per language. The translation record should have its own title, description, slug, meta fields and publication status.
• Publication status: The translation being able to be “draft/published” independently of the main content.
• Update flow: A flag showing that when the main-language content changes, the translation needs updating.
• Slug management: Unique, non-colliding addresses per language.
• Sitemap: Every language version appears in the sitemap; hreflang can also be given in the sitemap.
• Structured data and Open Graph: Language and URL must be correct in each language version (og:locale, inLanguage).
• Interface text: Use a separate translation dictionary (i18n files) for menus, buttons and form labels; do not embed text in the code.
• In-page links: Internal links from an English page should go to the English equivalents; users should not accidentally land on Turkish.

In modern frameworks (e.g. Next.js), multilingual routing and server-side generation provide a strong base for speed and SEO; for technical details, see our technical SEO with Next.js guide.

The 9 most common multilingual SEO mistakes

1. Switching the language with a cookie/session and serving a different language on the same URL. The search engine sees only one version.
2. Giving hreflang without reciprocity, or incorrectly.
3. Making the canonical of all language versions point to the main language. The translations drop out of the index.
4. Forced redirects by location. Bots and users cannot reach the other versions.
5. Publishing untranslated or half-translated pages.
6. Not translating the title and meta description or leaving them in Turkish.
7. Not adding language versions to the sitemap.
8. Translating word for word without keyword research.
9. Hiding the language switcher or only sending to the home page.

Multilingual site checklist

• The URL structure is chosen (subdirectory recommended); the default language's addresses are preserved
• Every language version has a permanent, separate URL
• hreflang is reciprocal, includes itself and uses the right codes
• Every page shows its own canonical
• Only fully translated pages are live and indexed
• There is a visible language switcher that goes to the page's equivalent
• There is no automatic redirect, or it is only on the home page and remembers the preference
• Title, meta description, slug and structured data are translated
• All language versions are in the sitemap
• Formats such as currency, date and phone are localized
• Legal texts are suitable for each country
• A translation update process is defined

Multilingual sites with Aktaş Digital

We build multilingual sites with separate URLs, persistent language preference, reciprocal hreflang, per-language titles/descriptions and publication-controlled translation management. We apply the principles in this guide on our own site too: Turkish addresses are preserved unchanged, and the English version is offered under /en/ only with content that is ready. To set up a multilingual infrastructure for web applications and corporate sites, to open your existing site to another language or to protect rankings while redesigning, you can write to us through our quote form. On avoiding ranking loss during redesign, see our website redesign checklist and for visibility in AI search our GEO guide.

Frequently Asked Questions

Should I buy a separate domain for a multilingual site?

For most businesses it is not necessary. A subdirectory structure (/en/) concentrates authority on one domain and makes management easier. If you need a strong local presence by country and a separate legal and commercial structure, a ccTLD can be considered.

Do I have to add hreflang for every page?

Only for pages that really have an equivalent and are live. Do not add hreflang for a page with no equivalent; do not publish half pages.

Is a Google Translate plugin enough?

No. A browser-based translation plugin does not produce separate URLs and translated content that a search engine can index. It also has no quality and brand-tone control.

Which page should the language switcher go to?

If possible to the equivalent of the page you are on; if there is none, to the home page of that language. Remembering the user's preferred language also improves the experience.

What happens if translations are not kept up to date?

If the main-language content changes and the translation stays old, you give users inconsistent information. That is why you need a process that tracks translation status and warns on change.

Will adding a second language affect my current ranking?

If set up correctly (default-language addresses are preserved, the new language is on separate URLs, hreflang is right), it does not affect current ranking. Changing existing addresses or redirecting the language automatically is the risky part.

Conclusion

A multilingual site is not a “translate the text” project but an architecture job in which URLs, hreflang, canonicals, language selection and content management are built together. Start with a subdirectory, preserve default-language addresses, give each version its own URL and meta information, publish only ready translations and avoid automatic redirects. The first thing you can do today: prepare a mapping table showing which languages each page of your site will have an equivalent in.