Working through search console reports
The reports are a search engine's account of what it found, and most of what they contain is either informational or already correct. The work is telling the actionable findings from the ones that should be left alone.
The reports are large and they do not rank themselves
A coverage report on a site of any size lists thousands of URLs across a dozen categories, and an enhancements report lists issues per structured data type. Almost none of it is sorted by whether it matters. A team that treats every item as a defect spends its time on exclusions the site intended and warnings about markup that is valid, while the two categories that are genuinely costing visibility sit unexamined in the same list.
- The coverage report has thousands of excluded pages and nobody knows which matter
- Structured data warnings have been present for years and are ignored as noise
- A manual action or security issue is present and was not noticed
- Page experience or Core Web Vitals reports are failing and the cause is not established
- Excluded pages are being chased individually rather than understood as classes
- The team cannot tell a site-wide problem from a page-level one
- Reports are checked monthly and acted on inconsistently
- Nobody has established which warnings are legitimately ignorable
The people who usually bring us this problem
A team with a large coverage report
Thousands of excluded URLs and no way to tell which categories are costing visibility.
A team that has stopped reading the reports
They have been noisy for so long that nobody looks, and something actionable could be sitting in them.
A team responding to a specific issue
A manual action, a security flag or a failing report needs establishing and addressing.
What this costs while it goes unfixed
Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.
Most warnings are informational, and saying so is the useful part
A structured data warning about a property that is optional, or a coverage exclusion the site deliberately caused, is not a defect. Treating them as defects produces work that changes nothing, and the cost is not only the time — it is that the reports stop being read, which is how a manual action goes unnoticed for months.
The report describes an outcome and not a cause
Excluded by noindex, discovered but not indexed, crawled but not indexed — each names what the search engine decided, and the reason is in the site. Reading a coverage category as a diagnosis is the most common mistake with these reports, and it produces fixes applied to the wrong layer.
Categories are classes of URL, not lists of pages
An exclusion affecting two hundred thousand URLs is usually one rule, one template or one canonical decision. Working through the list individually is unbounded; identifying the class and its cause is a piece of work with an end, and it is the same finding either way.
A manual action is a different kind of problem entirely
It is a decision a human made about the site rather than an automated observation, and it has its own process, its own evidence requirement and its own timeline. It is also the one report where inaction has a direct and continuing cost, which is why it is worth checking before anything else in the account.
Capabilities
Each of these is work we carry out, not an area we advise on.
Triage before analysis
Establishing which reports carry a continuing cost — manual actions, security issues, site-wide failures — and which are informational. Done first, because a manual action buried under two thousand coverage exclusions is the failure mode this step exists to prevent.
Coverage categories interpreted as classes
Each exclusion category read as a statement about a class of URL rather than about individual pages, and traced to the rule, template or canonical decision that produced it. The count is evidence about how many pages a single decision affects.
Which exclusions are intended
Establishing which of the excluded classes the site deliberately excluded, and confirming that the mechanism matches the intention. An intended exclusion implemented by the wrong mechanism is a real finding, and it is invisible unless the intention is known.
Structured data warnings assessed against requirements
Each warning read against what the type actually requires rather than against the fact that a warning exists. Warnings about optional properties are not defects, and separating them from missing required properties is what makes the report usable.
Enhancement and experience reports
Core Web Vitals, mobile usability and the enhancement reports, each read against what the site actually is — including the cases where a failing group is a small number of URLs and the cases where it is a template.
Manual actions and security issues
Establishing what the issue is, what evidence the review requires, and what has to be fixed before a reconsideration is worth submitting. The same discipline as a security flag: fix the cause, then submit, and never promise a timeline that belongs to the reviewer.
The actions worth taking
A short list, ordered by cost of inaction rather than by count. Most of the report is left alone deliberately, and what remains is specific: this class, this cause, this change.
Verification and monitoring
Confirming that a change moved the report it was aimed at, and setting the checks that would catch a manual action or a site-wide failure without waiting for a monthly review.
Engineering methodology
The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.
Read the reports in order of cost
Manual actions and security issues first, then site-wide failures, then the classes with a plausible effect on visibility, then the informational remainder. The order is deliberate, because the reports are not sorted by anything useful and the consequential items are not the numerous ones.
Treat every category as a class of URL
Find the rule, template or decision that produced the count. A number is evidence about the scope of a single cause, and working from individual URLs produces a list of symptoms with no end.
Ask whether the exclusion was intended
And whether the mechanism matches the intention. A site that meant to exclude a class and did it by the wrong means has a real problem that no amount of reading the report will reveal — the intention has to come from the site.
Judge a warning against the requirement, not against its existence
A warning about an optional property is not a defect, and treating it as one produces work with no outcome. The question is whether what the type requires is present and correct, and that is established by reading the requirement rather than the warning.
Leave most of it alone, and say which parts
The deliverable names what was examined and deliberately not acted on, with the reason. It is what stops the same triage being repeated next quarter, and it is what makes the reports worth reading again.
Fix the cause, then submit where submission is required
For manual actions and security issues, the review follows the fix and is submitted with the evidence. A reconsideration against an unremediated site is asking the reviewer to look at the same thing, and no timeline for their decision is ours to give.
What an engagement produces
Documentation is a deliverable, not an afterthought. On most of these engagements a large part of the value is a defect report precise enough for another team to act on.
Triage
- Manual actions and security issues, established first
- Site-wide failures, separated from page-level findings
- Every coverage category, read as a class with its likely cause
- Which exclusions are intended, and whether the mechanism matches
- Structured data warnings separated into required and optional
- Which reports carry no continuing cost, stated explicitly
Action
- The changes worth making, ordered by cost of inaction
- Causes fixed at the layer they exist at — rule, template or canonical
- Reconsideration submissions where a manual action or security issue requires one
- What was deliberately not acted on, with the reason
Verification
- The report each change was aimed at, confirmed as moved
- Which categories remain and why they are acceptable
- What to check and how often, so a manual action is not missed
- What the site intends, recorded, so the next triage is faster
Architecture and technology
The reports, by what they cost
- Manual actions — a human decision with a continuing cost and its own review process
- Security issues — same, and frequently the visible part of a compromise
- Site-wide failures — a template or rule affecting every page of a type
- Coverage exclusions — usually intended, occasionally the mechanism is wrong
- Structured data warnings — usually optional properties, occasionally required ones missing
- Experience reports — frequently a small number of URLs rather than a template
What the reports do not tell you
- Why a category exists — the report states the outcome, the cause is in the site
- Whether an exclusion was intended — only the site knows that
- Whether a warning matters — that depends on the type's requirements
- Whether a change would help — a report describes a state, not a consequence
- What a reconsideration will decide, or when
If this is not quite your problem
These overlap at the edges. Sending you to the right page is more useful than having you work it out.
The whole technical position needs establishing
An audit delivered as a prioritised engineering backlog.
Technical SEO auditThe coverage category is the problem
What is crawlable, indexable and reachable, and what limits each.
Crawl and indexationThe server errors are real
Reducing 5xx responses and the crawl rate they affect.
SEO server error remediationThe structured data warnings need addressing properly
Generating markup from the content model rather than per template.
Structured data implementationFrequently asked
How is this different from your technical SEO audit?
The audit examines the site; this examines what a search engine reports about it. They overlap in the middle and the direction is opposite: an audit starts from the site and establishes what is wrong, while this starts from the reports and establishes which of what they contain is worth acting on. Most of a coverage report turns out to be intended exclusions and optional-property warnings, so the deliverable here is usually a short list and a longer one of things deliberately left alone. Where the reports point at something real, that work goes to the audit, crawl and indexation, or server errors, depending on what it is.
Can you clear all our warnings?
No, and a provider who says they can is describing something else. Many warnings are about properties the type does not require, and many coverage exclusions are things the site deliberately did — clearing those means changing correct behaviour to make a report quieter. What this work does is separate the findings that carry a cost from the ones that do not, fix the first at the layer they exist at, and record which parts of the report were deliberately left alone so the same triage is not repeated. The reports will still contain warnings afterwards, and they will be the ones that do not matter.
What should we check first?
Manual actions and security issues, before anything else in the account. They are a human decision rather than an automated observation, they carry a continuing cost while they are in place, and they are the items most easily missed because a coverage report with thousands of exclusions is a very large thing to have on top of them. Reading the reports in order of what inaction costs — manual actions, then site-wide failures, then the classes with a plausible effect on visibility, then the informational remainder — is the whole method, and it takes minutes rather than the days the reports invite.
Why are so many pages excluded?
Because a site generates far more URLs than it intends to be indexed, and most exclusions are the system working. Tag and archive pages, filtered views, pagination, parameter variants and internal search results are all excluded because they should be — that is the indexation model doing its job rather than a defect. The real finding is when an exclusion is unintended, or when an intended exclusion is implemented by the wrong mechanism, and neither is visible in the report alone. That is why the coverage categories are traced back to the rule that produced them, and why the site's intention has to be established separately.
Our structured data warnings have been there for years. Does it matter?
Possibly not, and that is worth establishing rather than assuming either way. Most warnings concern optional properties, and a type with all its required properties present is valid regardless of them. The ones that matter are required properties that are missing or wrong, and those are read against the type's actual requirements rather than against the presence of a warning. Where the warnings are genuinely optional properties, the answer is to leave them and record why — because a report nobody reads is worse than one with known and accepted noise in it.
Related capabilities and work
Bring us the problem you have not been able to fix
Describe what is happening rather than what you think the cause is. If we are not the right people for it, we will say so.