Verifying Your Domain

Most tools ask you to prove you own a domain before they will do anything. LLM Metrix does not, and the reason is worth stating up front: tracking what AI engines say about a domain is observation of public data, and tracking a competitor’s domain is a first-class use case. Gating scans on ownership would break the product for the people who need it most.

So verification here is not a door you must walk through. It is a key that unlocks the specific things where an unproven claim would cost somebody else.

Tier	Method	What it unlocks
0	none	Scanning, rankings, citations, competitor tracking
1	Meta tag	AI Traffic log ingest (Agency plan), the verified badge
2	DNS TXT record	Claiming a white-label host name for your workspace (Business or Agency plan)

Note the plan names in that table. A tier is necessary for the capability beside it, never sufficient — each of those two also sits behind a plan gate, and the two checks are independent.

And note the word claiming on the tier-2 row, because it is doing real work. Tier 2 lets you reserve a host name against your workspace; it does not yet make anything answer on it. Reports and the dashboard are served from our hostname today, wearing your logo, name and colours. Step 5 is precise about which half of that is built.

Both methods will be familiar if you have verified a property in Google Search Console, which offers the same two proofs for the same reason: a meta tag proves you can publish on the site, a DNS record proves you control the domain itself. The second is the stronger claim, which is why it unlocks more here.

Step 1: Decide whether you need to verify at all

If you are monitoring a domain — yours or anyone’s — and reading rankings, citations and competitor data, you need nothing. Everything on those pages works at tier 0 and always will.

You need tier 1 if you intend to upload your own server access logs to the AI Traffic page. Ingesting logs is a claim about a site’s own visitors, and those rows become that project’s crawler analytics — accepting them for a domain you had not proved you control would be a data-poisoning primitive.

Check your plan before you publish a meta tag for this reason, because verifying will not be enough on its own: log ingest is the heaviest path in the product and is separately gated to the Agency plan. The upload endpoint checks verification first and the plan second, so on Team or Business you can pass the tier gate and still be turned away with upgrade_required — having done the work before finding out it was unusable.

You need tier 2 if you want to claim a white-label host name for your workspace — the name itself, reserved to you across the whole platform. Nothing is served on it yet, so this is a claim you stake rather than a switch you flip, and Step 5 explains both why the bar is that high and what white-label does give you today.

Step 2: Open the Domain ownership card

Go to Domains in the Optimise group of the sidebar. The page opens on your active project: a Primary Domain card at the top (editable, with a Save button), then Domain ownership.

The card’s own subtitle repeats the framing — verification is optional, scanning and citations work without it, and what it buys you is eligibility for log upload and a white-label host name, each still subject to its own plan gate. Its icon is a grey shield until you hold any tier, then a green check; at tier 2 a DNS verified pill appears next to the heading.

Underneath are two rows, Meta tag and DNS TXT record, each with a status pill:

• Not started — no token issued yet
• Awaiting check — token issued, never checked
• Not found yet — a check ran and failed
• Verified — proven
• Re-verify — the proof no longer matches the project’s current domain (see Step 7)

Owners, admins and members can all issue tokens and run checks — the same bar as editing the project’s domain, since anyone who can point a project at a domain may as well be allowed to prove it. Viewers cannot.

Step 3: Verify with a meta tag (tier 1)

On the Meta tag row, click Set up. That issues a random server-generated token and expands the instructions:

<meta name="llmmetrix-site-verification" content="YOUR-TOKEN" />

Copy it with the button beside the snippet, paste it into the <head> of your home page, publish, and click Check.

Three things about this method are worth knowing before you use it:

• Leave the tag in place. Removing it invalidates the verification — a re-check will fail.
• The check fetches your home page, https first and http only as a fallback, through the same hardened fetcher the rest of the product uses.
• It obeys your robots.txt. If your robots.txt disallows our crawler, the check refuses rather than sneaking past, and tells you so — with a pointer to the DNS method, which needs no fetch at all and grants a higher tier anyway.

Tier 1 is the method to reach for when log ingest is what you are after and you are already on the Agency plan — a marketing team can publish a meta tag in five minutes, where a DNS change is often a ticket.

Step 4: Verify with a DNS TXT record (tier 2)

On the DNS TXT record row, click Set up. The snippet is a single value:

