This status is not a quality problem. Google hasn't even read the page yet — it knows the URL exists and keeps deciding other pages are worth its time more. That distinction changes the entire fix list. Based on daily index monitoring across 16 production sites and 15,000 URLs.
Google found the URL — from your sitemap, an internal link, or an external one — and put it in the crawl queue. Then it didn't crawl it. The page has never been fetched, never been evaluated, never been judged on quality. It is waiting in line, and the line isn't moving.
Google's own documentation on crawl budget describes the two forces at play:
So "Discovered — currently not indexed" is Google saying: I know this exists. I haven't been convinced it's worth fetching.
These two statuses get lumped together in every "fix your indexing" checklist, and that's why so much advice fails. They have almost nothing in common.
| Discovered — currently not indexed | Crawled — currently not indexed | |
|---|---|---|
| Did Google fetch the page? | No, never | Yes |
| What's the verdict about? | Priority: not worth crawling yet | Quality: crawled, judged, rejected |
| Main causes | Weak internal linking, low crawl demand, publishing volume, young domain | Thin or duplicate content, no differentiation, low page-level importance |
| What fixes it | Links from crawled pages, authority, pacing | Better content first — then links |
| Typical timeline | Days to weeks once discovery improves | Weeks to months, requires editorial work |
The practical consequence: rewriting a "Discovered" page is usually wasted effort. Google never saw the old version, so it cannot compare. And adding links to a "Crawled — not indexed" page rarely helps on its own, because the page already lost on merit.
The most common cause by far. A URL that appears only in your sitemap has told Google nothing about its importance. Google's guidance is blunt: links are how it discovers pages, and every page you care about should be reachable from at least one other page. In practice there's a hierarchy: a contextual link inside the body of a frequently-crawled article is worth far more than the same link in a sitewide footer, which Google discounts precisely because it appears everywhere.
Dropping 140 articles in a month on a domain Google barely knows doesn't get you 140 crawls — it gets you a backlog. Crawl demand grows with trust and time. Sites that publish steadily tend to see far more of their new URLs crawled than sites that publish in bursts.
New domain, no backlinks, no history — Google has no reason to spend crawl resources. This is a real constraint and no plugin removes it. What you can control is which of your pages get the limited attention you do earn.
Faceted navigation, ?page= and ?filter= variants, tag archives, session parameters, soft 404s. Google spends real crawl capacity on these and has less left for the pages you care about. On a large site this alone can bury a section for months.
If your TTFB climbs when Googlebot crawls harder, Google backs off — that's the crawl-capacity side. Less common than people think, but easy to check in Search Console's Crawl stats report.
This is the single highest-leverage move, and the emphasis matters: from pages Google already crawls often. A link on a page that was last fetched four months ago does nothing. Your homepage, your top-traffic articles, your category hubs — that's where a new link gets seen within days.
We measured this on our own network of 12 production sites. URLs that got surfaced as internal links from already-crawled pages, versus comparable not-indexed URLs on the same sites in the same window, both measured from publication date:
| Metric | Surfaced as internal links | Not surfaced |
|---|---|---|
| Reached the index | 68% (2,278 / 3,329) | 41% (3,350 / 8,257) |
| Indexed within 30 days of publishing | 42% | 38% |
| Median time from being linked to indexed | 3 days | — |
Two honest caveats. This is observational data, not a randomized trial. And the selection runs against the linked group: those links went to the most neglected URLs first — pages Googlebot had never fetched, or hadn't returned to in months. The full methodology, including where the measurement is weak, is in our case study.
When you have hundreds of not-indexed URLs, order matters. Pages Googlebot has never fetched need discovery help most; pages it hasn't revisited in months come next; recently crawled pages can wait. The lastCrawlTime field from the URL Inspection API gives you this ordering for free — and it's the ordering our widget uses.
Authority raises crawl demand across the whole site. You don't need dozens: founders regularly report meaningful crawl increases after a handful of genuine links from sites Google itself crawls frequently. Test any directory or site with site: first — if Google barely indexes it, it can't pass anything to you.
Noindex or block the parameter and archive URLs that no one should land on. Fix redirect chains. Remove soft 404s. On big sites this frees measurable crawl capacity for pages that matter.
If you're publishing more than Google crawls, publishing more won't fix it. Fewer, better, well-linked pages beat a backlog every time.
Pinging your sitemap. Google retired sitemap ping endpoints in 2023. Submitting a sitemap in Search Console is still useful for discovery, but re-pinging it changes nothing about crawl priority.
The Google Indexing API for regular pages. It's officially limited to job postings and live-stream video content. Any tool implying it will push your blog posts into the index is misrepresenting what that API is for.
Mass "Request indexing" clicking. It works for a handful of URLs and has a daily quota. It does not scale to hundreds, and it treats the symptom — the URL still has no reason for Google to come back on its own next time.
There's also a subtler waste: rewriting content that Google has never fetched. If the status is "Discovered", the content isn't what's being judged. Fix discovery first, then let Google form an opinion.
Search Console's Pages report tells you how many URLs are in each bucket, but working URL by URL through the interface stops being realistic somewhere around fifty pages. The URL Inspection API gives you the same data programmatically: verdict, coverage state, last crawl time, and the canonical Google picked.
Its limit is 2,000 inspections per day per property (600 per minute). For a 2,000-URL site that's a full picture daily; for 20,000 URLs it's a ten-day cycle, which is exactly why prioritization matters — fresh posts and not-indexed pages first, stable pages less often.
Whether you build that yourself or use a tool, the data you want per URL is the same: current status, when Googlebot last actually came, and the history of status changes over time. The history is what tells you whether things are moving.
Keeping links pointed at the right URLs is the tedious part: which pages are not indexed today, which has Googlebot ignored longest, and who links to them?
IndexFixer runs that loop for you. It reads the real index status of every URL from Google Search Console (read-only, no API keys, no Google Cloud project), and its widget lists your not-indexed pages as normal internal links — most neglected first — on pages Googlebot already crawls. When a page gets indexed it drops out and the next one takes its place. You get per-URL verdicts, last crawl dates and full status history in your WordPress dashboard.
See how IndexFixer works →Days on an established site with good internal linking; indefinitely on a young site where the URL has no links pointing at it. Unlike quality-based exclusion, this one usually resolves quickly once discovery improves — in our data the median was three days from the moment a neglected URL got linked from crawled pages.
No. Nothing has been judged yet. It's a queue, not a verdict.
Not for this status. Google has never fetched it, so the content isn't why it's excluded. Rewriting matters for "Crawled — currently not indexed".
Only if the URL genuinely wasn't in it. Sitemaps aid discovery, not crawl priority — and the ping endpoint was retired in 2023.
Not for Google, which doesn't participate. It does notify Bing, Yandex, Naver and Seznam — and since Bing powers some AI search results, it isn't pointless, just irrelevant to this status.
There's no threshold. One contextual link from a page Google crawls weekly beats twenty links from pages it hasn't fetched since spring. Placement and crawl frequency of the linking page matter more than count.
Related reading: "Crawled — currently not indexed" explained · Case study: 0 → 98.6% indexed in 5 months · IndexFixer vs CrawlWP vs DIY · Setup guide