Indexability Checker
Read pasted HTML and response headers for signals that can block or redirect indexing.
Paste source HTML, response headers, or both. No network request is made to the page URL.
Optional. Used to compare the page URL with the canonical URL.
Options
Review depth only changes optional observations. The blocking summary combines generic robots rules with rules scoped to Googlebot; crawler-specific rules for Googlebot News, Bingbot, or other bots stay scoped instead of becoming global blockers.
Output
Indexability output will appear here.
Indexable is a conclusion, not a single tag
A robots meta tag is only one part of the picture. Search engines also see the HTTP response, response headers, redirects, canonical hints, crawl permissions, rendered content, and the page itself. That is why the result above deliberately says no obvious blocker rather than promising that a URL will be indexed.
Signals that can stop the current response from being indexed
noindexin a robots meta tag or applicableX-Robots-Tagresponse header.- A redirect response, where the current URL is forwarding elsewhere instead of serving indexable content.
- Persistent
4xx,5xx, or429responses, which prevent normal indexing of the returned content. - Conflicting robots directives where a restrictive rule such as
noindexis also present.
Signals that matter without being hard blockers
A canonical URL pointing elsewhere is important because it asks search engines to consolidate duplicate signals around another URL, but Google describes canonicalization as a hint rather than a rule. Likewise, nofollow controls link following rather than page indexing, and a missing meta description does not make a page non-indexable.
Missing titles and descriptions are still worth noticing during a page review, so the expanded mode can surface them without treating them as indexing blocks.
Robots.txt can hide the very noindex rule you wanted Google to read
Robots meta rules and X-Robots-Tag rules are discovered when a crawler fetches the URL. If robots.txt prevents that crawl, the crawler may never see the page-level noindex. A pasted-source check cannot resolve that conflict because robots.txt is a separate resource.
HTTP status belongs in the same review
When response headers are included, the parser reads a conventional HTTP status line and Content-Type. A successful 2xx response can move content into later indexing systems, but success alone never guarantees indexing. Redirects and error responses change the interpretation before page-level SEO tags are considered.
Pasted source may differ from the rendered page
JavaScript can alter canonicals, robots tags, content, and navigation after the original HTML arrives. The parser reads exactly what you paste. For a JavaScript-heavy page, compare server HTML with the rendered DOM and Search Console's URL Inspection output before diagnosing an indexing problem.
What happens to the HTML and headers you paste
Parsing happens in the browser and does not intentionally transmit the pasted HTML, headers, or optional page URL to Yoryantra for analysis. The page URL field is used only as a comparison value; entering it does not fetch the page.
Primary documentation for the rules above
Google documents these behaviors in its robots meta and X-Robots-Tag specification, HTTP status guidance, and canonicalization documentation.
