A page can sit in your sitemap, return a clean 200, carry a good internal link profile, and still not exist as far as Google is concerned. Search Console has a name for it: crawled currently not indexed. Google fetched the page, read it, and decided against keeping it.
We ran that check across all 285 published pages on this site on 25 August. The results were worse than we’d expected, and the two most damaged pages turned out to be the ones we’d been sending the most internal links to.
Every number below came out of that audit. Nothing is modelled, and nothing is a benchmark borrowed from someone else’s dataset.
What the Status Means
Google’s crawler reached the page and rendered it. No robots rule blocked it, the server didn’t error, and the canonical pointed at itself. Then the indexing step declined.
That’s different from every other coverage problem, and the difference matters because it changes the fix.
- Blocked. A robots rule or a noindex tag told Google to stay out.
- Discovered, not crawled. Google knows the address but hasn’t fetched it.
- Duplicate. Google picked a different page as the canonical version.
- Crawled, not indexed. Google read it and chose not to store it.
Only the last one is a judgement about the page itself. The first three are instructions Google followed, and you fix them by changing the instruction.
There’s no tag to change here. The page is competing for a slot and losing, usually against something you published yourself.
That’s also why the status feels unfair when you first meet it. Nothing is broken, nothing is misconfigured, and there’s no error message to act on.
Impressions Cannot Tell You a Page Is Indexed
This is the part that cost us the most time, so it goes near the top.
Search Console performance data is historical. Index status is current. A page can report impressions from June and be out of the index in August, and the performance report will keep showing you the June numbers.
One of our pages proves it. It logged 108 impressions over 365 days and its current status is crawled, currently not indexed.
Reading the performance tab alone, you’d call that a weak page and try to improve it. It isn’t weak, it’s absent, and no amount of rewriting fixes absence.
The reverse trap is equally common. A page with no impressions might be indexed and simply never surfaced, which is a different problem with a different fix.
You can’t separate these two from the performance report. You have to ask about the index directly.
The Check Takes One API Call
Search Console’s URL Inspection tool answers this in the interface, one address at a time. For a whole site you want the API version, which returns the same verdict as structured data you can loop over.
Four fields carry most of the value.
- coverageState. The plain-English status, and the field you came for.
- googleCanonical. The address Google chose for this content.
- userCanonical. The address you declared. A mismatch is its own diagnosis.
- lastCrawlTime. How stale Google’s copy is, which reframes everything else.
That last one deserves attention. One of our unindexed pages hadn’t been crawled since May. Google’s judgement was three months old, made against a version that no longer existed.
Google documents the quota as 2,000 queries per day and 600 per minute for each site. That’s generous for a shortlist and nowhere near enough to inspect a large site daily, so pick your candidates before you start.
Our shortlist was simple: every page with a meaningful internal link count and disappointing traffic. That’s where the expensive problems hide, because those pages have been paid for twice, once to write and once to link to.
What We Found Across 285 Pages
Three separate defects, none of which showed up in any performance report.
- Two pages not indexed despite carrying 22 and 23 internal links each.
- 43 pages with a corrupted meta field that removed their structured data.
- Five pages missing from the sitemap because of that same field.
A fourth finding was about the audit itself rather than the site, and it changed how we run these. We’ll come to it.
The Pages With the Most Internal Links Were the Ones Google Skipped
We had five pages covering one topic. Here’s the whole cluster, measured over 365 days.
| Page | Words | Internal links in | Impressions | Index status |
|---|---|---|---|---|
| Tool-specific guide | 2,435 | 8 | 11,857 | Indexed |
| Find and convert guide | 3,285 | 1 | 617 | Indexed |
| How to find guide | 3,841 | 23 | 108 | Not indexed |
| Services comparison | 2,116 | 4 | 12 | Indexed |
| Head-term overview | 4,288 | 22 | 0 | Not indexed |
Read the last two rows against the first. The page earning 11,857 impressions had eight internal links. The two earning almost nothing had 22 and 23.
The page on zero impressions was the longest of the five and held the cleanest address, the one matching the head term. It had never been indexed at all.
So 45 of the 46 internal links we spent on that topic pointed at pages Google wouldn’t keep. That single ratio reframed the whole audit.
Internal links aren’t free. Every one is a vote you could have cast elsewhere, and almost all of ours were landing where Google wouldn’t keep them.
Nothing in Search Console surfaces this. The performance report shows impressions per page, the links report shows internal links per page, and nobody joins the two against index status.
A Corrupted Meta Field Was Hiding 43 Pages
The second defect was a data problem, not an editorial one.
Our search plugin stores a robots directive for each page. On 43 posts that value was left behind by an earlier version of the plugin, stored twice-encoded. The current version reads back a text string where it expects a list, so it gives up.
The stored intent was ordinary, only index and follow. Nothing about the pages was wrong, and nothing an editor could see was different.
The consequence wasn’t ordinary. Every one of those pages served two structured data blocks instead of three, and the missing one was the block describing the article itself.
We only caught it by comparing a suspect page against a known good one in the served source. The pages looked correct in the editor, reported no errors, and rendered properly for a human reader.
Clearing the legacy field on one page restored its structured data immediately. That’s a two-key deletion rather than a rewrite, which is a useful reminder that not every indexation problem is a content problem.
It also explains why generic advice fails here. Every article about this status assumes thin content, and no amount of editing would have fixed a single one of those 43 pages.
Five Pages Were Missing From the Sitemap Entirely
The same corrupted field had a second effect we hadn’t anticipated.
Five published, indexable posts were absent from the sitemap. They weren’t marked noindex and weren’t excluded by any setting anyone chose. They were dropped because the plugin couldn’t parse their robots value.
A sitemap is the cheapest signal you control. Publishing a page and then failing to list it is self-inflicted, and we found it only by diffing the published list against the sitemap address by address.
That diff is worth running on any site over a hundred pages. It takes one database query and one fetch, and the answer should be zero.
Ours wasn’t zero. The diff is what turned an invisible plugin fault into a list we could act on.
Our First Check Reported One Noindex Page. There Were Twelve.
This one is about method, and it’s the finding we’d most want another team to copy.
Our first pass tested whether the robots value was a list containing “noindex”. It reported a single noindex page across 285 URLs.
The value is sometimes stored as a plain string rather than a list. The check silently skipped every page in that format, and the true count was twelve, including ordinary guides nobody meant to hide.
An audit that tests one storage format and reports a clean result is worse than no audit, because it buys false confidence. Normalise the value before you test it.
Run a second check that approaches the same question differently. A single result across 285 URLs is the kind of number worth testing twice before you trust it.
We caught it because the sitemap diff returned pages the noindex check had cleared. Two checks disagreeing is how you find a broken check, which is the argument for always running more than one.
It Happens Because Near-Duplicates Compete, Not Because Pages Are Thin
Our five pages weren’t spam. Each was researched, each ran past 2,000 words, and each was written months apart by someone trying to be thorough.
Their headings tell the real story. Three carried a why-it-matters section, a how-to-find section, a prioritise section, an outreach section and a common-mistakes section. That’s one page written three times.
Google indexed one of the three and declined the other two. That’s a reasonable response to being offered the same answer repeatedly.
The uncomfortable version: publishing more on a topic you already cover can reduce how much of your site gets indexed. Volume and coverage aren’t the same thing, and they can pull against each other.
Checking headings rather than titles is what makes this visible. Our three pages had different titles and nearly identical structures.
How We Chose Which Page Survived
The obvious choice was the page already indexed, the one on 617 impressions. We didn’t pick it.
We kept the head-term address instead, the page on zero impressions, because its address was the cleanest and it already held 22 internal links. Its absence from the index looked like a symptom of the duplication we were removing, not an independent verdict on the page.
That’s a bet, and we’ve said so publicly rather than presenting it as obvious. The safer play would’ve been keeping the indexed page and accepting a worse address.
Whichever you choose, take the baseline first. Impressions, clicks, average position and index status for every page involved, saved before you touch anything.
Save the original page bodies too. We kept a copy of all three, which turns a merge from a one-way door into something you can walk back if the re-measure disappoints.
The other rule we set ourselves: keep the retired pages as drafts rather than deleting them. A draft costs nothing and holds its address, so reversing the whole thing stays a ten-minute job.
What We Did, and What We Do Not Know Yet
We merged the three overlapping pages into one, keeping the cleanest address. The merged page runs to roughly 6,100 words because the three sources genuinely covered different depths, so little was discarded.
Then we redirected the two retired addresses, repointed 24 internal links, cleared the corrupted meta field on the survivor, and confirmed its structured data came back.
One detail worth copying: we added the redirects before unpublishing anything, so the old addresses never returned a 404 for a single request.
We also left the retired pages as drafts rather than deleting them. Deleting frees the address, and a stray attachment with the same address can then claim it.
What we can’t tell you is whether it worked. The consolidation ran on 25 August and the re-measure is booked for 6 October. Anyone showing you recovery numbers a day after a merge is showing you noise.
Three Causes, Three Different Fixes
By the end we had three distinct reasons for the same status, and grouping them stopped us applying one fix everywhere.
| Cause | How you spot it | The fix |
|---|---|---|
| Near-duplicate competition | Pages sharing five or more heading types | Merge, redirect, repoint the links |
| Broken stored data | Structured data missing against a control page | Clear the corrupted field |
| Never submitted | Published list and sitemap disagree | Fix the cause, flush the sitemap cache |
Only the first row is about writing. The other two are configuration faults that no editorial work would have touched.
Most published advice on this status assumes the first row and stops there. That advice sends you auditing content quality on pages whose problem is a stored value from a plugin upgrade.
Sorting the affected pages into these three buckets took an afternoon. It saved us from rewriting 43 pages that had nothing wrong with their content.
Fixing the Database Was Not Enough
One more trap, because it nearly let us declare victory early.
After clearing the corrupted field and correcting the affected records, we refetched the sitemap and the missing pages were still missing. The database was right and the served file was stale.
Search plugins cache their sitemaps, and ours had no cache table to clear, so the stale copy lived in the options store instead. Flushing it made the corrected pages appear immediately.
The general shape of this is worth carrying: a data fix and a served-output fix are two separate jobs. Always refetch the public file and confirm the change reached it.
The same applies to page caching. We purge after every write, because the database can be correct while every visitor and crawler still receives the previous version.
The Audit You Can Run This Week
Four steps, in the order that surfaces the most for the least effort.
Diff your published pages against your sitemap
Pull every published address from your database and every address from your sitemap, then list what appears in the first and not the second. The answer should be zero, and it often isn’t.
Normalise before you test for noindex
Whatever your platform stores, handle both a list and a plain string before concluding anything. Count the records your check skipped, not only the ones it flagged.
Inspect your best-linked underperformers
Rank pages by internal links received, take the ones with weak traffic, and inspect those. Trapped equity concentrates there, and the daily quota is ample for a list that size.
Group by intent and count the overlap
List the pages competing for one topic and compare their headings, not their titles. Pages repeating the same five sections are merge candidates, whatever their word counts say.
Not Every Unindexed Page Deserves the Same Attention
Once the list exists, the temptation is to work through it top to bottom. That wastes the afternoon, because the pages differ enormously in what they cost you.
Act first on well-linked pages
A page with 20 internal links pointing at it is consuming authority whether or not it’s indexed. Those are the expensive cases, and they’re expensive every day you leave them.
Leave new pages alone
Anything published in the last two months is probably still being decided. Pruning it early destroys something that hasn’t had its chance, and we’ve seen pages enter the index eight weeks after publication.
Check the crawl date before judging
If Google last crawled the page before your most recent rewrite, the verdict predates your fix. Request a recrawl and wait rather than rewriting a page Google hasn’t seen in its current form.
Treat zero-link pages as low priority
An unindexed page nobody links to costs you almost nothing. It’s a candidate for merging eventually, but it isn’t the fire.
Sorting our own list this way cut it from something daunting to five pages that mattered. Four of those five sat in one cluster, which is how the consolidation ended up being the whole project.
What Not to Conclude From This
Not every unindexed page should be merged or deleted. A new page often sits in this state for weeks before Google makes up its mind, and pruning it early destroys something that was about to work.
Nor is the status always a quality verdict. Our 43-page defect was a broken database value, and editing the content would’ve changed nothing.
Diagnose the cause before choosing the fix. The status tells you Google declined, it doesn’t tell you why, and the three causes we found needed three completely different responses.
Frequently Asked Questions
What does crawled, currently not indexed mean?
You have a page Google fetched and rendered successfully, then declined to store. No robots rule blocked it and the server did not error, so there is no tag to change. The page is competing for an index slot and losing, often against another page on the same site.
Can a page have impressions and still not be indexed?
Yes, and this catches people out. Performance data is historical while index status is current, so a page can report impressions from months ago and be out of the index today. One page in our audit logged 108 impressions over a year and is currently not indexed.
How do I check index status across a whole site?
To check at scale, use the Search Console URL Inspection API rather than the interface, since it returns the same verdict as data you can loop over. Google documents a quota of 2,000 queries per day and 600 per minute for each site, so inspect a shortlist.
Does a page that is not indexed still pass internal link value?
Treat it as though it does not. In our audit 45 of 46 internal links on one topic pointed at pages Google would not keep, so that entire linking budget returned nothing. Point those links at a page that is in the index instead.
Should I delete pages that are not indexed?
Not automatically. New pages often sit in this state for weeks before Google decides, and some cases are technical faults rather than quality judgements. We found 43 pages affected by a corrupted database value where editing the content would have changed nothing.
How long before I can tell whether a consolidation worked?
Allow about six weeks and take a proper baseline first, covering impressions, clicks, average position and index status for every page involved. We merged our cluster on 25 August 2026 and will not draw conclusions until 6 October.