Getting Started with Google Search Console and Bing Webmaster Tools: Verification, URL Inspection and Core Reports

Version note: This post is based on the Google Search Console and Bing Webmaster Tools help pages as of November 2026; the code examples were built and run with .NET 10.

Guess First

You've launched Bookstore at https://www.bookstore.example and added a property to Search Console as https://www.bookstore.example/, that is, with a URL (Uniform Resource Locator) prefix. A month later the marketing team opens blog.bookstore.example, and the old http:// addresses still get external links. Which of these three addresses do you think this property shows data for? And one more: do you need to verify from scratch to set up Bing Webmaster Tools?

Two Property Types: Domain and URL-prefix

Everything in Search Console hangs off a property, and there are two types. A Domain property covers the root domain, all subdomains and all protocols (http, https); you enter it as bookstore.example, without protocol and without www. It can only be verified with a DNS (Domain Name System) record. A URL-prefix property covers only URLs that start with the prefix you enter, protocol included: the https://www.bookstore.example/ property sees neither the http:// version nor the blog. subdomain.

That's why the answer to the opening question is "only the first one". Practical advice: as the site owner, set up a Domain property first and see all your data in one place. If you want to track a specific section separately, for example https://www.bookstore.example/en/ for English content, add it as an extra URL-prefix property. If you verify a URL-prefix property through DNS, the matching Domain property is verified automatically.

Verification Methods and Persistence

For a Domain property the only way is to create a TXT (text) record with the value Search Console gives you at your DNS provider. The record can take a day or more to show up. A URL-prefix property has more options: uploading an HTML (HyperText Markup Language) file to the root, adding a meta tag to the home page's <head>, or verifying through Google Analytics or Google Tag Manager.

The rule people miss: verification isn't one-off. Search Console checks periodically that the token is still there; if it can't find it, it warns you, and if the problem isn't fixed your permissions expire after a while. Deleting the DNS record after verification, losing the meta tag in a layout change, or forgetting the file in a new deploy silently ends your access. So if you choose the meta tag method, tie it to configuration rather than code:

namespace Bookstore.Web.Seo;

public sealed class SearchVerificationOptions
{
    public const string SectionName = "SearchVerification";

    public string? Google { get; init; }
    public string? Bing { get; init; }
}

@using Microsoft.Extensions.Options
@using Bookstore.Web.Seo
@inject IOptions<SearchVerificationOptions> Verification
@if (Verification.Value.Google is { Length: > 0 } google)
{
    <meta name="google-site-verification" content="@google" />
}
@if (Verification.Value.Bing is { Length: > 0 } bing)
{
    <meta name="msvalidate.01" content="@bing" />
}

builder.Services.Configure<SearchVerificationOptions>(
    builder.Configuration.GetSection(SearchVerificationOptions.SectionName));

The layout prints this partial only on the home page, because Google looks for the meta tag in the <head> of the non-logged-in home page. In the local test the values are fake tokens:

$ curl -s http://localhost:5481/ | grep -E "verification|msvalidate"
            <meta name="google-site-verification" content="local-test-google-token" />
    <meta name="msvalidate.01" content="LOCALTESTBINGTOKEN" />

Several people can verify the same property with different methods; that's a good backup. Two owners using the same method must not overwrite each other's token. If you work with an agency or consultant, the advice on Google's page about hiring SEO (Search Engine Optimization) help, "Do you need an SEO?", is clear: for an audit, grant read access only, not write access. Full access given to an SEO consultant can, with one wrong Removals request, temporarily take the whole site out of results.

URL Inspection: An X-Ray of a Single Page

The URL Inspection tool shows a URL's status in Google. For the indexed version, these are the fields you'll look at most:

• Google-selected canonical and User-declared canonical: the vote you cast with rel="canonical" and the decision Google made. If they differ, follow the diagnosis path in the sixth post of the series.
• Last crawl and Crawled as: the last crawl date and whether it was crawled as desktop or mobile. All the indexed data comes from this crawl.
• Crawl allowed?, Page fetch and Indexing allowed?: robots.txt permission, whether the page could be fetched, and the noindex status.
• Referring page and Sitemaps: a page that may have led Google to this URL and the sitemaps that contain the URL.

One trap: if robots.txt blocks crawling, "Indexing allowed?" always shows "Yes", because Google can't see the page and therefore can't see a noindex on it. "Yes" here doesn't mean "indexable", it means "I saw no block".

The live test fetches and tests the URL right now, so it can give a different result from the indexed version. Its limits matter: it doesn't check canonical selection, duplicate status, manual actions, or quality and security issues. A "URL is available to Google" result doesn't guarantee indexing. Screenshots exist only in the live test. You can ask for reindexing with Request indexing, but there's a daily quota per property and the request isn't a guarantee either; for many pages the right tool is a sitemap with accurate lastmod values.

The Page Indexing Report

The Page indexing report splits the URLs Google knows into "indexed" and "not indexed" and gives a reason for the ones not indexed. The reasons you'll see most: Crawled – currently not indexed, Discovered – currently not indexed, Duplicate without user-selected canonical, Duplicate, Google chose different canonical than user, Alternate page with proper canonical tag, URL marked 'noindex', Blocked by robots.txt, Soft 404, Not found (404), Page with redirect and Server error (5xx). In the next post we'll go through which of these is a problem and which is expected; for example, after mertozen.com moved to the /en/ structure in November 2026, the old ?lang=en addresses showing up as "Page with redirect" is exactly what you want, because those addresses now redirect to the new URLs with a 301.

