Crawled but not indexed? How to diagnose and fix Page indexing statuses in Search Console

What do "Crawled - currently not indexed" and "Discovered - currently not indexed" actually mean?

Both statuses appear in the Page indexing report in Google Search Console, and both describe URLs that are not in Google's index right now. They sit at different stages of the pipeline: one after a crawl, the other before it, and the cause and the cure differ.

What does "Crawled - currently not indexed" tell you?

Googlebot requested the page, received a response and processed it, but Google decided not to include it in the index at this time. Google's help page says the page may or may not be indexed in the future, and that you do not need to resubmit the URL for crawling. Because the fetch succeeded, the cause is rarely technical access. It is more often a judgment about value, duplication or quality.

Is this status a penalty?

No. It is a status, not a manual action. Search Console reports manual actions separately, and a page can sit in this state for ordinary reasons, such as thin content, near-duplication or low perceived demand.

What does "Discovered - currently not indexed" tell you?

Google found the URL, usually through a sitemap or a link, but has not crawled it yet. The help page explains that Google likely postponed the crawl because crawling at that moment was expected to overload the site, and the last crawl date stays empty until the first fetch. So this status points toward crawl scheduling, site capacity and the perceived importance of the URL.

Why would Google postpone a crawl?

Typical triggers are slow server responses, many low-value URLs competing for attention, a recent surge of new URLs and weak internal linking that signals low importance. The guidance on server response time and crawl frequency explains how a slow origin reduces Googlebot's appetite.

How do the two statuses differ from other "not indexed" reasons?

Search Console lists many other reasons, among them "Duplicate without user-selected canonical", "Alternate page with proper canonical", "Soft 404", "Blocked by robots.txt" and "Excluded by noindex tag". Some indicate a defect, and some are working as intended. Treat the report as a diagnostic list and not a to-do list of errors.

Which statuses need no action?

Alternate pages with a proper canonical, pages you deliberately excluded with noindex, and redirected URLs usually need nothing. Google's help text for "Alternate page with proper canonical" says there is nothing you need to do.

How do you read the Page indexing report in Search Console?

Start with the summary chart of indexed and not-indexed pages, then open the "Why pages aren't indexed" table, click each reason and inspect examples. Filter by sitemap so that you compare submitted URLs with indexed URLs.

Which filters and views give the clearest picture?

Use the filter for "All submitted pages" to see only URLs you listed in your sitemap, since those are the ones you expect to be indexed. Compare it with "All known pages", which includes URLs Google found elsewhere, such as parameters and old addresses. A large gap between submitted and indexed pages is the number to chase, and a large gap in known pages is usually noise.

How do you export the data?

Each reason table has an export button. Download the URL lists, join them with your crawl data and group them by template, folder and parameter pattern. Patterns point to causes that single URLs hide.

How should you use the URL Inspection tool?

Paste a representative URL into the URL Inspection tool to see the indexing status, the last crawl date, the canonical Google selected, whether crawling and indexing were allowed and, with a live test, how Google renders the page today. Compare the user-declared canonical with the Google-selected canonical, because a mismatch often explains "duplicate" statuses. The article on Googlebot, rendering and the DOM shows how to read the rendered HTML and spot resources that failed to load.

Does "Request indexing" fix the problem?

It asks Google to crawl a URL sooner, and it does not guarantee indexing. If the page has a quality or duplication problem, requesting indexing repeatedly changes nothing. Fix the cause first, then request once.

What is the difference between a sitemap URL and an indexed URL?

A sitemap is a suggestion, not an instruction. Google's sitemap guidance says to list canonical, indexable URLs you want in search. If your sitemap contains redirected, noindexed or duplicate URLs, the report fills with exclusions that you created yourself. Clean the sitemap before you interpret the numbers.

How often does the report update?

It reflects Google's processing, which lags behind your changes by days or weeks, and it is sampled for very large sites. Record the date of every fix so that you can match changes in the chart to your actions.

