Discovered, Currently Not Indexed: A WordPress Investigation

“Discovered, currently not indexed” means Google has found the URL but has not fetched it yet. On a small WordPress site, work through three checks: confirm the URLs in the sample are pages you want in search, confirm your server answers quickly and without errors, and confirm each wanted page is linked from a crawlable page and listed in your sitemap. Then record a recheck date and wait. Resubmitting the same URLs repeatedly does not speed this up.

What Google says the status means

Google’s Page Indexing report help, checked September 27, 2026, says: “The page was found by Google, but not crawled yet. Typically, Google wanted to crawl the URL but this was expected to overload the site; therefore Google rescheduled the crawl.”

Two consequences follow. First, nothing about the page’s content has been judged, because Google has not fetched it. Rewriting the text is not a fix for this status. Second, Google’s own explanation points at crawl scheduling, which depends on how much Google wants to crawl and how much your server can take.

Be careful before calling this a crawl budget problem. Google’s crawl budget guide, checked September 27, 2026, is written for large sites (about a million pages or more) that change weekly, medium sites (10,000 or more) that change daily, and sites with a large portion of their URLs in this status. It says: “If your site doesn’t have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don’t need to read this guide.” A 300-page WordPress site with a handful of discovered URLs needs the checks below, not a budget strategy.

If the page has already been crawled and the status says “Crawled, currently not indexed,” use that guide instead.

Sort the URLs you want from the ones you do not

Open the reason’s details page and export the example URLs. Sort them into two groups: pages you want in search, and URLs WordPress, a theme, or a plugin generated that nobody needs to find in search.

Google’s crawl budget guide says that when many of the URLs Google knows about are duplicates or unimportant, “this wastes a lot of Google crawling time on your site.” It also says soft 404 pages “waste your budget,” and gives differently sorted versions of the same page as an example of pages to keep out of crawling. A calendar that links to next month forever produces an endless run of unimportant URLs. If your sample is dominated by generated patterns like these, the useful work is reducing them: remove the links that create them, block crawling of the ones that must exist with robots.txt, or turn off the feature that generates them. The same guide advises against noindex for this, because Google still has to request a page to see the tag.

A few WordPress settings turn common sources into redirects. WordPress 6.4 disables attachment pages on new installations and redirects those URLs to the media file, according to the WordPress core announcement, checked September 27, 2026; sites that existed before the upgrade keep them. If you use WP Visibility, it redirects attachment pages to the file and redirects ?replytocom comment URLs to the post by default; both are toggles in the Indexing section of its settings. Links to these URLs can stay in your pages, so Google may still discover them, but a crawl of one ends at the file or the post rather than a separate page.

Check that your server answers quickly and cleanly

Because Google’s explanation mentions overloading the site, check whether your server gave Google a reason to slow down. Google’s HTTP status code documentation, checked September 27, 2026, says “5xx and 429 server errors prompt Google’s crawlers to temporarily slow down with crawling.”

1. Time a few of the discovered URLs as an anonymous visitor:

   curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" https://example.com/some-page/

   A consistent 200 is what you want. Occasional 500, 503, or 429 responses are worth investigating.

2. Count the status codes Googlebot requests received in your server’s access log, and look for 5xx and 429 responses. Log locations vary by host; your control panel usually links to them.

   grep "Googlebot" access.log | awk '{print $9}' | sort | uniq -c

   The ninth field is the status code in the common Apache and nginx log formats; adjust it if your host uses another format.

3. Open Settings, then Crawl stats in Search Console and look at Host status. Google’s Crawl Stats help, checked September 27, 2026, says it shows problems with robots.txt fetching, DNS resolution, and server connectivity, and that the report is available only for root-level properties. The same page says sites with fewer than a thousand pages should not need the report for that level of crawling detail. Host availability problems are still worth a look.

If you find repeated errors or rate limiting, the repair is in the layers that answer requests (the host, a firewall or CDN, or a plugin), not in the page content. Googlebot access errors covers finding the layer responsible.

Make each wanted page reachable

Crawlers find new URLs on pages they have already crawled, as Google’s sitemap overview explains (checked September 27, 2026). Google’s link guidance, checked September 27, 2026, says Google can generally crawl a link only if it is an <a> element with an href attribute, and that “every page you care about should have a link from at least one other page on your site.”

For each page you want indexed:

1. Inspect it in URL Inspection and read Referring page. Google’s URL Inspection help, checked September 27, 2026, describes this as a page Google “possibly” used to discover the URL; sitemaps are listed in a separate Sitemaps field. If no referring page is shown, or the only one is an old archive page, the page may have few links leading to it.
2. Check that at least one ordinary, indexable page links to it with a normal link. Menus or “related posts” blocks built with JavaScript click handlers instead of <a href> links cannot be relied on; Google says it can’t reliably extract URLs from them.
3. Confirm the page appears in your XML sitemap with an accurate modified date.

Google’s sitemap guidance, checked September 27, 2026, says to include the URLs you want in search results, that Google uses <lastmod> “if it’s consistently and verifiably accurate,” and that submitting a sitemap “is merely a hint.” WP Visibility’s sitemap lists published, indexable posts and pages with each post’s modified date as lastmod, and leaves out noindexed content, attachments, and password-protected posts. Submit Your Sitemap covers finding and submitting it. Submit it once. Google’s crawl budget guide says “Google reads your sitemap regularly,” so repeated submissions are not needed.

Record a recheck, and know when to stop

For a few of your most important discovered URLs, use Request indexing in URL Inspection. Google’s recrawl documentation, checked September 27, 2026, says there is a quota, that repeated requests for the same URL will not get it crawled faster, and that crawling can take from a few days to a few weeks.

As an illustration, the fictional garden.example has 40 discovered URLs. Thirty are event calendar months two years ahead, and ten are new articles. The calendar links are removed from the sidebar and the ten articles are linked from a guide hub page and confirmed in the sitemap. The owner requests indexing for the three most important articles and notes a recheck date three weeks out. This example shows the procedure; it is not a measured outcome.

Write down:

• The date, the number of URLs in the status, and how many are pages you want.
• Any server errors or slow responses found, and what was changed.
• Which pages gained links, and from where.
• The recheck date.

On the recheck, a URL may move to indexed, stay discovered, or move to “Crawled, currently not indexed.” Each is a separate result. Only the last calls for the content checks in the crawled guide.