GSC Error Review — SEO Playbook

Overview

What this task involves

A structured monthly walkthrough of five GSC report areas: the Coverage (Pages) report for indexing errors, Manual Actions for penalties, Security Issues for hacks or malware, Mobile Usability for mobile rendering problems, and Core Web Vitals for performance failures. The goal is to identify anything that has changed materially since last month and act on it.

This is a monitoring and triage task — not a deep investigation. If something requires significant investigation or remediation, it gets flagged and escalated. The task itself takes about an hour per client.

Why it matters

GSC tells us what Google sees. Issues in any of these five areas can cause silent ranking loss, indexing failures, or — in the case of manual actions or security issues — catastrophic drops that are hard to recover from.

The monthly check is cheap insurance. A robots.txt mistake, a developer's noindex tag left in production, or a security injection can cost a client their entire traffic base within weeks. Catching it in month one versus month three is the difference between a quick fix and a client relationship crisis.

What to focus on: changes, not totals

The most important thing to check is what has changed since last month — not the absolute numbers. A site with 50 crawl errors that has had 50 crawl errors for two years is not a problem. A site that went from 3 errors to 40 errors this month absolutely is.

Before starting, open last month's Zoho comment for this client and note the baseline numbers. You are looking for material increases, new error types, or new report sections that were previously clear.

Immediate escalation triggers: If you find a Manual Action, a Security Issue, or a sudden indexing collapse (e.g. indexed pages dropping from 120 to 15), stop the routine check and escalate to Melbourne immediately. Do not hold these items for the monthly report.

Coverage / Pages Report

The Coverage report (now labelled "Pages" in the current GSC interface) shows which URLs Google has indexed, which it has excluded, and which have errors.

Open the Pages report

In GSC, go to Indexing → Pages. You'll see four tabs: All, Error, Valid with warnings, Valid, and Not indexed. Focus on Error and Not indexed.

Note the total count of pages in each category. Compare to last month's numbers from the Zoho comment.
Any increase in Error count requires investigation. Click through to see the error types.
Any significant change in the total "Indexed" count (up or down) requires investigation.

Review each error type

Click on each error type to see the affected URLs. Categorise each error as one of three types:

Client-side / we can fix Soft 404s, redirect errors, noindex tags on pages that should be indexed, crawl anomalies we introduced. Log and fix within the current sprint.

Server-side / escalate to host Server errors (5xx), DNS resolution failures, connection timeouts. Log and escalate to Melbourne to raise with the client's hosting provider.

False positive / note and ignore Known paginated URLs, filter pages, or staging URLs that should not be indexed. If they were excluded last month and remain excluded, record "no change — expected" and move on.

Check the "Not indexed" tab for concerning exclusions

Not all "Not indexed" statuses are problems — Google legitimately excludes duplicates, redirects, and canonicalised pages. But some are worth investigating:

Crawled — currently not indexed: Google has seen the page but chose not to index it. If this applies to an important service page, it may indicate thin content or a crawl budget issue.
Discovered — currently not indexed: Google knows the page exists but hasn't crawled it yet. If an important page has been in this state for more than 4 weeks, flag it.
Blocked by robots.txt: If any important pages appear here, investigate immediately — this is often caused by a developer accidentally blocking the entire site during a migration.
Excluded by 'noindex' tag: Check that this only applies to pages that should legitimately be noindexed (thank-you pages, admin pages, etc.). If a service page appears here, flag it.

Robots.txt block: If you see "Blocked by robots.txt" for any important page, check the client's robots.txt file immediately (yoursite.com/robots.txt). A common migration mistake is leaving Disallow: / in a production robots.txt. This blocks Googlebot from the entire site.

Manual Actions

Check the Manual Actions report

In GSC, go to Security & Manual Actions → Manual Actions. This report shows any penalties applied manually by Google's spam team.

The desired state is: "No issues detected." If any penalty appears here — even a minor one — treat it as an immediate escalation to Melbourne. Do not proceed with the rest of the monthly check until Melbourne has been notified.

Understand the penalty types if one is found

If a manual action is present, note the exact penalty type and the scope (site-wide or partial). Common types include:

Spammy structured data Schema markup that misrepresents the page content. Remove the offending schema and submit a reconsideration request.

Unnatural links to your site Google has detected a manipulative backlink profile. Requires a disavow file and reconsideration request.

Thin content with little or no added value Pages that are too thin or duplicated. Requires content improvement.

Pure spam / Cloaking Most severe. Often caused by a hacked site serving spam to Googlebot. Requires immediate security remediation.

Manual action escalation: A manual action is never a routine finding. Escalate to Melbourne immediately with: the penalty type, the scope (partial or site-wide), and the URL of the GSC message. Melbourne will determine whether to involve a senior SEO or the client's developer.

Security Issues

Check the Security Issues report

In GSC, go to Security & Manual Actions → Security Issues. This report flags hacked content, social engineering, and malware that Google has detected on the site.

Like Manual Actions, the desired state is: "No issues detected." Any security issue is an immediate escalation — do not treat it as routine.

Understand the security issue types if found

Hacked content Google has detected pages injected by a third party — typically spam links, hidden content, or pages serving a different experience to Googlebot vs real users. Requires immediate security investigation by the client's developer or host.

Social engineering (phishing) Pages that attempt to deceive users into revealing credentials or installing malware. Users visiting the site will see a Google "Dangerous site" warning. Immediate client notification required.

Harmful downloads / Unwanted software The site is serving files that harm users. Immediate remediation required.

Security issue escalation: If a security issue is found, notify Melbourne immediately — not via the monthly report. The client's users may already be seeing Google warning pages. Speed of response directly affects the duration of ranking suppression.

Mobile Usability

Check the Mobile Usability report

In GSC, go to Experience → Mobile Usability. This report shows pages with mobile rendering issues. Google uses mobile-first indexing — mobile usability problems directly affect rankings for all users, not just mobile visitors.

Note the count of pages with errors. Compare to last month.
Any new error types warrant investigation.
Existing errors that are stable and already flagged in Zoho — record "no change" and move on.

Investigate new mobile usability errors

Click on each new error type to see affected URLs. The most common mobile usability errors are:

Text too small to read Font size under 12px on mobile. Usually a CSS fix — flag for developer.

Clickable elements too close together Buttons or links too small or too densely packed for touch interaction. CSS or layout fix — flag for developer.

Viewport not set The page is missing the viewport meta tag. A fundamental responsiveness issue — flag as high priority for developer.

Content wider than screen Horizontal scroll on mobile. Usually caused by a fixed-width element. Flag for developer.

Context matters: Mobile usability errors on the contact page or homepage are high priority. The same errors on a rarely-visited resources page are lower priority. Record the affected pages and note their importance when flagging to Melbourne.

Core Web Vitals

Check the Core Web Vitals report

In GSC, go to Experience → Core Web Vitals. This report shows pages classified as Good, Needs improvement, or Poor across the three CWV metrics: LCP (Largest Contentful Paint), INP (Interaction to Next Paint), and CLS (Cumulative Layout Shift).

Note the counts for each status. Compare to last month. GSC uses real-user data (Chrome UX Report) so it may take 4–6 weeks for changes made to the site to be reflected here.

Investigate new "Poor" pages or sudden changes

A gradual change in CWV counts over time is normal as the site evolves. What warrants investigation is a sudden shift — pages that were "Good" now showing as "Poor", or a material increase in the count of "Poor" URLs.

LCP (Largest Contentful Paint) — Poor threshold: >4s Usually caused by large unoptimised hero images, slow server response, or render-blocking scripts. Flag for Page Speed task or developer.

INP (Interaction to Next Paint) — Poor threshold: >500ms Usually caused by heavy JavaScript execution blocking user interactions. Flag for developer.

CLS (Cumulative Layout Shift) — Poor threshold: >0.25 Usually caused by images without dimensions, late-loading ads, or dynamic content injected above existing content. Flag for developer.

CWV and the Page Speed task: If CWV shows persistent "Poor" pages, this is a trigger for the Page Speed task. The GSC error review is not the place to fix CWV — it's the place to detect it. Log the finding and recommend the Page Speed task be scheduled.

Triage & Escalate

After reviewing all five report areas, categorise every finding before logging. Not everything needs action this month.

