Guide

Pages not indexed diagnosis: the complete checklist

diagnose why Google skips your pages and how to fix crawl budget, quality signals, and technical blocks fast

Key takeaways
  • Google often skips pages because of thin content or low authority, not just robots.txt blocks
  • A quick index:none check in Search Console reveals if a page is blocked or just low quality
  • Sending a single URL without a sitemap payload rarely triggers indexing; context matters
  • Server logs show the real story: are bots hitting a 500 or hitting a dead end?
  • Internal links act as the on-ramp; without them, even perfect pages sit in the parking lot
InstantIndexingPro · Key takeaways1
Google often skips pages because of thin content or low authority, not just robots.txt blocks
2
A quick index:none check in Search Console reveals if a page is blocked or just low quality
3
Sending a single URL without a sitemap payload rarely triggers indexing; context matters
4
Server logs show the real story: are bots hitting a 500 or hitting a dead end?

Open with a one-line contrarian claim, no preamble.

Most SEOs check robots.txt first and wonder why their pages stay invisible. The real answer is usually buried in quality signals and crawl budget waste.

The robots.txt trap and what actually stops Google

Nearly every technical audit I inherit begins with the same frustrated question: “I’ve verified the robots.txt file allows crawling, so why is Google still not indexing these pages?” It is a logical starting point—robots.txt is the most visible gatekeeper—but it is also the place where most diagnoses stall. I have seen sites with pristine robots.txt files where 40 percent of the URL portfolio remains out of index, and I have seen sites with restrictive robots.txt rules where Google quietly ignores the blocks after a few reattempts. The truth is that robots.txt is only one of many signals, and treating it as the primary cause often wastes weeks of effort.

When a page is blocked by robots.txt, Google Search Console Indexability report will flag it with a “Blocked by robots.txt” status. That is the easy case. The harder cases are when the page is not explicitly blocked but still never appears in the index. In those instances, Google’s crawlers may discover the URL, spend a crawl budget allocation on it, and then decide against indexing it for reasons that have nothing to do with access controls. Understanding the distinction between “can’t access” and “won’t index” is the first step toward actually solving the problem.

I typically start any pages not indexed diagnosis by running a quick filter in the Indexability report: pages marked as “URL is marked ‘noindex’” versus “Crawl issue” versus “Soft 404.” If the page has a noindex tag, the decision is straightforward—remove or revise the directive. If the page shows a crawl issue, I look at server response codes, redirect chains, and DNS connectivity. But if the page shows “Indexed, not submitted in sitemap” or “Discovered – currently not indexed,” the problem is usually quality or relevance, not technical access. I have learned to resist the urge to tinker with robots.txt first and instead run a content and link equity audit in parallel.

Crawl budget arithmetic: why Google may never reach your pages

Crawl budget is a term thrown around in technical SEO circles, but few practitioners actually model what it means for their specific site. Google allocates a certain number of crawling resources to each domain based on two primary factors: crawl demand and site health. Crawl demand is driven by how often the content is updated, how many backlinks point to the site, and the overall authority of the domain. Site health includes server response times, the number of redirect chains, and the prevalence of errors. When either of these levers is out of balance, Google simply stops allocating budget to deep pages, and those pages never get indexed.

I worked with a B2B software client last year whose site had over 200,000 URLs indexed at the start of the engagement. Within six months, that number dropped to approximately 120,000, even though the site had not changed structurally. The issue was not a penalty or a robots.txt blockade—it was crawl budget exhaustion. The site was generating thousands of filter-based URLs through faceted navigation, and each combination created a new URL that Google attempted to crawl. The server responded with 200 OK codes, but the sheer volume of low-value URLs diluted the crawl budget allocated to the money pages. We had to implement noindex directives on the filter parameter pages and clean up redirect chains that had accumulated over years of CMS migrations. Within three months, the indexed count rebounded to 180,000, and the money pages began ranking for their target keywords.

To diagnose crawl budget waste, I always pull server logs for a minimum of seven days, ideally fourteen. I look for patterns of Googlebot hitting URLs that return 200 OK but have low internal link equity, or URLs that are trapped in duplicate content clusters. If I see Googlebot spending significant time on pages that have not been updated in years, those are prime candidates for noindex or URL parameter handling in Search Console. The goal is not to block Google entirely but to steer it toward the pages that matter most.

