RankHive

Discovered – currently not indexed

Where you see it: Search Console → Indexing → Pages → Why pages aren’t indexed

Google has this URL’s address, from a link or your sitemap, but hasn’t fetched it yet. Google’s help explains that it wanted to fetch the URL but held off to avoid overloading your server, so it pushed the crawl back; that’s why no last crawl date shows. Google hasn’t read the page, so it hasn’t judged the content either.

Give new posts time; act when posts you care about stay stuck.

Google says crawling can take from a few days to a few weeks, so a fresh post here is normal. It needs work when older posts never leave, or when thousands of URLs pile up on a site with a few hundred posts: WordPress is exposing more than you meant to publish, or your best posts lack links.

Check a URL nowCan RankHive fix it? Partly

Check the URL Search Console listed

Paste the category page or hub post that should lead to the stuck URL, not the homepage. The checker follows internal links from it through a sample of pages and shows how many crawled pages link to each one, plus broken internal targets and a count of nofollow internal links.

Start from a hub or category page that links widely, rather than the homepage alone.

This crawls a capped sample of pages, so it is a spot check on one section rather than a full-site audit.

Internal link report

Enter a starting URL to map how a section of your site links together.

Reading the result

  • The stuck post shows an In of 1 in Links per page: one crawled page links to it, a thin link profile that fits this status.
  • Nofollow internal above zero: some internal links carry nofollow. Comment Reply and Add to cart buttons usually do. On a menu item or in-post link, it closes a route to the page.
  • Broken targets listed: internal links ending on 404 or another error, sending crawlers into dead ends. Repoint them.
  • Broken internal targets showing 403 or 429: a firewall or rate limit refused the checker partway through. If Googlebot meets the same wall, it crawls less; Google handles a 429 like a server error.

The same tool with its full guide: Internal Links

Why it happens on WordPress

Google’s crawl budget guide targets sites with over a million pages, or over ten thousand changing daily, plus sites where a large share of URLs sit in this status. Most WordPress sites are far smaller. The lever is what WordPress hands Google to crawl, and how easy your real posts are to reach.

A post that slid off every page linking to it

A new post sits on the homepage and its category page for a while, then drifts to /page/4/ and beyond. With no other post linking to it, Google knows it from the sitemap and deep pagination only. Google calls a sitemap a hint and finds pages mainly by following links.

Tags that multiply faster than posts

Every tag typed in the editor creates /tag/name/, and busy tags add /tag/name/page/2/. Core’s /wp-sitemap.xml, there since WordPress 5.5, lists public taxonomies and author archives next to your posts. Five tags per post can expose more tag URLs than articles.

Feeds and reply links on every post

WordPress prints a comments feed link on posts (/your-post/feed/) and feed links on category, tag and author archives. Threaded comments add a ?replytocom= link to each reply. Each is a URL Google can discover, and few belong in search.

Shop filters that never run out

WooCommerce sorting like ?orderby=price and layered filters like ?filter_color=blue&filter_size=m make a new URL for every combination, as do event calendars with endless next-month links. Google’s faceted navigation docs warn these can create a near-infinite set of URLs.

A server that slows down when Googlebot arrives

Google sets its crawl rate by how your server copes: quick, steady answers let it crawl more, while slow responses, 5xx errors and 429s make it back off. Tight shared-hosting limits, a page builder with no page cache and a security plugin throttling bots all cause that.

How to fix it

