Google Search Console in Detail: The Reports That Actually Matter

1. The Performance report: understanding clicks, impressions, CTR, and position

The Performance report is the most frequently used, and also the most frequently misread, view in Search Console. It shows four core metrics: clicks, impressions, average CTR, and average position, aggregated over the last 16 months. What matters is that "position" is an average across every SERP appearance: a position of 3.2 can mean a query sometimes ranks first in a featured snippet and sometimes ninth in the classic list. Without looking at the position distribution per query, this average is easily misread.

Clicks and impressions should never be viewed in isolation. Rising impressions paired with stagnant clicks almost always point to a CTR problem, usually caused by an unappealing title tag or a meta description that doesn't match search intent. The opposite case, falling impressions with stable CTR, indicates a visibility problem instead, for example from ranking losses or seasonal demand shifts. The built-in comparison against a prior period makes these shifts immediately visible and is the first step of any performance analysis.

# Query the Search Analytics API for queries and pages of the last 28 days
curl -X POST \
  "https://searchconsole.googleapis.com/webmasters/v3/sites/https%3A%2F%2Fwww.example.com%2F/searchAnalytics/query" \
  -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "startDate": "2026-06-13",
    "endDate": "2026-07-11",
    "dimensions": ["query", "page"],
    "rowLimit": 5000,
    "dataState": "all"
  }'

2. Using filters and segments in the Performance report correctly

The raw data in the Performance report only becomes actionable once it's filtered and segmented. The "Pages" dimension shows which URLs generate impressions at all, while the "Queries" dimension reveals what terms users actually search for, often differing from internal keyword planning. Combining both dimensions, for example by clicking a single page and then switching to the "Queries" tab, shows exactly which terms a given category page ranks for and where duplicate-content risk from cannibalization arises between similar pages.

The "Search appearance" filter narrows results down to those with rich-snippet properties, such as product star ratings or FAQ dropdowns, and shows whether structured data actually drives more clicks. The device filter separates desktop, mobile, and tablet traffic and frequently reveals that mobile CTR is lower than desktop despite higher impressions, a sign of unfavorable mobile snippet display. The compare mode for two filters at once, for example country against country or period against period, is the most powerful yet least used part of the report.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Sample Product",
  "sku": "MS-5678",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "94"
  },
  "offers": {
    "@type": "Offer",
    "priceCurrency": "USD",
    "price": "79.90",
    "availability": "https://schema.org/InStock"
  }
}
<!-- This markup determines eligibility for the "Search appearance: rich results" filter -->

3. Interpreting the Coverage and indexing report

The Coverage report, found under "Pages" in the current interface, classifies every known URL into one of four categories: error, valid with warning, valid, or excluded. The most common mistake is treating "excluded" as a blanket problem. Many exclusion reasons are intentional, for example "Duplicate, Google chose different canonical than user" on filter pages, or "Excluded by noindex tag" on internal search result pages. It only becomes critical once important product or category pages show up in these categories.

The status "Crawled, currently not indexed" deserves special attention, since it rarely has technical causes and more often stems from quality issues: thin content, missing internal links, or too much content overlap with pages already indexed. "Discovered, currently not indexed" instead points to a crawl budget problem, common in very large catalogs with many filter combinations. Comparing submitted sitemap URLs against the Coverage report's actually indexed URLs is the most reliable metric for a store's real indexing rate.

