A common pattern: a product team ships German, French and Japanese versions of their site, the translations are good, and three months later organic traffic from Munich, Lyon and Osaka is close to zero. Nothing is broken in an obvious way. The pages are indexed. They just don't rank, or Google keeps showing the English page to German searchers.
International SEO fails quietly. The fixes are mostly technical and mostly unglamorous, but each one has a specific failure mode you can check for. This is the checklist we work through when a localized site goes live.
Pick a URL structure you can live with
You have three options for where each locale lives, and the choice is hard to reverse later because every migration costs you ranking for a while.
| ccTLD (example.de) | Subfolder (example.com/de/) | Subdomain (de.example.com) | |
|---|---|---|---|
| Geo signal | Strongest, built in | Set via hreflang and content | Set via hreflang and content |
| Shares domain authority | No, each domain starts fresh | Yes | Partly, varies in practice |
| Operational cost | Several domains, certs, registrars | One site | One domain, separate hosts |
| Local trust | High in some markets | Neutral | Neutral |
| Best fit | Large budgets, local entities | Most product companies | Separate stacks per region |
For most product companies we recommend subfolders. One domain means every backlink you earn helps every locale, and you run one deployment. ccTLDs make sense when you have a real local business behind them and the budget to build links for each domain separately. Some also carry registration rules: .jp and .com.au both require a local presence, so check before you plan around them. Subdomains are usually a sign that the localized site runs on a different stack, which is a fine reason, but it's an infrastructure decision rather than an SEO win.
Whatever you choose, don't redirect visitors automatically based on IP address or browser language. Googlebot mostly crawls from US IP addresses, so an IP redirect can stop it from ever seeing your German pages. Show a dismissible banner suggesting the local version instead.
hreflang, done properly
hreflang tells Google which URL to show for a given language and region. It doesn't boost rankings by itself. What it does is swap the right version into results, so a searcher in Sydney gets your en-AU page instead of en-US. When it's wrong, Google ignores it, often without telling you.
The rules that trip teams up most often:
- Every page lists every alternate, including itself. The German page carries the full set of tags, not just a link back to English.
- Annotations must be reciprocal. If en-US points to de-DE but de-DE doesn't point back, Google discards the pair.
- Codes are ISO 639-1 language plus an optional ISO 3166-1 region. It's en-GB, not en-UK, and ja, not jp.
- Each URL in the set returns 200 and is self-canonical. Pointing hreflang at a redirect or a noindexed page breaks the cluster.
- Add x-default for the page shown to everyone who doesn't match a listed locale, usually your language selector or the main English page.
You can declare hreflang in the HTML head, in HTTP headers (useful for PDFs), or in the XML sitemap. On sites with more than a handful of locales, the sitemap is easier to keep correct because it's generated in one place instead of in every template. Pick one method. Mixing them invites contradictions.
Research keywords in the market, not in a translation tool
Translated keywords are the most expensive mistake on this list because the whole content plan sits on top of them. A literal translation is often a phrase nobody types. German searchers may use an English loanword where your translator picked the formal German term, or the reverse. Japanese searchers might search in katakana for one product category and in kanji for another, and the volumes can differ by an order of magnitude.
Do the research per market with a native speaker who knows the domain. Start from the English seed list as a map of topics, then for each topic find what people in that market actually search, using the keyword tool's location and language settings for that country. Check the live results page too. If the top results for your translated phrase are dictionary entries or unrelated products, the intent is different and you need another term.
Expect the topic list itself to change. A compliance angle that barely registers in the US may be a primary buying concern in Germany. Australian buyers search for GST handling where US buyers search for sales tax. Those differences are content opportunities, not just vocabulary.
Localize metadata and slugs, not just body copy
We regularly audit localized sites where the body text is German but the title tag, meta description and Open Graph tags are still English because they live in a different file. Google reads the title tag closely. An English title on a German page sends a mixed signal and looks wrong in the results.
Put every piece of metadata through the same translation and review workflow as the page: title, description, image alt text, structured data fields like product names and FAQ answers, and the html lang attribute. Write titles to the length limits of each language. German compounds run long, so a title that fits in English may get cut off in German; Japanese titles fit more meaning into fewer characters.
Slugs are a judgment call. Localized slugs such as /de/rechnungsverarbeitung/ help a little with relevance and click-through, and they read naturally to local users. They also make routing more complex, because you need a mapping table between locales. For Japanese, you can use Japanese characters in URLs, but they get percent-encoded when copied and look like noise in emails and chat. Many Japanese sites keep romanized or English slugs for that reason. Either way, decide once and keep it consistent.
en-US, en-GB and en-AU without duplicate content
Three English versions that differ only in spelling and currency are near-duplicates. Google won't penalize you for that, but it will pick one URL to show and fold the others into it, which can mean your Australian visitors see US pricing.
hreflang is what fixes this. With correct en-US, en-GB and en-AU annotations, Google can treat them as a cluster and serve the right one per country. Keep each page self-canonical. A common mistake is pointing the canonical of the en-GB page at en-US to avoid duplication, which tells Google the UK page shouldn't be indexed at all and cancels the hreflang.
Then give each version real local substance where it matters: prices in local currency including or excluding tax as local convention expects, local phone numbers and addresses, regional terms (VAT versus GST versus sales tax), and case studies or examples from that market. If there is genuinely nothing to localize on a page, it's reasonable to have one en page with a single English alternate rather than three copies.
Not every market is a Google market
For Germany, France, Australia, the UK and the US, Google holds the large majority of search, so optimizing for Google covers most of what you need. Bing still deserves a look for B2B audiences on corporate Windows machines, and it has historically leaned on the content-language meta tag more than on hreflang, so it costs little to set both.
Japan looks like a two-engine market, but Yahoo! JAPAN has used Google's search technology since 2010. Rank well on Google in Japan and you'll largely rank on Yahoo! JAPAN too. The page layout and ads around the results differ, but the organic work is the same. South Korea is the market where this changes: Naver has its own index and its own content ecosystem, so plan separately if Korea is on your roadmap.
Launch checks and what to monitor
- Crawl the site with a tool that validates hreflang and fix every missing return link and non-200 target.
- Confirm each locale is in the sitemap and that Search Console has no unexpected 'duplicate, Google chose different canonical' clusters.
- Search from each target country, using a VPN or the location setting, for your brand plus a core term, and check which locale appears.
- Track rankings and clicks per locale folder, not site-wide, so a weak market isn't hidden by a strong one.
Give new locales a few months before judging them. A fresh language section has no history and few local links. The technical setup decides whether it can rank at all; local content and links decide how far it climbs.
Questions we get asked
- Is a subfolder or a ccTLD better for international SEO?
- For most product companies a subfolder is the better default because every locale shares the main domain's authority. A ccTLD gives a stronger geo signal but each domain has to earn links on its own.
- What does hreflang x-default do?
- It names the page Google should show to searchers whose language or region doesn't match any listed alternate, usually a language selector or the main English page.
- Will en-US and en-GB pages count as duplicate content?
- There is no penalty, but Google may fold them together. Correct hreflang, self-referencing canonicals and real local details like currency and tax terms keep both versions indexed.
- Do I need to optimize separately for Yahoo! JAPAN?
- Mostly no. Yahoo! JAPAN uses Google's search technology, so ranking well on Google in Japan carries over. Korea is different, since Naver runs its own index.