A British skincare brand adds a German version of its site. Six months later, half the German pages aren't in Google at all, the rest show English titles, and a visitor from Munich is bounced to the US store by an IP redirect and shown prices in dollars.
A multilingual site is more than translated pages. Unless URL structure, hreflang, redirect behaviour, local keywords, currency and legal pages are set up together, neither search engines nor customers in that country will treat you as a local option. This guide walks through the decisions to make before you add the first new language.
First decision: are you targeting a language or a country?
They're not the same thing. A Spanish-language site can serve Spain, Mexico and much of Latin America; but if prices, delivery and legal terms differ by country, you're really selling into separate markets. German works the same way: Germany, Austria and Switzerland share a language but not a currency, spelling conventions or customs rules.
A simple rule helps. If only the language changes, target the language (de, fr, es). If price, currency, delivery, range or legal text change by country, target language and region together (de-DE, de-CH). Before deciding, answer these honestly:
- Which countries can you actually deliver to, at a reasonable cost and speed?
- Will prices and currency change by country?
- Is the product or service range the same in each market?
- Who will answer customer questions and handle returns in that language?
- Where do you need a local entity, representative or tax registration?
Our experience is consistent: two markets done properly almost always bring in more business than ten languages done halfway. Translation is the cheapest line item. The real load is support, returns, compliance and keeping every language current.
Domain structure: country domains, subfolders or subdomains
Google's documentation on multi-regional sites lists four options with their pros and cons. The choice is as much commercial as technical, because each structure means a different maintenance load and a different way authority builds up.
| Structure | Example | Pros | Cons |
|---|---|---|---|
| Country-code domain | example.de | Clearest country signal, local trust | Separate cost and infrastructure per domain, targets one country only, links build up separately on each |
| Subfolder on a generic domain | example.com/de/ | Easy to set up and maintain, one domain and shared authority | Single server location, harder to separate sections |
| Subdomain | de.example.com | Easy to set up, can use different servers | Users may not know whether “de” means language or country, separate upkeep |
| URL parameter | example.com?lang=de | Practically none | Not recommended by Google, hard to segment and target |
For most businesses, the right answer is subfolders on one .com domain: /de/, /fr/, /us/. Links and brand strength accumulate in one place, you run one platform, and launching a market is as simple as opening a folder. If your home market has lived on a country domain such as .co.uk for years, you don't have to move it; the UK site can stay on .co.uk while other markets sit on .com. hreflang works across domains.
Country domains make sense when you have a local entity, a strong local brand or a separately run team in that country. Buying a .de purely to look more local mostly gives you a second site to grow from scratch. Also note that Google treats some country codes, such as .io, .co, .me and .tv, as generic, so they carry no country signal. Google ignores geo meta tags entirely, and doesn't treat server location as a definitive signal because of CDNs.
hreflang: the rules and the most common mistakes
hreflang tells Google about the other language and regional versions of a page, so that a user in Germany gets the German page and a user in the UK gets the British one. Google doesn't use hreflang or the HTML lang attribute to work out a page's language, though; it reads the content. A page with a German title and an English body won't be rescued by hreflang.
You can implement it three ways: link elements in the page head, an HTTP header (for non-HTML files such as PDFs) or an XML sitemap. Google treats them as equivalent and says using more than one brings no benefit in Search. For sites with thousands of pages, the sitemap is usually the easiest to manage.
- Every version lists itself as well as all other versions.
- The relationship must be reciprocal: if the English page points to the German one, the German page must point back. If two pages don't point to each other, Google ignores the tags.
- Use fully qualified URLs starting with https, not relative paths.
- Language codes follow ISO 639-1 (en, de, fr, ar), with an optional region in ISO 3166-1 Alpha 2 (de-AT, en-GB). A region code can't be used on its own.
- The United Kingdom is en-GB, not en-UK. Google ignores reserved codes such as UK, EU and UN.
- x-default marks the fallback page for users who match no version, typically a language selector or your main version.
- Every URL in your hreflang set should return 200, be indexable and be its own canonical; pointing hreflang at redirecting or noindexed pages breaks the signal.
The mistakes we see most in the field
One-way annotations come first: English pages point to the other versions, but those versions never point back. Close behind is every language version carrying a canonical to the English home page, which tells Google the others are duplicates and cancels hreflang out. Third, linking every version to the foreign home page instead of the equivalent page. Fourth, half-translation: Google's documentation says localised versions are only treated as duplicates when the main content is left untranslated, and pages where only the navigation was translated are exactly that.
Why automatic IP redirects do damage
Google's guidance is direct: avoid automatically redirecting users from one language version to another based on their perceived language, and don't use IP analysis to adapt your content. The reasons cut both ways.
For users, a German speaker living in London or an American on holiday in Spain loses the ability to choose. For search engines, Google's documentation notes that its crawler's default IP addresses appear to be in the USA and that it sends requests without an Accept-Language header. On a site that redirects by IP, Google may simply never see some versions.
The fix is unglamorous but solid: a visible language selector on every page, linking to the equivalent page and naming each language in itself (Deutsch, Español, English). If a visitor's location and the page language don't match, offer a small banner that doesn't block the page, something like “This page is also available in German”, and remember the choice with a cookie.
Localisation, not just translation
Machine translation now produces a good first draft, and Google has removed its old advice to block auto-translated pages with robots.txt. That doesn't mean any translation is welcome: Google's spam policies explicitly list producing many pages through automated transformations, translation included, that offer little value to users as an example of scaled content abuse. Our practice is a machine draft followed by a native-speaking editor, with titles, meta descriptions, calls to action and legal text always checked by a person.
Keyword research per market
Translating a keyword isn't the same as finding what people search for. The British “sofa” is often a “couch” in the US; the German equivalent of a corner sofa might be “Ecksofa” or “Wohnlandschaft”, depending on the product. Set location and language for the target market in Google Ads Keyword Planner, filter Search Console performance by country and look at who actually ranks in that country's results. Each market needs its own keyword map, and a category that matters in Germany may not exist in your home range at all.
Currency, delivery, payment and legal pages
Google lists local addresses, phone numbers, language and currency among the signals it uses to understand who a page is for. For customers, they're simply trust: a German shopper expects euro prices including VAT, clear delivery times and returns terms, and familiar payment options such as PayPal, Klarna or SEPA direct debit. Since Brexit, UK businesses shipping to the EU need to be clear about customs and import VAT, and Switzerland, outside the EU, needs the same clarity.
Same language, different region: en-GB, en-US, de-DE, de-AT, de-CH
Separate regional versions of the same language only make sense when something actually changes. If price, currency, delivery, spelling and legal details are the same, one “en” or “de” version is enough; separate versions just add maintenance.
| Market | hreflang | What changes | Watch out for |
|---|---|---|---|
| United Kingdom | en-GB | Pounds, colour and optimise spellings, postcode, VAT-inclusive prices | Never en-UK |
| United States | en-US | Dollars, color and optimize spellings, ZIP code, state sales tax | Imperial units such as inches and pounds |
| Germany | de-DE | Euros, Impressum, withdrawal notice | Formal “Sie” form of address |
| Austria | de-AT | Euros; local words such as Jänner and Paradeiser | Austrian legal disclosures |
| Switzerland | de-CH | Swiss francs, ss instead of ß, non-EU customs | French- and Italian-speaking regions (fr-CH, it-CH) |
If regional versions are near-identical, Google may treat them as duplicates and pick one. Each regional version should therefore be its own canonical, link to the others with hreflang and carry genuine differences in price, delivery, spelling and contact details. Where two copies target the same audience, say example.de and example.com/de/ showing the same German content, Google recommends choosing one and marking it with rel=canonical.
Switzerland deserves its own note. Swiss Standard German doesn't use ß at all: it's “Strasse”, not “Straße”. The country also has French- and Italian-speaking regions, so the Swiss market isn't a single language. Prices are in francs, and data protection falls under Switzerland's own Federal Act on Data Protection rather than the EU GDPR.
Content management and translation workflow
Most multilingual sites break down in the workflow, not the translation. The English page is updated and the German one keeps an old price for six months; a new product launches in English and opens half-translated in French. Your CMS needs to be set up to prevent this.
- Localised URL slugs: /de/produkte/ecksofa, not /de/products/corner-sofa.
- Separate title and meta description fields per language; if a translation is missing, the page shouldn't publish in that language.
- hreflang generated automatically from content relationships; a hand-maintained list breaks at the first update.
- Other languages flagged as out of date when the source text changes.
- Right-to-left support (dir=rtl) and a matching design for languages such as Arabic.
- A glossary of brand terms, product names and words never to translate. Translation management tools such as Crowdin, Lokalise or Phrase keep the glossary and translation memory in one place.
Give every market an owner: someone who reads the language natively, sees local customer questions and will spot anything odd on the page first. They needn't be on your payroll, but they should be the last reader of every text that goes live.
What Search Console offers today, and what it doesn't
The International Targeting report in Search Console was retired in September 2022, and the country targeting setting is no longer supported. Google said at the time that it continues to support hreflang and that its recommendations for multilingual and multi-regional sites still stand. So there's no switch today that says “/de/ is for Germany”; the signals come from the domain, hreflang and the content itself.
Set up measurement deliberately. Add each language folder (such as https://example.com/de/) as a separate URL-prefix property so each market gets its own reports. Read the performance report with country and page filters together, and use URL Inspection to see which canonical Google has chosen for each version. Check hreflang reciprocity regularly with a crawler, and track country and language together in Google Analytics 4. Where Google isn't the only major search engine in a target market, add that engine's webmaster tools too.
Where to start
- Choose your target markets and decide for each whether you're targeting a language or a language and region.
- Settle the domain structure; unless you have a specific reason, subfolders on one domain.
- Run keyword research separately for each market and plan the page structure from it.
- Set up language-specific URLs, titles and meta fields in your CMS, with hreflang generated automatically.
- Remove automatic IP redirects; use a language selector on every page and an optional suggestion banner instead.
- Have a native-speaking editor review every machine draft, and always titles, meta descriptions and legal text.
- Prepare currency, delivery, payment methods and legal pages separately for each market.
- Crawl the site before launch to check hreflang: reciprocity, codes and canonical consistency.
- Add each language folder to Search Console as its own property and monitor each market separately for the first three months.
- Name an owner for each market who keeps its content current.
AYTE Digital publishes its own site in Turkish, English and German, and we apply the same structure for clients expanding abroad, from the technical set-up to the native-editor process. Which market to open first we decide together, based on your sales and demand data.
