You published a post, submitted it in Google Search Console, waited a few days, and it still does not appear in Google Search. You search for the exact title in quotes and nothing comes up. The URL Inspection tool says “URL is not on Google.”
This is one of the most frustrating situations in SEO — especially when other pages on the same site index without any issue. The problem is that “not indexed” is not a single problem with a single fix. It is a symptom that can come from at least a dozen different root causes, and the fix for each one is completely different.
Across WordPress sites I’ve managed, most indexing problems ultimately traced back to internal linking issues, duplicate content, or pages that Google simply didn’t consider sufficiently different from existing content. This guide covers every real cause I have encountered, how to identify which one applies to your specific page, and exactly what to do about it. Before diving in, if you have not already read my breakdown of GSC indexing statuses and what each one means, start there — the status message GSC shows you is the fastest way to narrow down which category your problem falls into.
Start Here: Check the URL Inspection Tool First
Before you do anything else, open Google Search Console, go to URL Inspection, and enter the exact URL of the page that is not indexing. Do not guess at the cause — read what GSC is actually telling you.
The status message and the crawl details underneath it will immediately tell you which stage of the process the page is stuck at:
- If all crawl fields show N/A — Google has not visited the page yet (discovery problem)
- If crawl fields show a date and successful fetch — Google visited but rejected the page (quality or duplication problem)
- If page fetch shows Failed with an error code — something is actively blocking Googlebot (technical problem)
Also check the “Referring page” field. If it says “None detected,” that is a significant signal on its own — it means no page Googlebot has crawled is linking to your page, which directly affects crawl priority.
With that context, here are the real causes, grouped by which stage they affect.
Discovery Stage Problems
These are issues that prevent Google from even knowing your page exists or prioritizing it for crawling.
1. No Internal Links Pointing to the Page (Orphan Page)
This is the most common cause I see on client sites for pages sitting at “Discovered — currently not indexed” with no referring page detected. Google found the URL via your sitemap, but no crawled page on your site links to it. Without a real HTML link from an already-indexed page, your new post sits in a low-priority crawl queue with no clear path for Googlebot to follow to reach it.
Sitemaps tell Google a URL exists. Internal links tell Google the URL matters. Both are needed — sitemaps alone are not enough to get a page crawled promptly.
How to confirm it: In GSC URL Inspection, check “Referring page.” If it says “None detected,” this is your issue. Also check the Links report in GSC under the Internal Links section to see which pages are linking to your URL.
How to fix it: Add contextual internal links from 2 or 3 already-indexed posts that are topically related. Use anchor text that naturally describes what the linked page covers. Then clear your caching plugin on those linking pages, clear server-level cache, and resubmit those linking pages in GSC — not the stuck page. Let Googlebot follow the links to the new page. I cover the full strategy for internal linking for SEO including how to identify and fix orphan pages across your site.
2. Caching Layer Hiding Your Internal Links From Googlebot
This is a subtler version of the orphan page problem, and it is one that trips up even experienced WordPress site managers. You add internal links to three existing posts pointing to your new page. You resubmit those posts in GSC. They get reindexed the same day. But your new page still shows “Referring page: None detected.”
What happened: your caching plugin (WP Rocket, LiteSpeed Cache, W3 Total Cache) or your hosting’s server-level cache served Googlebot a cached version of those linking pages — the version that existed before you added the new links. Googlebot reindexed the pages from cache, which means it saw the old version without the new links. Your new page remained effectively invisible.
How to confirm it: After adding internal links to existing posts, do View Page Source (Ctrl+U) on those pages — not browser Inspect, which shows the live DOM. Search for the URL of your stuck page in the raw HTML source. If it does not appear, the cached version does not contain the link.
How to fix it: Clear your caching plugin specifically on the linking pages. Then also contact your host to clear server-level cache on those same URLs — hosting cache and plugin cache are independent layers and both need to be cleared. Only after confirming the links appear in the raw HTML source should you resubmit those pages in GSC.
3. Page Not in XML Sitemap
If a page is not in your XML sitemap and has no internal links pointing to it, Google has no way to discover it at all. This happens when custom post types, certain categories, or specific page templates are excluded from sitemap generation by your SEO plugin settings.
How to confirm it: Fetch your sitemap URL (usually yoursite.com/sitemap_index.xml or yoursite.com/sitemap.xml) and search for the URL of your stuck page. If it is not there, check your SEO plugin settings to confirm the post type or category is included in sitemap generation.
How to fix it: In Rank Math, go to Sitemap settings and confirm the relevant post type is enabled. In Yoast, check SEO → General → Features → XML Sitemaps, then drill into the content types section. After fixing the sitemap, resubmit it in GSC under the Sitemaps report.
4. Crawl Budget Being Used Elsewhere
On large sites or sites with significant technical debt — lots of redirect chains, duplicate URLs, low-quality pages, or faceted navigation generating thousands of URLs — Google may spend its crawl budget on other pages before reaching your new post.
This is less common on small to medium WordPress sites but becomes relevant if your site has grown quickly or has accumulated technical issues over time. Signs include consistently slow indexing across multiple new pages, not just one specific post.
How to fix it: Run a full technical SEO audit to identify what is consuming crawl budget unnecessarily. Common culprits include tag archives, date archives, author pages, URL parameters, and paginated URLs that add hundreds of low-value pages to your crawlable URL space. Use robots.txt and noindex directives strategically to reduce unnecessary crawling and help Google focus on higher-value content. I cover the full approach to crawl budget optimization including which pages to block and which to keep accessible.
| GSC Status | Likely Cause |
|---|---|
| Discovered – Currently Not Indexed | Internal links, crawl priority |
| Crawled – Currently Not Indexed | Quality, duplication |
| Blocked by robots.txt | Robots issue |
| Duplicate without user-selected canonical | Duplicate/canonical issue |
| Blocked due to access forbidden (403) | Firewall/WAF |
Crawl Stage Problems
These are issues where Google attempts to visit the page but something blocks the visit or prevents a successful fetch.
5. Blocked by robots.txt
A Disallow rule in your robots.txt is preventing Googlebot from crawling the page. This blocks the crawl entirely — Google knows the URL exists but cannot visit it.
How to confirm it: In GSC URL Inspection, check “Indexing allowed?” If it shows “No: blocked by robots.txt,” that is your answer. You can also check your robots.txt directly at yoursite.com/robots.txt and look for Disallow rules that would match your page’s URL path.
How to fix it: Remove or narrow the Disallow rule that is catching your page. Be careful with broad rules like Disallow: /blog/ that could be blocking your entire blog. After fixing robots.txt, request indexing in GSC.
6. Blocked by noindex Tag
The page has a noindex directive that is explicitly telling Google not to index it. This is different from robots.txt — noindex allows the crawl but blocks the indexing at the page level.
How to confirm it: In GSC URL Inspection, “Indexing allowed?” will show “No: noindex.” You can also check the page source for a meta robots tag containing “noindex” or an X-Robots-Tag HTTP header with noindex.
How to fix it: The tricky part is finding where the noindex is coming from. Check in this order: your SEO plugin settings for the specific post, your SEO plugin settings for the post type or category, your theme settings, and any membership or access restriction plugins. After removing the noindex, request indexing in GSC.
A common WordPress-specific trigger: if you had “Discourage search engines from indexing this site” enabled in Settings → Reading during development, and you launched without unchecking it, your entire site is noindexed. Check this first on brand new sites.
7. Server Returning a 403 Forbidden Error to Googlebot
The page loads fine for human visitors, but Googlebot is receiving a 403 access denied response. Something on the server is blocking Googlebot’s user agent specifically.
Common causes include WAF (Web Application Firewall) rules at the hosting or CDN level that flag Googlebot’s IP or user agent, security plugins with aggressive bot-blocking settings, or access restrictions applied to specific URL path patterns. One pattern I have diagnosed firsthand: URL slugs that contain certain words — “403,” “forbidden,” “hack,” “attack” — can trigger server-side pattern matching that interprets the request as a security probe and returns a 403, even though the page is completely public and visible to browsers.
How to confirm it: GSC URL Inspection will show “Page fetch: Failed — Blocked due to access forbidden (403)” and the status will read “Page is not indexed: Blocked due to access forbidden (403).”
How to fix it: Check your hosting firewall and WAF settings for rules that might be blocking Googlebot. If you use Cloudflare, check your firewall rules for anything that could match Googlebot’s user agent or IP range. Check your security plugin settings for bot blocking or rate limiting that may be too aggressive. Use the GSC “Test Live URL” feature and examine the HTTP response headers to identify exactly where the block is originating — at the server, CDN, or plugin level.
8. Server Errors (5xx) During Googlebot’s Crawl
Googlebot attempted to visit the page but the server returned a 500-level error — it crashed, timed out, or was unavailable. This can happen if the server is under load during Googlebot’s crawl or if a specific page triggers a PHP error.
How to confirm it: GSC URL Inspection will show a 5xx error in the page fetch field. Also check your server error logs for the time period around when you would expect Googlebot to crawl.
How to fix it: Check the specific error. A 500 error on a specific page often points to a PHP memory limit issue or a plugin conflict on that page. A 503 error may indicate general server overload. Ensure caching is working correctly so Googlebot is served cached pages rather than triggering full PHP execution on every visit. See my guide on fixing server errors in WordPress for diagnosis steps.
Indexing Stage Problems
These are issues where Google successfully crawls the page but decides not to add it to the index. The status in GSC will show “Crawled — currently not indexed” with a real crawl date and successful page fetch.
9. Thin or Low-Quality Content
Google crawled the page, evaluated the content, and decided it does not meet the quality threshold for indexing. This is not about word count specifically — a 300-word page that directly and completely answers a specific question can be indexed. A 1,500-word page that is vague, repetitive, or does not add anything beyond what ten other pages already say may not be.
Google is increasingly good at assessing whether a page genuinely helps a searcher or just exists to fill a keyword gap.
How to confirm it: Use “View Crawled Page” in GSC URL Inspection to see what Google actually rendered. Does the page look useful and substantive? Also honestly evaluate whether this page offers anything a searcher could not get more easily from another page on your site or from a competitor.
How to fix it: Improve the page substantively. Add specific detail, real examples, original perspective, or a format (table, checklist, comparison) that makes it genuinely more useful than existing indexed content on the same topic. Then request indexing after making the improvements.
10. Content Too Similar to Other Pages on Your Site
You have multiple pages on your site covering the same topic from slightly different angles. Google indexed one of them and considers the others redundant. This is a keyword cannibalization problem — your pages are competing with each other, and Google resolves the competition by picking one and ignoring the rest.
This is particularly common when a site has both a service page and multiple blog posts targeting the same primary keyword, or when older posts cover the same ground as newer ones without enough differentiation.
How to confirm it: Search Google for your target keyword with site:yourdomain.com. If multiple pages appear for the same query, or if a different page than the one you are trying to index appears, cannibalization is likely. Also check “View Crawled Page” to see what Google rendered — if it looks very similar to another indexed page on your site, that is the issue.
How to fix it: Differentiate the pages more clearly, consolidate them if they are covering the same ground, or add a canonical tag pointing to the primary version. The fix depends on whether the pages serve genuinely different search intents or are actually duplicating each other. I cover this in full in my guide on duplicate content in WordPress.
11. Page Rendering Issues Hiding Content From Googlebot
The page looks great in your browser, but when Googlebot rendered it, key content was missing — hidden behind JavaScript interactions, loaded only after scroll events, or dependent on API calls that did not complete during rendering. Google saw a thin page and decided not to index it.
How to confirm it: Use “View Crawled Page” in GSC URL Inspection. This shows a screenshot and the HTML of what Google actually rendered, not what your browser shows. Compare it to what you see as a visitor. If they look significantly different — missing sections, blank image areas, collapsed content — rendering is the issue.
How to fix it: Move critical content into static HTML rather than JavaScript-rendered content where possible. For lazy-loaded images, ensure the actual image src URLs are present in the HTML source (not just JavaScript placeholders). For WordPress specifically, check whether your caching plugin is serving a pre-rendered version that does not include dynamically loaded content.
12. Google Chose a Different Canonical
You have a canonical tag on the page, but Google disagrees with it and has chosen a different URL as the canonical. It will index the URL it prefers and skip yours.
How to confirm it: In GSC URL Inspection, check “Google-selected canonical.” If it shows a different URL than your page URL, Google has overridden your canonical. The status may show as “Duplicate — Google chose different canonical than user.”
How to fix it: Understand why Google prefers the other URL. Usually it has more inbound links, better load time, or stronger content. Either improve your page to make it the clearly preferred version, or accept Google’s choice and redirect your page to the Google-preferred URL. Simply re-declaring the same canonical without addressing the underlying reason Google overrode it will not change the outcome. See my guide on canonical tags for the full technical detail.
Special Cases Worth Knowing
The Page Was Recently Published
If the page was published in the last 48–72 hours and this is a relatively new site, the answer may simply be patience. New sites with low crawl authority do not get crawled immediately after every publish. That said, if another page published on the same site on the same day indexed fine and yours did not, timing alone is not the explanation — something specific to your page is the issue.
The Page Was Previously Indexed and Then Dropped
If a page was indexed, ranked, and then disappeared from Google Search, that is a different situation from a newly published page that never indexed. A page dropping from the index is usually a signal that Google re-evaluated the content and changed its quality assessment — often triggered by a core algorithm update, a significant change to the page itself, or competing pages improving while yours stayed static.
Check the Performance report in GSC to confirm when impressions for that page dropped to zero. Then check whether any changes were made to the page around that time, or whether a core update rolled out in that period.
“Sitemaps: Temporary Processing Error”
If the GSC URL Inspection panel shows “Temporary processing error” under Sitemaps, this is a GSC-side glitch, not a problem with your sitemap or your site. It typically resolves itself within a day or two and does not need any action on your part.
The Diagnostic Workflow I Use
When a client asks me why a specific page is not indexed, this is the exact order I work through:
- Check GSC URL Inspection — read the status message and all crawl fields carefully
- Check “Referring page” — if None detected, internal link visibility is the first thing to investigate
- Check “Page fetch” — if Failed with an error code, address the technical block before anything else
- If crawled successfully but not indexed — use “View Crawled Page” to assess what Google saw
- Check for noindex tags in page source and SEO plugin settings
- Check robots.txt for accidental blocks
- Run a site: search for the target keyword to check for cannibalization
- Review the content honestly for quality and differentiation
Working through this order means you never spend time optimizing content when the real issue is a server block, and you never chase technical fixes when the real issue is content quality. The status message in GSC tells you which half of this list to focus on first.
What Not to Do
A few things that are commonly suggested but rarely help and sometimes make things worse:
Do not repeatedly click Request Indexing without making a change. Google sees the repeated submissions. If the page has not changed and the underlying issue has not been resolved, resubmitting does not help. Request Indexing is most effective as a signal that you have updated the page — use it after making a substantive change, not as a first response to seeing the page is not indexed.
Do not use RankMath’s Instant Indexing API for general blog posts. The Indexing API is officially supported by Google only for job postings and livestream structured data. Using it for general content is against Google’s guidelines and may produce unreliable results. It is not a substitute for addressing the actual indexing issue.
Do not add links from service pages as a first response to a crawling problem. Service pages do pass link equity, but adding links from every available page when the real issue is caching or content quality is treating the symptom rather than the cause.
Do not change the URL slug as a fix for a 403 error. If the 403 is coming from a server-level rule, renaming the URL may not resolve it — and creating a new URL without properly redirecting the old one adds a redirect chain problem on top of the original issue.
Frequently Asked Questions
How long does it take for Google to index a new page?
It varies widely depending on your site’s crawl authority and how well the page is linked internally. On established sites with frequent publishing, new pages can be indexed within hours to a few days. On newer sites or sites that publish infrequently, it can take several weeks. If another page published on the same site on the same day indexed quickly while yours did not, the delay is not about timing — something specific to that page is the issue. Use the URL Inspection tool to identify what.
Will requesting indexing in GSC speed up the process?
Only if you have already resolved the underlying issue. Request Indexing signals to Google that the page is ready to be re-evaluated — it works best after you have made a substantive change or fixed a technical problem. Clicking it on a page with unresolved issues (missing internal links, thin content, caching problems) will not accelerate anything. It also does not override Google’s quality assessment — if the page was crawled and rejected, resubmitting without improving the content will produce the same result.
Why did my page get indexed and then disappear from Google Search?
A page dropping from the index after being indexed is usually a re-evaluation triggered by a core algorithm update, a significant change to the page itself, or competing pages improving while yours stayed static. Check the Performance report in GSC to confirm the exact date impressions dropped to zero. Then check whether any page changes were made around that time, or whether a Google core update rolled out in that period. The fix is typically a content improvement, not a technical one.
My page is indexed but not ranking — what is wrong?
Indexed and ranking are different things. If the page is indexed but generating zero impressions in the GSC Performance report, the most common causes are: the page targets keywords with very low search volume, stronger pages on the same topic are outranking it, or the content does not match the actual search intent for the target keyword. Check what pages are currently ranking for your target keyword and honestly assess whether your page is more useful, more specific, or better structured than those results.
Can changing the URL slug fix a 403 indexing error?
Usually not, and it can create additional problems. If the 403 is caused by a server-level WAF rule or firewall pattern, the new URL slug may trigger the same block. Changing the slug without setting up a proper 301 redirect from the old URL also creates a broken link for any pages already linking to it. Identify and fix the server configuration issue first — use GSC’s Test Live URL to examine the HTTP response headers and pinpoint where the block originates.
Is it normal for some pages on a site to index quickly while others take weeks?
Yes, this is normal and expected. Google prioritizes crawling pages it considers more likely to be high quality and relevant, based on signals like inbound internal links, topical authority, and historical crawl data for the site. A new page with strong internal links from already-indexed authoritative pages will get crawled faster than a new page with no referring links. It is not random — it reflects how well each page is integrated into your site’s overall link structure.
The Key Takeaway
Almost every indexing problem I have diagnosed comes down to one of the causes in this guide. The key is reading what GSC is actually telling you rather than assuming the cause and jumping to a fix.
The most important habit to build: check the URL Inspection tool before taking any action, read every field in the crawl section, and match what you see to the specific cause category above. That alone eliminates most of the trial-and-error that makes indexing problems so frustrating to solve.
If you are working through a specific case and want a second pair of eyes on what GSC is showing, drop the details in the comments.
