Summarize this article with AI
Crawled - currently not indexed is the Search Console status that tempts people into rewriting whole sections of a site before they know which pages matter. Googlebot visited and read the page, then decided not to index it. The report won't tell you which of those URLs you actually need in search, and that determines whether any fix is worth the effort.
The screenshots in this guide come from a site I manage, where this status grew from about 3.2K to 4.7K pages in three months. I checked the advice in the top-ranking guides against Google's own documentation and dropped the parts it doesn't back.
You'll pull the pages that matter out of the report with the sitemap filter, rule out the statuses that look like this one, match the fix to the cause, and see what Google actually says about timing. Here's the workflow.
What "Crawled - currently not indexed" means
"Crawled - currently not indexed" means Google crawled the page but hasn't added it to its index. The page won't appear in search results.1 Google says it may or may not be indexed in the future, and that there's no need to resubmit the URL for crawling.
It reads like an error, but the Page indexing report in Google Search Console files it as a reason, not an error: you'll find it in the Why pages aren't indexed table with the status Not indexed.1 Older guides call it "Excluded", the label from the old Index Coverage report.
First check: inspect one important affected URL and read the indexed result, not the live test. You're reading Google's stored record there, rather than whatever the live page serves right now. It shows the most recent crawl and index status, plus whether Google selected a different canonical.2
Did Google pick some other URL as canonical? Then you're usually looking at a duplicate status, and that calls for a different fix. A passing live test proves less than it might seem: it doesn't test every indexing issue, and it can't predict Google's canonical choice.2
Key takeaways:
- The pages you want in search come first; the total URL count can wait.
- Use the Page indexing report's sitemap filter to narrow the list.1
- Content, links and rendering come later; first make sure it isn't really a duplicate, noindex or soft 404 case.
- Save Request Indexing for a substantive change, and look at the indexed result again afterward.
Decide which URLs need attention
Start with the pages you want searchers to land on. Their purpose and what URL Inspection shows set the priority; the total count doesn't.
That's about 1,500 more URLs in three months, and the chart can't say why. What matters is which pages entered the group. If the new arrivals are feeds, archives and other utility URLs, the increase is noise. Product pages or articles in the mix? Now you've got work to do.
Expect some housekeeping URLs here too (XML sitemaps, robots.txt, RSS feeds, paginated pages, image files). They don't need landing-page treatment. Pagination and filter pages are a judgment call: does the page do a job nobody else on the site does?
| URL or pattern | Priority | What I do next |
|---|---|---|
| Important article, category or product page | High | Confirm the indexed result, then review content and rendering |
| Many important pages on the same template | High | Compare affected and indexed pages before changing the template |
| XML sitemap, robots.txt, RSS feed or image file | Low | Leave it out of the landing-page queue |
| Pagination, tag or filter page | Depends on its purpose | Judge its standalone usefulness and its links to the content it organizes |
| Parameter URL duplicating an existing page | Consolidation review | Inspect the canonical evidence and use the duplicate workflow if it applies |
| Private URL you don't want in search | High, for access control | Check protection and remove public links and sitemap entries |
Shrinking the count with noindex on a page you want indexed defeats the point. When Googlebot reads a noindex tag or header, Google drops that page from search results.1 The directive only works when robots.txt allows Google to crawl the page.2
Find the pages that matter with the sitemap filter
In Google Search Console → Indexing → Pages, set a sitemap filter at the top first, and only then open Crawled - currently not indexed. I pick the sitemap that holds the pages under review and jot the filter name beside the export, or I'd forget what the list covers.
The Page indexing report offers four scopes:
| Filter | What it shows | Use it to |
|---|---|---|
| All known pages | Every URL known to Google, in a sitemap or not | Scan the full mix of URL types |
| All submitted pages | URLs in a sitemap or sitemap index submitted through the Sitemaps report or robots.txt | Start with the pages you told Google you want |
| Unsubmitted pages only | URLs that aren't in a submitted sitemap | Spot pages missing from your sitemaps, or URLs Google found that you never meant to publish |
| A specific sitemap | URLs listed in that submitted sitemap or sitemap index | Focus on one important page group |
A URL counts as submitted even if Google also discovered it another way. The examples table is limited to 1,000 rows and doesn't necessarily show every affected URL.1 Export the filtered examples by all means. Just remember they're a sample whenever the issue count runs higher. The tighter the filter, the more the list sticks to pages you care about.
Group the export by directory, template or page purpose. Then take a few affected pages from each group, plus one indexed page doing a similar job, to compare against. Here's the worksheet to drop into a spreadsheet:
URL,Sitemap filter,Page purpose,Want indexed?,Indexed result,Last crawl,Declared canonical,Google-selected canonical,Content gap,Internal link gap,Rendering concern,Action,Owner,Change date,Recheck result
https://example.com/guide/,content-sitemap.xml,Public guide,Yes,,,,,,,,Review,,,
Grouping by URL pattern? The Search Console regex cheat sheet has patterns ready to paste. Write down what's actually on the page; a directory name can mislead.
Rule out the look-alike statuses first
Several reasons in the Page indexing report look like this one but need a different fix. Run every priority page through URL Inspection and check the Page indexing section of its indexed result. Confirm the status and, where it's shown, Google's canonical choice before you pick a remedy.2
| Inspection finding | What it means | Where to go next |
|---|---|---|
| Crawled - currently not indexed | Google crawled the page but hasn't indexed it | Continue with the diagnosis below |
| Discovered - currently not indexed | Google found the URL but hasn't crawled it yet | Investigate the crawl stage |
| Alternate page with proper canonical tag | The page points to a canonical that is indexed | Check that it's the version you intended |
| Duplicate without user-selected canonical | Google chose another canonical, and you didn't declare one | Compare the duplicates and pick the preferred URL |
| Duplicate, Google chose different canonical than user | Google's canonical choice differs from yours | Compare the competing URLs and canonical signals |
| A noindex reason | Google found a directive that excludes the page | Decide whether that directive is intentional |
| Live test passes | The live test doesn't cover every indexing issue or show canonical selection | Go back to the indexed result |
Is the reason noindex on a page you want indexed? Then:
- Remove unintended noindex meta tags or X-Robots-Tag headers1
- Check that robots.txt allows crawling, so Google can read the change2
The report lists noindex under a separate reason, so deal with that first. Structured data problems affect rich result eligibility, not this status; handle them separately.2
Searching site:example.com/guide/ gives you a fast hint that only cuts one way. If that exact URL shows up, it's in Google's index, so inspect it before you change anything.1 No match? Inconclusive. Indexed pages sometimes just don't appear in a site: query.
For canonical exclusions, use the alternate-page workflow or the duplicate without user-selected canonical guide. If the reported reason is soft 404, switch to the soft 404 guide before you judge the content here.
Crawled vs discovered: a different stage
Crawling and indexing are separate stages: a visit from Googlebot doesn't guarantee a place in the index.3 With "Discovered - currently not indexed", Googlebot hasn't come by yet. For that status, Google says it typically wanted to crawl the URL but expected that to overload the site, so it rescheduled the crawl.1 Hence the empty last crawl date on those URLs.
For that status, use the discovered currently not indexed workflow. Once a crawl is confirmed, two questions remain: what does the page offer, and can Google render it?
Fixing crawled currently not indexed, one targeted change at a time
Every fix here starts from a hypothesis, compared against an indexed page that does a similar job. Google lists low content quality and website design that makes indexing difficult among the common indexing issues.3 Write the gap down in plain words first. Only then choose a change.
Weigh the content and the intent behind the query
Judge content quality with Google's own self-assessment questions: does the page offer original information, does it add substantial value compared with other pages in search results, and was it made mainly for search engines?4 Thin content isn't a word-count problem, though. With product pages, my test is simple: would a shopper decide faster? Clear specs or an honest comparison pass; another generic description doesn't.
Name the task people arrive to finish. What's missing from the page for that task? Unique content, maybe, or a worked example, or a clear decision. Add it. Got two pages chasing the same purpose? Merging them may be the better move.
Format matters as well. A reader working through a process wants the steps; a definition won't help them. Intent is still your editorial call, and it can't prove why Google skipped the page.
For a larger content review, follow the thin content workflow. In the worksheet, log a precise gap like "no worked example". "Needs more content" doesn't count.
Give the page a path in through internal links
Google reads links as a relevance signal, and it follows them to new pages to crawl. If the sitemap is a page's only way in, it's cut off from your internal linking. Add contextual links from related pages, in spots where a reader would want one.
Hunting for link sources? A site:example.com "topic" search lists candidates; keep only the relevant ones. Each source page goes in the worksheet, next to the anchor text you intend to use.
Check duplicate content and canonical signals
Set the pages side by side: main content, and the task each one serves. Sharing a keyword doesn't make two pages duplicates. Would users be better off with both, or with one merged version?
How to spot it: In the URL Inspection Tool, check whether Google selected a different canonical URL than the page itself.2 Read the canonical from the indexed result. The live test can't predict which canonical Google picks. If it's a duplicate, continue in the duplicate workflow instead of rewriting content.
When the pages are versions of the same content:
- Set the correct rel=canonical tag pointing to the preferred version5
- Link internally to the preferred URL and list only that URL in the sitemap5
- Use a redirect if you want to retire the overlapping page instead of keeping both5
A canonical preference is a hint, not a rule. Google may override your preference if it determines a different page is the better canonical.5 Check Google's choice in the indexed result after the change.
Check rendering and intermittent server problems
If resources are blocked, Google may render the page differently from what users see. Hold the main content up against what the URL Inspection live test renders. That describes the page as it is now. It says nothing about indexing.
Any robots.txt rule blocking CSS or JavaScript the page needs to render? Find it. Main content missing from the render? Get a developer to look at how those resources and the JavaScript load. Retest after the fix, then watch the indexed result.
Intermittent failures? Your server logs will show them, and so will Crawl Stats in Search Console. Crawl Stats breaks crawl requests down by response, file type, purpose and Googlebot type, and shows host status.6 But one page needs its own evidence; a site-wide trend won't settle it.
Our log file analysis workflow keeps that digging organized. And if the reason turns out to be a server error, the 5xx guide is the place to go.
Redirect targets and private URLs
A redirect target that won't get indexed needs its own inspection. Look at its content, its canonical signals and the internal links aimed at it. Several important targets to watch? The focused sitemap in the timing section below handles that.
Anything private should sit behind a login or a password; that's a developer task. Then strip out public links and sitemap entries that lead there. Being unindexed isn't the same as being private.
Look at site-level quality, not an authority score
Google designs its ranking systems around single pages. Site-wide signals and classifiers still play a part in how it understands them, though, by its own account. It also says its systems "prioritize the fast inclusion of high quality, useful content".7 So zoom out. Quality problems can repeat across the site, not only on one page.
When a batch of similar important pages stays unindexed, hold off publishing more like them until you've compared their templates, purpose and internal links. Skip "low authority" as an explanation and record what you actually found.
Write a ticket you can test
Only turn a finding into a change once you can name the observed problem. The priorities below are my recommendations for important public pages, not confirmed causes for every URL in the report.
| Observed pattern | Priority | Change | How to check it |
|---|---|---|---|
| Missing answer or original information | High | Add missing information or an example that helps users complete the task | Review the revised page, then inspect it again |
| No useful internal path | High | Add relevant contextual links | Confirm the links are live, then inspect the page again |
| Main content missing from the rendered page | High | Fix resource blocking and JavaScript delivery | Retest rendering, then check the indexed result later |
| Overlapping pages or conflicting canonical signals | Depends on the version you want | Differentiate or consolidate | Inspect the preferred URL and Google's canonical choice |
| Important redirect destination still unindexed | High | Strengthen the destination's signals and add it to a focused sitemap | Filter by that sitemap and inspect the destination |
| URL that should be private | High, for access control | Add protection and remove public discovery paths | Check protection separately from indexing status |
| Utility URL with no search landing role | Low | Record the decision to leave it | Track the important-page group instead of the total count |
Copy this ticket and fill in the blanks with evidence:
Affected URL: https://example.com/guide/
Intended outcome: indexed as the preferred public page
Search Console sitemap filter:
Indexed-result reason and last crawl:
Declared canonical / Google-selected canonical:
Indexed comparison URL:
Observed gap (not assumed cause):
Proposed content, link, canonical, or rendering change:
Owner:
Change date:
Current-page verification:
Later indexed-result verification:
Outcome / next action:
Timelines, according to Google
Changed something substantive? A single page gets a recrawl request; a whole group gets fix validation. Neither one guarantees indexing. And if the page hasn't changed, Google says don't bother resubmitting.
Request indexing after substantive improvements
Once you've made substantive improvements, request re-indexing via the URL Inspection Tool → "Request Indexing."7 Recrawl requests are for individual URLs, have a quota, and don't guarantee indexing.2 Requesting the same URL again and again won't get it crawled any faster.
Google's tip for a group of important pages: put only those pages in a sitemap, filter the Page indexing report by it, and click Validate fix. Validating a subset can finish sooner than validating every affected URL on the site. Without the filter, validation covers every instance of the issue on the site, and it stops when Google finds a single remaining instance.1
Validation is optional. Google updates the instance count whenever it crawls a page with a known issue, whether or not you requested validation.1
Crawling, validation and quality reassessment run on different clocks
| Process | Google's documented timing | What it doesn't promise |
|---|---|---|
| Crawling after a recrawl request | A few days to a few weeks | That the page gets indexed |
| Page indexing fix validation | Typically up to about two weeks, sometimes much longer | A date when a given page will be indexed |
| Recognizing broader helpful-content improvements | Some changes take effect in a few days; for the site as a whole, it could take several months | A fixed recovery deadline for this status |
These are separate processes, not a recovery schedule. Record the change date and check the indexed result later before you decide a revision failed. Use this checklist for the page group you changed:
[ ] Current page contains the intended content and change.
[ ] Relevant internal links point to the intended URL.
[ ] Canonical declaration and sitemap inclusion match the chosen version.
[ ] Current-page rendering concern has been retested where relevant.
[ ] Later indexed result has been reviewed after the change.
[ ] Important-page outcomes are tracked separately from utility URL counts.
[ ] Unresolved examples have a recorded hypothesis and next action.
Judge success by whether your important pages get indexed as the preferred version. A report at zero isn't the goal. Google doesn't guarantee that it will crawl, index or serve any page.3 Still stuck in crawled - currently not indexed after a real change? Back to the worksheet, then, with a new hypothesis.
Frequently asked questions
How do I fix crawled but not indexed pages?
Read the indexed result in URL Inspection first. After that, work through content quality, internal links and rendering. Choose a change tied to a gap you observed, such as a missing worked example or a blocked rendering resource. Request indexing after a substantive improvement and check the indexed result again later.
What happens if a page is crawled but not indexed?
Searchers won't find it on Google. It might get indexed later, or it might not; Google doesn't promise either way. So put your effort into the pages you want searchers landing on, and let the rest of the report be.
Is crawling the same as indexing?
No. Crawling and indexing are separate stages, and a visit from Googlebot doesn't guarantee a place in the index. "Crawled - currently not indexed" means the crawl happened. "Discovered - currently not indexed" means Google found the URL but hasn't crawled it yet.
Is a rising crawled - currently not indexed count a problem?
Only if important pages are entering the group. Feeds and paginated pages? Usually fine to leave. Product pages and articles are where it matters. So before changing anything site-wide, open the sitemap filter and URL Inspection and check which pages make up the count.
Why does a URL show up in a site: search while Search Console lists it here?
When that exact URL shows up (same protocol, same trailing slash), Google has it indexed. Inspect it to see Google's current record for the page; Google updates the report's count when it crawls the page again. The reverse proves nothing: an indexed page isn't guaranteed to appear in a site: query.
How long does indexing take after a meaningful change?
There's no guaranteed deadline. After a request, Google says crawling can take anywhere from a few days to a few weeks. Validation usually runs up to about two weeks, and sometimes far longer. Site-wide, a quality reassessment could stretch over several months.
Should I add noindex to clear this status?
Not to a page you want indexed. Once Googlebot sees a noindex (tag or header), the page drops out of Google's results. And Google must be able to crawl it, so robots.txt can't block it. For a private page, deal with access protection and public links instead.
Can crawled - currently not indexed pages hurt the rest of my site?
Not as a penalty you can point to. By Google's account, its ranking systems are built to work at the page level, though site-wide signals and classifiers shape how it reads pages too. When lots of important pages sit in this status together, suspect something they share: a template, the content or the internal links.
Once your important pages make it into the index, the next question is whether they earn traffic. SEO Heatmap visualizes your Search Console clicks page by page, so you can see which fixed pages start pulling their weight. It's free for one Search Console property.
Sources (7)
SEO Heatmap Knowledge relies on primary sources: Google's documentation, web standards, peer-reviewed research, and vendors' own pages for their pricing and features. Our editorial standards
- Google Search Console Help. “Page indexing report.”
- Google Search Console Help. “URL Inspection tool.”
- Google Search Central. “In-depth guide to how Google Search works.”
- Google Search Central. “Creating helpful, reliable, people-first content.”
- Google Search Central. “How to specify a canonical URL with rel="canonical" and other methods.”
- Google Search Console Help. “Crawl Stats report.”
- Google Search Central. “Ask Google to recrawl your URLs.”
