domain-pre-flight

Three steps

1. domain-pre-flight check <domain> Run every enabled check and print a scored verdict in seconds — mostly offline.
2. --check-handles / --check-trademark Opt-in online checks: same-name handles across 5 platforms and trademark deep-link scan.
3. --json ↳ exit 0 / 1 / 2 Machine-readable output plus an exit code aligned with the band, ready to wire into CI.

Who it’s for

• Indie hackers & solo makers sanity-check the name before you buy it — one command instead of five browser tabs
• Startup founders & PMs triage a shortlist of company or product names against the traps that eat weeks after launch
• Growth & marketing teams weigh names on pronunciation, memorability and LLMO fitness before you lock one in
• Automation engineers wire it into CI so a bad domain never reaches the registrar step

When to reach for it

• Naming a new product or side project: judge the top three candidates on one common yardstick
• Considering a short or number-heavy SLD: the deductions show exactly what the pattern will cost you
• Buying a pre-owned domain: the Wayback probe surfaces what lived on it before
• Automating domain procurement: pipe it in and let the exit code decide whether the pipeline continues

Install

pip install domain-pre-flight

# CLI + MCP server
pip install "domain-pre-flight[mcp]"

The optional extra bundles an MCP server, so agents like Claude can call the same checks as tools over stdio.

What it checks

• Structure: length, hyphens, digits, IDN/punycode, RFC 1035 validity — fully offline
• TLD abuse risk: Spamhaus and SURBL statistics per TLD, up to −70 for the worst offenders
• Past-content history: Wayback Machine snapshot count and archive span, up to −25
• Typosquat and brand similarity: Levenshtein distance and bigram overlap against ~120 well-known brand stems, up to −60
• Negative meaning: term match across 11 languages (EN, ES, PT, JA, KO, ZH, HI, AR, VI, TH, ID), up to −70
• LLMO fitness: pronunciation and memorability heuristics, scored 0–20 (experimental)
• Homoglyphs: IDN visual look-alike detection against known confusables, up to −75
• Same-name handles (opt-in): GitHub, npm, PyPI, X, Instagram availability check

Real verdicts

Four domains, defaults, verdict strings copied verbatim from the tool. Measured 2026-07-12 with v0.10.0.

Passes (GREEN band)

Rejections (ORANGE / RED bands)

A clean .com brand-free name lands at 100. Introduce a .tk TLD and add digits, and 90 points are gone before you check anything else. A name that matches an existing brand exactly loses 60 to trademark risk alone. The verdict does not tell you which name to pick — it tells you which ones you should not.

Full scoring rules (weights per check) →

How much one choice moves the number

Same SLD, only the shown factor changed. Real deductions from the tool.

Usage

# full check (structure + history + verdict)
domain-pre-flight check example.com

# offline only — skip the Wayback call
domain-pre-flight check example.com --no-history

# add handle availability across 5 platforms
domain-pre-flight check example.com --check-handles

# JSON output for CI (exit code matches the band)
domain-pre-flight check example.com --json

What real runs return

Three common patterns, all measured with defaults. Reason strings are copied verbatim from the tool.

• my-app123.tk → RED (10/100): .tk TLD risk −70, 3 digits −15, 1 hyphen −5. Three separate red flags stack in a name that "sounds fine".
• google.com → ORANGE (40/100): identical to known brand "google" −60. The verdict does not care that the TLD is clean — the trademark risk carries the whole deduction.
• llmoscore.com → GREEN (100/100): no brand overlap, no negative-meaning hits across 11 languages. What a clean candidate looks like.

The tool does not pick names. It surfaces, before you buy, the pattern buried in a name you were about to commit to.

Status: experimental. Score weights and thresholds are still being calibrated against real-world domain decisions. The verdict is one input, not the only one — Wayback misses will still show up, and homoglyph attacks against your live brand need dedicated monitoring.

Why this tool exists

Domain decisions travel one way. Once you buy, the name lives on your product, in every URL, in every "the correct spelling is —" moment. The signals that would have flagged it — a heavily abused TLD, an existing brand within edit distance 1, an English word that reads as a slur in another language, a URL that used to host something you would not want to inherit — are all cheap to check before you register, and expensive to escape afterwards. This tool checks all of them, at once, in one command.

Alongside dnstwist and Namechk

Different questions. dnstwist generates the permutations attackers might register against your brand; Namechk checks availability across social platforms. domain-pre-flight is the layer before either one — should this name be registered at all, and against what criteria.

A dash means the official docs describe no such feature as of July 2026. The tools are complementary: use domain-pre-flight to decide whether to buy, dnstwist to see who might buy against you, and Namechk when handles across many social platforms are the deciding factor.

FAQ

About the author

Built by Ken Imoto: 300+ technical articles across Zenn, Qiita, Dev.to and this site, 40+ books in 4 languages, 400K+ pageviews on Zenn and Qiita, 4 research papers on Zenodo, and creator of the LLMO Framework.

More about Ken →

Related

The LLMO fitness score operationalizes part of the LLMO Framework — a broader set of practices for making content discoverable by LLMs. Read the framework for the wider context.

LLMO Framework →