Google Search Console: The Complete Guide

Google Search Console is a free tool from Google that shows how your website performs in Google Search: which pages are indexed, what queries bring in traffic, and where technical issues are blocking pages from ranking. It draws directly from Google's own crawling and indexing systems, so it's the only place to see search queries, impressions, and click-through rates the way Google actually recorded them, rather than an estimate from a third-party crawler.

Anyone who owns or manages a website benefits from it, from a five-page brochure site to a marketplace with fifty thousand product pages. Search Console tells you what's actually happening: which URLs Google has indexed, which ones it rejected and why, how a redesign changed your rankings, and whether a recent code change quietly broke something Googlebot can no longer crawl. This guide walks through setup, how to read each report without misreading the numbers, and the mistakes that trip up most first-time users.

Setting Up and Verifying Your Property

Search Console organizes data by "property": the site or set of URLs you're monitoring. You get two choices when you add one, a Domain property or a URL-prefix property, and the difference matters more than it first appears.

A Domain property covers every subdomain and protocol at once: http and https, www and non-www, blog.example.com and shop.example.com all roll into a single view. It's the right choice for most standard websites, since it gives you one unified report instead of several fragmented ones. A URL-prefix property locks to the exact protocol, host, and path you enter, which is useful when you specifically need to isolate one section, such as https://example.com/blog/, or when you don't control DNS and can't complete the domain-level verification method.

Verification proves you control the property, and the available methods depend on the property type. A Domain property verifies through a DNS TXT record added at your domain registrar. A URL-prefix property can verify through an HTML file uploaded to the server, an HTML meta tag added to the site's head section, an existing Google Analytics or Google Tag Manager container already installed on the site, or a DNS record if you'd rather use that route anyway. Once verified, keep at least one verification method in place; removing the file or the DNS record later can silently revoke access without any warning.

• Domain property: verify once at the registrar, get every subdomain and protocol in one view
• URL-prefix property: locks to one exact protocol, host, and path
• Verification methods: DNS TXT record, HTML file upload, HTML meta tag, Google Analytics, Google Tag Manager
• Add www and non-www URL-prefix properties too if you want to confirm redirects are configured correctly

Reading the Performance Report Correctly

The Performance report is where most people spend their time, and it's also the most commonly misread. It shows four metrics for every query and page combination Google has data for: clicks, impressions, average CTR, and average position. Clicks count an actual click-through to your site from a Google Search results page. Impressions count each time one of your URLs appeared on a results page a user loaded, whether or not they scrolled far enough to see it. Average CTR is clicks divided by impressions, and average position is the mean ranking position across every impression in the selected date range.

Average position is the metric that causes the most confusion. A page can show "position 4" while actually ranking position 1 for one query and position 12 for another; the number is an average across every query and device that generated an impression, not a single ranking you can point to. Filter by an individual query before drawing conclusions about where a page "ranks." The same caution applies to comparing date ranges: a dip in average position can mean the page genuinely dropped, or it can mean the page started ranking for a wider spread of lower-value queries that pull the average down without any real ranking loss.

The report defaults to Web search and the last three months, but the filters underneath the graph, query, page, country, device, and search type, are where the real analysis happens. Search type lets you split Web, Image, Video, and News results, which matters because a page can perform very differently in Image search than in standard Web results. Search Console keeps performance data for up to 16 months, so year-over-year comparisons are possible directly in the tool without exporting anything to a spreadsheet.

• Clicks: an actual click-through from a Google Search results page
• Impressions: the URL appeared on a loaded results page, regardless of scroll position
• CTR: clicks divided by impressions
• Average position: the mean rank across every impression in the date range, not a single number you can quote as "the" ranking

The Pages Report: What "Not Indexed" Really Means

The Pages report splits every URL Google knows about into Indexed and Not indexed, and the second bucket is where most of the useful diagnostic information lives. A URL landing in "Not indexed" isn't automatically a problem; some of the reasons are entirely intentional.

"Excluded by noindex tag" and "Blocked by robots.txt" usually mean exactly what they say: you told Google not to index the page, on purpose or by accident from a staging-site robots.txt that never got updated after launch. "Alternate page with proper canonical tag" and "Duplicate without user-selected canonical" both point to canonicalization: the first means Google agrees with the canonical URL you declared, the second means you didn't declare one clearly enough and Google picked a different URL to index than the one you intended. "Crawled - currently not indexed" and "Discovered - currently not indexed" are worth watching closest, since they usually signal a quality or crawl-priority judgment: Google looked at the page, or found a link to it, and decided it wasn't worth indexing yet.

Soft 404s and server errors are worth checking on a schedule, not just after a migration. A soft 404 is a page that returns a 200 OK status but whose content looks like an error page to Google, a common outcome of "no results found" search pages or thin category pages with nothing left in stock. Server errors that spike right after a deploy almost always trace back to a hosting or caching change, not an SEO problem.

