Crawled – Currently Not Indexed: How I Diagnose the Real Cause

Google Search Console says the page was crawled. The URL returns 200.
Your sitemap includes it. Yet it still sits under “Crawled –
currently not indexed.”

My first judgement is simple: do not keep pressing “Request
indexing”. That button asks Google to look again. It does not give
Google a better reason to keep the page in its index.

Google’s own Page indexing report defines this status plainly: Google
crawled the page but did not index it, and the page may or may not be
indexed later. Google also says there is no need to resubmit the URL
merely because it has this status. The useful question is not “How do I
submit it again?” It is “What would Google find different if it returned
today?”

This is the diagnosis I use for WordPress pages, including service
pages where the commercial cost of being absent can be far greater than
the number of affected URLs suggests.

What the status actually
tells you

“Crawled – currently not indexed” means discovery and crawling have
already happened. Google reached the URL and processed it, but the URL
is not currently in the searchable index.

That distinction matters. A “Discovered – currently not indexed” URL
has not yet been crawled. A crawled URL has moved further through the
process, so repeatedly editing robots.txt or resubmitting a sitemap is
often aimed at the wrong stage.

Google does not guarantee indexing. Its documentation says indexing
depends on the page content and metadata, and lists low-quality content,
robots rules and difficult site design among common reasons a page may
be missing.

One caution: Search Console reports can lag. I inspect the exact URL
before treating a report row as the current truth.

Start with one URL, not
the whole report

Large lists encourage rushed fixes. I begin with one commercially
important example, then compare it with two useful controls:

• a similar page that is indexed;
• another excluded page using the same WordPress template;
• the canonical URL that Google selected, if Search Console shows
  one.

This comparison tells me whether I am looking at an isolated page
problem or a repeatable template problem. If every weak location page is
excluded, rewriting one URL will not repair the system that created the
others. If only one strong service page is affected, the investigation
needs to stay page-specific.

The four-gate diagnosis

The table below is the decision tool I would use before changing the
page.

The order is deliberate. There is little value rewriting 1,500 words
if the rendered page still carries noindex. There is
equally little value checking the sitemap for the fifth time when Google
has already crawled the URL and the real issue is duplication.

Gate 1: confirm
that the page can be indexed

Check the live URL and the version Google fetched in URL Inspection.
I want to see a successful response, indexable robots directives and the
main content present in rendered HTML.

WordPress creates a few common traps. A staging setting can leave
“Discourage search engines from indexing this site” enabled. An SEO
plugin can add a page-level noindex rule. A CDN or security layer can
serve a different response to Googlebot. A JavaScript template may also
hide the useful content until someone interacts with the page.

Google explains that a noindex rule only works when the
crawler can access the page and read it. Blocking the same URL in
robots.txt can prevent Google from seeing that directive. That is why I
treat crawling control and indexing control as separate jobs.

Gate 2:
decide whether this URL is the real canonical

A self-referencing canonical is useful, but it is not an order Google
must obey. Google selects a representative URL from duplicate or very
similar pages and can choose a different canonical.

On WordPress, I compare the clean URL with parameter versions,
attachment pages, archives, HTTP or HTTPS variants, trailing-slash
variants and any near-duplicate service or location pages. Then I check
whether redirects, internal links, canonical tags and the XML sitemap
all point to the same destination.

Conflicting signals create ambiguity. Fix the cluster, not just the
tag.

Internal links
show whether the page matters

An XML sitemap helps Google discover URLs, but Google is explicit
that a sitemap does not guarantee crawling or indexing. For a small
WordPress site, strong internal linking often tells a clearer story than
another sitemap submission.

Google uses links to discover pages and as a relevance signal. I
therefore inspect:

• how many crawlable internal links point to the URL;
• whether those links come from relevant, established pages;
• the anchor text and surrounding sentence;
• how many clicks separate the URL from the homepage;
• whether the page is part of a logical service or insight
  cluster.

For this website, for example, a focused article about index
exclusion belongs naturally beside the Technical SEO service and the existing technical SEO audit
checklist. That relationship helps readers move from symptom to
wider diagnosis. It also gives search engines clearer context.

