Internationalized Domain Names: IDNs, Punycode and SEO

Short answer: Internationalized domain names (IDNs) contain characters outside plain ASCII, such as müller.de, ąžuolas.lt or domains in Cyrillic, Greek, Arabic or Chinese script. Behind the scenes they are converted to an ASCII form called punycode, starting with xn--. Search engines index and rank IDNs like any other domain, so there is no inherent SEO penalty or bonus. The real trade-offs are practical: how the address looks when shared, how easily people type it, email support, and consistency in your technical setup. Many businesses register the IDN and the ASCII version and choose one as the main domain.

What an IDN is

For most of the internet’s history, domain names could only use the letters a–z, digits and hyphens. That excluded most of the world’s writing systems and many European letters with diacritics. Internationalized domain names remove that limit, so domains can be written in local scripts and with local characters.

Examples of the forms IDNs take:

• Latin letters with diacritics under ordinary country or generic endings, for example a German name with ü or a Lithuanian name with ą, č or ž.
• Non-Latin scripts under Latin endings, such as a Greek or Cyrillic name under .com.
• Fully local domains, where the ending itself is in the local script, such as the Cyrillic .рф for Russia or Chinese-script endings.

Whether a specific ending supports specific characters depends on the registry. Country registries typically allow the letters of their national languages.

IDNs have been available for many years, yet they remain relatively rare compared with ASCII domains, and adoption varies strongly by market. That rarity is one reason some software still handles them poorly.

How punycode works

The domain name system itself still works with ASCII. So each IDN has two forms:

• Unicode form, what people see and type: the domain with its local characters.
• Punycode form, what DNS uses: an ASCII encoding that starts with xn-- followed by letters and digits.

Browsers convert between the two automatically. When someone types the Unicode form, the browser looks up the punycode form. When the browser shows the address bar, it usually displays the Unicode form, but it may show punycode instead when it detects a risk of spoofing, for example when a domain mixes scripts that contain lookalike characters. This protection against so-called homograph attacks means that some IDNs will appear as xn--... to some visitors.

How search engines treat IDNs

Search engines handle IDNs as normal domains. The Unicode and punycode forms of a domain are the same host, and pages on an IDN can be crawled, indexed and ranked like any other. In search results, the domain is usually displayed in its readable Unicode form.

A few points about signals:

• Country endings still work as country signals. An IDN under a country code ending carries the same geographic association as an ASCII domain with that ending. The broader structure choice is covered in ccTLD vs subdomain vs subfolder.
• Keywords in the domain are a minor factor at most. An IDN that spells a search term in the local language will not rank because of that alone, just as keyword domains in ASCII do not.
• Brand matters more. A domain that matches how customers write your brand name can support recognition and clicks, which is the real benefit for many local businesses.

Practical advantages

• Correct spelling of names. A business named with local letters can use its real name instead of an approximation. For many brands this matters for identity.
• Local recognition. In markets that use non-Latin scripts, a domain in the local script can be easier to remember and read for local audiences.
• Availability. Short, meaningful IDNs are sometimes available when the ASCII equivalent is taken.
• Readable in results. In search results and local-language contexts, the readable form looks natural.

Practical drawbacks

• Typing. Visitors abroad, or with a different keyboard layout, may find special characters hard to type. Many people type the ASCII approximation out of habit.
• Sharing. When copied in some apps, email clients or older systems, the domain may appear in punycode, which looks unfamiliar and can seem suspicious.
• Email. Email addresses on IDNs are not supported everywhere. Many businesses use an ASCII domain for email even when the website runs on an IDN.
• Tool support. Some analytics, advertising, form validation and CRM tools handle IDNs inconsistently, showing punycode in reports or rejecting the address.
• Trust. Because lookalike IDNs are used in phishing, some users and security tools are cautious with unusual characters.

Choosing: IDN, ASCII or both

