Agentic Commerce Case Study: A Step-by-Step Walkthrough
Reading about agent-ready feeds and schema in the abstract only gets you so far — at some point you need to see the pieces move together on a real-shaped business. What follows is an illustrative walkthrough, built from the pattern of engagements we run at Salterra Digital Services, showing how an agentic commerce project unfolds from a vague sense that “something’s off” to a measurable shift in how AI shopping agents treat a brand. It is not a single named client with verified figures — it’s a composite of the diagnosis-to-execution sequence we see repeat across mid-sized ecommerce catalogs, and any numbers below are labeled hypothetical.
The teaching point is the sequence: how you find the problem, decide what to fix first, and prove it worked.
The Business and the Problem
Picture a mid-market outdoor gear retailer — a 400-SKU catalog of packs, tents, and cold-weather layers, sold direct through its own storefront and a couple of marketplace listings. Organic traffic had been flat but healthy for years. The trigger for the engagement wasn’t a traffic drop; it was a founder noticing that when they asked ChatGPT and Perplexity for buying advice in their own category, their brand rarely showed up, and when it did, the details were wrong — a discontinued product listed as current, a price that hadn’t been true in months.
That’s a common way these projects start now: not a rankings report, but a founder running their own “mystery shop” against an AI assistant and not liking what they see. It’s worth normalizing this as a legitimate discovery signal in the AI-search era — traditional analytics won’t flag “an agent is quietly steering customers elsewhere,” because that traffic was never yours to lose. You have to go looking for it.
The Diagnosis: Running an AX Audit
Before recommending anything, the first move is always a baseline audit — the same discipline covered in our step-by-step agentic commerce guide, applied here to a live catalog. The audit surfaced four layered failure points; fixing only one would have left the others silently capping results.
Crawler access was partially blocked
A security plugin installed years earlier, before anyone was thinking about AI agents, was rate-limiting unfamiliar user agents — catching several shopping-bot crawlers along with the spam traffic it was designed to stop. Nobody had audited that rule since it was set.
The product feed was incomplete
Roughly a third of SKUs were missing GTIN or MPN identifiers, and variant data (size, color) was inconsistently structured — some products listed every variant as a separate feed entry, others collapsed them into one listing with the variant buried in title text instead of a structured attribute.
Schema existed but didn't match reality
Product schema was present sitewide, which looked like a point in the brand’s favor until closer inspection — prices in the markup lagged the live site by days after a sale ended, because the schema was generated at build time and the site hadn’t rebuilt on the sale’s end date. An agent trusting the markup over the rendered price would recommend a stale deal that no longer existed.
Policy information was orphaned
Return and shipping policy lived on a single standalone page, linked from the footer, with no schema connecting it to individual product offers. An agent evaluating a specific pack had no structured way to answer “can this be returned,” so it guessed, omitted the detail, or passed in favor of a competitor whose policy was explicit at the offer level.
The Strategy
With four distinct problems, the temptation is to fix everything at once. We don’t recommend that, for the same reason you don’t change five variables in one experiment: you lose the ability to attribute what moved the needle. The plan sequenced fixes by two criteria — blast radius (does this block agents entirely, or just make them less confident) and effort (ship this week, or a dev sprint).
That put crawler access first (highest blast radius, lowest effort — a config change), the feed second (high blast radius, moderate effort), schema accuracy third (needs a process fix, not a one-time correction), and policy markup fourth (lower blast radius alone, but compounds with the others once in place).
Execution, Step by Step
Step 1: Fix crawler access first, then verify — don't assume
The bot-management rule was corrected to explicitly allow known shopping and AI-search crawlers by name rather than a broad heuristic. Verification wasn’t “check the robots.txt and move on” — it meant pulling server logs a week later to confirm those user agents were completing successful fetches, not just being allowed through in theory. This is the step teams most often skip, and it’s the cheapest one to get right.
Step 2: Rebuild the feed around complete, atomic SKU data
Every product got a GTIN/MPN where one existed in manufacturer data, and variants were normalized so each size/color combination was its own structured entry rather than text buried in a title. Unglamorous data-entry work, but it’s the single highest-leverage fix in most agentic commerce projects — a missing identifier doesn’t just weaken a listing, it can exclude the product from consideration entirely.
Step 3: Move schema generation off a static build cycle
Instead of schema baked in at deploy time, pricing and availability fields were switched to pull live from the same source of truth as the storefront’s displayed price, on every render. The rule adopted going forward: if a human and an agent can ever see a different price for the same product at the same moment, that’s a bug, not a rounding error.
Step 4: Nest policy data at the offer level
MerchantReturnPolicy and OfferShippingDetails were added directly inside each product’s Offer markup, so the return window and shipping cost travel with the SKU instead of living on an orphaned policy page. This closed the gap an agent needs closed to move from “here’s an option” to “here’s a recommendation.”
What to Measure — and When
Because the fixes shipped in sequence, measurement happened in matching stages rather than as one before/after snapshot at the end. For each phase, the team tracked three things: whether the relevant crawlers were successfully fetching pages (server-log confirmation), whether the feed and schema passed structured-data validation with zero mismatches against the live storefront, and — the qualitative core of the exercise — repeated manual “mystery shop” prompts run against ChatGPT and Perplexity for the same dozen category queries, logged consistently before and after each phase.
That manual prompt log matters more than it sounds like it should. Rank trackers weren’t built for this; the only reliable way to know whether an agent’s behavior changed is to keep asking it the same questions and record what comes back. Suppose, illustratively, that in the baseline round the brand was named in roughly 1 of 12 category prompts, and by the final round that had risen to something like 7 or 8 of 12 — that’s the kind of shift this measurement approach is built to catch, a number no traditional SEO report would surface.
What Changed, and Why
In this illustrative scenario, the most noticeable shift wasn’t aggregate traffic — it was the quality and accuracy of how agents described the brand when they did surface it. Early on, when the brand appeared at all, the details were often wrong or hedged (“this may still be available”). After the feed and schema fixes, the same category prompts returned confident, specific answers: current price, accurate stock status, and a clear return policy stated as fact rather than omitted.
The “why” traces back to the diagnosis. Agents don’t reward effort or brand loyalty; they reward legibility and confidence. Every fix reduced ambiguity for a system that has to decide, in a fraction of a second, whether recommending a product carries risk. Complete identifiers reduce risk. Live-matching schema reduces risk. Offer-level policy data reduces risk. None of these are persuasion tactics — they’re closer to removing the reasons an agent would say no.
Lessons and Takeaways
- Diagnose before you fix. Four problems needed four different remedies; treating “agentic commerce” as one undifferentiated task would have wasted a sprint solving the wrong thing first.
- Sequence by blast radius and effort, not by what’s most exciting. Crawler access is boring and it’s still where you start — nothing downstream matters if the agent can’t get in the door.
- Schema that lies is worse than no schema. A confident, wrong answer damages trust faster than an honest gap, both with the agent’s evaluation and the customer who shows up expecting a price that no longer exists.
- Measurement has to be manual, at least for now. Until agent-referral analytics mature, the “mystery shop” prompt log is the closest thing to a reliable before/after signal, and it only works if run consistently.
- This work isn’t a one-time project. Agent platforms update how they crawl, weight, and present results on their own schedule. The audit-fix-measure loop is meant to repeat on a cadence, not close with a single report.
Frequently Asked Questions
Is this case study based on a real client?
No — it's an illustrative, composite walkthrough built from the pattern we see repeat across agentic commerce engagements, meant to teach the diagnosis-to-execution sequence rather than report verified results from a specific business.
How long does a project like this typically take?
The sequence — crawler fix, feed rebuild, schema correction, policy markup — commonly spans several weeks to a couple of months depending on catalog size, with crawler access fixable almost immediately and feed normalization usually the longest phase.
Do I need all four fixes, or can I start with just one?
Start with whichever the audit shows is actually blocking you, but don't stop there — fixing only the crawler issue would have let agents in the door while the feed and schema problems kept them from trusting or recommending anything once they arrived.
How do I run my own version of the "mystery shop" measurement?
Write down realistic buying prompts a customer in your category would type, run them against the major AI assistants on a fixed schedule, and log whether your brand appears, whether details are accurate, and how confidently it's recommended — consistency in how you ask matters more than which tools you use.
Does fixing agentic commerce issues also help traditional SEO?
Largely yes — complete structured data, accurate pricing, and clean crawler access are foundational technical SEO practices too, so this work reinforces rather than competes with a standard organic program.
What's the biggest mistake teams make when starting this kind of project?
Trying to fix everything simultaneously instead of sequencing by blast radius and effort, which makes it impossible to tell which change moved the needle and often stalls the project under its own complexity.
Terry has 30+ years in software and SEO. He’s the founder of Salterra Digital Services and SEO Spring Training, host of the Roundtable SEO Mastermind, and lead instructor at SEO University — teaching the exact tactics his team uses on client work.
Continue learning
Ready to master this?
This guide is one lesson from the Agentic Commerce & Agent Experience Optimization (AX) course. Get every lesson, framework and checklist — plus the full 38-course catalog — inside SEO University.
Practitioner-focused training across the full digital marketing stack — from technical SEO to conversion optimization and the AI search era. By Salterra Digital Services, since 2011.