Availability & AI / 9 min read
A TLD price is not availability: how to read domain checks
Start here
A standard extension price never answers whether your exact name can be registered. Treat availability and premium as independent facts, and never rewrite unknown or unsupported as taken.
A price table for .com tells you what an ordinary .com costs at the registrars we compare. It does not tell you whether shipfast.com is free, reserved, or sold as a premium name. Those are different questions, answered at different times, by different systems.
People and AI assistants collapse the questions. They see a cheap .dev row and announce that a brand is available. They see an empty website and conclude the domain is unused. They see a WHOIS timeout and report the name as taken. This article is the contract we use instead.
Price, availability, and premium are three questions
A useful shortlist keeps three columns. The first is the standard registration and renewal for the extension at a registrar. The second is whether that exact domain can be registered right now. The third is whether the name is ordinary-tier or premium.
Swipe or scroll the table to compare all columns →
| Question | What answers it | What does not |
|---|---|---|
| What does an ordinary name under this extension cost? | A fresh standard price list, with a retrieval time | A website being down; a guessed “usual” .com rate |
| Can this exact domain be registered? | An exact-name check with a timestamp | The extension’s list price; an empty home page |
| Is this name standard or premium? | A provider that reports premium independently | A missing premium flag; a low list price |
Cheapest domains answers the first question from a saved catalog. It answers the second and third only when you (or an assistant) request an exact-name check. Price research never implies a check. A check never invents a missing premium flag.
If any column is empty, leave it empty. A blank premium field means “not confirmed.” It does not mean “not premium.” A blank availability field means “not confirmed.” It does not mean taken.
Unknown is not taken — in provider answers and on our website
This rule is about both what registrars and other providers return and what we are allowed to show. Providers send many inconclusive outcomes: timeouts, unsupported extensions, access errors, reserved-but-unclassified names, and responses that confirm one fact but not the other. Our adapters keep those outcomes distinct from “unavailable.”
On the website, a taken name is shown as Taken only after a provider has confirmed that the name is not available for new registration. Unchecked rows have no pill. In-flight rows show a spinner. Settled but unconfirmed rows say Not confirmed. The recap uses the same vocabulary: Not checked before a request, Not confirmed when evidence is missing, and Taken only for confirmed unavailability.
The public API uses the same facts. status can be available, unavailable, premium, unsupported, or unknown. availability is available, unavailable, or unknown. premium is true, false, or null. Unsupported means the provider cannot check that extension. Unknown means reliable evidence is missing. Neither value may be rewritten as unavailable.
Assistants that “helpfully” turn unknown into taken remove names the user might still buy. Assistants that turn unknown into available send people to a checkout that will fail. The honest sentence is: we could not confirm this, here is the registrar link, check again if you still want the name.
RDAP and WHOIS are registration records, not checkout quotes
RDAP is the Registration Data Access Protocol. It is the IETF successor to port-43 WHOIS for looking up registration objects. ICANN’s RDAP page explains the protocol and points to the lookup service. Many open-source “domain MCP” tools query public RDAP or WHOIS and treat a missing object as available.
That can be a useful first filter. It is not a registrar checkout. A name can exist in the registry as available and still be premium, reserved for the registry, restricted by policy, or unsellable at the shop you intended to use. A name can also look unregistered in a timed-out WHOIS response while it is already taken.
RDAP answers “is there a registration object?” when the server responds clearly. It does not answer “what will I pay at Porkbun or Cloudflare for this exact string?” and it does not replace a provider that classifies premium creation quotes. Our leftover checks use registrar or registry-adjacent APIs that return independent availability and premium facts, not a WHOIS scrape.
If an assistant only has an RDAP tool, it should still say that premium and purchase eligibility are unconfirmed. If it also has our tools, it should use the price catalog for extensions and check_availability for a short list of finalists — not for every brainstormed name.
How a selected check is allowed to run
One uncached selected lookup makes at most one Cloudflare call, then one leftover call per remaining stage when facts are still missing, then at most one selected-registrar call if that registrar was not already used as leftover. The leftover order is Name.com, then Gandi, then Fastly Precise when those stages are configured. The chain stops once both availability and premium are confirmed.
Omitted registrar still permits leftover stages. It does not invent a selected-registrar call. Vercel can fill missing availability when selected; it has no documented premium flag. Gandi leftover can classify some premium creation quotes. Fastly inactive results without a premium flag can establish standard tier; reserved, DNS-only, aftermarket-only, taken, and unknown results cannot.
Successful checks expire after five minutes and may change sooner. Preserve the check time. Do not poll. Do not scan an entire catalog. A rate-limited or failed stage leaves that provider’s facts unknown and may allow a later independently admitted stage to continue. Primary admission failure stops the chain.
The website list view is a bounded version of the same idea: it checks visible names in groups of 20, reuses shared leftover evidence, and keeps a spinner while a later leftover stage is still working. Price queries and naming suggestions alone leave availability unchecked. Visiting a guide never starts a check.
What an assistant should do with these facts
- Suggest names from the project brief. Label each suggestion availability not checked until a tool result exists.
- Use current renewal prices for extensions that fit the budget. Keep source times and coverage limits.
- Check at most a few user-chosen finalists. Read availability and premium independently. Preserve timestamps.
- If the result is unknown, unsupported, or incomplete, say that. Offer the registrar link. Do not mark the name taken.
- Never register, reserve, or claim a purchase. Those operations are not implemented here.
A compact review table helps a human catch mixed-up stages. Each row should show which facts were retrieved and which were written as explanation. Invented availability is worse than an honest unknown.
Swipe or scroll the table to compare all columns →
| Candidate | List price used | Check result | Safe next sentence |
|---|---|---|---|
| A | Standard .com renewal from a dated catalog row | Available, standard tier confirmed | Confirm checkout at the selected registrar while the check is still fresh. |
| B | Hidden — premium confirmed | Available and premium | Get the registrar’s premium quote before comparing cost. |
| C | Standard .dev row only | Availability unknown | Do not treat this as taken or free. Complete the exact-name check or open the registrar. |
Candidate C is the failure mode this article exists to prevent. The list price is real. The availability is not. Writing “C is taken” or “C is free” from that row is a fabrication.
Exact names leave the conversation
A price query needs an extension and filters. An availability check needs the exact domain. That domain is sent to the checking providers and can appear in hosting logs when it is placed in a URL. Keep the private project brief in the chat. Send only the lookup inputs.
Shareable homepage links include the typed name. Opening or reloading such a link sends that query to the host. Read the privacy explanation before putting a confidential launch name into a shared URL.
What this page does not claim
This is not a promise that every assistant will discover us, call our tools, or cite this article. Google’s guidance for AI search features does not require a special AI file. Publishing /llms.txt and a public MCP server makes research possible; it does not guarantee selection.
Coverage is limited to connected registrars and configured check providers. A missing registrar is not evidence that it is expensive. A missing check provider leaves facts unknown. GoDaddy and Namecheap are examples of brands people search for that are not public comparison rows today.
For prices, start with the renewal guide and a TLD page such as .com. For tool setup, use assistant setup and the API guide.
Frequently asked questions
If a check comes back unknown, is the domain taken?
No. Unknown means we do not have reliable evidence. Unsupported means the provider cannot check that extension. Only an unavailable result means the name is not available for new registration at the time of the check.
Does a cheap TLD price mean my name is available?
No. The price describes a standard name under that extension at a covered registrar. Check the exact domain separately, and read availability and premium independently.
Is a WHOIS or RDAP lookup the same as your availability tool?
No. RDAP and WHOIS look up registration objects. They can be a useful filter, but they are not a checkout quote and they often do not classify premium. Our exact-name tool returns independent availability and premium facts from configured providers, with timestamps.
Why does the website show Not confirmed instead of Taken?
Taken is reserved for confirmed unavailability. Not confirmed is the label for missing or inconclusive evidence, including unknown provider answers. Showing Taken without that confirmation would invent a result the registrar did not give us.