Search Console is the only place you can see what Google actually thinks about your site, it costs nothing, and most people connect it once and then look at the front graph occasionally. The front graph is the least useful thing in it.
Four reports carry almost everything worth acting on. Here is what each one is really telling you and the mistake each one invites.
1. Performance — but filtered to one page
The default view is site-wide totals, which averages away everything you need. The version that produces decisions is the Pages tab, one page at a time.
Pick a page that matters. Open it, then look at its queries. You are answering two questions: is this page found for what I intended, and is it found for things I did not intend.
The second is often more interesting. A page appearing for queries you never targeted is telling you what readers actually think it is about, and that is frequently a better topic than the one you chose.
The trap: average position. It is an average across every query and every impression, so it moves for reasons that have nothing to do with performance — start ranking for fifty new terms at position 40 and your average gets worse while you improve. Use clicks. Use impressions as context. Treat average position as decoration.
The most useful single filter: sort by impressions, high to low, then look for rows with many impressions and almost no clicks. Those are queries where you appear and nobody chooses you — usually a title and description problem, occasionally a sign you are ranking for something you should not be. Rewriting a title is a ten-minute job with a measurable outcome, which makes this the highest return per minute in the whole tool.
2. Page indexing — the report that answers "why is this not on Google"
If a page is not appearing at all, this is where the answer is, and it is specific rather than general.
The categories that actually matter:
- Crawled — currently not indexed. Google looked and chose not to include it. This usually means thin or duplicative content, not a technical fault. Uncomfortable, but honest feedback.
- Discovered — currently not indexed. Google knows the URL exists and has not got round to fetching it. Often a sign of too many low-value URLs competing for attention — filters, parameters, pagination.
- Duplicate, Google chose a different canonical. Google disagrees with your canonical tag. Worth reading closely: it names the URL it preferred, which tells you exactly what it thinks is duplicated.
- Excluded by noindex tag. If a page you want indexed is here, you have found your problem. This is the most common cause of a launched site never appearing, because development settings survive launches.
- Soft 404. A page returning success while looking empty or irrelevant to Google. Also what you get when you redirect dead pages to the homepage.
The trap: treating every excluded URL as a problem. Plenty of exclusion is correct — you do not want filtered category URLs indexed. Read the list, decide which exclusions are intended, and only chase the ones that are not.
3. URL Inspection — for one specific question
Not a report so much as a lookup, and the fastest way to end an argument.
Paste a URL and it tells you whether it is indexed, when it was last crawled, which canonical Google chose, and whether it found any structured data. Use "Test live URL" and then "View crawled page" to see the HTML Google actually received — which is not always the HTML you think you are serving.
That last point is the one worth knowing. If your content only appears after JavaScript runs, this is where you find out what a crawler sees without it. A page that renders empty here is a serious problem and an invisible one from a browser — the same class of failure as a site that returns 200 and serves nothing.
The trap: requesting indexing repeatedly and believing it does something. It queues the URL. It does not persuade Google to include a page it has decided against, and pressing it ten times does not help.
4. Links — read once a quarter, not weekly
Two lists: who links to you, and how your own pages link to each other.
The internal links list is the one people ignore and the one you can act on. Sort by fewest internal links. Pages at the bottom are the ones your own site treats as unimportant, and if a page that matters commercially is down there, that is a fixable structural problem — add links to it from related pages that already perform.
The external list is mostly informational. It is useful for noticing that a page earned a link you did not know about, which tells you what other people found worth citing.
The trap: the number of linking domains is not a score. A quarterly glance is enough.
What I would ignore
Core Web Vitals in Search Console is field data with a lag of weeks and it groups URLs into buckets, so it is poor for diagnosis. Use it to notice a problem exists, then measure the specific page directly.
The Enhancements reports matter only if you use those features. Manual Actions matters intensely if you have one and not at all otherwise — check it once, then only when something dramatic happens.
Two things to do the first time you open it properly
Confirm you own the property. Not your developer, not your agency. It should be verified on your account with them added as users. This is the single most common access problem I run into, and it becomes urgent exactly when a relationship ends.
Export the last sixteen months now. Search Console only keeps sixteen months, and it will not give them back later. One CSV, saved somewhere, is your baseline for every future question about whether something changed — and having a baseline is the difference between a diagnosis and an argument, which is the case I made for investigating ranking drops and for measuring local work.
Fifteen minutes a month in these four screens will tell you more about your site than any monthly report you are sent — and it is the same data, seen without a filter. If you would rather have someone read it with you, that is a short piece of work.