llmmetrix-verification=YOUR-TOKEN

In your DNS provider, add a TXT record for the domain, using @ (or a blank host) to target the domain itself, paste the value, save, and click Check. DNS usually applies within minutes but can take up to an hour, and the checker is throttled to ten checks per minute per project — enough to poll while you wait.

Proof scopes downward only. Proving acme.com covers reports.acme.com, because control of a domain implies control of everything under it. Proving blog.acme.com says nothing about acme.com — subdomains are routinely delegated to third parties, and that tenant must not be able to claim the parent.

Tier 2 supersedes tier 1: a DNS proof unlocks everything the meta tag did and more.

Step 5: Spend tier 2 on a white-label host name

Two things travel under the name “white-label” and only one of them is built. Take them in the order that matters to you.

White-label branding is live, and needs no verification at all. On Business and Agency, your workspace’s logo, product name and accent colour replace ours across the dashboard, the printable report, every token-gated /report/ link you share and the chrome of the emails we send. A client opening a shared report sees your brand on the page. That is a plan feature, not a tier-2 one — it is already working before you touch DNS.

A white-label host name is what tier 2 buys, and it is a reservation rather than a redirect. Today it records the name against your workspace and nothing answers on it: reports and the dashboard are still served from our hostname. So do not schedule a client hand-off around reports.acme.com resolving — claim the name now if you want it held, and treat serving on it as not yet shipped.

The reservation still requires tier 2, and the reason is structural rather than procedural. The setting is stored in a column that is globally unique across the entire platform. Exactly one workspace can hold reports.acme.com. If the field accepted any string, the first account to type a name would take it from every other tenant — permanently, including from the company that actually owns the domain, and that damage lands whether or not anything is being served yet. DNS control is the right bar precisely because a custom host is a DNS delegation when it ships: anyone who could point a CNAME at us can write a TXT record today, so the proof costs a legitimate owner nothing and stops a squatter completely.

Enforcement lives in the branding API rather than in a form: the write is refused unless some project in the workspace holds a tier-2 proof whose domain covers the host you are claiming, and white-label itself requires the Business or Agency plan. There is no custom-domain field in Settings → Branding today — the claim is made through PATCH /api/workspaces/[id]/branding by an owner or admin. Clearing the field needs no proof; giving a name up is always allowed.

If the Domain ownership card tells you tier 2 “lets you serve reports from your own domain”, read it as the reservation described above. The wording there is ahead of what is built, and this page is the accurate one.

Step 6: Handle the failures you will actually hit

A failed check leaves its reason on the row in amber, and the messages are written to be acted on:

• “No llmmetrix-site-verification tag found” — usually a CDN still serving a cached copy of your home page. Purge and re-check.
• “Found a tag, but its content did not match your token” — a partial copy. Copy the whole value with the button.
• “No TXT records found” or “no llmmetrix-verification=… record” — propagation, most of the time. Wait and re-check.
• “Found a record, but its token did not match” — an old record from a previous attempt. Remove it and add the current one.
• A robots.txt refusal — allow our crawler, or switch to the DNS method.

Re-issuing a token does not rotate one you already published for the same domain: clicking through the flow again reuses the live token rather than silently invalidating the DNS record you added an hour ago and are still waiting on.

Step 7: Keep proofs valid when the domain changes

Editing a project’s Primary Domain deletes that project’s existing proofs. This is not a bug to work around — a proof of acme.com must not survive the project being re-pointed at a domain the workspace does not control, or verification would mean nothing.

If a stale proof does linger, the card reports it as Re-verify rather than hiding it, with the reason spelled out: the proof was issued for the old domain, and the project now points somewhere else. A check in that state refuses rather than testing the wrong host. Issue a fresh token for the new domain and run the method again.

Practical consequence: if you are migrating a domain, expect to redo verification afterwards, and re-check anything that depended on it — log upload will start returning domain_not_verified the moment the tier drops.

Step 8: Where to go next

• Monitoring AI Traffic and Crawlers — the tier-1 capability, including the Agency plan gate, and what to do with it once it is unlocked.
• AEO for agencies — where a white-label reporting domain earns its keep.
• Technical SEO for AEO — the wider set of site-level signals verification sits alongside.
• Citation intelligence — one of the tier-0 surfaces that keeps working on any domain, verified or not.