Why does Google crawl a page and then decline to index it?

Google indexes pages it judges useful, distinct and worth storing. After a crawl, the systems compare the page with what is already known, evaluate quality signals and canonical relationships, and decide whether the page adds something. Pages that duplicate, thin out or mislead tend to wait outside the index.

Which content problems are the usual suspects?

Thin pages with little unique text, near-duplicate pages that differ only by a city name or a filter, auto-generated pages with no real value, doorway-style pages built to catch queries, boilerplate-heavy product pages and outdated posts that nobody reads. Google's spam policies describe scaled content abuse, and the discussion of scaled content abuse and AI-generated content explains where low-value mass production crosses the line.

How can you tell a thin page from a short, useful one?

Length is not the test. A short page that completely answers a narrow question can be valuable. A long page that repeats generic text is not. Ask whether a visitor would learn something here that the rest of your site and the top results do not already tell them.

Which duplication patterns trigger exclusion?

Faceted navigation and parameter URLs, session IDs, printer-friendly versions, HTTP and HTTPS or www and non-www variants, trailing-slash inconsistencies, and category and tag archives that list the same posts. Google chooses a canonical among duplicates, and the others usually appear as duplicate or alternate pages. The guide to canonicalizing product variants works through the commercial version of this problem.

What if Google chooses a different canonical than you did?

Strengthen your signals: make the preferred URL the one in internal links, sitemaps, redirects and the rel="canonical" tag, and make the duplicate genuinely different if it deserves its own entry.

Which quality signals matter at site level?

Google evaluates pages in the context of the whole site. A site with a large share of thin or unhelpful pages can see slow indexing across the board, even for good pages. Google's guidance on helpful, people-first content and E-E-A-T describes the qualities its systems reward: demonstrated experience, clear authorship and a purpose beyond attracting clicks.

Can a few weak pages affect the good ones?

They can dilute internal links and crawl attention, and a high proportion of low-value URLs can slow discovery of the rest. Pruning and consolidating weak sets is often the single most effective fix.

Why does Google discover a URL but not crawl it?

Discovery means a URL is in Google's queue. Crawling depends on Googlebot's scheduling, which weighs the site's crawl capacity, the perceived value of each URL and the load the site can bear. For small sites the cause is almost always weak signals of importance. For large sites it is a mix of capacity and priority.

What does crawl budget have to do with it?

Google's documentation on managing crawl budget for large sites explains that it applies mainly to very large sites, sites with rapidly changing content and sites with many URLs reported as "Discovered - currently not indexed". It describes crawl capacity (what the server can handle) and crawl demand (how much Google wants to crawl). The guide to crawl traps and infinite filter URLs shows how endless URL spaces drain that attention.

Does a small business site have a crawl budget problem?

Rarely. If a site with a few hundred pages shows many "Discovered" URLs, the likelier causes are thin pages, weak internal links or a slow or unstable host, not budget in the technical sense.

Which technical issues delay crawling?

Slow time to first byte, frequent 5xx errors or timeouts, rate limiting that blocks Googlebot, large uncompressed HTML, redirect chains, blocked CSS and JavaScript and unstable DNS. Google's Crawl stats report shows request counts, response times and host status, so check it for spikes in errors or latency that line up with the postponed URLs.

Where do you find server-side evidence?

In access logs. The method in log file analysis for large URL sets shows how to confirm that Googlebot, verified by reverse DNS or published IP ranges, is or is not requesting your URLs.

How do internal links signal importance?

Pages linked from the homepage, navigation and relevant content get crawled sooner than pages buried six clicks deep or linked only from a sitemap. Orphan pages, which nothing links to, are common victims. Surfacing them is covered in the walkthrough on orphan page identification.

How many internal links does a page need?

There is no magic number. A page you want indexed should be linked from at least one crawlable, relevant page with descriptive anchor text, and your most important pages should be linked from several.

