How Domain Yoga ranks brandability

When you run a search, Domain Yoga returns around 250 names and gives each one a brandability score and a relevance score. The two are deliberately separate. Relevance measures how well a name fits the project you described. Brandability measures the quality of the name on its own — whether it would make a strong brand for any business, independent of your prompt. This page explains what goes into that brandability score.

Shorter is stronger

The best brand names are short. Four to nine characters is the sweet spot; a name can earn a bit more length if it's especially evocative, but every extra character is a small tax on memorability, on typing it correctly, and on fitting it into a logo. Long, descriptive strings score lower.

The radio test

A great name survives being spoken aloud. If someone hears your domain once — on a podcast, in a hallway, in a demo — they should be able to spell it without asking. Names that pass this test tend to be one to three syllables and pronounceable in an obvious way. Clever spellings that need explaining fail it.

Clean phonetics and spelling

Brandability rewards names that are easy to say and unambiguous to write: no hyphens (they don't survive the radio test and read as spammy), no gratuitous digits, and no awkward letter collisions where the boundary between words produces something unintended. Double letters that complicate spelling are penalised unless they're part of a familiar pattern.

Distinctive beats descriptive

A generic, descriptive phrase — the kind that literally states what you do — is easy to think of and hard to own. Distinctive names win: invented words, wordplay, and evocative coinages are more memorable and far easier to trademark and rank for. The score favours names that feel like a brand, not a category.

The TLD is part of the name

The extension isn't an afterthought — it's read as part of the whole. A complementary TLD can lift a name (a tech product on .io, .ai, .dev, or .app; a clean .com or .co), while a spam-coded extension drags the whole name down regardless of how good the root is. Domain Yoga scores the name and its extension together.

Availability decides the order

A high score only matters if you can actually register the name. Every candidate is checked live for availability across 800+ extensions, and available domains float to the top of your results — so the names you see first are both high-scoring and yours to claim.

How the names are generated

To give every search range, the AI is asked to mix approaches within a single batch — invented coinages, wordplay, real-word brandables, and metaphors — rather than return 25 variations on one idea. That diversity is deliberate: it's how a single search surfaces directions you wouldn't have thought to ask for.

The availability benchmark corpus

Separately from search results, Domain Yoga publishes a domain-availability benchmark at /data/availability, intended to repeat monthly. One full run exists so far, captured 2026-08-02. What keeps a later run comparable to an earlier one is the corpus — the same 5,006 names measured each time. The TLD set is free to widen between runs: each stratum × TLD observation stands on its own, so measuring more TLDs in a later run doesn't disturb the comparisons that already exist.

The corpus itself isn't published as a standalone file — it lives in our private source repository, version 1, frozen 2026-07-31. That's not the same as hidden: every one of its 5,006 labels, its stratum, and — for patterns — the specific pattern it's built from is recoverable from the published NDJSON at /data/availability, since each of the 15,018 measurement records names the exact candidate that was checked.

It's 5,006 names across four strata. Three draw from web2 — Webster's Second International, 1934, chosen because it's public domain: 1,250 dictionary-words are single web2 words, 1,250 compounds are two web2 words concatenated, and 1,256 patterns apply a prefix or suffix (get-, try-, -hq, and similar) to a web2 word. The fourth stratum, 1,250 invented names, is pronounceable CVCVC strings generated independently of any wordlist.

The corpus is frozen on purpose. Regenerating it would invalidate any trend comparison across runs — a claim like "availability on .com is down from last month" is only honest if the names being measured didn't change between runs, and that specific comparison doesn't exist yet: there's only one run to date. That run measured all 5,006 names against three TLDs — .com (Verisign), .app (Google Registry), and .dev (Google Registry) — 15,018 checks in total.

Later runs widen that coverage: the benchmark now checks ten TLDs across seven registries — .com and .net (Verisign), .org (Public Interest Registry), .io and .ai (Identity Digital), .co (the endpoint at rdap.registry.co), .app and .dev (Google Registry), .xyz (CentralNic), and .tech (Radix) — 5,006 names × 10 TLDs = 50,060 checks per run. Each check resolves the name's registry RDAP record, ordinarily via IANA's bootstrap: a 404 means available, a 200 means registered, anything else is recorded as indeterminate rather than guessed. Two of the ten, .io and .co, are absent from IANA's bootstrap; those two resolve instead from a list maintained in this repository rather than from IANA.

That supplement is why every capture run now opens with a control check: before any candidate name is measured, one domain per TLD that is already known to be registered is checked first, and the run aborts unless every one of them comes back registered — a safeguard added after the 2026-08-02 run described above, which predates it and ran without this check. This matters because a wrong-but-real RDAP endpoint can answer a registered name with a well-formed 404 — indistinguishable from a genuine "this name is free" response, same status, same content type, same body shape. Verified live, rdap.centralnic.com does exactly this for google.co: a real RDAP server, answering the wrong TLD's registered name as if it were free. Nothing in the resulting data could reveal that failure after the fact — the only defence is checking a known answer before trusting an unknown one.

Each registry is checked by its own sequential worker, so no registry sees more concurrency than the single combined stream 2026-08-02 used. Request density is not identical, though: that run interleaved a .com check between consecutive Google checks, while Google's worker in a wider run issues .app and .dev checks back to back — roughly 1.5× the rate that already produced 419 .app and 413 .dev unresolved checks in the first run. That costs precision on those two TLDs (more checks landing as indeterminate), not bias — the published availability percentage excludes indeterminates from its denominator.

The corpus has a known bias: web2 is a dictionary, not a frequency list, so the dictionary-words and compounds strata over-represent archaic and obscure vocabulary. Read their availability figures as an optimistic ceiling, not a picture of how available common English words actually are.

That bias reaches patterns too: every one of the 157 distinct base words the stratum applies get-/try-/-hq-style prefixes and suffixes to is itself a dictionary-words word — getaalii, tryacetone, adonitehq, not typical startup vocabulary. Patterns rows are comparable with each other, but their absolute availability rates inherit the same optimistic ceiling and aren't evidence that "a normal word with get-/try-/-hq" is generally this available.

One measured caveat from that run: the capture script retries each check inline up to three times (400ms, then 1,200ms, then 3,000ms) before giving up, and 832 of the 15,018 checks (5.5%) were still unresolved after those retries — 419 on .app, 413 on .dev, none on .com. A separate, paced re-check pass run the next day, 2026-08-03, resolved 831 of them; the last one had failed on a transport error rather than another throttle, and a second pass minutes later resolved it too. That split is a property of the registries, not of the names: Google Registry throttled that run and Verisign didn't.