International URLs: Transliteration, Unicode Slugs, and Global SEO

· 2 min read

Publish in one language and slugs are a solved problem. Publish in Russian, Arabic, Japanese, or even accented French, and every title forces a decision: keep the native script in the URL, or transliterate to ASCII?

What actually happens to Unicode in a URL

URLs transmit only ASCII. A native-script path like /статьи/кофе doesn't travel as those characters — it travels percent-encoded, UTF-8 byte by byte:

/статьи/кофе
/%D1%81%D1%82%D0%B0%D1%82%D1%8C%D0%B8/%D0%BA%D0%BE%D1%84%D0%B5

Modern browsers display the readable form in the address bar, which hides the problem. The encoded form is what surfaces everywhere else — server logs, analytics reports, plain-text emails, some chat apps, markdown documents, curl commands. A 12-character Cyrillic slug becomes 60+ characters of hex noise the moment it leaves the browser. The same applies in miniature to Western European accents: café → caf%C3%A9.

Does Google handle Unicode URLs?

Yes — Google has crawled, indexed, and ranked percent-encoded UTF-8 URLs for many years, and a native-script slug can even serve as a relevance signal for native-script queries. The SEO question is not "can it rank" but "what happens around the ranking":

  • Sharing degrades. Copied links unfurl differently per app; some paste readable text, some paste %D0%BA.... Ugly links get shared less, and shares are upstream of links.
  • Mixed-script tooling breaks. Plenty of CMS plugins, log analyzers, and older enterprise systems still mangle non-ASCII paths — invisible until the one system in your chain that does.
  • Length budgets shrink. With every character costing up to 9 encoded bytes, URL length limits arrive fast.

A decision framework

Audience is global or mixed → transliterate. English-adjacent and international products should ship ASCII slugs. moscow-coffee-guide works for every reader, every tool, every context.

Audience is single-market, native-script → either works; be consistent. A Japanese site for Japanese readers loses little with native paths — users read them fine and Google ranks them. But once chosen, the convention is permanent: mixing /ブログ/ and /blog/ across one site is the worst of both.

Accented Latin (French, German, Spanish, …) → fold the accents. This one isn't close. creme-brulee costs a French reader nothing and eliminates the encoding tax entirely. Fold é→e, ü→ue or u, ß→ss and move on.

Transliteration is language work, not character work

Naive accent-stripping fails beyond Western Europe. Real transliteration needs per-script rules — Cyrillic ж→zh, щ→shch; Greek θ→th; Arabic letters to their Latin conventions — and some scripts can't be transliterated without a dictionary at all (Kanji readings depend on the word). The slug generator applies proper per-script maps for Cyrillic, Greek, Arabic, and the full Latin accent range: type Café São Paulo — обзор and watch it become cafe-sao-paulo-obzor.

Domains have their own version of this

Internationalized domain names (münchen.de) encode differently — as Punycode (xn--mnchen-3ya.de) rather than percent-encoding — with a parallel trade-off: native readability against the fact that browsers display Punycode for many mixed-script domains to block homograph phishing. The slug advice generalizes: native scripts where your audience is uniform, ASCII where anything crosses a border.