Whatever you choose, only one version should serve content. The other should redirect with a 301, exactly as you would handle www and non-www. The principle of one canonical host is explained in WWW, trailing slashes and case.

Technical setup checklist for IDNs

1. Get an SSL certificate that covers the domain. Certificates are issued for the punycode form; most certificate authorities and automated tools handle this, but verify that the certificate covers both the bare domain and www.
2. Configure the server with the punycode form where configuration files expect ASCII host names.
3. Use one form consistently in canonicals, hreflang and sitemaps. Both forms identify the same host, but mixing them in one site’s technical tags makes checks harder. Many teams use punycode in technical files and the Unicode form in visible text.
4. Redirect the alternative domain (the ASCII version or the IDN) to the main one with 301 redirects on every path, not only the home page.
5. Verify the domain in Search Console and other webmaster tools; domain properties generally accept the Unicode form and handle the conversion.
6. Test sharing and email. Paste the address into common messaging apps and email clients your customers use, and check how it appears.
7. Check analytics and ad platforms for how they display and accept the domain.

If you are moving an existing site to an IDN or away from one, treat it as a full domain migration with URL mapping, redirects and monitoring, as described in the website migration SEO checklist.

Common IDN mistakes

• Both versions serving the same content. The IDN and the ASCII domain each show the full site without redirects, creating duplicate hosts. Pick one and redirect the other.
• Redirecting only the home page. Old links to deep pages on the secondary domain then land on the home page or an error. Redirect every path to its equivalent.
• Certificates that cover only one form. Visitors who type the other domain see a security warning before the redirect can happen.
• Printing only the IDN on material for international customers. People abroad may not be able to type it. Show the ASCII version where your audience is international.
• Ignoring lookalike domains. Others can register IDNs that look like your brand. For well-known brands, monitoring and defensive registrations are part of brand protection.
• Forgetting internal systems. Contact forms, newsletter tools and CRMs that reject or mangle the domain can break lead capture after a switch.

Beyond the domain: local characters in URLs

The same questions come up for the path of the URL. Slugs can also contain local characters, which are percent-encoded when copied. Some sites keep the domain in ASCII but use native-script slugs; others transliterate everything. Both approaches work for search. The trade-offs are covered in should you translate URL slugs. Whatever you choose, apply it consistently across the site.

Consistency problems across hosts, redirects and hreflang are easy to miss on international sites. Site SEO AI Audit crawls the whole site and reports redirect chains, canonical problems, broken language versions and hreflang errors, weighted by how many pages each affects, so a mismatch between domain forms or a missing redirect shows up quickly. You can run a first audit free.

Related reading

• International SEO glossary: key terms explained simply
• HTTP to HTTPS migration: an SEO checklist that works
• Local trust signals for country versions of your website

The bottom line

IDNs are ordinary domains for search engines: they are indexed and ranked like any other, and country endings keep their geographic meaning. The decision is practical, not algorithmic. Weigh brand identity and local readability against typing, sharing, email and tool support. Register both forms where it matters, pick one main domain, redirect the other and use one form consistently in your technical setup.

FAQ

Are internationalized domain names bad for SEO?

No. Search engines crawl, index and rank IDNs like other domains. The trade-offs are practical, such as typing, sharing and email support, not ranking penalties.

What is punycode?

Punycode is the ASCII encoding of an internationalized domain name, starting with xn--. DNS uses it behind the scenes, while browsers usually display the readable form.

Why does my domain sometimes appear as xn--?

Some apps and systems show the punycode form, and browsers may display it when a domain mixes scripts that could be used for spoofing. It is still the same domain.

Should I register both the IDN and the ASCII version?

It is often wise, especially if your brand name contains local characters. Use one as the main domain and redirect the other to it with 301 redirects.

Can I use an IDN for email?

Support for email addresses on IDNs is still inconsistent. Many businesses keep an ASCII domain for email, even when the website uses an IDN.