Self Audit

The complete Codex audit report for aeocodex.com — run using the same methodology and pipeline we apply to every client engagement. This page is both the report and the evidence.

Audit Summary

Domain audited
aeocodex.com
URLs in scope
1 — homepage only at time of publication
Audit date
Methodology
The Codex v1.0 — Playwright AX tree extraction across four rendering states, LLM-assisted semantic classification, deterministic scoring
Overall score
100 / 100
Grade
A
Critical findings
0
Moderate findings
0
Minor findings
0

How The Codex Audit Works

The Codex pipeline runs in five stages. Each stage is automated. The output of each stage feeds the next.

  1. AX Tree Extraction. Playwright navigates to each URL in scope and extracts the full Accessibility Tree via Chrome DevTools Protocol across four rendering states: initial page load, post-scroll to trigger lazy-loaded content, post-interaction to expose dynamic state changes, and mobile viewport at 390 by 844 pixels.
  2. Structured Data Extraction. All JSON-LD blocks in the page head are extracted and parsed. The llms.txt file is checked at the site root.
  3. LLM Classification. The flattened accessibility tree, structured data, and llms.txt status are sent to a language model with a constrained prompt. The model returns only a typed JSON array of findings from the ten-type taxonomy. No prose, no explanation — structured output only.
  4. Recommendation Generation. Each finding is sent individually to a second model call that returns a three-sentence developer-readable fix: what the problem is, how to fix it, and how to verify the fix worked.
  5. Scoring. Findings are scored deterministically using a fixed deduction table with no model involvement. Critical findings deduct 20 points. Moderate findings deduct 10 points. Minor findings deduct 3 points. The floor is zero.

Rendering States

The Codex extracts the Accessibility Tree across four rendering states because semantic failures are often state-specific. An element correctly named on initial load may lose its accessible name when a user interaction changes the DOM.

Initial State

The page immediately after load, waiting for network idle. Missing ARIA roles on static elements, absent JSON-LD, and structural heading failures are captured here.

Post-Scroll State

After scrolling to trigger IntersectionObserver-based lazy loading. Lazy-loaded product grids and infinite scroll elements invisible to agents on initial load are captured here.

Post-Interaction State

After clicking the first interactive element and waiting for DOM settlement. Dynamic ARIA label removals on interaction, modal state trees, and variant selector failures are captured here.

Mobile Viewport State

At 390 by 844 pixels with a mobile user agent string. Responsive layout ARIA degradation — elements correctly named on desktop but losing their accessible names in mobile layout — is captured here.

Finding Types — Definitions and Results

missing_accessible_name — Pass

Definition. An interactive element has no machine-readable accessible name. An agent cannot determine what the element does.

Severity. Critical.

Result. Pass. All interactive elements have accessible names in all four rendering states.

wrong_element_type — Pass

Definition. An interactive control is implemented using a non-semantic element — a div or span with a click handler instead of a button.

Severity. Critical.

Result. Pass. Every interactive element uses the correct native HTML element.

jsonld_missing — Pass

Definition. The page contains no JSON-LD structured data block in the head.

Severity. Moderate.

Result. Pass. One JSON-LD block with a complete @graph is present in the page head.

jsonld_stale — Pass

Definition. The JSON-LD references entities or values that do not correspond to visible content on the page.

Severity. Moderate.

Result. Pass. All values in the JSON-LD correspond to content visible on the page.

schema_availability_missing — Pass

Definition. A product or offer is described in structured data but no availability property is declared.

Severity. Moderate.

Result. Pass. All Offer nodes declare availability as schema:InStock.

schema_product_id_missing — Pass

Definition. A product is described in structured data without a unique identifier.

Severity. Moderate.

Result. Pass. AEO Codex offers are services identified by name and URL. No physical product identifier is applicable.

policy_not_machine_readable — Pass

Definition. Return policies, shipping terms, or warranty information exist only as PDF files or images.

Severity. Moderate.

Result. Pass. All policy-adjacent content is in parseable HTML text. No PDF links are present.

form_labels_absent — Pass

Definition. Form inputs exist without programmatically associated labels.

Severity. Moderate.

Result. Pass. This page contains no form elements at publication time.

llms_txt_missing — Pass

Definition. No llms.txt file exists at the site root.

Severity. Minor.

Result. Pass. An llms.txt file is present at /llms.txt and returns HTTP 200.

schema_price_mismatch — Pass

Definition. A price visible on the page differs from the price declared in the JSON-LD structured data.

Severity. Minor at small deviations, Critical above five percent.

Result. Pass. All prices in JSON-LD exactly match the prices in visible page content.

Score Calculation

Starting score
100
Critical finding deduction
20 points each — 0 findings — 0 points deducted
Moderate finding deduction
10 points each — 0 findings — 0 points deducted
Minor finding deduction
3 points each — 0 findings — 0 points deducted
Final score
100 / 100
Grade
A — score 90 or above

Verification

Every claim in this report is verifiable independently without contacting AEO Codex.

  1. Open your browser's developer tools on this page. Navigate to the Accessibility panel. Confirm every interactive element has an accessible name.
  2. View the page source. Find the script tag with type application/ld+json. Paste the contents into the Google Rich Results Test. Confirm it validates without errors.
  3. Request /llms.txt and confirm HTTP 200.
  4. Request /.well-known/veracity.json and confirm the assertions match the claims on this page.

The audit is the product. The product is the proof.