Search Console opens on a chart most people cannot act on. One month the line is up, the next it is down, and it never says why. The reports that answer “what do I change next” are buried one level deeper, and only five of them regularly produce a decision.
The rest are useful for specific jobs: URL Inspection when one page misbehaves, Crawl Stats when the server is the suspect, Links when you need to know who cites you. This article covers the five worth a standing appointment, what each one actually measures, and the decision each one should trigger. It also covers the statuses that look like problems and are not, because that is where most of the wasted work happens.
The Performance Report: Queries With Impressions and No Clicks
Open Performance → Search results. The default view shows clicks and impressions for the past three months, and Google documents the four metrics precisely:
- Clicks: how many times a user clicked your site from Google Search results.
- Impressions: how many times your site appeared in results.
- CTR: clicks divided by impressions.
- Average position: the average position of the topmost result from your site.
That last definition matters. Average position is not a rank tracker. If one URL ranks second for a branded query and fortieth for a generic one, the number is an average across those rows, not the position of the page you have in mind. Use it to spot movement inside one query, not to compare pages against each other.
The dimension tabs are Queries, Pages, Countries, Devices, Search appearance, and Dates. The two that produce work are Queries and Pages, usually combined with a filter.
The decision: filter to queries where your site appears but earns few clicks relative to the impressions. Then look at the page ranking for that query. Three cases cover most of it:
- The page ranks in the top ten and the query is clearly relevant, but CTR is low. The title and description are not matching the searcher’s wording. Rewrite the title around the query, keep it under about 60 characters, and check that the description answers the query rather than repeating the title.
- The ranking page is a category or a tag archive. The query wants an article. Point the internal links at the page that deserves the traffic, or write the missing piece. Our guide to structuring WordPress pages for SEO covers how to do that without creating a second page that competes with the first.
- The query is a different intent than the page serves. A page about “how to change permalinks” ranking for “best permalink structure” will collect impressions and no clicks. That is a content gap, not a metadata problem.
Two limits are worth knowing before you build a dashboard on this report. Query data is sampled, and not every search appears in the list, so a missing query is not proof of zero demand. And Google’s own note says results are specific to the time, place, device, and recent history of the searcher, which is why checking the same query in a private window rarely reproduces the row you are looking at.
Page Indexing: Not Every “Not Indexed” Is a Problem
The Page indexing report is the one people misread most often, because “not indexed” covers several unrelated situations. Google lists each reason with a definition, and a few of those definitions contain the most useful sentence in the product: no need to resubmit.
| Status | What Google says it means | What to do |
|---|---|---|
| Crawled – currently not indexed | Google crawled the page and chose not to index it. It may index later. No need to resubmit. | Improve the page if it matters, or accept it. Resubmitting does nothing. |
| Discovered – currently not indexed | Google found the URL but has not crawled it. The crawl was rescheduled, typically because crawling would overload the site. | Check server response times and crawl demand. Resubmitting does nothing. |
| Duplicate, Google chose different canonical than user | Google indexed a different URL as the canonical. | Align canonicals and internal links, or make the pages genuinely different. |
| Soft 404 | The page returns a friendly “not found” message with a 200 status. | Return a real 404, or add enough content to be a real page. |
| Excluded by noindex tag | A noindex tag or header is doing exactly what it was told. | Confirm it is intentional. If it is, leave it alone. |
| Blocked by robots.txt | The URL is disallowed, often deliberately. | Check whether the block was meant for this path. |
| Server error (5xx) | Googlebot could not access the URL, timed out, or the site was busy. | Fix the server before touching content. |
| Alternate page with proper canonical tag | Google found the canonical and indexed it instead of this URL. | Nothing. This is the system working. |
The pattern is that only some of these are content problems. A soft 404 is a content or status-code problem. A 5xx is an infrastructure problem. A deliberate noindex is a decision already made. Google’s documentation also notes that you do not have to click Validate: the instance count updates the next time Google crawls a page with a known issue. Validation is for tracking a fix, not for triggering one.
The decision: open the report once a week, look only at statuses that changed, and ask one question per status: did I mean this? If yes, close the tab.
Core Web Vitals: Read the Group, Not the Number
The Core Web Vitals report uses field data, meaning measurements from real visitors rather than a lab test. It groups URLs by status (Poor, Need improvement, Good), by metric (LCP, INP, CLS), and by URL group, which is a set of similar pages. Mobile and desktop are reported separately because they fail for different reasons.
The thresholds are fixed and measured at the 75th percentile of page views, according to web.dev’s Web Vitals documentation:
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP (loading) | ≤ 2.5 s | 2.5–4.0 s | > 4.0 s |
| INP (responsiveness) | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS (layout shift) | ≤ 0.1 | 0.1–0.25 | > 0.25 |
Google’s own guidance on ordering the work is blunt: “URLs labeled ‘Need improvement’ could be improved, but are less important to fix than Poor URLs.” So the first pass is the Poor table, sorted by the URL group with the most pages or the most important template. Fixing a product template beats fixing one product.
The decision: pick one URL group in Poor, identify which of the three metrics failed, and fix that metric on the template. The WordPress page speed guide walks through the template-level fixes in the order that moves field data. If all three are Poor on the same group, start with LCP, because a page that takes four seconds to render is also a page where every interaction lands on a busy main thread.
Two caveats keep this report honest. Field data covers the last 28 days, so a fix shipped today will not show up tomorrow. And Google warns that a site-wide event — a traffic spike, or a latency change at the service hosting your images — can push a borderline group from Good to Poor with no code change at all. If a group flips overnight and you shipped nothing, look for the event before you look for the bug. A clean lab score is not a defense either; improving your PageSpeed score is a different job from moving a Poor URL group, and our breakdown of the performance metrics beyond Core Web Vitals covers what this report never shows.
Manual Actions and Security Issues: The Binary Reports
Most Search Console reports are diagnostic. These two are verdicts.
A manual action means a person at Google reviewed the site and decided it violates a spam policy. That is different from an algorithmic decline, which never appears in this report. The report distinguishes actions that affect the whole site from those that affect a subset of pages, and it lists patterns for the affected URLs.
Recovery has one rule that people get wrong: fix every affected page. Google states that fixing the issue on just some pages “will not earn you a partial return to search results.” If there are several actions, all of them need to be addressed before a reconsideration request makes sense. The request itself is a short explanation of what was wrong and what changed; it is not a place to argue that the algorithm was unfair.
Security Issues is a separate report and covers hacking, malware, and deceptive redirects. A manual action can point at it: if the action mentions hacked content or redirects, the Security Issues report is where the evidence lives. Check both before deciding the site is clean.
The decision: look at both once a month. “No issues detected” is a real answer — it means you can stop speculating about a penalty and go look at content, competition, or seasonality instead.
Sitemaps: “Last Read” Is a Fetch, Not an Index
The Sitemaps report causes more unnecessary resubmission than any other screen in Search Console. Google defines the fields plainly:
- Last read: “The last time the sitemap was fetched by Google.” It appears only if Google could fetch the file.
- Status: the result of the latest crawl. “Success” means the sitemap was loaded and processed, and all URLs will be queued for crawling.
- Discovered pages: the number of URLs parsed from the sitemap. For a sitemap index, it is the count across all child sitemaps, with duplicates counted once. Google adds that there is “no guarantee that a page URL discovered in a sitemap has been indexed.”
That is the whole misunderstanding in three definitions. Last read is a fetch timestamp. Discovered is a parse count. Success is a queue entry. None of them is an index status, and none of them is a ranking factor.
The decision: submit each sitemap once, then use this report for two things only. First, confirm Google is still fetching the file — if Last read stops moving, something is blocking the request. Second, read the error detail when a sitemap reports errors, because a malformed <loc> or a duplicate tag is fixable in minutes. For whether pages are indexed, use Page Indexing.
The Order to Read Them In
Five reports, three rhythms:
Weekly, ten minutes. Performance first: any query with rising impressions and flat clicks. Then Page Indexing: any status that changed since last week.
Monthly, twenty minutes. Core Web Vitals for the Poor URL groups, then Sitemaps for the Last read date. Manual Actions and Security Issues take thirty seconds when they are clean.
After a traffic drop, in this order. Manual Actions and Security Issues first, because a verdict outranks a diagnosis. Page Indexing second, because a template that dropped out of the index explains a cliff better than a ranking change does. Performance last, with the date range set wide enough to include the drop, to see whether the loss is one query, one page, or the whole site.
If you are rebuilding the rest of the process, our guide to boosting your SEO ranking covers the parts that never appear in Search Console.
What These Five Reports Cannot Tell You
They cannot tell you why a page was crawled and not indexed. “Crawled – currently not indexed” is an outcome, not a reason; the reason lives in the content, the internal links, and the competition for that query.
They cannot tell you how often Googlebot visits. That is Crawl Stats, under Settings.
They cannot tell you whether a query converts. Search Console stops at the click. Revenue lives in analytics, and a high-impression query with terrible conversion is a product problem wearing an SEO costume. The plugin layer helps with the mechanics — our roundup of free WordPress SEO plugins covers what each one automates — but no plugin reads these reports for you.
And they cannot tell you what a competitor is doing. A page that lost positions to a better page is not a technical fault, and no amount of re-indexing will fix it.
Used this way, the five reports are a short checklist rather than a dashboard: what changed, did I mean it, what do I fix. Everything else in Search Console is a tool you reach for when one of those answers is unclear.
FAQ
How often should I check Search Console?
Weekly for Performance and Page Indexing, monthly for Core Web Vitals, Sitemaps, Manual Actions, and Security Issues. Daily checking produces anxiety, not decisions, because field data and index status both move on delays measured in days.
Why does Search Console show no data for a query I rank for?
Query data is sampled and not every search appears in the list, so the row may simply not be reported. Rankings also vary by location, device, and search history, which is why a private-window search will not always reproduce the row.
Does “Discovered – currently not indexed” mean I should resubmit my sitemap?
No. Google’s documentation says the URL was found and the crawl was rescheduled, often to avoid overloading the site, and that there is no need to resubmit. Look at server response times and crawl demand instead. The same applies to “Crawled – currently not indexed.”
What is a good CTR in Search Console?
There is no universal number, and any article that gives you one is guessing. CTR depends on position, query intent, and what else occupies the results page. Compare a page against its own CTR at the same average position over time, or against other pages ranking for similar queries on your site.
Do Core Web Vitals affect rankings?
Google uses page experience signals in ranking, and Core Web Vitals are part of that set. They are not a tiebreaker you can win with a single metric; a fast page with thin content still loses to a slower page that answers the query. Treat the report as a way to remove a disadvantage, not as a ranking lever on its own.
Why has my sitemap’s “Last read” date not changed?
Because Google has not fetched the file since that date, which can be normal for a sitemap that rarely changes. If the date is weeks old and you have published new URLs, check that the sitemap still returns 200, that robots.txt does not block it, and that the URL in the report matches the live file.