Domain Verification
Scanning a URL is open to anyone — publishing a public claim about it is not. Domain verification is how AllyProof establishes that the site you are making claims about is actually yours.
Why verification exists
Anyone can scan any URL. That is deliberate, and every comparable tool works the same way: WAVE, Lighthouse, PageSpeed, and axe DevTools all let you point at a domain you have never touched.
Publishing is a different act. A share link, an accessibility statement, an embeddable seal, or an automated scan evidence summary publishes observations about a site to the public. Without an ownership check, anyone could scan a competitor and publish "fails WCAG", or put a green seal on a site they do not control.
So the rule is narrow and absolute: scanning is open, publishing is gated.
What verification unlocks
Until a site is verified, it scans normally and its results are visible to your own team. Verification is what enables anything outward-facing:
| Capability | Needs verification |
|---|---|
| Scanning, issue lists, scores, history | No |
| Public share links | Yes |
| Accessibility statements | Yes |
| Embeddable accessibility seal | Yes |
| Automated scan evidence summaries | Yes |
| Regulatory / compliance module | Yes |
| Declared markets, establishment country, locale roots | Yes |
Your AllyProof administrator can additionally require verification before a site may be scanned at all. That is an organization-wide setting and is off by default; the publishing gate above is not optional and cannot be turned off.
Choosing a method
Two methods are supported. They are equivalent — pick whichever you can deploy faster, and you can switch between them at any point before verifying.
HTML meta tag is usually quicker if you can deploy to the site. It takes effect the moment the page is live.
DNS TXT record is the better choice when you would rather not touch the site's markup, when the homepage is behind a login or a bot-protection layer, or when a marketing team owns the HTML and an infrastructure team owns DNS. DNS changes can take up to 48 hours to propagate.
Both are set up under Sites → (your site) → Verification, which shows the token, the exact snippet, and a Verify now button.
Method 1 — HTML meta tag
Add the tag AllyProof shows you to the <head> of your site's homepage:
<meta name="allyproof-verification" content="allyproof-verify-YOUR-TOKEN">
Deploy the change, then click Verify now. AllyProof fetches the homepage
and looks for the token. The check follows redirects, so a http → https or
apex → www redirect is fine.
The tag must be present on the URL registered for the site. If you registered
https://example.com but the tag is only on https://www.example.com and
there is no redirect between them, the check will not find it.
Method 2 — DNS TXT record
Add a TXT record at your DNS provider for the site's root domain:
| Field | Value |
|---|---|
| Type | TXT |
| Host / Name | @ (or leave empty — this means the root domain) |
| Value | allyproof-verify-YOUR-TOKEN |
Save it, wait for propagation, then click Verify now. AllyProof resolves the domain's TXT records and looks for one containing the token. Other TXT records — SPF, DKIM, and so on — are unaffected; the check reads them all and matches on the token, so nothing needs to be removed.
The token
Each site gets its own token, derived from the site's identifier and a server-side secret. It is stable: the token shown today is the token that will verify tomorrow, so it is safe to commit to a template or check into infrastructure-as-code.
Because it is per-site, a token from one site will not verify another. Copying a meta tag from one property to another is the most common cause of a verification that will not pass.
When verification fails
Meta tag — confirm the change is on the live site rather than a staging
build, that it is inside <head>, and that the page returns HTML to a plain
request. A homepage rendered entirely by client-side JavaScript will not work:
the check reads the HTML the server sends, and never executes scripts. Put the
tag in the server-rendered document, or use the DNS method instead.
DNS — propagation is the usual answer; check with
dig TXT example.com +short (or nslookup -type=TXT example.com) and look for
the token in the output. If your provider automatically appends the domain to
the host field, entering @ may have produced a record on
example.com.example.com. Leave the host empty instead.
Verification is re-checkable as often as you like — a failed attempt costs nothing and changes nothing.
After you're verified
Verification is checked when you click Verify now, not on a schedule. Once a site is verified it stays verified, and removing the record will not silently revoke it.
Leave the record in place anyway. It is inert either way — a TXT record costs nothing and the meta tag is invisible to visitors — and it is what you will need if the site is ever re-verified: after changing the registered URL, moving to a different verification method, or re-adding the site later. Deleting it turns a future one-click check into a deploy.