Google Search Console Errors: How to Find and Fix Every One (2026 Guide)

The quick answer

Most Google Search Console errors come down to one of three things. Google can’t reach the page, Google can reach it but has been told to stay out, or Google visited and decided the page wasn’t worth indexing. The fix is almost always the same routine. Open the report, read the exact reason, run an example URL through the URL Inspection tool, fix the root cause on every affected page, then click Validate fix.

If you’re short on time, work in this order:

1. Manual actions and security issues, because they can pull your site out of Google altogether.
2. Server errors and accidental blocks (5xx, robots.txt, noindex, 403).
3. Indexing problems on pages that earn you money or leads.
4. Sitemap errors.
5. Core Web Vitals.
6. Structured data warnings.

Everything else can wait.

 

Why Search Console errors scare people (and what changed in 2026)

I’ve been doing SEO for Six years, long enough to remember when Search Console was called Webmaster Tools and the crawl errors screen was a short list of 404s you could clear in an afternoon. Today’s version is far more detailed. That’s mostly a good thing. It also means a site owner can open the Pages report, see thousands of grey rows and a few red ones, and assume the site is on fire.

Usually it isn’t. The most useful thing I can tell you before we get into specifics is that “Not indexed” doesn’t mean “broken.” Google’s own documentation says it’s fine for many URLs to stay out of the index, such as duplicates, redirects and deliberately blocked pages. What you want is the canonical version of every important page to be indexed. So the real job is sorting the errors that matter from the ones that don’t, and that’s what this guide does.

It also helps to know what has changed, because plenty of older tutorials are now out of date:

• The Mobile Usability report was retired on December 1, 2023, along with the Mobile-Friendly Test.
• The Page Experience report was removed too, while the Core Web Vitals and HTTPS reports stayed.
• FAQ rich results stopped appearing in Google Search on May 7, 2026, and the matching Search Console report was dropped in June.
• On June 3, 2026, Google launched Generative AI performance reports showing how often your pages appear in AI Overviews and AI Mode.

Every error below follows the same pattern: what it means, why it happens and how to fix it.

 

How to read Search Console errors before you fix anything

“Error,” “warning” and “Not indexed” aren’t the same thing. In the Page indexing report, “Not indexed” mixes real errors with perfectly legitimate exclusions. Check the Source column too. It shows whether the cause sits with your website or with Google, and generally you can only fix the website ones.

Treat URL Inspection as your microscope. Paste a URL into the bar at the top of Search Console and you’ll see what Google last indexed. Click Test live URL and you’ll see what Google sees right now. One catch: the live test doesn’t check duplicate or canonical conditions, so a clean result doesn’t guarantee the page will be indexed.

Fix every instance before you validate. Validation stops the moment Google finds a single remaining instance of the problem. It usually takes up to about two weeks, sometimes much longer, and Google asks you not to click the button again until the current run has passed or failed. Here’s a trick most people miss: submit a sitemap containing only your most important affected pages, filter the report by that sitemap, then request validation. A smaller batch tends to finish faster.

Know the limits. Example lists stop at 1,000 URLs and aren’t guaranteed to be complete. An issue stays in the table until 90 days after its last instance disappears. The data also isn’t real time, so check Google’s Search Status Dashboard before assuming a sudden change is your fault.

Small site? Relax a little. Google says that if your site has fewer than about 500 pages, you probably don’t need the Page indexing report. A few site:yourdomain.com searches will show whether your key pages are indexed.

Page missing from every report? That usually means Google hasn’t found it. Link to it from an indexed page, add it to your sitemap, and give it a few days.

 

Page indexing errors: what every status means and how to fix it

Go to Indexing → Pages and scroll to the “Why pages aren’t indexed” table. Here’s the whole list at a glance, followed by a walkthrough of each status.

