Crawled – Currently Not Indexed: What It Means, When to Fix It

"Crawled - currently not indexed" means Google fetched the page successfully and then decided not to add it to its index, at least for now. It is a decision, not a crawl error, and on most sites it is partly normal. It needs work only when it lands on pages you want people to find in search; for feeds, filter URLs and other low-value addresses, it is the right outcome.

What Google says "Crawled - currently not indexed" means

The status appears in Search Console's Page Indexing report, in the table "Why pages aren't indexed". It carried the same label in the older Index Coverage report, where it sat in the "Excluded" group. Google's Page Indexing report documentation (checked October 2026) describes it plainly: "The page was crawled by Google but not indexed," and it "may or may not be indexed in the future; no need to resubmit this URL for crawling."

The status tells you 2 things: access worked, so robots.txt, server errors and redirects are not the cause, and the decision came after the fetch. Google's documentation on how Search works says indexing is not guaranteed and "depends on the content of the page and its metadata". It names low-quality content and site design that makes indexing difficult among common reasons.

Its neighbor, "Discovered - currently not indexed", means Google knows the URL but has not fetched it yet. Here the fetch is done, and the page itself, or its place in your site, did not earn a spot.

Is "Crawled - currently not indexed" a problem?

Google's own guidance on the report is direct: "Don't expect every URL on your site to be indexed." The useful question is which URLs are in the list.

A practical first cut: in the Page Indexing report, switch the sitemap filter from "All known pages" to "All submitted pages". That view shows only URLs listed in the sitemaps you submitted, your own statement of what should be indexed. Investigate affected URLs in that view first; those outside it usually belong in the "Leave" row.

The causes behind the status

Google does not report a reason for an individual URL in this status, so the causes are found on the site.

URLs that were never meant to rank. Feed URLs, tracking and session parameters, faceted navigation combinations and internal search pages get crawled because something links to them, and rarely offer anything a better page does not. Google's documentation on faceted navigation says crawlers typically fetch a very large number of these URLs before recognizing them as useless.

Thin or near-empty pages. A page that answers with a 200 status but has little to read: an empty category, a placeholder, a profile with no content. If the page looks empty or reads like an error page, Google may report it as "Soft 404" instead; if it has some content but too little to stand on its own, it can land here.

Pages too similar to other pages. Google's documentation describes grouping pages with similar content and choosing the one most representative of the group. Location pages that differ only by city name, product variants with identical descriptions, and articles that cover the same question twice all compete for the same place.

Weak signals of importance. A page that only your sitemap mentions, or that sits deep behind pagination, tells Google little about how much it matters. Internal links are the signal you control most directly; see our internal linking data.

Content that only exists after JavaScript runs. Google renders pages and runs their JavaScript, but if the main text, title or canonical tag appear only after rendering, what Google evaluates depends on that step succeeding.

Newly published pages. "May or may not be indexed in the future" leaves room for a page still being evaluated; a new article here for a short time is not yet a finding.

How often homepages depend on JavaScript for what search engines read first

In 34 external sites where SEOReport compared the server's raw HTML with the rendered homepage (May–October 2026), 7 (21%) depended on JavaScript for something a search engine reads first: either the title, meta description, canonical or H1 appeared only after JavaScript ran, or the raw HTML held almost none of the page's text. In 4 of the 34 (12%), the raw HTML contained 2% or less of the words a visitor sees after rendering.

The JavaScript rendering guide covers moving critical content into the server response.

How to confirm which cause applies

Open URL Inspection for one affected URL from each pattern you see and work through the result in this order.

1. Last crawl. Note the date. A fix made after that date has not been seen yet, so judge the page Google actually fetched.
2. "Page fetch" and "Indexing allowed?". Expect "Successful" and "Yes". If indexing is not allowed, the URL has a noindex problem, not this one.
3. "User-declared canonical" and "Google-selected canonical". If a Google-selected canonical is shown and it is a different URL, Google is treating another page as the main version. That is a canonical question, covered in the canonical tags guide.
4. "Test live URL", then "View tested page". The screenshot shows the page as Google rendered it in that test. If the main content is missing from the screenshot, the likely cause is rendering. Google notes that the live test does not check every indexing condition, including whether the page is a duplicate, so a clean live test does not mean the page will be indexed.
5. Compare with your own pages. Put the affected page next to the indexed page closest to it. If you cannot say in one sentence what the affected page offers that the indexed one does not, the cause is thin or duplicate content.

