Google Search Console Errors Explained: What to Fix First

Google Search Console errors are messages telling you that Google couldn't crawl, index, serve securely or show some of your pages the way you intended. They show up in different reports (Page indexing, HTTPS, Core Web Vitals, rich result reports, Crawl stats, Manual actions and Security issues), and how serious they are varies a lot. Some take your whole site out of search. Others are normal housekeeping.

This guide goes through each report, explains what its messages mean in plain language, and gives you an order for fixing them.

Which Google Search Console errors matter most?

The serious ones are manual actions, security issues and crawl failures that hit the whole site, because they can remove or flag your entire site in search. Next come indexing errors on pages that should rank. Warnings about rich results and Core Web Vitals matter less. Many "not indexed" reasons aren't errors at all.

Here is a rough order of severity:

How much an error matters also depends on which URLs it hits. A 404 on an old tag page you deleted on purpose is fine. A 5xx on your top product category is not.

What do manual actions and security issues mean?

A manual action means a human reviewer at Google found that your site breaks its spam policies. A security issue means Google detected hacked content, malware or deceptive pages. Both can remove pages from results or put warnings on them, so check these two reports before you do anything else.

Manual actions

According to Google's Manual actions report documentation, when a manual action is issued, some or all of the site will not be shown in Google search results. The most common types are:

• Thin content with little or no added value: scraped pages, doorway pages, thin affiliate pages.
• Unnatural links to or from your site: paid links or link schemes.
• Cloaking and sneaky redirects, hidden text and keyword stuffing.
• Structured data issues: markup that doesn't match what's visible on the page or that misleads.
• User-generated spam in comments, forums or profiles.

To fix one, open the description to see which pages are affected, fix every affected page, make sure Google can reach those pages, then click Request Review and explain what you changed. Google says reviews can take several days or weeks.

Security issues

The Security issues report covers hacked content (including code, content and URL injection), malware and unwanted software, and social engineering such as phishing. Affected pages can get a warning label in search results, or a warning page in the browser when someone tries to visit them.

One detail people often miss: Google says fixing only some pages won't get you partly back into search results. Clean the whole site, close the hole that let the attacker in, and only then request a review.

What do page indexing errors mean?

Page indexing errors explain why a specific URL isn't in Google's index. Some of the reasons are real errors: server errors, wrong noindex tags, robots.txt blocks on pages you need. Others describe pages that are correctly left out, such as duplicates and redirects. Fix the first kind only on URLs you actually want indexed.

Google's Page indexing report help lists the reasons. Here they are, grouped by what you should do about them:

The two "currently not indexed" reasons have their own guides: Crawled – currently not indexed and Discovered – currently not indexed. For a full walkthrough of every reason, step by step, see how to fix website indexing problems.

Is "not indexed" always a problem?

No. Google's own documentation says many non-indexed pages are intended: duplicates, redirected URLs, pages you blocked or removed. A site with 2,000 indexed pages and 5,000 "not indexed" URLs can be perfectly healthy if those 5,000 are filter combinations, old redirects and canonicalized variants. The question to ask is whether any URL you want to rank is on the list, not how big the number is.

The report also shows two warnings. "Indexed, though blocked by robots.txt" means Google indexed a URL it couldn't crawl, usually because other pages link to it. If you want it out of the index, allow crawling and add noindex. Robots.txt alone won't remove it (see the robots.txt for SEO guide). "Page indexed without content" means Google couldn't read the page content, often because of cloaking or a format Google can't process.

What do crawl stats host status errors mean?

Host status problems in the Crawl stats report mean Googlebot had trouble reaching your site at all, through robots.txt fetch failures, DNS resolution failures or server connectivity failures. These hit every URL at once, so a recent red status there outranks almost any per-page error.

The Crawl stats report documentation explains the three categories:

• robots.txt fetching. Google needs either a valid robots.txt file or a 404 for it. If the request returns anything else, such as a 5xx or a timeout, Google will slow down or stop crawling until it gets an acceptable response. A firewall rule or CDN setting that blocks /robots.txt for bots can quietly freeze crawling of the whole site.
• DNS resolution. Your DNS server didn't recognize the hostname or didn't respond. Check your registrar, nameservers and any recent DNS migration.
• Server connectivity. The server didn't respond, or sent an incomplete response. This usually comes from overload, rate limiting or bot protection that treats Googlebot as an attacker.

The status colors help you prioritize. Red means recent problems that need checking. Yellow means problems more than a week old. Green means no significant issues.

What do HTTPS report errors mean?