Status	Usually a problem?	Quick fix
Server error (5xx)	Yes	Fix hosting, firewall or crashing code
Redirect error	Yes	Collapse chains, remove loops
URL blocked by robots.txt	Only if you want it indexed	Edit robots.txt
URL marked ‘noindex’	Only if you want it indexed	Remove the noindex
Soft 404	Yes	Return a real 404/410, or add real content
Not found (404)	Rarely	301 only if a replacement exists
Unauthorized (401) / Forbidden (403)	Yes, for public pages	Remove auth or stop blocking Googlebot
Other 4xx issue	Investigate	Inspect the URL
Crawled – currently not indexed	Often	Improve quality and internal links
Discovered – currently not indexed	Often	Improve crawl efficiency and server speed
Alternate page with proper canonical tag	No	Nothing
Duplicate without user-selected canonical	Sometimes	Add canonical tags
Duplicate, Google chose different canonical than user	Sometimes	Align your signals
Page with redirect	No	Update links and sitemap
Indexed, though blocked by robots.txt	If unintended	Use noindex, not robots.txt
Page indexed without content	Yes	Fix rendering or cloaking

 

Server error (5xx)

What it means: Googlebot couldn’t get the page because your server returned a 500-level error, timed out, or was too busy.

Why it happens: Overloaded shared hosting, a crashing plugin or database, painfully slow dynamic pages, or a firewall that mistakes Googlebot for an attacker. That last one catches people out because Googlebot often sends more requests than a human visitor, which can trigger protection systems.

How to fix it: Open Settings → Crawl stats and check host availability to see whether this is a one-off blip or a pattern. Match the error times against your server logs. Then work through the usual suspects: better hosting or caching, the plugin that conflicts, parameter-heavy URLs, and WAF or CDN rules that should let verified Googlebot through. Server errors can be temporary, so a live test may pass even though the crawl failed. If it passes now, validate the fix and keep an eye on it.

Redirect error

What it means: Google followed your redirect and gave up. That happens with chains that are too long, loops, targets that exceed the maximum URL length, or an empty or malformed URL in the chain.

Why it happens: Usually two redirect rules fighting each other, like a server rule forcing HTTPS while a plugin forces the old version, or a trailing-slash rule and a no-slash rule bouncing a URL back and forth. I’ve seen sites where the host, a caching plugin and the CDN were all “helping” redirect the same URL.

How to fix it: Trace the path with curl -IL https://example.com/page or a crawler such as Screaming Frog. Point the first URL straight at the final destination with one 301, delete the conflicting rule, and update internal links so nothing enters the chain in the first place.

URL blocked by robots.txt

What it means: Your robots.txt file told Googlebot not to crawl the URL.

Why it happens: Sometimes it’s intentional (admin areas, cart pages, internal search). Sometimes it’s an accident. The worst version is a developer pushing the staging site’s blanket Disallow to the live server on a Friday afternoon, with nobody noticing until Monday’s traffic report. Over-broad rules like Disallow: /blog do similar damage, as does a CMS setting that discourages search engines.

How to fix it: Open your live robots.txt, find the rule matching the URL, and remove or narrow it. Check the robots.txt report under Settings to confirm Google fetched the new version. If the block was deliberate, leave it, but remember that robots.txt controls crawling, not indexing. To keep a page out of Google, use a noindex tag and let Google crawl the page so it can see that tag. Also make sure you aren’t blocking the CSS and JavaScript files Google needs to render your pages.

URL marked ‘noindex’

What it means: Google found a noindex directive and respected it. That directive can sit in a meta robots tag or an X-Robots-Tag HTTP header. If you wanted the page hidden, congratulations. If not, it’s a self-inflicted wound.

Why it happens: WordPress’s “Discourage search engines from indexing this site” checkbox, a per-page setting in an SEO plugin, a staging header that survived the launch, or a CDN rule that adds the header.

How to fix it: Check the page source and the response headers, because noindex can hide in either. Remove it, run Test live URL, confirm “Indexing allowed?” now says yes, then click Request indexing. Also make sure the page isn’t sitting in your sitemap while still carrying a noindex, which sends Google mixed signals.