# robots.txt rules that commonly cause "Excluded by robots.txt" in the Coverage report
User-agent: *
Disallow: /catalogsearch/
Disallow: /checkout/
Disallow: /customer/
Disallow: /*?p=*&
Allow: /catalogsearch/result/

Sitemap: https://www.example.com/sitemap.xml

4. The Core Web Vitals report in Search Console

Unlike Lighthouse, the Core Web Vitals report in Search Console shows no per-page measurements. Instead it groups URLs with a similar template into "URL groups" and evaluates them using aggregated CrUX field data over 28 days. A single red URL rarely triggers a crisis on its own; what matters is the number of affected URLs within a group and the trend over several weeks. A sudden jump of many product pages from "good" to "needs improvement" after a deployment is a reliable early warning sign of a performance regression.

The report strictly separates mobile and desktop, since CrUX data is collected per form factor and mobile scores are almost always worse due to slower networks and devices. Clicking an affected URL group opens sample URLs that can be followed directly into PageSpeed Insights or the URL Inspection tool. Because CrUX only provides data for URLs with sufficient traffic volume, many long-tail pages remain unrated, and only a lab measurement can approximate their score.

5. The URL Inspection tool: a workflow for indexing problems

The URL Inspection tool provides two distinct data sources: the last state Google crawled and stored in the index, and a live test that fetches and renders the page in real time. After any content change, such as a new title tag or corrected structured data, the live test should always be used first to confirm the change is actually being served correctly before requesting reindexing. The live test also shows the rendered HTML after JavaScript execution, which is usually uncritical for Hyvä stores with server-rendered HTML, but can be decisive for content that loads client-side.

The "Request indexing" function has a daily quota and doesn't act immediately; it merely places the URL higher in the crawl queue. For bulk changes, for example after an attribute migration affecting thousands of products, resubmitting an updated sitemap is more effective than manually requesting individual URLs. The "Enhancements" section within URL Inspection also shows whether structured data parsed correctly and which rich-snippet types are active for that exact URL.

{
  "inspectionResult": {
    "indexStatusResult": {
      "verdict": "PASS",
      "coverageState": "Submitted and indexed",
      "robotsTxtState": "ALLOWED",
      "indexingState": "INDEXING_ALLOWED",
      "lastCrawlTime": "2026-07-09T03:14:22Z",
      "pageFetchState": "SUCCESSFUL",
      "googleCanonical": "https://www.example.com/produkt/beispiel.html",
      "userCanonical": "https://www.example.com/produkt/beispiel.html"
    },
    "mobileUsabilityResult": {
      "verdict": "PASS"
    }
  }
}

6. The Links report: analyzing internal and external linking

The Links report is organized into external links, internal links, top linked pages, and top linking text. For external links, the raw count matters less than the number of referring domains: a thousand links from ten domains carry far less SEO weight than a hundred links from a hundred different, topically relevant domains. A sudden spike in links from low-quality domains can indicate negative SEO or spam linking and should be checked via the Disavow tool in Google Search Console if organic visibility drops at the same time.

The internal links report shows which pages within the store are linked to most internally, indirectly revealing how important the crawler perceives a page to be. Product pages with only one or two internal links are a strong signal of insufficient internal linking, often the actual cause behind the "Crawled, currently not indexed" status from the Coverage report. Increasing internal link count through cross-selling blocks, breadcrumbs, or category navigation is usually more effective than any external link-building effort.

7. Sitemaps report: submission, processing, and troubleshooting

The Sitemaps report shows, for each submitted sitemap, a status of "Success" or "Couldn't fetch," along with the number of discovered URLs. It's essential not to confuse "Success" with "fully indexed": the status only confirms the XML file was syntactically read correctly, not that every URL it contains actually made it into the index. The truly relevant comparison happens in the Coverage report filtered by "Sitemaps," which shows how many of the submitted URLs were actually indexed.

For large Magento catalogs, a sitemap index file with several sub-sitemaps split by type, for example products, categories, and CMS pages, is recommended instead of a single monolithic file over the 50,000 URL limit. The lastmod date should only be updated when content actually changes, since Google flags repeatedly unchanged lastmod timestamps as an unreliable signal and reduces recrawl priority accordingly.

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://www.example.com/sitemap_products_1.xml</loc>
    <lastmod>2026-07-10T02:00:00+00:00</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://www.example.com/sitemap_categories.xml</loc>
    <lastmod>2026-07-08T02:00:00+00:00</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://www.example.com/sitemap_cms_pages.xml</loc>
    <lastmod>2026-07-01T02:00:00+00:00</lastmod>
  </sitemap>
</sitemapindex>

8. Setting up and interpreting email alerts correctly

Search Console automatically sends email notifications to all verified property users whenever it detects significant increases in indexing errors, manual actions, security issues, or new Coverage error categories. These alerts are based on threshold comparisons against the property's historical average and typically only fire once several hundred URLs are affected or a clear percentage jump occurs, which means small, gradual declines often go unnoticed.

It's important to check the notification settings under "Users and permissions" for every relevant team member, since alerts by default go only to the registered users' individual email accounts and aren't automatically forwarded to shared team inboxes. For faster reaction times than the default alert cadence, custom monitoring via the Search Console API is recommended: a daily script compares click and impression values per page type against the rolling 7-day average and flags deviations far earlier than Search Console's built-in email alerts.

9. GSC reports compared: meaning, common misreadings, correct action

Every Search Console report answers a different question, and each is typically misread in its own way. The table below summarizes what really matters for the most important reports.

In practice, the full value of Search Console emerges only from combining the reports: a CTR drop in the Performance report, a new Coverage exclusion, and a falling internal link count on the same URL group almost always reveal the same root cause from three different angles. Reading reports in isolation finds symptoms; combining them finds the actual cause.

10. Summary

Google Search Console solves one core problem: without reliable data on visibility, indexing, and user experience, technical SEO is pure guesswork. The Performance report shows how users actually find the store, the Coverage report shows whether important pages make it into the index at all, and the Core Web Vitals report shows whether the user experience meets Google's standards. The URL Inspection tool is the fastest path from diagnosis to confirming a fix, while the Links and Sitemaps reports expose the structural foundation of indexing.

The decisive difference between superficial and effective use of Search Console lies in combining reports rather than looking at isolated numbers. Reading Performance, Coverage, and Links data together for the same URL group, and supplementing email alerts with your own API monitoring, surfaces ranking problems weeks earlier than simply waiting for the monthly check in the interface.

11. FAQ: Google Search Console in Detail