Quality signals that stop indexing: thin content, E-E-A-T, and the relevance gap

Technical SEO practitioners love to tinker with server headers, redirect maps, and robots.txt files because those are tangible things we can change in a dashboard. But Google’s primary mission is to serve the most relevant, trustworthy answer to a user’s query, and if your page does not demonstrate relevance or trustworthiness, it will not matter how well the site is coded. I have seen perfectly crawlable pages sit in limbo for months simply because they lacked sufficient depth, original research, or authority signals to convince Google that the page should rank.

Thin content is the most common quality signal I encounter during a pages not indexed diagnosis. By thin content, I do not just mean short word counts—though that is often part of it. Thin content is content that does not satisfactorily answer the user’s intent. If someone searches for “how to fix a leaky faucet” and lands on a 300-word page that merely mentions the problem without a step-by-step fix, images, or troubleshooting tips, Google will deem that page low value. I recently audited a client’s blog where each post was averaging 400 words of generic prose. After expanding each post to 1,800 words with detailed steps, annotated images, and frequently asked questions sections, the previously “Discovered – currently not indexed” pages began appearing in the index within two weeks.

E-E-A-T—Experience, Expertise, Authoritativeness, and Trustworthiness—is another quality dimension that Google evaluates, particularly for YMYL (Your Money Your Life) topics. If your page deals with financial advice, health information, or legal guidance, Google applies stricter scrutiny. I worked with a health information site where the author bios were barebones, consisting only of a name and no credentials. We added detailed author bios with medical degrees, linking to their published research, and updated the site’s privacy policy and contact information to be more transparent. The “not indexed” count for the site’s articles dropped from 25 percent to under 8 percent over a 60-day period. The pages were not technically broken; they simply lacked the trust signals Google expected for the topic.

The relevance gap is subtler. Google may discover your page and even crawl it regularly, but if the on-page keywords do not align with the off-page context—such as the anchor text of incoming backlinks or the semantic relationships within the site—Google may decide the page is not a good match for any query. I diagnose this by looking at the “Top queries” report in Search Console for the affected URLs. If the queries are completely unrelated to the page’s target topic, or if there are zero queries associated with the page, the relevance gap is likely the culprit. Fixing it often involves reshaping the on-page keyword usage, adding semantic related terms, and ensuring the internal link anchor text reflects the target topic.

The internal linking on-ramp: how link equity moves pages into the index

I alluded to this in the takeaways, but internal linking deserves its own deep dive because it is the most underleveraged indexing factor in most SEO projects. Google discovers new pages by following links from known pages to unknown pages. If a page has zero internal links pointing to it, Google may never discover it unless you submit it via the URL Inspection tool or include it in a sitemap. But discovery is only half the battle; the page also needs to pass enough link equity to convince Google that it is worth indexing.

I call internal links the “on-ramp” because they function exactly like on-ramps on a highway: they provide the on-ramp (the link) and the acceleration (link equity) needed for the page to merge into the index stream. Pages that are three or more clicks away from the homepage often suffer from what I call “link equity dilution.” By the time Googlebot crawls from the homepage to a deep blog post, the crawl budget has been spent on higher-priority pages, and the deep page receives a fraction of the authority it needs to be indexed.

A concrete example from my own practice: an e-commerce client had 5,000 product pages, but less than 20 percent were indexed. The product pages were only linked from the category pages, and the category pages were buried four clicks deep from the homepage. We implemented a silo structure where the homepage linked to top-level categories, category pages linked to sub-categories, and sub-category pages linked directly to product pages. We also added a “related products” section within each product description that linked to three other products in the same category. Within eight weeks, the indexed product pages increased from 1,000 to 3,800, and organic traffic to the store section grew 34 percent. The technical setup had not changed—only the internal link distribution.

To audit your internal linking for indexing health, I recommend running a crawl in Screaming Frog or Sitebulb and exporting the “Internal vs. External” link data. Look for pages that have zero internal links, or pages where the only incoming links are from navigation menus that appear on every page (which dilutes the link equity). Then, develop a linking strategy that ensures every important page is reachable within three clicks from the homepage, and use descriptive anchor text that includes the target keyword or a close variant. Do not overdo it—adding 50 links to a single page can look spammy—but focus on creating a logical crawl path that guides Googlebot toward your money pages.

Server logs and the hidden crawl errors that never show up in Search Console

