Independent SEO consultant serving London & the UK+44 7472 849630info@seoconsultantlondon.onlineGoogle Business Profile
  1. Home
  2. Guides
  3. Crawled, Currently Not Indexed: Causes and Fixes
Indexing problems

Crawled, Currently Not Indexed: Causes and Fixes

Crawled, currently not indexed means Google fetched the page but chose not to add it to its index yet. It is a status, not a penalty. The usual causes are low perceived value, duplication, weak internal links or technical signals. Fix the page's quality and links first, then wait; resubmitting does not help.

Quick answer

Crawled, currently not indexed means Google fetched the page but chose not to add it to its index yet. It is a status, not a penalty. The usual causes are low perceived value, duplication, weak internal links or technical signals. Fix the page's quality and links first, then wait; resubmitting does not help.

Key takeaways

  • The status means Google has crawled the URL and has not indexed it, and Google says the page may be indexed later.
  • It is a decision about value and signals, not an error, so the fix is almost always to improve the page or its context, not to resubmit it.
  • Not every URL in this report needs fixing: parameter pages, thin archives and duplicates are often better left out.
  • Check the basics first: noindex tags, canonicals, redirects and soft 404 behaviour, then judge quality, uniqueness and internal links.
  • Discovered, currently not indexed is a different status: Google knows the URL but has not crawled it yet.

What does "Crawled, currently not indexed" actually mean?

Crawled, currently not indexed is one of the statuses that appears in the page indexing report in Google Search Console. It tells you that Googlebot, Google's crawler, has visited the URL and downloaded its content, and that Google has not added the page to its search index. The page therefore cannot appear in search results, at least for now.

Google's Search Console documentation describes the status in a plain way: the page was crawled but not indexed, and it may or may not be indexed in the future. The documentation also says that you do not need to resubmit the URL for crawling. That single sentence removes a lot of wasted effort, because many site owners respond to the status by repeatedly requesting indexing.

Is this an error, a penalty or a decision?

It is closest to a decision. Google evaluated the page after fetching it and, based on what it saw and what it knows about the rest of the web, chose not to include it yet. There is no manual action involved, and no message in the Manual Actions report. The status does not mean the page is broken or that the site is in trouble.

That framing matters because it changes the response. If the status were an error, you would fix a fault. Because it is a decision about value and signals, you improve the evidence that the page deserves a place in the index.

Why "currently" is the important word

The word "currently" signals that the status can change. Pages move from this status into the index without any action, and pages leave the index later. Treat the report as a snapshot of Google's present view, not a permanent verdict.

Where do you see it?

Open Search Console, choose the property, and open Indexing, then Pages. The report splits URLs into indexed and not indexed, and lists reasons for exclusion. Click "Crawled - currently not indexed" to see a sample of affected URLs, and use the URL Inspection tool on any single URL for more detail.

The report shows a sample, not necessarily every affected URL, so for large sites you need to export the data and group it. Sampling is one reason it is easy to misjudge how big the problem is.

What the report does not show

It does not tell you why Google chose not to index a page. You have to infer the reason from the page itself, its links, its duplicates and your site's wider quality. The sections below show how to do that systematically.

How is this different from "Discovered, currently not indexed"?

The two statuses sound alike and are often confused, but they point to different stages of the process. Separating them stops you from applying the wrong fix.

Google's documentation describes the discovered status as a page that was found by Google but not crawled yet, and says Google likely planned to crawl it but delayed the visit to avoid overloading the site. Because no crawl has happened, the report shows no last crawl date.

What does each status tell you?

The table below compares them.

StatusHas Google fetched the page?Main questionTypical response
Discovered, currently not indexedNoWhy has crawling been delayed or deprioritised?Improve discoverability, server health and internal links
Crawled, currently not indexedYesWhy was the content not worth indexing yet?Improve page value, uniqueness and signals

Why the distinction saves time

If a page has never been crawled, rewriting it will not help until Google visits. If a page was crawled and rejected, forcing more crawling will not help. Each status directs effort to a different layer.

Can a page move between the two?

Yes. A page may sit as discovered for a time, then be crawled and move into the crawled-not-indexed status or into the index. Over weeks you may see URLs shift categories, which is normal. Watch the trend rather than a single day's number.

