AstraVerify Domain Trust Check

Quality 72 / 100needs work

5 tools, about 2,173 tokens to load them all · tool set 590c978ecc8b · tools last changed 2026-10-15 · checked 2026-10-19 10:52 UTC

Tool changes

• 2026-10-15fetch_as_crawlerchangeddescription
  before

  Show exactly what one named crawler receives from the domain's root page. Use when the person asks "what does Google see?" or "can ChatGPT read my site?", and whenever check_discoverability reports a crawl-access problem - this is the tool that explains such a result instead of restating it. robots.txt can read perfectly while a CDN or firewall returns 403 to one crawler and 200 to another, and only a real fetch shows that. Inputs: domain (bare, like example.com) and agent, exactly one of googlebot, bingbot, oai-searchbot, perplexitybot, claudebot, gptbot. Call it once per crawler to compare them. Returns the HTTP status, the full redirect chain, response headers, content type, the text that crawler would index, and flags for an outright block or a bot-challenge page - which is how cloaking becomes visible. One live fetch of the root page, nothing else, and it changes nothing.

  after · 90% of words in common

  Show exactly what one named crawler receives from the domain's root page. Use when the person asks "what does Google see?" or "can ChatGPT read my site?", and whenever check_discoverability reports a crawl-access problem. check_discoverability scores crawl access across all six crawlers; this returns the one raw response behind that score, which is what explains such a result rather than restating it. robots.txt can read perfectly while a CDN or firewall returns 403 to one crawler and 200 to another, and only a real fetch shows that. Inputs: domain (bare, like example.com) and agent, exactly one of googlebot, bingbot, oai-searchbot, perplexitybot, claudebot, gptbot. Call it once per crawler to compare them. Returns the HTTP status, the full redirect chain, response headers, content type, the text that crawler would index, and flags for an outright block or a bot-challenge page - which is how cloaking becomes visible. One live fetch of the root page, nothing else, and it changes nothing.

• 2026-10-15get_reportchangeddescription, input schema, output schema
  before

  Both AstraVerify scores for a domain, plus a shareable report link. Reach for this first on any broad question - "is my domain set up right?", "check my domain", "what should I fix first?" - and use the single-subject tools only once the person has narrowed it to email or to the website. Input: a bare domain like example.com. Returns the Email Security score, the Discoverability score, every open fix ranked critical then important then informational, and report_url. Work down that order. Some findings are marked as needing no action - a weak key the provider generates and the owner cannot replace, for instance - so do not present those as work. Unlike the other tools here, this one creates something: report_url is a snapshot of these findings saved to a new unlisted page at astraverify.com/r/..., and that page is what the person can send to whoever administers the domain. It opens later without rescanning, after the scan itself has aged out. Running the tool again on an unchanged scan returns the same page rather than a second one. Nothing is written anywhere the person owns.

  after · 84% of words in common

  Both AstraVerify scores for a domain, plus a shareable report link. Reach for this first on any broad question - "is my domain set up right?", "check my domain", "what should I fix first?" - and use the single-subject tools only once the person has narrowed it to email or to the website. Input: a bare domain like example.com. Returns the Email Security score, the Discoverability score, every open fix ranked critical then important then informational, and report_url. Work down that order. Some findings are marked as needing no action - a weak key the provider generates and the owner cannot replace, for instance - so do not present those as work. Unlike the other tools here, this one creates something: report_url is a snapshot of these findings saved to a new unlisted page at astraverify.com/r/..., and that page is what the person can send to whoever administers the domain. It opens later without rescanning, after the scan itself has aged out. Running the tool again on an unchanged scan returns the same page rather than a second one. Nothing is written anywhere the person owns. Set include_history to answer "has this improved?" or "did my fix land?": it adds the first and latest reading of each score, the move between them, and only the dates the score actually changed. A domain we have not watched before says so rather than reporting a flat line.