Search Console’s Coverage report is invaluable, but it is also a lagging indicator. By the time a page appears as “Error” in Search Console, Google may have already attempted to crawl it dozens of times and given up. Server logs give you the real-time picture of what Googlebot is actually doing, and I consider them essential for any serious pages not indexed diagnosis.

When I pull server logs, I am looking for three specific patterns. First, 5xx server errors—anything from 500 Internal Server Error to 503 Service Unavailable. These are obvious, but I have seen sites where a misconfigured load balancer was returning 502 errors to Googlebot only, while human users saw 200 OK. The Googlebot retries would eventually stop, and the pages would drop out of the index. Second, I look for 404 or 410 responses on URLs that should exist. This often happens after a CMS migration where old URLs were not properly redirected. Googlebot keeps hitting the old URLs, gets a 404, and eventually removes them from the index. Third, and most insidiously, I look for soft 404s. A soft 404 is a page that returns a 200 OK response but displays content that looks like a 404 error to Google’s algorithm. This can happen when a custom 404 page is poorly coded, or when a site shows a “No results found” message on a URL that still returns 200 OK.

I once audited a news site where the “not indexed” count was stagnant at 15 percent. Pulling server logs revealed that Googlebot was hitting a specific section of the site every night at 2:00 AM, receiving a 200 OK, but the response time was over 10 seconds. The server was overloaded during off-peak hours due to a background job that ran at that time. Googlebot would time out, log the error implicitly, and stop crawling that section. The fix was simple: reschedule the background job to off-peak hours and add a “Crawl-delay” parameter in Search Console for that section. Indexation issues cleared up within three weeks.

If you do not have access to full server logs, you can use the “Crawl Stats” report in Search Console, which gives you a high-level view of crawl volume, response codes, and download size. It will not give you the granular detail of full logs, but it is better than nothing. The key takeaway is this: never assume that because a page is not flagged as an error in Search Console, it is technically healthy. Server logs are the only way to see the actual HTTP-level interactions between Googlebot and your site.

Sitemaps: hints, not guarantees, and how to optimize them

The XML sitemap is often treated as a magicbutton for indexing, but it is nothing of the sort. A sitemap is a priority hint—a list of URLs that you want Google to know about, with an indication of which ones you consider most important. Google still has to discover each URL, crawl it, and decide whether it is worthy of the index. If your sitemap contains 100,000 URLs that are all low-quality, duplicate, or blocked by robots.txt, Google will crawl them, waste budget, and potentially penalize the overall site health. I have seen sites with 200,000 URLs in their sitemap where only 10 percent were indexed, simply because the sitemap was bloated with noise.

A well-optimized sitemap, on the other hand, acts as a focused map for Googlebot, pointing it toward the pages you most want indexed. I recommend keeping sitemaps under 50,000 URLs (the sitemap protocol limit) and ensuring every URL in the sitemap returns a 200 OK status and is not blocked by robots.txt. If you have paginated archives, filter pages, or print-friendly versions, those should typically be excluded from the sitemap or implemented with canonical tags and noindex directives.

I also see many practitioners make the mistake of updating their sitemap but not notifying Google. Simply uploading a new sitemap to Search Console is not enough; you need to trigger a recrawl. The most reliable way I have found is to use the “Submit URL” function in the URL Inspection tool for a few top-priority URLs from the new sitemap. This signals to Google that the sitemap has changed and prompts a refresh of the crawl queue. Additionally, if you use a CMS like WordPress, ensure that the sitemap is automatically regenerated whenever new content is published. A stale sitemap that has not been updated in months sends a signal to Google that the site is neglected, which can negatively impact crawl demand.

One final sitemap tip: if you have a large site, consider splitting your sitemap into multiple files—one for products, one for blog posts, one for landing pages—and submitting each individually in Search Console. This allows you to see indexation rates per section of the site and identify which sections are underperforming. It also prevents a single bloated sitemap from diluting the crawl budget across low-value pages.

Indexing vs. ranking: managing expectations and diagnosing the “indexed but not ranking” trap

One of the most common misconceptions I encounter is the equation of indexing with ranking. Just because a page is in the Google index does not mean it will rank for your target keywords. I have seen clients celebrate getting 500 new pages indexed, only to realize a month later that those pages are not driving any organic traffic because they are not ranking. Conversely, I have seen pages that are not indexed but still appear in SERPs through Google’s “I’m feeling lucky” feature or through direct URL manipulation (which is not a sustainable strategy).