For background on how these stages relate, the distinction between crawling versus indexing is the place to start.

Why does Google crawl a page and then not index it?

Google does not index everything it crawls. The web is vast, and a search index has to choose which pages are worth storing and serving. A page can be technically perfect and still be left out because it adds little that is not already available.

The causes fall into a handful of families. Working through them in order is faster than guessing.

Is the page low in perceived value?

This is the most common cause. Thin pages with little original information, pages that repeat what is on other pages and pages that exist only to hold a keyword often land here. Google's helpful content guidance emphasises content created for people, with substance and originality, and pages that do not meet that bar can be passed over.

Look at the page as a searcher. Does it answer a real question in a way that is better than what already ranks? If not, the status is a reasonable response.

What thin looks like in practice

A service page with two sentences and a form, a location page that swaps one place name into identical text, a tag archive with a list of titles and no commentary, or an auto-generated listing with no unique information.

Is the page a duplicate or near duplicate?

Google tends to index one version of similar content and treat the rest as duplicates. If your page is almost the same as another URL on your site, or on another site, it may be crawled and then excluded in favour of the other version.

Check whether the page has a canonical tag pointing elsewhere, whether parameters create copies, and whether you have several pages targeting the same topic. Google chooses among duplicates using signals such as canonical tags and duplicate URLs.

Why near duplicates are easy to create

Templates, filters, print versions, session identifiers, and trailing slashes all produce multiple URLs for the same content without anyone intending it.

Are the technical signals sending mixed messages?

Conflicting signals confuse Google's choice. A page with a noindex tag, a canonical to a different URL, a redirect, or a soft 404 appearance may be crawled and not indexed because the signals say not to. Sometimes the conflict is accidental, for instance a template that adds noindex to staging and keeps it after launch.

Inspect the live URL, view the rendered HTML and confirm that the indexing directives say what you intend.

What a soft 404 is

A soft 404 is a page that returns a normal success code but looks empty or like an error to Google, such as a search results page with no results. Google may treat it as not found.

Which pages in this report matter and which do not?

Before fixing anything, decide which URLs deserve to be indexed. The report often contains a mix of important pages and URLs that nobody wants in search results, and treating them all alike wastes effort.

A short triage turns a long list into a manageable one.

How do you group the URLs?

Export the list and sort by URL pattern: product or service pages, blog posts, category or tag archives, parameter URLs, paginated pages, internal search results and media attachments. Count how many fall into each group and mark each group as wanted, unwanted or unsure.

This takes an hour and often shows that most of the list belongs to groups you never intended to rank. A spreadsheet with columns for pattern, count, intent and action is enough.

What to do with unwanted groups

If a group should not be indexed, make that explicit: noindex it, canonicalise it to the preferred page, block it from internal links or remove it. Clean signals help Google focus on the pages that matter.

Which important pages deserve attention first?

Prioritise pages that are close to revenue: service pages, key category pages, high-value guides and location pages with real substance. If one of these appears under this status, treat it as a priority, because the page cannot earn traffic until it is indexed.

Check also whether the page was ever indexed. A page that dropped out of the index after a change suggests a different cause from a new page that has never been indexed.

How to check history

Use the URL Inspection tool and Search Console's performance report for the URL. If impressions existed and then stopped, look at what changed on the page and the site at that time.

How do you diagnose a single URL step by step?

A repeatable checklist prevents guesswork. Work through the steps in order and record what you find in your change log.

The sequence below goes from cheapest checks to deeper investigation.

What do you check in the URL Inspection tool?

Paste the URL into the inspection bar. Confirm the crawl date, the Googlebot type, whether indexing is allowed, the user-declared canonical and the Google-selected canonical. Then run a live test to see how the current version renders.

If the Google-selected canonical is a different URL, the page is being treated as a duplicate and the question becomes why. If indexing is not allowed, find the directive that blocks it.

What the rendered HTML tells you

View the rendered HTML to check that the main content, headings and links are present after JavaScript runs. If the content appears only after user interaction, Google may not see it.

What do you check in the page itself?