Soft 404

What it means: The page returns a normal status code but reads like a “not found” page to Google. Think empty categories, out-of-stock products with no content, “no results” pages and thin pages with an error message.

Why it happens: Badly configured templates, JavaScript content that never loads for Googlebot, or mass-redirecting dead URLs to the homepage.

How to fix it: If the page is truly gone, return a real 404 or 410. If it should exist, add proper content, then use the live test and View tested page to see what Google actually receives. Redirect only when a genuinely equivalent page exists. Sending everything to the homepage usually just swaps one soft 404 for another.

Not found (404)

What it means: Google requested the URL and got a 404.

Why it matters, or doesn’t: Most of the time it doesn’t. Google’s advice is to fix only the 404s you link to yourself or list in a sitemap, and to use a redirect when a page has moved. Google keeps checking old URLs for a while, then less and less often.

How to fix it: Sort the list by importance. If a dead URL still has backlinks, internal links or search traffic, 301 it to the closest replacement. If it’s a broken internal link, fix the link. If it’s neither, leave it alone. Do check that your custom 404 page returns a genuine 404 status, not a 200.

Blocked due to unauthorized request (401)

What it means: The page demanded authorization, so Googlebot was blocked.

How to fix it: If the page should be public, remove the login requirement. If it’s genuinely private, like staging or a members’ area, leave it, because Google shouldn’t index it anyway. Open the URL in an incognito window to see what a stranger sees. If you must let Googlebot through a login wall, verify its identity properly instead of trusting the user-agent string.

Blocked due to access forbidden (403)

What it means: Your server refused the request. Google treats this as a misconfiguration because Googlebot never supplies credentials.

Why it happens: Security plugins, WAF rules, bot-protection modes, hotlink protection, or geo-blocking that rejects traffic from the regions Googlebot crawls from (mostly the US).

How to fix it: Check your firewall and CDN logs for blocked Googlebot requests, relax the rule, and allow verified Googlebot traffic. Then retest with the live inspection.

URL blocked due to other 4xx issue

This is a catch-all for 4xx responses that don’t fit any other category. It’s often an unusual response from a firewall or bot manager. Inspect the URL, note the exact response code in the live test, and work out which layer (server, CMS or CDN) is sending it.

Crawled – currently not indexed

This is the status that keeps SEOs up at night.

What it means: Google crawled the page but didn’t index it. It may or may not be indexed later, and you don’t need to resubmit it.

Why it happens: In my experience this is a quality or value verdict far more often than a technical fault. The usual culprits are thin or near-duplicate pages, mass-produced pages (human- or AI-written) that add nothing beyond what already ranks, tag and filter archives, weak internal linking, and pages on a site Google doesn’t yet trust much on that topic.

How to fix it:

• Ask whether the page deserves to be indexed. Tag pages, thin location pages and old thank-you pages often don’t.
• Search the target query yourself. If the top results offer something yours doesn’t, such as original data, first-hand experience or a clearer answer, close that gap.
• Rewrite for the searcher’s intent, not the keyword. Add what only you can add: examples, screenshots, numbers, a named author with real credentials.
• Add internal links from relevant, already indexed pages with descriptive anchor text, and link from a hub or category page.
• Consolidate overlapping pages. Merge them, 301 the weaker one into the stronger one, or noindex pages with no search value.
• Be patient. Hammering Request indexing doesn’t change Google’s opinion of quality.

Discovered – currently not indexed

What it means: Google knows the URL exists but hasn’t crawled it. Google usually wanted to crawl it but expected that to overload your site, so it rescheduled, which is why the last crawl date is empty.

Why it happens: Slow or struggling servers, large sites flooding Google with low-value URLs (faceted filters, parameters, calendars), brand-new sites with little crawl demand, and pages with almost no internal links.

