Google Search Console Errors Explained: What Each Report Means

What Search Console is telling you

Google Search Console reports what Googlebot found when it crawled your site, what it chose to index, and how your pages appear in results. Most of what it shows is information, not error. A site with a few hundred pages will nearly always have some URLs listed as not indexed, some structured data warnings and some pages in a Need improvement group. That is normal. The skill is telling the handful of issues that cost you traffic apart from the many that do not.

The reports sit in the left-hand menu in four main areas:

• Indexing: Pages, Video pages, Sitemaps and Removals.
• Experience: Core Web Vitals and HTTPS.
• Enhancements: one report for each type of structured data Google found, such as Breadcrumbs or Review snippets.
• Security and Manual actions: Manual actions and Security issues.

The URL Inspection tool at the top of every screen sits alongside all of these. It shows what Google knows about one URL, and its Test live URL button fetches the page as Googlebot would now.

Which reports need action, and how urgently

Two questions decide whether any issue matters: does it affect a page you want in search results, and is the number growing? A redirect error on a retired campaign page does not matter. A server error on your best-selling product does.

The Page indexing report, status by status

The Pages report splits URLs into indexed and not indexed, then lists a reason for every URL that is not indexed. Google calls each reason an issue, but many describe correct behaviour.

Open any reason to see example URLs and a chart over time. The chart matters more than the total. A steady count of alternate pages is fine. A sudden jump in server errors after a hosting change is not.

Checking an issue from the command line

Before changing anything, confirm what Googlebot sees. Export the example URLs from the report with the Export button, save them as urls.txt, then check the status code and final address of each:

while read -r url; do
  curl -s -o /dev/null -A "Googlebot" -w "%{http_code} %{num_redirects} %{url_effective}  $url\n" -L "$url"
done < urls.txt

Each line shows the final status code, how many redirects were followed and where the URL ended up. Server errors show as 5xx, redirect problems show as a high redirect count or a final 4xx, and soft 404 candidates return 200 with a very small page.

To check for a stray noindex, look at both the HTML and the headers:

curl -sI https://www.example.com/page/ | grep -i x-robots-tag
curl -s https://www.example.com/page/ | grep -io '<meta[^>]*robots[^>]*>'

For a sitemap marked Couldn't fetch, check it loads, returns 200 and is real XML:

curl -sI https://www.example.com/sitemap.xml | head -n 5
curl -s https://www.example.com/sitemap.xml | head -c 300

If the sitemap returns HTML, a login page or a 404, fix that first. The sitemap could not be read guide covers the common causes.

Then use URL Inspection on one example and run Test live URL. If the live test passes but the report still shows the issue, the report is simply out of date and will update after the next crawl.

The other reports in plain terms

Sitemaps

Each submitted sitemap shows a status and a count of discovered URLs. Success means Google read it. A sitemap listing thousands of URLs that are not indexed suggests it includes redirected, noindexed or duplicate pages; it should list only the canonical URLs you want indexed.

Core Web Vitals

URLs are grouped by how real visitors experienced them, for mobile and desktop separately. Fix groups marked Poor first, one template at a time. See Core Web Vitals assessment failed.

HTTPS

Lists URLs Google found that are not served over https. Each should redirect to its https version, or be fixed so it loads securely with a valid certificate.

Enhancements

Each structured data type gets its own report with invalid and valid items. Critical issues make a page ineligible for that rich result. Non-critical issues only mean optional properties are missing, and the page can still show the result. See structured data syntax errors and breadcrumb structured data issues.

Manual actions and Security issues

A manual action means a person at Google found a breach of the spam policies, such as unnatural links or thin, copied content. A security issue means Google detected hacked pages, malware or deceptive content. Both can remove pages from results or add warnings. Fix the cause fully, then use Request review and explain what you changed.

A worked example

A site owner logs in and sees 3,000 pages not indexed against 900 indexed. It looks alarming. Opening the Pages report shows:

• 1,600 alternate pages with proper canonical tag, mostly filtered shop URLs pointing at their category page.
• 900 pages with redirect, left over from a move to https last year.
• 400 crawled, currently not indexed, mainly tag archives and very short product variants.
• 100 server errors, all on the search results template, which times out under load.

The server errors are fixed first by caching the search template and blocking crawl of internal search result URLs in robots.txt. Validation is started. The thin tag archives are set to noindex and the short variants merged into their parent products. The alternate pages and redirects are left alone, because they are doing their job. Two months later the not indexed total is still high, but every page the business wants found is indexed.

The fix, step by step

Edge cases worth knowing

• Reports lag behind reality. Page indexing data can be several days old. Always check a URL with the live test before assuming the issue is still present.
• Example URLs are a sample. Search Console shows up to 1,000 examples per issue. Fix the pattern, not just the listed URLs.
• Property type matters. A URL-prefix property for https://www.example.com/ does not show the non-www or http versions. A domain property covers every protocol and subdomain.
• Validation can fail on new URLs. If more URLs with the same problem appear during validation, it can fail even though your fix worked on the original ones.
• Indexed, though blocked by robots.txt. This means Google indexed the URL from links without crawling it. Blocking does not remove a page; use noindex and allow crawling instead.

Keeping on top of it

Search Console rewards a regular, short routine more than an occasional long one:

1. Every week: check Manual actions and Security issues, and glance at the Pages chart for sudden jumps.
2. Every month: review Page indexing, Sitemaps and Core Web Vitals, and open any issue whose count is rising.
3. After any release that changes templates, URLs, hosting or plugins: inspect a few key URLs with the live test and watch the reports for the next two weeks.
4. Keep notifications reaching you: make sure the owner and full users have a current email address under Settings, Users and permissions, because Google emails them about new issues.

For a wider check of the same problems across your whole site, the site audit guide explains how a crawl finds them before Google reports them.