Read the page as a stranger. Is the purpose clear? Is the content original? Does it match the search intent for its main topic? Is the title distinct from other titles on your site? Is there a clear route to the next step?

Then compare it with the top results for its target query. If the competing pages are richer, more specific or more trustworthy, the status is not a surprise.

How to compare fairly

Look at depth, evidence, structure, freshness, media and authorship. Note what they offer that you do not, and what you can offer that they do not.

What do you check in the site around it?

Count the internal links that point to the page, and check where they come from. A page with one link from a deep archive sends a weak signal about importance. A page linked from the homepage or a key hub sends a strong one.

Check the sitemap too. Include the URL if it is meant to be indexed, and remove it if it is not. Sitemaps should list canonical, indexable URLs only.

Why orphan pages struggle

A page with no internal links relies on the sitemap alone. Google may crawl it and still treat it as unimportant, because nothing on the site points to it.

What fixes work for pages that should be indexed?

Once you know a page deserves to be indexed, improve the evidence. The aim is to make it obvious to Google that the page is unique, useful and an important part of the site.

Fixes fall into content, structure and technical categories, and they often work best in combination.

How do you improve the content?

Add substance that is specific to your business: first-hand experience, real examples, clear pricing information where appropriate, process explanations, answers to the questions customers ask, and original images or data. Remove filler that repeats generic text found elsewhere.

Make sure the page has a single clear purpose and matches the search intent. If it tries to serve several intents at once, split it or choose the one that fits the page.

What to avoid adding

Do not pad the page with extra words to reach a length target. Length is not a ranking factor on its own, and padding makes quality worse.

How do you strengthen internal links?

Link to the page from relevant, well-linked pages using descriptive anchor text. Add it to a hub or category page. Include it in navigation if it is a key service. Remove links that point to competing pages with the same intent.

This does two things: it tells Google the page matters and it helps visitors find it. A practical method starts with website architecture and internal links that give important pages clear routes.

How many links are enough

There is no number. Aim for links from the pages a visitor would naturally come from before needing this one, and make sure at least one of them is a strong page.

How do you fix technical conflicts?

Remove accidental noindex tags, align canonicals with the intended URL, fix redirect chains, make sure the page returns a true 200 status and ensure the content renders without user interaction. Keep only canonical, indexable URLs in the sitemap.

After making changes, request validation in Search Console if the report offers it for the issue type, and then allow time. Repeated manual requests do not speed up a decision based on value.

When to be patient

Google reassesses pages on its own schedule. Improvements to quality and links can take weeks to be reflected, so record the change date and check again after a reasonable period.

When is the status a signal about the whole site?

Sometimes the status is not about individual pages but about the site as a whole. If a large share of new pages are crawled and not indexed, it can reflect how Google judges the site's overall quality and usefulness.

Reading the pattern across the report helps you tell the difference.

What patterns point to a site-wide quality issue?

Warning patterns include a large and growing share of excluded pages, new content that is repeatedly left out, many similar pages produced from a template, and little distinctive content across the site. If most of what you publish looks like what already exists, the index has little reason to take more.

In that case, fixing individual URLs will not be enough. You may need to prune low-value pages, consolidate overlapping ones and raise the standard of what you publish. The decision to refresh, merge or remove content depends on purpose, links and potential.

Why publishing more can make it worse

Adding more thin pages increases the proportion of low-value URLs, which can reinforce the pattern. Quality and focus work better than volume.

What about large sites and crawl resources?

On very large sites, Google allocates crawl resources according to a site's size, health and perceived value. Wasted crawling on parameter URLs, endless filters or duplicates can reduce attention paid to important pages. Reducing waste helps Google spend its visits where they matter.

Most small business sites do not face crawl constraints in this sense, and for them the status is nearly always about page value and signals rather than capacity.

How to reduce crawl waste

Block or consolidate parameter combinations that add no value, fix redirect chains, remove broken links, keep sitemaps clean and make sure the server responds quickly and reliably.

How do you handle special cases?

A few situations produce this status for reasons that are specific to how a site is built. Recognising them avoids long investigations.

Each one has a typical cause and a typical response.

What about new sites and new pages?