How to fix it: Improve server response time first. Then cut crawl waste: block or noindex junk parameter URLs, fix redirect chains, and keep your sitemap limited to canonical, indexable URLs. Strengthen internal links to the stuck pages and publish consistently. On small sites this often clears within a few weeks. For a handful of critical pages, Request indexing is fine.

Alternate page with proper canonical tag

What it means: This URL is an alternate version of another page, such as a mobile or AMP variant, and it correctly points to a canonical page that’s indexed. There’s nothing to do. Search Console also doesn’t detect alternate-language pages in this status. The only time to act is when the canonical points somewhere wrong, like every product page canonicalizing to the homepage. That’s a classic side effect of a misconfigured SEO plugin or theme.

Duplicate without user-selected canonical

What it means: Google found a duplicate, you didn’t say which version you prefer, so Google picked one and left this one out. It isn’t strictly an error, it’s Google doing its job. But you’ve given up control.

How to fix it: Add a self-referencing rel=canonical to every indexable page. Redirect true duplicates with a 301 (HTTP to HTTPS, www to non-www, trailing slashes, tracking-parameter URLs). If two pages that look alike are meant to be different, make the content meaningfully different.

Duplicate, Google chose different canonical than user

What it means: You declared a canonical, but Google thinks another URL is the better one and indexed that instead.

How to fix it: Inspect the URL and compare the user-declared canonical with the Google-selected canonical. Then work out why they differ: near-identical content, a canonical target that doesn’t match the page, or conflicting signals from internal links, sitemap entries or redirects. Make the canonical tag, internal links, sitemap and redirects all name the same preferred URL. If Google’s choice is actually the better page, accept it. You may also see the older label “Duplicate, submitted URL not selected as canonical.” Same disease, same cure.

Page with redirect

What it means: The URL redirects somewhere else, so only the target can be indexed, not this URL. It isn’t an error. The clean-up job is to update internal links and sitemap entries so they point to the final destination. That saves crawl effort and removes noise from your report.

Warning: Indexed, though blocked by robots.txt

Google indexed the URL without crawling it, usually because other pages link to it, so snippets will be thin. If you want it out of Google, remove the robots.txt block and add noindex. If you want it in, simply unblock it.

Warning: Page indexed without content

Google indexed the page but couldn’t read its content, possibly because of cloaking or an unsupported format. Content that only appears after a click or fails to render can also trigger this. Use URL Inspection to view the crawled page and screenshot, and compare it with what users see. Make sure the main content is in the rendered HTML, don’t block your JS and CSS, and use server-side rendering or prerendering for JavaScript-heavy pages.

 

Sitemap errors in Search Console

The Sitemaps report gives each submitted file one of three statuses: Success, Has errors (it could be read, but with problems) or Couldn’t fetch. It only lists sitemaps you submitted through the report or the API, so ones Google found via robots.txt won’t appear.

If you see “Couldn’t fetch,” the usual suspects are a robots.txt block, a wrong URL returning a 404, server trouble, an unresolved manual action (sitemaps aren’t read while one is open), or low crawl demand for the file. Run the exact sitemap URL through URL Inspection, fix what it reports, then resubmit.

If you see “Has errors,” click the sitemap and read the specific message. These are the ones commonly encountered based on Google’s documentation:

Error	How to fix it
URLs not accessible / URLs not followed	Remove URLs that redirect, 404 or are blocked; list absolute final URLs, not relative links.
URL not allowed	Every URL must share the sitemap’s protocol and host, and sit at or below its folder.
Path mismatch (www or non-www)	Make the URLs inside the file match the host the file is served from.
Compression error	Re-gzip the file and upload it again.
Too many URLs / File size error	Stay under 50,000 URLs and 50 MB uncompressed per file; split the file and use a sitemap index.
Invalid date	Use W3C datetime format, like 2026-10-07 or a full timestamp with timezone.
Invalid URL / Parsing error	Escape special characters (& becomes &) and remove spaces and stray quotes.
Incorrect namespace / Unsupported format / Leading whitespace	Use the standard sitemap namespace and straight quotes, and start the file with the XML declaration.
Sitemap contains URLs blocked by robots.txt	Unblock the URLs or take them out of the file.
Temporary error	Wait a few hours; resubmit only if it persists.

