Multilingual SEO in Practice — What We Learned Running KO, EN, and FR Sites Ourselves
The core of multilingual site SEO isn’t “translating as much as possible” — it’s structuring things so each language version points search engines accurately to the others. In practice, there are three decisions to make: ① domain structure (ccTLD vs. subdomain vs. subdirectory), ② hreflang integrity (do each language’s URLs reference each other correctly?), and ③ content strategy (translate everything, or prioritize by market?). Rather than general theory, this is a record of the problems we ran into — and how we solved them — while running growthmk.com’s Korean, English, and French sites ourselves as subdirectories (/en, /fr) of a single domain. We used Google’s official guide to multi-regional sites as our baseline, and wrote down where that baseline broke down in actual operation and how we fixed it.
What’s Actually Hard About Multilingual SEO?
When most teams first build a multilingual site, they treat translation quality as the biggest variable. But what actually tanks search performance isn’t how natural the translation reads — it’s structural integrity. If a Korean and an English version of the same article get read by search engines as two unrelated pages, or conversely if two completely different articles get incorrectly grouped as translations of each other, no amount of translation quality will get the right language in front of the right reader.
This isn’t an isolated problem — the data confirms how common it is. In Ahrefs’ analysis of 374,756 domains, 67% of sites that had implemented hreflang had some kind of error (Ahrefs’ hreflang research). hreflang, the core signal here, is “easy to add, hard to add correctly” — and we weren’t an exception either. All three decisions below exist to protect that integrity, and for each one we’ve laid out Google’s official principle (from its documentation) side by side with what we actually chose and why (from running the site). That said, multilingual SEO only works on top of the fundamentals — crawling, indexing, rendering — so if you want that foundation first, we’d recommend starting with our complete technical SEO guide.
Decision 1 — Domain Structure: Subdirectory vs. Subdomain vs. ccTLD
The principle: Google allows all three, but spells out the trade-offs for each
Google’s guide to multi-regional sites lays out three options for language- and region-specific URL structures: a country-code domain (ccTLD, e.g. example.fr), a subdomain under a gTLD (fr.example.com), or a subdirectory under a gTLD (example.com/fr). The official documentation doesn’t declare a single right answer — it compares trade-offs instead. A ccTLD sends the clearest regional-targeting signal, but requires separate infrastructure per domain, which gets expensive. A subdomain is easy to set up and lets you separate server locations, but its regional targeting is hard to infer from the URL alone. Google explains that a subdirectory is easy to set up and keeps maintenance overhead low, since it shares the same host (Managing multi-regional and multilingual sites). That same document explicitly states that distinguishing language via a URL parameter (?lang=fr) is “not recommended.”
Our choice: A single domain plus subdirectories, with legacy subdomains cleaned up via 301s
We decided to run all three languages under a single growthmk.com domain, using /en and /fr subdirectories. There were three reasons.
- Consolidating domain authority — When every language’s content accumulates under one domain, the trust earned through Korean content also works as shared host equity for the English and French directories. Split the domain into three, and your backlinks and trust scatter across three as well.
- Operational simplicity — We run a headless setup (frontend and CMS separated), and with subdirectories, the same application just branches by language based on the URL path — no need to multiply domains, certificates, or deployment pipelines by the number of languages. This is exactly the “low maintenance, same host” advantage Google describes.
- Separating language from country — Our English and French sites aren’t regional sites targeting a specific country — they’re content organized by language. The goal is “prospects who read French,” not “residents of France,” so a ccTLD’s strength in country targeting didn’t justify its cost.
There’s one more important practical point. We used to run our English content on a subdomain, en.growthmk.com. When we moved to subdirectories, we didn’t just leave the old subdomain sitting there — we cleaned it up with 301 permanent redirects for every path, pointing to growthmk.com/en/*. It wasn’t just a domain swap: we stripped the old URL’s category prefix (e.g. /insight/{slug}) and mapped it to the new /en/{slug} structure, redirected tag and author pages we no longer maintain up to a parent page, and set the old subdomain’s robots.txt to block all indexing (Disallow: /). The riskiest thing you can do when changing your domain structure is leave the old structure half-alive. If both the old and new URLs respond with 200, search engines see the same content living in two places, and their sense of which one is canonical starts to wobble. Picking one canonical location and consolidating the rest with 301s is the very first thing to do when restructuring.
| Structure | Regional Targeting Signal | Authority Consolidation | Operating Cost | Our Judgment |
|---|---|---|---|---|
| ccTLD (example.fr) | Strongest | Scattered per domain | High (separate domain and infrastructure) | Right when country targeting matters. Overkill for our language-based goal |
| Subdomain (fr.example.com) | Weak (hard to infer from URL) | Partially scattered via host separation | Medium | Legacy en. setup → consolidated into subdirectory, cleaned up with 301s |
| Subdirectory (example.com/fr) | Weak (supplemented by canonical and hreflang) | Fully consolidated under one domain | Low (same host) | What we chose — consolidated authority + simplicity for our headless setup |
| URL parameter (?lang=fr) | — | — | — | Not recommended by Google — ruled out |
Decision 2 — hreflang: Reciprocal Links and Group Integrity
The principle: hreflang has to be bidirectional, or it gets ignored
hreflang is the signal that tells search engines “here’s where the other language versions of this page live.” Google recognizes three equally valid ways to declare it: ① a <link rel="alternate" hreflang="..."> tag in the HTML <head>, ② an HTTP Link: header, or ③ an <xhtml:link> element in an XML sitemap. The single most important rule is the return link. Google’s documentation states it plainly: “If two pages don’t both point to each other, the tags will be ignored.” If a Korean page points to an English page, the English page has to point back to the Korean page too. Each language version needs to list every variant — including itself — and it’s a good idea to include x-default as well, for users who don’t match any specific language (Tell Google about localized versions).
Our choice: Resolving “multiple URLs for the same language” conflicts through group normalization
In theory, this is simple: just make KO, EN, and FR point to each other. In practice, we ran into something trickier — a situation where the same language ended up with multiple URLs. During migration, some articles ended up with two Korean slugs, or translation-link data was only entered on one side, leaving two Korean candidates inside what should have been a single group. When that happens, the hreflang set ends up with a duplicate language, and search engines can’t tell which Korean URL is the real match. This is a textbook case of the “67% of sites have errors” statistic mentioned above.
Our fix was to stop assembling hreflang on the fly, page by page, and instead group translation-linked articles together (group normalization) so the whole group shares a single hreflang set. Here’s how it works.
- Build groups from link relationships — Follow each article’s translation-link data and merge connected articles into one bundle. If A is a translation of B, and B is a translation of C, then A, B, and C form one group.
- Enforce one URL per language within a group — If a group ends up with two or more URLs for the same language, pick one as canonical, discard the rest, and log the conflict. The key is to “log and clean up,” not “silently ignore” — you need to be able to trace, later, why a given article’s hreflang was dropped.
- The whole group shares the same alternates set — Every page in the group shares the same finalized “language → URL” mapping, so the Korean, English, and French pages automatically point to each other, and to themselves. The reciprocity rule is enforced structurally.
- Fill x-default consistently — For users who don’t match any specific language, we default to Korean, but fall back to English for any article that has no Korean version, and locked that rule in place.
With this approach, hreflang stops being “something a person hand-tunes page by page” and becomes “an output computed once from the underlying data.” Whether you have 200 articles or 500, the same rule applies uniformly across every page, which structurally eliminates the scenario where some pages are correct and others are off. This group set carries straight through into the sitemap too. Because each sitemap URL carries the same group’s alternates alongside it, the hreflang in the page’s <head> and the hreflang in the sitemap never diverge. If the two contradict each other (head points to A, sitemap points to B), search engines get a confusing signal — but generating both from a single source of truth (the group set) means that contradiction can never arise in the first place.
Decision 3 — Content Strategy: Prioritize by Market, Don’t Translate Everything
The principle: use canonical and hreflang to sort out regional duplicate content
When you offer identical or similar content across multiple language and regional URLs, Google’s guidance is to “pick a preferred version and use rel="canonical" and hreflang so the right language and regional URL surfaces to searchers” (Managing multi-regional and multilingual sites). Some duplication is unavoidable when running a multilingual site, and the standard practice isn’t to hide or avoid it, but to designate a canonical version and tie everything together with signals. That said, pushing out mass machine translation with no human review is exactly the territory Google’s spam policy warns against (more on that in the next section).
Our choice: English as a subset of Korean, plus market-exclusive content
One of the earliest and most important content decisions we made was to not translate every Korean article into English and French one-to-one. The reason is straightforward. A large share of our Korean content is tightly bound to the Korean market’s context — the domestic search landscape, domestic regulation, the domestic media ecosystem — and has little or no search demand among English- or French-speaking readers. Translating and indexing an article with no demand doesn’t help readers, and it drags down the site’s overall “helpful content” standing.
So our English site is a subset of our Korean content. Topics that translate universally regardless of language — SEO/GEO principles, B2B marketing methodology, measurement frameworks — go out in English, while topics specific to the Korean market stay Korean-only. On top of that, we add exclusive content that only makes sense for English- and French-speaking markets. It’s a subset that also expands outward beyond the overlap.
What makes this work technically is content-language metadata. For every article, we specify in the CMS, via a meta field, “is this article’s language ko, en, or fr?” — and the frontend filters listings, archives, and the sitemap by language based on that field. We used to distinguish language with tags, but that got ambiguous fast — an article could end up mistakenly carrying two language tags — so we switched to a dedicated content-language field. That field does two jobs at once: ① filtering the UI so “the Korean listing shows only Korean articles,” and ② determining which language section an article belongs to when generating language-specific sitemaps.
As a result, our sitemap is generated dynamically per language. Korean articles live at growthmk.com/{slug}, English ones at growthmk.com/en/{slug}, and French ones at growthmk.com/fr/{slug} — each on its own path — and thanks to group normalization, each entry automatically points to its group’s other language versions via hreflang. Static pages (home, about, services) and topic-cluster pages follow the same principle, assembling a set from only the language versions that actually exist. Articles that only exist in Korean go into the sitemap alone; articles that exist in both Korean and English go in as a linked pair.
| Content Type | KO | EN | FR | Decision Criteria |
|---|---|---|---|---|
| Universal methodology (SEO/GEO/B2B principles) | Yes | Yes | Partial | Language-agnostic demand → offer multilingual |
| Korea-specific topics (domestic search, regulation) | Yes | No | No | No overseas search demand → Korean only |
| English/French-market-exclusive content | Case by case | Yes | Yes | Only relevant to that market → new production per market |
| Service/company info (static pages) | Yes | Yes | Yes | Common across every market → all three languages |
Multilingual SEO isn’t a “translation project” — it’s a “market-by-market content prioritization decision.” The standard we always emphasize — “not traffic volume, but the one customer who becomes revenue” — applies just as directly across languages. The goal of our English site isn’t to mirror the Korean article count one-for-one; it’s to precisely reach the topics that actual prospective customers in English-speaking markets are searching for.
Three Common Traps — What We Actually Hit or Avoided
Trap 1 — Indexing raw automated translation
When you’re trying to grow a multilingual site quickly, the most tempting shortcut is machine-translating every page and pushing it live. But Google’s spam policy explicitly names “automatically transforming scraped content, e.g. through synonym replacement or translation, to mass-produce pages that provide little to no value to users” as spam, and defines scaled content abuse as “content produced at scale, however it’s created, that provides little to no value to users” (Google Search spam policies). Machine translation itself isn’t banned — but it becomes risky the moment you push it out at scale without human review, editing, or market-context enrichment. That’s one of the reasons we chose not to translate everything: if an article doesn’t have the resources to be properly polished, it’s safer not to translate it at all.
Trap 2 — Missing hreflang reciprocity
This is the most common failure, and the quietest one. If your Korean page includes hreflang pointing to the English version, but the English page forgets the return link back to Korean, Google discards the entire pair. It’s more dangerous precisely because everything looks fine on screen. We eliminated this by scrapping the whole idea of “hand-adding hreflang page by page.” With a shared group set, filling in just one direction becomes structurally impossible — since every page in a group shares the same set, if A points to B, B has no choice but to point back to A.
Trap 3 — Unresolved duplicate content
When you change your domain structure (subdomain → subdirectory) or clean up your URL rules, leaving the old URL alive while adding a new one means the same content responds with 200 in two places. Search engines read that as duplication and split their indexing decision between the two. The fix is unglamorous, but non-negotiable: pick one canonical version, consolidate the rest with 301s, and where similar-but-unmergeable content exists, designate a preferred version with canonical. Cleaning up our old en. subdomain with 301s — and mapping the old English category and tag prefixes we no longer maintain right along with it — was exactly the work we did to avoid this trap.
A Multilingual SEO Audit Checklist
The table below is what we actually check. We run through the same sequence whenever we add a new language, change the structure, or do a routine audit.
| Area | Check | Passing Criteria |
|---|---|---|
| Domain structure | Is the language URL format consistent? | Every language follows the same rule (e.g. subdirectory). No parameter-based approach |
| Has the legacy structure (old domain, old paths) been cleaned up? | Old URLs are consolidated into the canonical version via 301. No two locations respond with 200 at once | |
| hreflang | Is the reciprocal link bidirectional? | KO↔EN↔FR all point to each other, and to themselves |
| Is the same language duplicated within a set? | One URL per language per group. Conflicts are logged and resolved | |
| Is x-default present? | A default (e.g. KO) is set for users who don’t match any language | |
| Sitemap | Does each language sit at the correct path? | KO=/slug, EN=/en/slug, FR=/fr/slug. No omissions or misrouted paths |
| Does the sitemap’s hreflang match the head’s hreflang? | Generated from a single source of truth → the two signals never contradict each other | |
| Content | Does each language version match market demand? | No mass-indexed machine translation of zero-demand articles. Human review applied |
| Is the language metadata accurate? | Each article has exactly one language field set. It’s the basis for listing and sitemap filtering |
Multilingual SEO isn’t about passing this checklist once — it’s about building the structure so the checklist keeps passing as new articles get added. Do it by hand, and things drift further out of alignment as the article count grows. Generate it from data as a rule instead, and consistency holds no matter how much the site grows. To build a broader search foundation, we’d recommend following up with our complete technical SEO guide and our Google SEO content optimization checklist; for the market perspective on going global, see marketing the Korean market for global companies; and for AI search readiness, see our complete guide to GEO (generative engine optimization). A multilingual site is a signal not just to search engines but to AI answer engines too, shaping “what gets shown to which language’s users” — and the more structurally sound it is, the more accurately both humans and AI cite the right language version. Ultimately, running a multilingual site well comes down to structure: getting the right content in front of the right reader — especially the one reader who becomes revenue.
We can apply the experience we’ve built running our own multilingual SEO structure to your company’s site. That includes diagnosing your domain structure, auditing hreflang integrity, and designing content priorities by market. Check out our approach on the SEO services page, and if you’d like a concrete review of your current multilingual site’s issues, reach out through our consultation contact form.
You can see the full picture of this topic in “The Complete Guide to Going Global — From Market Selection to Localization and Global SEO.”
FAQ
For a multilingual site, is a subdirectory or a subdomain better for SEO?
Google doesn’t dictate a single right answer — it lays out the trade-offs instead. A ccTLD sends the strongest regional-targeting signal but costs the most; a subdomain lets you separate servers but sends a weaker regional signal from the URL alone; a subdirectory shares a host, which makes maintenance easier and consolidates domain authority in one place. A ccTLD makes sense when country targeting is clear-cut; a subdirectory makes sense when you’re organized by language and care about consolidated authority and operational simplicity. We chose a single domain plus subdirectories (/en, /fr) for the latter reasons.
What’s the most common hreflang mistake?
Missing the return link. Google states explicitly that if two pages don’t point to each other, hreflang gets ignored entirely. Fill in only one direction, and everything looks fine on screen while the whole signal gets discarded — and Ahrefs’ research found that 67% of sites implementing hreflang had errors. Rather than adding it by hand page by page, group translation-linked articles together and have them share the same set — that makes filling in only one direction structurally impossible.
Do I need to translate every piece of content into every language?
No. Topics that only matter to one market — a specific country’s search or regulatory environment, for instance — are better left in that language alone, with only genuinely universal topics offered multilingually. Mass-indexing zero-demand articles via machine translation doesn’t help readers, and risks falling under the “large volumes of valueless content” that Google’s spam policy warns against. Our English site is structured as a subset of our Korean content, plus exclusive content built specifically for English-speaking readers.
Will search rankings drop if I switch my domain structure from a subdomain to a subdirectory?
They can, if you don’t clean up the old URLs. The key is picking one canonical version and merging the old URL into the new one with a 301 permanent redirect. If both stay live, indexing splits across duplicate content. We 301-redirected every path on our old en.growthmk.com to growthmk.com/en/*, and cleaned up the old category prefixes, mapped retired pages, and blocked indexing on the old domain’s robots.txt at the same time. Consolidating this way transfers the signal the old URL had built up over to the new one, minimizing any ranking drop.