What is a step-by-step workflow for diagnosing not-indexed URLs?

Work through five steps: segment, sample, inspect, classify and decide. The workflow turns a long list of URLs into a short list of fixable patterns.

How do you segment the URL list?

Export the URLs for each reason and tag them by page type (product, category, article, location page, tag archive, parameter URL), by folder, by publication date and by whether they appear in the sitemap. Count each group. A single template with thousands of URLs usually explains most of the report.

Which segments deserve attention first?

Those with business value: revenue pages, lead-generating service pages and cornerstone content. Ignore parameter noise until the valuable pages are fixed.

How do you sample and inspect effectively?

Take ten URLs from each segment, open them in the URL Inspection tool, run a live test and note the canonical, the render, the status code and any blocked resources. Then read each page as a visitor and compare it with the best page you have on that topic.

What should you record for each sampled URL?

URL, template, status code, user-declared canonical, Google-selected canonical, word count of unique text, internal inlinks, rendered content check and your verdict: valuable, duplicate, thin or unnecessary.

How do you classify the cause?

Symptom	Likely cause	Typical fix
Crawled, thin unique text	Low content value	Add original detail, merge into a stronger page or remove
Crawled, near-duplicate of another URL	Duplication	Consolidate, canonicalize or noindex
Discovered, no internal links	Weak importance signals	Add contextual links from relevant pages and navigation
Discovered, slow or erroring server	Crawl capacity limits	Improve hosting, caching and error rates
Soft 404	Empty page returning 200	Return a real 404 or add meaningful content
Canonical points elsewhere	Mixed or incorrect signals	Align canonicals, redirects, sitemaps and links

What if a page fits two causes?

Fix the cheaper one first and recheck. Duplication and thinness often coexist, and consolidating solves both.

How do you decide what to do with each segment?

Choose among five actions: improve the page, strengthen its links, consolidate it into another page with a permanent redirect, mark it noindex, or remove it. The decision framework in the content pruning and consolidation plan gives the rules for choosing, including how to protect URLs that have backlinks.

Should you delete everything that is not indexed?

No. Some pages are not indexed for good reason, and others will index once you improve them. Decide on merit, not on status alone.

How do you improve content so that Google wants to index it?

Make each page the clearest, most complete and most trustworthy answer to a specific question, and make it different from your other pages. That means original detail, accurate facts, structured headings and visible expertise.

What does a stronger page contain?

A direct answer near the top, headings that name the sub-questions, first-hand details such as photographs, measurements, prices or case notes, relevant entities and related terms used naturally, evidence and sources, a named author, an update date that reflects real revision and links to deeper pages. These are the same qualities that earn visibility in AI features, as the guide to AI Overviews and AI Mode explains.

How do you add uniqueness to templated pages?

Include data and details that exist only for that page: local project examples for a location page, specifications and fit notes for a product, a worked example for a service. If you cannot supply anything unique, the page probably does not need to exist.

What about location and service-area pages?

These are a frequent source of crawled-but-not-indexed pages. Keep a page for a place only when you have real local content, such as completed projects, local regulations, team presence and customer questions. Merge the rest into a regional page. The advice on link building for local businesses shows how to gather real local detail that also earns links.

Will adding words alone help?

No. Padding makes pages worse. Add information, not volume.

How should you handle ecommerce product and category pages?

Write original descriptions for important products, show real photos, add specifications, reviews and shipping details, and make sure variants are handled with consistent canonicals. For category pages, put useful text where it helps shoppers, as discussed in the notes on category page content placement. Keep markup and visible data aligned, as the comparison of Merchant Center feeds and structured data explains.

What if you have thousands of near-identical products?

Prioritize by revenue, enrich the top sellers first, consolidate variants where sensible and keep the rest out of the sitemap until they have something to offer.

How do canonicals, sitemaps and links help Google decide?

