For a Multilingual Site, Separate URLs Per Language Win at SEO

"Can't I just drop the /en, /ko from the URL?"

My blog (backtodev) serves both Korean and English. The URLs look like this.

https://backtodev.com/ko/portfolio
https://backtodev.com/en/portfolio

Every time I shared my portfolio, it nagged at me — the link changes depending on whether I'm sending it abroad or within Korea. So the thought naturally came up: "Couldn't I just have one URL (/portfolio) and automatically show Korean or English based on browser language?"

Technically, sure, possible. But looking into it, it turned out to be something you shouldn't do, from an SEO standpoint. The conclusion was "keeping separate URLs per language is the right call," and I'm writing down why. Anyone building a multilingual site hits this fork in the road eventually.

Search engines see "URL = page"

Starting with the core premise: search engines like Google index one URL as one page. The URL is both the page's address and its identity.

So what happens if a single URL (/portfolio) shows different content depending on browser language?

Same URL: https://backtodev.com/portfolio
  ├─ Opened with a Korean browser → Korean content
  └─ Opened with an English browser → English content

Google's crawler typically scrapes sites from a US IP + English environment. That means Google recognizes /portfolio as only a single English page. The Korean version becomes entirely invisible to it. No matter how good your Korean writing is, it never shows up in search.

Approach	What Google sees	Result
1 URL + browser branching	Only one language (usually English)	The other language never gets indexed
Separate URLs per language	Two distinct pages	Both languages get search exposure

And there's also cloaking risk

Showing different content per visitor from a single URL can look suspiciously like cloaking. Cloaking means "showing search engines different content than users see," which is a pattern Google actively penalizes.

Of course, language branching isn't malicious cloaking. But the structural fact that "same URL, different content per viewer" is inherently tricky for search engines to handle. There's no real reason to take on that risk.

So the answer: separate URLs per language

Google's officially recommended approach is exactly this — distinct URLs per language. And among the options, it most recommends the subdirectory approach.

https://backtodev.com/ko/portfolio   ← Korean
https://backtodev.com/en/portfolio   ← English

There are broadly three ways to split multilingual URLs, compared here.

Approach	Example	Assessment
subdirectory	`backtodev.com/en/...`	✅ Google's recommendation, easy to manage
subdomain	`en.backtodev.com/...`	Possible, but more complex to configure
country ccTLD	`backtodev.kr`, `backtodev.com`	High cost and management burden

For a personal blog or small site, subdirectory (/en/) is effectively the answer. One domain covers everything, and the language is clearly visible in the path, making it easy for search engines to distinguish.

next-intl does this by default

next-intl, commonly used to add multilingual support in Next.js, defaults to path-based routing. In other words, it's designed from the ground up around a subdirectory structure like /en/, /ko/.

// i18n/routing.ts
import { defineRouting } from "next-intl/routing";

export const routing = defineRouting({
  locales: ["en", "ko"],
  defaultLocale: "ko",
});

The folder structure naturally follows suit as app/[locale]/....

app/
  └─ [locale]/          ← en / ko live here
       ├─ portfolio/page.tsx
       └─ posts/[slug]/page.tsx

Just following the library's defaults, with no extra tricks, gives you SEO-friendly per-language URLs. There's no need to fight against it by forcing everything into one URL.

Tying the two pages together as "siblings" — hreflang & canonical

Once you've split URLs by language, it's good practice to tell search engines "these two are different-language versions of the same content." That way Google shows the right version in search results based on the user's language. This is what the hreflang tag is for.

<!-- <head> of the /ko/portfolio page -->
<link rel="alternate" hreflang="ko" href="https://backtodev.com/ko/portfolio" />
<link rel="alternate" hreflang="en" href="https://backtodev.com/en/portfolio" />
<link rel="alternate" hreflang="x-default" href="https://backtodev.com/ko/portfolio" />

hreflang="ko", hreflang="en": tells Google where each language version lives
hreflang="x-default": the fallback version shown to users who don't match either

On top of this, keep each page's canonical (the authoritative URL) pointing at itself. This prevents "the Korean and English pages are similar in content" from getting flagged as duplicate content.

<!-- /ko/portfolio's canonical points at itself -->
<link rel="canonical" href="https://backtodev.com/ko/portfolio" />

So how do you solve the sharing hassle?

Back to the original problem: "it's annoying to have to decide the language ahead of time when sharing." This can be solved without breaking the URL structure at all.

Share a prefix-less link → middleware detects the visitor's browser language and auto-redirects to /ko/ or /en/
In other words, keep the SEO-friendly unique URLs intact, and just route to the right language only at the moment a person clicks

SEO (keeping unique URLs) and user convenience (automatic language selection) aren't actually in conflict — split the responsibilities, and you get both. Indexing goes through per-language URLs; the entry experience goes through redirection.

Summary

The core of multilingual URL design, boiled down:

Merging into one URL and swapping content by browser → don't do this (only one language gets indexed + cloaking risk)
Keep distinct URLs per language → Google indexes both languages separately
Prefer the subdirectory form (/en/, /ko/) — next-intl's default
Tie language versions together with hreflang, prevent duplication with canonical
Handle sharing convenience separately, via automatic redirection

At first, having /en, /ko cluttering the URL felt like something I wanted to remove. But it turned out to be exactly the mechanism that lets search engines read both languages at all. Showing up in search matters far more to a blog than tidiness, so I decided to keep the per-language URLs as they are.