In Part 1, we covered why a genuinely multilingual website is one of the highest-leverage moves a business can make right now, and how it directly reshapes SEO, AEO, and GEO visibility, layer by layer. Here in Part 2, we get into execution — because this is where almost every multilingual project actually falls apart. Not on strategy. On the files nobody thought were important.
5. Impact on LLMs Directly (Training and Retrieval)
Beyond real-time search and generative answers, LLMs are also trained on, and increasingly retrieve live from, crawlable web content. This is the layer businesses think about least, and it may end up mattering most.
- LLMs using retrieval-augmented generation (RAG) pull live content to answer prompts. Native-language pages get retrieved and cited far more reliably than machine-translated equivalents, which models increasingly detect and quietly down-weight as low-confidence.
- Well-localized, high-quality multilingual content increases the probability of being represented in an LLM's own knowledge base for that language — meaning your brand can get referenced correctly even when a user never visits your site at all. Your website becomes a source, not just a destination.
- Consistent terminology and clear structure across languages help LLMs build an accurate internal "entity model" of your brand, which sharply reduces the risk of a model hallucinating incorrect information about your products, pricing, or services in a language you never actually built content for.
- AI crawler access matters as much as content quality. A model can't retrieve what it's blocked from reading. Explicit AI crawler directives in
robots.txt, per-localellms.txtfiles, and IndexNow pings for every localized URL all directly affect whether your native-language content ever gets discovered by the systems doing the citing in the first place.
6. The Detailed Workflow: Building a Multilingual Website Correctly
This is where most projects fail — not in strategy, but in execution. A proper multilingual rollout follows a defined technical and content workflow, and a handful of specific files carry wildly disproportionate weight relative to how often they get skipped.
Step 1 — Locale and Market Research
Identify target languages based on actual demand data — search volume, market size, existing traffic by geography — rather than assumption. Output: a locale priority matrix.
Step 2 — URL Architecture Decision
Choose one of three structures before any content work begins:
- ccTLD (example.de, example.fr) — strongest geo-signal, highest maintenance cost.
- Subdomain (de.example.com) — moderate signal, moderate cost.
- Subdirectory (example.com/de/) — easiest to maintain, and the most commonly recommended structure for consolidating SEO authority under one domain.
Step 3 — Technical Foundation Files
These are the files that carry the most weight, and are the ones most frequently done wrong — or skipped entirely:
| File / Element | Purpose | Impact if Missing or Wrong |
|---|---|---|
hreflang tags (in <head> or via XML sitemap) |
Tells search engines which language/region version of a page to serve to which user | Wrong-language pages served in results; duplicate content penalties; ranking cannibalization between language versions |
| hreflang x-default | Tells crawlers which version to fall back to for unmatched languages/regions | Ambiguous fallback behavior; the "wrong" language can get served to unmatched visitors by default |
| XML sitemap per locale (or unified with hreflang annotations) | Ensures every localized URL is discoverable and crawled | Entire language sections can go unindexed, silently, for months |
| robots.txt (with AI crawler directives) | Confirms crawlers — and AI crawlers specifically — aren't accidentally blocked from locale subfolders/subdomains | Whole language versions silently excluded from search indexing and AI retrieval alike |
| Language-specific meta titles & descriptions | Native-language snippets in SERPs | Mismatched language in search snippets tanks click-through rate immediately |
| Structured data (JSON-LD) per language | Enables AEO/GEO answer eligibility per locale | Loss of featured snippets, AI Overview citations, and voice answers in that language |
| llms.txt / llms-full.txt per locale | Gives AI models a direct, machine-readable summary of who you are, in the language they're being asked about you in | AI models fall back to whatever fragments they can find — or say nothing about that market at all |
Translation/locale resource files (.po, .json, .xliff, or CMS-native locale tables) |
Central source of truth for all UI and content strings per language | Inconsistent terminology, broken UI strings, and content drift between languages over time |
| Canonical tags (self-referencing per locale) | Prevents locale pages from being seen as duplicates of each other | Search engines may consolidate and rank only one language version, burying the rest |
| Content style guide / glossary per locale | Ensures terminology, tone, and branding consistency across translators or AI translation passes | Inconsistent entity naming, which confuses both search engines and LLMs about your brand identity |
Step 4 — Native Content Creation (Not Translation)
Content should be transcreated — written or substantially rewritten with native fluency and SEO/AEO intent for that specific market — rather than translated word-for-word. This includes independent keyword research per language, not a translated keyword list bolted on afterward. Even when a first pass is AI-translated for speed, a human native-language review pass before publishing is what actually catches the idiom that reads fine to a machine and slightly wrong to an actual reader.
Step 5 — Structured Data & Schema Localization
FAQ, HowTo, Product, and Organization schema should be implemented per language, with translated field values — not just duplicated English schema with a language tag slapped on top and called done.
Step 6 — Internal Linking and Language Switcher
A visible, crawlable language switcher — not JavaScript-only, which crawlers may never execute — that links every locale version to its equivalent pages, reinforcing the hreflang relationships rather than contradicting them.
Step 7 — Ongoing Content Parity Monitoring
Language versions drift out of sync the moment the source site gets updated and the translations don't. A content parity workflow — often a translation management system (TMS) integrated with the CMS, or at minimum a disciplined per-page changelog — keeps every locale current instead of slowly, quietly stale.
Step 8 — Performance & Local Hosting Considerations
CDN configuration and regional hosting affect Core Web Vitals per region, which factors into both SEO ranking and the user-experience signals that feed into AEO/GEO eligibility. A fast English page and a sluggish translated one send mixed signals about the same brand.
7. Why a Properly Built Multilingual Site Beats a Google-Translated One
Slapping a Google Translate widget onto a single-language site is the most common shortcut in the industry — and it doesn't just underperform. It actively works against every goal above, while giving the appearance of having solved the problem.
| Factor | Google-Translated Widget | Properly Built Multilingual Site |
|---|---|---|
| Indexability | Often not crawlable at all — client-side JS translation widgets frequently aren't rendered or indexed by search bots | Fully indexable, static or server-rendered localized URLs |
| URL structure | Usually stays on a single URL with no locale path | Dedicated URLs per locale, enabling independent per-language ranking |
| Translation quality | Literal, context-blind machine translation; frequently mangles idioms, technical terms, and brand names | Native or professionally transcreated content with correct tone and terminology |
| Keyword targeting | None — it translates existing English keywords verbatim, which rarely match native search behavior | Independent keyword research per language and market |
| hreflang / canonical signals | Not implemented | Fully implemented, correctly cross-referenced across every locale |
| AEO/GEO/LLM eligibility | Excluded — inconsistent, low-confidence machine text is rarely cited by answer engines, generative engines, or LLMs | Eligible for featured snippets, AI Overviews, and direct LLM citations |
| Brand trust | Visible "translated by Google" banners and awkward phrasing quietly undercut credibility | Native-quality content builds trust and measurably improves conversion |
| Long-term cost | Appears free, but generates close to zero organic value in target languages — the market opportunity gets wasted, not saved | Higher upfront investment, with compounding organic traffic and citation value over time |
The core issue is that a translation widget treats language as a display-layer patch — it changes what a human reader sees, but does nothing to change what crawlers, answer engines, or LLMs actually retrieve and evaluate. A real multilingual build treats language as infrastructure: it changes the URLs, the metadata, the schema, and the underlying content itself. That's the only version of "multilingual" that actually gets discovered, ranked, and cited in that language — everything else is a translated coat of paint on an otherwise invisible site.
This is exactly the standard we build to. Native-language pages on dedicated locale URLs, hreflang and canonical tags fully implemented, JSON-LD schema translated (not duplicated) per language, per-locale llms.txt files for direct AI-entity queries, AI-translated first drafts with a human native-language review before anything goes live, and a content parity workflow that keeps every language current as the site evolves — not a widget bolted on and forgotten.
8. Conclusion
The discovery landscape has split into at least four distinct systems — SEO, AEO, GEO, and LLM retrieval — and all four now operate on a language-by-language basis. A business that exists in only one language is invisible across an increasing share of these systems, regardless of how strong that single-language presence is. Building a true multilingual site — with correct hreflang implementation, localized structured data, native content, and a disciplined content-parity workflow — isn't just an SEO tactic anymore. It's the foundation for being found, understood, and correctly represented across every single layer of how people, and AI, now search.
Want your website built as real multilingual infrastructure, not a translate widget?
Let's map out the right locales and get it built properly.
Get Started