There is one tool that shows you what Google actually does with your website: which pages are in the index, which search terms you appear for, at what position, and where Google fails to read your site. It comes from Google itself, it costs nothing, and a surprising number of small sites have never set it up. Google Search Console.
Analytics tells you what visitors do on your site. Search Console tells you how they get there in the first place, and whether they can. The two answer different questions, and for anything to do with visibility, Search Console is the more important one.
What you need before you start
Three things, no more: a Google account, your website's address, and some form of access that lets you prove to Google that the domain is yours.
Do not use an account that belongs to an agency or to one individual employee. The property hangs off that account, and moving ownership later is a chore. An account that will still be yours in two years is worth more here than the one you happen to be signed in with.
Which verification route you take depends entirely on where you have access: to the domain's DNS settings, to the server's file system, or to the head section of your pages. You almost always have one of the three.
Creating the property: the fork that decides everything after it
Open search.google.com/search-console and sign in. The first time, the Select property type dialog appears right away, with two boxes side by side: Domain on the left, URL prefix on the right. If you already have a property, the same dialog sits behind the selector at the top left, under Add property.
The domain property covers the whole domain, including every subdomain and both protocols. It is the right choice, but it requires you to add a so-called TXT record with your domain provider. That sounds more technical than it is: you copy a string Google gives you into your domain's DNS settings, wait a few minutes, click verify. For this property type there is no other route.
The URL prefix property covers exactly one address, say https://your-domain.com. It is quicker to set up because you get four verification methods to choose from: a file, a meta tag, Google Analytics or Google Tag Manager. The catch: if people reach your site with www in front and you only verified the version without it, you miss half the data.
Take the domain property if you can reach the DNS settings. The TXT record is work once and never a concern again. If you cannot get at DNS — because some provider manages the domain and takes three weeks to answer an email — then a URL prefix property today beats a domain property eventually.
One note that saves you trouble later: whichever method you pick, the proof has to stay in place. Google rechecks it at intervals. Delete the record, file or tag after confirming and you lose the property, and with it access to its data, after a while.
Method 1: DNS record (for the domain property)
The route for the domain property, and the only one that covers every subdomain and both protocols at once.
- In the Select property type dialog pick Domain on the left, enter the domain without
https://and withoutwww— soyour-domain.com— and click Continue. - Google now shows a box with a line starting
google-site-verification=, and a Copy button next to it. That line is your TXT value. - In a second tab, open your domain's DNS management. It sits with whoever provides the nameservers — not necessarily with whoever sold you the domain.
- Create a new record of type TXT. The Name or Host field takes
@or is left empty; both stand for the domain itself, and your provider's interface will tell you which one it wants. The Value field takes the copied line, complete and unchanged. Leave TTL on its default. - Save, wait five to ten minutes, go back to Search Console and click Verify.
Where the setting hides at the usual providers: Cloudflare under DNS → Records → Add record, GoDaddy under My Products → DNS, Namecheap under Domain List → Manage → Advanced DNS, IONOS under Domains & SSL → Domain → DNS. The labels change every few years, the principle does not: you are looking for the list of DNS records and adding one more.
The most common stumbling block with this method: the domain was bought at provider A, but the nameservers point at provider B — typical with Cloudflare, or when the web host took over DNS. Any record you add at A then goes nowhere, because nobody serves it. A whois lookup tells you who holds the nameservers, or in a terminal:
dig NS your-domain.com +short
Do not delete existing TXT records while you are in there. A domain root can carry several side by side, and the SPF record your email depends on is one you want to leave alone.
Before you click verify in Search Console, check for yourself whether the record has propagated:
dig TXT your-domain.com +short
On Windows, nslookup -type=TXT your-domain.com does the same job. If your google-site-verification= line shows up in the output, verification will work. If it does not, clicking will not help — wait and look again in an hour.
Method 2: HTML file on the server
Google's recommended method for a URL prefix property, and the most reliable one if you can reach the server.
- Pick URL prefix on the right and enter the address exactly as your site is served, including
https://and including or excludingwww. To Google,https://www.your-domain.comis a different property fromhttps://your-domain.com. - Google opens the list of methods. At the top, already expanded, sits HTML file. Clicking Download file drops a file named something like
google1a2b3c4d5e6f7g8h.htmlinto your downloads folder. - Upload it unchanged to your website's root directory. On classic hosting that is the folder holding your home page — depending on the provider,
httpdocs,public_htmlorwww. On WordPress it is the installation directory; on Next.js it is thepublic/folder. - Open the file in a browser, so
https://your-domain.com/google1a2b3c4d5e6f7g8h.html. You should see a blank page with a single line startinggoogle-site-verification:. - Back in Search Console, click Verify.
Where it goes wrong: nearly always with the file not being served the way it should be. Single-page applications and some content systems redirect anything they do not recognize to the home page. Google then sees your layout instead of the string and reports a redirect. Renaming is out too — the file name is part of the proof. And uploading the file into your CMS media library rather than the root leaves it at an address Google never looks at.
Method 3: HTML tag in the head
The route without file access: one line in your home page's source.
- Create the URL prefix property as above, then expand HTML tag in the method list. Google shows a line of the form
<meta name="google-site-verification" content="..." />and a Copy button. - That line belongs inside the
<head>of your home page, anywhere before</head>. On WordPress every SEO plugin has a field for it — Yoast under SEO → General → Site connections, Rank Math under General Settings → Webmaster Tools. Without a plugin it goes into the child theme's header template, never the parent theme, or the next update takes it with it. Builders like Wix, Squarespace and Webflow have a custom-head-code field in their project settings. - Publish, load the home page, open the source with Ctrl + U or Cmd + Option + U and search for
google-site-verification. If it is there, click Verify in Search Console.
On Next.js with the App Router you do not have to write the tag by hand; the Metadata API knows the field:
export const metadata = {
verification: { google: "your-verification-value" },
};
You enter only the contents of content="...", not the whole tag.
Where it goes wrong: the tag has to be in the <head>, not the <body>, and it has to be in the source the server delivers. If it is injected later by JavaScript, the verifier will not reliably see it — it reads the HTML the server sends. The second classic is caching: a plugin or CDN is still handing out the old version. If the search in the source finds nothing, clear the cache first and look again.
Method 4: Google Analytics
If your site already carries GA4 with the gtag.js snippet in the head, this is the fastest route: no record, no file, one click.
- Create the URL prefix property, expand Google Analytics in the method list, click Verify.
- That is it — provided three things hold: you are signed in with the same Google account that has at least the Editor role on the GA4 property; the snippet sits in the
<head>of the home page; and it belongs to the same domain you are verifying.
Where it goes wrong: if Analytics is loaded through Google Tag Manager, the verifier finds no snippet in the source — then use method 5. A consent banner that only loads the Analytics code after acceptance rules this route out as well. That is not a fault on your site, just the consequence of a verifier that clicks nothing.
Method 5: Google Tag Manager
- The container code has to be on the home page: the
<script>part in the<head>, the<noscript>part right after the opening<body>. - Your Google account needs Publish permission on that container. Read or edit is not enough.
- Expand Google Tag Manager in the method list, click Verify.
Where it goes wrong: usually on exactly that permission, or on a container that was created but never published. A container still in draft delivers nothing on the website, however finished it looks inside the GTM interface.
Submit the sitemap so Google does not have to guess
Once the property is verified, you submit your sitemap. Click Sitemaps in the left menu, enter the path in the Add a new sitemap field and click submit. The field takes only the part after the domain, so sitemap.xml — the address in front of it is already there.
Which path you enter depends on the system: WordPress has served wp-sitemap.xml out of the box since version 5.5, with Yoast it is sitemap_index.xml, and most other systems and builders use sitemap.xml. You check whether the file exists by opening it in a browser. Right after submitting, the table still says the sitemap is being fetched; a few hours later the status flips to Success and the number of discovered URLs appears beside it.
The sitemap does not force Google to index everything at once. It is a map, not an order. But it speeds up the point where new pages get found at all, and that is exactly what matters for a site that is only just building out its content. If you want the reasoning behind why topical breadth matters, it is in finding SEO problems.
When verification fails: the messages in plain language
Google does tell you what went wrong, but in a sentence that never names the cause. The translation:
The required TXT record was not found. Either it has not propagated yet — then wait — or it is in the wrong place. Check with dig TXT your-domain.com +short whether it is served at all. If nothing comes back, your record sits with a provider that does not manage this domain's DNS. The second most common cause: the Name field holds your-domain.com instead of @, which files the record under your-domain.com.your-domain.com.
The verification file was not found. Open the address yourself in a browser. A 404 means the file is not in the root. Your home page means a redirect caught it. If you see the string but Google does not, a firewall or security plugin may be blocking Google's crawler.
The verification file was redirected. The server answers with a redirect instead of the file. Typical for applications that send every unknown address to the home page. Use the meta tag method instead here.
The meta tag was not found. Open the home page source and search. Not visible there: clear the cache. Visible but sitting below </head>: move it up.
No permission for this Google Analytics property. You are signed in to Search Console with a different account than the one in Analytics, or your account only has read access there.
No message at all, but nothing gets verified either. Leave everything in place. Google keeps checking in the background, and plenty of properties verify themselves within a day. The mistake now would be deleting the proof and starting over. And you are allowed to leave several methods in place at once — it raises the chance that one of them lands, and it costs nothing.
Five mistakes you only notice weeks later
The worse mistakes are not the ones that produce a red message. They are the ones where everything appears to work.
Only one domain variant verified. If you use the URL prefix property and only confirm https://your-domain.com, you see nothing of the visits over www or http. The domain property avoids this because it covers every variant at once.
Removing the verification proof later. The TXT record, the file and the tag all have to stay. Delete the record during a tidy-up, or switch out the plugin that served the tag, and you lose verification after a while, and with it access to the data.
Entering the sitemap with its full address. The sitemap field takes just sitemap.xml, not the complete URL. If the path is wrong or the file does not exist, Google reports "Couldn't fetch" — check your-domain.com/sitemap.xml in a browser first.
The property belongs to the wrong account. If the agency verified with its own account, your access ends when the engagement does. Verify once yourself with an account you own, and invite everyone else as users.
Never looking at it again after setup. Search Console emails you when something breaks — but only to the owner's address on file. Check under Settings → Users and permissions whether that is an address somebody actually reads.
Giving others access without handing over your account
Under Settings → Users and permissions → Add user you add further Google accounts. Two roles are on offer: Full may do everything except manage users, Restricted may read most reports. For an agency or a developer, Full is enough.
What you should not hand out is ownership. You do not become an owner by invitation anyway, but by verifying yourself — which is exactly why the proof you placed above is the real title deed to this property.
The report that sits above all the others
If you could only open one report in Search Console, it would be the page indexing one. It splits your pages into two piles: indexed and not indexed. And for the second pile, it states the reason.
This is where Search Console beats every other SEO tool. A crawler guesses why a page does not rank. Search Console writes it down for you: "Excluded by noindex tag", "Alternate page with proper canonical tag", "Crawled, currently not indexed". Each of those phrases points at a concrete problem you can fix. Anyone who crawls instead is looking for the answer inside their own site while Google already noted it down.
Work through the three most common reasons in the not-indexed pile before you open any other tool. How to sort the findings by impact is in finding SEO problems.
The performance report: where your real chances are
The second indispensable report is called Performance. Here sit the queries you appear for, with impressions, clicks and average position.
The gold seam in it: filter position to the range between 4 and 15 and sort by impressions. Those are pages Google already considers relevant but that sit just below the click zone. They need no benefit of the doubt anymore, only a better answer. Why that particular range is the cheapest lever for more visitors is in increasing website traffic.
How to put those queries next to what people then do on the page — intent from Search Console, behavior from Analytics — is in analyzing user behavior.
Getting a single page checked right away
One tool in Search Console that gets used too rarely: URL inspection, in the search bar at the top. You enter the address of a single page and get its current status within seconds: whether it is indexed, when Google last visited it, and whether there were problems reading it.
The practical use comes when you have published a new page and do not want to wait for Google to find it on its own eventually. After the inspection a button appears, "Request indexing". One click puts the page in the queue, and it is often in within a day or two rather than weeks. Do not overdo it, the quota is limited, but for the two or three important new pages it is exactly the right tool.
A word on patience
A freshly verified account shows little at first. The data fills over days, the index report sometimes takes a week to show a complete picture. That is not a fault and not a reason to check three times a day. Set it up, submit the sitemap, and look again in a week.
Where to start
Create a domain property, set the TXT record with your domain provider, verify. Submit the sitemap. Then wait a week and open the page indexing report. What sits in the not-indexed pile is your first to-do list, and it comes straight from the source that matters.
Frequently asked questions
Is Google Search Console free?
Yes, entirely, with no feature held back. There is no paid tier, no user limit and no cap on the data. One Google account manages up to 1,000 properties, which is more than enough for any small or mid-sized site.
How long until data shows up in Search Console?
The performance report runs about two to three days behind, so the first rows appear a few days after verification rather than immediately. The page indexing report takes longer, often a week, before it shows a complete picture of your pages. There is no backfill for the time before you verified.
Domain property or URL prefix — which is better?
The domain property, if you can reach your domain's DNS settings. It covers every subdomain and both protocols at once, so no visits fall through the cracks. The URL prefix property is worth it when you have no DNS access, or when you genuinely want to watch only one section, such as a single subdomain.
What do I do when verification fails?
First check whether the proof is being served at all: the TXT record with dig TXT your-domain.com +short, the verification file and the meta tag by opening them in a browser. If nothing arrives there, the cause is DNS propagation, the wrong provider, a redirect or a cache — not Google. Do not delete the proof after a failed attempt: Google keeps checking in the background, and you may leave several methods in place at the same time.
Do I need Search Console if I already have Google Analytics?
Yes, the two measure different things. Analytics starts counting once somebody arrives on your site. Search Console shows what happens before that: which query put you in front of somebody, at what position, and which pages Google never took into the index at all. That earlier stage is fundamentally invisible in Analytics.
Does the verification proof have to stay in place permanently?
Yes. Google rechecks at intervals whether the TXT record, file or meta tag is still there. If the proof disappears — during a DNS tidy-up, in a relaunch, or along with the plugin that served the tag — you lose verification after a while, and with it access to the property and its history.