Skip to content

Blog

How to audit AI crawler access to your website

Mike Holp · Published · Updated · 5 min read

How to audit AI crawler access to your website starts with a route inventory, not a blanket allow rule. Identify the public pages you want discovered, inspect robots.txt and meta robots directives, fetch representative URLs, and keep private application routes protected. This guide is for site owners and marketers who want answer-engine discovery without exposing dashboards or user data.

Short answer: List public and private route groups, check robots.txt for the crawlers relevant to your goals, verify that public pages return a successful response without login, and inspect the rendered HTML for noindex directives. Allow access only where the content is intentionally public. Crawler access improves retrievability; it does not guarantee a citation.

What an AI crawler audit should prove

A useful audit answers four separate questions:

QuestionEvidence
Can the crawler reach the host?DNS, TLS, response status, and timeout
Is the route allowed?Matching robots.txt group and disallow rules
Is the page indexable?No accidental noindex, login wall, or canonical conflict
Is the content useful?Rendered text, entity clarity, and source links

Do not collapse these into one “AI-ready” badge. A page can be allowed by robots.txt but return a 404, render no meaningful text, or be marked noindex. Google's guidance says pages must meet normal Search technical requirements to be eligible for AI Overviews or AI Mode; there is no separate AI markup requirement (Google AI features).

Step 1: Inventory public and private routes

Make two lists before changing crawler policy. Public routes may include documentation, articles, pricing, and service pages. Private routes usually include account, reports, checkout, API, admin, and customer data paths.

Start with a table:

Route groupIntended audienceCrawler policyTest URL
/blog/Public readersAllowOne current article
/docs/Public developersAllowOne reference page
/dashboard/Authenticated usersBlockLogin redirect
/api/ApplicationsBlockOne endpoint
/reports/Customer dataBlockOne report URL

Use the narrowest path rule that expresses your intent. A host-wide block can hide useful public content; a host-wide allow can expose routes that require authentication.

Step 2: Read robots.txt as a crawler would

Fetch the live /robots.txt file and inspect each user-agent group. A rule applies according to the crawler's matching group and the most specific applicable path. Check the names documented by the provider whose discovery surface you care about, rather than assuming every bot uses the same policy.

OpenAI documents separate crawler purposes for search discovery and training. If ChatGPT search visibility is the goal, review the policy for OAI-SearchBot; GPTBot is a separate publishing decision (OpenAI bot documentation). Keep sensitive paths blocked in every relevant group.

Robots.txt is not an access-control system. Private data still needs authentication and authorization. Never rely on a disallow line to protect customer information.

Step 3: Check page-level indexability

For one URL in each route group, inspect:

  • HTTP status and redirect chain;
  • X-Robots-Tag response header;
  • HTML meta name="robots";
  • canonical URL;
  • visible title and main text;
  • structured data in the rendered document;
  • links to login or consent walls.

A public page should not accidentally inherit noindex from a shared layout. A canonical should resolve to the page's preferred public URL. If JavaScript adds important text or JSON-LD, test the rendered output as well as the initial response.

Step 4: Verify the route from outside your network

Test a public page from a clean environment and record the date, URL, status, response time, and final URL. Repeat a private route to confirm it does not leak content through an alternate hostname or redirect.

A minimal audit receipt includes:

  1. URL tested.
  2. User agent or tool used.
  3. Timestamp.
  4. Status and redirect chain.
  5. Robots decision.
  6. Indexability decision.
  7. Notes about visible content.

The VisiScan AI crawler checker can provide a quick route-level check. Use provider documentation and your own security controls for the final policy.

Common mistakes

Blocking every AI crawler

A blanket block may also block a search-discovery crawler you intended to allow. Decide separately for search, training, and private application routes.

Allowing a bot but exposing an app

Crawler rules do not bypass authentication safely. Keep authorization checks on every account, report, API, and checkout route.

Testing only robots.txt

Robots policy cannot prove that a page is live, indexable, canonical, or useful. Pair it with a real fetch and rendered-page inspection.

Assuming access equals citation

Retrieval systems decide what to use and cite. A successful fetch is a prerequisite signal, not a ranking result.

FAQ

Should I allow AI crawlers on my business website?

Allow documented search-discovery crawlers when you want public pages considered, and block private routes. Decide separately whether you permit training crawlers. Review the policy whenever a provider changes crawler names or purposes.

Does robots.txt control indexing?

Robots.txt controls crawl access, not guaranteed indexing. A blocked URL may still be known to a search engine, and an allowed URL can remain unindexed for many reasons. Use page-level directives and Search Console for indexability checks.

How often should crawler access be audited?

Audit after a robots, framework, domain, or deployment change, then include representative public and private routes in a recurring technical check. The cadence should follow how often your routing and security policy changes.

Conclusion

To audit AI crawler access to your website, map route intent, inspect robots and page directives, fetch representative URLs, and preserve a dated receipt. Keep public discovery separate from private-data protection, and treat access as one part of SEO readiness. Start with the AI crawler checker, then verify the live policy in your own infrastructure.

Sources

Keep going

Turn the ideas in this article into a measurable baseline for your own site.