• Excluded by noindex tag: intentional, or a leftover staging directive
• Blocked by robots.txt: check whether that's actually what you want
• Duplicate without user-selected canonical: declare a canonical tag clearly
• Crawled / Discovered - currently not indexed: often a content-quality or crawl-priority signal
• Soft 404: page returns 200 but reads like an error page

URL Inspection: Debugging One Page at a Time

The URL Inspection tool checks a single URL against two different views: the version currently in Google's index, and a live test that crawls the page right now. The two can disagree, and that gap is diagnostic information in itself; if the live test shows a page as indexable but the indexed version is older or shows a different canonical, it usually means Google hasn't recrawled since your last change.

The tool also shows which canonical URL Google actually selected for the page, separately from the canonical URL you declared in the HTML. When the two don't match, it's a strong signal that something about the page reads as duplicate or low-value content to Google's systems, even if you're confident it's unique. It's also where you find the referring sitemap, the last crawl date, mobile usability status for that specific page, and a rendered screenshot showing what Googlebot actually saw when it loaded the page, including any content that failed to render because of a JavaScript error.

Request indexing from this tool queues the page for a priority crawl, but it isn't a guarantee and it isn't meant for bulk use. It's most useful for a single page after a meaningful update: a new product, a corrected canonical, a fixed noindex tag. Submitting dozens of URLs this way in a short window doesn't speed anything up and can read as a spam signal instead.

Sitemaps and Crawl Stats

An XML sitemap is a list of URLs you want Google to know about, submitted from the Sitemaps section of Search Console. It doesn't force indexing; Google still evaluates every URL on its own merits, but it does help discovery, especially on large or poorly interlinked sites where Googlebot might not find every page by following links alone. Each sitemap file is limited to 50,000 URLs and 50MB uncompressed; larger sites use a sitemap index file that points to several smaller sitemap files.

After submission, the Sitemaps report shows when the file was last read and how many of its URLs made it into the index. A large gap between submitted and indexed counts is worth investigating in the Pages report, filtered to that sitemap, rather than a reason to resubmit the sitemap itself; resubmitting doesn't change how Google evaluates the URLs inside it.

The Crawl Stats report, under Settings, breaks down every request Googlebot made to the site: by response code, by file type, by crawl purpose (discovery versus refresh), and by the specific Googlebot type, desktop, smartphone, image, or video. A sudden rise in 404 or 500 responses here, or a crawl volume that drops off a cliff, is usually the earliest signal of a server or hosting problem, often before it shows up anywhere else.

• Sitemap limit: 50,000 URLs / 50MB uncompressed per file; use a sitemap index for more
• A sitemap aids discovery, it doesn't force indexing
• Crawl Stats: watch response-code trends for early signs of server problems

Core Web Vitals, Mobile Usability, and Other Experience Reports

The Core Web Vitals report groups your URLs into Good, Needs improvement, and Poor based on three field metrics measured from real Chrome users: Largest Contentful Paint (LCP, how long the main content takes to render), Interaction to Next Paint (INP, how responsive the page feels to clicks and taps), and Cumulative Layout Shift (CLS, how much visible content jumps around while loading). Google's published thresholds treat an LCP under 2.5 seconds, an INP under 200 milliseconds, and a CLS under 0.1 as "good."

This data comes from the Chrome UX Report, meaning it reflects real visitors on real devices and connections rather than a single lab test. A page can look fast in a local development environment and still show as "Poor" here if most of its real-world traffic comes from a mid-range phone on a slow mobile connection. Because the report groups similar URLs together instead of listing every page individually, fixing one templated issue, an unoptimized hero image, a web font that blocks rendering, often resolves the status for an entire group of URLs at once.

Mobile Usability flags issues that only matter on small screens, like text too small to read without zooming or clickable elements placed too close together to tap accurately. The Security Issues and Manual Actions reports are worth checking even when nothing seems wrong: a manual action means a human reviewer at Google took action against the site for a policy violation, and it won't show up anywhere except here.

Common Mistakes and a Simple Monthly Routine

The most common mistake is treating average position as a leaderboard ranking instead of an average, covered above. A close second is reacting to a normal seasonal dip in the Performance graph without checking the same period a year earlier; plenty of query volume is seasonal, and the date comparison feature makes that a quick check instead of a guess. A third is submitting a sitemap once at launch and never returning to it, so new sections of the site never get listed for faster discovery.

A workable routine doesn't need to be complicated. Once a month, check the Pages report for any new spike in a "Not indexed" category, especially soft 404s and server errors. Check Core Web Vitals for any group that moved from Good into Needs improvement. Scan the Performance report's query list for new queries the site is starting to rank for, which often reveal content gaps worth addressing. Confirm the sitemap's indexed count hasn't drifted far from its submitted count. None of this takes long once it's a habit, and catching a broken canonical or an accidental noindex tag within a month is a very different outcome than catching it six months later after a slow ranking decline nobody could explain.