Learning Path
Navigate the AXO curriculum
Websites
Website Deep Dives
AXO Worked Examples
Three before/after transformations showing exactly what changes when AXO techniques are applied to a product page, an API reference, and an editorial article.
What these are, and what they are not
These are constructed teaching examples, not client work. We wrote both the “before” and the “after” to isolate a specific technique and show what it does to the markup. No company implemented these, and we are not attaching citation-lift percentages to them.
That is deliberate. Credible before/after measurement for AI citations requires holding everything else constant across a large page set, and almost no published figure in this field does. A page that teaches sourcing discipline should not lead with numbers it cannot source. What each example gives you instead is the mechanism: what an agent could not determine from the original, and what the revision makes explicit.
Example 1: E-commerce Product Documentation
A product page rewritten so a shopping agent can compare it against alternatives
Before Optimization
Issues Identified:
- • No structured data markup
- • Generic product descriptions
- • Missing technical specifications
- • No clear pricing information
- • Poor heading structure
<div class="product"> <h2>Amazing Wireless Headphones</h2> <p>Experience incredible sound quality with our premium wireless headphones. Perfect for music lovers!</p> <div class="price">$199.99</div> </div>
After Optimization
Improvements Made:
- • Added Product schema markup
- • Named model and specifications
- • Explicit price, currency, and availability
- • Proper heading hierarchy
- • Machine-readable identifiers (SKU, brand)
<article itemscope itemtype="https://schema.org/Product">
<h1 itemprop="name">Northwind Studio 500 Wireless Noise-Cancelling Headphones</h1>
<meta itemprop="sku" content="NW-STU500-BLK" />
<div itemprop="brand" itemscope itemtype="https://schema.org/Brand">
<meta itemprop="name" content="Northwind Audio" />
</div>
<p itemprop="description">
Over-ear wireless headphones with adaptive noise cancellation,
40-hour battery life, multipoint pairing to two devices, and
lossless playback over USB-C.
</p>
<div itemprop="offers" itemscope itemtype="https://schema.org/Offer">
<span itemprop="price" content="199.99">$199.99</span>
<meta itemprop="priceCurrency" content="USD" />
<link itemprop="availability" href="https://schema.org/InStock" />
<meta itemprop="priceValidUntil" content="2026-12-31" />
</div>
</article>Microdata is used here so the before and after sit in the same markup. JSON-LD in a script tag is the preferred delivery format in production.
What the transformation actually does
An agent asked to “find noise-cancelling headphones under $250 with at least 30 hours of battery” cannot answer from the “before” version. Nothing in it is a comparable value: “Amazing Wireless Headphones” is not a model, “incredible sound quality” is not a specification, and $199.99 in a styled div is a string, not a price with a currency and a validity window.
- • Identity: a specific model name and SKU let an agent match this page to the same product elsewhere
- • Comparability: battery life, pairing, and connection type are now filterable attributes rather than adjectives
- • Transactability: price, currency, and availability are the minimum an agent needs to act rather than merely describe
Example 2: API Documentation
A developer reference rewritten so an agent can produce a working call from it
Before Optimization
Documentation Issues:
- • Scattered endpoint information
- • Inconsistent example formats
- • Missing error code documentation
- • No machine-readable API spec
- • Vague parameter descriptions
## User API Get user information by sending a request to our user endpoint. Returns user data in JSON format. Example: GET /api/user
After Optimization
Improvements Made:
- • OpenAPI 3.0 specification
- • Detailed parameter descriptions
- • Complete example requests/responses
- • Error code documentation
- • Rate limiting information
## GET /api/v1/users/{userId}
Retrieves detailed information for a specific user account.
Requires a bearer token with the `users:read` scope.
### Parameters
- userId (string, required): Unique user identifier (UUID format)
### Response (200 OK)
{
"id": "550e8400-e29b-41d4-a716-446655440000",
"email": "user@example.com",
"created_at": "2026-01-15T10:30:00Z"
}
### Error Codes
- 401: Authentication required or token expired
- 403: Token lacks the users:read scope
- 404: User not found
### Rate Limit
120 requests per minute per token.What the transformation actually does
The test for API documentation is not whether it reads well. It is whether an agent that has read only this page can write a call that succeeds, and can interpret the response when it fails. The “before” version fails that test on every axis: the path is incomplete, the parameter is unnamed, the response shape is unspecified, and there is no version.
- • Versioned, complete paths stop an agent from confidently generating an endpoint that never existed
- • Typed parameters with formats (“string, required, UUID”) remove guesswork that otherwise becomes a runtime error
- • Literal response bodies give the agent field names to reference instead of inventing plausible ones
- • Enumerated error codes are what let an agent recover rather than retry blindly
- • Stated rate limits keep automated consumption inside bounds you chose
Example 3: Editorial Article
A marketing-led article rewritten into something quotable
Before: Marketing-Heavy Content
- • “Revolutionary new approach to learning”
- • “Game-changing methodology”
- • Vague benefit statements
- • No named sources or dates
- • Poor heading structure
After: Fact-Based Content
- • Claims stated plainly, each traceable to a named, dated, linked source
- • Step-by-step implementation guides
- • Scope and limitations made explicit
- • Concrete worked examples
- • Clear H1–H6 hierarchy
Content Structure Transformation
Before Structure:
After Structure:
What the transformation actually does
Superlatives are unquotable. An answer engine building a response cannot lift “revolutionary new approach” into a sourced answer, because there is no proposition in it to attribute. The revision’s value is that every paragraph contains something an engine could quote and credit.
- • Specific titles match the way people actually phrase questions
- • Named, dated sources let a system verify a claim instead of deciding whether to trust an anonymous assertion
- • Self-contained sections survive extraction; a paragraph that depends on three earlier ones does not
- • Visible bylines and dates are among the few authority signals a machine can read directly
One caution the “after” column is deliberately making: replacing vague claims with invented precision is worse than the original. A statistic without a source is not fact-based content — it is marketing copy wearing a number. If you cannot cite it, make the point without it.
Patterns Across All Three
Structure First
Every “after” version is easier to extract from in isolation. Heading hierarchy and semantic markup are what make a fragment stand on its own.
Specificity Wins
Named models, typed parameters, and cited claims replace adjectives. Specific and sourced, not specific and invented.
Make Machines Not Guess
Currency, format, version, scope, date. Each one is an assumption an agent would otherwise have to invent.