Search Console verification: five methods, and two questions that pick one for you
Search Console verification proves you control a site before Google shows you any of its data. Five methods exist, only a DNS record verifies a Domain property, and every other method covers exactly one protocol-and-hostname spelling.
Search Console verification is the step where you prove to Google that you control a site, before it shows you any data about that site. Five methods are available and they are not interchangeable: only a DNS record verifies a Domain property, and every other method verifies exactly one protocol-and-hostname combination. Decide the property type first. The method follows from that.
What you need before this chapter
You need write access to at least one of four things: the files at your site root, the <head> of your homepage, your DNS zone, or an Analytics or Tag Manager container that is already installed on the site. You also need to know which hostname you actually want data for, because a hostname is the unit both Search Console and Google's crawler count in — that decision is the subject of subdomain vs subfolder.
What Search Console verification actually proves
It proves exactly one thing: whoever added the token had write access to something only an owner should be able to change. It says nothing about who registered the domain, and it grants nothing beyond reading that property's data and using its tools. The five methods differ only in which door they ask you to open.
That is also why the property type has to come first. A URL-prefix property is scoped the way a robots.txt file is scoped, and Google states that boundary plainly: "The rules listed in the robots.txt file apply only to the host, protocol, and port number where the robots.txt file is hosted" (robots.txt introduction and guide, read 2026-09-04). Verify https://example.com/ and you have not verified https://www.example.com/, http://example.com/, or https://shop.example.com/.
A Domain property removes that whole class of mistake by covering every protocol and every subdomain at once, and it has one way in. Google's own line for the DNS method is short: "Add a DNS record to your domain provider's record list to prove ownership. This is required only for Domain property" (Verify your site ownership, read 2026-09-04).
A URL-prefix property verifies a spelling. A Domain property verifies a domain.
The five methods, side by side
Google lists seven, but two of them are automatic for sites hosted on Google Sites and Blogger, which leaves five real choices. Every row below is a token you place somewhere and then leave alone.
| Method | Where the token goes | Domain property? | Dies when |
|---|---|---|---|
| DNS record | TXT or CNAME in your zone | Yes — the only one | You move registrar and do not copy the record |
| HTML tag | <meta> in the homepage head | No | A theme or layout change rewrites the head |
| HTML file | A file at the site root | No | A rebuild ships without the file |
| Google Analytics | The tag already on the page | No | You lose edit rights on that property |
| Tag Manager | An active container snippet | No | You lose publish rights on that container |
The last two are the ones people regret. They are the fastest to click through, and they attach your access to a second system whose permissions someone else may change without telling you. The first three put the token on infrastructure you already control, which is why they survive staff changes and the other two sometimes do not.
One more thing the table does not show: none of these methods changes how your site is crawled. A verified property is a window, not a lever. Nothing about the site's treatment in search differs before and after the moment you press the button.
How to verify ownership in six steps
The order matters, because step two eliminates most of the table for you.
- Decide what you want data for. One hostname, or the domain and everything under it. If the answer is "everything", you are choosing a Domain property and the method is already decided.
- Check which door you can actually open. Ask yourself which of the four — DNS zone, homepage head, site root, existing container — you can edit today without filing a ticket.
- Add the property in Search Console and copy the token it gives you. Each property gets its own token; they are not reusable across properties.
- Place the token and publish. For DNS, allow for propagation before you press the button — an early press fails and the token stays valid, so retrying costs nothing but time.
- Press Verify, then confirm from outside. Run the matching command in the block below from a machine that is not your build server.
- Add a second method. Verification is per-token, not per-person, and a property with two tokens in two systems survives losing either one.
The token check you can run any time
This is the part worth keeping. Pick the line that matches the method you used, and run it once a quarter or after any redeploy that touches templates.
# HTML tag: is the meta element still in the delivered head?
curl -sL -A 'Mozilla/5.0' https://example.com/ \
| grep -o '<meta[^>]*google-site-verification[^>]*>'
# HTML file: does the verification file still return 200?
curl -s -o /dev/null -w '%{http_code}\n' https://example.com/google1234567890abcdef.html
# DNS: is the TXT record still published?
dig +short TXT example.com | grep google-site-verification
# The record you are looking for, for reference:
# example.com. IN TXT "google-site-verification=YOUR_TOKEN_HERE"The first command fetches the delivered HTML rather than the rendered page. That is deliberate: a verification tag injected by client-side script is a tag Google may never see, and this command shows you what arrives before anything runs.
Three ways verification quietly breaks
None of the three produces an error at the moment it happens. You find out when the data stops.
- You verified the wrong spelling. The property is
https://example.com/, the site serveshttps://www.example.com/, and the report is almost empty. The property is verified and correct — it is just measuring a hostname nobody visits. - A deploy dropped the token. Google is explicit that the token has to stay: "Important: To stay verified, don't remove the DNS record from your provider, even after verification succeeds." The same holds for the file and the tag. Permissions expire after a grace period whose length Google does not publish.
- The borrowed system took your access with it. Verifying through Analytics or Tag Manager means your ownership depends on your rights in that account. And the worst case is spelled out: "If all verified owners lose access to a property, all users will lose access to the Search Console property."
What this chapter cannot tell you is which methods your platform allows. Hosted builders remove some of these doors and the list changes; that constraint is theirs, not Google's. Once you are in, the reports themselves are read in how to read your Search Console data, and the per-page view is in how to read the URL inspection tool. To see what a fetch of your homepage returns before any of this, see how QueryWin reads a page.
Common questions
How long does Search Console verification take?
The check itself is immediate. The waiting is in DNS propagation, which is outside Google's control and varies by provider. Data is a separate wait: the property starts collecting from the day it is verified and does not backfill history.
What is the difference between a Domain property and a URL-prefix property?
A Domain property covers every protocol and every subdomain of one domain. A URL-prefix property covers one exact prefix and nothing else. If you are not sure which you want, you want the Domain property.
Can I remove the HTML file after it verifies?
No. Every method here is checked again over time, and removing the token starts the clock on losing the property. Leave it and forget it.
Can two people verify the same site?
Yes. Several owners can hold separate tokens on one property, and each one is independent. That is the cheapest insurance available here.
Does verifying a site help it rank?
No. It is a permission check, not a signal. Nothing in Google's documentation ties verification to ranking, and we have no measurement suggesting otherwise. What it changes is what you can see.
Does a site have to be verified to be indexed?
No. Discovery and indexing run whether or not anyone has claimed the site, and plenty of indexed sites have no verified owner at all. Verification is what lets you look at the result and submit things by hand.
I verified a subdomain. Does the parent domain come with it?
Not with a URL-prefix property. Verifying blog.example.com gives you that hostname and nothing above or beside it. Cover the whole tree by verifying the domain through DNS instead, which is the same boundary robots.txt uses.
Part of the QueryWin handbook · Level 2
