← All workflows

Debug indexability

Enter the signals you already observed. The workflow identifies the first technical blocker and explains what the result does not prove.

  1. 1Enter signals
  2. 2Read the conflict
  3. 3Verify live
Local evidence parser.Paste response evidence or set each signal manually. No URL is fetched.

Paste the evidence you already collected

Copy a final header block, the rendered HTML head, and the relevant robots.txt. The parser fills the signal controls below.

Nothing is sent or saved.

Signals you observed

Use the final response and rendered directives, not assumptions from a template.

Technical verdict

Technically eligible

Diagnosis updates as signals change.

Indexability recipeSave or reload the rules. Input and output are never included.
Recipe preflight

Review the saved mappings

    Indexability run manifestDownload settings, counts, and SHA-256 receipts for this run. Raw input and output stay out of the file.
    Many URLs, one evidence model.Map a crawler export once, then preserve every technical group and its reason.
    Batch mode

    Classify a crawler export

    Load a CSV or TSV, map the evidence columns, and group every URL without claiming that it is indexed.

    Map the URL and status columns, then classify the rows.

    Indexability groups from supplied evidence
    URLGroupReason

    “Technically eligible” means only that the supplied columns did not contain a technical exclusion. It is not proof of Google indexing, canonical selection, ranking, or traffic.

    Four URLs, four different technical groups.

    The synthetic crawler export includes one technically eligible page, one noindex page, one robots/noindex conflict, and one canonical pointing elsewhere.

    The expected file records only the supplied technical evidence. It does not claim that any URL is indexed.

    Use this workflow when…

    • A page is missing from search and you need to separate eligibility from ranking.
    • Canonical, robots.txt, and noindex signals appear to contradict one another.
    • You need a concise diagnosis before opening a crawler or Search Console.

    Read the signals in this order

    Later signals cannot repair a response that is not an indexable document.

    1. 1
      Response

      Confirm that the tested URL returns the final 200 document rather than a redirect or error.

    2. 2
      Crawl access

      A blocked crawler may not see changed directives on the page.

    3. 3
      Index directives

      Check both rendered meta robots and the final HTTP X-Robots-Tag.

    4. 4
      Canonical

      A canonical is a consolidation signal, not a command or an indexing guarantee.

    “Technically eligible” does not mean indexed, ranking, or selected as canonical. Search demand, quality, duplication, discovery, and search-engine processing remain outside this local check.

    Common conflicts

    The workflow calls these out because a single green signal can be misleading.

    SignalsWhat it meansNext check
    200 + noindexCrawlable document, not eligibleFind the directive source
    robots blocked + noindexCrawler may not see the noindexAllow crawl before relying on removal
    200 + canonical elsewhereSignals request consolidationCompare content and internal links
    redirect + self-canonicalCanonical on the old response is irrelevantInspect the final destination

    Where the result can go

    Download the result first. It stays useful without another product.

    1Keep the file

    Copy or download the cleaned output and use it in any compatible workflow.

    2Fetch the live page

    AnalyseSpider can request one public URL and show the response and directives it actually receives.

    Check one live URLDevAwesome and AnalyseSpider are operated by Matthias Ramahi. This is a related workflow handoff, not an independent recommendation.