You can register a domain name with Turkish letters such as ç, ğ, ı, ö, ş or ü, provided the registry for your extension accepts them. The domain system itself only carries ASCII, so the name is converted behind the scenes into Punycode and shows up on the wire as a label starting with "xn--". The registration is the easy part. What deserves your attention is how that name behaves when a customer types it on a phone, when an email server handles it, when a chat app shortens it and when a report prints it. If you run a brand, a shop or a client site with Turkish letters in its name, the decision comes down to three documents: RFC 3492 for Punycode, RFC 5891 for registration and lookup, and Google's URL structure page.
Two assumptions are worth dropping early. One is that an accented domain name gives a ranking edge. Google's URL structure page sets no rule about letters in the domain and makes no ranking promise. The other is that Punycode is a speed or security setting. It is only an encoding. The practical questions are about people and software, not about search engines.
How a Turkish letter travels from keyboard to DNS
Follow one name through the system and the vocabulary falls into place. A visitor types "çarşıelişi" into an address bar. The browser keeps the Unicode form for display, but the name that reaches DNS has to be ASCII. The Unicode form is called a U-label and the ASCII form an A-label. RFC 5891 (Opens in a new tab) states that IDNs appearing in DNS queries or responses must be A-labels, and it describes an A-label as the Punycode encoding of the U-label with the ACE prefix "xn--" added at the front.
RFC 3492 (Opens in a new tab) defines the Punycode part. It calls Punycode a way to uniquely and reversibly transform a Unicode string into an ASCII string, one in which ASCII characters are represented literally and the remaining characters become letters, digits and hyphens that are valid in host name labels. The document also limits itself: Punycode is explicitly not designed for processing arbitrary free text, so it applies to domain labels and not to URL paths.
Who defines what
RFC 3492 does not define the "xn--" prefix. It speaks of an ACE prefix and leaves its definition to the IDNA specification. RFC 5891 supplies the actual string. Keeping that split in mind helps when you read a forum thread that attributes everything to "the Punycode RFC".
Four sample labels
| What you type | What DNS sees |
|---|---|
| çarşıelişi | xn--arelii-vua80d3me |
| kasırga | xn--kasrga-r9a |
| öğretmen | xn--retmen-vxa24a |
| kilim | kilim |
The last row shows that a label without non-ASCII letters stays as it is. Treat the other rows as illustrations. The exact string to register is the one your registrar displays at checkout.
What registries are asked to check
A registry does not simply store whatever you type. RFC 5891 says a registry must accept only the exact string for which registration is requested, which means it must not silently map your input to something else. It may accept a U-label, an A-label or both, and the document recommends supplying both so that the registry can confirm they match exactly.
| Check | What RFC 5891 says | What it means for you |
|---|---|---|
| Normalization | Input must be Unicode in Normalization Form C | Type the name instead of pasting text copied from a design file |
| Hyphens | No hyphen at the start or end, and no double hyphen in the third and fourth positions | Reconsider hyphenated brand names |
| Combining marks | A label may not start with a combining mark | Hidden characters in copied text can trigger a rejection |
| Disallowed characters | Disallowed or unassigned characters are rejected | Decorative symbols and emoji do not pass |
| Length | 63 characters or fewer in ACE form | Measure long brand names in their xn-- form |
The lookup side is more permissive than the registration side. The document says so explicitly, and the consequence is simple: a name that resolves is not proof that the same name could be registered today.
Which letters a given extension accepts is a policy of that extension’s registry. The RFCs do not list it, and the answer differs by extension. Ask the registry or an accredited reseller for the current rules. If you are still choosing an extension, the .com.tr or .com decision is a separate question.
Dotted and dotless i
Turkish has two different letters where English has one. "kırtasiye" and "kirtasiye" are two different labels with different Punycode forms (xn--krtasiye-tkb versus plain "kirtasiye"). DNS does not treat one as a typo of the other. Anyone who types the second spelling on an ASCII keyboard lands on a different registration, or on nothing.
Why capital letters add a wrinkle
The registration protocol requires normalized Unicode input, but a registrar’s search box may still convert capital İ and I in its own way. Practical suggestion: search both spellings of your brand separately, and write down the A-label that the registrar displays for each.
Why the length limit matters here
Non-ASCII letters expand when encoded, so a name that looks short on screen can be longer in ACE form. Because the 63-character limit counts the "xn--" prefix too, test a sentence-like brand name at the registrar before building a logo around it.
What Google’s URL structure page says, and what it leaves out
The Search Central page on URL structure best practices (Opens in a new tab) gives a clear instruction about non-ASCII characters: percent-encode them in the href attributes of your links. Its example prefers a URL with the German word "gemüse" written as gem%C3%BCse over the raw form. The page also recommends readable words instead of long ID numbers, words in your audience’s language (transliterated where applicable), and hyphens rather than underscores between words.
For multi-regional sites, the page mentions structures that make geotargeting easy, such as a country-specific domain or a country subdirectory on a generic domain.
What the page does not do is just as useful to know. It gives no rule about the letters in a domain name, does not discuss how internationalized domain names are encoded and says nothing about rankings and Punycode. A claim such as "accented domains rank better" or "xn-- domains rank worse" finds no support in that source.
Two encodings, two places
The percent-encoding advice concerns the path after the domain. Imagine an ASCII domain with a path like "/el-isleri/çanta". The path is percent-encoded in links, while a Turkish-letter domain would be handled by Punycode. They are separate mechanisms, and mixing them up leads to wrong conclusions in both directions.
Where the name breaks in daily use
A valid name is not guaranteed to look the same everywhere. One browser may show the Unicode form while another application shows the xn-- form, and nothing in the RFCs or in Google’s page promises how a given piece of software behaves. These checks are practical suggestions, to be run before you commit.
- Share the link in a chat app, an email client and a social post. Does it stay clickable, and what text is displayed?
- Create a mailbox on the domain and send messages to recipients on several providers. Mail systems may not handle the Unicode form the same way, so look for bounces and silent drops.
- Print the name on a business card or shop sign and ask a stranger to read it back.
- Say the address aloud on a phone call and see whether the listener can spell the dotted and dotless letters.
- Record how the name appears in your analytics, ad accounts and Search Console property.
If the email test fails, you do not have to abandon the name. Keep the Turkish-letter domain for the website and run email from an ASCII domain. That setup appears as one of the options in the comparison table.
Technical records that depend on the name
Because DNS carries A-labels, every technical record ends up tied to one concrete spelling of the name. The table lists the places where mismatches cause confusion.
| Place | What to look at | Practical suggestion |
|---|---|---|
| DNS panel | The registrar may display Unicode or xn-- | Store both forms in a shared document |
| TLS certificate | The name form shown on the order screen | Order with the name form displayed, then open the site in a browser to test |
| Email authentication records | SPF, DKIM and DMARC are tied to the domain name | Confirm the expected name form in your sending provider’s help pages |
| Search Console | The name form you enter for the property | Record the form and the property type you chose |
| Ad and analytics tools | Destination URL and referral exclusion fields | Screenshot how each tool shows the name |
Each row depends on the provider, so the provider’s own documentation decides. Keep one rule: use the same name form across all tools. For the choice between a domain property and a URL-prefix property, see Search Console domain vs URL prefix.
Four setups compared
There are four workable arrangements. None of them is right for every business. The table puts strengths and weaknesses side by side so you can match them to your own customers.
| Setup | Strength | Weakness | Fits |
|---|---|---|---|
| Turkish-letter domain only | Matches the brand spelling exactly | Typing errors on ASCII keyboards, extra testing for email and apps | A local brand whose customers all use Turkish keyboards |
| ASCII domain only | Types and sends cleanly everywhere | The brand letters change, for example ı becomes i | A business with email-driven sales or foreign contacts |
| ASCII main domain, Turkish-letter twin redirecting to it | Absorbs spelling variants and keeps the brand look in print | Two annual fees and two records to manage | A shop whose signage shows the Turkish spelling |
| Turkish-letter main domain, ASCII twin redirecting to it | Brand identity first, ASCII typists still arrive | Shared links may display the xn-- form | A cultural or craft brand where the spelling is part of the identity |
The fourth row carries a risk you cannot control: how a shared link looks depends on the app that displays it. For that reason the third row is the cautious starting point.
A rule of thumb for deciding
Answer three questions in writing before you decide.
- Where do customers type or read the address: a phone keyboard, a desktop, a printed card?
- How much of the business depends on email, such as quotes, order confirmations and invoices?
- Do foreign suppliers, partners or press need to reach you?
If the second or third answer is yes, make the ASCII name the main address and register the Turkish-letter name as a twin. If all three answers are no, the Turkish-letter name can be the main address, though an ASCII twin is still a cheap form of protection. This is a practical suggestion, not a Google principle.
Example scenario: a handicraft shop in an old market street
Example scenario: a handicraft shop in a covered market sells hand-knitted and embroidered pieces online and takes custom orders through its website. The owner wants "çarşıelişi" as the domain so that the sign over the shop and the web address match.
The owner works through the three questions. Customers read the address from the sign and type it into a phone. Order confirmations go out by email. A wool supplier abroad also writes to the shop from time to time. The second and third answers are yes, so the shop chooses an ASCII main domain, registers the Turkish-letter spelling as a twin and sets up a permanent redirect from the twin to the main site. The sign keeps the Turkish spelling. Confirmation emails leave from the ASCII domain.
The follow-up list is short: internal links, the sitemap and canonical tags all point to the main domain, the twin has its own email records, and the owner checks after a few weeks that visits arriving through the twin land on the right page without errors.
Before launch the owner also types the Turkish spelling on a phone and on a laptop whose keyboard is set to English, then confirms that the twin resolves and redirects. The test takes a few minutes and exposes any gap between what the sign promises and what a visitor can actually enter. Order slips carry the ASCII main address in small type beside the Turkish spelling, so a customer who cannot type ı or ş still holds a working address.
Presenting the name to customers
Written forms on the site
Put the full address as plain text in the footer, on the contact page and in email signatures. Plain text can be copied and pasted and read by search engines. An address that exists only inside an image loses both benefits.
Phone and print
If you must say “dotted i” or “dotless ı” every time you read the address aloud, that is a sign you need an ASCII twin. On printed material, show only the main address and let the redirect catch the other spelling.
Directories and profiles
Fill in the website field of business directories, map listings and social profiles with the main address. Some software rejects Unicode domains. If you get an error, switch to the ASCII form instead of altering the name by hand.
Consistent reporting
Use one spelling of the name in every monthly report so that nobody wonders which domain is the main one.
Questions to put to the registrar
Support for Turkish letters and the behavior of the checkout screen can differ between registrars. Get written answers to these questions before ordering.
- Does my extension accept ç, ğ, ı, ö, ş and ü?
- In what form do I enter the name, and what form appears on the confirmation screen?
- Are the dotted and dotless spellings handled as separate registrations?
- Do renewal, transfer and privacy services work the same way for Unicode names?
- In what form will the name be requested when I transfer it to another registrar?
- Does your email hosting open mailboxes on Unicode domains?
Keep the answers with your domain records, since the person who handles the renewal next year may not be the person who registered the name.
Scoring two candidate names
To apply the decision rule to real candidates, give each criterion 0, 1 or 2 points. The scoring is a practical suggestion, not a method from Google.
| Criterion | 0 points | 1 point | 2 points |
|---|---|---|---|
| Typing on a phone | Turkish letters required and awkward | Turkish letters present but easy to type | Plain ASCII letters |
| Email test | Failed | Problems with some providers | Clean everywhere |
| Readability in print | Dotted and dotless letters get confused | Possible confusion | Clear |
| Foreign contacts | Frequent foreign correspondence | Occasional | None |
| Spelling twin | Owned by someone else | Free but not registered | Registered and redirecting |
The candidate with the higher total carries less usability risk. On a tie, choose the ASCII main address and register the Turkish-letter name as a twin.
Switching names later
Choosing the wrong main address is not permanent, but changing it later is a site move, with all the planning that implies. If the Turkish-letter name turns out to cause trouble in email or shared links, you can promote the ASCII twin to main address. The twin already exists, already has a redirect and may already carry some inbound links, which is why registering it at the start saves work.
Practical suggestion: write down now which direction you would move if the first choice fails. A short note such as “fallback main address: the ASCII name” prevents a rushed decision later. When the day comes, redirect in the other direction with a permanent redirect, update internal links, canonical tags and the sitemap, and keep the old redirect in place. Changing the main address and redesigning the site in the same week makes it hard to tell which change caused a traffic drop.
For a business with a physical shop, one more item belongs on the list: signage, invoices and packaging. They lag behind the website, and customers who read an old printed address should still arrive. That is the case for keeping both names registered for as long as printed material with either spelling is in circulation.
Pre-registration checklist
- I searched the dotted and dotless spelling of the brand separately.
- I noted the A-label of each spelling.
- Each label stays under 63 characters in ACE form.
- I learned the registry’s Turkish-letter policy for the extension.
- I sent a real test email to several providers.
- I tested the link in chat apps and email clients.
- I decided in writing whether to register the ASCII twin and spelling variants.
- I confirmed that the sitemap and canonical tags point to the main address.
Mistakes to avoid
Testing only the address bar
A name that opens fine in a browser can still fail in email or in a shared link. Test each environment separately.
Expecting a ranking boost
No official statement links Turkish letters in a domain to better rankings. Choose the name by how your customers write and say it.
Leaving the twin unregistered
A spelling you leave free can end up in someone else’s hands. Registering a name you do not plan to promote is a cheap safeguard.
Leaving the text inconsistent
The domain is one signal of care, but the site copy should also use Turkish letters consistently. A Turkish article editing checklist helps catch ı and i slips in the text itself.
Choosing the redirect type carelessly
If the twin is meant to be permanent, set up a permanent redirect with no extra hops. The reasoning behind brand spelling choices appears in choosing a brand name for SEO, and for the cleanup of www, https and trailing-slash variants on the main domain, see www vs non-www standardization.
Frequently Asked Questions
Can I register a domain name with Turkish letters?
Technically yes, if the registry for your extension accepts them. RFC 5891 describes the checks registries apply, but the list of accepted letters is each registry’s own policy, so ask your registrar for the current rule.
What is Punycode?
RFC 3492 defines it as a way to uniquely and reversibly turn a Unicode string into an ASCII string. In domain names it appears together with the "xn--" prefix that RFC 5891 specifies.
Does an accented domain affect Google rankings?
Google’s URL structure page sets no rule about letters in the domain and makes no ranking statement, so neither a positive nor a negative effect can be claimed from it.
Can I use Turkish letters in URL paths if my domain is ASCII?
Yes. Google recommends words in your audience’s language and percent-encoding of non-ASCII characters in links. That is a different mechanism from the Punycode used in the domain.
Could ı and i send visitors to someone else’s site?
Yes. "kırtasiye" and "kirtasiye" are two separate labels. Checking or registering the spelling that ASCII typists will use is a cheap safeguard.
Which should be my main address, the Turkish-letter or the ASCII one?
If email and foreign contacts matter, the ASCII address is the cautious choice. For printed signage, the Turkish spelling can remain. The three questions in the decision rule settle it.
How does the 63-character limit apply?
RFC 5891 asks for 63 characters or fewer in ACE form, and the count includes the "xn--" prefix. Turkish letters add characters when encoded, so measure a long name in its ASCII form before registering.
Conclusion
A Turkish-letter domain is neither a trap nor a built-in advantage. Punycode makes the name travel through DNS, the registry decides what it accepts, and Google’s URL structure page sets no rule for letters in the domain. The decision rests on use: how your customers write the name, how your email behaves, and how links look in the apps people share them in.
Practical suggestion: an ASCII main address, a Turkish-letter twin and a clean permanent redirect lower the risk for a brand. Fill in the decision table with your own answers, record your email and link tests, and only then register the name.
Once the new domain is live and you want your first quality mentions, our guest post service can help you get them.
Post a comment
Please log in to leave a comment. Login