WordPress crawled currently not indexed: earn its place
You are in Search Console, looking at an important WordPress URL. It is in the sitemap, Google has crawled it, and yet the Page indexing report says Crawled – currently not indexed. The page is live, colleagues can see it, and somebody has already hit Request indexing more than once.
For a service business in Dubai, the UAE, Liverpool or the wider UK, that can feel daft. But crawling a URL and retaining it in Google’s index are separate decisions. The useful question is not how many more times you can submit it. It is whether the page gives Google a clear enough reason to keep it.
A crawl is not an acceptance letter
Google may fetch a page to understand it without adding it to search results. Its Page indexing documentation distinguishes crawling from indexing, notes that some exclusions are expected, and points site owners to URL Inspection when investigating a particular page.
WordPress crawled currently not indexed usually means Google has seen the URL but has not selected it for indexing at that point. Common reasons include duplicate or very similar content, a conflicting canonical signal, thin material, weak internal linking, or a page that has little separate purpose from another URL already known to Google.
That does not mean every excluded URL needs rescuing. Tag archives, filtered URLs, attachment pages, staging remnants and old campaign pages may be better left out. The trouble starts when an important service page, location page or useful article is quietly missing while weaker variations are piling up around it.
First decide whether the URL deserves indexing
Start with the business job of the page. Can you explain what someone would find there that they cannot get more clearly from another page on the site?
A separate indexed page is more defensible when it has its own audience, question, offer, evidence or next action. A page written only because someone wanted another keyword variation is less convincing. Publishing five articles that all answer the same service question in slightly different outfits creates crawl noise, not necessarily more visibility.
This is also where a broader AI readiness audit of website structure and content clarity can be useful. The same muddled page relationships that confuse indexing can make an offer harder for people and automated systems to interpret.
Use URL Inspection to identify the actual disagreement
Open the specific URL in URL Inspection, then compare its current status with the broader Page indexing report. You are looking for signals that do not agree with one another.
- Indexing allowed: confirm the page is not blocked by a noindex directive, robots rule or access issue.
- Canonical: check the user-declared canonical and Google’s selected canonical. If Google selects another page, treat that as a clue rather than a minor detail.
- Last crawl: make sure Google fetched the version you believe is live, especially after a rewrite or migration.
- Sitemap presence: confirm the URL is included only if it is a page you genuinely want indexed.
- Referring pages: look for meaningful internal links, not merely a URL buried in an XML sitemap.
A WordPress sitemap can be technically present while still giving a misleading picture. Cached sitemap output, an old SEO plugin configuration or a URL that redirects elsewhere can leave owners inspecting the wrong version. If the sitemap seems stale, use this WordPress sitemap cache diagnosis before treating sitemap inclusion as proof that the page is ready.
Compare the competing pages, not just the excluded one
A familiar example is a WordPress service article that appears correctly in the sitemap and has been crawled. It remains excluded while three similar posts compete for the same intent: one is a general service guide, one is a local variation with a changed heading, and one is a newer rewrite with much the same body copy.
Put those pages side by side. Check the title, main heading, introductory answer, service details, proof, FAQs, internal links and call to action. If the practical answer is that they all say roughly the same thing, Google has little reason to retain every version.
Do not solve that by stretching the excluded page with filler. Give it a distinct job. It might cover a different buyer stage, a genuinely different technical problem, a separate location with local evidence, or a useful operational decision the other pages do not address. If it cannot earn that role, consolidate it into the stronger page and redirect it carefully.
Internal links should explain why the page matters
Google can discover a URL through a sitemap, but internal links help establish its place within the site. Link to an important article from a relevant service page, a related guide and, where sensible, a hub page. Use anchor text that describes the topic rather than vague prompts.
There is a practical WordPress wrinkle here. A page builder template may show related posts visually but output links only after JavaScript runs, or a navigation change may have removed the only contextual link while leaving the page in the sitemap. Check the rendered page and the actual source, not just the editor preview. The editor is often very confident right up until it isn’t.
Stable URLs, accessible templates and dependable internal navigation all support a cleaner indexing picture. Website stability work that supports AI readiness is relevant because a site that regularly serves inconsistent versions, broken templates or thin auto-generated pages gives search systems more uncertainty to work through.
Make one meaningful change, then reinspect
Once you have identified the likely reason, make the smallest change that genuinely improves the page’s case. That could mean correcting the canonical, removing an accidental noindex setting, consolidating duplicate articles, adding useful original content, or placing stronger contextual internal links.
- Confirm the preferred URL and whether it should be indexed at all.
- Resolve technical conflicts such as canonicals, redirects, blocked resources or stale sitemap entries.
- Differentiate or consolidate pages competing for the same intent.
- Add relevant internal links from pages with a clear relationship to the topic.
- Use URL Inspection to test the live URL, then request indexing once the page has materially changed.
Keep a short record of what changed and when. Without it, a later plugin update, cache purge or content edit can muddle the picture again, and you are back guessing from a status label.
When the evidence is strong enough to escalate
Escalate when the page is important, indexable, self-canonical or correctly canonicalised, materially distinct, internally linked, available to Google, and still excluded after Google has had an opportunity to recrawl the revised version. Bring the inspected URL, selected canonical, crawl date, examples of competing URLs, sitemap status and the changes made. That is far more useful than saying Google is ignoring the site.
Questions about crawled currently not indexed pages
How long can indexing take after requesting it?
There is no fixed timetable. Google may recrawl quickly or take longer depending on its own systems and the site context. Request indexing is a prompt to consider the URL, not a guarantee of inclusion. Concentrate on whether the page is technically consistent, useful and distinct before submitting another request.
When is an excluded URL expected rather than a problem?
Exclusion is often expected for duplicate versions, redirects, filtered pages, low-value archives, old pages being retired and URLs deliberately marked noindex. It becomes a problem when a commercially important page with a clear purpose is excluded while less useful or overlapping pages are being indexed instead.
If an important page is stuck in this state, fix the reason the page is being excluded before submitting it again. A proper review starts with the URL’s role, its competing pages and the signals Google is actually receiving.