Proving the site

Services that will show your pages, pay you for them or index them first want one thing: proof that the site is yours. Every one of them asks for the same proof in one of two shapes.

A meta tag. The service gives you a string, you store it, and the site puts it in the head of every page. Google Search Console and Bing work this way.
A file. The service gives you a token and an address, and the site must answer at exactly that address with exactly that token. Brave Creators works this way.

The platform could always do the first. The second is newer: until September 2026 nothing on any site answered under /.well-known/, so a service that verifies by file could not be satisfied at all.

The card

Backoffice → Redirects → Proving the site. Every service that has registered a proof appears there with three things: whether it is set, what the service does with the proof, and a box to change it.

The card stores nothing of its own. Google's token stays in the Google settings, Bing's stays as a tag on the site's metadata tier, Brave's stays on the site row — the card reads and writes them where they live. That is why a fourth service will appear here by registering itself, without this screen being edited.

Two behaviours worth knowing:

Empty clears it. Clearing Bing's token removes the tag rather than rendering an empty one.
„Could not be read" is not „not set". If a module's own storage is unavailable, the card says so instead of showing an empty box you would then fill in by mistake.

Through the tools: seo_verifications reads them all, seo_verification_set writes one.

Brave Creators

What it is for. Brave Creators is about creator payouts — Brave users tip verified sites and channels. It is not a search console, it does not index anything, and verifying here changes nothing about how Brave Search sees you. (Brave's crawler follows your robots.txt like any other; see Web delivery.)

Where the token goes. The organization screen, beside the site's robots.txt: Brave Creators token.

Brave shows you one token and two ways to use it — a DNS record whose value is brave-ledger-verification=<token>, and a file containing the token alone. Paste either. The field keeps what the file method needs, so you never have to work out which half you are looking at.

What the site then does. It answers:

https://<your site>/.well-known/brave-rewards-verification.txt

with the token, as plain text and nothing else. Clear the field and the address goes back to answering 404 — never an empty file, because a service that asked for a token and received an empty page reports a failure nobody can explain.

One firm, one host. The file is a claim about who owns this site, so it is served only on that firm's own hostname. Another firm's site never answers with your token, and a host that belongs to nobody in particular falls back to the default site — which usually stores no token, and so answers 404.

After you change it. The site answers immediately; the edge may not. Cloudflare caches this address, so purge it (Safety → purge, or safety_purge_cache) or wait out the cache before telling Brave to check. Verifying against a cached 404 is the most common way this appears not to work.

Why the whole `/.well-known/` prefix is not ours

Warning

/.well-known/ is a shared doorway, and one of its rooms is not ours: /.well-known/acme-challenge/ is how this installation's TLS certificates are issued. Caddy answers it directly, on demand, for every customer domain.

Routing the whole prefix to the application would break nothing on the day it was done — certificates last months — and then break every certificate renewal at once, weeks later, with no recent change to blame.

So each file is routed by name. Adding another one is one line in the edge configuration (in both Caddyfiles — the live container runs Caddyfile.nodns), plus one registration in the module that owns the value. That is deliberate friction, and it is cheap compared with what it prevents.

Through the tools

The token is part of the site's identity, so it travels with it:

organization_site        → reads it back (empty = not verified)
organization_site_save   → writes it; "" clears it, omitting it keeps it

A caller that does not mention the field never clears it — the same rule the rest of the site identity follows.

What this does not do

It does not make Brave Search rank or crawl you differently.
It does not verify by DNS. That method belongs to whoever holds the zone; if you prefer it, add the TXT record at your DNS provider and leave this field empty.
It does not tell Brave you are verified. You still click verify on Brave's side — this only makes the answer be there when they look.