Two domains can have similar SEO metrics and completely different investment potential. We built domain name analysis in Karma.Domains to help investors separate those cases before the expensive, manual part of due diligence begins.
Table of Contents
- Table of Contents
- I didn't want another appraisal score
- We nearly built too much
- The first layer contains facts
- Word count turned out to be an AI problem
- The second layer interprets the name
- The model was confident about bad splits
- Our test set started flattering us
- Production controls mattered more than the prompt
- Four ways I would use the new filters
- How the report supports the decision
- The same fields work outside the browser
- Where the automation stops
While reviewing auction and expired-domain lists in Karma.Domains, I kept running into the same gap. Our reports could tell me a great deal about a domain's past: what used to be on the site, which topics appeared in its archive, whether its backlink profile showed obvious risk, and which SEO signals were available.
The report said much less about the name itself.
That distinction matters to a domain investor. A clean two-word commercial name and an awkward string of fragments can sit next to each other with similar authority metrics. One may be easy to pronounce, easy to remember, and useful to several kinds of buyers. The other may have no plausible end user at all.
As our database grew past 13 million expired and auction domains, with more than 400,000 domains processed daily from 40+ sources, that blind spot became harder to ignore. Karma.Domains already supported 90+ filters and combined available data from Ahrefs, Semrush, Moz, Majestic, Similarweb, the Wayback Machine, and other sources. Investors could screen history and SEO signals in detail. They still had to read thousands of names one by one.
So we built a new layer for the question every domainer asks first: is the name worth a closer look?
I didn't want another appraisal score
The obvious product idea was a single “investment quality” number. I rejected it early.
A domain has no universal value outside a buyer, a market, a sales horizon, and a strategy. An investor who specializes in short acronyms sees a different asset than someone building a portfolio of local service domains. A natural phrase in Dutch may look meaningless to an English-only model. A strong geo-service name can be useful to a lead-generation operator and irrelevant to a brandable marketplace.
A single score would hide those assumptions. Worse, it would make a subjective model output look precise.
Karma.Domains already has a Brand Score, and we kept it separate. The new analysis exposes the evidence an investor may want to filter: structure, words, language, name type, industry, and possible exact-match intent. The investor supplies the strategy.
My opinion here is fairly strong: appraisal is the wrong abstraction for the discovery stage. Discovery should reduce the pile while preserving the reasons a name survived.
We nearly built too much
Our first product vision was much larger. It included investor-specific views, projects, an inbox, a deal pipeline, monitoring, and several other workflow features.
Most of those ideas may still be useful. They were also a good way to spend months building a separate product before proving that investors wanted the underlying analysis.
We cut the scope back. The first release would live inside the search and report experience people already used. It would add fields to the existing domain record, filters to the existing list, and a readable breakdown to the existing report. The same data would also be available through the Public API and MCP.
That decision shaped the feature. We were building a better first pass through inventory, not a replacement for an investor's portfolio system.
The first layer contains facts
Some properties of a domain name do not need a language model.
For the second-level domain, Karma.Domains calculates:
- character length;
- digit and hyphen counts;
- whether digits or hyphens are present;
- a letter pattern;
- a vowel and consonant pattern;
- text at the beginning, end, or anywhere in the name;
- the TLD.
The letter pattern uses L for a letter, N for a number, H for a hyphen, and X for another character. The vowel pattern uses V for a vowel, C for another Latin letter, plus N, H, and X.
Take solar7.com as a simple example. Its letter pattern is LLLLLN. Its vowel pattern is CVCVCN. No model has to “understand” the name to produce either result.
Patterns are especially useful when the shape of the asset matters. An investor looking for four-letter names can filter for LLLL. Someone researching pronounceable five-letter combinations can work with vowel patterns such as CVCVC, then apply a language or name-type filter afterward.
These fields are predictable. Run the same filter tomorrow and the structural result will not change because a model interpreted the name differently.
Word count turned out to be an AI problem
Word count sounds like another fact. It is not, at least not for a domain without spaces.
Before we can say that a name contains two words, we must decide where one word ends and the next begins. Eightshapes probably means “eight shapes.” A string that mixes languages, a surname, and an abbreviation may support several reasonable splits. A made-up brand may look like two familiar fragments even when the intended reading is one coined word.
This is why the word-count filter belongs to the AI-assisted part of the system. It depends on tokenization, and tokenization depends on meaning.
That small realization changed the architecture. We stopped treating every field that looked numeric as deterministic.
The second layer interprets the name
The model receives the domain name and TLD. It does not see backlink metrics, auction popularity, traffic estimates, or KarmaScore while classifying the name. We wanted the result to describe the string, not rationalize signals from elsewhere in the report.
The analysis tries to identify:
- the words inside the name;
- the likely language of each word;
- a short meaning;
- one primary type, such as dictionary word, descriptive phrase, personal name, or brandable;
- additional types where applicable, including geographic, acronym, and EMD;
- one or more broad industries;
- a commercial phrase when the name appears to be an exact-match domain;
- an overall confidence level.
We use 17 broad industry categories. They are deliberately coarse. “Software” or “real estate” can help narrow a large list. A model inventing an extremely specific business plan from six letters would not.
The same restraint applies to name types. A primary type must be singular. A name cannot be both a clear descriptive phrase and a coined brandable simply because the model wants to hedge. Geographic, acronym, and EMD work as additional attributes because they answer different questions.
On paper, this looked straightforward. The first tests were not.
The model was confident about bad splits
The most common error was word segmentation.
A model would leave an obvious compound such as eightshapes glued together. On another name it produced a split equivalent to cop + salive, even though the second token made no sense. Multilingual strings caused their own trouble. A name such as vuelostime invites competing Spanish and English readings, and the model could jump between them without admitting the ambiguity.
Language detection created another class of errors. Early versions inferred a language from the TLD, treated Latin characters as evidence of English, or confused a place name with a language. Acronyms were sometimes expanded without evidence. Industry labels multiplied whenever a word had a weak association with several markets.
EMD classification swung in both directions. A narrow prompt missed useful commercial phrases. A broader prompt started calling almost any descriptive combination an exact-match domain.
We tried several model families. Some returned malformed or truncated structured data. Faster models tended to scatter industries across weak associations. One model produced noticeably better linguistic analysis on a test batch, but it was too slow and expensive for the volume we needed to process.
Increasing temperature did not help. These were systematic errors, not a shortage of creativity.
One change did improve difficult names: asking the model to form a general meaning before finalizing the word split. On thegeoffcapesfoundation, semantic context helped it arrive at the / geoff / capes / foundation. It still did not solve every multilingual or ambiguous case, but it gave tokenization a better starting point.
Our test set started flattering us
At one point, we added several difficult domains and their correct interpretations to the prompt as examples. The next evaluation looked much better.
Too much better.
We were repeatedly testing some of the same domains. The prompt had effectively been given the answers. It could reproduce those cases without learning a rule that transferred to new inventory.
We removed the domain-specific examples and rewrote them as general instructions. The scores fell. That was useful because the lower result was honest.
This was probably the most important development lesson in the project. A prompt can look excellent when the test set leaks into it. Domain names make that mistake easy to miss because every troublesome string feels like a special case worth adding as an example.
After that, we judged changes on unseen names, with extra attention to multilingual strings, long compounds, personal names, acronyms, and phrases that could be segmented more than one way.
Production controls mattered more than the prompt
We kept improving the prompt, but prompt work eventually hit diminishing returns. The production safeguards did more to make the feature trustworthy.
The backend checks that every token can be joined back into the original name. The model cannot add a letter, drop a character, or silently “correct” spelling. If the split fails validation, the system falls back to a safer representation.
The schema allows one primary type, which prevents contradictory answers in that field. Missing analysis remains unknown. We do not convert an unprocessed or failed classification into a false “no.” In the interface, AI-derived filters and the classification panel carry a warning that the result may be inaccurate.
This approach accepts an uncomfortable fact: some names are ambiguous, and the model will sometimes be wrong. The controls keep a strange answer from becoming corrupted structure or false certainty.
An investor can still find an overlooked candidate by trying adjacent filters. The system should never make a questionable inference disappear behind a confident score.
Four ways I would use the new filters
The practical value appears when exact structure and semantic classification work together. Here are four starting recipes. The ranges are examples, not universal buying rules.
| Strategy | Structural filters | AI-assisted filters | Manual review |
|---|---|---|---|
| Clean brandables | 5–12 characters, no digits or hyphens, selected TLDs | One or two words, brandable, target language, relevant industry | Pronunciation, spelling, radio test, comparable sales, trademarks |
| Local service EMDs | Market TLD or ccTLD, reasonable length, required geo or service fragment | Geographic, EMD, target language, service industry | Natural phrasing, real search behavior, local demand, legal risk |
| Dictionary and descriptive names | Chosen TLDs, length range, no unwanted characters | Dictionary word or descriptive phrase, language, industry | Buyer pool, alternate meanings, plural form, spelling variants |
| Short acronyms | Three to five letters, patterns such as LLL or LLLL, no hyphens | Acronym flag and language context where available | Plausible expansions, existing organizations, liquidity, trademarks |
Clean brandables
I would begin with what the model cannot misread: TLD, length, digits, hyphens, and pattern. Then I would add one or two semantic constraints, such as brandable plus software.
If the list becomes too small, loosen the semantic field before the structural rules that define the strategy. A mislabeled industry can hide a good name. A 19-character domain does not become a six-letter brandable because the classifier likes it.
Local service names
Geo-service combinations benefit more from semantic filters because the order and language of the phrase matter. Search for the geographic and EMD flags, then review the actual tokenization and meaning shown in the report.
A model can recognize that a city and a service are present. It cannot tell you whether a local customer would naturally say the phrase, whether the search demand is commercially useful, or whether the market is already saturated.
Dictionary words and descriptive phrases
Language is a useful discovery filter here, especially across ccTLDs. It also deserves skepticism. Short words may exist in several languages, and proper names often resemble dictionary words.
I would inspect the colored word breakdown in the report before accepting the type. The visual split makes a questionable interpretation easier to catch than a bare label in a table.
Acronyms
The structural pass does most of the work for short acronyms. The AI flag helps separate likely initials from ordinary short words, but it cannot know every organization, product, or niche abbreviation.
For this strategy, false positives are cheap. Trademark mistakes are not. Keep the AI threshold broad and make the legal and end-user checks strict.
How the report supports the decision
The Domain name tab in a Karma.Domains report shows both layers separately.
The Structure section contains the measurements: length, digits, hyphens, letter pattern, and vowel pattern. The Classification section shows the proposed word split, meaning, type, languages, industries, EMD phrase, word count, and confidence.
We also use the validated word split to display a readable CamelCase version of the domain. Copying the name still gives you the original lowercase domain. The formatted version is there to make a list easier to scan, not to alter the asset.
Brand Score appears in the same area for convenience, but it remains its own signal. The name analysis does not absorb it into a new master number.
If you review only a few dozen domains per month, much of this may be unnecessary. You can read the names yourself. The filters become useful when the raw list contains thousands of candidates or when several people must apply the same portfolio thesis consistently.
The same fields work outside the browser
We built the feature into the existing search layer, so the name fields are available through the web interface, the Karma.Domains Public API, and the Karma.Domains MCP server.
In the web app, an investor can combine the new fields with auction source, current price, end time, TLD, history, and SEO filters.
The API supports repeatable searches inside a private dashboard, spreadsheet pipeline, or portfolio workflow. An investor can store a thesis as query parameters and run it against new inventory without reconstructing the screen each time.
MCP exposes the same search to ChatGPT, Claude, and other compatible assistants. A request can be conversational:
Find short
.comauction names with no digits or hyphens. Keep one- or two-word English names classified as brandable in software or finance. Show the name breakdown and auction details.
The next message can adjust the thesis:
Keep the structural rules, remove finance, and include descriptive phrases under ten characters.
Natural language makes iteration easier. The underlying filters still do the actual search.
Where the automation stops
The name analysis does not estimate a sale price, predict a sell-through rate, or approve a purchase. It does not replace trademark research, native-language judgment, comparable-sales analysis, or a close look at the archive and backlink profile.
It also cannot know your holding cost, preferred marketplaces, tolerance for illiquidity, or access to likely buyers. Those variables often matter more than one extra signal in a report.
My preferred workflow is simple. Use deterministic filters to define the shape of the asset. Add AI fields to explore meaning and commercial context. Open the reports for the small group that survives. Then check history, links, legal risk, comparable sales, and current auction conditions before setting a bid.
The feature earns its place when it turns 10,000 names into 40 worth reading. Choosing the four worth buying is still the investor's job.