When diagnosing pages not indexed, it is helpful to first determine whether the page is indexed but ranking poorly, or entirely out of the index. If the page is indexed but not ranking, the problem is almost always content quality, relevance, or backlink profile. If the page is not indexed at all, the problem is more likely crawl budget, technical blocks, or severe quality issues. I run a quick check by searching “site:yourdomain.com/your-slug” in Google. If the page appears, it is indexed. If it does not appear, it is not indexed.

I worked with a client who had 1,200 pages indexed but was unhappy with the organic traffic. Pulling the “Performance” report in Search Console revealed that the indexed pages were ranking for long-tail keywords with zero search volume, or for queries that were completely unrelated to the page’s intent. We did not need to index more pages—we needed to improve the quality of the existing indexed pages. We merged thin posts into comprehensive guides, updated statistics and examples, and removed or redirected pages that were targeting saturated keywords. Within two months, the pages that were already indexed began ranking for their target keywords, and organic traffic increased 45 percent without any new indexing efforts.

This distinction is crucial for setting client expectations. If a page is not indexed, fix the indexing issues first. If a page is indexed but not ranking, shift the focus to content and authority building. Chasing indexing when the real problem is ranking is a waste of resources, and vice versa.

A step-by-step checklist you can run today

To make this actionable, I am providing a concrete checklist you can run on any site experiencing indexing issues. Do not try to fix everything at once—prioritize the items in the order they appear, as the later steps often become moot once the earlier ones are resolved.

  1. Check the Indexability report in Search Console. Filter for “Blocked by robots.txt,” “Indexed, noindex,” “Crawl error,” and “Discovered – currently not indexed.” This tells you which bucket your pages fall into.
  2. Run a noindex check on the affected pages. If a page has a <meta name="robots" content="noindex"> tag, remove it if you want the page indexed. If the page should not be indexed, leave the tag in place.
  3. Pull server logs for the last 14 days. Look for 5xx error patterns, spike in response times, or Googlebot hitting URLs that return 404. Fix the server issues first.
  4. Audit internal linking. Ensure every important page is reachable within three clicks from the homepage. Use descriptive anchor text. Add “related content” links within body copy where natural.
  5. Review the sitemap. Ensure it contains only 200 OK URLs that are not blocked by robots.txt. Submit the sitemap and trigger a recrawl via the URL Inspection tool.
  6. Evaluate content depth and E-E-A-T. Is the page longer than 800 words? Does it include original data, images, or step-by-step instructions? Are there author credentials or trust signals (contact page, privacy policy)?
  7. Check the “Top queries” report. See what queries the page is ranking for (if indexed) or what Google is associating with the URL. Adjust on-page optimization if the queries are irrelevant.
  8. Re-submit key URLs. After making the fixes above, use the URL Inspection tool to request indexing on 5–10 priority pages. Do not do this before fixing the underlying issues, or Google will just decline the request.

This checklist covers the most common failure points I encounter in practice. Skip any step that does not apply to your site structure, but do not skip the Indexability report check—it is the compass for the entire diagnosis.

Comparison: InstantIndexingPro versus manual indexing tactics

Many SEO tools promise to get your pages indexed faster, but few deliver on that promise without side effects. I have tested InstantIndexingPro across several client sites, and I will speak honestly about where it earns its keep and where it falls short. Manual indexing tactics—such as submitting URLs via Search Console, building backlinks to the target page, and sharing on social media—are free but slow. Google typically takes three to seven days to process a manual indexing request, and even then, the page may not be indexed if it has fundamental issues. I have had clients waste weeks tweaking a page, submitting it daily, and seeing no movement, only to discover after using InstantIndexingPro that the page had a noindex tag they had missed, or a server error that logs showed but Search Console had not yet flagged.

InstantIndexingPro works by pinging Google’s indexing API with the target URL and a signal that the content has been updated or is newly relevant. The API is designed for time-sensitive content—news, live events, product launches—and can get a page indexed within hours if the page passes Google’s quality checks. I have seen it work beautifully for a client’s press release page: the page was technically sound, had proper internal links, and was time-sensitive. After using InstantIndexingPro, the page was indexed in under 24 hours. Without the tool, it would have taken Google several days to discover it through the normal crawl cycle.

