Multilingual Website Design

A multilingual website earns its cost when every language version is built for a market rather than copied from the home language. That means its own address, its own search terms, the contact options people in that country actually use and legal pages that fit local rules.

Below we go through the decisions in the order we make them on client projects: whether a second language is worth it, how to structure addresses and hreflang, how to run translation and updates, and how to measure each language once it is live. Each section gives you something concrete to check, decide or ask.

01When a second language actually pays off

A second language pays off when people in another market already look for what you sell, can buy from you and can be served by someone who speaks their language. Translation is the visible part; the lasting work is answering inquiries, keeping copy current and meeting local legal duties.

If nobody can answer a German email within a working day, a German version costs more trust than it earns. Check five conditions first:

• Demand: inquiries, orders or visits already arrive from that country, or distributors there ask for material in their language.
• Search evidence: people search for your product or service in that language, which keyword tools confirm before anything is written.
• Capacity to respond: a named person can answer messages in the language during that market's business hours.
• Delivery: you can ship, travel or provide the service there, including payment terms and invoicing.
• Upkeep: someone owns the version and updates it when products, prices or staff change.

If only one or two hold, start smaller: a single landing page in the new language for a trade fair or campaign tests demand before you commit to a full version. A bilingual website with two well maintained languages usually does more than a five language site where three versions are out of date.

02Localization goes further than accurate translation

Translation makes text correct in another language; localization makes it convincing to a reader in a particular market. A Turkish product page may open with company history, while a German purchasing manager scans for specifications, delivery terms and certificates, and an American reader may expect a short summary of benefits and a clear next step.

These are differences in how readers decide, not in grammar, which is why a fluent translation can still underperform. Localization usually changes:

• Form of address: formal Sie or informal du in German, first names or titles in English, decided once and used on every page.
• Examples: use cases, holidays and place names that make sense to the local reader.
• Proof: certificates, standards and associations recognized in the target market.
• Calls to action: "request a quote," "book a call" or "send your drawing," matched to how buyers in that market usually start a conversation.
• Imagery: photos of people, products and settings that local readers relate to.

A practical test: ask a native speaker who knows your industry whether the page reads like a local company wrote it. If they keep stumbling over phrases that only make sense in Turkish, it is translated, not localized.

03Choosing between subfolders, subdomains and country domains

For most businesses, language subfolders on one domain are the simplest structure to run, and the choice belongs before any page is written, because changing it later means redirecting every address. Google describes three main options:

• Subfolders: an en folder and a de folder on your existing domain. One platform and one hosting setup, and links earned by any language point to the same domain; country targeting is less explicit.
• Subdomains: a separate host name for each language. Useful when a version needs its own server or team, but each behaves more like a separate site.
• Country code domains: such as a .de or .fr domain. The clearest signal that a site serves one country, but every domain is registered, secured and built up on its own, under each registry's eligibility rules.
• Language parameters: a language added as a parameter to the address; Google does not recommend it.

Decide whether you target languages or countries: a company selling to Germany, Austria and Switzerland usually needs one German version, split by country only when prices, delivery or legal terms differ. We translate page slugs so addresses match local search terms; our slug generator keeps special characters consistent.

04Getting hreflang right on every page

hreflang is an annotation that tells Google which pages are language or regional versions of each other, and it only works when every version lists every other version as well as itself. If two pages do not point to each other, Google ignores the annotations.

The annotations can sit in the page head, in HTTP headers (useful for PDF files) or in the XML sitemap; use one method site wide so errors stay traceable. For each group of equivalent pages:

1. Map every page to its equivalents: your services page in three languages forms one group; a post that exists only in Turkish needs no annotation.
2. Give each version a language code, and add a region code only when you genuinely publish different versions for different countries.
3. List all versions of the group, including the page itself, on every page in that group.
4. Add the default version annotation, which points to the page shown to users whose language matches none of your versions, usually a language chooser or your English page.
5. Confirm that every address in the annotations returns the final page, not a redirect, and that it is the canonical, indexable version.

Our hreflang generator produces a correct first draft. After launch, crawl the site and confirm every return link exists, because a single missing return link breaks that pair.

05Language switcher design without forced redirects

Let visitors choose their language with a switcher that is visible on every page, and do not move them automatically based on their IP address or browser settings. Google advises against automatic redirects between language versions, because they stop both people and crawlers from reaching every version.

A visitor in Frankfurt may be an English speaking engineer; a visitor in London may prefer Turkish. A good switcher meets these criteria:

