When someone emails me a screenshot of Google Search Console asking "is this bad?", it is almost always one of about fifteen status messages. Some of them sound alarming and are actually fine. Some of them sound benign and quietly mean nothing on the site is getting indexed. After enough of these conversations I started keeping a personal cheat sheet, and this article is that cheat sheet, cleaned up.
I am going to cover two distinct GSC reports because people mix them up constantly: the Sitemaps report (statuses for the sitemap file itself) and the Page indexing report (statuses for individual URLs that came from your sitemap). For each status I will tell you what it actually means, what triggers it, and what, if anything, to do.
Sitemap-file statuses
These appear at Search Console under Sitemaps. They describe the file, not the URLs inside it.
Success
Google fetched your sitemap, parsed it without errors, and discovered the URLs inside. That is all this status means. It does not mean those URLs are indexed. It does not even mean they will be. I see people ship a sitemap, see Success the next day, and assume the SEO job is done. It is not. Success on the sitemap file just means the file was syntactically valid and reachable.
Worth checking: the Discovered URLs count in the same panel should match, roughly, the number of URLs in your file. If it is much lower, your sitemap probably contains URLs that violate the spec (relative paths, URLs from a different host, URLs over 2,048 characters) and Google silently dropped them.
Couldn't fetch
This is the most common error and it is almost always one of four causes, in order of frequency:
- The URL you submitted does not exist. Triple-check the path. I have watched people submit sitemap_index.xml when the actual file is at sitemap-index.xml. Search Console does not follow redirects gracefully here.
- robots.txt is blocking the sitemap path. A surprising number of sites block /sitemap* accidentally because of a wildcard rule meant to block CMS internals.
- Your server is rate-limiting Googlebot specifically, or returning 5xx on the sitemap URL. Cloudflare's bot fight mode and similar shields cause this. Test from a different IP, then check your logs for 429 or 503 responses to Googlebot's user agent.
- The sitemap is gzipped without the .xml.gz extension or with the wrong Content-Type. Google needs application/xml, application/gzip, or similar, not text/html.
Resubmitting will not help if any of these are true. Fix the cause, then click Validate Fix or just wait. Google retries on its own.
Has errors
The file was fetched but parsing partially failed. Click into the report and you get specific error messages: Invalid URL, URL not allowed (meaning it is outside the property), Compressed sitemap is not gzipped, and a few others. The errors are usually clear enough; the gotcha is that Google only shows the first 10 to 20 errors per file. If your generator is producing systematically broken output, fixing the visible errors and resubmitting can reveal a fresh batch.
Sitemap could not be read
This is a sibling of Couldn't fetch but means the file was fetched and the response was something Google could not make sense of at all. Usually that is HTML (a soft 404 page returning 200, very common with frameworks that catch-all to the homepage), an empty file, or a binary that is not valid gzip.
The diagnostic: open the URL in an incognito window and look at the raw response with View Source. If it is not XML, your routing or generator is the problem.
Pending
You will see Pending briefly after submitting a new sitemap. It means Google has the URL queued but has not fetched it yet. If it stays in pending for more than a few days, it is effectively the same as Couldn't fetch. Something is blocking the actual retrieval.
Page-indexing statuses
These appear under the Pages or Coverage report and apply to individual URLs. This is where the real story lives. The sitemap file can say Success while none of your URLs are getting indexed.
Indexed
The URL is in Google's index and eligible to appear in search results. Note: indexed does not mean ranking. It just means included.
Submitted and indexed
A subset of Indexed. These are URLs that came in via your sitemap (as opposed to URLs Google found by following links). For most healthy sites, this number should be most of what your sitemap contains. A large gap between Submitted (your sitemap) and Submitted and indexed is the headline problem to solve.
Discovered – currently not indexed
This is one of the most misunderstood statuses. It means: Google knows the URL exists (because it is in your sitemap), but has not crawled it yet. It is not a quality verdict. It is a queue.
For new sites and sites with little authority, this status can apply to hundreds of URLs at once and stay that way for weeks. Google's crawl budget for unproven sites is small. Things that move URLs out of this state: external backlinks pointing to specific pages, internal linking from already-indexed pages, manual URL inspection plus Request indexing (capped at around 10 per day per property), and time.
If you have hundreds of URLs sitting here, the answer is rarely "fix the URLs" and almost always "improve site authority and internal linking, then wait."
Crawled – currently not indexed
This one is a quality verdict, dressed up politely. Google fetched the page, looked at the content, and decided not to include it. The reasons in practice:
- The content is thin (under roughly 300 words, or padded with boilerplate)
- The content is near-duplicate of another page on your site or another site
- The page is templated with no unique value (tag archives, faceted-nav permutations, near-empty author pages)
- The page is technically fine but feels low-effort to whatever quality model Google is running
The fix is content, not technical. Adding more pages to your sitemap will not help; in fact, it can hurt by diluting the average quality signal across the property. I usually recommend removing low-quality URLs from the sitemap entirely (or setting them to noindex) before doing anything else.
Submitted URL not selected as canonical
Google indexed a URL, but it is a different URL than the one you submitted. Almost always one of:
- HTTP vs HTTPS mismatch (you submitted http://, Google decided https:// is canonical)
- www vs non-www mismatch
- Trailing slash mismatch
- Tracking parameters in the submitted URL (?utm_source=...)
- Localized variants where Google picked a different language as primary
The fix is to align your sitemap URLs with your actual canonical tags. Run a quick check: pick five URLs from your sitemap, fetch each one, look at the rel canonical link in the head. If the canonical does not match the URL you submitted, the sitemap is wrong.
Duplicate, Google chose different canonical than user
Same idea as above but more pointed: you have a rel canonical declared, and Google ignored it. This happens when the canonical you declared points to a page Google considers a worse match (often: canonical points to a thin index page, but the deep page has more substance).
The fix: re-evaluate which version really should be canonical. Often Google is right.
Excluded by 'noindex' tag
The page has a meta robots noindex tag or X-Robots-Tag noindex header. If you did not intend that, it is a CMS misconfiguration. If you did intend it, take the URL out of your sitemap. Sitemaps should only contain URLs you want indexed.
Page with redirect
The URL returns a 3xx and Google followed it. Not an error per se, but the URL does not belong in your sitemap. The destination URL is what should be there. Redirect chains in sitemaps waste crawl budget and look sloppy in audits.
Soft 404
The page returned 200 OK but Google's heuristics decided it is actually a not-found page (empty product listings, no-results search pages, deleted articles still serving a 200 with "this content is no longer available"). Soft 404s are crawl budget poison.
The fix is to actually return a 404 status code from those URLs, or redirect them to the relevant alive page. Do not argue with Google about whether the page is "really" a 404. Fix the response.
Server error (5xx)
Self-explanatory at face value, less so when it is intermittent. If you only see this on a few URLs, it is likely your origin choking under load or a specific endpoint that times out. If you see it across the board, your server is unhealthy or rate-limiting Googlebot. Check your access logs for 5xx returned to user agents starting with Googlebot.
Not found (404)
URL in your sitemap returns 404. Either your sitemap is generating from stale data, or pages were deleted without updating the feed. Both are easy to fix; both are signs the sitemap pipeline is not tracking actual content state.
Blocked by robots.txt
Google read your robots.txt and your sitemap, saw a contradiction, and respected the robots block. Including blocked URLs in your sitemap is a soft signal of confusion. Clean it up.
Submitted URL has crawl issue
The catch-all status when none of the above apply cleanly. Click into it for the actual error. Usually it is a one-off network failure that resolves itself in a few days. Worth watching, not worth panicking about.
What I actually do when I open Search Console
The order I work through these reports, on every site:
- Sitemap report first. If the file is not being read, nothing downstream matters.
- Submitted vs submitted-and-indexed gap. This is the headline number.
- Crawled – currently not indexed. If this number is large, the problem is content quality, not technical SEO.
- Discovered – currently not indexed. If this is large and Crawled – currently not indexed is small, the problem is crawl budget and authority.
- Canonical mismatches. Quick wins, usually a sitemap-generation bug.
- Soft 404s and redirects in sitemap. Sitemap hygiene.
You can solve a lot just by getting the sitemap to match reality: only canonical, indexable, 200-returning URLs. Everything else compounds.
If you would like more on the diagnostic side, see the companion piece on why your sitemap might not be getting fully indexed.