Are IDN Domains Bad for SEO? Special Characters and Punycode

Is an IDN domain bad for SEO?

An IDN domain is a domain name that contains characters outside plain ASCII, such as the umlauts ä, ö and ü or the accented letters in café. Google's official documentation says IDNs are fine to use. However, email, sharing and typing problems mean you should also own an ASCII version and pick one main address.

So this article covers only that question. We will not repeat general domain advice here, so for naming basics read our guide to choosing a domain name.

Our team hears this question most often from businesses whose brand name contains an umlaut, a cedilla or another special letter. They want the domain to match the brand exactly, and they worry that Google will punish them. First, part of the answer is clear in official sources. Second, part of it is not, and we mark that difference below.

Note: every sample domain in this article is fictional and makes no claim about availability.

What is an IDN, and which special characters does it cover?

IDN stands for internationalized domain name. According to ICANN, IDNs let people around the world use domain names in local languages and scripts. For example, that covers Arabic, Chinese, Cyrillic and many others. It also covers Latin letters with marks, such as ä, ö, ü, é, ñ, ç and the Turkish letters ğ, ı and ş.

ICANN describes two forms of every IDN label. First, the Unicode form is what a user expects to see, and ICANN calls it a U-label. Second, the ASCII form is what the DNS stores, and ICANN calls it an A-label. You can read the details on the ICANN IDN page.

So every IDN has two faces:

• The readable face in the address bar, the ad copy and the printed brochure.
• The ASCII face that starts with xn-- and travels through DNS records and server settings.

In short, most practical problems come from the gap between these two faces.

What is punycode, and how do you read an xn-- address?

Punycode is an encoding that turns a Unicode domain label into a string of ASCII letters, digits and hyphens. Then the converted label gets the prefix xn-- in front. Also, ICANN's own example shows the same pattern.

A few fictional examples show the logic:

• The label bäckerei becomes xn--bckerei-5wa.
• Likewise, the label müller becomes xn--mller-kva.
• The label café becomes xn--caf-dma.
• The label köln becomes xn--kln-sna.

As you can see, the converter removes the special letters first. Then it appends them with position data. Therefore, you cannot read an xn-- string by eye. Use your registrar's tool or a trusted IDN converter instead.

However, one point matters a lot. Punycode applies only to the domain part of a URL. The path after the domain, then, uses a different method called percent encoding. We explain that difference in its own section below.

Can Google handle an IDN domain?

Yes, and the documentation says so directly. Google Search Central's page on multi-regional and multilingual sites states that it is fine to use localized words in the URL or to use an IDN. The same page also recommends UTF-8 encoding in URLs and proper escaping when you link to them. Source: Google Search Central, managing multi-regional and multilingual sites.

However, that sentence does not promise two things. First, it does not say that IDNs are neutral for rankings. Second, it does not say that every other system will cope as easily. Also, email providers, social networks and analytics tools all have their own behavior.

In short, Google's side is clear. So you can crawl, index and serve an IDN site. The risks sit mostly outside Google, so the next sections look at those links in the chain.

Do IDN domains change your rankings?

We could not find an explicit statement in the official Google documentation that an IDN helps or hurts rankings. For that reason we do not write sentences like "IDNs lower your rankings" or "IDNs boost them". Claims like these, then, usually come from personal experience, not from a published rule.

Why care at all, then? Because SEO is more than a ranking signal. People must remember, type, share and click your address. Therefore, an IDN can make some of those steps harder.

Also, the domain name alone is not a ranking trump card. We cover related myths in separate articles: does domain age affect SEO and do exact match domains still work. Therefore, we will not repeat them here.

When you decide, ask "what will users and systems do?" next to "what will Google do?".

How does an IDN domain look in the browser address bar?

Browsers show an IDN as Unicode in some cases and as punycode in others. The Chromium project's documentation explains that Chrome shows Unicode when it judges the name safe. However, when it sees a risk, it falls back to the xn-- form. Source: Chromium IDN documentation.

The main rules in that document are easy to summarize:

• Latin, Cyrillic and Greek letters cannot mix inside one label.
• Names built with lookalike characters show as punycode unless the extension fits that script.
• Names that closely resemble well-known domains show as punycode to protect users.
• The browser's language settings do not change the decision.

So a plain name made of Latin letters and a few umlauts is unlikely to trigger these rules. Still, each browser applies its own policy. We suggest opening your address in the browsers your audience uses and checking it by eye.

What goes wrong when you share or copy an IDN address?

Paste results, however, differ by app. For example, in some places the readable name stays. In others you see a long string that starts with xn--. This behavior is not identical everywhere, so test it in the channels you actually use.

We usually run these checks:

1. Paste the address into a messaging app and see whether the link stays clickable.
2. Add the same address to a social post and see whether the preview opens.
3. Type the address into an email body and ask the recipient how it looks.
4. Print the address on a business card and see whether readers type it correctly.

Also note that the display URL in an ad can differ from the landing page address. However, that is not necessarily an error. Still, check ad approval and appearance separately.

To check a link preview, use our Google SERP preview tool for the search result side.

Can an IDN domain cause email problems?

It can, so email is the area to test most carefully. If your domain contains an umlaut, every sending and receiving system must accept an address such as info@bäckerei.example. However, we found no official guarantee that all systems do. In practice, support depends on your provider and on the recipient's system.

ICANN's Universal Acceptance initiative targets exactly this compatibility gap. Its goal is that systems treat all domain name formats consistently. However, the existence of the initiative does not mean that every tool you use is ready.

The safe route is usually this:

• Use an ASCII domain for your official business email.
• Keep the IDN for the website and brand display only.
• If you do want email on the IDN, send test messages to several providers and record the results.

For infrastructure details, read our business email guide. Never send test messages to real customers. Send them between your own accounts.

How do you register an IDN, for example under .tr?

Each registry sets its own rules, so the official registry page is the source of truth. For the Turkish .tr space, the TRABIS knowledge base says that individuals and legal entities can register domain names that contain the Turkish characters ğ, ı, ü, ş, ö and ç. Source: TRABIS knowledge base. For other extensions, such as .de, read the registry's own official page, because we did not verify those rules for this article.

In general, the process looks like this:

1. Check whether both the special and the plain version are available.
2. Confirm availability and documentation rules for the extension with your accredited registrar and the registry.
3. Make sure the registration form accepts special letters and shows the punycode result.
4. After registration, check that WHOIS and DNS output show the name correctly.

Some .tr names are restricted; see our article on takil and takal restrictions. Fees and rules change, so check current values at the official source.

Use our WHOIS lookup and DNS lookup after registration.

Should you register both the special and the plain version?

In most cases, yes. First, people do not always type with the right keyboard. A visitor who types baeckerei or backerei instead of bäckerei lands somewhere else. If you own the plain version, you keep that traffic.

Brand protection is a second reason. A competitor or a bad actor could register the plain version and build a lookalike site. So owning both closes that gap.

You pay only a renewal fee for the extra name, and you should check the current value with your registrar. However, you also take on more admin work, because you must track two renewal dates. So keep both names with the same registrar, with renewal dates close together.

The table compares the two options side by side:

Which version should be the main address, and how do you redirect?

If you own both, pick one main address and bind the other to it with a permanent redirect. For most business sites we recommend the plain ASCII version as the main address, because email and sharing are safer. If the brand's appearance is critical, the special version can be the main address. In other words, consistency matters more than the choice itself.

Apply it in this order:

1. Decide on the main address and write it down.
2. Send every path of the other name to the same path on the main address with a permanent 301 redirect.
3. Point each page's canonical address to itself on the main address. See our canonical tag guide.
4. Use only the main address in your sitemap and internal links.
5. Test the redirect with the redirect checker.

However, a temporary redirect does not fit this job. Our article on 301, 302, 307 and 308 redirects explains why. For how long to keep it, read how long 301 redirects should stay.

How do you set up SSL and DNS for two names?

