What Google Search Console is and why it is indispensable
The most underused free tool in technical SEO is not a crawler, a backlink analyser, or an on-page plugin. It is Google Search Console. Most professionals have it set up, but remarkably few consult it with the depth it deserves. According to data compiled by Ahrefs in 2025, fewer than 30% of verified GSC site owners actively review their indexing reports more than once a month.
Google Search Console is the direct interface between your website and Google. It is the only data source that tells you exactly which queries generate impressions and clicks to your site, which pages are indexed and which are not, which crawl errors Googlebot has encountered, and how your pages perform on Core Web Vitals measured with real Chrome user data. No paid tool, however sophisticated, has access to these data points: they are exclusive to Google.
GSC traces its origins to Google Webmaster Tools, launched in 2005. It was rebranded as Google Search Console in 2018 with a redesigned interface, and since then it has added Core Web Vitals reports, page experience data, and advanced features such as the URL Inspection API. For any technical SEO professional, GSC is where every audit begins. Before opening Screaming Frog, before configuring a Sitebulb crawl, before parsing server logs, the first question should always be: what is Google seeing? And that question can only be answered from Search Console.
If you are conducting a technical SEO audit, GSC provides roughly 60% of the diagnostic data you need before turning to third-party tools. The difference between GSC data and third-party data is fundamental: GSC shows real data from Google — real impressions, real clicks, average positions calculated by Google, indexation statuses determined by Googlebot. Third-party tools estimate these data through sampling and statistical modelling. For critical technical decisions — such as determining whether an entire site section is being indexed correctly — GSC data is the source of truth.
Understanding this distinction is particularly important when diagnosing sudden traffic drops. A third-party tool might show a ranking change; GSC shows whether the drop is due to fewer impressions (visibility issue), a lower CTR (snippet issue), or pages being removed from the index entirely (technical issue). Each diagnosis leads to a completely different remediation path.
How to set up Google Search Console from scratch
Setting up Google Search Console is a three-step process that, when executed poorly, creates data gaps you may drag along for months without realising. The first step is choosing the correct property type, and this is where most mistakes happen before anything else has begun.
Google offers two property types: domain property and URL-prefix property. A domain property automatically covers all subdomains, all protocols (HTTP and HTTPS), and all URL variants under a single domain. A URL-prefix property covers only the exact URL you specify: if you verify https://www.yourdomain.com, you will not see data for https://yourdomain.com or http://www.yourdomain.com. For most sites, the domain property is the correct choice because it provides a consolidated view of all data.
Domain property verification requires DNS access. You need to add a TXT record that Google provides during the setup flow. This method is the most robust because it does not depend on files on the server that can be lost during migrations or deployments. Google’s Search Console Training documentation details each verification method step by step.
Once the property is verified, the second critical step is linking Google Search Console with Google Analytics 4. This integration allows you to cross-reference organic acquisition data (GSC) with on-site behaviour data (GA4) — a combination that reveals not only which queries drive traffic but which queries drive conversions. Without this link, you operate with two isolated data sources telling incomplete stories.
The third step, which many skip, is submitting the XML sitemap. Although Google can discover pages without a sitemap through links, the sitemap significantly accelerates discovery of new URLs and gives GSC additional data about update frequency and relative page priority. The sitemaps section in GSC also surfaces processing errors that indicate technical problems in your sitemap file.
A frequent setup mistake is failing to add all relevant users with appropriate permissions. GSC supports three access levels: owner (full control), full user (read all data and use all tools), and restricted user (partial read). For SEO, development, and marketing teams working in parallel, establishing correct permissions from the outset prevents repetitive access requests and ensures every team has visibility into the data they need.
Performance report: queries, clicks, and impressions
The Performance report is by far the most consulted section of Google Search Console — and also the most frequently misinterpreted. The confusion begins with the most basic metric: impressions.
An impression in GSC does not mean a user saw your result. It means your URL appeared on a search results page that was loaded by a user. If your result sat at position 47 and the user only saw the top 10, GSC still counts an impression. This definition has direct practical implications: a high impression count with low CTR does not necessarily indicate a snippet problem; it may simply mean your average position is too low to earn clicks.
The four metrics in the Performance report are: total clicks (times a user clicked your result), total impressions (times your URL appeared in results), average CTR (clicks-to-impressions ratio), and average position (weighted average of your result’s position across all queries). These metrics can be filtered by query, page, country, device, search appearance, and date range.
The real value of the Performance report lies in cross-analysis. Filtering by a specific page and sorting queries by impressions reveals which searches Google considers that page relevant for. If you see queries that do not match the page’s content, you have a search intent or cannibalisation problem. If you see relevant queries with many impressions but few clicks, the meta title or meta description may need optimisation.
According to Google’s official documentation, the Performance report retains data for the last 16 months. This enables seasonality analysis and year-over-year comparisons that are impossible with third-party tools that do not store historical data. For technical SEO, period comparison is especially useful after infrastructure changes: CMS migration, server change, CDN implementation, or URL architecture update.
A pattern experienced professionals actively look for is divergence between impressions and clicks. If impressions grow but clicks stagnate, it may indicate Google is showing your content for increasingly broad queries — a sign of growing topical authority — but your average position is not high enough to earn clicks. Alternatively, it may suggest a competitor has improved their snippet and is capturing clicks that were previously yours.
Indexing report and coverage: detecting excluded pages
If the Performance report tells you what is working, the Indexing report tells you what is failing. It is the most direct diagnostic tool for technical SEO problems affecting site-wide visibility.
The Indexing report classifies all URLs known to Google into four statuses: valid (correctly indexed), valid with warning (indexed but with minor issues), excluded (not indexed, either by Google’s decision or by site directives), and error (issues preventing indexation). The ratio between these categories is an immediate indicator of the site’s technical health.
The most frequent — and most revealing — exclusion reasons are:
“Discovered – currently not indexed”: Google knows the URL but has not crawled it. On small sites, this may indicate perceived low content quality. On large sites, it is the classic symptom of crawl budget problems. If this category grows month over month, the site is generating URLs faster than Googlebot can process them.
“Crawled – currently not indexed”: Google crawled the page but decided not to index it. This is the clearest signal that Google considers the page’s content insufficient, duplicate, or low quality. It is not a technical error — it is a quality judgement that requires content review.
“Duplicate, Google chose different canonical”: Google has detected this URL is a variant of another and has decided to index the other version. If the URL Google chooses as canonical is not the one you intended, you have a canonical conflict that may affect ranking of the correct page.
“Excluded by ‘noindex’ tag”: The page has a noindex directive that Google has respected. If you see pages here that should be indexed, some technical process is applying noindex incorrectly — a surprisingly common error after CMS updates or code deployments.
According to a Moz analysis of over 50,000 websites, 42% have at least one section with indexing problems that the marketing team is unaware of. The GSC Indexing report is the most direct way to detect these problems before they impact organic traffic.
Review of the Indexing report should be weekly for active sites. Any sudden change in the number of excluded pages or in the distribution across exclusion categories signals that something has changed in the site’s technical infrastructure requiring immediate investigation.
Core Web Vitals in Search Console: interpreting the data
The Core Web Vitals section in Google Search Console is the only official source of field performance data from Google. Unlike PageSpeed Insights or Lighthouse, which run lab tests under controlled conditions, the Core Web Vitals in GSC show real metrics collected from real users visiting your site with Chrome.
GSC groups site URLs into three statuses for each metric: good (green), needs improvement (yellow), and poor (red). URLs are grouped by similar patterns — they are not evaluated individually — which means one poorly performing URL can drag down an entire group of structurally similar URLs. This grouping behaviour is important for prioritising fixes: resolving a problem on one URL can automatically improve the status of dozens or hundreds of URLs in the same group.
The three Core Web Vitals metrics GSC reports are:
LCP (Largest Contentful Paint)
Measures when the page’s main visual element becomes fully rendered. The “good” threshold is under 2.5 seconds. The most frequent LCP issues on business websites are: unoptimised hero images, web fonts blocking rendering, and slow servers taking more than 600 ms to serve the initial HTML. According to Chrome User Experience Report data, 40% of websites do not pass the good LCP threshold.
INP (Interaction to Next Paint)
Measures the page’s responsiveness to user interactions (clicks, taps, keystrokes). It replaced FID in March 2024. The “good” threshold is under 200 milliseconds. INP issues typically originate from excessive JavaScript blocking the main thread, costly event handlers, or framework hydrations competing with user interactions.
CLS (Cumulative Layout Shift)
Measures the page’s visual stability during loading. The “good” threshold is below 0.1. The most common causes of high CLS are: images and embeds without explicit dimensions, dynamically loaded ads displacing content, and web fonts triggering a reflow when they replace the system font.
To interpret Core Web Vitals data in GSC correctly, it is essential to understand that the data has a 28-day delay. GSC displays a 28-day rolling average of field data, meaning improvements implemented today will not appear in GSC for a month. This delay is intentional: Google requires a sufficient volume of real user data for the metrics to be statistically significant.
The most effective strategy for improving Core Web Vitals is to prioritise by volume of affected URLs. If the GSC report shows that 70% of mobile URLs have poor LCP, that is the number one priority regardless of whether desktop URLs are in the green. Google uses mobile experience as the primary ranking reference since the full adoption of mobile-first indexing.
Sitemaps and URL submission: best practices
The sitemaps section in Google Search Console serves two purposes: it lets you submit XML sitemaps to accelerate page discovery, and it provides diagnostic data on how Google processes those sitemaps.
Submitting an XML sitemap through GSC is one of the most direct mechanisms for communicating your site’s complete structure to Google. According to Google’s official documentation on building and submitting sitemaps, a well-configured sitemap can reduce the discovery time for new pages from weeks to days. This is especially relevant for sites that publish content frequently or that have undergone significant structural changes.
Best practices for sitemaps in GSC are straightforward but frequently violated:
Only canonical URLs returning 200
The sitemap must not contain URLs that return redirects (301, 302), errors (404, 410), or that carry noindex directives. Each incorrect URL in the sitemap is a signal of technical inconsistency that Google records.
Automatic updates
The sitemap should be generated dynamically or updated automatically with every content change. A static sitemap that falls out of date creates the inverse problem: Google tries to crawl pages that no longer exist and fails to discover new ones.
Segmentation by content type
For sites with multiple content types (product pages, blog posts, category pages), using separate sitemaps per type makes diagnosis easier. If the product sitemap shows errors, you know exactly where to look without reviewing the entire site.
Include lastmod when accurate
The lastmod tag tells Google when each URL was last updated. If this date is genuine (reflecting a substantial content change), Google uses it to prioritise crawling of updated pages. If it is artificial (auto-updated daily without real changes), Google learns to ignore it, nullifying its value.
The URL Inspection tool in GSC complements sitemaps for specific cases. It allows you to request indexing of a specific URL, which is useful after publishing urgent content or correcting a technical error on an important page. However, this request does not guarantee indexing: Google evaluates content quality and relevance before including it in the index.
For detailed sitemap configuration and its interaction with robots.txt, see our guide on XML sitemap and robots.txt.
The 5 errors most commonly ignored in Search Console
After auditing hundreds of Google Search Console accounts, a clear pattern emerges: certain errors repeat across sites of all sizes, and in most cases nobody is watching for them. Not because they are hard to find, but because the reports where they surface are not part of the standard review routine.
Error 1: Not reviewing non-www and HTTP URL properties
If you verified https://www.yourdomain.com but not https://yourdomain.com, you may be missing data for pages Google crawls on the non-www version. With domain properties this does not apply, but many sites still use URL-prefix properties inherited from the Google Webmaster Tools era. Google’s official documentation recommends domain properties precisely to avoid this issue.
Error 2: Ignoring the Enhancements report
Beneath the main reports, GSC includes enhancement reports for breadcrumbs, FAQ, products, articles, and other structured data types. These reports surface Schema.org implementation errors that prevent your pages from appearing with rich snippets. A mistake in FAQ markup can mean your answers do not appear in the expandable snippet, losing visual real estate to competitors who implement it correctly.
Error 3: Not configuring email alerts
GSC sends email notifications when it detects critical problems: server error spikes, security issues, manual actions, or significant drops in indexing coverage. Many site owners disable these notifications or filter them to spam. These alerts are the most direct early warning system Google offers.
Error 4: Trusting URL Inspection blindly
The URL Inspection tool shows how Google sees a specific page at the moment of inspection, but it does not necessarily reflect how Google previously indexed it. An inspection showing “URL is on Google” does not guarantee good ranking or correct canonical selection. You must read the full inspection detail, including the Coverage and Mobile Usability tabs, which contain additional data about the page’s real status.
Error 5: Not cross-referencing GSC data with server data
GSC shows what Google sees, but it does not show what Google cannot see. If Googlebot cannot reach certain site sections due to network issues, firewall rules, or CDN configuration, those pages simply do not appear in GSC. Server log analysis is the necessary complement for detecting Googlebot requests that fail before reaching GSC. According to the Ahrefs report on Google Search Console, combining GSC with server logs is the practice that most distinguishes professional technical audits from basic automated ones.
The discipline of reviewing these five points monthly can prevent most technical problems that are otherwise discovered too late in formal audits.