Do not add twenty footer links to make a page look important. A few
relevant editorial links are more useful and less noisy.

The
difficult question: does the page deserve its own URL?

This is where many indexing checklists become too polite.

Sometimes the page is technically fine and still should not be
indexed. A thin tag archive, a near-copy of another service page or a
location page with only the town name changed may have no distinct job
in search. Requesting indexing will not repair that.

I test standalone value with five questions:

1. Which query or task is this page meant to satisfy?
2. Is another URL already a better answer?
3. What evidence, experience or decision support exists here that is
   absent elsewhere?
4. Would a visitor miss anything useful if this page were merged into
   another?
5. Is the page written for a real local need, or was a place name
   inserted into a generic template?

For a Bristol service business, a useful local page might explain
service coverage, constraints, process, local proof and the next action.
A cloned page with “Bristol” swapped into the heading is not a local
strategy. It is duplication with a postcode.

Possible outcomes are not limited to “rewrite and resubmit”. The
correct decision may be to merge the page, redirect it, keep it
accessible but noindex it, or remove it when it serves no user
purpose.

A practical WordPress
repair sequence

Once I know which gate failed, I work in this order:

1. Record the baseline. Save the Search Console
   status, last crawl date, selected canonical, referring pages and current
   organic performance.
2. Fix eligibility conflicts. Correct status codes,
   robots rules, rendering or accidental redirects.
3. Consolidate duplicates. Choose one destination and
   align redirects, canonicals, sitemap entries and internal links.
4. Strengthen the page’s job. Make the intent
   specific. Add first-hand reasoning, evidence, examples or a decision
   tool that a competing page does not provide.
5. Improve internal context. Link from relevant
   services or guides with descriptive anchor text.
6. Validate the live output. Crawl the page again and
   inspect what Googlebot can receive.
7. Request indexing once. Use URL Inspection after a
   material change, then allow time for recrawling and evaluation.
8. Measure the result. Watch index status,
   impressions, queries and conversions rather than treating submission as
   success.

Google’s recrawl guidance allows site owners to request re-indexing
after adding or changing a page. Use that step at the end. A request
without a material improvement only repeats the same test.

When I would
investigate a site-wide issue

One excluded article is different from a pattern affecting every new
service page. I broaden the audit when I see:

• a sudden rise after a WordPress theme, plugin or migration
  change;
• the same canonical or noindex problem across a template;
• large numbers of generated archives, parameters or thin location
  pages;
• important pages becoming deeper in the internal link structure;
• rendered mobile content differing from desktop;
• server errors or security controls affecting Googlebot.

That is the point where an isolated edit becomes inefficient. A
crawl, template comparison and Search Console export can reveal whether
the same cause is being repeated across the site. My technical SEO audit
process explains the wider sequence I use to separate symptoms from
root causes.

What success should look
like

The immediate success signal is not “Request submitted”. It is that
the intended canonical becomes indexed and starts earning impressions
for relevant queries.

I would monitor:

• URL Inspection and Page indexing status;
• Google-selected canonical;
• impressions and query relevance for the repaired URL;
• clicks from internal links to the page;
• visits to the contact page and completed enquiry actions;
• recurrence of the same exclusion across the template.

Indexing can still take time, and inclusion is never guaranteed. The
purpose of the repair is to remove contradictions and give the URL a
clear reason to exist.

If an important WordPress service page remains excluded after the
four gates have been checked, I can review the technical signals,
internal architecture and content overlap together. Discuss your website and include the affected URL
plus the Search Console status you are seeing.

Evidence base

Sources

• Google
  Search Console: Page indexing report
• Google
  Search Central: How Google Search works
• Google
  Search Central: Canonicalisation
• Google
  Search Central: Link best practices
• Google
  Search Central: Sitemaps
• Google
  Search Central: Block indexing with noindex
• Google
  Search Central: Ask Google to recrawl a URL

About the author

Md Onik Mia

Md Onik Mia is a Bristol-based SEO Expert and
Technical SEO Specialist with 5+ years of SEO and digital marketing
experience. His work focuses on Technical SEO, Local SEO, SEO strategy,
AEO and AI Search, analytics and automation. View
selected projects or learn more about working with an SEO expert in Bristol.