A new site has no history, few links and little evidence of value, so Google may crawl pages and wait before indexing them. This is common in the first weeks. Build links to the pages from your own site, earn a few genuine mentions, publish useful content and be patient.

Submitting a sitemap and ensuring the homepage links to key pages helps Google understand the structure. A new site should not expect every page to be indexed at once.

How to help a new site gain trust

Publish a small number of strong pages rather than many weak ones, show real business details, make contact information clear and link pages together in a logical structure.

What about JavaScript-heavy pages?

If content is loaded by JavaScript, Google may crawl the shell and delay rendering. If the rendered page is thin or the content depends on actions Googlebot does not perform, the page can appear empty and be left out.

Test with the rendered HTML in URL Inspection. If content is missing, consider server-side rendering or pre-rendering for important pages. Testing JavaScript SEO and rendering shows whether Google sees the main content, and server-side rendering is the usual remedy.

What to look for in the render

The main heading, the body text, the links to other pages and any structured data. If any are missing, search engines may not see them.

What about pages behind forms, filters or logins?

Pages that appear only after user actions, such as filtered product views, internal search results or gated content, are often not intended for the index. Crawled and not indexed is a reasonable outcome. Decide whether the content should be public, and if so, give it a stable URL, unique content and normal links.

If it should not be public, protect it properly. A login or noindex directive is clearer than relying on Google to skip it.

How to treat faceted URLs

Allow indexing only for filter combinations that match real search demand and carry unique content. Canonicalise or block the rest.

How do you monitor the report over time?

A single export tells you where you stand today. Monitoring shows whether your actions are working and catches problems early. The effort is small once it is set up.

Plan a regular rhythm and keep a record, so that changes in the report can be matched to changes on the site.

What should you track?

Record the number of URLs under the status by group, the number of indexed pages, the number of important pages affected and the date of each site change. Compare month by month, and annotate large changes such as a redesign, a new template or a plugin update.

A simple spreadsheet or dashboard is enough. The goal is to see direction: is the share of wanted pages that are indexed rising, falling or steady?

Which numbers can mislead

The raw count of excluded URLs can rise when you add pages or fix a crawl trap that exposes more URLs. Judge progress by the status of the pages you want indexed, not by the total.

When should you escalate?

Escalate if important pages remain unindexed after meaningful improvements and a reasonable wait, if indexed pages are dropping out, or if the pattern grows. Review for site-wide quality, technical regressions and recent changes. Consider an independent technical review if the cause is unclear.

Stubborn cases often benefit from a technical SEO consultant who covers crawling, indexing and rendering, and a broader SEO audit can reveal whether the issue is page-level or site-wide.

A short action plan to finish

Export the list, group by type, decide what should be indexed, fix signal conflicts, improve content and links for the important pages, tidy sitemaps and noindex rules for the rest, then recheck after a few weeks.

Which mistakes make the problem worse?

Responses to this status are often more harmful than the status itself. The mistakes below come up repeatedly, and avoiding them saves weeks of effort and protects the pages that are already working.

Each one comes from treating a decision about value as if it were a fault in the plumbing.

Why does repeated indexing requesting backfire?

Requesting indexing again and again feels productive, and it creates a record of activity. Google's documentation states that resubmitting is not needed for this status, and the request tool has limits. Repeating it does not alter a judgement based on quality and signals, and it uses time that could go into improving the page.

Use the request tool after a real improvement, such as a substantial rewrite or the removal of an accidental noindex tag. Do it once, note the date and wait.

What to do instead

Improve the page, strengthen the links to it, confirm the technical signals and let Google return in its own time. Measure the result in the page indexing report over several weeks.

Why is deleting everything a poor reflex?

Some owners respond by deleting every URL on the list. That can remove pages that have a purpose, such as contact pages, legal pages or useful archives, and can create broken links and lost equity. Deletion is the right choice only for pages with no value to users and no inbound links.

For other pages, consolidation is safer: merge overlapping pages into one stronger page and redirect the old URLs with a 301 redirect. Merging pages cleanly relies on 301 redirects and redirect mapping so that signals follow the content.

How to decide between merge, improve and remove