Consistent technical signals remove ambiguity: one URL per piece of content, listed in the sitemap, linked internally, self-canonical and returning 200. When these signals disagree, Google guesses, and the guess is often to exclude.

Which canonical mistakes cause exclusion?

Canonical tags pointing to a different page for no reason, canonicals to redirected or noindexed URLs, canonicals that differ between the raw HTML and the rendered page, multiple canonical tags and canonicals set only by JavaScript. Google's documentation on consolidating duplicate URLs says canonicalization is a hint, which is why redirects and consistent linking add weight.

When should you use a redirect instead of a canonical?

Use a permanent redirect when a URL should disappear and a clear replacement exists. Use a canonical when both URLs must stay live, such as parameter or variant URLs.

How should you build and maintain the sitemap?

Include only canonical, indexable, 200-status URLs, update the lastmod date only when the content changes meaningfully, split large sitemaps by section so that you can compare indexing rates, and remove URLs you have retired. A sitemap that mirrors your intent makes the Page indexing report much easier to read.

Should you submit every URL?

Submit URLs you want indexed. Leave out parameter variants, internal search results and thin archives.

How do you strengthen internal links?

Add contextual links from related, already-indexed pages to the pages you want crawled, use descriptive anchor text, include important pages in navigation or hub pages, and fix orphan URLs. Google's link guidance says to use anchor elements with an href attribute and to give every page you want indexed at least one link from another page. The reasoning behind crawlable links and descriptive anchor text applies directly here.

Does a footer link count?

It is crawlable, but sitewide footer links carry less contextual meaning than a link inside relevant content.

Which technical fixes speed up crawling and indexing?

Improve server speed and stability, return correct status codes, keep HTML lean, avoid blocking resources and make rendering dependable. Googlebot crawls more readily from hosts that respond quickly and consistently.

What server improvements help?

Caching and a content delivery network, efficient database queries, adequate hosting capacity, compression and keeping time to first byte low. Watch the Crawl stats report for response time trends, and fix recurring 5xx errors at the source.

Should you limit crawl rate?

Only if Googlebot is genuinely overloading your server. Google's guidance says most sites do not need to, and that slowing the crawl can reduce discovery.

How do status codes and soft 404s affect indexing?

Return 404 or 410 for pages that no longer exist, 301 or 308 for permanent moves and 200 only for real content. A page that says "not found" but returns 200 is a soft 404 and is excluded. Empty category pages, out-of-stock pages with no information and internal search results with no hits are common sources.

How do you fix soft 404s on ecommerce sites?

Keep temporarily out-of-stock products live with accurate availability and alternatives, redirect permanently discontinued products to the closest relevant page or return 404 or 410, and noindex empty search or filter pages.

Why do rendering problems matter?

If key content appears only after JavaScript runs, and that script fails or is blocked, Google may see a nearly empty page and decline to index it. Test with the URL Inspection live test, and prefer server-side or static HTML for important content. The comparison of client-side and server-side rendering risk explains the trade-offs.

Which resources must stay unblocked?

The CSS, JavaScript and images required to render the main content. Blocking them in robots.txt can leave Google with an incomplete picture.

Which "not indexed" pages are healthy, and which should you leave alone?

A tidy site has many intentionally excluded URLs. Duplicates handled by canonicals, pages marked noindex, redirected old URLs and private areas should not be indexed, and forcing them in does harm.

What does a healthy exclusion list look like?

A good report contains mostly "Alternate page with proper canonical", "Page with redirect", "Excluded by noindex tag" and "Not found (404)" for pages you meant to retire, with few "Crawled" and "Discovered" entries among valuable pages. The goal is not zero excluded URLs. It is that every important URL is indexed and every excluded URL is excluded on purpose.

Should you ever force indexing of a noindexed page?

Only if the noindex was a mistake. Remove the tag or header, confirm it in the live test and request indexing.

How do robots.txt and noindex interact?