After fixing a problem there's a "Validate fix" button. Google first expects every instance to be fixed; if even one remains, validation stops. The process typically takes up to two weeks, sometimes longer, and you shouldn't press the button again in the meantime.

The Performance Report: Clicks, Impressions, CTR and Position

The four metrics of the Performance report are defined like this: clicks, the number of times a user clicked through to your site from Google results; impressions, the number of times your site appeared in results; CTR (click-through rate), clicks divided by impressions; and average position, the average position of your site's topmost result. The report can be broken down by query, page, country, device, search appearance and date; the search types Web, Image, Video and News are separate. The newest data can be preliminary and may change within a few hours.

Know one counting rule when you read it: when you look by property, even if several pages of your site appear for the same query they count as a single impression and the position is the topmost result; when you look by page, every URL is counted separately. That's why CTR and position differ between the property and page views, and it isn't a bug.

AI (Artificial Intelligence) features: according to Google's "AI features and your website" page, traffic from AI Overviews and AI Mode is included in overall Search Console data, under the "Web" search type in the Performance report. Since June 2026 there are also separate generative AI performance reports, opened to all sites as of August 31, 2026. We'll cover what that report shows and doesn't show in the measurement post of the GEO (Generative Engine Optimization) series.

Bing Webmaster Tools: Five Minutes with Import

The shortest way to set up Bing Webmaster Tools is to import from Search Console. On the My Sites page you click Import, sign in with your Google account and grant access; Bing lists your verified sites and their sitemaps, and the ones you pick are added as automatically verified. You can import up to 100 sites at once. Bing periodically rechecks ownership through your Search Console account; if you revoke that access you'll need to verify another way. The alternatives are an XML (Extensible Markup Language) file, the msvalidate.01 meta tag, a DNS CNAME (Canonical Name) record and Domain Connect. Traffic data for a newly verified site can take up to 48 hours.

Why does Bing matter? Beyond its own search traffic, Microsoft Copilot and Bing's AI-powered answers ground on Bing's index, and since February 2026 Bing Webmaster Tools offers an AI Performance report in public preview that shows citations on those surfaces. Details in the GEO series. Bing also supports announcing changed URLs instantly with IndexNow; the implementation is in the "XML Sitemaps and IndexNow" post of the Technical SEO series.

A First-Week Checklist for mertozen.com

Taking this site as the example, here is a short list for the first week after setting up both tools:

Day 1: set up a Domain property for mertozen.com. This single property covers the www and non-www addresses, http and https, the TR pages and the EN pages under /en/ together. If you like, open an extra URL-prefix property for https://www.mertozen.com/en/; it makes it easier to see the English content's performance separately.

Day 1: submit /sitemap.xml in the Sitemaps report. The site's robots.txt already has a Sitemap: line, but submitting shows you the number of URLs read and any errors in the report. Check in the robots.txt report that the file is read without problems.

Day 2: import into Bing Webmaster Tools from Search Console.

Days 2–3: inspect one TR and one EN post with URL Inspection. Is the Google-selected canonical the same as the User-declared canonical? Is the EN post's canonical the /en/blog/... address? Is Crawled as mobile?

Day 7: look at the "not indexed" reasons in the Page indexing report; separate the expected reasons from the unexpected ones. Save the first week's data in the Performance report as a baseline; it's still too early to interpret it.

Ongoing: review the users, give read-only access to everyone for whom read access is enough, and check that email notifications are on.

Production Notes

Make verification tokens part of your infrastructure code. If DNS is managed with a tool like Terraform, keep the TXT record there too, so nobody can delete it thinking "what is this for?".

Think about properties before migrations and restructurings. If your Domain property is ready when you move to a subdomain or a new domain, the data stays continuous. The site migration process is in the "Site Migrations" post of the Technical SEO series.

Export Search Console data regularly. The interface keeps a limited history; for long-term comparisons you'll need to keep the data yourself. Deep analysis and dashboards belong to the upcoming Analytics and Measurement series.

Common Pitfalls

Setting up only a URL-prefix property and never seeing non-www or http traffic. A Domain property closes that blind spot.

Deleting the verification file or DNS record because the job is done. Verification is continuous; when the token goes, the access goes.

Treating Request indexing as a publishing step. There's a quota and no guarantee; an accurate sitemap and internal links are the real discovery path.

Reading the live test's "available" result as "indexed". The live test doesn't check canonical or quality.

A Small Experiment

★☆☆ Check which property type you use for your own site; if it's URL-prefix, add a Domain property and compare the total clicks of the two properties.

★★☆ Extend SearchVerificationOptions: in production, log a warning at startup if the Google token is empty. Use options validation with ValidateOnStart.

★★★ Pick ten random URLs from your site's sitemap and write down, in a table, the "Google-selected canonical" for each from URL Inspection. In how many is it the same as your canonical?

The tools are set up. In the next post we'll use them for the question you'll open them with most often: a step-by-step diagnosis tree for "why isn't my page indexed?".