"Crawled - currently not indexed" means Googlebot fetched the page successfully and then decided not to put it in the index. The fetch worked, the HTML came back, and the decision that followed went against the page. That is the whole content of the string: it reports a state, not a reason. Nothing in those five words tells you whether the cause was a canonical conflict, an orphaned URL, thin content, a duplicate of something you already published, or simply a page that is three days old.
"Discovered - currently not indexed" and "Crawled - currently not indexed" describe two different points in the same pipeline, and confusing them sends people to fix the wrong thing. Discovered means Google knows the URL exists and has not fetched it yet, usually because it found the address in a sitemap or a link. Crawled means the fetch already happened. A page stuck on discovered has a crawl problem — the URL is not being scheduled — while a page stuck on crawled has a selection problem, because Google already spent the request and read the page before saying no.
The practical consequence is that the two states respond to different work. Adding an internal link from a page Google crawls often is the standard move for a discovered URL, because it raises the page's priority in the crawl queue. That same link does much less for a crawled URL, where Google has the content and has already judged it. On a crawled page the question is what about the page, or about the pages around it, made indexing look not worth it.
No, and this is worth stating because coverage strings are easy to parse wrongly. Every one of Google's not-indexed coverage states contains the word "indexed" somewhere in it, so a naive substring test on the word reports the opposite of the truth. Market4's own reader tests for the phrase "not indexed" first and only then for "indexed", so "Crawled - currently not indexed" resolves to false rather than true. Any script or dashboard that reads coverage strings needs the negative test to run first, or it will quietly count every excluded page as a win.
A page can be crawled and left out for reasons that live in the page, in the site around it, or in the timing of the publish. Market4's indexing diagnosis enumerates a fixed list of named causes rather than offering advice, because a closed list is what lets a cause be ruled out as well as ruled in. The list covers robots.txt, a noindex directive, a page the server cannot deliver, a canonical pointing elsewhere, an orphaned URL, a URL in no sitemap, content missing from the server-rendered HTML, thin content, duplication of the site's own corpus, a publish burst, and a page that is simply too new.
The per-site limit is the one that binds: 2,000 calls a day and 600 a minute, counted against the property rather than against the key or the tool that asked.
A page that cannot be delivered is not indexed. A page that loads slowly usually is. The line between those two facts is where most page speed work stops paying for itself, and knowing which side you are on takes two different kinds of measurement.
Market4 turns one release note into a changelog page, a blog post, a mail-out and a week of social posts — and then tells you which of them brought anyone back.
Three of those causes carry a threshold you can check yourself before blaming anything more mysterious. A page whose server-rendered HTML holds too little text is treated as thin. A page that repeats more than half of another page on the same site is treated as a duplicate of its own corpus. A page published within the last 72 hours is treated as too new for the state to mean anything at all, which is the cause most often misread as a problem.
| Threshold | Value | What it decides |
|---|---|---|
| Thin content | 500 characters of server-rendered text | Below it, thin content is offered as a likely cause |
| Corpus overlap | 0.5 of the page repeated from your own pages | Above it, duplication of your own corpus is offered as a likely cause |
| Indexing grace period | 72 hours since publication | Inside it, the page is called too new rather than not indexed |
An indexing diagnosis is only as good as the evidence behind it, so Market4 grades every cause it names on four levels: confirmed, likely, possible and ruled out. Confirmed is reserved for cases where the evidence is definitive on its own — robots.txt forbidding the path, a noindex directive present in the header or the meta tag, Google naming a different canonical. Ruled out is the grade that does the quiet work: telling somebody it is not robots.txt, not a canonical conflict and not a fetch failure removes weeks of guessing, and it is the part nobody can do for themselves from Search Console alone.
Two honesty rules go with the grading and are worth copying into any diagnosis you build. A cause is only stated when evidence for it is present, so absent evidence produces no cause rather than a guess. And null is never collapsed into false: "Google has no record of a link to this page" and "Google has never looked at this page" are different findings, and only the first one is an orphan. Reporting them as the same thing turns a missing measurement into a false accusation.
One thing not on that list is page speed, and its absence is deliberate. None of the named causes of a crawled but unindexed page is a performance metric, which is a strong signal that a slow page and an unindexed page are two different problems with two different fixes. It is also a different state from the one where Google has no record of the URL at all, which is a discovery failure rather than a selection one, and it has a different clock from the ordinary wait before a new post is indexed.
No. It is a selection outcome, not an enforcement action. Google fetched the page, evaluated it alongside everything else it holds, and did not add it to the index this time. The state can reverse on its own without any edit, which is one reason it is a poor thing to react to in the first 72 hours after publishing. A penalty would show up as a manual action in Search Console, which is a different report entirely.
Market4's indexing diagnosis treats any page published within the last 72 hours as too new for the state to be meaningful, and reports that as the cause rather than looking for a fault. Beyond that window the state is worth investigating, but it still is not urgent: a new page can sit in this state for weeks and then be indexed with no change made to it. Reacting inside the grace period usually means editing a page that was going to be indexed anyway.
Rarely, because resubmission addresses discovery and this state is past discovery. Google already fetched the page; asking it to fetch again does not change the judgement that followed the last fetch. Resubmission is the right move for a URL Google has never seen or one whose content changed materially since the last crawl. For an unchanged page in this state it costs quota and returns the same answer.
Yes, and it is one of the named causes. When a page repeats more than half of another page on the same site, that overlap is offered as a likely cause of the page being crawled and left out. This is the failure mode of publishing many near-identical pages quickly: each one is fine on its own and the set competes with itself. The fix is fewer, more distinct pages rather than more of the same shape.
It is direct evidence, not proof, and the distinction matters. An empty list on a page Google has already crawled means Google holds no record of anything linking to it, which is what an orphan looks like. But an absent record is not the same as a confirmed absence of links, which is why a diagnosis should grade the finding rather than assert it. Confirmation comes from agreeing evidence: Google sees no links and your own internal link audit finds none either.
Search Console's regex filters are RE2 expressions, which is a deliberately smaller syntax than the one most regex tutorials teach. What RE2 leaves out, what to write in place of each missing construct, and the two things a filter does not change.
