What Does “Crawled – Currently Not Indexed” Mean in Search Console, and How Do You Fix It?

The “Crawled – currently not indexed” status means Google has visited your page and seen its content, but has not added it to the search index at the moment. It is not an error or a penalty; most often it suggests that the page did not look valuable, original or high-priority enough to Google. The fix usually lies in strengthening content and site signals.

Many site owners who open the “Page indexing” report in Search Console for the first time panic at the long list headed “Not indexed”. Yet most of that list is normal: redirects, duplicate URLs and pages you deliberately set to noindex should be there. What matters is being able to tell why pages you do want indexed are not. This article unpacks each status, the diagnosis steps and when you should wait.

What exactly does “Crawled – currently not indexed” mean?

This status says Googlebot crawled the URL successfully but decided not to add the page to the index. The page is reachable, but Google may not currently find its content worth indexing. The status can change over time: the page may be indexed later or stay on this list for a long while.

Google is clear that it does not promise to index every page; indexing depends on many signals such as content quality, originality, the overall state of the site and the benefit the page brings to the web. So “crawled but not indexed” is most often not a technical failure but a value judgement.

• —Crawled: Googlebot reached the page and read the content.
• —Currently not indexed: the page is not eligible to appear in search results right now.
• —Not permanent: the status can change over time, but if waiting does not change it, you need to act.
• —Not a penalty: different from a manual action or spam penalty, which shows up in a separate report.

Which “not indexed” statuses exist in the Page indexing report?

The Page indexing report groups non-indexed URLs by reason: crawled but not indexed, discovered but not crawled, alternate page, duplicate page, soft 404, noindex, robots.txt block, redirect and 404, among others. Each group means something different and calls for a different response, so first read correctly which group you are in.

• —Crawled – currently not indexed: the page was read but not added; mostly a matter of value and originality.
• —Discovered – currently not indexed: Google knows the URL but has not crawled it yet; a matter of crawl priority and site resources.
• —Alternate page with proper canonical tag: the page deliberately points to another URL; mostly normal.
• —Duplicate page: Google chose another URL as canonical, or there is no user-selected canonical.
• —Soft 404: the page returns 200 but looks empty or like a “not found” page.
• —Excluded by ‘noindex’ tag: the page has been deliberately kept out of the index.
• —Blocked by robots.txt: Google is not allowed to crawl the page.
• —Page with redirect and Not found (404): the URL now goes elsewhere or no longer exists.

A large number in the report is not a problem in itself. Most excluded URLs may be addresses that should not be indexed anyway. What to watch for is seeing your important service, product or blog pages on the list.

What causes pages to be crawled but not indexed?

The most common causes are weak content or content very similar to other pages, poor internal linking to the page, low overall site quality signals and a new site that has not yet earned trust. Sometimes a technical issue, such as content loading late through JavaScript, makes the page look empty.

• —Thin or weak content: short, superficial pages made up of a few sentences.
• —Duplicate or very similar content: the same text repeated with the city or product name swapped.
• —Weak internal linking: almost no links to the page from the menu or other pages.
• —Low overall site quality: if most pages on a site offer no original value, new pages may also be picked up late.
• —A new site or new page: there may be a waiting period until trust and crawl patterns settle.
• —Technical problems: content that only appears in the browser, slow loading, a soft-404-like appearance.
• —Too many low-value URLs: tag, filter and archive pages can dilute attention.

An important note here: if there are already many strong pages on the same topic, Google may judge that nothing is missing for a new page. A new page must not merely repeat the topic; it needs to add something, such as experience, examples, local knowledge or current data.

How does “Discovered – currently not indexed” differ from this?

With “Discovered”, Google knows the URL exists (for example through a sitemap or a link) but has not crawled the page yet. With “Crawled”, the page was read but not indexed. The first is mostly about crawl priority and timing, the second about content assessment.

Discovered-but-not-crawled pages on small sites usually resolve with time. If many pages stay in that state, server slowness, the site generating too many low-value URLs or general quality signals may be responsible. On large sites the crawl budget topic comes into play; we cover it in a separate article.

• —Discovered, not crawled: first check server speed, internal links and the accuracy of the sitemap.
• —Crawled, not indexed: first look at the value, originality and internal linking of the content.
• —In both: making the page more valuable and supporting it with internal links is the most lasting fix.

When do “alternate page” and duplicate statuses become a problem?

“Alternate page with proper canonical tag” is generally normal: the page points to another URL with its own canonical tag and Google respects that choice. The problem is when this status appears on a page you want indexed; it can indicate the canonical points to the wrong place.

With “duplicate” statuses, Google found the content the same or very similar to another URL and chose one as canonical. Remember that Google treats the canonical tag as a hint, not an absolute command. If the page you chose is not being indexed and Google picks another URL as canonical, you need to question whether the two pages really offer separate value.

• —Expected: a parameter, filter or http/www copy URL is listed as an alternate page.
• —Problem: your service or product page mistakenly gives a canonical to another page.
• —Problem: two similar pages compete for the same query and Google has picked one.
• —Fix: verify the canonical, merge duplicate pages or give each a different, original purpose.

What is a soft 404 and how is it fixed?

A soft 404 is when a page returns an HTTP 200 (success) status code but Google treats it as an error page because its content is empty, very short or looks like “not found”. These pages are not indexed. The fix is to add content to a page that should exist, or to give the correct 404/410 code to one that does not.

Soft 404s appear mostly in two places: pages whose content loads through JavaScript and looks empty at crawl time, and e-commerce pages that show almost no content when a product is out of stock or a category is empty. Deleted pages sent to the homepage via redirect chains are also sometimes read as soft 404s.