HTTPS report errors mean Google indexed the HTTP version of some pages instead of the HTTPS version, and the report tells you why. Common causes are an invalid certificate, sitemaps or canonicals pointing to HTTP, and HTTPS URLs that redirect back to HTTP or are blocked by robots.txt.

The HTTPS report lists these reasons:

1. HTTP marked with canonical tag: the HTTP page names itself as canonical. Point the canonical to HTTPS.
2. HTTPS has invalid certificate: this usually affects the whole site. Renew or reconfigure the certificate.
3. Sitemap points to HTTP: update the sitemap URLs to HTTPS.
4. HTTPS has redirect: the HTTPS URL redirects to HTTP. Reverse the redirect.
5. HTTPS URL is roboted: a robots.txt rule blocks the HTTPS version.
6. HTTPS not evaluated: there's no HTTPS equivalent, Google chose HTTP as canonical, or other errors stopped the check. Fix the other errors first.

The report is only available for Domain properties and HTTPS URL-prefix properties, and it shows sample URLs rather than a full list. Mixed signals like these often come from the same root cause as duplicate content, so it's worth reviewing your canonical tag setup at the same time.

What do Core Web Vitals and rich result errors mean?

Core Web Vitals "Poor" or "Need improvement" statuses mean real Chrome users had slow loading, slow responses or layout shifts on a group of URLs. Rich result errors mean your structured data has a critical problem, so that item can't appear as a rich result. Neither stops a page from being indexed.

Core Web Vitals report

The Core Web Vitals report uses field data from the Chrome UX Report (CrUX). It groups similar URLs together and labels each group by its worst metric:

Because URLs are grouped, one slow template (for example, all blog posts with a heavy hero image) can put hundreds of URLs into "Poor" at once. Fix the template, not single pages. After you click to start validation, Search Console tracks the group for 28 days. The Core Web Vitals guide covers the fixes.

Rich result status reports

In the rich result status reports, items are valid or invalid. Critical issues ("Why items are invalid") make an item ineligible for rich results. Non-critical issues ("Improve item appearance") don't affect eligibility. Missing required properties are critical, so fix those first. Missing recommended fields are optional.

Remember that some rich result types no longer exist. Google retired HowTo rich results in 2023 and FAQ rich results for all sites in May 2026, so adding that markup won't bring back rich snippets.

Sitemap messages such as "Couldn't fetch" or "Parsing error" have their own breakdown in XML sitemap errors.

How do you fix Search Console errors in the right order?

Work from site-wide to page-level, and from pages that earn money to pages that don't. Check manual actions and security issues, then host status, then indexing errors on your important URLs, then HTTPS, then Core Web Vitals and structured data. Validate each fix in Search Console once it's live.

A practical workflow:

1. Check Manual actions and Security issues. If either has a finding, stop and handle it first.
2. Open Crawl stats → Host status. Fix any recent red status.
3. Filter Page indexing by sitemap. Pick your submitted sitemap in the filter so you see errors on URLs you actually want indexed, not crawl noise.
4. Use URL Inspection on a few sample URLs per reason. Compare the live test with the indexed version to confirm the cause.
5. Fix by template. One noindex in a category template or one robots.txt rule often explains thousands of URLs.
6. Click "Validate fix". Google says page indexing validation usually takes up to two weeks. Core Web Vitals tracking runs for 28 days.

Search Console only shows samples of affected URLs and only for pages Google has tried to crawl. A crawler run over your whole site fills the gaps: it finds the noindex tags, broken redirects and blocked resources behind each message before Google reports them. If you want that cross-check done for you, a free SEORecheck audit crawls your pages and flags indexability, robots.txt, redirect, canonical, HTTPS and Core Web Vitals issues, with example URLs. You can see what that looks like in the sample report.

When the list is long, rank fixes by impact and effort. How to prioritize SEO fixes explains a simple framework for that.

Why do fixed errors come back?

Usually because the cause sits upstream: a CMS plugin update that brings noindex back, a deploy that overwrites robots.txt, or a CDN rule that starts blocking bots again. Google's rich result documentation notes that if an issue comes back within 90 days, the original detection date is kept. After every release, check the settings that break most often. SEO regression testing turns that into a repeatable checklist.

Key takeaways

• Not every Search Console message is an error. Many "not indexed" URLs are excluded on purpose.
• Manual actions, security issues and host status failures affect the whole site, so check them first.
• Judge page indexing errors by which URLs they hit. Filter by your sitemap to see the URLs that matter.
• HTTPS errors almost always come from mixed signals: canonicals, sitemaps or redirects pointing to HTTP.
• Core Web Vitals and rich result problems don't block indexing. Fix them by template.
• Fix, test, then validate. Expect about two weeks for indexing validation and 28 days for Core Web Vitals.