Verify a domain

Vercatus reads a site’s pages at its owner’s request. Before a domain can be crawled, someone in your workspace proves control of it. Until it is proven nothing is analysed or measured for the domain: the topics are not built, the poll does not ask the answer engines about it, and the site audit, which crawls your pages, does not start. What is read before that is the access preview of a workspace’s first domain: its robots.txt first (and nothing else if that disallows Vercatus), then its home page, llms.txt and sitemaps, and how Googlebot and the AI crawlers are answered at the home page, in a few dozen requests, once the owner’s email is confirmed. The setup wizard’s domain check and the icon shown beside a site’s name read the home page too (the crawler reference lists them). This protects site owners from being crawled without consent and protects you from a colleague accidentally running analysis on the wrong company.

There are two ways, and a team often uses both. Search Console verifies the site the moment it is connected, so work starts today. A DNS record proves control of the whole domain; in a company it can take a while to go through IT, so Vercatus looks for it on its own once the record has been shown to you.

Search Console: start now

The Google account you connect must be an owner or a full user of one of these:

• the site’s Domain property, sc-domain:example.com, which also covers www.example.com and every other host under the domain;
• the URL-prefix property for exactly the site’s address, at the root: https://www.example.com/.

A restricted user does not qualify, and neither does a URL-prefix property for a folder or for another host. Vercatus checks every property the account can see, not only the one it reads search data from.

1. On the site’s Setup, under Ownership, press Connect Search Console (starts now) and sign in with that account. If it qualifies, the site is verified on the way back.
2. If Search Console was connected before, Verify with Search Console checks again. When no property qualifies, it lists the ones it found and the access the account has on each.

This verification lasts as long as the access does. Every sync reads the account’s properties again; if none qualifies any more, or Search Console is disconnected, or Google no longer accepts the connection, the site stops being verified. The audit log records it, a notice says so, and runs wait until the site is verified again.

DNS: full ownership

1. Under Ownership, copy the TXT record: name @ (the root of the domain), value ca-verify=<token>.
2. Add it at your DNS provider, or send it to whoever manages the domain’s DNS.
3. Wait, or press Check the record (Verify on a site already verified through Search Console). Vercatus checks for the record by itself: every few minutes in the first hour, every quarter of an hour for two days, then hourly until 14 days have passed; after that, only when you press the button. DNS changes can take a few minutes to reach every resolver; the button’s check says what it found. When the record checks out, the owner is emailed and, if the workspace is waiting for its first audit, the audit starts.

A TXT record is a line of text published in a domain’s DNS, and anyone can read it. Only someone who controls the domain’s DNS can publish one, so a record carrying your workspace’s token shows that your side controls the domain. The token is random and means nothing to anyone else: it cannot sign in to anything or change anything.

The record is read when a check runs, not afterwards. Once the site is verified by DNS it stays verified, and removing the record later changes nothing in Vercatus; keeping it costs nothing and lets anyone on the team repeat the check. A site verified through Search Console becomes fully verified when the record checks out, and a change in Search Console never withdraws DNS verification.

The meta tag is the lesser alternative: <meta name="ca-verify" content="<token>"> in the home page’s <head>, checked the same way, automatic checks included. It proves control of the home page rather than of the domain.

Where verification applies

Verification belongs to the workspace where the site is. Someone who runs more than one workspace, for example their own and their agency’s, or an agency and its client workspaces, does not have to prove the same domain twice:

• Adding a domain you already verified. When you add a domain that is verified in another workspace where you are an owner or admin, it is verified in the new one at once. The Add site dialog says Verified through that workspace instead of showing the DNS record, the Ownership row names it, and the audit log records it. A verification held in a workspace you do not run is never reused.
• How long it lasts. A verification that rests on a DNS record or a meta tag stays, as it does in the workspace that proved it, even if the site is later removed there. One that rests on Search Console lasts as long as that access: when the access goes, or the site is removed there, the copy stops being verified too, with a notice saying why. Adding the DNS record in the new workspace makes it its own.

Moving a site to another workspace

An owner or admin can move a site to another workspace they own or administer, including between an agency and its client workspaces, from the site’s Setup (Move to another workspace) or, in an agency, from a client workspace’s menu on the Agency page (Move a site in). Type the domain to confirm.

The site keeps its verification and everything measured on it: its topics and their questions, the engines’ answers and its Answer Share history, its competitors, plays and verdicts, runs, pages and findings, goals, notes, its schedule and its connections (Search Console, Analytics, crawler traffic, CMS and deploy hooks). What stays behind is the workspace’s own record: its audit log and what it was billed for. Scheduled reports, review links and saved views there drop the site; a scheduled report left with no site is paused, a review link left with no site is revoked, and an API key made only for that site is revoked. People limited to some sites lose access to it there. Both workspaces’ audit logs record the move and both get a notice.

A site cannot move while one of its runs is queued or running, into a workspace that already has the same domain, or into one whose plan has no site left (a client workspace billed through its agency counts as part of the agency’s plan, so moving between them takes no extra site).

On a plan, the first site audit starts the moment the site is verified (see Buy a plan), and a verified site can then be run, scheduled and watched. A run button on a site that is not verified opens the ways to verify it instead.