The useful question in a website audit is not whether a site is "ready for AI." It is whether specific public signals can be fetched, parsed, and checked. Everything after that, including indexing, retrieval, citation, ranking, and action, belongs to a different layer of evidence.
MachineRead starts with this narrower question. For a submitted public URL, the Essentials audit records technical conditions related to access, discovery, and interpretation. The report exposes individual findings because a score without its observations is easy to overread.
Start with what the site publishes
Automated clients do not all receive or process a page in the same way. A browser may execute JavaScript and display a complete document even when the first HTTP response contains little more than an application shell. Google, for example, describes crawling, rendering, and indexing as separate phases, and says some JavaScript sites require rendering before their generated content is visible to Google (Google, "Understand the JavaScript SEO Basics"). That documented Google process should not be treated as a description of every crawler.
Other signals are narrower still. A robots.txt file states rules that crawlers are requested to honor, but the standard explicitly says those rules are not access authorization (Koster et al., sec. 1). A sitemap can present URLs for discovery, but Google calls sitemap submission a hint and does not guarantee that it will use the file to crawl those URLs (Google, "Build and Submit a Sitemap"). These files matter because they express inspectable intent, not because their presence determines what happens later.
MachineRead therefore tests the representation and declarations a site actually publishes, then describes only what those tests support.
Two views of the same public surface
Essentials evaluates 13 included check groups with a current maximum of 56 checked points. The groups cover public signals such as the initial HTML response, crawler directives, canonical metadata, sitemaps, structured data, and machine-readable discovery files. MachineRead checks llms.txt in the general audit. When API or protocol scope is active, it also checks ai-catalog.json, api-catalog.json, and openapi.json.
The report also includes a stricter agent-readiness view. Its 8 default probes form the default scope; the full methodology describes 21 probes when all applicable scope options are enabled. This view keeps explicit agent-facing and protocol signals legible without changing the 13-group, 56-point Essentials contract.
The two summaries answer related but different questions. The Essentials score condenses the included evidence. The strict view isolates a smaller set of agent-oriented observations. Neither is a probability that a model will mention the site.
Nine advanced rows are displayed as locked coverage areas. They show the shape of coverage that did not run. A locked row is not a failed live test, and MachineRead does not fill missing evidence with an inferred result.
Read findings before scores
Start with findings that change what later evidence means. If a plain request is denied or the returned HTML lacks the expected public content, well-formed metadata elsewhere may have limited value to that requesting client. Check the response status, headers, and body first. Then inspect directives and discovery files. Finally, review whether metadata agrees with the visible page.
That order also keeps remediation proportional. A malformed canonical has a different fix from an intentional crawler block. The audit supplies evidence and context; the site owner decides whether a finding conflicts with the site's actual publishing policy.
MachineRead is deliberately not a full-site crawler, a browser task runner, or a content judge. It runs specific checks against a public target. The methodology reference documents the checks and scoring, while the agent integration guide describes the public machine-readable interfaces.
What this check can and cannot establish
The audit can establish that the tested URL and related public resources returned particular responses at audit time. It can report whether the inspected signals were present, parseable, internally coherent, and consistent with each check's documented criteria.
It cannot establish that an untested URL behaves the same way, that every crawler will honor or interpret a signal alike, or that a search engine or model will index, retrieve, cite, rank, or act on the site. It also cannot replace a full crawl, rendered-browser testing, log analysis, or provider-specific verification.
Works Cited
Google. "Build and Submit a Sitemap." Google Search Central, updated 8 July 2026, https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap. Accessed 7 Aug. 2026.
Google. "Understand the JavaScript SEO Basics." Google Search Central, updated 4 Mar. 2026, https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics. Accessed 7 Aug. 2026.
Koster, Martijn, et al. "Robots Exclusion Protocol." RFC 9309, Internet Engineering Task Force, Sept. 2022, RFC Editor, https://www.rfc-editor.org/rfc/rfc9309.html. Accessed 7 Aug. 2026.
See also
- Methodology reference - definitions, weights, and evidence boundaries
- Why agents need to read your site - why access is a prerequisite rather than an outcome
- Public audit interface - accepts a URL for the checks described above