• Position: the same place on every page, usually the top right of the header; on mobile, at the very top of the menu.
• Labels: each language named in its own language: Türkçe, English, Deutsch. Flags stand for countries, not languages.
• Destination: the link opens the same page in the other language, or the closest section page, never simply the home page.
• Memory: the choice is remembered on the next visit, handled within your cookie consent setup.

A gentle suggestion is acceptable: a small, dismissible banner noting that the page also exists in German when the browser language suggests it. Remember when it is closed, or it becomes as irritating as a redirect.

06Keyword research for each language and market

On a multilingual website, search terms have to be researched in each language from scratch, because the phrase people type in another market is often not the dictionary translation of your Turkish keyword.

Spelling and vocabulary also differ inside one language. An American buyer searches for "aluminum" and a British one for "aluminium"; a holiday rental in British English is a vacation rental in the United States. German joins nouns into single words, while English buyers mix trade terms and plain descriptions. A workable process:

• Start with the buyer: ask your distributors how customers there describe what they need.
• Collect candidates: use a keyword suggestion tool set to the target language and country, then look at what currently ranks for each candidate.
• Read the results page: if marketplaces dominate, your page may need a different angle, such as a specification page.
• Assign one primary term per page: write the title, description, main heading and slug of that language version around it.
• Record variants: note spelling variants, plurals and compounds so writers use them naturally in the body copy.

Keep the result as a keyword map: one row per page, one column per language. It becomes the brief for writers and the reference for tracking rankings later, which our SEO work reports separately for each language.

07A content workflow that keeps languages in step

Multilingual sites rarely fail at launch; they fail months later, when the Turkish page changes and the other versions quietly do not. Preventing that drift takes a routine with a few fixed parts:

• Master language: decide which language is the source for each page; for an export catalog it may be English.
• Glossary: product names, technical terms and words you never translate, with the approved form in each language.
• Translation memory: ask your translation agency to keep a translation memory, a database of previously translated sentences, so repeated text stays consistent and unchanged sentences are not translated again.
• Change log: a simple sheet listing each page, its languages and the date each version was last updated; when the master changes, the other versions are flagged.
• Review in context: a native speaker reads every page on the staging site, not in a spreadsheet, because awkward line breaks, truncated buttons and overlong headings only show up on screen.

In the content panel, editors should see which versions exist for a page and which are older than the master, so your team notices an outdated translation before a customer does.

08Machine translation: useful draft, risky final copy

Machine translation is a reasonable way to produce a first draft and a poor way to publish pages nobody has read. Google's spam policies name pages generated through automated transformations such as translation, where little value is added for users, as an example of abuse.

Search is only part of the risk: a mistranslated tolerance or a wrong unit costs trust with a buyer who has never met you. Where it fits depends on what is at stake:

• Helps: first drafts of long pages, which a fluent reviewer then edits against the glossary.
• Helps: understanding incoming inquiries in languages you do not cover yet, before you reply through someone who speaks them.
• Helps, with checks: long specification tables and image descriptions, once every number and unit has been compared with the source.
• Hurts: headlines, slogans and calls to action, where tone and rhythm matter more than literal meaning.
• Hurts: legal texts, which must be written for the rules of the market, not converted from the Turkish version.

Browser translation widgets are a separate problem: they translate on the fly at the same address, so search engines see only the original. Our rule is machine draft, glossary applied, review by someone fluent in the industry.

09Forms, currencies, units and contact channels

A visitor who reads flawless English copy and then meets a form requiring a Turkish ID number will usually leave. Everything touched after reading needs the same localization as the text.

• Forms: phone fields accept country codes, address fields do not assume Turkish provinces, and labels, error messages and confirmation emails are translated.
• Routing: each language form sends its message to a person who speaks that language, and the automatic reply arrives in the language the visitor used.
• Currency and units: if you show prices, use the currency of the target market; give dimensions in inches and pounds alongside metric values for American buyers.
• Dates and numbers: German uses a decimal comma where English uses a point, and day and month appear in a different order in American English, so a delivery date written the Turkish way can be misread.
• Time zones and channels: state opening hours with the time zone, and offer the channel buyers in that market actually use, whether email, phone or a messaging app, as long as you can staff it.

Before launch, fill in every form in every language yourself and check where each message lands, what the visitor receives and how long a reply takes.

10Legal pages written for each market

Legal pages are written for the law of each market, not translated from the Turkish versions. Each version links to the texts that apply to its readers, reviewed with your legal adviser.

