Indexing and coverage errors keep pages out of Google, and you fix them by reading Search Console’s coverage report, diagnosing each status, and resolving the specific cause so valuable pages get indexed. An unindexed page cannot rank for any query, no matter how strong the content is.
This article explains how indexing works, how to read the Search Console coverage report, what each “not indexed” status means, and how to fix both quality-related and technical non-indexing. It covers the exact statuses you will see, the cause behind each one, and the action that resolves it.
Every section gives a direct answer first, then the diagnosis and the fix. The goal is a clear path from a missing page to an indexed page that can compete in search results.
How Indexing Works?
Indexing is the storage stage of search, where Google saves a rendered page in its index so the page can appear in results. Google completes three steps in order: it crawls the URL, renders the HTML and JavaScript, then evaluates the page for indexing. A page that fails any step stays out of the index.
Crawling fetches the page. Rendering builds the final content the way a browser does. Indexing stores the page and its signals. The coverage report in Search Console reports the outcome of these steps per URL, splitting your site into indexed pages and not-indexed pages with a reason attached to each group.
Crawl
Google requests the URL and reads its response code, robots rules, and links.
Render
Google executes the page like a browser to see the final content and tags.
Index
Google evaluates value and signals, then stores the page or excludes it.
Understanding these three steps matters because each “not indexed” status maps to a failure at one of them. A robots block fails at crawl, a noindex tag fails at index, and a quality signal fails at the evaluation inside indexing. The terminology around how engines store and retrieve pages is covered in the reference entry on how search engine indexing works. Now that the three steps are clear, the next step is reading the report that records them.
[elementor-template id=”4365″]How to Read the Search Console Coverage Report?
The Search Console Pages report is the dashboard that records the indexing outcome for every URL Google found on your site. Open the report under the Indexing section in the left menu. The top shows a count of indexed pages and not-indexed pages. Below that sits a table that groups not-indexed pages by reason, such as “Excluded by noindex tag” or “Crawled - currently not indexed”.
Read the report in two passes. The first pass reviews the grouped reasons to see which statuses affect the most URLs. The second pass uses URL Inspection on a specific page to confirm the exact status, the canonical Google chose, the last crawl date, and whether the live page differs from the indexed version.
- Open the Pages report. Click Indexing, then Pages, in the Search Console sidebar.
- Sort by affected URLs. Start with the reason that blocks the largest number of valuable pages.
- Inspect one URL. Paste a single URL into URL Inspection to read its exact status and chosen canonical.
- Test the live URL. Use “Test live URL” to compare the current page against the last indexed version.
2 reports drive every diagnosis: the Pages report for the site-wide pattern and URL Inspection for the single-page detail. With the report open, the next task is matching each status to its cause and fix.
What Are the Common Not Indexed Statuses and Fixes?
The common “not indexed” statuses are the labels Search Console assigns to pages it chose to exclude. Each label points to a single cause and a single corrective action. The table below maps every status to its cause and its fix so you can route each affected page to the right repair.
| Status | Cause | Fix |
|---|---|---|
| Excluded by noindex tag | A noindex meta tag or X-Robots-Tag header tells Google not to index the page | Remove the noindex tag if the page should rank, then request indexing |
| Crawled - currently not indexed | Google crawled the page but judged it low value, thin, or duplicative | Improve depth and uniqueness, add internal links, strengthen the content |
| Discovered - currently not indexed | Google knows the URL but has not crawled it, often a crawl budget or value signal | Add strong internal links, include the URL in the sitemap, raise page value |
| Duplicate, Google chose different canonical | Several similar URLs exist and Google selected another as canonical | Set a correct canonical, consolidate duplicates to one page |
| Blocked by robots.txt | A robots.txt rule blocks Google from crawling the URL | Remove or narrow the disallow rule, then request indexing |
| Soft 404 | The page returns 200 but has little or no real content | Add real content, or return a proper 404 or a 301 redirect |
| Page with redirect | The URL redirects to another URL, so the source is not indexed | Confirm the redirect target is correct, or remove an unintended redirect |
| Not found (404) | The URL returns a 404 and no longer exists | Restore the page, or 301 redirect the URL to the closest live page |
These statuses fall into two repair tracks. Crawled-not-indexed and discovered-not-indexed point to quality and value. Noindex, robots blocks, canonical conflicts, and soft 404s point to technical settings. The next section handles the quality track first because it affects the most pages on content-heavy sites.
How to Fix Quality-Related Non-Indexing?
Quality-related non-indexing is exclusion that Google applies when a page is technically valid but judged too thin or too similar to existing results. The two statuses in this track are “crawled - currently not indexed” and “discovered - currently not indexed”. Both mean the page can be crawled but does not earn a place in the index on its current value.
Improve the page on three fronts. Increase depth by answering the full query and its follow-up questions in one place. Increase uniqueness by removing text that repeats other pages and adding original data, examples, or a real case. Increase internal support by linking to the page from related articles with descriptive anchor text, which raises both crawl frequency and perceived value.
- Depth. Cover the question, the qualifiers, and the related sub-questions instead of a single paragraph.
- Uniqueness. Replace duplicated boilerplate with original detail that no competing page already states.
- Internal links. Point relevant pages at the URL so Google revisits and re-evaluates it.
- Consolidation. Merge several thin pages on the same topic into one strong page when none earns indexing alone.
Google’s own documentation states that pages with little unique value are often left unindexed, which is why depth and uniqueness change the outcome more than any submission trick. The discipline of writing pages that earn indexing is detailed in the reference on SEO content writing fundamentals. Once quality is handled, the remaining exclusions are technical, so the next section corrects the settings that block indexing.
How to Fix Technical Non-Indexing?
Technical non-indexing is exclusion caused by a setting, tag, or status code rather than by content value. These faults are common after a site migration, a plugin change, or a staging environment that leaks blocking rules into production. Each fault has a precise fix that takes effect once Google recrawls the page.
Start with accidental blocks because they remove valuable pages instantly. A noindex meta tag or an X-Robots-Tag header keeps a page out of the index even when the content is strong, so remove the tag from any page that should rank. A robots.txt disallow rule stops the crawl before rendering, so narrow the rule to the paths you actually want blocked.
Then resolve duplicates and bad status codes. A canonical conflict happens when several URLs serve near-identical content and Google selects a different page as canonical. Set the canonical tag to the URL you want indexed, or consolidate the variants into one page. The role of the canonical tag in choosing one indexable URL is explained in the entry on the canonical tag and duplicate content.
A soft 404 returns a 200 status with empty or near-empty content, which confuses Google about whether the page exists. The behavior and detection of a soft 404 error response is documented in the terminology reference. Fix it by adding real content if the page should exist, or by returning a true 404 or a 301 redirect if it should not. With the technical faults corrected, the final step is asking Google to re-index the page and confirming it worked.
How to Request Indexing and Verify the Fix?
Requesting indexing is the action that tells Google to recrawl and reconsider a page after you fix its cause. Open URL Inspection, enter the corrected URL, run “Test live URL” to confirm the fix is live, then click “Request Indexing”. This queues the page for a fresh crawl but does not guarantee indexing on its own; the underlying cause must already be resolved.
Support the request with two structural signals. Confirm the URL appears in the XML sitemap so Google has a clear list of pages you consider important. Confirm at least one relevant page links to the URL with descriptive anchor text so the page is not orphaned. A page that is fixed, submitted, in the sitemap, and internally linked has the strongest path back into the index.
- Test the live URL. Run “Test live URL” in URL Inspection to confirm the fix is visible to Google.
- Request indexing. Click “Request Indexing” to queue a fresh crawl of the corrected page.
- Check the sitemap. Confirm the URL is present in the XML sitemap submitted in Search Console.
- Add internal links. Link to the page from related content so it is no longer an orphan.
- Reinspect later. Recheck the URL after several days to confirm the status changed to indexed.
Hours to weeks is the realistic window for indexing after a request, depending on crawl demand and page value. The same diagnosis sequence applies to large sites under crawl pressure, which is covered in the sibling guide on crawl budget for large service and location sites. Indexing problems also overlap with rendering, so pages that depend on scripts are addressed in the guide on JavaScript SEO problems and fixes.
Last Thoughts on Indexing and Coverage Errors
Indexing and coverage errors decide whether a page can compete at all, because a URL that Google excludes never reaches the ranking stage. The repair path is the same every time: read the Search Console Pages report, diagnose the exact status, resolve the specific cause, then request indexing and verify the result. Quality statuses such as crawled-not-indexed call for stronger, more unique content, while technical statuses such as noindex, robots blocks, canonical conflicts, and soft 404s call for corrected settings and status codes.
Treat the coverage report as a routine check rather than a one-time cleanup. Site migrations, plugin updates, and new templates reintroduce blocks and duplicates over time, so a monthly review keeps valuable pages indexed and catches regressions before they cost traffic. Pages that fall out of the index after being indexed deserve the same diagnosis, since the cause is recorded in the same report. Related foundations sit in the sibling guides on technical SEO issues that hurt local rankings and structured data that earns rich results.
Key Takeaways
- An unindexed page cannot rank, so indexing is the first requirement before any ranking work.
- Google crawls, renders, then indexes a URL; each “not indexed” status maps to a failure at one of these steps.
- The Search Console Pages report groups not-indexed URLs by reason, and URL Inspection confirms the status per page.
- Crawled-not-indexed and discovered-not-indexed signal low value; improve depth, uniqueness, and internal links.
- Noindex tags, robots blocks, canonical conflicts, and soft 404s are technical faults fixed by correcting settings and status codes.
- After fixing the cause, request indexing, confirm the sitemap and internal links, then reinspect to verify indexing.
Frequently Asked Questions (FAQs)
Why isn’t my page indexed?
Common reasons include a noindex tag, a robots.txt block, a duplicate or canonical conflict, thin content shown as crawled-not-indexed, a soft 404, or a redirect on the URL.
What is crawled - currently not indexed?
Crawled-currently-not-indexed means Google crawled the page but chose not to index it, usually a quality or value signal. Improve depth, uniqueness, and internal links to strengthen the page.
What is discovered - currently not indexed?
Discovered-currently-not-indexed means Google knows the URL but has not yet crawled or indexed it, sometimes due to crawl budget or perceived low value. Add internal links and sitemap entries.
How do I find indexing errors?
Use the Search Console Pages report to see indexed and not-indexed groups with reasons, then use URL Inspection to read the exact status and chosen canonical for each individual URL.
How do I fix a noindex mistake?
Remove the accidental noindex meta tag or X-Robots-Tag header, or remove the robots.txt block, then enter the URL in URL Inspection and request indexing so Google recrawls it.
What causes duplicate or canonical exclusions?
Duplicate or canonical exclusions come from multiple similar URLs serving near-identical content. Set a correct canonical tag to the preferred URL, or consolidate the variants into one indexable page.
What is a soft 404?
A soft 404 is a page that returns a 200 status with little or no real content. Fix it by adding genuine content, or by returning a proper 404 or a 301 redirect.
How do I get a page indexed?
Fix the underlying cause, confirm the URL is in the sitemap and internally linked, then enter it in URL Inspection and click Request Indexing so Google queues a fresh crawl.
Does thin content prevent indexing?
Thin content can prevent indexing, because crawled-not-indexed often reflects low value. Improve depth, add unique data and examples, and link to the page from related content to raise its value.
How long does indexing take?
Indexing takes from hours to several weeks. Requesting indexing can speed the recrawl, but page value and crawl demand decide the final outcome, so a request alone does not guarantee indexing.
Should every page be indexed?
No. Apply noindex to thin, duplicate, or utility pages, and index only valuable, unique pages. Indexing low-value URLs dilutes site quality and wastes crawl resources.
Why did indexed pages drop out?
Indexed pages drop out after a quality reassessment, new duplicates or canonical changes, an added block, or an error. Diagnose the cause in the Search Console Pages report and apply the matching fix.
Want More Leads From Search?
Get a free, no-obligation SEO consultation and a clear plan to grow your business.