Classify each finding

Use the following three-bucket classification for every issue found:

Fix now (Hanoi) Issues we can resolve directly — a noindex tag on the wrong page, an incorrect redirect, a missing canonical. Fix it, then log it as "Fixed" in Zoho.

Escalate to Melbourne Issues requiring client or developer action — server errors, mobile layout fixes, CWV improvements, and all manual actions and security issues regardless of severity. Log the finding with enough context that Melbourne can brief the client or developer without needing to re-investigate.

Monitor (no action yet) Issues that exist but are stable and below the action threshold — e.g. a small number of 404s on URLs that were deliberately retired, or CWV in "Needs improvement" (not "Poor"). Log as noted and set a reminder to check again next month.

Fix what you can fix now

Before closing out the task, action anything in the "Fix now" bucket. This includes:

Requesting re-indexing of fixed pages via the URL Inspection tool
Updating robots.txt if a block was introduced incorrectly
Removing erroneous noindex tags if we have CMS access
Validating a fix in GSC if one was submitted last month (check the status has moved to "Fixed")

Log in Zoho

Write the monthly check comment

Add a comment to the relevant Zoho task. The comment should be brief but specific — one line per report area, stating whether it is clear, has stable known issues, or has new findings requiring action.

Coverage / Pages "47 indexed (was 47 last month). 2 soft 404s — same as last month, monitoring. No new errors."

Manual Actions "Clear — no issues detected."

Security Issues "Clear — no issues detected."

Mobile Usability "3 pages with 'text too small' error — same as last month, flagged to Melbourne in [date] comment. No new errors."

Core Web Vitals "Mobile: 12 Good, 4 Needs improvement, 0 Poor. Desktop: all Good. No change from last month."

Actions taken "Removed noindex from /services/roofing/ — had been added during last month's theme update. Re-indexing requested."

Escalations "Nil." — or list each item escalated with a clear action owner.

Done when: All five report areas checked, findings classified, any "Fix now" items actioned, Zoho comment logged with a line per report area, and any escalations sent to Melbourne.

Standards Checklist

Confirm every item before marking the task complete.

Report areas reviewed

Coverage / Pages — error count compared to last month, error types categorised

Manual Actions — checked and result recorded ("clear" or escalated immediately)

Security Issues — checked and result recorded ("clear" or escalated immediately)

Mobile Usability — error count compared to last month, new errors investigated

Core Web Vitals — Good / Needs improvement / Poor counts compared to last month

Triage and logging

Every finding classified: Fix now / Escalate / Monitor

"Fix now" items actioned before closing out

Any manual actions or security issues escalated to Melbourne before proceeding further

Zoho comment written with one line per report area

Escalations explicitly noted in Zoho comment with action owner

Common Mistakes

Mistake	Why it's a problem	What to do instead
Logging "GSC checked — all good" without specifics	This tells the next person nothing. If rankings drop next month, there's no baseline to compare against.	Write a line for each report area with the actual numbers — even if everything is clear.
Looking at totals instead of changes	A site with 50 stable crawl errors is not a problem. A site that went from 2 to 50 errors this month absolutely is.	Always compare to last month's Zoho comment before deciding whether a number is concerning.
Holding a manual action for the monthly report	Manual actions suppress rankings site-wide. Every day without a reconsideration request is a day of lost traffic.	Escalate manual actions and security issues immediately — same day, not at end-of-month.
Treating all "Not indexed" pages as errors	Many pages should not be indexed — thank-you pages, admin URLs, paginated duplicates. Flagging them all creates noise and wasted work.	Distinguish between expected exclusions (these are fine) and unexpected exclusions (service pages, key landing pages). Only act on the latter.
Not checking the URL Inspection tool after fixing an issue	Fixes submitted to Google are not instant. If you don't request re-indexing after fixing a noindex or crawl error, the fix may sit undetected for weeks.	For any URL you've fixed this month, use the URL Inspection tool to request indexing immediately after the fix.
Skipping the check when "nothing major happened this month"	The most damaging issues — robots.txt misconfiguration, a developer's noindex left in production — are invisible until GSC catches them. There is no such thing as a month where you can skip this check.	Run the check every month regardless. The hour is worth it.