Skip to main content

Astle AI methodology

Evidence first. Scores second.

Astle AI combines three different kinds of evidence: a technical crawl, model-assisted interpretation and sampled AI answers. They answer different questions and should not be treated as interchangeable measures of success.

Run a free website audit

1. A bounded technical crawl

The free scan starts from a public URL and follows a bounded set of pages on the same website. It checks robots access, response behavior, page metadata, canonical links, structured information and content organization. The report states how many pages were reached; the current free limit is 50.

The crawler reads the HTML returned by the website. It is not a full browser session for every page, and content created only after client-side JavaScript runs may not appear in the evidence. Private networks, authenticated content, inaccessible URLs and pages beyond the crawl budget are outside a normal public scan.

  • A missing signal means it was not found in the captured evidence.
  • An intentional exclusion may be correct for that page's purpose.
  • A partial or failed crawl should not be interpreted as a clean bill of health.

2. Technical scores summarize checks

The SEO score combines crawlability, indexability, on-page checks, site architecture and schema checks. Technical GEO summarizes access and readability-related signals. These are Astle AI's diagnostic calculations, not scores provided by Google or an AI search company.

The underlying finding and affected URL are more useful than the total alone. A high aggregate score can coexist with a serious issue on a commercially important page. Fixes should be prioritized by business importance, evidence and scope—not just by which change increases the number fastest.

3. AI analysis adds interpretation

Signed-in deeper analysis uses extracted website evidence to infer business context, audience, differentiation and content gaps. Model outputs can be incomplete or mistaken. Confidence expresses uncertainty in an inference; it is not a verified fact about the business.

Review inferred names, audiences, competitor suggestions and recommendations against the actual product. The technical crawl works without a language-model call; model-assisted dimensions require successful analysis and available request budget.

4. Visibility is measured through API samples

Tracking submits saved questions to supported web-assisted API model configurations and retains answers and available citations. Brand matching checks the supplied name; citation matching checks the domain and its subdomains. Citation presence and brand-name presence are reported separately.

The samples do not reproduce consumer application sessions or every location and user context. Model changes, retrieval differences and nondeterminism can move results without a website change. Compare multiple runs with stable questions and inspect raw evidence before drawing a conclusion. A mention is not a conversion and a missing mention is not proof of universal absence.

5. Fixes require human review and a live recheck

Repository jobs are limited to supported source and permitted changes. The original and changed projects are built in an isolated environment before a successful draft PR is created. Dependency installation disables lifecycle scripts; managed builds restrict network access, with public Google Font hosts allowed.

A build validates one part of code correctness. It cannot verify every business claim, deployment setting or visual state. The owner reviews, merges and deploys. A rescan after a merge can still see the old website if deployment has not finished, so validate the actual public release before interpreting the result.

Start with your own website.

Run a free technical audit, inspect the evidence and choose your next step.

Run a free audit