WordPress Not Indexed: The 10 Most Common Causes

WordPress powers a large share of the web, and a WordPress site that is not indexed usually has one of a small number of things wrong with it. The good news is that most of them are settings, not mysteries. A checkbox, a plugin default, a canonical tag written by a theme. The awkward news is that WordPress hides these settings in several different places, so people tend to fix the one they know about and miss the one that actually applies.

Here are the ten causes worth checking, roughly in order of how often they turn out to be the answer.

First, confirm your WordPress site is not indexed

Before changing anything, establish what Google actually holds. The URL Inspection tool in Search Console gives a verdict for one URL at a time, if you have the property verified. If you do not, or you want to watch a set of URLs over days rather than take one reading, a tool like AIndexify checks each submitted URL against live Google results on a fixed schedule and records submitted and indexed as separate events, with the date each page was first found. No Search Console connection is required. Either way, get a factual answer per URL before you start turning dials.

1. “Discourage search engines” is ticked

Settings, Reading, “Discourage search engines from indexing this site”. One checkbox, site-wide effect. It adds a noindex signal to every page, and it survives migrations: staging sites launch with it ticked more often than anyone would like to admit. Google’s documentation is blunt about what noindex does: the page is dropped or kept out entirely. Check this first. It takes ten seconds and it is the most common single cause.

2. A robots.txt rule is blocking the crawl

WordPress serves a virtual robots.txt unless a physical file exists, and plugins can write rules into either. A leftover Disallow: / from a developer, or a rule blocking /wp-content/ broadly enough to hide your CSS, changes what Googlebot can fetch. Note the trap: robots.txt controls crawling, not indexing, so a blocked page can still appear in results as a bare URL while the content stays invisible. The mechanics are covered in the robots.txt disallow trap.

3. Your SEO plugin set a noindex you forgot about

SEO plugins can set noindex per post, per post type, or per archive type. A single toggle such as “noindex all tag archives” is usually sensible; the same toggle applied to posts or pages is not. Open the plugin’s search appearance settings and read every noindex line. Then check a few individual posts, because per-post overrides beat the defaults.

4. The page is private, password protected, or behind a maintenance screen

A private post is invisible to logged-out visitors, including Googlebot. So is anything behind a password, and so is a site running a coming-soon or maintenance plugin, which typically serves every visitor the same placeholder. Googlebot sees the placeholder, not your content. If a launch happened but the maintenance plugin stayed active, the site is technically live and practically absent.

5. The canonical points somewhere else

Themes and plugins write canonical tags, and they occasionally write the wrong one: pointing every paginated page at page one, pointing HTTPS at an old HTTP address, or pointing a rebuilt page at a URL that no longer exists. Google treats the canonical as a strong hint about which URL to keep. When it follows a bad hint, your page is not missing, it is filed under a different address. Why Google indexes the wrong URL covers the diagnosis in detail.

6. Archive pages are diluting the site

Every tag, category, date, and author archive is a URL WordPress generates automatically. A small blog can carry hundreds of near-empty archives, each duplicating fragments of the same posts. None of this blocks indexing outright, but it gives Google a large set of thin URLs to evaluate and little reason to prioritise the ones you care about. Noindexing thin archives narrows the site to the pages that deserve attention.

7. The sitemap is missing, stale, or blocked

Modern WordPress ships a native sitemap, but SEO plugins commonly replace it, and a misconfiguration can leave you with neither, or with two that disagree. Check that the sitemap URL loads, lists your real pages, and is submitted in Search Console. A sitemap does not compel indexing, but it is the cheapest way to tell Google which URLs you consider canonical.

8. The theme is serving soft 404s

Page builders and thin templates sometimes produce pages with a header, a footer, and nearly nothing in between. Google may classify these as soft 404s: pages that say “200 OK” while behaving like errors, and it declines to index them. Empty category pages and placeholder pages from demo imports are the usual suspects.

9. The page is orphaned

WordPress will happily hold a published page that no menu, no post, and no widget links to. Google discovers URLs mostly by following links, so an orphan depends entirely on the sitemap for discovery, and competes from the weakest possible position. Link new pages from somewhere a crawler already visits, ideally the front page or a well-indexed post.

10. Nothing is wrong, Google has not decided yet

Sometimes the answer is that every setting is correct and the queue is simply long. Google’s own guidance says crawling can take days to weeks, and submitting a URL asks Google to look; it does not oblige Google to keep what it finds. New domains and recently restructured sites wait longest. The honest move is to distinguish “blocked” from “not yet”, and only the passage of time, observed, tells you which you have. The broader picture of how discovery, crawling, and selection fit together is in the full guide to Google indexing.

Work down the list, then watch

The first four causes are binary: a setting is on or it is off, and fixing it removes the obstacle the same day. Causes five to nine are structural and improve gradually after the fix. The tenth is not a fault at all, just Google exercising its judgement on its own schedule.

Fix what the list turns up, then measure rather than assume. Submit your URLs and see, on a fixed checking schedule, which pages Google has actually kept.