google-site-verification on 27 domains: 100 records in DNS, five tags in HTML
google-site-verification is where a Search Console property starts. Across 27 domains read on 2026-09-08, 23 carry at least one TXT record and 100 records in total, five homepages also ship the meta tag, and not one site relies on the tag alone.

FIELD TEST · 2026-09-08 · 27 domains · DNS TXT and homepage HTML · one lookup each
Sample and method: the 27 homepages on this panel were reduced to their registrable domains, and each domain's apex TXT records were read once on 2026-09-08 through a public resolver. The same homepages were fetched once each with a desktop Chrome user agent, redirects followed, no JavaScript executed, and every verification meta tag in the served HTML was recorded. Three sites had already dropped out of the panel — stackoverflow.com, medium.com and www.reddit.com.
Twenty-three of 27 domains carry at least one google-site-verification TXT record, and between them they carry 100 of those records. Five homepages also ship the tag in their HTML, and every one of those five is a domain that already had DNS records — no site on this panel rests on the meta tag alone. Fourteen domains carry a Microsoft ownership record in DNS. Zero homepages ship an msvalidate.01 meta tag.
How we measured this
Two lookups per site, both from outside, both cheap. The DNS half was a single TXT lookup for the registrable domain against a public resolver. The HTML half reused the homepage capture from the same morning. Neither one needs access to anybody's Search Console.
# Both halves, against any domain you like
dig +short TXT example.com | grep -i 'site-verification'
curl -s https://example.com/ | grep -oiE 'name="[a-z0-9.-]*(verification|validate)[a-z0-9.-]*"'
Registrable domain means the apex: about.gitlab.com was looked up as gitlab.com, developer.mozilla.org as mozilla.org. The 27 homepages mapped to 27 distinct domains, so no domain is counted twice.
Four limits, and the first one governs how any of this can be read. A domain with no visible token is not an unverified domain. Google documents six ways to verify a URL-prefix property, and four of them — Google Analytics, Tag Manager, Google Sites, Blogger — leave nothing a stranger can look up. We read the apex only, once, so subdomain properties with their own records were never asked for. And we cannot tell which of the 100 records is still doing work; nothing outside Search Console exposes that.
What Google's documentation says a token is for
It proves control before Google will show you any data about the site, and the method decides what the proof covers. The DNS route is the only one that works for a Domain property: "Add a DNS record to your domain provider's record list to prove ownership. This is required only for Domain property (example.com) not URL-prefix properties" (Verify your site ownership, read 2026-09-08). The HTML tag route needs something else entirely — "you must be able to insert a tag into the <head> tag on your homepage".
Two sentences from the same page decide how the counts below can be interpreted. The first is the instruction nobody follows in reverse: "To stay verified, don't remove the DNS record from your provider, even after verification succeeds." The second explains why a domain ends up with eight of them: "Multiple people can verify ownership of the same website property, using the same or different verification methods. If you use the same verification method, just be sure that you don't overwrite the verification tokens of any other owners."
A stack of verification records is a list of people, not a list of mistakes.
So the word "stale" does not appear below. We can count tokens from outside. We cannot tell a live owner from a departed one, and Google's own guidance is to leave them in place.
Where google-site-verification records actually live
DNS wins by a distance, and the two routes are not competing — they stack. Every domain that ships the meta tag also has records in DNS.
| Where the token lives | Domains | Share of 27 |
|---|---|---|
| DNS TXT only | 18 | 67% |
| DNS TXT and HTML tag | 5 | 19% |
| HTML tag only | 0 | 0% |
| Neither, visible from outside | 4 | 15% |
The four with nothing visible are bbc.com, nytimes.com, substack.com and wikipedia.org. All four return exactly one TXT record at the apex, which is the shape of a domain whose records are kept elsewhere or whose verification runs through Analytics or Tag Manager. Reading that row as "four unverified newsrooms" would be wrong, and it is the easiest wrong reading available.
The five homepages carrying the tag in HTML are framer.com, github.com, react.dev, stripe.com and theverge.com. Framer ships four separate google-site-verification meta tags on one page, plus seven records in DNS. Stripe ships two in HTML and six in DNS. On the other side of the range, astro.build and react.dev each publish exactly one TXT record in total, and that record is their verification token.
One hundred records across 23 domains
The average verified domain here carries 4.3 google-site-verification records. Twelve carry five or more. Seven carry seven or more.
| Domain | Google TXT | Microsoft TXT | All TXT at apex |
|---|---|---|---|
| netlify.com | 8 | 2 | 29 |
| techcrunch.com | 8 | 2 | 27 |
| figma.com | 7 | 2 | 41 |
| framer.com | 7 | 2 | 24 |
| gitlab.com | 7 | 2 | 30 |
| mozilla.org | 7 | 1 | 17 |
| slack.com | 7 | 0 | 12 |
| stripe.com | 6 | 1 | 37 |
| astro.build | 1 | 0 | 1 |
| react.dev | 1 | 0 | 1 |
The spread is the finding rather than any single row. One record and eight records are both normal-looking states for a large site, and the count tracks how many separate parties have been handed access over the domain's life rather than anything about the site itself. Figma's apex carries 41 TXT records in total, of which 7 are Google ownership tokens and the rest are other services asking the same favour.
The Microsoft half, and what we could not confirm
Fourteen of 27 domains publish a TXT record beginning with MS=, and zero of the 27 homepages ship a meta tag named msvalidate.01. Both of those are counts of a string, and that is all we are claiming for them.
We wanted to write the next sentence, and we are not going to. Bing's own help documentation would not load for us on 2026-09-08, and the MS= prefix is used by more than one Microsoft product, so naming which service each of those 14 records proves ownership for would be a guess dressed up as a reading. What the counts do support is narrow and still useful: on this panel the DNS zone is where ownership proof lives, and the HTML head is nearly empty of it. If Bing is on your list — and its index is what Copilot and web search in ChatGPT draw from — the setup path and what the AI Performance report can tell you afterwards are in Bing Webmaster Tools setup.
Other tokens showed up along the way: 12 domains carry an Apple record, 9 an Atlassian one, 6 a Facebook domain verification, and exactly one carries a Yandex record. Naver appears once too, but in HTML, on notion.com.
What this changes for you today
Run the two commands above against your own domain, and then compare the answer against Search Console. That comparison is the whole point, because the outside view and the inside view answer different questions.
- Read your own TXT records first, before you add another one — a fifth token for the same property is how these piles start
- Use the DNS record if the property matters, because it is the only method that covers a Domain property and every protocol and hostname spelling under it
- Do not remove a token you cannot account for, because Google's documentation says another owner may be standing on it
- Do not read an empty TXT response as an unverified site, including your own — four methods leave no trace at all
Which method fits which situation is a separate decision with five real options, worked through in Search Console verification. If the question underneath is whether search engines and AI crawlers can reach the site in the first place, ownership proof is downstream of that; the gap diagnosis starts at the other end.
Common questions
How did you measure this?
One TXT lookup per registrable domain on 2026-09-08 through a public resolver, plus one homepage fetch per site on the same morning with a desktop Chrome user agent. Twenty-seven domains after three exclusions. Both commands are in the method section and reproduce the counts for any single domain.
Does having several google-site-verification records hurt anything?
Nothing we measured says so, and Google's documentation treats several owners as normal. What a pile costs is legibility: after eight records, nobody on the team can say which agency still has access to the data.
Should I use the DNS record or the HTML meta tag?
The DNS record if you can reach the zone file, because it is required for a Domain property and it survives a homepage redesign. The meta tag is the fallback when you can edit the page and not the zone. On this panel the choice is already settled: 18 domains use DNS alone and none uses the tag alone.
Why did four domains show nothing?
We do not know, and the measurement cannot tell us. Four of Google's six URL-prefix methods leave no public artifact, so the likeliest explanation is that those four verify through Analytics or Tag Manager. A subdomain property with its own record would also be invisible to an apex lookup.