• Turkey: KVKK, Law No. 6698, requires an information notice (aydınlatma metni) under Article 10; link it from every form on the Turkish version.
• European Union: companies outside the EU that offer goods or services to people in the EU can fall under the GDPR, so the English and German versions need a privacy notice that reflects it, and cookie consent is needed before non essential tracking.
• Germany: § 5 DDG requires commercial digital services to keep an easily found, permanently available legal notice (Impressum); for regulated professions it includes the chamber, the legal job title, the state that granted it and the professional rules.
• Germany, technical side: § 25 TDDDG requires consent for storing or reading non essential information on devices, and Art. 28 DSGVO requires a data processing agreement with service providers such as form, booking or newsletter tools.

For other markets, check local requirements with an adviser there. We build the pages, link them in each footer and show the cookie banner in the visitor's language.

11Technical SEO for each language version

Each language version needs its own clean technical signals: a canonical tag pointing to itself, a sitemap entry, translated metadata and the same speed as the main version.

• Canonicals: the canonical tag, which names the preferred address of a page, points from each language version to itself and never to the Turkish original; pointing translations to the original tells Google they are duplicates.
• Sitemaps: one sitemap per language, or one sitemap carrying the hreflang annotations, submitted in Search Console.
• Visible language: Google works out a page's language from its visible content, not from the lang attribute in the code, so menus, footers, buttons and body copy all appear in that language. Keep the lang attribute correct anyway for browsers and screen readers.
• Metadata: titles, descriptions, alt text and structured data are translated too.
• Speed and layout: fonts must contain every character you need, such as Turkish ğ and ı or German ß, without loading extra files that slow down LCP, the time until the main content appears.

Measure Core Web Vitals per language template. Google's "good" thresholds at the 75th percentile are LCP of 2.5 seconds or less, INP (responsiveness to taps and clicks) of 200 milliseconds or less and CLS (unexpected layout movement) of 0.1 or less. German text often runs longer than Turkish or English, so buttons can wrap to two lines and shift the layout.

12Measuring each language as its own channel

On a multilingual website, report every language as a separate channel, otherwise a weak version hides inside a healthy total.

• Search Console: add each language folder as its own property or filter by its address prefix, then compare queries, countries and click through rate per language.
• Analytics: segment by language folder and by country to see where interest actually comes from.
• Conversions: record the language with every form submission, call and message, so you know which version produces inquiries, not just traffic.
• Advertising: run separate campaigns or ad groups per language, with ads written in that language and landing pages in the same language. Google Ads Quality Score, a diagnostic built from expected click through rate, ad relevance and landing page experience, suffers when a German ad leads to an English page. Our Google Ads management builds campaigns this way.
• Consent: Google requires consent mode for measurement and personalized advertising features for users in the European Economic Area, so set it up before launch rather than after the first report looks incomplete.

Review the numbers monthly with a simple rule. Impressions without clicks point to titles and descriptions; visits without inquiries point to the contact path, the form or the reply time in that language.

13Common mistakes and what to do instead

Most multilingual mistakes are made before launch, and these six come up repeatedly when we review existing sites:

• Launching every language at once with half finished copy: launch the languages you can maintain properly, then add the next one when the first is producing inquiries.
• Translating menus but not the rest: body copy, PDFs, error pages, cookie banners and confirmation emails stay in Turkish; instead audit every template and every automated message for each language.
• Putting text inside images: banners and infographics with Turkish text embedded cannot be translated or indexed; instead keep text in the page and use images without lettering.
• Translating customer reviews and presenting them as original: this misleads readers; instead show reviews in their original language with a clearly marked translation next to them.
• Letting a plugin generate every page in every language: tag archives, empty categories and thin pages multiply; instead decide which pages deserve a version in each language and leave the rest out of the language groups.
• Changing the address structure after launch without a plan: moving from parameters to folders breaks rankings and links; instead map every old address to its new one with permanent redirects and update the hreflang groups the same day.

A short written decision on languages, structure and ownership, agreed before design starts, prevents most of them.

14Choosing a partner for a multilingual website

Choose a team that asks about your markets before it asks about languages, and that can show a multilingual website it runs itself. Our own site runs in Turkish, English and German on subfolders, with reciprocal hreflang and legal pages per language, so the setup we recommend is the one we maintain every day.

Whoever you talk to, these questions separate a careful plan from a translation plugin:

• How are hreflang, canonicals and sitemaps produced, and what happens when we publish a page in one language only?
• Who writes and who reviews each language, and where is the glossary kept?
• Can our editors see which versions are older than the master page?
• Which legal pages will each market get, and who reviews their content?
• How will we see inquiries per language after launch?

The same principles apply to a manufacturer selling abroad or a hotel website for international guests. If the base site still needs work, start with our website design service and plan languages in from the beginning.

For package scope, see the website pricing section; additional languages are quoted in writing based on pages, languages and who handles localization. To start, tell us which markets you want to reach, and after a short first call we will send a proposed URL structure, a language plan and a written quote.