Fix "Discovered - Currently Not Indexed" in WordPress
You publish a page, submit it in Search Console, and a week later the coverage report still says "Discovered – currently not indexed." No error, no penalty, nothing obviously broken — Google just hasn't bothered to index it. Here's what that status actually means and what to do about it.
What This Status Actually Means
Search Console splits unindexed URLs into several buckets, and people often lump them together. They're not the same problem:
| Status | What it means |
|---|---|
| Discovered – currently not indexed | Google knows the URL exists (from your sitemap or a link) but hasn't crawled it yet |
| Crawled – currently not indexed | Google fetched the page but decided not to add it to the index |
| Excluded by 'noindex' tag | You (or a plugin) explicitly told Google not to index it |
| Duplicate without user-selected canonical | Google sees near-identical content elsewhere and picked a different URL |
"Discovered – currently not indexed" is the frustrating one because it means Google hasn't even looked yet. It's a scheduling problem more than a quality problem — though on a WordPress site, quality issues often cause the scheduling problem in the first place.
Symptom: What You're Seeing
Usually it shows up one of two ways:
- You publish a new post, wait a few days, and Google Search Console's Page Indexing report lists it under "Discovered – currently not indexed" instead of "Indexed."
- You migrated a site to Getwebup, and pages that used to rank on the old host are sitting in this bucket on the new domain or after a URL change.
Run a quick check first, before assuming it's a crawl-budget issue:
curl -I https://yourdomain.com/the-page/ | grep -i x-robots-tag
curl -s https://yourdomain.com/the-page/ | grep -i 'noindex\|canonical'
curl -s https://yourdomain.com/robots.txtIf any of those return a noindex directive or a canonical pointing somewhere else, that's your answer — skip ahead to the noindex section below. If they come back clean, the cause is almost always crawl priority.
Cause 1: WordPress's Own "Discourage Search Engines" Toggle
This is the single most common cause we see after a migration or a fresh install, and it's embarrassingly easy to miss. WordPress ships with a setting under Settings → Reading called "Discourage search engines from indexing this site." It's meant to be used during development, but it gets left checked when a staging site goes live, or gets accidentally re-enabled during a Softaculous restore or a database import that overwrites wp_options.
Check it directly in the database if the admin UI feels unreliable:
SELECT option_value FROM wp_options WHERE option_name = 'blog_public';blog_public = 0 means the site is telling every search engine to stay away — it injects <meta name="robots" content="noindex,nofollow"> into every page's <head>. Set it back to 1, or flip the toggle off in the admin, and re-request indexing.
Cause 2: An SEO Plugin or Page Builder Set noindex Per-Page
Yoast, Rank Math, and All in One SEO all let you set indexing rules per post, per category, and per custom post type. It's common for someone to bulk-set an archive or post type to noindex early on and forget it applies to new content too. In Rank Math this lives under the post's SEO panel → Advanced → "Robots Meta." In Yoast it's under the same "SEO" meta box, "Advanced" tab.
Page builders cause a subtler version of this: Elementor and Divi templates sometimes carry their own meta settings that override the theme, especially on landing pages built from an imported template kit.
Cause 3: Crawl Budget Is Going Somewhere Else
If the individual page checks out clean — no noindex, no bad canonical — the problem is usually that Googlebot has a lot of other URLs on your site competing for its attention, and your new page hasn't made the cut yet. This is common on:
- WooCommerce stores with thousands of filter/attribute URL combinations (
?color=red&size=m) that Google keeps re-crawling instead of your actual pages - Sites with tag and date archives enabled that generate hundreds of thin, near-duplicate pages
- Large sites where the XML sitemap hasn't been resubmitted after a bulk content push, so Google is working through a stale queue
Check Settings → Crawl Stats in Search Console (under the property's Settings page) to see what Googlebot has actually been spending its time on over the last 90 days. If it's mostly hitting parameterized URLs or old archive pages, that's your crawl budget leak.
Cause 4: The Page Is Genuinely Thin or Low-Value
Google is more selective about what it indexes than it used to be. A 150-word blog post, a tag archive with three items on it, or a page that's 90% boilerplate and 10% unique text is a common candidate for permanent "discovered, not indexed" status — Google crawls it eventually, decides it's not worth adding, and moves on. No amount of resubmitting fixes this; the content itself needs to be more substantial or merged into a stronger page.
Cause 5: Orphan Pages With No Internal Links
If a page only exists in your sitemap and nothing on the site actually links to it, Google treats it as lower priority. Sitemap-only discovery is the weakest kind. Add at least one contextual internal link from a related, already-indexed page — a blog post linking to a new service page carries far more weight than the sitemap alone.
The Fix, In Order
- Confirm the page isn't noindexed — check
blog_public, the SEO plugin's per-post setting, and the raw HTML with curl. - Confirm the canonical tag on the page points to itself, not to another URL.
- Add at least one internal link to the page from existing, indexed content.
- In Search Console, open URL Inspection, paste the exact URL, and click Request Indexing. This forces an immediate crawl rather than waiting for the queue.
- If it's part of a bulk-published batch, resubmit your XML sitemap under Sitemaps so Google re-reads the full list with current lastmod dates.
- If Crawl Stats shows budget going to junk URLs, block them in
robots.txtor addnoindexto the low-value archive types (tag pages, filtered product URLs) so Googlebot stops wasting time there.
How Long It Actually Takes
Manual "Request Indexing" usually gets a page crawled within a few hours to a couple of days — but it has a soft daily quota per property, so don't burn it on ten pages at once. For a real fix (as opposed to a nudge), expect the underlying signal — internal links, content depth, crawl budget cleanup — to take one to four weeks to fully reflect in Search Console, since it's reporting field data on a rolling basis, not a live status.
Prevention
- After every migration or staging-to-live switch, check Settings → Reading before doing anything else.
- Keep tag and date archives disabled unless you're actually using them for navigation — most WordPress sites don't need them indexed.
- Link new content from at least one existing page before or right after publishing, not weeks later.
- Resubmit your sitemap after any bulk import, not just once when the site launches.
- Review Crawl Stats quarterly on larger sites — it's the only place that shows you where Googlebot's time is actually going.
Frequently asked questions
Is "Discovered – currently not indexed" the same as being penalized by Google?
No. It's not a penalty or a manual action — those show up separately under Security & Manual Actions in Search Console. This status just means Google hasn't crawled and indexed the URL yet, usually due to crawl priority or content depth, not a violation.
I clicked "Request Indexing" and nothing happened. Why?
Request Indexing has an unpublished daily quota per property. If you've used it heavily that day, it queues silently instead of running immediately. Wait 24 hours and try again, and in the meantime fix the underlying cause (noindex, internal links, thin content) rather than repeating the request.
Does submitting an XML sitemap guarantee indexing?
No — a sitemap only tells Google a URL exists. It doesn't guarantee a crawl or an index decision. Pages discovered only through the sitemap, with no internal links pointing to them, are consistently the slowest to get indexed.
Why did pages that were indexed on my old host end up 'discovered, not indexed' after migrating to Getwebup?
This almost always traces back to the WordPress "Discourage search engines" setting getting re-enabled during the migration, or the domain/URL changing without updating canonical tags and internal links to match. Check blog_public in wp_options first — it's the most common cause after a move.