The step teams skip most often is HTTPS on both names. A visitor who opens the redirecting name still connects to it first. If the certificate does not cover that name, the visitor sees a security warning before any redirect.

Check these points:

• Confirm that the certificate covers both the special and the plain name.
• Enter DNS records in the form your registrar requires, using the ASCII punycode form if needed.
• Make sure both names resolve to the same server or the same redirect rule.
• Do not forget the www and non-www forms.

You can see certificate status with our SSL checker. Also, some control panels do not accept special letters. When that happens, enter the ASCII form, which ICANN calls the A-label.

For example, panel details differ between hosting providers. So we also suggest reading your provider's help page on IDN setup.

Is a special character in the domain the same as one in the URL path?

No, these are two separate mechanisms, and people confuse them often. The domain part travels as punycode. The path part travels as percent encoding. Google's URL structure documentation says non-ASCII characters in links should be percent encoded. It uses the German word gemüse as an example, written as gem%C3%BCse. Source: Google Search Central, URL structure.

The table sums up the difference:

So using a special character in the domain does not force you to use one in the path. The reverse is also true.

Should you use special characters in URL paths?

However, you do not have to. Because Google accepts localized words in the URL, a path with umlauts works technically. Still, we prefer simple ASCII paths on most sites. Writing ue for ü and ss for ß stops shared links from turning into long percent codes.

Ask yourself these questions:

• Does your site already use special characters in paths, and would changing them create a big redirect workload?
• Can your team apply the same rule on every new page?
• Do percent codes cause trouble in the links people share?

Above all, consistency is the key rule. If you publish both a simplified and a special version for one page, you risk duplicate content and split signals. For slug writing, read our URL slug rules and use the slug generator.

If you change existing paths, set up a one step 301 redirect from each old address to the new one.

What should you check when moving an existing site to an IDN domain?

First, a move is the riskiest moment in any domain change. Our team writes the checklist before the move and ticks each step in order. Here is a conceptual version; adapt it to your own site structure.

1. Build a page by page map of old and new addresses.
2. Set up permanent redirects from every old address to its new counterpart.
3. Update internal links, canonical addresses and the sitemap to the new address.
4. Renew the HTTPS certificate so it covers the new name.
5. Add and verify the new address in your search console.
6. Watch crawl errors and redirect chains after the move.

You can also read Google's official guidance on site moves. Because menu names and button labels change, find the relevant section in the tool and follow the guidance step by step. How long a move takes differs from site to site, so we give no fixed duration.

If you want help with a move plan, see our SEO consulting service.

Does an IDN make sense for multilingual or international sites?

Still, if your target is one country with one language, an IDN is a real option. However, if you target several countries and languages, the picture changes. Google's multi-regional documentation says that country code domains give a strong signal for a specific country. Also, that signal and the IDN choice are separate topics.

For example, visitors from abroad may not own a keyboard with your special letters. For them, typing an IDN is hard. In that case a plain ASCII name is safer for accessibility and sharing.

Relate your language versions to each other with proper tags, not with the domain name. For that, read our hreflang guide and our multilingual SEO guide.

Note: the same Google document advises against redirecting users automatically to another language version based on a guess about their language. It recommends links to the other versions instead.

When should you avoid an IDN domain?

However, an IDN is not bad in every case, but some situations carry risk. If several of the signs below fit you, make the ASCII name your main address.

• Email sits at the center of your business, and customers write to you at your domain.
• Your audience uses foreign keyboards or in-app browsers.
• You print the address often on ads, cards and brochures.
• Nobody on your team can manage domains and DNS.

On the other hand, an IDN can make sense when the brand loses its meaning without the special letters. It can also fit a local campaign site for a regional audience. Even then, we suggest holding the plain version as an extra name and redirecting it.

In short, the safe default is a plain main address plus a special redirecting name. Still, decide based on your own conditions.

Does an IDN domain carry impersonation or security risk?

IDNs have their own security angle: lookalike letters can power fake addresses. For that reason the Chromium documentation describes lookalike checks in the browser. If a name closely resembles a popular domain, the browser shows it in xn-- form.

