Discovered – currently not indexed and crawled status: Differences, diagnosis, and solutions

Diagnosis: How do you read URL Inspection and the live test?

For pages marked as not indexed in Search Console, diagnosis begins by examining several important affected pages individually in the URL Inspection tool. The tool separately shows Google’s latest indexed information and the live test result for the page’s current state.

According to Google’s URL Inspection tool help page, the live test only confirms whether Google can access the page for indexing; a valid result does not mean the page will be indexed. The documentation also notes that the live test cannot detect every indexing problem. Read the following fields during inspection:

• Indexing allowed? If “No”, the page has a noindex tag or header.
• Google-selected canonical: Located in the Page indexing section and visible only in indexed data, not in the live test.
• Crawled page: The HTTP response, headers, and HTML received by Google; these reveal whether the content actually reached Google.
• Screenshot: Generated only in the live test; it shows whether text loaded through JavaScript is visible.

Basic use of the report and tool is explained step by step in the Google Search Console usage guide .

Checking canonicals, duplicate content, and the sitemap

If an unindexed page is a duplicate or very close equivalent of another page, Google selects one canonical page to represent the group. When canonical tags, internal links, and the sitemap point to different addresses, Google receives conflicting signals.

Google’s canonicalization documentationstates that the canonical page is crawled most regularly, while duplicate pages are crawled less frequently to reduce the load crawling places on the website. The document lists regional variants, sorting and filtering parameters, and demo versions accidentally left publicly accessible among causes of duplicate content. Duplicate content is not considered a spam policy violation, but it leads Google to choose which page enters the index.

A sitemap should contain only URLs intended for indexing, returning a 200 response, and pointing to their own address as canonical. A sitemap full of redirected, noindex, or duplicate addresses pushes genuinely important pages further back in the queue.

Solutions for Discovered status: Server response and crawl load

When pages with Discovered – currently not indexed status increase, the first place to examine is how the server responds to Googlebot. According to the crawl budget documentation, when a website slows down, response times increase, or the server returns 5xx errors or rate-limiting signals such as HTTP 429, the crawl capacity limit falls and Google crawls less.

The document describes crawl demand as the second factor: demand for Googlebot varies with website size, update frequency, page quality, and relevance. If most URLs known to Google are duplicates or unimportant, crawl time is spent on them. The main steps recommended in the document are:

1. Consolidate duplicate content, directing crawling toward unique content rather than individual URLs.
2. If unimportant URLs (such as infinite-scroll duplicates or differently sorted lists) cannot be consolidated, block their crawling with robots.txt.
3. Do not use noindex to manage crawl budget; Google still requests the page and then drops it after seeing noindex.
4. Avoid long redirect chains, improve server response times, and support 304 (Not Modified) responses.

If URL Inspection shows a “Hostload exceeded” warning, the documentation recommends increasing server resources if it makes sense for the business. If regular 500 errors also occur, investigate their source using the steps in the 500 Internal Server Error guide . Although the guide primarily targets large websites, the same logic applies to a small website with slow server responses.

Solutions for Crawled status: Strengthening thin and duplicate content

For pages with Crawled status, the solution is usually the page itself rather than a technical setting: if content repeats another page, is very short, or offers the searcher no new information, first question why the page exists. In its recrawling documentation, Google states that its systems prioritize quickly including high-quality, useful content.

During review, ask the following questions for each page:

• Does this page cover the same topic and intent as another page on the website?
• Does the text contain unique information beyond the template, or does only the city or product name change?
• Is this an automatically generated address such as a tag, archive, filter, or search results page?
• Is the page’s main text present in the HTML even before JavaScript loads?

Choose one of three approaches according to the answers: genuinely expand and differentiate the content, consolidate similar pages into one strong page and redirect the old ones with 301 redirects, or deliberately leave the page outside the index. Highlighting the website’s valuable pages is a healthier goal than trying to get every page indexed.

Page not being indexed: Internal links and orphan pages