Work in patterns, not single URLs: export the affected list and group it by path. 400 URLs under /tag/ is one decision, not 400.

How to fix each cause

Low-value URL classes. Take them out of the sitemap and leave the status alone. For faceted navigation, Google's documentation recommends blocking filter URLs in robots.txt, or using URL fragments for filters, when those URLs should not appear in search. An example to adapt to your own URL patterns:

User-agent: *
Disallow: /*?*sort=
Disallow: /search/

Thin pages. Add the substance the page promises, or remove it: return 404 or 410, or 301 to a close equivalent.

Near-duplicates. Merge pages that answer the same question into one stronger page and redirect the others to it. Where variants must exist, such as a product in 3 colors, point each variant's canonical tag at the main version:

<link rel="canonical" href="https://example.com/products/linen-shirt/" />

Weak internal linking. Link to the page from where a reader would expect it: its category or hub page, related articles, and navigation where it belongs, with descriptive anchor text.

Rendering. Serve the title, canonical, H1 and main text in the HTML response, through server rendering or pre-rendering, so the page does not depend on a script to say what it is.

The sitemap itself. Google's sitemap documentation says to include the URLs you want to see in search results, and that Google uses lastmod only when it is consistently accurate. List only canonical pages that answer 200 and can be indexed. Sitemaps that advertise the wrong URLs are common: in 29 external sites whose sitemap pages SEOReport fetched between May and October 2026, 8 (28%) had at least one sitemap URL that redirects, is marked noindex, or is blocked by robots.txt. The XML sitemaps guide covers what a clean sitemap contains.

How to verify the fix

After changing the affected pages, open the reason in the Page Indexing report and click "Validate fix". Validation rechecks the URLs listed under the reason and passes only when all known instances are gone. If that list still holds feeds or filter URLs you decided to leave out of the index, expect it to fail. Start it from the "All submitted pages" view instead: Google's documentation says that with a sitemap filter applied, validation covers only the URLs in that sitemap.

Expect days to weeks. Google's documentation says validation typically takes up to about 2 weeks and in some cases much longer. Google also updates the count during regular crawling, whether or not you start validation.

Search Console names the affected URLs, not the pattern on your site that produces them, and checking hundreds of URLs one at a time, by hand or in a single AI chat session, rarely covers the whole set. No tool outside Google can say why Google chose not to index a page. A full SEOReport diagnosis shows the causes on your site that often sit behind it: pages your sitemap lists that answer with almost no text, near-duplicate articles named in pairs, underlinked articles, homepage content that only appears after JavaScript runs, and sitemap entries that redirect or are marked noindex. A later report, or weekly monitoring, shows whether those findings have cleared.

Common questions

Will "Request indexing" fix "Crawled - currently not indexed"?

Not by itself. Google has already crawled the page, and its documentation for this status says there is no need to resubmit the URL. URL Inspection's own help adds that a request "does not guarantee that the page will appear in the Google Index". Change the page first; then requesting indexing for a few key pages, or "Validate fix" for the group, asks Google to look again.

Should I add noindex to pages stuck in this status?

Only to pages you never want in search results. A noindex moves them to "URL marked 'noindex'", which states your intent and keeps the report readable. For pages you do want indexed, noindex is the opposite of a fix.

Does this status mean my site has a penalty?

No. A manual action appears in Search Console's Manual actions report, not in Page Indexing. This status is a per-URL indexing decision, and Google's documentation notes that most sites have at least a few unindexed pages.

Why does a page I want indexed keep returning to this status?

Usually because the change was too small to alter the decision: a few sentences added to a page that still duplicates another, or new text on a page nothing links to. Repeat the comparison with your closest indexed page and count the internal links that point to the affected one.