What a healthy sitemap contains: only canonical, indexable URLs that return a 200 status. No redirects, no noindex pages, no 404s. Keep lastmod honest, because Google ignores priority and changefreq anyway. Reference the sitemap in robots.txt as well. You need owner permission to submit it in the report; without that, list it in robots.txt instead. And remember that the “Discovered pages” count only shows how many URLs were parsed, not how many will be crawled or indexed.

 

Core Web Vitals errors (Poor and Needs improvement)

The Core Web Vitals report groups your URLs by status (Poor, Needs improvement, Good), by metric (LCP, INP, CLS) and by group of similar pages, using real-user field data. A group takes the status of its worst metric, so poor CLS with good INP still makes the group Poor. Mobile and desktop are reported separately, and the gap between them is often big.

The thresholds are measured at the 75th percentile of real visits:

Metric	Good	Poor
Largest Contentful Paint (LCP)	2.5 s or less	Over 4 s
Interaction to Next Paint (INP)	200 ms or less	Over 500 ms
Cumulative Layout Shift (CLS)	0.1 or less	Over 0.25

(INP replaced First Input Delay in March 2024, so any tutorial still talking about FID is out of date.)

Fixing LCP: Find the LCP element, usually the hero image or main heading, in PageSpeed Insights. Compress it and serve a modern format such as WebP or AVIF. Set explicit dimensions, preload it or mark it as high priority, and never lazy-load it. Lazy-loading the LCP image is a very common mistake. Then work on server response with caching, a CDN and better hosting, and remove render-blocking CSS and scripts from above the fold.

Fixing INP: INP measures how quickly the page responds to taps and clicks across the whole visit. Break long JavaScript tasks into smaller chunks, remove or delay third-party scripts (chat widgets, heatmaps, surplus tag-manager tags), and trim your DOM size. Test interaction-heavy pages like forms and search results, not only the homepage, because those are usually the worst offenders.

Fixing CLS: Set explicit width and height on images, iframes and video. Reserve space for ads, embeds and cookie banners. Preload key fonts and use font-display: swap. Never inject new content above content that’s already visible.

Be patient. Field data is a rolling 28-day window, so even a perfect fix takes around four weeks to show. Low-traffic URLs may not have enough data to appear at all.

Two honest notes: First, since the Mobile Usability report is gone, use Lighthouse and a real phone to check mobile usability. Second, don’t over-invest. Google has said a good page experience can contribute to success in Search, but the most relevant content still comes first. Fix real slowness. Don’t chase the last 50 milliseconds.

 

HTTPS report errors

The HTTPS report is available only for Domain properties and HTTPS URL-prefix properties. It lists indexed HTTP URLs and explains why the HTTPS version isn’t being used. The errors are:

• HTTP marked with canonical tag: the HTTP page names itself as canonical. Point the canonical to the HTTPS URL.
• HTTPS has invalid certificate: renew or repair the certificate (expired, wrong hostname, incomplete chain).
• Sitemap points to HTTP: update your sitemap to list HTTPS URLs.
• HTTPS has redirect: the HTTPS URL redirects back to HTTP. Fix the rule.
• HTTPS URL is roboted: unblock it in robots.txt.
• HTTPS not evaluated: fix the other errors first. This is often a site-wide certificate or availability problem, or Google simply hasn’t crawled the HTTPS version yet.

While you’re there, force HTTPS site-wide with a single 301 and clean up any mixed content (HTTP images or scripts on HTTPS pages).

 

Structured data and rich result errors

Depending on your markup, you’ll see enhancement reports such as Product snippets, Merchant listings, Breadcrumbs, Videos, Events or Job postings. Errors make an item ineligible for rich results. Warnings flag optional improvements. Google publishes a list of common rich result messages with fixes. These are the ones seen most often:

• Missing field “X”: add the property. An empty string counts as missing.
• Invalid object type / Invalid value type for field: use the type Google expects, such as a URL string where an object is wrong.
• Either “X” or “Y” should be specified: provide at least one of the listed properties and check the feature’s documentation for the exact rule.
• Invalid datetime, missing timezone or not ISO 8601: supply a full ISO 8601 value including the time zone.
• Invalid price format / Invalid ISO 4217 currency code: give the price as a clean number and the currency as a code such as USD or INR.
• No global identifier provided: products need at least one of gtin, mpn or isbn.
• Duplicate field: define each property once per object.
• Invalid or unsupported @context: Google supports only the standard schema.org-style contexts and doesn’t support custom remote JSON-LD contexts.
• Data-vocabulary.org deprecated: migrate to schema.org.

My workflow: test the live URL in the Rich Results Test, fix the JSON-LD, redeploy, retest, then click Validate fix. Keep your markup matching what visitors can see. Marking up invisible, irrelevant or misleading content can trigger a structured data manual action.

What’s been retired (not an error): if a report vanished from your account, nothing is wrong with your site. FAQ rich results stopped showing on May 7, 2026, and the FAQ report, search appearance filter and Rich Results Test support were dropped in June. The FAQPage markup type itself isn’t deprecated, so valid markup won’t throw errors. It just won’t earn the rich result. HowTo rich results went earlier, and practice problem markup was deprecated in November 2025. In June 2025 Google also phased out seven types: Book Actions, Course Info, Claim Review, Estimated Salary, Learning Video, Special Announcement and Vehicle Listing, and reporting for six of them left Search Console. Rankings aren’t affected, and you can keep the markup.

 

Video indexing and AMP errors

Google indexes only one video per page, and only from a “watch page” where the video is the main reason to visit. The main reasons you’ll see for “No video indexed”:

• Video isn’t on a watch page: a blog post where the video merely supports the text doesn’t qualify. Make the video the main content or build a dedicated page.
• Cannot determine video position and size: the player loads only after a click, often behind a placeholder image. Load the real player at its true size when the page opens.
• Thumbnail problems (missing, wrong format, invalid size, blocked by robots.txt, unreachable): supply a crawlable thumbnail in a supported format and size.
• Video not found on host service: the video is private, deleted or the ID is wrong.
• MRSS failure: switch to schema.org VideoObject markup.

Always confirm that the page itself is indexed first, because a video can’t be indexed from a page that isn’t.

If you still run AMP, the AMP report lists validation errors that you fix tag by tag. Honestly, if AMP no longer earns its keep, retiring it is often the cleaner fix.

 

Manual actions: when a human at Google penalizes your site

A manual action means a human reviewer decided some or all of your pages break Google’s spam policies, and the affected pages may rank lower or disappear from results. You’ll find it under Security & Manual Actions → Manual actions and in your Search Console messages. Check this report first, every time.

Manual action	What to do
Major spam problems	Remove scaled content abuse, cloaking and other repeated violations
Unnatural links to your site	Get the links removed or nofollowed; disavow only what’s left
Unnatural links from your site	Remove paid or exchanged links, or qualify them with nofollow or sponsored
Thin content with little or no added value	Remove or substantially improve thin affiliate, scraped and doorway pages
Cloaking and/or sneaky redirects	Show Google and users the same content; remove conditional redirects
Hidden text and/or keyword stuffing	Reveal or delete hidden text; clean repeated keywords from titles and alt text
User-generated spam	Remove spammy posts and profiles; add moderation, rel="ugc" and CAPTCHA
Site abused with third-party spam	Clean up forums, uploaders and internal search pages; block spammy terms; patch vulnerabilities
Spammy free host	Hosting providers must clean up abusive accounts
Structured data issue	Remove misleading or invisible markup so it matches visible content
Cloaked images	Show the same images to Google and to visitors
AMP content mismatch	Make the AMP and canonical content essentially the same
Sneaky mobile redirects	Audit third-party scripts and ads; remove mobile-only redirects; check for hacks
Site reputation policy	Move, noindex, redo as first-party, or remove the third-party content
Back button hijacking	Remove code that manipulates browser history
News and Discover policy violations	Fix the specific policy named and document changed editorial practices