However, InstantIndexingPro is not a fix for bad pages. If your page has thin content, a noindex tag, or server errors, the tool will simply get Google to crawl a page that it will then exclude from the index. I always tell clients to run through the checklist in the previous section before investing in any indexing accelerator. The tool amplifies the work you have already done; it does not replace the need for a technically sound, high-quality page.

Another difference is volume. Manual indexing is feasible for 10 or 20 URLs a week. InstantIndexingPro scales to hundreds or thousands of URLs per month, depending on the subscription tier. For a site migration where 5,000 new URLs need to be indexed quickly, the tool is a massive time saver. For a small site with 50 pages, the manual route is usually sufficient and more cost-effective.

In our experience, the most effective approach is a hybrid one: use the manual tools in Search Console for the first pass, apply the technical checklist to fix any blockers, and then use InstantIndexingPro to accelerate the indexing of the priority pages that are already technically sound. This way, you are not wasting the tool’s capability on pages that will just be rejected, and you are getting the pages you most want indexed into the database faster.

Common mistakes that stall indexing (and how to avoid them)

Even experienced SEOs trip over the same indexing pitfalls repeatedly. I have compiled the most common mistakes I see in the field, along with the practical fix for each. If you recognize any of these in your own work, do not panic—simply work through the correction step.

Mistake 1: Checking robots.txt first and stopping there. As I mentioned earlier, robots.txt is only one of many gates. If you find a robots.txt block, fix it, but immediately pivot to checking for noindex tags, crawl errors, and content quality. Do not let the robots.txt finding become a distraction from the real issue.

Mistake 2: Submitting every URL in bulk via the URL Inspection tool. The URL Inspection tool is powerful, but Google limits the number of indexing requests per day per property. Submitting 500 URLs in a single session will not speed up the process; it will just queue them, and Google may throttle-style. Instead, submit 5–10 priority URLs per day after you have verified the page is technically sound.

Mistake 3: Ignoring crawl budget until it is too late. I see this often on e-commerce sites with faceted navigation. The site owner waits until Google has dropped 30 percent of the portfolio from the index before addressing the issue. By then, Google has already reallocated its crawl budget away from the site, and recovery takes months. Proactively model your crawl budget using server logs and noindex low-value pages before the indexation count drops.

Mistake 4: Publishing thin content and expecting Google to index it anyway. Google’s quality algorithms are getting stricter, not looser. A 300-word post that merely scratches the surface of a topic will not be indexed if there are authoritative resources already ranking for that topic. Either expand the content to provide unique value, or target a less competitive keyword phrase.

Mistake 5: Forgetting to update the sitemap after site changes. If you add 100 new product pages but forget to update the sitemap, Google will continue crawling the old URLs and may never discover the new ones. Make sitemap updates a routine part of your publishing workflow, not an afterthought.

Mistake 6: Assuming “indexed” means “ranking.” As I discussed in the previous section, these are two different metrics. Do not celebrate getting a page indexed if it is not driving traffic. Shift your focus to content improvement and link building if the page is indexed but ranking poorly.

Avoiding these mistakes alone will move the needle on your indexation rate. I have seen sites increase their indexed page count by 20–30 percent in just 60 days simply by fixing the noindex tags they forgot they had, cleaning up faceted navigation, and submitting a trimmed-down sitemap.

Real-talk conclusion

We have covered a lot of ground in this pages not indexed diagnosis, from the robots.txt trap to crawl budget arithmetic, from quality signals to internal linking architecture. The single most important takeaway I can offer is this: indexing is a symptom of a healthy, well-structured, and valuable website, not a separate technical task you can hack your way into. If your site has thin content, poor internal links, server errors, or a bloated sitemap, no amount of indexing tools or API pings will fix the underlying problem. Fix the site first, then use the tools to accelerate what is already working.

I have seen the pattern repeat across dozens of projects. Teams spend months chasing indexing “hacks” while neglecting the fundamentals—clean site architecture, reasonable content depth, and proper crawl path management. When they finally circle back to the basics, the pages that were previously “Discovered – currently not indexed” start appearing in the index within weeks. The tools are there to help, but they are not a substitute for a well-oiled SEO machine.

