Never Buy A .online Domain

Source: Hacker News

Introduction

I’ve been a .com purist for over two decades of building. Once, I broke that rule and bought a .online TLD for a small project. This is the story of how it went up in flames.

Namecheap’s Alluring Offer

Earlier this year, Namecheap ran a promo that let you choose one free .online or .site per account. I was working on a small product—a tiny browser—and thought, “why not?” After a $0.20 charge to cover ICANN fees, I hooked the domain up to Cloudflare and GitHub and thought I was up and running.

The Disappearing Act

Weeks later, while checking traffic data for an unrelated domain, I saw zero visitors in the last 48 hours. Loading the site showed the dreaded full‑page “This is an unsafe site” warning. The site only contained a link to the App Store, some screenshots, and a few lines of text about the app—nothing that should trigger a block.

Clicking through the warnings to inspect the site resulted in a “site not found” error.

Initial Recon

I verified that Cloudflare was still active and that the CF Worker pointed to the domain, then turned to the registrar. Namecheap displayed the domain correctly with the proper expiration date and nameservers.

Running a quick DNS query, however, returned nothing:

dig NS getwisp.online +short

A WHOIS lookup showed the status serverHold.

Stuck in No‑Man’s‑Land

I double‑checked for any emails from the registry, registrar, host, or Google—none. I emailed Namecheap, and they replied:

The response clarified that the hold was placed by the registry, not Namecheap, due to “abusive operations.” I then contacted the abuse team at Radix, the registry for the .online TLD, and received:

The Verification Catch‑22

Radix said the domain was suspended because it was blacklisted on Google Safe Browsing. To lift the suspension, I needed to verify ownership in Google Search Console, which requires adding a DNS TXT or CNAME record. But the domain wouldn’t resolve, so verification was impossible.

The catch‑22:

1. Google won’t remove the Safe Browsing flag until the domain is verified.
2. Radix won’t reactivate the domain until Google removes the flag.

I reported the false positive through several Google channels:

• Safe Browsing error report
• Phishing report
• Safe Search review contact

All attempts returned “No valid pages were submitted” because the domain did not resolve. As a last resort, I submitted a temporary release request to Radix so Google could review the site’s contents.

A Series of Unfortunate Events

Looking back, I made several mistakes I won’t repeat:

• Choosing an obscure TLD. .com remains the gold standard.
• Not adding the domain to Google Search Console immediately. I skipped analytics and assumed I wouldn’t need it.
• Skipping uptime monitoring. The site was just a landing page, but I should have had basic observability.

Both Radix and Google have hair‑trigger bans and cumbersome removal processes, offering no notifications or grace period to address issues. Whether the .online TLD is inherently more prone to false positives or my site was simply reported early on, I’ll never know.

Oh well, c’est la vie. Goodbye, $0.20.

Notes

1. A mirror of the original site can be found here to verify the contents.
2. serverHold is set by the registry and is a royal pain to deal with—usually indicates a serious issue.
3. clientHold is set by the registrar and is mostly related to payment or billing problems.