Domain verification

Ground rules

• Reply in the user's language.
• Verification shows that the user controls the site. Help only with sites the user owns or administers, and never suggest ways around verification.
• Verification is completed in the user's Sitelemetry web workspace, not through the audit tools. Give the user the nextAction.url the tool returned; do not guess other account URLs.
• When a tool asks for verification, no audit ran and no audit allowance was used.
• Never ask for passwords, API tokens or DNS, hosting or Google account credentials. The user makes the change, or you edit project files with their approval.

1. Read the reason

Targets are matched exactly. https://example.com/ and https://www.example.com/ are different targets, and so are different ports and paths. Verify the spelling the user wants to audit.

2. Verification methods

The workspace issues a token that starts with sitelemetry- and shows the exact record name and file URL for the target. Always use the values it shows.

DNS TXT record

• Name: _sitelemetry-challenge.<hostname>, for example _sitelemetry-challenge.example.com, or _sitelemetry-challenge.www.example.com for the www host.
• Value: the token, exactly.
• Many DNS panels add the domain automatically; then enter only _sitelemetry-challenge (or _sitelemetry-challenge.www) in the name field.
• New records can take from minutes to hours to become visible, depending on TTL. Check with nslookup -type=TXT _sitelemetry-challenge.example.com or dig +short TXT _sitelemetry-challenge.example.com.

HTTP file

• URL: https://<host>/.well-known/sitelemetry-verification.txt
• Content: only the token, as plain text. Surrounding whitespace is ignored. The file must be smaller than 2 KB.
• The URL must answer with a success status over HTTPS with a valid certificate. A redirect to another host, protocol or port fails the check.
• Where the file usually goes:
  • Next.js, Vercel and most static site generators: public/.well-known/sitelemetry-verification.txt
  • Netlify: .well-known/sitelemetry-verification.txt inside the publish directory
  • nginx or Apache: the .well-known folder in the document root. Make sure rules that hide dot-folders do not block it; in nginx, a location ^~ /.well-known/ { } block takes precedence over regex rules that deny dot-folders.
  • WordPress: the .well-known folder in the site's root directory, uploaded with the host's file manager or SFTP
• Check it with curl -s https://example.com/.well-known/sitelemetry-verification.txt; the output must be the token.

Google Search Console

Available when the workspace offers a Google connection and the user is a verified owner of the property.

• A Domain property (sc-domain:example.com) covers the whole host, including host-wide checks.
• A URL-prefix property covers only that prefix. It authorizes host-wide checks only when it is the root URL of the hostname, such as https://example.com/.

3. What verification covers

• Host-wide security checks need proof for the domain, the hostname or the root URL. A proof for a path prefix such as https://example.com/shop/ covers only checks that work within that prefix.
• On an account with security-only access, a default audit_security call (or a default audit_full, which on such an account runs security only) runs seven public checks without verification: DNS, email DNS, RDAP, TLS, HTTP headers, MITM posture and technology fingerprint. Verification adds checks for HTTP methods, exposed files and paths, and API exposure. An explicit modules list runs without verification only if every module is one of those seven public checks (dns, dns-email, rdap, tls, http-headers, mitm-posture, tech-fingerprint). Any other module needs current verification, and host-wide modules need host proof.
• On other accounts, every audit needs current verification of the exact target, including the public checks.
• Verification does not create a monitoring project. The first accepted audit creates one automatically.
• A proof stays current for 30 days after it was last checked. Keep the DNS record or file in place so it can be checked again.

4. Retry

Retry only after the user confirms that the workspace shows the target as verified.

• Call the same tool with the same target spelling and the same arguments as the rejected call.
• If the result is again a verification reason, compare the target spelling with the verified one and check whether the proof is current. Do not retry in a loop.
• Then continue with the website-audit skill to present the results.