In practice, this has two consequences for you. First, if your brand name looks like a well-known address, visitors may see a warning or raw punycode. Second, someone with bad intent could register a lookalike of your name and mislead your visitors.

The precautions are simple:

• Register the plain version and close variants of your brand name yourself where possible.
• Search regularly for new registrations that resemble your name.
• Write your official address the same way on every channel.
• Keep the address format fixed in signatures, invoices and business cards.

As a result, this protects your visibility and your users' trust. This section is not legal advice; for brand disputes, talk to a trademark attorney.

Which tests confirm that your IDN setup works?

However, "It opens" is not enough. Problems rarely show on the first look: redirect chains, certificate gaps and wrong canonical addresses show up weeks later. So run the tests below once after setup.

1. Open the special name, the plain name, and the www and non-www forms one by one.
2. Confirm that each ends at the main address in a single redirect step.
3. Check that the status code is a permanent redirect.
4. See that the HTTPS certificate is valid on every form.
5. Verify that the canonical address in the page source points to the main address.
6. Verify that the sitemap contains only one address format.

The redirect checker, the SSL checker and the XML sitemap generator help here. If a chain appears, read what a redirect chain is and how to fix it.

It is also a good habit to repeat the tests for a few weeks after the move.

Example scenario: which path does a fictional bakery choose?

The scenario below is fictional and exists only to show the logic. A bakery uses the brand spelling bäckerei and wants the umlaut in its domain. The plain spelling baeckerei keeps its meaning but loses some of the brand's look.

In such a case our team would suggest this order:

1. Register both versions.
2. Run business email on the plain ASCII domain.
3. Use the special name for ads and signage to protect the brand look.
4. Publish the site on one main address and bind the other name to it with a permanent redirect.
5. Define both names in your measurement tools and watch traffic after the redirect.

Whichever name is the main address, the visitor gets the same result. In other words, a user who types either spelling lands on the same page. Moreover, the email side stays safe.

Still, this is not a template to copy. Instead, it is a way of thinking. In your own business, the email share, the audience and the amount of print material can change the math.

Which mistakes do people make with IDN domains most often?

Most mistakes we see come from assumptions, not from missing knowledge. The list below covers the common ones.

• "Google cannot read IDNs." The official page says using an IDN is fine.
• "An IDN raises rankings automatically." We found no such statement in official sources.
• "If the domain has special letters, the path needs them too." The two layers are independent.
• "Buying the second name and leaving it empty is enough." An empty name without a redirect gives visitors an error page.
• "A certificate is a one time job." You re-check coverage for every new name and subdomain.

Moreover, each of these can turn into a silent loss on your site. For example, an extra name without a redirect can turn away mistyping visitors for months without anyone noticing. So treat every extra name as part of the setup.

How do you manage address formats in search console and analytics?

Next, set up measurement to match the main address you chose. Otherwise the data of one site spreads over two places, and you cannot tell which version you are tracking. Menu names can change, so we give no exact button names here. Find the relevant section in the tool and follow the official help page.

The general approach looks like this:

1. Add the main address as a property in your search console and verify ownership.
2. Add the redirecting name too, so you can watch how the redirect behaves.
3. Submit the sitemap only under the main address.
4. Set the domain filter in your analytics to the main address.
5. Use one address format in campaign links; the UTM builder helps with tagging.

If your reports show one page under two address formats, that usually points to a missing canonical address or redirect. In that case check the redirect first, then the canonical address.

What is the right approach to an IDN domain in short?

In short, Google accepts IDN use, but we found no explicit statement about ranking effects in the official documentation. Meanwhile, the problems appear mostly in email, sharing and typing. So the most solid route is to register both versions, make one the main address and bind the other with a permanent redirect.

Remember that punycode in the domain and percent encoding in the path are different topics. Therefore, your domain decision does not set your path decision.

For more, return to our general guide to choosing a domain name and to our article on restricted .tr names.

Note: this article gives general information. Registration terms and platform settings can change, so check the current state at the official sources.