Punycode (xn--) Domains and SEO: What Google Says

A Punycode domain is not an SEO problem in itself. Google's guide to managing multi-regional sites says it is fine to use localized words in the URL or an Internationalized Domain Name (IDN), and the xn-- Punycode form is simply how that same name is written for DNS. What needs care is consistency between the two spellings, and whether users recognize and trust the name they see.

This guide explains how the Unicode and xn-- forms relate, where each one appears, and a checklist for keeping an IDN site clean for crawlers.

Unicode name vs xn-- name

DNS only handles ASCII letters, digits and hyphens. To allow names such as münchen.de or пример.рф, the IDNA standards define two forms of each label:

• U-label: the Unicode form people read, for example münchen.
• A-label: the ASCII-compatible form, which always starts with xn--, for example xn--mnchen-3ya. RFC 5890 defines xn-- as the prefix that appears at the beginning of every A-label.

The conversion between the two is Punycode, defined in RFC 3492 as a way to uniquely and reversibly turn a Unicode string into an ASCII string. It works label by label: in münchen.de, only münchen changes.

You can check any name with the Punycode converter.

Where each form shows up

• DNS, hosting panels and SSL certificates usually work with the xn-- form.
• Browsers convert a Unicode host to its xn-- form before connecting. Whether the address bar then shows the Unicode name or the xn-- name depends on each browser's own display and anti-spoofing rules, so the same link can look different to different visitors.
• HTML links may use either form. A URL parser treats https://café.fr/menu as https://xn--caf-dma.fr/menu, so both point to the same address.
• Server logs, analytics filters and some email or chat apps may show the xn-- form, which can look like a different site to people who do not know the conversion.

What Google documents

Google's documentation is short on IDNs, and it is worth quoting only what it says:

• The multi-regional sites guide says it is fine to use localized words in the URL or an IDN, recommends using UTF-8 encoding in the URL, and reminds you to escape URLs properly when linking to them.
• The URL structure guide asks for reserved and non-ASCII characters in URLs to be percent-encoded. Its examples show https://example.com/gem%C3%BCse as the recommended form of a path containing ü.

Note the split: Punycode is for the host, percent-encoding is for the path. https://münchen.de/straße becomes https://xn--mnchen-3ya.de/stra%C3%9Fe. Mixing them up, for example percent-encoding the host, produces invalid URLs.

Google does not document a ranking advantage for keywords in an IDN, so do not choose one for that reason. Choose it because it is the name your audience types and remembers.

An SEO checklist for IDN sites

1. Pick one canonical spelling of the host and use it in rel="canonical", hreflang annotations, XML sitemaps and redirects. The xn-- form is ASCII and survives any file encoding, which makes it a safe choice for machine-read files.
2. Keep internal links consistent. Mixing münchen.de and xn--mnchen-3ya.de in links is not a duplicate-content problem in itself, because both resolve to the same host, but one spelling makes audits and log analysis simpler.
3. Encode paths as UTF-8. Non-ASCII paths should be percent-encoded exactly once. See double URL encoding (%2520) for what happens when they are encoded twice.
4. Redirect related ASCII domains. If you also own an ASCII spelling, such as buecher.example next to bücher.example, choose one primary domain and redirect the other with 301s so links and signals point to one site.
5. Verify every form in your tools. Analytics filters, firewall rules and CDN settings may expect the xn-- form. A filter written with the Unicode name may silently match nothing.
6. Check which URLs are indexed. After a migration to or from an IDN, use URL Inspection in Search Console or an index checker on a sample of URLs to confirm the expected host and path form is the one that is indexed.

How to find the xn-- form of your domain

1. Paste the Unicode name into the Punycode converter. It returns the A-label for each part, for example xn--mnchen-3ya.de for münchen.de.
2. In a browser console, new URL("https://münchen.de").hostname returns the same xn-- host, because it uses the browser's own conversion.
3. Note that uppercase letters are mapped before conversion: MÜNCHEN.DE also becomes xn--mnchen-3ya.de.
4. Watch for characters that older software converts differently. Current browsers keep ß in faß.de (xn--fa-hia.de), while older IDNA 2003 tools map it to fass.de, a different domain.
5. Record both forms in your documentation, analytics filters and monitoring, so a search for either one finds the site.

Trust and spoofing risks

IDNs allow look-alike characters from other scripts. The Cyrillic letter а (U+0430) looks like the Latin a (U+0061), so аpple.com written with a Cyrillic first letter is a different domain: its A-label is xn--pple-43d.com. Browsers have defenses against such names, and that is one reason some of them fall back to showing the xn-- form.

For your own site this has two consequences:

• Avoid mixing scripts in one label. A name entirely in one script is easier for users and browsers to trust.
• Expect some visitors to see xn--. Put the readable brand name in your page titles, logo and copy, so a visitor who sees an xn-- address still recognizes the site.

Length and character limits

RFC 5890 repeats the DNS rule that a label may be at most 63 octets, and the xn-- prefix counts toward it, so the Punycode part of a label can be at most 59 characters. A label with many non-ASCII characters grows quickly when encoded: 日本語 (3 characters) becomes xn--wgv71a119e (14 characters). Long IDN labels can hit the limit sooner than you expect.

Bottom line

An IDN is a normal domain with two spellings. Google says IDNs are fine; the work is in using one spelling consistently, encoding paths correctly and making the brand recognizable to users whose software shows xn--. For the path side of the story, read %20 vs + in URLs and HTML entities vs URL encoding; for campaign links on an IDN site, see UTM parameter encoding mistakes. All string operations, including URL encoding, are on the universal encoder decoder.