carbon38.com
Audited 6 days ago· shopify
Agent-readiness across all five AI commerce surfaces.
Surfaces — click to filter
9 failing · 5 not checked · 14 shown
5 checks couldn't run on this store — each is listed below with the reason. Your score reflects only what we could verify.
Enforce HTTPS sitewide and ship a Strict-Transport-Security header with max-age ≥ 6 months
Why this matters: AI agents and payment flows refuse plain HTTP; weak HSTS is treated as effectively no HSTS by trust-and-safety scanners.
Findings (1)
Confirmed the homepage is HTTPS (status 200), probed http://carbon38.com/ for redirect behaviour, and parsed the Strict-Transport-Security header (value: "max-age=7889238").
How: URL scheme + homepage status check, an http://host/ redirect probe through politeFetch, and a Strict-Transport-Security max-age parse (RFC 6797; ≥ 180-day threshold).
- HSTS max-age is below the 6-month minimumCRITICAL
/parsed max-age = 7889238s (need ≥ 15552000s = 180 days)
What we found
max-age=7889238What we expected
Strict-Transport-Security: max-age=31536000; includeSubDomainsBump
max-ageto at least 15552000 (180 days). 31536000 (1 year) is required for preload-list inclusion.
Add a positive merchantReturnDays to finite-window return policies
Why this matters: AI agents quote your concrete return window in shopping cards. Without `merchantReturnDays`, your policy renders as 'has a return policy' without the headline number.
Findings (11)
Inspected 153 finite-window MerchantReturnPolicy nodes (0 carry a positive merchantReturnDays, 0%).
How: For each MerchantReturnPolicy node whose returnPolicyCategory normalizes to MerchantReturnFiniteReturnWindow, require merchantReturnDays to be a positive number (or a numeric string > 0).
Coverage
0/153 · 0%
- Finite-window MerchantReturnPolicy missing positive merchantReturnDaysHIGH× 10
What we found
(missing)What we expected
30Set
merchantReturnDaysto a positive integer (or switch the category to MerchantReturnUnlimitedWindow).Affected (10)
- /products/cloudnova-rift-white-ice
- /products/cloudnova-rift-white-ice
- /products/cloudnova-rift-white-ice
- /products/cloudnova-rift-white-ice
- /products/cloudnova-rift-white-ice
- /products/cloudnova-rift-white-ice
- /products/cloudnova-rift-white-ice
- /products/cloudnova-rift-white-ice
- /products/cloudnova-rift-white-ice
- /products/cloudnova-rift-white-ice
…and 1 more
Add every required top-level key to the UCP profile
Why this matters: A profile missing one of the four required keys is treated as non-conformant — agent runtimes fall back to default behaviour and may skip the merchant.
Findings (1)
Profile is missing required key(s): signing_keys.
How: Read the profile root (or top-level ucp wrapper) and verify the presence of version, services, capabilities, and signing_keys keys.
- Required top-level key
signing_keysis missingHIGHWhat we expected
Add a top-level "signing_keys" field to the JSON document (empty array/object is fine).Set
signing_keysat the root of the JSON document.
Skipped — the runner did not surface transport metadata
Context: If your UCP profile says `no-cache`, agent runtimes re-fetch on every interaction — brittle at scale and prone to rate-limit failures.
Why this was skipped
Wanted to inspect the UCP profile's Cache-Control header, but the runner did not surface transport metadata.
How: Parse the Cache-Control header on the /.well-known/ucp response; require public, max-age ≥ 60, and no no-store/no-cache/private.
- Transport metadata not available — runner update pendingLOW
This check activates once the runner (Task I1) populates ctx.wellKnownUcp.cacheControl.
Skipped — Profile declares no signing_keys; JWK validation has no entries to evaluate.
Context: Malformed JWK entries are rejected silently by agents — signed payloads cannot be verified and the merchant loses trust signal.
Why this was skipped
Profile declares no signing_keys; JWK validation has no entries to evaluate.
How: Walk signing_keys[] and validate each entry per RFC 7517 §4.1 (kty required) + RFC 7518 §6 (kty-specific required parameters). kid is OPTIONAL per RFC 7517 §4.5 and not enforced here.
Add includeSubDomains to your Strict-Transport-Security header
Why this matters: Without includeSubDomains, an HTTP subdomain (staging, mail, …) can be used to attack the apex's cookies.
Findings (1)
Inspected the homepage Strict-Transport-Security header ("max-age=7889238") and the includeSubDomains directive is absent.
How: Parse the homepage Strict-Transport-Security header for the includeSubDomains directive (RFC 6797 §6.1.2).
- HSTS header is missing the includeSubDomains directiveMEDIUM
What we found
max-age=7889238What we expected
Strict-Transport-Security: max-age=31536000; includeSubDomainsAppend
; includeSubDomainsto your STS header once every subdomain you operate supports HTTPS.
Skipped — No OfferShippingDetails node carried `shippingRate`, so the MonetaryAmount check has nothing to evaluate.
Context: An invalid rate object is silently dropped; agents can't quote your shipping cost in shopping cards.
Why this was skipped
No OfferShippingDetails node carried shippingRate, so the MonetaryAmount check has nothing to evaluate.
How: On each OfferShippingDetails node where shippingRate is set, require an object with numeric value/maxValue (typed or numeric string) and a 3-letter ISO 4217 currency.
Skipped — Profile declares no capabilities; required-field checks have nothing to evaluate.
Context: Capabilities missing version/spec/schema can't be matched against agent support tables — agents skip them silently.
Why this was skipped
Profile declares no capabilities; required-field checks have nothing to evaluate.
How: For each capabilities[] entry, require non-empty string values for version, spec, and schema.
Add preload to your Strict-Transport-Security header and submit to hstspreload.org
Why this matters: HSTS preload-list inclusion is the strongest downgrade protection available — first-time visits are protected too.
Findings (1)
Inspected the homepage Strict-Transport-Security header ("max-age=7889238") and the preload directive is absent.
How: Parse the homepage Strict-Transport-Security header for the preload directive (hstspreload.org vendor extension to RFC 6797).
- HSTS header is missing the preload directiveLOW
What we found
max-age=7889238What we expected
Strict-Transport-Security: max-age=31536000; includeSubDomains; preloadAppend
; preloadafterincludeSubDomainsand submit your domain at https://hstspreload.org/.
Add descriptive alt text to product images (WCAG 2.x SC 1.1.1)
Why this matters: Alt text is the only text description AI agents and screen readers have for your product imagery.
Findings (11)
Parsed <img> alt attributes across 20 sampled product pages (3 have alt text on at least 80% of images).
How: Per PDP, count <img> tags via regex; a tag 'has alt text' when its alt attribute is present AND non-empty after trim. A PDP passes when it carries no <img> at all OR ≥80% of its <img> tags have non-empty alt.
Coverage
3/20 · 15%
- Most images on this product page lack alt textLOW× 10
What we expected
<img src="/img/sneaker.webp" alt="Red leather running shoe, side view" />Populate the alt attribute on each <img> with a description of what the image shows; use alt="" only for decorative images.
Affected (10)
- /products/cloudnova-rift-white-ice38/54 <img> tags have non-empty alt (70%)
- /products/cloudnova-form-2-ivory-desert38/54 <img> tags have non-empty alt (70%)
- /products/cloud-6-push-lilac-black38/54 <img> tags have non-empty alt (70%)
- /products/cloudsurfer-next-peony-heather38/54 <img> tags have non-empty alt (70%)
- /products/w-bondi-9-truffle-salt-sea-glass40/56 <img> tags have non-empty alt (71%)
- /products/w-bondi-9-black-white42/58 <img> tags have non-empty alt (72%)
- /products/w-bondi-9-stardust-silver40/56 <img> tags have non-empty alt (71%)
- /products/bondi-9-frost-cielo-blue40/56 <img> tags have non-empty alt (71%)
- /products/holiday-tote-natural-135/51 <img> tags have non-empty alt (69%)
- /products/cloudtilt-pearl-ice36/52 <img> tags have non-empty alt (69%)
…and 1 more
Add an AggregateRating to Product nodes when you have real reviews
Why this matters: Review ratings are a trust signal agents use to rank and filter products.
Findings (11)
Looked for a valid aggregateRating on Product JSON-LD across 20 sampled product pages (6 valid, 30%).
How: On each Product node, parse aggregateRating (or the first element if it's an array) and require ratingValue in [0,5] AND reviewCount or ratingCount ≥ 1.
Coverage
6/20 · 30%
- Product has no valid AggregateRating (ratingValue 0-5 + reviewCount/ratingCount ≥ 1)LOW× 10
Render
aggregateRatingfrom real review totals — never fabricate.Affected (10)
- /products/cloudnova-rift-white-ice
- /products/cloudnova-form-2-ivory-desert
- /products/cloud-6-push-lilac-black
- /products/cloudsurfer-next-peony-heather
- /products/w-bondi-9-truffle-salt-sea-glass
- /products/w-bondi-9-stardust-silver
- /products/clifton-10-white-white
- /products/bondi-9-frost-cielo-blue
- /products/bondi-9-white-white
- /products/cloudtilt-pearl-ice
…and 1 more
Skipped — No MerchantReturnPolicy node carried returnFees, returnMethod, or refundType, so the enum check has nothing to evaluate.
Context: Invalid enrichment values are dropped silently, leaving merchants confused about why their rendered policy is missing fields they configured.
Why this was skipped
No MerchantReturnPolicy node carried returnFees, returnMethod, or refundType, so the enum check has nothing to evaluate.
How: On each MerchantReturnPolicy node, inspect returnFees/returnMethod/refundType if set; require the bare name or schema.org URL form of a value in the corresponding Schema.org enum.
Enable Apple Pay through your payment processor (informational only)
Why this matters: Apple Pay is a checkout-quality signal for human shoppers — informational only, does not affect the agent-readiness score.
Findings (1)
Scanned the homepage and 20 sampled PDPs for Apple Pay markers; none matched.
How: Substring match on known Apple Pay SDK/markup signatures (ApplePaySession, apple-pay-button, /apple-developer-merchantid-domain-association) across the homepage and every sampled PDP HTML.
- No Apple Pay markers detected on the homepage or PDPsINFO
Enable Apple Pay in your payment processor's dashboard (Stripe / Adyen / Braintree). Informational only — does not affect the score.
Enable Google Pay through your payment processor (informational only)
Why this matters: Google Pay is a checkout-quality signal for human shoppers — informational only, does not affect the agent-readiness score.
Findings (1)
Scanned the homepage and 20 sampled PDPs for Google Pay markers; none matched.
How: Substring match on known Google Pay SDK/markup signatures (pay.google.com/gp/p/js/pay.js, google.payments.api, <google-pay-button) across the homepage and every sampled PDP HTML.
- No Google Pay markers detected on the homepage or PDPsINFO
Enable Google Pay in your payment processor's dashboard (Stripe / Adyen / Braintree). Informational only — does not affect the score.