Free checklist · public repositories
Prove your storefront is agent-ready.
A storefront can expose llms.txt, Product JSON-LD,
feeds, and machine-readable pages—and still disagree with
itself. Map every claim to a public artifact, a source of
truth, and a regression check before calling the work done.
No login · No form submission · No live-site crawl · Public repository evidence only
- Discovery
- llms.txt
- Catalog semantics
- JSON-LD
- Projection parity
- feeds
- Regression protection
- CI
illustrative not an audit result
Two-minute browser-local check
Count the evidence you can point to today.
Check only what a reviewer could verify in one public repository at one immutable revision. This self-check does not inspect your repository and is not an audit result or checkout eligibility decision.
Discovery baseline missing
Start with the free repository preflight and the seven evidence checks below. Missing evidence is useful scope—not a failed grade.
Nothing is uploaded, stored, or sent to WrightOps. Your selections stay only in this open browser tab and disappear when you reset or leave the page.
Seven public-evidence checks
Start with the source of truth, not the output format.
Passing means the public repository shows how the output is produced and how drift is caught. A live URL or a valid-looking JSON block by itself is not enough.
Discovery has an owner
Identify the code or template that emits
/llms.txt, the XML sitemap, and any catalog-feed
index. Record store-view and locale behavior instead of
assuming one global file.
Machine-readable pages are deterministic
Document whether product and category content is rendered as Markdown, negotiated content, or another stable projection. Name exact routes, media types, and fallback behavior.
Product semantics use real catalog data
Map Product and Offer fields—name, description, image, SKU or identifiers, brand, price, currency, availability, and condition—to their real catalog sources. Omit unavailable facts rather than fabricating them.
Optional commerce claims stay conditional
Reviews, ratings, shipping details, return policies, and price-validity dates should appear only when current source data supports them. Empty defaults are not evidence.
Every projection agrees
Compare visible HTML, JSON-LD, machine-readable content, and product feeds for the same fixture. Price, currency, availability, identifiers, canonical URL, and locale should not contradict one another.
Localization is explicit
Show how store views, language, currency, canonical URLs, and alternate links affect every projection. A default-locale success does not prove multi-store behavior.
Regression checks protect the claim
Use representative catalog fixtures and assertions for required fields, conditional fields, locale behavior, and cross-projection parity. Pin the evidence to an immutable repository revision.
-
01
Claim
Write the exact behavior a maintainer or agent should be able to rely on.
-
02
Authoritative source
Name the catalog field, configuration, or committed content that owns the fact.
-
03
Generated projection
Point to the template, serializer, route, or feed builder that publishes the fact.
-
04
Acceptance check
Show the fixture and deterministic assertion that fails when the projection drifts.
Use the checklist in scope
Turn a broad commerce goal into a reviewable repository question.
-
01
Name one public repository and revision
Keep the evidence review reproducible and separate from a changing live storefront.
-
02
Choose the failing evidence layer
Discovery, catalog semantics, projection parity, localization, or regression protection.
-
03
Point to the expected source of truth
Do not ask an auditor to infer catalog authority from rendered output alone.
-
04
Define an executable acceptance signal
Prefer a fixture-backed check over a screenshot, score, or unsupported completeness claim.
The boundary is part of the checklist
Repository evidence—not a live-store certification.
This guide does not crawl, validate, or monitor a production storefront. It does not assess vulnerabilities, security, privacy, legal duties, regulatory compliance, or platform eligibility, and it does not guarantee indexing, ranking, agent ingestion, traffic, sales, or revenue.
Read the complete audit terms- ✓ One public GitHub repository
- ✓ One immutable revision
- ✓ Public source and test evidence
- × No private code, credentials, or customer data
- × No live-site crawling or production access
- × No fabricated reviews, policies, or catalog facts
- × No ranking, adoption, traffic, or revenue guarantee
Direct answers
Before you use the checklist.
Does adding llms.txt make a storefront agent-ready?
No. It is one discovery surface. The referenced machine-readable content, catalog semantics, and cross-projection evidence still need to be truthful and testable.
Should every optional Product field be emitted?
No. Emit a field only when current catalog data supports it. Missing evidence should stay missing rather than becoming an invented rating, policy, identifier, or date.
Does the $750 audit certify a live storefront?
No. The fixed service reviews one public GitHub repository at one immutable revision and delivers evidence-linked findings. Live-site testing, implementation, certification, and ongoing monitoring are excluded.
Does opening a scope request create a contract?
No. WrightOps confirms the exact written scope before sharing the authorized PayPal Business checkout. Paid work begins only after provider-confirmed settlement.
One repository · one revision · inspectable proof
Use the checklist to name the evidence gap.
Need only the next three fixes? Complete the WrightOps free audit, then the $149 Fix Plan checks matching public evidence and buyer acknowledgements in your browser before revealing the existing PayPal Business checkout. No mailbox is required for that gated purchase path. Choose the $750 human-reviewed audit only when its broader scope matches the work.