Skip to main content
Yoryantra
← Back to Tools

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.
“No obvious blocker” only describes the pasted signals. Robots.txt access, redirects before this response, rendered JavaScript, canonical selection, soft 404 detection, and search-engine quality decisions still sit outside this check.

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

  • noindex in a robots meta tag or applicable X-Robots-Tag response header.
  • A redirect response, where the current URL is forwarding elsewhere instead of serving indexable content.
  • Persistent 4xx, 5xx, or 429 responses, which prevent normal indexing of the returned content.
  • Conflicting robots directives where a restrictive rule such as noindex is 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.