• 2026-10-15check_discoverabilitychangeddescription
  before

  Check whether search engines and AI assistants can crawl, read and quote this site. Use when the person asks about SEO basics, robots.txt, sitemaps, llms.txt, or whether Google, ChatGPT, Claude or Perplexity can see their site. Input: a bare domain like example.com. Returns a Discoverability score 0-100 broken into crawl access (25: robots.txt, plus what the edge actually serves to Googlebot, Bingbot, OAI-SearchBot, PerplexityBot, ClaudeBot and GPTBot), site plumbing (20: HTTPS, one canonical host, sitemap, real 404s), page metadata (20), structured data (20) and answer-engine readiness (15: llms.txt, a definitional opening, question-form headings). Every finding carries the exact file, tag or record to publish. It makes roughly 15 fetches over a few seconds - robots.txt, the sitemap, the root page, up to four pages listed in the sitemap, llms.txt, the preview image, one deliberately missing URL to see how 404s are handled, and the root page once as each of the six crawlers. It identifies itself as AstraVerifyBot, except on those six checks, where the point is to send the crawler's own user-agent. It fetches nothing off that domain and crawls no further. Cached 15 minutes. It changes nothing on the site. This is a separate scan from check_email_security and does not include it.

  after · 90% of words in common

  Check whether search engines and AI assistants can crawl, read and quote this site. Use when the person asks about SEO basics, robots.txt, sitemaps, llms.txt, or whether Google, ChatGPT, Claude or Perplexity can see their site. Input: a bare domain like example.com. Returns a Discoverability score 0-100 broken into crawl access (25: robots.txt, plus what the edge actually serves to Googlebot, Bingbot, OAI-SearchBot, PerplexityBot, ClaudeBot and GPTBot), site plumbing (20: HTTPS, one canonical host, sitemap, real 404s), page metadata (20), structured data (20) and answer-engine readiness (15: llms.txt, a definitional opening, question-form headings). Every finding carries the exact file, tag or record to publish. It makes roughly 15 fetches over a few seconds - robots.txt, the sitemap, the root page, up to four pages listed in the sitemap, llms.txt, the preview image, one deliberately missing URL to see how 404s are handled, and the root page once as each of the six crawlers. It identifies itself as AstraVerifyBot, except on those six checks, where the point is to send the crawler's own user-agent. It fetches nothing off that domain and crawls no further. Cached 15 minutes. It changes nothing on the site. This is a separate scan from check_email_security and does not include it. It scores crawl access across all six crawlers at once; for the exact response a single named crawler receives - status, redirect chain, headers, the text it would index - use fetch_as_crawler.

• 2026-10-10verify_fixchangedoutput schema
• 2026-10-10get_reportchangedoutput schema
• 2026-10-10check_discoverabilitychangedoutput schema
• 2026-10-09verify_fixchangedoutput schema
• 2026-10-09get_reportchangedoutput schema
• 2026-10-09check_discoverabilitychangedoutput schema
• 2026-10-09verify_fixchangeddescriptionmeaning changed
  before

  Re-runs only the checks behind one component (crawl, plumbing, metadata, structured, answer) and returns the updated score.

  after · 14% of words in common

  Re-check a single discoverability component after the person has fixed it. Use only once check_discoverability has reported that component failing and the person says the fix is done - never speculatively. Without a previous scan to compare against it returns NOT_READY. Inputs: domain (bare, like example.com) and component, one of crawl, plumbing, metadata, structured, answer - the identifier from the earlier scan's findings. Returns that component re-measured and the updated Discoverability score, so you can tell the person plainly whether the change worked. Always a live re-fetch, never served from cache, which is exactly why it beats a second check_discoverability straight after an edit. It draws on the discoverability fresh-scan budget for that domain (30 an hour, counted across all callers), so use a full check_discoverability instead when several areas changed. It only re-reads public pages; it changes nothing on the site.

Showing the latest 10. Full history: list_changes · trend: quality JSON.

Checks run on what our credential-free, read-only probes observe; tools are never called and no code audit is performed. How it is computed.