The domain you are reading this on has a letter in it that does not exist in the alphabet the internet actually runs on. I bought it anyway. Buying it took minutes; understanding what I had bought took considerably longer, and the bill for that misunderstanding is still arriving in small instalments.
Almost every guide to buying a domain covers the same four things: pick something short, prefer .com, check the trademark, turn on auto-renew. All fine. None of them warned me about the thing that has actually cost me time, so that is what this post is about — one specific purchase, what it did to every tool I use afterwards, and the fifteen minutes of checking that would have caught it.
The name I bought, and the string the internet uses instead
The name has an ñ in it. DNS does not speak Unicode, so a domain containing a character outside the ASCII range is stored and transmitted in an encoded form called punycode: a prefix of xn-- followed by a mangled version of the word. My browser shows me the pretty spelling with the accent. Practically every other tool I touch shows me the other one.
You can see what any name turns into before you buy it, in one line:
# Python 3, no installation beyond Python itself
python -c "print('yourname.com'.encode('idna').decode())"
# or ask curl what hostname it is really resolving
curl -v https://yourname.com/ 2>&1 | head -3Run that on an accented name and you get back something that looks like a corrupted file transfer. That string is not a bug and it is not temporary. It is the real name of your website, and it is the one that will appear in the places where a machine writes your domain down for a human to read.
Where the second spelling turned up
In rough order of how much each one annoyed me:
- Search Console. The property is the encoded host. URL inspection expects the encoded host. The sitemap has to be submitted as a complete URL on the encoded host. Paste the pretty version into any of those fields and you are working on a property that is either empty or a different thing entirely. The screens I use, and the ownership check I now run on every property, are in the guide to the parts of Search Console that actually matter.
- Everything machine-readable on the site itself. Canonical tags, sitemap entries, internal links, redirect destinations, the certificate. Two legitimate spellings of one hostname means every one of those files can disagree with the others while looking perfectly valid. I had to settle on a rule — encoded form everywhere a machine reads it, accented form only in prose and the logo — and the full account of untangling that is in the post on retiring an old site on the same domain.
- Email addresses. An address on an accented domain depends on the sender’s mail client handling internationalised addressing properly. Some do. I have not tested enough of them to tell you which, and that uncertainty is itself the problem: a contact address is not a place to find out. I checked the mail records on all five domains I own and wrote up what I found in the post on email on my own domain and what broke, and the encoded host was the least of the problems there.
- Anywhere a platform prints the raw hostname to a stranger. Link previews, referrer displays, account verification screens, analytics reports, invoices. A domain beginning
xn--in a list of otherwise normal domains looks, to a person who has never seen punycode, exactly like something dodgy. There is a reason browser vendors treat mixed-script names as a phishing signal; the cost of that caution lands on legitimate holders too. - Me, typing it. Every time I write the domain in a terminal, a config file or a support form, I have to decide which spelling that particular field wants. It is a small tax, charged many times.
What did not break
Being fair about this matters, because the internet’s usual advice is “never use an IDN”, and the actual experience is narrower than that.
The certificate was a non-event. This domain carries a free Let’s Encrypt certificate issued to the encoded hostname, valid until 6 December 2026 on the day I checked it, renewing without me touching anything. No premium was charged for the accent, nothing failed validation, no browser has ever warned about it. The registration itself was ordinary. The hosting panel accepted the name without comment. Browsers display the pretty spelling and always have.
So the accent did not cost me anything structural. It cost me a permanent second spelling to keep track of, and about a dozen small corrections in places where I had written the wrong one. If your audience speaks a language with accents and expects to see them, that trade may well be worth making. Mine does not, which brings me to the part I got more wrong.
The accent was not the real mistake
This blog is written in English for readers in the United States and the United Kingdom. Its domain is a Spanish phrase. The brand on the masthead is a third thing again, in English.
Nobody in my audience can type the domain from memory. Not because punycode is difficult, but because the ñ is not on their keyboard and the words are not in their language. Type-in traffic, word of mouth, someone reading the address off a screen to a colleague — all of that is dead on arrival, and no amount of technical tidiness brings it back. A domain has exactly one job outside of search results, which is to survive the journey from one human’s mouth to another human’s address bar, and mine cannot do it for the people I am writing for.
That is the part no buying guide put in front of me, because buying guides are written about names in the abstract. The test is not “is this a good domain”. The test is: can the specific person I want reading this site hear the name once, in their own language, on their own keyboard, and get here? Ask it that way and half of the clever names fail.
The fifteen minutes I should have spent before paying
None of this needed hindsight. Every one of these checks is available before the card comes out.
- Say it out loud to someone from the audience you are targeting, and watch them try to write it down. If they ask you to spell it, you have your answer.
- Type it on the keyboard layout your reader uses. Accents, hyphens and easily-confused letters all fail this test in different ways.
- Run the punycode conversion from the command above and look at what comes back. If you would not be comfortable seeing that string in an invoice or a link preview, choose differently.
- Check the language match. The domain, the content and the brand should be in the same language. Two out of three is a permanent explanation you will be giving to readers and to yourself.
- Search the exact string and check the national trademark register for the market you sell into — the USPTO search for the US, the EUIPO for the EU. Registering first does not beat a prior trademark.
- Read the renewal line in the cart, not the headline price, and check whether the extension you picked carries a premium renewal. Where that number hides in the panels I use is covered in the post on my three registrars and where their renewal prices hide.
- Decide where DNS will live before you need it, because the answer affects which registrar makes sense. That decision is its own job, described in the post on pointing a domain at your host without downtime.
Two more that are less about the name and more about not losing it: put the registrar account’s recovery email on a different domain, and set auto-renew against a card that will still be valid in a year. Both sound obvious. Both fail silently, and the notification telling you they have failed goes to the address that no longer works.
What I am doing about it, which is less than you would expect
The obvious move is to register an ASCII spelling of the same brand and redirect one to the other. I have not, and I want to be straight about the reasoning instead of presenting a tidy resolution.
Buying the second name is the easy part. Deciding which of the two is the canonical home is the hard part, because that decision is a migration: every canonical tag, every internal link, every redirect rule, the Search Console property, the certificate and the mail records all have to move together, and the old host has to keep answering correctly for years afterwards. I have just finished doing a version of that job on this domain and I am not volunteering for another one this quarter. Meanwhile the current name works — it resolves, it is secure, it is indexed, and the one thing it cannot do is travel by word of mouth to an English-speaking reader.
So the honest summary is that I am living with a decision I would not make again, and the reason it persists is the same reason most bad domain decisions persist: the cost is spread thinly over years, and fixing it is concentrated into one unpleasant week.
Which is exactly why the fifteen minutes before payment are worth more than any amount of cleverness afterwards. A domain is the one component of a website you cannot refactor, swap out on a quiet Tuesday or restore from a backup. Everything else on this domain — theme, platform, the entire content — I have changed at least once. The name is the only thing I am stuck with.