The review process:

1. Expand the action to see which URL patterns are affected.
2. Fix every affected page, because fixing only some earns no partial return.
3. Make sure Google can reach the pages (no login, robots.txt block or noindex).
4. Click Request review and explain the exact issue, the steps you took and the outcome.

Don’t resubmit before you get a decision. Reviews can take several days or weeks, and link-related ones longer. For link problems, ask site owners to remove or qualify the links first. Blindly disavowing everything isn’t seen as a good-faith effort. If you bought the site recently, say so in your request.

A traffic drop with no manual action is usually algorithmic, and there’s no review button for that. Google released core updates in March and May 2026 and spam updates in March and June. Line up the date of your drop against those, then honestly improve the pages that lost.

 

Security issues: hacked sites, malware and deceptive pages

The Security issues report is separate from manual actions. It flags signs your site was hacked, or behavior that could harm visitors, such as phishing or malware. The categories include hacked content (injected code, content or URLs), malware, deceptive pages, and harmful or uncommon downloads.

Don’t just chase the warning. Find the way in:

1. Identify the entry point, often an outdated plugin or theme, a weak or reused password, or a compromised hosting account.
2. Restore a clean backup, or remove injected files, database entries and spam pages.
3. Update everything, rotate every password and API key, and switch on two-factor authentication.
4. Check for rogue admin users, unfamiliar cron jobs and strange .htaccess rules.
5. Request a review in the report once the site is clean.

If a site:yourdomain.com search shows pages about pharmacy or casino keywords you never wrote, you’ve found the classic sign.

 

Crawl Stats: the report most people never open

Go to Settings → Crawl stats and look at host status, which covers robots.txt fetching, DNS resolution and server connectivity. Google points to the host status verdict when diagnosing server errors. A red mark there explains many mysterious indexing drops. A robots.txt file that returns server errors can make Google back off from the entire site, so keep that file fast and always available. The fixes are rarely glamorous: reliable DNS, uptime monitoring, a CDN or firewall that doesn’t block Googlebot, and enough server capacity for crawl spikes.

 

Property verification and permission problems

This is boring, but it blocks everything else.

• Use a Domain property if you can. Verified with a DNS TXT record, it covers every protocol and subdomain, so you won’t miss data because you only added the http://www version.
• DNS verification failing? The TXT record is usually on the wrong host or hasn’t propagated. Check the record, wait out the TTL and verify again.
• Lost verification? Meta-tag and HTML-file methods break when someone swaps the theme, caches the head aggressively or deletes the file. Leave the token in place permanently and add a second verification method as a backup.
• Can’t submit a sitemap? Only owners can do it in the report, but others can list the sitemap in robots.txt.
• Sitemap not showing up? You’re probably looking at the wrong property, such as http versus https or www versus non-www.
• “No data” on a brand-new property? That’s normal. Give it a few days.

 

My 20-minute weekly Search Console routine

1. Manual actions and Security issues: Thirty seconds, and the only place where bad news can wipe out everything else.
2. Pages report: Look at the trend, not the totals. The sparkline next to each reason helps you see which status caused a spike in errors or a drop in indexed pages.
3. Sitemaps: Everything on Success? Does the discovered count roughly match the number of indexable pages you expect?
4. Core Web Vitals: Any new Poor group?
5. Performance: Compare clicks and impressions with the previous period, and check which pages and queries dropped. If you have access, glance at the Generative AI report too.
6. Change log: Write down every deployment, plugin update and robots.txt edit. Most “mystery” indexing crashes trace back to a release.

After any major deployment, check the Pages report within a week. Not a month.

 

