What is Google Search Console and how to add your site.

Google Search Console is a free service from Google that lets you monitor your site’s status in Google Search, see its problems and fix them. To add a site, you create a property, verify that the site belongs to you and submit a sitemap; the first data starts arriving within a few days.

Search Console is the only place where the correspondence between your site and Google can be read. It shows you which page is in Google’s index, which one was left out and why, how many times the site was shown for which searches and how many times it was clicked. Registering is not required to appear on Google; Google says so clearly. But without it, there is no way to notice a problem when one appears.

Setup requires no technical knowledge and takes an afternoon. The only difficult step is verification, and that usually amounts to adding one line in the control panel of the company you bought your domain from. This guide walks through the steps in order. If you need support after setup to read the reports or fix the problems they reveal, SEO consulting starts precisely with these reports.

In whose name should the Search Console account be opened?

In the company’s own name. Search Console has two roles: owner and user. An owner manages everything and can add and remove other people; users work with full or restricted view rights and cannot add anyone. Our recommendation is that verified ownership sit on a permanent Google account belonging to the company, and that the person who built the site or the consultant be given access as a user or an additional owner.

There is a practical reason for this: when you part ways with the person who built the site and that person is the only owner, the site has to be verified again to access the reports. If ownership sits with the company from the start, access is never lost in any separation; and the company decides who can access the site.

Domain property or URL-prefix property?

In Search Console a site is called a “property,” and there are two types. A domain property gathers all subdomains and all protocols of the domain into a single view: addresses with and without “www,” on “http” and “https,” all appear in the same report. A URL-prefix property covers only addresses that exactly match the prefix you enter, including its protocol.

The difference shows up in verification. A domain property can only be verified with a DNS record; a URL-prefix property has several verification methods. If you can access your domain’s DNS settings, a domain property is usually the better choice, because none of the address variants slips through. This site’s record shows how much that matters: on 22.08.2026 Google knew 93 addresses for this site, while the site had 58 pages. The difference was variants without “www,” with “http,” without a trailing slash and ending in “/index.html.” Seeing them all in the same view was the precondition for consolidating them all into a single address.

How do you add a site to Search Console?

• Sign in to Search Console with your Google account.
• Open the property selector and click “Add property.”
• Choose the property type: domain or URL prefix.
• Choose the verification method; for a domain property this is a DNS record (TXT or CNAME).
• Add the record in your domain provider’s control panel and press “Verify”; if you like, you can save the verification and come back later.
• It takes a few days for data to start arriving; seeing an empty report during this time is normal.

If verification fails on the first try, there is no need to panic. Google writes that it can take anywhere from a few minutes to a few days for the DNS record to become visible to it, and recommends waiting a day or two and trying again. Do not delete the DNS record after verification either: Google states that verification will be lost if the record is removed.

How do you submit a sitemap?

Once the property is verified, open the sitemaps report in the left-hand menu, enter your sitemap’s address and submit it. A sitemap is the file that gives Google the list of pages on the site; most content management systems generate it automatically. The report shows whether the sitemap was read and how many addresses were found in it. We explained separately how the sitemap is built and the causes of the “couldn’t fetch” warning in the sitemap guide.

Which reports should you look at in the first week?

• Performance — how many times the site was shown on Google (impressions), how many times it was clicked, the click-through rate and the average position. The default view shows the last three months; data for the most recent days may be preliminary and can change within a few hours.
• Page indexing — how many pages are in the index, how many are outside it and the reason for each. Some of the “not indexed” rows are expected states; you have to read them row by row to see which one is a problem.
• URL Inspection — whether a single address is on Google, the canonical address Google chose for that address and whether crawling succeeded. You can also request a recrawl from here; Google states that this has a daily limit and does not guarantee indexing.
• Enhancements and rich results — whether the structured data on the pages (breadcrumbs, profile page and so on) is valid.

The first two of these reports answer most of the question of whether the site appears on Google. Among the not-indexed rows, “Crawled - currently not indexed” deserves extra attention; we explained what it means in a separate guide. When the site does not appear at all, the guide to a site not showing up on Google gathers what each row points to under nine headings. How to read the average position is the subject of the guide to checking where you rank.

What do you do if Search Console shows a structured data warning?

First-hand evidence: two structured data warnings appeared in this site’s Search Console reports, and both pointed to a real defect in the site’s own code. The first was in the profile page report: the dateModified field, which carries the page’s “when was this last changed” information, contained only a date, with no time and no time zone. Search Console flagged this as an “invalid datetime.” The fix was to make the field carry a full date and time with a time zone (23.09.2026).

The second was in the breadcrumb report: the name of one link in the trail was empty. The fix did more than repair that page; since that day this site’s generator stops the build whenever a breadcrumb trail has an unnamed link, so the same defective page can never go live again. Today’s pages do not have this defect; if it still appears in the report, it is a record from an old crawl and is closed by starting validation of the fix in the report.

The lesson is this: structured data does not change how the page looks, so when it breaks, no one notices. These Search Console reports are the first place to tell you about the breakage. We explained how the warnings are worked through in the structured data debugging guide, and how we test our own schema in an article.

Search Console does not show your site to Google; it shows you how Google sees your site.

What does Search Console not show?

Search Console shows only the status in Google Search. It does not see what visitors do after entering the site; that is the job of visitor analytics tools. It does not show the status in other search engines; they have their own tools. Nor does it show your competitors’ data: you see only the data of the property you have verified.

How often should you check Search Console?

There is no need to check every day; daily fluctuation is mostly noise. The moments to check are clear: after a major change to the site, after new pages are published, after a redirect or domain change, and otherwise at a regular interval. What matters is that every reading is done with the same window length and written down somewhere.

On this site readings go into a dated log: the first reading on 22.08.2026 was saved as a baseline, and the reading on 23.09.2026 was compared with it. The only reason we can talk about the difference between them is that the first reading was recorded.

And a note on expectations: Search Console shows a problem; it does not solve it. A row in the report says “this page is not in the index”; understanding the reason and fixing it is a separate job. That is why the first task after setup is to read the reports once from start to finish and record the site’s current state as a baseline. The effect of every later change is read against that baseline.

If you want to find out together why your site doesn’t show up on Google, SEO consulting audits every layer from crawling to indexing and makes the fix in the source code.