• —If the page should exist: add meaningful content and make sure the main content is in the initial HTML.
• —If the page no longer exists: return a 404 or 410 status, or 301-redirect to a genuinely relevant page.
• —If a product is out of stock: keep showing product information, alternatives and related products.
• —Avoid redirecting every deleted page to the homepage; this can be a soft 404 signal.

How do you read noindex and robots.txt block statuses?

“Excluded by ‘noindex’ tag” says the page itself asks not to be indexed; you need to check whether that is intentional. “Blocked by robots.txt” shows Google cannot reach the page at all. Both are sometimes found on live pages by mistake, for example because of settings left over from development.

A critical distinction here: on a page blocked by robots.txt, Google can never read a noindex tag, because the page is not crawled. If you want to remove a page from the index, use noindex rather than blocking it in robots.txt, and keep the page crawlable. Conversely, after removing a noindex tag from a page you want indexed, you must wait for Google to recrawl it.

• —Intentional noindex: thank-you pages, internal search results, test pages — normal.
• —Accidental noindex: a leftover “discourage search engines” setting on a newly launched site, or theme and plugin settings.
• —Accidental robots.txt block: a “Disallow: /” line put in during development and left on the live site.
• —Check: inspect the robots meta tag in the page's HTML source and the X-Robots-Tag header.

For more on the robots.txt file, see our guide, where we cover decisions about which bots to allow or block.

How do you diagnose step by step with the URL Inspection tool?

The URL Inspection tool shows how Google sees a single page: whether it is in the index, which canonical it chose, the last crawl date and how the page appeared during crawling. It is the most reliable first step for diagnosis and often shows clearly where the problem lies.

• —Step 1: Enter the page's full URL in the search box at the top of Search Console.
• —Step 2: Read the “URL is on Google” result: is it indexed, in what state, was it discovered through the sitemap?
• —Step 3: Are the “User-declared canonical” and “Google-selected canonical” the same?
• —Step 4: Look at the last crawl date and whether the crawl was successful.
• —Step 5: Use “Test live URL” to see the page's current state through Google's eyes.
• —Step 6: In the rendered HTML and screenshot of the live test, confirm the main content appears.
• —Step 7: If there is no barrier and content is complete, assume the issue is about content value and internal linking.

If content looks missing in the live test, the problem may be rendering rather than page value. In that case make sure the main content is in the server-generated HTML. Prerendered pages like those on our own site are advantageous in this respect, but do not assume the same result on every infrastructure.

How do you fix a page that is crawled but not indexed?

First decide whether the page is genuinely worth indexing. If it is, deepen the content, add original examples and information, give it meaningful internal links from the site and resolve overlap with duplicate pages. If it is not, merging, noindexing or deleting it may be the better choice.

• —Strengthen the content: enrich superficial text with original examples, steps, comparisons and current information.
• —Make sure it meets search intent: is the page the type the target query expects?
• —Increase internal links: link from relevant strong pages, in natural context with descriptive anchor text.
• —Weed out duplicates: merge very similar pages or give each a separate purpose.
• —Put only valuable, canonical pages in the sitemap.
• —Remove technical barriers: speed, rendering, redirect chains and soft 404s.
• —Remove the page if needed: if it serves no purpose, give a clean exit with 404/410 or a 301.

After these steps, results may not appear immediately. It takes Google days, sometimes weeks, to reassess the page. Pressing the “request indexing” button for the same page over and over does not speed things up.

When should you wait and when should you act?

Waiting days or even a few weeks is normal for a newly published page; indexing takes time, especially on new sites. If the page stays in the same state for a long time, many important pages are affected or you have found a barrier (noindex, robots, canonical error), you should act rather than wait.

• —Can wait: pages published a few days or weeks ago, with no technical barrier and with internal links.
• —Can wait: the period when the site is new overall and crawl patterns are settling.
• —Act: if noindex, a robots.txt block, a wrong canonical or a 404/soft 404 is found.
• —Act: if your important service and money pages have not been indexed for months.
• —Act: if many pages share the same status; this is usually a site-level quality or structure issue.

After fixing a problem, you can use the “Validate fix” option on the relevant status in the report. Validation can take days; be patient and monitor the process regularly.

Does the “Request indexing” button really work?

The “Request indexing” button sends a request for Google to recrawl a URL, but does not guarantee the page will be indexed. It is useful for a few newly published or substantially updated pages; if the reason a page is not indexed is content value, the button does not solve the problem.

Using the button repeatedly and sending bulk requests is inefficient; there is also a daily quota. A more effective route is to fix the issue at its source and keep natural discovery paths such as the sitemap and internal links solid. Using the indexing request once, after fixing the problem, is enough.

Indexing problem checklist and common mistakes

The most common mistakes with indexing problems are assuming a general penalty without reading the report in detail, trying to index every page, relying only on the “request indexing” button and never questioning content quality. The checklist below offers a systematic approach.

• —Read the status fully: separate crawled, discovered, alternate, duplicate, soft 404, noindex and robots statuses.
• —Decide which pages should be indexed; deliberately leave unnecessary URLs out.
• —Run a live test with URL Inspection and verify the canonical and render result.
• —Check noindex, robots.txt and X-Robots-Tag settings.
• —Question content value: is it original, deep and matched to intent?
• —Tidy internal links and the sitemap; merge duplicate and similar pages.
• —Wait after changes and follow up with “Validate fix”.
• —Cleanly remove or redirect pages with no lasting value.

When many pages share the same status, it usually carries a site-level message: content that is generally superficial, too many duplicate pages or a scattered site architecture. In such cases, reviewing the content strategy and site structure together gives more lasting results than fixing pages one by one.

In technical audits at 404 Ajans, we first lay out the indexing report as a table and classify each status as “normal”, “monitor” or “action needed”. This simple split makes it easier to see which problem genuinely affects traffic.