WordPress Pages Not Indexing? 7 Causes to Check First

Your WordPress pages or posts are published, the content is live, and Google still shows nothing. Before you reinstall plugins or blame your theme, know this: WordPress has a handful of specific switches that silently block indexing: a checkbox in your settings, a toggle in your SEO plugin, a robots.txt rule. This guide walks the seven most common causes, how to confirm each one, and how to run a free index audit across your URLs so you fix the real blocker instead of guessing.

How to fix page indexing issues in WordPress?

To fix WordPress indexing, check the two platform-specific blockers first: open Settings → Reading and confirm "Discourage search engines from indexing this site" is unchecked, then open your SEO plugin (Yoast, Rank Math, SEOPress, or All in One SEO) and confirm no noindex toggle is set on the page, post type, or taxonomy. If both are clean, inspect the URL in Google Search Console for the exact reason.

The fastest first move: audit which URLs are actually indexed

Don't diagnose one page at a time. Pull your sitemap or a list of important URLs and check them in bulk so you can see the pattern: that pattern is the diagnosis. If only tag and author archives are missing, you have a thin-content issue. If every URL is missing, you almost certainly have a sitewide noindex from the Settings → Reading checkbox or a robots.txt block.

Run a free index audit on your WordPress URLs to see, in one pass, exactly which pages Google has indexed and which it hasn't. That list tells you whether you're chasing a single page or a sitewide switch, and saves you from fixing the wrong thing.

Cause 1: The "Discourage search engines" checkbox

This is the number-one reason a new WordPress site indexes nothing. Settings → Reading has a checkbox labeled "Discourage search engines from indexing this site." When it's on, WordPress injects a sitewide <meta name="robots" content="noindex"> and disallows crawling in robots.txt. It gets enabled during development and forgotten at launch. Uncheck it, save, and request indexing in Search Console.

Cause 2: A plugin noindex toggle (Yoast, Rank Math, SEOPress, AIOSEO)

Every major SEO plugin can set noindex per page, per post type, or per taxonomy. In Yoast SEO, Rank Math, SEOPress, and All in One SEO, an "Allow search engines to show this page?" setting flipped to No, or a bulk default that noindexes an entire post type, will quietly de-list matching URLs. Open the affected page's SEO box, or the plugin's search-appearance settings, and confirm indexing is allowed.

Cause 3: A robots.txt Disallow blocking Googlebot

WordPress serves a virtual robots.txt unless you've added a physical file. Either can carry a Disallow: / or a path rule that blocks your pages. View yourdomain.com/robots.txt directly, and use the URL Inspection Tool in Google Search Console, which tells you if a URL is "Blocked by robots.txt." Remove the offending rule. Note that a robots block stops crawling, while noindex stops indexing; the two have different fixes.

Cause 4: Thin or duplicate archive pages

Google routinely declines to index low-value WordPress URLs: tag archives, author archives, date archives, and attachment pages. These often hold near-duplicate snippets and little unique text. This isn't always a bug: it's Google judging value. If these are the only missing URLs, that's expected. Set them to noindex deliberately in your SEO plugin and focus crawl budget on real content. For the full mechanism, see why pages get crawled but not indexed.

Cause 5: A new or low-authority site still in the queue

If your site is young, Google may simply not have crawled the pages yet. In Search Console you'll see "Discovered – currently not indexed" or "Crawled – currently not indexed." Submitting a URL requests a crawl but doesn't force indexing, and on a low-authority site, URLs can wait weeks. Build internal links to important pages and earn a few external links to raise crawl priority. This is a patience-plus-signals problem, not a broken switch.

Cause 6: Caching, security, or Cloudflare rules blocking Googlebot

Performance and security plugins, and Cloudflare's firewall, can serve Googlebot a challenge page, a 403, or stale cached HTML carrying an old noindex. Plenty of advice treats a security plugin as something that helps indexing; in practice, a misconfigured security or caching layer is just as often the cause. Check your firewall's verified-bot rules, exclude Googlebot from challenges, and purge the cache after any SEO change.

Cause 7: No XML sitemap submitted

A sitemap doesn't guarantee indexing, but it's how Google discovers URLs efficiently. WordPress, Yoast, Rank Math, and the others all generate one, typically at /sitemap.xml or /sitemap_index.xml. Confirm it loads, then submit it under Sitemaps in Google Search Console. If the sitemap lists URLs that aren't indexed, you've narrowed the problem to one of the causes above, not discovery.

Diagnostic table: cause → confirm → fix

WordPress cause	How to confirm	Fix
"Discourage search engines" checkbox	View page source for noindex; check Settings → Reading	Uncheck the box, save, request indexing
Plugin noindex toggle	Open the page's SEO box / plugin search-appearance settings	Set "Allow indexing" / remove post-type noindex
robots.txt Disallow	Load /robots.txt; GSC says "Blocked by robots.txt"	Remove the Disallow rule
Thin/duplicate archives	Pattern shows only tag/author/attachment URLs missing	Noindex them intentionally; prioritize real content
New / low-authority site	GSC shows "Discovered/Crawled – currently not indexed"	Add internal + external links; wait, then validate
Security/cache/Cloudflare block	GSC fetch fails or returns 403; cached noindex	Allow verified Googlebot; purge cache
No sitemap submitted	/sitemap_index.xml missing or not in GSC	Generate via SEO plugin, submit in Search Console

Confirm the fix worked: don't assume

After you change a setting, the page won't reindex instantly. Use the URL Inspection Tool to request indexing, then re-check the URL a few days later. For a fast read across many pages, check whether your pages are indexed in bulk rather than inspecting them one by one. The goal is confirmation, not hope.

Key takeaways

• Audit first, diagnose second. A bulk index check shows whether one page or the whole site is affected: that pattern is your diagnosis.
• Two WordPress-specific switches cause most cases: the Settings → Reading checkbox and a plugin noindex toggle. Check both before anything else.
• Submission ≠ indexing. Requesting a crawl in Search Console can't override a noindex tag, a robots.txt block, or thin content.
• Some "missing" pages are correct. Tag, author, and attachment archives are often better left out of the index.

Once your pages are indexing, the next risk is silent de-indexing: a plugin update or a botched migration can flip a noindex back on without warning. Run a free index audit on your WordPress URLs to confirm everything is live today, and consider monitoring index status at scale with automated de-indexing alerts so you catch a drop the day it happens instead of months later.