Quick answer
Indexability is a page’s ability to be added to a search engine’s index after it is crawled. It depends on a successful response, no noindex directive, a self-referencing canonical, renderable content and sufficient value; crawlability is the earlier step of being fetchable at all.
What is indexability?
Indexability is whether a search engine is able and allowed to add a page to its index after it has fetched it. An indexable page returns a successful response, is not excluded by a noindex directive, is not pointing its canonical to a different URL, and has content the engine can render and considers worth keeping.
Only indexed pages can rank. A page that is perfectly written but not indexable gets no organic traffic at all.
Crawlability vs indexability
The two are steps in a pipeline, and a page can fail at either:
| Step | Question | Typical blockers |
|---|---|---|
| Discovery | Does the engine know the URL exists? | No internal links (orphan pages), missing from the sitemap |
| Crawlability | Can the crawler fetch it? | robots.txt disallow, server errors, timeouts, login walls |
| Rendering | Can it see the content? | Content only loaded by JavaScript that fails or is blocked |
| Indexability | Is it allowed and worth storing? | noindex, canonical to another URL, duplicate or thin content, soft 404 |
| Ranking | Does it deserve a position for a query? | Relevance, quality, links |
A subtle point: robots.txt controls crawling, not indexing. A URL blocked in robots.txt can still appear in results (without a snippet) if other pages link to it, and a noindex tag on a page blocked by robots.txt is never seen. To keep a page out of the index, allow crawling and use noindex; see robots.txt disallow all and X-Robots-Tag.
What makes a page non-indexable
| Signal | How to check | Fix |
|---|---|---|
<meta name="robots" content="noindex"> or X-Robots-Tag: noindex | View source, response headers | Remove if the page should rank |
| Canonical points elsewhere | <link rel="canonical"> in the head | Self-canonical for pages that should rank |
| Redirect (3xx) | Response status | Link to the final URL directly; avoid redirect chains |
| Client or server error (4xx, 5xx) | Response status | Fix or redirect; monitor 5xx |
| Soft 404 | Page returns 200 but looks empty or "not found" | Return a real 404, or add real content |
| Duplicate content | Similar pages, parameters | Consolidate, canonicalize |
| Thin or low-value content | Search Console "crawled, currently not indexed" | Improve, merge or remove |
Worked example: auditing a site's indexability
A site submits 1,200 URLs in its sitemap. A crawl and Search Console's page indexing report show (sample data):
| Status | URLs | Share | Action |
|---|---|---|---|
| Indexed | 860 | 72% | Monitor |
| Excluded by noindex | 95 | 8% | 80 are tag archives (keep), 15 are product pages set to noindex by mistake (fix) |
| Alternate page with proper canonical | 120 | 10% | Expected: parameter versions of category pages |
| Crawled, currently not indexed | 85 | 7% | Thin location pages; merge into one city guide |
| Discovered, currently not indexed | 25 | 2% | New posts with no internal links; link them |
| Not found (404) | 15 | 1% | Remove from sitemap, redirect where useful |
The sitemap should list only canonical, indexable URLs. Here, 255 of 1,200 sitemap entries (21%) were never meant to be indexed, which wastes crawl attention and muddies reporting; see crawl budget.
How to improve indexability
- Keep a clean sitemap of canonical, 200-status, indexable URLs only.
- Link to every important page from somewhere crawlable; shallow crawl depth helps.
- Make content available in the HTML or ensure JavaScript renders reliably; see JavaScript SEO.
- Use one signal per page: do not combine
noindexwith a canonical pointing elsewhere. - Consolidate near-duplicates and prune low-value pages; see content pruning and index bloat.
- Watch server errors, which make crawlers slow down and drop URLs.
In TapCub
TapCub's Monitoring › Crawl health report counts search-engine fetches, success rate, distinct pages, 404s and 5xx by engine. If you set a sitemap URL, it compares sitemap URLs with what crawlers actually fetched and shows how long new pages waited before each engine's first fetch, a quick way to spot pages that are not even being crawled. Status codes need server-side records (log import or server events); script-only collection cannot see them. Indexing status itself comes from the search engine, so connect Search Console for clicks and impressions by page. See log file analysis for SEO and check crawl health.
Sources
- Google Search Central. Page indexing report.
- Google Search Central. Block search indexing with noindex.
- Google Search Central. In-depth guide to how Google Search works.
Was this explanation clear?
We use your answers to fix and expand this page.
Couldn’t send. Please try again in a minute.
Thanks for the feedback. We’ll use it to improve this page.You’ve already sent feedback on this page. Thanks.
Customer Experience Consultant
Writes about live chat, visitor conversations, and self-service, sharing practical ways to make customer communication clearer and more effective.