You publish a post, wait a day, then search its exact title in quotes. Nothing. Search site:yourdomain.com/the-post-slug. Nothing. So the question starts as “is the post bad?” — but that is almost never where the answer is.
A post missing from Google has a short list of possible causes, and they sit at readable layers: the site-level noindex switch, a robots.txt line, a firewall, the sitemap, internal links, and finally Google’s own scheduling queue. Work them in that order and the expensive answer (rebuilding content) stays off the table until everything on the cheap end is actually clear.
That is what this guide does. Each section starts with the concrete check, then the fix, including what WordPress is silently doing under each one.
How a Post Gets Indexed — and What You Control
Two separate things have to happen, in this order:
- Discovery. Google learns the URL exists — from a link on another page of your site, from a link on someone else’s site, or from your sitemap.
- Indexing. Google crawls it, evaluates it, and adds it to the index. This step has no service-level guarantee and no published timeline.
You control step 1 almost completely: make sure the URL exists in the sitemap and is linked from a page that is already indexed. Step 2 is Google’s scheduling, and it is not negotiable — a site Google trusts gets crawled in hours; a new site with few links can wait weeks with identical configuration.
One date that changed the “submit everything Facebook” habit: in June 2023, Google decommissioned the sitemaps ping endpoint, saying the unauthenticated submissions had become mostly spam. Pinging google.com/ping?sitemap=... now returns a 404. Sitemaps still matter — submitted via robots.txt or Search Console — but the ping itself is dead and any plugin still firing it is performing dogma, not work.
The Minute-Long Checks to Do First
Before changing anything, confirm the fault actually exists:
curl -s https://yourdomain.com/robots.txt
And in view source on the post:
<meta name="robots" content="noindex,nofollow">
Those two checks — robots.txt and the <meta name="robots"> tag — plus the Search Console URL Inspection tool (here is the tool and how to use it) will locate most indexing failures in under a minute. URL Inspection shows you what Google sees right now, including crawl availability, indexing state, and the rendered page. It is the only tool that reads the live index rather than guessing from what the site serves.
If you have not set up Search Console at all, that is the ordering problem — spend ten minutes there before any plugin work. And if you are unsure what indexing means in the first place, our explainer on how Google indexes a WordPress website is the shorter version.
Fix 1: The Whole Site Is noindexed and Nobody Noticed
This is the most common real cause, and it is almost always an accident with one tombstone left in Settings.
Open Settings → Reading and look for the checkbox labelled “Discourage search engines from indexing this site.” (The Reading screen documents it.) The name undersells it: when that box is ticked, WordPress does two things at once:
- Adds
<meta name="robots" content="noindex,nofollow">to the header of every page - Serves a robots.txt that tells every user agent
Disallow: /
That combination is actually an anti-pattern for keeping a page out of results. robots.txt blocks crawling, so Googlebot never loads the page and never reads the noindex meta. The URL can still be shown — as a bare, description-less entry dated from whenever Google last crawled it — because the block prevented Google from ever seeing the signal that was supposed to remove it. One mechanism is enough: untick the box so the noindex meta goes away with the block, or if you genuinely need a page permanently out of the index, use noindex without a robots.txt block.
The classic paths that turn this on:
- A site that was built on staging or a clone and quietly had the box ticked there
- A coming-soon / maintenance plugin that was never fully deactivated
- A security plugin that sets noindex on 4xx pages by mistake (rare, but check)
- A fresh site someone built and never switched over
After unticking, do not assume anything. Confirm both layers cleared:
curl -s https://yourdomain.com/robots.txt
should not show Disallow: / under User-agent: *, and view source should show no site-wide noindex meta tag. Only then request indexing again in Search Console.
If you actually meant to block crawl for legal or private reasons — a different intent from indexing problems — our guide to deliberately stopping crawlers is the version that goes the other way, and it is safer because it starts from intent instead of accident.
Fix 2: robots.txt Is Blocking Googlebot at the Wrong Line
A default WordPress robots.txt blocks /wp-admin/ and allows admin-ajax.php, which is correct and safe. Problems start when plugins or hosts add lines that target the whole site:
User-agent: *
Disallow: /
The subtlety worth knowing: when robots.txt disallows a page, Googlebot cannot fetch it and therefore cannot read its meta tags. A noindex page that is also disallowed stays in the index as a URL-only entry, because Google never saw the noindex. That is why the fix for accidental blocks is to remove the blanket Disallow: / — and why, if a page must genuinely stay out of the index, the instruction belongs in a crawlable noindex meta tag, not both.
The other silent blocker is not robots.txt at all — it is the firewall. Some hosts and WAFs (Cloudflare, Sucuri, and a range of security plugins with built-in rate limiting) block or challenge automated requests, and Googlebot is automated traffic. If Search Console URL Inspection shows a crawl error, 403, or “Page fetch failed,” check what sits between you and Google. Google’s guide to verifying Googlebot has the reverse DNS procedure — a legitimate Googlebot’s IP resolves back to *.googlebot.com. Do that before you allowlist anybody, because on a bad network nobody should be allowlisting by IP range alone.
Fix 3: Google Never Found the Post
If noindex is cleared and robots.txt is clean, the remaining common cause is a discovery gap: the post exists at a URL, but nothing points to it, and the sitemap misses it.
Sitemap. Open <yourdomain.com>/wp-sitemap.xml (WordPress 5.5 default) or your plugin’s sitemap and confirm the post’s URL is actually present. As a general reference, Google’s sitemap guide notes what a good sitemap contains — accurate lastmod, full URL list, correct format. If you want conventions, our sitemap examples and best practices cover the practical pattern for a WordPress site.
Two sitemap pitfalls that show up on real builds:
- SEO plugins often drop noindex posts from the sitemap. Rank Math and similar tools exclude pages marked noindex, which is correct behaviour — and means a missing post from your sitemap is a hint that your plugin has similarly marked it noindex. Fix the meta robot, and the sitemap usually repairs itself.
- lastmod is only useful if it is true. Google reuses the lastmod element to estimate when a URL last changed. Plugins that auto-refresh lastmod to “today” on every page destroy the signal; leave lastmod meaningful or leave it out.
Internal links. Google also discovers through links, and a page linked only from the sitemap is a weaker signal than one linked from a relevant, indexed article. A new post with three internal links from established pages gets crawled faster than one stranded at the end of a six-month-old hub. Orphan content, per our broader WordPress indexing explainer above, is the classic new-post scenario that fits “Discovered – currently not indexed.”
New sites. On a domain with no history, weeks of waiting is normal, not a malfunction. Our checklist for getting a WordPress site indexed before launch is the launch-day version of this section.
Fix 4: It’s Crawled but Not Indexed
Search Console shows statuses that are worth reading by name, because they say different things:
| Status | Meaning | Fix direction |
|---|---|---|
| “Discovered – currently not indexed” | URL is known but not yet crawled | Usually scheduling; add internal links, then wait |
| “Crawled – currently not indexed” | Crawled but declined | Quality signal; consolidate or improve the page |
| “Blocked by robots.txt” | Crawl prevented | Fix robots.txt first |
| “Alternate page with proper canonical tag” | Not a problem | Deliberate; no action |
| “Not found (404)” | URL doesn’t serve | Fix the URL, not the indexing |
“Discovered” and “Crawled – currently not indexed” are the two that people misread. Neither is a filter you can disable. Google’s indexing pipeline makes quality calls, and thin content, near-duplicates of an existing page, and mechanically generated material are the usual suspects. The actionable moves are boring: strengthen the page so it answers its question better than the nearest competitor, get it internal links from pages that already rank, collapse it into a stronger page if it is actually redundant, and wait. Re-requesting indexing repeatedly re-runs the crawl, not the crawl decision.
[REQUEST: Screenshot placeholder — Search Console’s Page indexing report, with “Discovered – currently not indexed” expanded.] Image: shot-02-page-indexing-status.png
If the decline persists across a whole content group rather than one URL, it stops being a config bug — that is the point where the ranking factors our 12-month WordPress SEO review covered matter, and it is generally not something a plugin toggle can repair.
What Doesn’t Speed Indexing
A few favourite answers to “how do I make Google index faster” are myths or leftovers, and they make indexing problems look more mysterious than they are.
- IndexNow. The protocol is real and officially documented, and Bing, Yandex, Seznam, Naver, Mojeek and other engines honour it. Google does not participate. Submitting your URLs to IndexNow will not change Google’s crawl behaviour for your site; it is a Bing-family instant-submit mechanism. Useful, occasionally, just never for the problem you named.
- Sitemap ping. Dead since 2023 as noted above. Any plugin still pinging is behind on changelog.
- Resubmitting your sitemap repeatedly. Search Console reads your already-submitted sitemap during scheduled recrawls; a daily manual resubmit does nothing beyond the first confirm.
- Meta tags like
revisit-after. Not a Google directive. It does nothing. - “Submitting” via third-party ping services. Same family as the dead sitemap ping, minus the undocumented endpoint.
What does work, repeatedly confirmed: strong internal linking, a verified sitemap in Search Console, clean page content, and time.
Content Structure Consistency for Recovery
If multiple posts are stuck, the pattern is usually site-wide, not post-specific. Rank-safe content architecture changes are typically needed; check our guide to improving WordPress search ranking for the content-level levers, and our “ensuring WordPress is SEO friendly” checklist for the structural quick-wins. Don’t chase a plugin option named “force index” — an index directive is already the default for any normal WordPress page.
The Twenty-Minute Triage Order
- Search Console → URL Inspection on the post’s URL. Note the status it reports verbatim
- If it shows noindex, open Settings → Reading and check “Search engine visibility”
- View source on the post: search for
robotsin the<meta>tags curlyour robots.txt and confirm no blanketDisallow: /- Check hosting/CDN logs for 403 responses against Googlebot; verify Googlebot via reverse DNS before allowlisting
- Confirm the post is in the sitemap, and confirm
lastmodis sane - Add two or three internal links to the post from pages that are already indexed
- Request indexing once (not ten times) in Search Console
- Then wait — and set a calendar reminder for 7 days before assuming failure
FAQ
How long does it take for a new WordPress post to appear in Google?
There is no official timeline and it depends mostly on your site’s crawl history. On established, regularly-indexed sites it can be hours; on new sites it can be weeks. If the Search Console report says “Crawled – currently not indexed”, the wait is the wrong thing to fix first — the content is the thing to improve.
How do I check if my post is indexed?
Use Search Console URL Inspection on the exact URL — it reads the live index and gives a definitive yes or no. The site: search operator is a quick approximation but can miss pages for innocent reasons, including recent publication.
Does IndexNow make Google index my posts faster?
No. IndexNow is honoured by Bing, Yandex, Seznam, Naver, Mojeek and others, but Google has not adopted it. Use it for those engines if you want, but for Google, a sitemap in Search Console plus internal links is the only route.
What does “Discovered – currently not indexed” mean?
Google knows the URL exists but has not crawled it yet — a scheduling decision, usually influenced by crawl priority and your site’s crawl budget. Adding internal links from already-indexed pages raises the priority; repeatedly requesting indexing does not change it.
Can a plugin make my posts invisible to Google?
Yes, in several ways: a maintenance-mode plugin (noindex), a security plugin that rate-limits Googlebot’s IP ranges, a “force index” toggle left off in an SEO plugin’s per-post settings, or the WordPress “Search engine visibility” box being ticked. It is all in the earlier sections, all reversible.
Do I need to resubmit my sitemap after each new post?
No. Search Console treats a submitted sitemap as a standing discovery source; Google schedules its own sitemap recrawl. Resubmit once when you change sitemap structure or add a new section, not per post.
