If you are hunting for a noindex checker, you want a live read of the meta robots tag and X-Robots-Tag header on one URL, not another essay about “why Google won’t index me.” Site Signals has that check. Run it before you treat a Search Console status as gospel.
On September 8–9, 2026, Search Console briefly labeled pages — including homepages people knew were live — as Crawled - currently not indexed. Glenn Gabe and others flagged it publicly. John Mueller confirmed it was a short reporting blip that resolved overnight, not a mass deindex. That is useful history. It is also the wrong reason to start ripping templates apart.
A reporting bug and a real noindex look the same in a panicked screenshot. Separate them in five minutes.
What actually happened on Sep 8–9
For a short window, the Page indexing report and related views showed “Crawled - currently not indexed” on URLs that were still indexed in results. Mueller’s note on Bluesky the morning of September 9 called it a small blip, said nothing broke on the indexing side, and reminded people it is easy to double-check a homepage before declaring an emergency.
If your API pull or overnight dashboard caught that window, you may still see a scary spike in “not indexed” counts in exports. Rerun the report. Do not ship a remediation plan off a single bad snapshot.
Reporting bug vs real noindex
Search Console status is Google’s view after crawl and processing. A noindex is your instruction, shipped as:
<meta name="robots" content="noindex">(ornoindex, follow) in the HTML<head>- or an
X-Robots-Tag: noindexHTTP response header from the origin, CDN, or edge worker
Those are different problems. A false Search Console label does not mean the page suddenly grew a robots meta tag. A real noindex will keep the URL out (or push it out after the next crawl) even when the dashboard looks calm again.
Also remember: if robots.txt blocks the URL, Google may never fetch the HTML, so it never sees the meta noindex. Blocking crawl and shipping noindex are not interchangeable fixes. For crawl rules, use a robots.txt check separately. For “is this response telling Google not to index?”, use the noindex tool.
Run the free Noindex Tag Checker first
Open the Noindex Tag Checker, paste a production URL, and run it. You want a clear yes/no on the live response: meta robots, X-Robots-Tag, or neither. Staging hosts, preview branches, and “www vs non-www” copies are where accidental noindex usually hides.
Typical real failures the checker is built to catch:
- A leftover
noindexfrom a staging theme that shipped to production - A CDN or WAF edge rule adding
X-Robots-Tag: noindexon a path you thought was public - Plugin “discourage search engines” toggles that write meta robots on every page
- Soft-404 or auth interstitial HTML that includes noindex while the “pretty” URL looks fine in a logged-in browser
If the checker is clean and Google still shows a durable “Crawled - currently not indexed” days later, you are in quality, duplication, or crawl-budget territory — not a robots-meta incident. Fix the wrong layer and you waste the week.
A five-minute triage when Search Console looks scary
- Pick one money URL (homepage or a key service page), not a random thin URL.
- Confirm it still appears with a
site:query or URL Inspection live test. - Run the noindex checker on the exact canonical you care about.
- If noindex is present, remove it at the source (theme, plugin, header, CDN), then request indexing after the next clean crawl.
- If noindex is absent and Inspection says indexed, treat the dashboard spike as reporting noise — especially if it clustered on Sep 8–9, 2026.
Mueller’s point still stands: not every red status is a fire. The discipline is checking the live response before you rewrite content, merge sitemaps, or nuke internal links.
Why the checker beats a View Source glance
View Source only shows the HTML Google would see if it got the same document your browser did. It misses CDN-injected headers, A/B edge variants, and geo or bot-specific responses. The noindex checker is built to inspect the response the tool fetches, including X-Robots-Tag, which never appears in the HTML panel at all.
That matters after a scare like Sep 8–9. Teams paste a homepage into View Source, see no meta robots, and still trust a bad Search Console export. Headers are where many “we never added noindex” incidents actually live — especially on Cloudflare Workers, nginx maps, and “preview protection” rules that outlived the launch.
What not to do after a false not-indexed scare
Do not mass-submit every URL. Do not flip the whole site to “allow all” in a panic plugin. Do not confuse this blip with the August 2026 spam update or with a Core Update. And do not use a robots.txt Disallow as a substitute for noindex — that hides the directive from Google instead of communicating it.
If you also need to verify crawl allow/block rules, Site Signals has a sibling robots.txt checker and a Disallow directive test. Keep those jobs separate from the noindex question.
Ship the check, then decide
The Sep 8–9 Search Console blip was real, short, and confirmed. Real accidental noindex is also real, and it does not announce itself with a press note. Start with the live URL.
Run the free noindex checker on the page you actually care about. If the tag or header is there, fix the response. If it is not, stop treating a reporting blip like a ranking funeral — and dig into quality and duplication only after the robots layer is clean.