Google's help text says robots.txt is not the correct mechanism to avoid being indexed, and that a blocked page can still be indexed if other information exists. To exclude a page reliably, allow crawling and use noindex, or protect it with a login. The detailed trade-offs are in the guide to noindex versus disallow for filtered pages, and the overview of robots.txt and AI crawler controls explains what each rule can and cannot do.

Why is a robots.txt block plus noindex a trap?

Because the crawler never fetches the page, so it never sees the noindex tag, and the URL can linger in results with no description.

What does a real fix look like in practice?

This is a fictional example that illustrates the method. The outcomes are invented.

What was the situation?

A fictional online garden retailer had 6,200 URLs in its sitemap, of which 2,900 sat in "Crawled - currently not indexed" and 1,100 in "Discovered - currently not indexed". Organic revenue had plateaued, and the team assumed Google had a bug.

What did the diagnosis show?

Segmenting the exports showed that 2,000 crawled URLs were product variants with manufacturer text, 600 were tag archives with no unique copy and the rest were seasonal blog posts. Most "Discovered" URLs were deep pagination pages linked only from the sitemap, and the Crawl stats report showed time to first byte spiking above one second at peak hours.

What did they change?

They rewrote the top 300 products with original descriptions, photographs and care guides, consolidated variants under canonical parent products, noindexed and then removed the tag archives, merged overlapping seasonal posts into evergreen guides with permanent redirects, linked the new guides from category pages with descriptive anchor text, trimmed the sitemap to canonical URLs and added caching to cut response times. They monitored the Page indexing report weekly, noted the date of each batch and recorded that indexing changes took several weeks and could not be guaranteed.

What did they learn?

The statuses were symptoms of duplication, thinness and weak signals, not a Google fault. Fixing patterns moved far more URLs than any single resubmission.

Which mistakes make indexing problems worse?

The mistakes below waste time or deepen the problem. All are avoidable with a pattern-based workflow.

What do teams get wrong most often?

Requesting indexing for hundreds of URLs, stuffing pages with filler text, blocking pages in robots.txt instead of noindexing them, submitting sitemaps full of redirected or duplicate URLs, deleting pages that have backlinks, publishing more thin pages to "fix" a volume gap and judging success within days.

Which mistake is the most expensive?

Publishing at scale without a quality gate. Each new batch of thin pages adds to the pool Google declines to index and can weaken signals for the rest.

How do you build a durable habit?

Review the Page indexing report monthly, track the ratio of indexed to submitted pages per section, require a distinct purpose for every new URL and keep a change log. The article on the technical SEO audit checklist places indexing checks inside a wider routine, and measuring SEO in the AI era explains how to tie indexing health to visibility and business outcomes.

How long should you wait before judging a fix?

Several weeks at minimum, and longer for large sites. Google recrawls on its own schedule, and the expectations set out in the explanation of how long SEO takes apply here too.

How does AH SEO Agency help with indexing problems?

We segment your Page indexing exports, inspect representative URLs, trace each pattern to its cause and write a prioritized fix list covering content, canonicals, internal links, sitemaps and server performance. We tell you plainly which statuses are healthy and which are real problems.

Where do you start?

Book a technical SEO engagement, order a full SEO audit or request a free SEO audit to see which URLs are held back and why.

Summary: how do you move URLs from "not indexed" to indexed?

Segment the report, inspect samples, find the pattern, then improve content, align canonical and sitemap signals, strengthen internal links and stabilize the server. Leave healthy exclusions alone, and measure over weeks.

• "Crawled - currently not indexed" points to value, duplication or quality, and "Discovered - currently not indexed" points to crawl scheduling and importance.
• Neither status is an error, and resubmitting rarely helps.
• The URL Inspection tool, Crawl stats and server logs give the evidence.
• Consistent canonicals, clean sitemaps and contextual internal links remove ambiguity.
• Prune, merge or enrich weak sets instead of publishing more of them.