If a page is not indexed and no internal links point to it, it sits in an unimportant corner of the website in Google’s eyes. Google’s crawlable links documentationstates that every important page should have a link from at least one other page on the website.

The how Google Search works documentation also explains that most new pages are discovered by following links from a known page (such as a category page) to the new page. Pages found only in a sitemap and never mentioned in menus, categories, or related posts remain orphaned. According to the crawlable links documentation, Google can generally crawl a link only if it is an <a> element with an href attribute; buttons operating only through a JavaScript click event do not serve this purpose.

The solution is to link the important page from relevant service pages, its category page, and current articles using descriptive anchor text. For cases where multiple pages drop out of the index after migration or redesign, also consult the traffic checks after a website migration guide .

The Request indexing button: Limits and quota

The “Request indexing” button in URL Inspection requests recrawling of individual URLs; it does not ensure indexing and only adds the page to a queue. Google’s request recrawling documentationexplicitly states that a crawl request does not mean the URL will be indexed immediately or in the future.

Official documentation lists the following limitations for the button:

• There is a quota for individually submitted URLs; the URL Inspection help page states that daily request counts are limited.
• Repeatedly requesting the same URL does not speed up crawling.
• A request cannot be submitted for a page shown as non-indexable in the live test.
• Submitting a request requires being an owner or full user of the Search Console property.
• For many new or updated pages, the recommended route is submitting a sitemap marked with <lastmod>.

The documentation states that crawling can take from a few days to a few weeks. Since the report already states that resubmission is unnecessary for a page with Crawled status, pressing the button without changing content produces the same result.

How does the Validate Fix workflow work?

Validate Fix is a way to ask Google to recheck affected URLs after all instances of a problem have been corrected. According to the Page indexing report documentation, the process generally takes around two weeks, and can take longer in some cases.

When the button is pressed, Search Console immediately checks a few pages first; if the problem persists on them, validation ends. Otherwise, the status becomes “Started” and only URLs containing known instances of the problem are queued for recrawling, rather than the whole website. If the first checked instance is fixed, the status becomes “Looking good”; if all known instances have disappeared, it becomes “Passed”; if the issue persists on some pages, it shows “Failed”. If the issue resolves itself without validation being requested, the status is “N/A”.

The documentation warns against the following: do not press the button again before validation ends as passed or failed; after failure, use See details to view problematic URLs, correct them, and use Start new validation. Filtering by a sitemap containing only the most important pages before requesting validation can complete the process faster than a request covering every URL. For these two statuses, being considered “fixed” means Google has crawled and indexed the page, so validation is meaningful only after a real improvement.

Common mistakes: Common practice and the correct approach

For pages showing Discovered – currently not indexed or Crawled – currently not indexed warnings, the most frequent mistake is trying to solve the problem with a single button. The table below shows the differences between common practice and a sound approach:

As the report documentation emphasizes, a URL not being indexed does not always result from a problem, and the total count in the report is not expected to exactly match the number of URLs on the website. Tags, pagination, and parameterized addresses remaining outside the index are normal on most websites.

When should you wait, and when should you intervene?

Waiting is reasonable if excluded pages are unimportant or their numbers decrease over time; intervention is needed if important pages stay in the same status for a long time and the count rises. Google provides no specific indexing timeframe, so examine the trend more than the calendar.

Situations where waiting is enough

If a few newly published pages are waiting as Discovered – currently not indexed, the server responds quickly, pages are connected by internal links, and the report count decreases over weeks, the process is progressing naturally. Additional requests do not change the result in this situation.

Situations requiring intervention and specialist support

If service, category, or product pages remain Crawled for a long time, the Discovered count keeps growing, or server-related warnings appear in URL Inspection, the issue warrants technical investigation. When hundreds of similar pages, complex filters, and a migration history combine, the technical SEO service examines URL inventory, canonical signals, internal linking, and server response together. At Onur Freelance, monthly SEO starts at 9,000 TL; package details are on the SEO prices page.