WordPress problem fix
Google has the URL in its queue and chose not to fetch it yet. The cause is crawl budget, not content. We free the budget; Google catches up.
'Discovered — currently not indexed' in Search Console means Google knows the URL exists (usually from your sitemap or an internal link) but has not actually fetched it yet. Unlike 'Crawled — currently not indexed', the page has never been read — so the cause is not content quality, it is crawl budget and authority. The three real causes: (1) the site is publishing more URLs than Google has crawl budget for (most common on large WordPress sites with autogenerated tag/archive/paginated URLs), (2) overall site authority is too low to earn the crawl budget the URL count implies, or (3) Google has crawled the URL in the past, decided it was low-value, and downgraded the priority for future crawls. The fix path is mostly architectural: cut the URL count Google has to consider, strengthen the internal-link path to the URLs that matter, and stop publishing low-quality URLs that drain budget. Re-requesting indexing on a 'Discovered' URL works in roughly 1 in 4 cases — it is a faster fix than waiting but not a substitute for solving the budget problem.
If any of these match, you are on the right page.
Search Console → Pages report shows URLs under 'Discovered — currently not indexed'
Affected URLs have never appeared in URL Inspection as 'Last crawl'
Site has many autogenerated URLs (tags, categories, paginated archives, faceted filters)
site:yoursite.com count is dramatically lower than the URL count in your sitemap
New posts sit in 'Discovered' for weeks before getting crawled
Crawl budget is Google's per-site quota for how many URLs to fetch in a given period. It is loosely tied to site authority, server response time, and historical content quality. A 50-page site with high authority can have its whole sitemap crawled hourly; a 50,000-URL site with low authority might get 500 crawls per day, most of which Google spends on URLs it already indexes.
WordPress generates URLs aggressively by default — every tag is a URL, every category is a URL, every author is a URL, every paginated archive is a URL, every attachment is a URL. A 100-post site can easily generate 800+ crawlable URLs without the owner realizing. Most of them are near-duplicates. Google notices, downgrades the site's crawl efficiency, and 'Discovered — not indexed' grows.
Two reasons. (1) The internal-link path from a high-priority page (homepage, hub page) to the new post is weak or non-existent. (2) The site is in the slow-lane of Google's crawl scheduler because of low authority or low historical quality. Fix the internal link first; the authority fix is months of work.
The real method, in the order it works.
Audit your URL count. wp-cli post list --post_type=any --format=count plus sitemap URL count. If you have more than 10x the URLs of useful content, you have a budget problem.
Noindex the URL categories that should not compete for crawl budget: tag archives, paginated archives past page 1, attachment pages, author archives on single-author blogs, faceted product filters.
Remove noindexed URLs from your sitemap. Yoast and RankMath do this automatically when you noindex; double-check by opening sitemap.xml in a browser.
Internal link from the homepage or a hub page to every new piece of content within 24 hours of publishing. A new post with zero links from indexed pages waits in line; a new post linked from the homepage usually crawls within 48 hours.
Submit the URL to URL Inspection → Request Indexing. Works in roughly 1 in 4 cases for 'Discovered' URLs. Do it once per URL; do not repeat.
Improve server response time. Google measures the average time-to-first-byte across your site. Faster TTFB = more crawls per minute = more crawl budget. Cache, CDN, faster hosting — all three help here.
Long-term: build domain authority via inbound links to the homepage and a small number of pillar pages. Crawl budget tracks authority.
Real fix, from our work
An ecommerce client on WooCommerce had 4,200 'real' product and content URLs and 38,000 URLs in their sitemap. The other 33,800 were tag pages, paginated archives, attachment pages, and faceted filter combinations like /shop/?color=red&size=small&sort=price-asc. Of the 4,200 real URLs, 2,900 sat in 'Discovered — currently not indexed' for over 90 days. We noindexed every faceted filter combination, killed attachment pages, noindexed pagination past page 1, and deleted unused tag taxonomies. Sitemap dropped from 38,000 to 4,400 URLs. Six weeks later, 2,400 of the 2,900 'Discovered' URLs had moved to 'Indexed'. Google did not need more authority — it needed us to stop wasting its budget on noise.
Written by Ali Yasin Jatoi
Founder of WebCare Studios. Ali has worked with WordPress for more than 10 years, including managing a fleet of 150+ sites with WP-CLI automation for updates, security cleanup, and malware removal. He has hands on experience across major hosts including Cloudways, A2 Hosting, Hostinger, and Bluehost.
Site down, hacked, or broken checkout gets a senior engineer within 4 hours. No ticket queues, no bots.
Flat quote up front. If we cannot get you back online, you do not pay. Risk sits with us, not you.
We work on a snapshot first and never touch your live database until the fix is verified safe.
We run a fleet of WordPress sites every day. The errors you are seeing are ones we have closed hundreds of times.
No. The sitemap is a hint, not a command. Google decides which sitemap URLs to crawl based on its own scheduler. A clean focused sitemap helps; a bloated sitemap actively hurts because it dilutes the signal.
Sometimes. Roughly 1 in 4 for 'Discovered' URLs in our experience. It is faster than waiting if you have a small number of URLs you really need indexed. It is not a substitute for fixing the underlying budget problem.
Only if they are genuinely useless (autogenerated tag pages, attachment pages, faceted filters). Real content should stay and be linked-to better, not deleted. Deletion is the right call for autogenerated noise; rewriting and linking is the right call for real content.
Discovered = Google knows about it but has not fetched it. Crawled = Google fetched it and decided not to index. Discovered is a crawl-budget problem (architectural); Crawled is a quality/demand problem (content). Different fix paths — see our Crawled page for that side.
Usually it speeds it up, because TTFB drops. A misconfigured CDN that returns 5xx to Googlebot (rare but happens) will slow crawling. Check Search Console → Crawl Stats for 5xx errors during the periods Google is crawling.
Two fields. Email and your URL. A senior WordPress engineer reads it within minutes and replies on email and WhatsApp with what is wrong and what we will do next.
Real proof and field guides tied to "GSC: Discovered — currently not indexed".