Find out what the list holds before changing anything. Feeds and tags need settings; real posts need links.

  1. 1. Export the list and count it by pattern

    In Indexing → Pages, click this status, then Export. Label each row: /tag/, /author/, /feed/, ?replytocom=, ?orderby= or filter_, /page/, or other. The other column holds your posts and pages. Leave /page/2/ and deeper crawlable even if listed: they are how Google reaches older posts.

  2. 2. Inspect one real post

    Paste a post from the other column into URL Inspection. Discovery shows the sitemaps listing it and a referring page, if Google has one; a blank one doesn’t prove no links exist. Run Test live URL to rule out a block.

  3. 3. Link stuck posts from pages Google visits often

    In the Performance report, find two or three older posts on the same topic that get clicks. Add a sentence to each linking to the stuck post, with anchor words that say what it covers.

    Internal link checker

  4. 4. Take unwanted URLs out of your sitemap

    Google’s crawl budget guide warns that listing URLs you don’t want in search wastes crawling. List posts and pages, little else.

    • Yoast SEO: whatever you switch off under Show in search results also leaves its sitemap.
    • SEOPress and All in One SEO: content set to noindex, or to No under Show in Search Results, is left out of their sitemaps.
    • No SEO plugin: core’s sitemap has no settings screen, so dropping users or tags takes a plugin or a code filter.

    Sitemap checker

  5. 5. Switch off feeds and filter URLs you don’t use

    Yoast SEO’s crawl optimization settings can switch off each kind of feed you don’t use. For sort and filter URLs you never want crawled, Google’s faceted navigation docs accept a robots.txt Disallow, such as Disallow: /*filter_ or Disallow: /*orderby=. For filtered duplicates you want folded into another page, use a canonical instead; Google can’t read one on a blocked URL.

    Robots.txt validator

  6. 6. Check that the server can take more crawling

    In Settings → Crawl stats, look for host status problems or rising response times. Then check page caching, hosting limits and any security tool that throttles bots, such as Wordfence’s rate limiting, and look in its log or Cloudflare’s security events for blocked Googlebot requests.

  7. 7. Request indexing for a handful, then stop

    Once the links are live, use Request indexing on your most important stuck posts. It is rationed per property, and Google says asking again for the same URL won’t speed up the crawl.

Check the fix in Search Console

Google sets no date for crawling a discovered URL, so track progress post by post first.

  1. Inspect each post you linked a week later. Once Last crawl shows a date, Google has fetched it, and the result says the URL is on Google or names its new status.
  2. Switch the Page indexing filter from All known pages to your post sitemap to see this status for posts alone.
  3. Click Validate fix only when every listed URL should leave this status. It fails as soon as Google rechecks one still here, so skip it while feeds, tags or parameter URLs you chose to leave share the list. Google puts most validations at up to about two weeks.

URLs leave this status for the index, for Excluded by ‘noindex’ tag if you hid them, or for Crawled – currently not indexed when Google fetched a post and passed on it. That last one is a content question.

Can RankHive fix this?

Partly. For posts and pages Google hasn’t reached, RankHive adds internal links from related posts and improves thin ones, and it can add Disallow lines for filter URLs to the robots.txt WordPress serves. Sitemaps, server speed and archive settings stay with you.

What it writes, once you approve

  • Internal links in your posts and pages pointing at the uncrawled post, each shown in its sentence.
  • An edited passage or a full rewrite of a thin post or page.
  • Disallow lines for filter parameters in the virtual robots.txt WordPress generates. A physical robots.txt file in the site root overrides them.

What it can’t do here

  • Generate, edit or submit sitemaps; it only reads them.
  • Noindex archives or feeds, or change your SEO plugin’s settings.
  • Speed up your server or change hosting, Wordfence or Cloudflare settings.
  • Edit archives or WooCommerce products.
  • Click Request indexing or Validate fix; its Search Console access is read-only.

Every change is drafted next to the current value and waits for your approval. Each one written is logged in the Change Log, with Revert.

Check the rest of your site while you’re here

The free site check reads your public pages for titles, meta descriptions, headings, canonical tags and schema, and shows what needs fixing. If you sign up, RankHive reads your Google Search Console data every week, drafts the fixes, and writes the ones you approve to WordPress. Nothing changes on your site until you say yes.

Free site check. No sign-up needed.

Related issues

Common questions

Is “Discovered – currently not indexed” bad?

Not by itself. Google’s help says not indexed isn’t necessarily bad, and on WordPress much of this list is feeds, tags and parameter links. It deserves time when posts you wrote to rank stay here for weeks.

Is it a crawl budget problem?

Rarely on a typical WordPress site. Google writes its crawl budget guide for sites with about a million pages, or ten thousand changing daily. Below that, trimming what WordPress exposes and linking your posts does more.

Will submitting a sitemap fix discovered but not indexed pages?

No. A sitemap tells Google a URL exists, which is how many of these got here. Links from pages Google already crawls are what move a post up the queue.

Why do new posts sit in Discovered for weeks?

Usually nothing but the sitemap points to them. Check for a link from a page with traffic, a recent read date in Indexing → Sitemaps, and a clean host status in Crawl stats.

Read next

Sources

Checked against these pages on .