Google Search Console is free and set up in three steps: create the property, verify ownership, submit the sitemap. The only step that takes any thought is the first one. A domain property covers every subdomain and both protocols but needs a DNS TXT record; a URL prefix property only captures URLs matching that exact prefix including the protocol, and offers many verification paths in return. Correcting that choice later is painful: a new property never backfills data from before it existed. For a freshly created property Google says data "should begin to appear in your property in a few days"; later on, the regular report data normally runs two to three days behind collection. Confuse those two deadlines and you will treat an empty report on day three as a fault. And then comes the part where most people take the wrong turn: impressions are not visitors, average position is a mean across very different queries, and the query table never shows every search term, for privacy reasons.
I run my business as a solo freelancer with a workforce of AI employees built on Claude, and Search Console is where everything measurable starts for me. How the whole concept is built is on Hiring AI Employees; how these numbers turn into an audit is in How to Run an SEO Audit With AI. This post is about the beginning: set it up, submit the sitemap, and read the numbers the way they are meant.
Domain property or URL prefix: the decision up front
Google offers two property types, and they measure different things.
Google states the narrow scope of the URL prefix property explicitly: it "includes only URLs with the specified prefix, including the protocol". If your site serves both http and https, you need a separate property per protocol. Hence the classic mistake: someone creates http://example.com/, later moves to https, and the property measures almost nothing from the migration day onward, without a single error message.
My recommendation, if you can reach the DNS zone: use the domain property. It survives a protocol switch, a move from example.com to www.example.com, and every new subdomain. The price is one DNS record, a one-off five minutes at your domain registrar. Without DNS access, take the URL prefix property in the exact notation your site runs under. Both in parallel is allowed: the domain property as the overall view, a URL prefix property on https://example.com/blog/ for a single area. Converting one into the other afterwards is not possible, the second property starts at zero. So make the decision once, calmly, instead of twice, quickly.
Verifying ownership, and what trips people up
Verification proves to Google that the site is yours. The routes differ in durability.
The most important pitfall is written right into Google's help and still gets overlooked constantly: do not remove the verification token after verifying. On the DNS record Google says literally that you should not remove it "even after verification succeeds, to maintain verification", and it checks regularly whether the token is still valid. If it disappears, you lose ownership and with it access to your reports. It mostly happens during cleanups of old DNS records, or in a relaunch that replaces the <head>.
Also, do not rely on Analytics or Tag Manager alone: both hang off a third tool and the same Google account. Whether a consent manager interferes depends on how it is installed. If it blocks the snippet before consent, verification can wobble; if it loads the snippet regardless, it does not. The DNS record is the most stable anchor.
And stay the verified owner yourself. Anyone who should read along is added under Settings as a user, not as a second owner: up to 100 users per property are possible, and only an owner can add or remove them. Grant the smallest level that covers the job.
Submitting your sitemap
A sitemap is an XML file listing your URLs, and most systems generate one automatically at /sitemap.xml. The flow in Search Console:
- Check it is reachable. Google recommends testing the sitemap URL first with the live URL test: the fetch must come back "Successful", and the file must not sit behind a login.
- Open the Sitemaps report, paste the tested URL under "Add a new sitemap", click Submit. The fetch normally happens immediately.
- Check the status. If it does not say Successful, open the row and you see the specific error.
- Also add it to robots.txt, with a line like
Sitemap: https://example.com/sitemap.xml. That is your second route, independent of any account.
The limits: 50 MB uncompressed or 50,000 URLs per sitemap; beyond that you split the file and point to the parts from a sitemap index file.
And set your expectations right away: Google's own documentation says that submitting a sitemap "is only a hint: it doesn't guarantee that Google will download the sitemap or use the sitemap for crawling URLs on your site". Even after a successful fetch, crawling can take a while and may not cover all URLs. A sitemap speeds things up and adds structure, it does not force anything.
What the numbers actually mean
The performance report shows four values, and three of them get misread routinely.
Impressions are not visitors. Google defines an impression as how often a user saw a link to your site on Google, and the detailed documentation adds the decisive word: potentially saw. It counts as soon as your element is present on the current results page, regardless of whether anyone scrolled to it; carousels and infinite scrolling are the exception. So 10,000 impressions only means: your link sat on a results page 10,000 times.
Average position is a mean, and a double one at that. For each query Google takes only the topmost position one of your pages reached, then averages across all queries. Google's own example: query 1 returns 2, 4 and 6, the 2 counts; query 2 returns 3, 5 and 9, the 3 counts; that makes (2 + 3) / 2 = 2.5. So a single-digit average position does not mean "roughly page one": it can come from position three for a dozen niche terms and position forty for your main term. A result without an impression does not enter the statistic at all. The value is an impression-weighted mean across very different queries, not a ranking of your website; Google itself calls it "a complex metric that can be misleading if you don't understand the subtleties".
That is why position and click-through rate are only read together, and even then as a hypothesis. A good position with a very low click-through rate can mean your title does not promise the answer being looked for. It can just as well come from SERP features above you, the device mix, the country, or queries the result page already answers. A poor position with a high click-through rate often points to brand queries. Both patterns tell you where to look, not why.
The report does not show every query, and that is deliberate. Very rarely issued queries count as anonymised queries for privacy reasons and never appear in the table. Google's current help publishes no threshold for this; a Google blog post from 2022 described them as queries that "aren't issued by more than a few dozen users over a two-to-three month period". That is a 2022 characterisation, not a confirmed rule for 2026. They are included in the chart totals, unless you filter by query. On top of that comes the second truncation: the interface exports at most 1,000 rows, while the API serves up to 50,000 rows per day and search type. So if the sum of your table rows does not match the total in the chart, nothing is broken.
How much stays hidden shows in an analysis of my own website from 19 September 2026: Sebastian pulled an API export of query by page, truncated at 5,000 rows, containing 4,770 distinct queries. Of those, 205 ran to more than one of my own pages, accounting for 11,536 of 132,781 impressions, or 8.7 per cent of that measured set. You do not see the pattern in the default 1,000-row view, it only emerges when you group query and page together. And the actual finding came from fetching the pages: a strong overview page simply did not link to the more specific target page for the same query. Search Console data tells you where to look. What to do, you only see on the page itself.
Reading the first weeks without mistaking noise for signal
The most common misuse is not technical, it is about timing: too early, too granular, too eager to interpret.
- Expect a delay, and mind the time zone. Between collection and visibility Google says data should normally be available after two to three days, and the last days in the chart can be preliminary. A drop at the right edge is usually an unfinished day. Data is grouped in Pacific Time, which is why it never matches your web analytics exactly.
- Switch granularity to weekly or monthly. Daily data from a small website is almost entirely noise. Weekly values smooth out weekend and holiday effects and make trends visible in the first place.
- In weeks one and two, look at status, not clicks. Is the sitemap being processed successfully? How many pages does the indexing report list as indexed, and why not the rest? Those are findings that hold immediately.
- Never compare without a date. A before-and-after is only a measurement if you know when the change went live. Write down the date of every change, or in six weeks you will have a curve and a hunch.
- Export early. Performance data goes back 16 months and then disappears. A monthly export costs two minutes and, a year from now, is the only source you still have.
The employee who runs these accounts without changing anything in them
Search Console is quick to set up. What tends to be missing in practice is someone looking at it regularly, separating the signals from the coincidences, and keeping the results. So at my place it is a standing role.
Sebastian, my AI employee for SEO and GEO, prepares the setup, reads the reports afterwards, and files every raw output in a dated job folder so each finding can name its source later. The setup itself I approve beforehand: a DNS record and a new ownership change the state of your domain and your account. Only the reading afterwards is free. For accounts that are not his own he follows a hard rule, and I would recommend it to you too whenever a service provider manages your Search Console: read-only, and nothing submitted without approval. You stay the verified owner, the provider gets a user role. Sitemap submissions, removal requests and indexing requests are interventions in your visibility, and you decide on those.
This role additionally measures AI search, because it has a metric of its own: not position, but citation. How that fits together is in Generative Engine Optimization (GEO) Explained; which tool besides Search Console delivers real data is in SEO Audit Tools Compared.
Frequently asked questions
What does Google Search Console cost?
Nothing. It is free for every site owner, with no usage cap and no paid tier. All you need is a Google account and verified ownership. The Search Console API, which you use to export beyond the 1,000 rows of the interface, is free as well. The same goes for Bing Webmaster Tools.
Why do I see no data after setting it up?
Because none has been collected yet. Search Console does not backfill data from before the property was created. For a newly added property Google says data "should begin to appear in your property in a few days"; with a new website, plan for a good week. The two to three days are something else: the running delay on an established property.
Do I have to submit a sitemap for Google to find my pages?
No, Google also finds pages through links. A sitemap still helps, especially with new, large, or poorly interlinked websites. Google explicitly calls submitting one a hint rather than a guarantee: there is no assurance that the sitemap will be downloaded or used for crawling.
Does Search Console improve my ranking?
No. It measures and reports, it does not intervene in search. What it gives you are findings: which pages are not indexed and why, which queries you appear for, where impressions arrive without clicks. The improvement happens afterwards on your website, in the order that counts for a small business, and whether it worked shows up in the same Search Console at the follow-up measurement.
What to do next
Do the three steps today: create the domain property, verify it with a DNS TXT record, submit the sitemap URL and also write it into robots.txt. That is half an hour. Then set a reminder four weeks out, and until then look only at the indexing report, not the click curve. After four weeks, pull the two lists that actually matter: queries with many impressions and few clicks, and queries where several of your pages appear at the same time.
If you do not want to keep that rhythm yourself, the role is more interesting than the tool. How my employees are built and work together is in the org chart. And if the DNS record is the part you dread: that is the step most questions in my community are about, usually with a screenshot from the provider's own interface. The templates for the monthly rhythm are there too.