Will fixing these errors help you show up in ChatGPT and Gemini?

Honestly, nobody can promise you a place in an AI answer, and anyone who does is guessing. What I can say is that clean indexing is the entry ticket. Google says a page must be indexed and eligible to appear in Search with a snippet to be a supporting link in AI Overviews or AI Mode, and that no special optimization is required. So every fix above doubles as an AI visibility fix. A page that’s noindexed, blocked or stuck at “Crawled – currently not indexed” can’t be a source. Snippet limits matter too, because controls like nosnippet and max-snippet restrict what these features can show.

Beyond the technical fixes, this is what I’d do:

• Audit bot access: Look in robots.txt, your CDN and any security plugin for blanket AI-crawler blocks you didn’t choose, since some tools now switch them on by default. OpenAI publishes a crawler called OAI-SearchBot for ChatGPT’s search features, and blocking it can keep you out of those answers.
• Write answer-first: Put the direct answer in the first sentence or two under each heading, then add the detail. Readers skim that way, and so do systems that lift passages.
• Use question-style headings that match how people phrase the problem.
• Show real experience: A named author, dates, your own screenshots and specific numbers are hard to fake and easy to trust.
• Keep it fresh: Update the page when Google changes a report, and show the date.
• Skip the gimmicks: Google has said llms.txt files won’t help or hurt you in Google Search.

And measure it. Since June 3, 2026, Search Console has had Generative AI performance reports for AI Overviews and AI Mode. Access has been widening since launch, and the reports show impressions rather than click data. Google’s John Mueller has explained that an impression counts only when a link to your site is actually shown.

 

Frequently Asked Questions

How long does “Validate fix” take in Search Console?	Google says validation typically takes up to about two weeks, though it can take much longer. You’ll get an email when it passes or fails. Don’t restart it until the current run finishes.
Do I need to fix every error in Search Console?	No. Many “Not indexed” reasons are intentional or harmless: duplicates, redirects, noindexed pages and old 404s. Fix the errors on pages that matter for traffic, leads or revenue, and leave the rest.
Why are my good pages “Crawled – currently not indexed”?	Google fetched them but judged them not valuable enough, or too similar to existing pages, for now. Improve originality and depth, add relevant internal links, consolidate overlapping pages and give it time. Resubmitting rarely helps.
How do I fix “Discovered – currently not indexed”?	Google knows the URL but hasn’t crawled it, often to avoid overloading your server. Speed up your server, remove low-value URLs that waste crawl effort, strengthen internal links and keep your sitemap clean.
Does Request indexing guarantee indexing?	No. Indexing is never instant, even after a direct crawl request, and Google doesn’t guarantee that every page makes it into the index. Think of it as a nudge, not a command.
Where did the Mobile Usability report go?	Google retired it on December 1, 2023, together with the Mobile-Friendly Test and its API, and points people to Lighthouse instead.
Why did my FAQ rich results report disappear?	Google stopped showing FAQ rich results on May 7, 2026, and removed the report in June. Valid FAQ markup doesn’t cause errors. It just won’t produce the rich result anymore.
Will fixing Search Console errors improve my rankings?	Fixing errors gets blocked or ignored pages into the index and removes obstacles. It doesn’t rank a page higher by itself. Rankings still depend on relevance and quality, so treat indexing fixes as a prerequisite, not a guarantee.
How often should I check Search Console?	Weekly for most sites. Check daily during migrations, launches or traffic drops, and always after a major deployment.

 

Final thoughts

After Six years, I still open Search Console every Monday morning. I don’t expect disaster. Small problems are cheap to fix on day one and expensive on day ninety. The pattern never changes: read the exact reason, inspect a real URL, decide whether the page matters, fix the cause rather than the symptom, validate, then leave it alone long enough for Google to respond.

Don’t chase a spotless report. Chase a site where the pages that matter are crawlable, indexable, fast and genuinely useful. Do that, and most of the errors above either never show up or take five minutes to clear.