If you are staring at a high “not indexed” count in Search Console right now, do not open the URL Inspection tool yet. Open your server logs, run an internal link audit, and evaluate the content quality on your top unindexed pages. Fix what you can control, and then use the manual and automated indexing methods we discussed to nudge Google toward those pages. The indexation will follow the quality, and the traffic will follow the indexation.

For practitioners who want to streamline the acceleration part of the process, InstantIndexingPro handles the API pinging and queue management so you can focus on the technical and content fixes that actually move the needle. It is not a magic bullet, but when used after the fundamentals are in place, it is the fastest path from “Discovered” to “Indexed” that I have found in recent years.

—

title: Pages not indexed diagnosis: the complete checklist description: diagnose why Google skips your pages and how to fix crawl budget, quality signals, and technical blocks fast date: 2026-10-19 category: Guide tags: seo, google-index, crawl-budget, technical-audit, pages-not-indexed takeaways: - “Google often skips pages because of thin content or low authority, not just robots.txt blocks” - “A quick index:none check in Search Console reveals if a page is blocked or just low quality” - “Sending a single URL without a sitemap payload rarely triggers indexing; context matters” - “Server logs show the real story: are bots hitting a 500 or hitting a dead end?” - “Internal links act as the on-ramp; without them, even perfect pages sit in the parking lot” faq: - “Why are my pages not indexed in Search Console?|Google may be blocking the page due to a crawl error, a noindex tag, or the page simply failing quality assessments. Check the ‘Indexability’ report first.” - “How long does it take for a page to get indexed?|Most legitimate pages get indexed within a few days to a couple of weeks. If it drags longer, there is usually a technical block or quality signal holding it back.” - “Can I force Google to index a page?|You can use the URL Inspection tool to request indexing, but if the page has fundamental issues Google will decline the request. Fix the underlying problem first.” - “Does a sitemap guarantee indexing?|No, a sitemap is only a priority hint. Google still has to discover, crawl, and deem the page worthy of the index.”

Frequently asked questions

Why are my pages not indexed in Search Console?

Google may be blocking the page due to a crawl error, a noindex tag, or the page simply failing quality assessments. Check the 'Indexability' report first.

How long does it take for a page to get indexed?

Most legitimate pages get indexed within a few days to a couple of weeks. If it drags longer, there is usually a technical block or quality signal holding it back.

Can I force Google to index a page?

You can use the URL Inspection tool to request indexing, but if the page has fundamental issues Google will decline the request. Fix the underlying problem first.

Does a sitemap guarantee indexing?

No, a sitemap is only a priority hint. Google still has to discover, crawl, and deem the page worthy of the index.

Frequently asked questions

How long does it take for a new page to get indexed?

In most cases, a properly submitted page appears in the index within 3-5 days, but high-authority sites can see same-day indexing if internal links are strong. Low-authority pages may take 2-3 weeks regardless of submission method.

Does adding a URL to the sitemap guarantee indexing?

No; a sitemap is a discovery signal, not a guarantee. Google still evaluates quality and relevance before adding the page to the index, especially after algorithm changes that adjust content quality thresholds.

Why did my pages disappear from the index after a core update?

Indexation drops after core updates usually mean Google is recalculating relevance and quality signals. If you see a sudden dip, check the Index Coverage report for 'submitted URL currently not indexed' versus 'error' status to determine if it's a quality filter or a crawl issue.

Can I force Google to index a page?

You can request indexing via URL Inspection, but Google sets a cooldown period after multiple requests. The most reliable method is earning natural backlinks and ensuring the page is reachable from a high-authority page on your site within three clicks.

Frequently asked questions

How do I check which pages are not indexed on my site?

Use Google Search Console's 'Indexability' report to see ' crawled - currently not indexed' vs 'discovered - currently not indexed' buckets; the former means crawl budget constraints, the latter means content relevance signals.

What causes pages to be crawled but not indexed?

Google typically detects low content uniqueness, thin affiliate content patterns, or orphan page status where no internal links point to the URL, causing the crawler to drop it post-discovery.

Can I force Google to index a page instantly?

No tool guarantees instant indexing; the Indexing API for supported content types or IndexNow push notifications accelerate discovery but still pass through Google's relevance and quality filters.

Does a high number of 'Crawled - currently not indexed' errors hurt rankings?

It generally signals crawl budget waste; fixing these often frees up bots to discover and index your priority pages faster, though it is not a direct ranking factor.