Improve if the page has a clear purpose and potential. Merge if several pages share one intent. Remove if the page has no users, no links and no purpose.

Why is blocking in robots.txt the wrong fix?

Blocking a URL in robots.txt stops Google crawling it, but it does not remove it from the index if it is already known, and it prevents Google from seeing a noindex tag on the page. For pages you want out of the index, allow crawling and use noindex, or remove the page properly.

Using robots.txt to hide content you do not want indexed often produces a different status, such as indexed though blocked, which is harder to manage. Choose the right tool for the outcome you want.

Which tool does which job

Robots.txt controls crawling. Noindex controls indexing. Canonical tags suggest a preferred version among duplicates. Redirects move users and signals to a new URL.

How does the fix differ across common platforms?

The principles are the same on every platform, but the places where problems hide differ. Knowing the typical sources of low-value URLs on your platform speeds up the clean-up.

The notes below are general patterns, not guarantees, and settings change between versions, so always verify on your own site.

What should you look for on WordPress?

WordPress creates many archive URLs by default: tag pages, category pages, author pages, date archives, attachment pages and paginated lists. If these are thin or duplicate your main content, they often show up under this status. Review which archives are useful, and noindex or consolidate the rest using your SEO plugin's settings.

Check also for plugins that generate extra URLs, staging copies that were left indexable and theme templates that output duplicate content. A crawl will show patterns that are hard to spot by hand.

What to check in the plugin settings

Look at the settings for taxonomies, archives, attachments, and the XML sitemap, and confirm that only pages you want indexed appear in the sitemap.

What should you look for on Shopify and other shops?

Online shops commonly create several URLs for one product, for example through collection paths, variants and filters. Canonical tags usually point to the main product URL, and Google may crawl the alternatives and exclude them. This is often expected and does not need fixing.

Concern yourself with product and collection pages that are genuinely unique but unindexed, and check that they have unique descriptions, internal links and accurate structured data. Store-specific settings are covered in a Shopify SEO checklist.

Why variant URLs are usually not a problem

If the canonical points to the main URL and the main URL is indexed, excluded variants are working as designed.

What should you look for on custom or JavaScript sites?

Custom builds can introduce unusual patterns: URLs generated by routing rules, content that depends on client-side rendering, and parameters that create endless combinations. Review the router, the rendering approach and the way internal links are produced, since links created only by scripts may not be followed reliably.

Work with developers to produce a list of URL patterns the site can generate, then decide which should be indexable. It is far easier to design this up front than to clean it up afterwards.

How to make the conversation with developers easier

Bring examples from Search Console, a sketch of the intended URL structure and a clear request: which patterns should be indexable, which should not and how each will be signalled.

Frequently asked questions

Is Crawled, currently not indexed a penalty?

No. It is a status in the Search Console page indexing report meaning Google fetched the page and has not added it to the index. It is not a manual action. It can reflect page quality, duplication or weak signals, and pages sometimes move into the index later without any change.

How long does it take for these pages to get indexed?

There is no fixed time. Google says such pages may be indexed later, and improving the page or its internal links can speed this up. Expect days to weeks for well-linked, useful pages, and longer or never for pages that add little beyond what is already indexed.

Should I keep requesting indexing in the URL Inspection tool?

No. Google's documentation says that resubmitting a page for crawling is not needed for this status. Repeated requests do not change a decision based on page value. Improve the content, strengthen internal links and fix technical conflicts, then let Google reassess on its own schedule.

Do I need to fix every URL listed under this status?

No. Many listed URLs are low-value by design, such as filtered pages, tag archives, tracking-parameter variants or thin pages. Group the URLs by type, decide which should rank, and focus on those. For the rest, leaving them unindexed or tidying them with canonicals and noindex is fine.

What is the difference from Discovered, currently not indexed?

Discovered means Google knows the URL exists but has not crawled it yet, often to avoid overloading the server. Crawled means Google has fetched the page and decided not to index it for now. The first is mostly about crawl scheduling, the second mostly about page value.

Related pages

Want an expert to look at your site?

Send your website and goals. You will get a clear next step, not a generic sales pitch.

Book a free consultation
Get a quoteEmail us