A page can be technically accessible to visitors but still send signals that prevent or discourage search indexing. An indexability review checks the response status, robots directives, canonical URL and other page-level signals before you spend time changing content.
Use the Page Indexability Checker to inspect a public URL for common blockers.
Start with the HTTP status
A normal indexable page should usually return a successful response. Redirects, 404 responses and server errors tell search engines that the requested URL is not a standard content page. Fixing the underlying status is often more important than changing meta tags.
Check robots meta and X-Robots-Tag
A page can include a noindex directive in HTML or in an HTTP header. Either can instruct search engines not to include the page in search results. When troubleshooting, inspect both sources rather than assuming the HTML head contains every directive.
Review the canonical URL
A canonical link suggests which URL should represent a set of duplicate or near-duplicate pages. A canonical pointing somewhere else is not exactly the same as noindex, but it can cause Google to prefer another URL. Confirm that the canonical matches the page you actually want indexed.
Robots.txt and indexing are different
A robots.txt rule controls crawling, not indexing in every situation. Blocking a URL from crawling can even prevent a search engine from seeing a noindex directive on that page. Use robots.txt to manage crawl access, not as a substitute for page-level index control.
Other reasons a page may remain unindexed
- The page is new and has not been crawled yet.
- Google considers another URL a better canonical.
- The page has very little unique value or duplicates other pages.
- Internal links make the page difficult to discover.
- The server is unstable or slow during crawling.
Worked example: a public page with a noindex directive
This illustrative example shows how to interpret conflicting signals; it is not a live test result. Suppose a page returns HTTP 200, has a canonical pointing to itself, and contains <meta name="robots" content="noindex, follow">. The page loads successfully, but the noindex directive still tells supporting search engines to exclude it. A successful response and a self-referencing canonical do not cancel that instruction.
- Confirm that the page is intended to appear in search. Private or internal pages may deliberately use noindex.
- If it should be indexed, inspect the page’s SEO settings and the HTTP X-Robots-Tag header. Remove only the unintended noindex instruction.
- Clear the relevant page cache, then run the checker again on the exact public URL.
- Use Google Search Console URL Inspection to check the live URL and, where appropriate, request indexing. A request does not guarantee inclusion.
Match the finding to the next action
| Finding | What to check next |
|---|---|
| Redirect response | Inspect the final destination. Link internally to the intended destination rather than an obsolete URL. |
| HTTP 404 | Check the address. Restore content only if the page should exist; do not redirect every missing page to the homepage. |
| Canonical points elsewhere | Decide whether the two pages are duplicates. Keep the canonical if the other URL is the intended representative. |
| No obvious blocker | Review discovery, content quality and Google’s selected canonical in Search Console. Technical accessibility alone is not proof of indexing. |
Google explains why a crawler must be allowed to fetch a page to see its noindex instruction in its noindex documentation.
A clean technical result is not a guarantee
Passing technical indexability checks means obvious blockers were not detected. Search engines still decide whether and when to index a page. Use the UptimeFixer Indexability Checker for the page-level review, then confirm important URLs in Google Search Console.