```
No ancestor `itemscope` of type Product exists on this page. Per the microdata spec, `itemprop` declares a property of the nearest ancestor item - with none present, this Offer is self-contained, not attached to anything.
This is what makes the gap easy to miss: the Offer item is internally valid, so a tool checking it in isolation won't flag an error. What it can't do is tell a parser "this price and this availability belong to a Product named X, with SKU Y" - because that connection was never declared.
Expected graph
```
Product
├─ name
├─ sku
├─ brand
├─ image
└─ offers
├─ price
├─ availability
└─ priceCurrency
```
What Hyvä renders today
```
Offer (standalone)
├─ price
├─ availability
└─ priceCurrency
image (standalone,
itemprop with
no parent scope)
Product - absent
```
[image: Comparison diagram: the expected schema.org Product graph with name, sku, brand, image, and offers, versus what Hyvä actually renders - a standalone Offer and image with no Product entity]
Shareable version of the graph above, with the verified `price.phtml` snippet.
## Why the disconnect matters for parsers
Search and shopping surfaces that assemble a product answer - from classic rich-results eligibility to newer shopping-oriented indexes - generally need one connected entity: a Product with an identity, tied to an Offer with price and availability. A page where price/availability data sits near Product content without a formal link asks the consumer to infer the connection instead of reading it directly. That removes an explicit Product→Offer relationship and makes reliable entity extraction harder; it doesn't guarantee any specific system will fail to use the page, but it's a weaker signal than a declared graph.
JSON-LD avoids the problem by declaring the whole graph in one block, independent of DOM nesting. Hyvä already applies this pattern to breadcrumbs: since release 1.3.15, the theme renders a `BreadcrumbList` JSON-LD script server-side. It just hasn't been extended to Product.
## A related trap: schema added through GTM
Some teams add Product schema via Google Tag Manager to avoid touching theme code. This only helps clients that execute the injected script. Server-rendered HTML is the safer assumption for any crawler whose JavaScript behavior you can't verify: OAI-SearchBot and PerplexityBot are broadly understood to run little or no client-side JS, though neither publishes full technical details, while Googlebot and Bingbot do render JavaScript for their own indexes. GTM-based schema is therefore inconsistent across consumers rather than reliably invisible - which is its own problem, since you can't predict which pipeline will see it. Rendering the JSON-LD from the template removes that uncertainty entirely.
## The fix: a server-rendered Product JSON-LD block
Add a JSON-LD block from the product template (or a small module) so it ships in the initial HTML and explicitly declares the Product-Offer relationship the existing microdata leaves implicit. Populate every value from live product, store, and stock data.
```
```
`aggregateRating` should only be emitted when real review data exists for that product - don't copy the sample values above as a placeholder; Google treats fabricated ratings as a policy violation.
`mpn`, `hasMerchantReturnPolicy`, and `shippingDetails` are optional but increasingly expected for Google Merchant Center parity - include them if the data exists, skip otherwise rather than hardcoding placeholders.
Reuse the same source values the existing microdata already computes - `$product->getIsSalable()` for availability, the same final price and currency - so the two blocks never disagree. The existing Offer/image microdata doesn't need to be removed; it's incomplete rather than harmful, and adding JSON-LD alongside it doesn't create a conflict since the microdata was never linked to a Product in the first place.
## Validation checklist
1. **Check raw source, not the rendered DOM** - "View Page Source," or fetch with `curl`. If the JSON-LD isn't in that output, server-rendering has failed and it won't reach any non-JS consumer.
2. **Run [Google's Rich Results Test](https://search.google.com/test/rich-results)** and confirm it reports a `Product`, not just an Offer.
3. **Cross-check with [validator.schema.org](https://validator.schema.org/)** for the full entity graph, including nested Offer, brand, and rating.
4. **Compare the product URL across three places** - the page's canonical tag, `Product.url`, and `offers.url` - they should all resolve to the same URL.
5. **Compare price and availability** in the JSON-LD against the existing microdata - a mismatch is worse than either being absent.
6. **Spot-check a configurable, an out-of-stock, and a discounted product**, since these are where mappings usually break.
The takeaway
Hyvä's server-rendered HTML and live price/availability computation are genuine strengths. The missing piece is one wrapper: a declared Product entity that ties the existing data together. A server-side JSON-LD block adds that connection explicitly, without needing to touch or remove what's already there.
## FAQ
Does Hyvä have zero structured data for products?
No. `price.phtml` emits Offer-level microdata, and the gallery emits `itemprop="image"`. What's missing is the `schema.org/Product` wrapper that would connect those fragments into one entity.
Can I just use a schema plugin instead of editing the template?
Yes, provided the plugin outputs JSON-LD server-side. Verify it in raw page source; tag-manager-based or JS-rendered solutions won't reach clients that skip JavaScript execution.
Is a connected Product JSON-LD enough on its own for AI shopping surfaces?
It's one necessary piece, not the whole picture. Crawler access in robots.txt, page speed and crawlability, and (for Google's surfaces specifically) a complete Merchant Center feed all factor in separately. A declared Product entity removes a common structural blocker; it doesn't substitute for the rest.
- [UCP Readiness Checklist for Magento 2: 10 Steps to AI Agent Commerce](https://angeo.dev/ucp-readiness-checklist-magento/): Is your Magento 2 store ready for Google's Universal Commerce Protocol? 10 steps from AEO foundations to a verified UCP profile - with free MIT modules.
*UCP is an actively evolving protocol - capabilities, naming, and merchant onboarding processes may change. This checklist reflects the state of the specification as of May 2026 (version 2026-04-08). We update this guide when the spec changes.*
[image: UCP Readiness Checklist for Magento 2 - 10 steps from default installation to AI agent commerce readiness]
10 steps from default Magento 2 installation to UCP-ready AI agent commerce
### TL;DR - 2 minute version
- UCP readiness is **not just installing a module** - it requires AEO foundations first (robots.txt, llms.txt, schema, feed)
- Steps 1-4 are **AEO foundations** that also benefit Google Search, ChatGPT, and Perplexity visibility
- Steps 5-8 are **UCP-specific**: module installation, key generation, profile enablement, verification
- Steps 9-10 are **optimisation**: FAQ schema and a full AEO audit
- Estimated total time: **4-6 hours** (excluding OpenAI's ACP feed approval timeline)
- UCP discovery ≠ UCP recommendation. Completing this checklist makes your store *findable* - not automatically *recommended*
In this guide · 10 min read
1. Foundation: Steps 1-4 (AEO prerequisites)
2. UCP implementation: Steps 5-8
3. What you have after Step 8
4. Optimisation: Steps 9-10
5. The complete picture
6. What comes next
7. FAQ
Universal Cart has begun rolling out in the US as of May 19, 2026. Canada and Australia are next, per Google's announcements. The UK is expected to follow.
If your Magento store has not implemented UCP, it cannot be discovered by AI agents using the UCP protocol - which Google is deploying across Search AI Mode, Gemini, and YouTube Shopping. This does not mean your store is invisible to all AI systems - Google Merchant Center feeds, direct crawling, and schema still matter - but UCP is an additional discovery layer that is growing in importance.
This checklist covers the ten steps between a default Magento installation and a UCP-compliant store. Some take five minutes. Some take a few hours. All steps can be implemented on your existing Magento installation.
*This guide is part of the [Merchant-Controlled AEO](https://angeo.dev/merchant-controlled-aeo/) architecture. For a plain-English explanation of what UCP is and why it matters, see [What Is UCP? A Store Owner's Guide](https://angeo.dev/what-is-ucp-for-store-owners/).*
## Before UCP: the foundation (Steps 1-4)
UCP is the roof. These four steps are the foundation. Without them, UCP has nothing to build on - a UCP profile without indexed content and structured product data is a door with nothing behind it.
These steps also improve your visibility in Google Search, ChatGPT, Perplexity, and Claude - they are valuable regardless of whether you implement UCP.
### Step 1 - Unblock AI crawlers in robots.txt
**Time:** 5 minutes
**Why it matters:** AI agents and crawlers need permission to access your store. Magento's default `robots.txt` blocks most of them.
Open `yourstore.com/robots.txt` and verify that these bots are explicitly allowed:
# Required for AI commerce visibility
User-agent: OAI-SearchBot
Allow: /
User-agent: Googlebot
Allow: /
User-agent: Google-Extended
Allow: /
`OAI-SearchBot` is ChatGPT's search indexer. `Google-Extended` is used by Gemini. Both need access for their respective commerce protocols to function.
If any of these appear under a `Disallow: /` directive, fix it before proceeding. Everything else in this checklist is irrelevant if crawlers cannot reach your store.
**Detailed guide:** [How to fix robots.txt for ChatGPT and Gemini →](https://angeo.dev/magento-2-robots-txt-chatgpt-gemini-ai-bots/)
### Step 2 - Generate llms.txt
**Time:** 10 minutes (automated)
**Why it matters:** `llms.txt` tells AI systems what your store sells, in plain language. Without it, AI agents construct an approximate - and often inaccurate - model of your business.
composer require angeo/module-llms-txt
bin/magento module:enable Angeo_LlmsTxt
bin/magento setup:upgrade
The module generates both `llms.txt` and `llms.ljson` from your live catalog automatically. Cron-scheduled to update when products change.
Verify: visit `yourstore.com/llms.txt` - you should see a structured summary of your store, categories, and key products.
**Detailed guide:** [How to generate llms.txt for Magento 2 →](https://angeo.dev/how-to-generate-llms-txt-for-magento-2-in-5-minutes/)
### Step 3 - Implement Product JSON-LD schema
**Time:** 1-2 hours
**Why it matters:** AI agents - and UCP specifically - rely on structured product data. JSON-LD is the format both Google and OpenAI prefer. Magento's default uses microdata, which is less reliable for AI parsing.
Critical fields to include:
| Field | Why it matters |
| `name` | Product name - used as the primary identifier |
| `description` | Product description - AI agents read this to form recommendations |
| `offers.price` | Current price - required for shopping comparisons |
| `offers.priceCurrency` | Currency code - ambiguous pricing breaks AI agent trust |
| `offers.availability` | **Most common failure.** ChatGPT Shopping and UCP both skip products without confirmed availability |
| `sku` | Product identifier - used for cross-platform matching |
| `aggregateRating` | Review score - affects recommendation confidence (if you have reviews) |
**The single most common failure:** `offers.availability` missing. This one field determines whether AI agents consider your product purchasable. Without it, your products may be skipped entirely - regardless of how complete the rest of your schema is.
**Detailed guide:** [Product JSON-LD schema for AI Search →](https://angeo.dev/magento-2-product-schema-json-ld-ai-search/)
### Step 4 - Submit product feed for ChatGPT Shopping
**Time:** 30 minutes + 1-4 weeks approval
**Why it matters:** ACP and UCP serve different platforms but share the same foundation. A submitted product feed makes your products available for ChatGPT Shopping consideration. The product data you prepare - prices, availability, descriptions - is the same data UCP needs.
composer require angeo/module-openai-product-feed
bin/magento module:enable Angeo_OpenaiProductFeed
bin/magento setup:upgrade
Submit your feed through `chatgpt.com/merchants`. Approval typically takes one to four weeks. Note: OpenAI has not published a stable, widely-documented merchant onboarding standard as of May 2026 - treat the submission process as evolving.
**Detailed guide:** [Magento 2 ChatGPT Shopping Registration →](https://angeo.dev/magento-2-chatgpt-shopping-registration/)
## UCP implementation (Steps 5-8)
With the foundation in place, your store is ready for UCP. These steps add the protocol-specific discovery layer.
### Step 5 - Install the UCP profile module
**Time:** 10 minutes
**Why it matters:** This is the discovery layer - the file at `/.well-known/ucp` that tells AI agents your store exists and what capabilities it supports.
# Requires Magento 2.4.7+, PHP 8.2+, OpenSSL extension
composer require angeo/module-ucp:^0.1@beta
bin/magento module:enable Angeo_Ucp
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento cache:flush
### Step 6 - Generate ECDSA signing keys
**Time:** 5 minutes
**Why it matters:** UCP requires cryptographic signing keys for secure communication between your store and AI agents. The module generates ECDSA P-256 keys - the same standard used by Apple Pay and Google Pay.
bin/magento angeo:ucp:keys:generate
The command prints the private PEM key to your terminal exactly once. Copy it immediately into `app/etc/env.php`:
// app/etc/env.php
'ucp' => [
'signing_keys' => [
'angeo-ucp-2026-abcd' => '
',
],
],
The public JWK is saved to Magento config automatically. The private key never touches the database.
### Step 7 - Enable the UCP profile
**Time:** 2 minutes
**Why it matters:** The module installs disabled by default. You need to explicitly opt in.
Navigate to: **Stores → Configuration → Angeo → UCP → General → Advertise UCP Profile: Yes**
For v0.1.x (profile-only release), leave all individual capabilities disabled - the profile establishes your presence in the UCP discovery layer while actual endpoints are developed in later versions.
**v0.1.x note:** Enabling a capability in the admin panel adds it to the advertised profile - but the matching REST endpoint does not exist yet in this release. Leave capabilities disabled until the corresponding endpoint module is available and tested.
### Step 8 - Verify the profile
**Time:** 2 minutes
**Why it matters:** A malformed profile is worse than no profile - it signals to AI agents that your store is unreliable.
# Fetch and validate your UCP profile
curl -s https://yourstore.com/.well-known/ucp | python3 -m json.tool
You should see a valid JSON response with `version: "2026-04-08"`, your signing keys, and the `dev.ucp.shopping` service binding.
Run the built-in validator:
bin/magento angeo:ucp:validate --json
Green pass means your profile is spec-compliant. Non-zero exit means something needs fixing - the output tells you what.
**External validation:** You can also use [ucpchecker.com](https://ucpchecker.com) to validate your profile against the official conformance test suite.
## What you have after Step 8
**At this point, your store has a spec-compliant UCP profile at `/.well-known/ucp`.** AI agents that support UCP discovery can find your store and read its capabilities.
This does not mean AI agents will immediately recommend your products. UCP discovery is one layer in a stack that also includes catalog quality, pricing, schema completeness, entity authority, and feed registration. Steps 9 and 10 address the most impactful remaining signals.
Think of Steps 1-8 as infrastructure. What you build on that infrastructure - product quality, content quality, brand authority - determines the commercial outcome.
## Optimisation and monitoring (Steps 9-10)
### Step 9 - Add FAQPage schema to key pages
**Time:** 1-2 hours
**Why it matters:** AI agents extract FAQ content as trusted answers. Category pages and product pages with FAQ schema are more likely to be cited in AI responses - and more likely to be the source an agent references when recommending products.
Add FAQPage JSON-LD schema to:
- Your top 10 category pages (by revenue)
- Your top 20 product pages (by revenue)
- Your homepage
Each FAQ section should contain 3-5 questions with direct, factual answers. Use the questions your customers actually ask - shipping times, return policies, size guides, compatibility, care instructions.
### Step 10 - Run a full AEO audit
**Time:** 30 seconds
**Why it matters:** Steps 1-9 cover the individual components. The audit scores your store across all 9 AEO signals and shows where gaps remain.
# CLI audit - shows scored results for all 9 signals
bin/magento angeo:aeo:audit
Or use the web-based audit - no installation required:
### See exactly where the gaps are
The audit checks all 9 signals - robots.txt, llms.txt, schema, feeds, UCP profile, and more. 30 seconds.
[Run free AEO audit →](https://angeo.dev/ai-magento-audit/)
Target: 85%+ AEO score with UCP profile active.
## The complete picture
| Step | Time | Impact | Also benefits |
| 1. robots.txt | 5 min | Prerequisite - without this, nothing works | ChatGPT, Perplexity, Claude |
| 2. llms.txt | 10 min | AI agents understand your store correctly | All AI platforms |
| 3. JSON-LD schema | 1-2 hrs | Products are parseable and purchasable | Google Search, ChatGPT Shopping |
| 4. ACP feed | 30 min + wait | ChatGPT Shopping visibility | ChatGPT |
| 5. UCP module | 10 min | Google AI discovery layer | UCP-specific |
| 6. Signing keys | 5 min | Secure agent communication | UCP-specific |
| 7. Enable profile | 2 min | Go live on UCP | UCP-specific |
| 8. Verify | 2 min | Confirm spec compliance | UCP-specific |
[content truncated]
- [Magento SEO Audit 2026: The Complete 4-Layer Checklist (Including AI Search)](https://angeo.dev/magento-seo-audit-2026/): Complete Magento 2 SEO audit checklist for 2026 - technical SEO, on-page, Core Web Vitals, plus the AI search visibility layer most audits miss.
*Tools and platform behavior change - verify current versions and Google guidelines as you work through this.*
[image: Magento 2 SEO audit checklist 2026 - technical SEO, on-page, and AEO AI search visibility layers]
### TL;DR - what a 2026 Magento audit covers
- One useful way to structure a Magento audit in 2026 is across **four practical layers**: technical SEO, on-page SEO, performance, and - new in 2026 - AI search visibility (AEO)
- Most audit checklists stop at traditional SEO. That leaves a growing blind spot: whether AI assistants can find and recommend your store
- **Traditional SEO tools** (Screaming Frog, Lighthouse, Search Console) cover the first three layers well
- **AI search visibility** needs its own checks: robots.txt for AI crawlers, llms.txt, Product schema completeness, structured product feeds (where supported)
- This guide gives a full checklist for both - and a free tool for the AEO layer
In this guide · 16 min read
1. A practical four-layer framework
2. Layer 1: Technical SEO audit
3. Layer 2: On-page SEO audit
4. Layer 3: Performance & Core Web Vitals
5. Layer 4: AI search visibility (AEO) - the new layer
6. 2020 vs 2026: how the audit changed
7. Tools: what covers which layer
8. DIY vs automated audit
9. FAQ
10. References
If you run a Magento 2 or Adobe Commerce store, an SEO audit used to mean one thing: check whether Google can crawl, index, and rank your pages. That is still essential - but in 2026, it is no longer the complete picture.
A growing share of product discovery now happens inside AI assistants - ChatGPT, Perplexity, Gemini - where customers ask questions and receive recommendations without visiting a search results page. A store can pass every traditional SEO check and still be invisible to these systems.
This guide covers the full 2026 audit: the technical and on-page SEO checks every Magento store needs, plus the AI search visibility layer most checklists miss.
## A practical four-layer framework for Magento audits in 2026
In this guide, we break a Magento audit into four practical layers. This is a structuring framework, not an industry standard - but separating these concerns makes findings clearer and harder to miss.
| Layer | What it checks | Primary tools |
| **1. Technical SEO** | Crawlability, indexation, sitemaps, duplicate content, URL structure | Search Console, Screaming Frog |
| **2. On-page SEO** | Titles, meta, headings, schema, internal linking, images | Screaming Frog, Rich Results Test |
| **3. Performance** | Core Web Vitals, page speed, mobile usability | Lighthouse, PageSpeed Insights |
| **4. AI search visibility (AEO)** | AI crawler access, llms.txt, Product schema for AI, structured product feeds and merchant data sources (where supported) | AEO audit tools |
Layers 1-3 are well-covered by established tools and checklists. Layer 4 is newer, less understood, and often receives less attention than traditional SEO areas.
## Layer 1: Technical SEO audit
Technical SEO ensures Google can crawl and index your store correctly. For Magento 2, the recurring problem areas are predictable.
### Crawlability & indexation
- robots.txt allows Googlebot and does not accidentally block key pages
- XML sitemap is current, submitted in Search Console, and excludes noindex URLs
- No critical pages returning 404 or 5xx - check Search Console Coverage report
- Faceted navigation (layered nav filters) is not generating thousands of crawlable parameter URLs
- Canonical tags are correct on category, product, and paginated pages
**The Magento duplicate content trap:** Magento 2 generates duplicate content through layered navigation filters, category paths, and pagination. A product accessible at multiple URLs (with filter parameters, via different categories) splits ranking signals. Canonical tags and parameter handling in Search Console are the standard fixes.
### Site structure
- Category hierarchy no deeper than 3 levels
- SEO-friendly URLs without unnecessary parameters (Magento: Stores → Config → Web → URL options)
- 301 redirects in place after any URL changes - preserve link equity
- No redirect chains (301 → 301 → 200 wastes crawl budget)
- Breadcrumbs present and marked up with BreadcrumbList schema
## Layer 2: On-page SEO audit
### Metadata & content
- Unique title tags on every indexable page (no "Default Title" or duplicate category titles)
- Meta descriptions present and unique on key pages
- One H1 per page, descriptive and keyword-relevant
- Product descriptions are original - not manufacturer/supplier copy duplicated across the web
- Category pages have real descriptive content, not just a product grid
- Image filenames and alt text are descriptive (e.g. `nike-pegasus-41-blue.jpg`, not `IMG_4821.jpg`)
### Structured data (schema)
- Product schema (JSON-LD) present with name, price, currency, and availability
- Organization schema on the homepage
- BreadcrumbList schema on category and product pages
- FAQPage schema where you have FAQ content
- Schema validates in Google's Rich Results Test with no errors
**Quick check:** Run any product URL through [Google's Rich Results Test](https://search.google.com/test/rich-results). The most common Magento finding: schema present but using microdata instead of JSON-LD, or missing `offers.availability`. Both matter more in 2026 because JSON-LD is generally easier for search engines and automated systems to parse consistently than embedded microdata.
### Internal linking
- Important products are reachable within 3 clicks of the homepage
- Related products and cross-sells create internal link paths
- No orphan pages (indexable pages with zero internal links)
- Blog/content links to relevant category and product pages
## Layer 3: Performance & Core Web Vitals
In 2026, mobile is the primary index Google uses, and Core Web Vitals are a confirmed ranking factor. Magento 2 stores - especially on the default Luma theme - frequently fail here.
- Largest Contentful Paint (LCP) under 2.5s on mobile
- Cumulative Layout Shift (CLS) under 0.1
- Interaction to Next Paint (INP) under 200ms
- Images served in modern formats (WebP/AVIF) and lazy-loaded below the fold
- Full-page cache (Varnish) enabled and working
- JavaScript and CSS minified and merged; render-blocking resources minimized
- Production mode enabled (`bin/magento deploy:mode:set production`)
**Run it:** Test your homepage and a product page in [PageSpeed Insights](https://pagespeed.web.dev) and a weekly Lighthouse audit. For Magento specifically, the Hyvä theme is often adopted to improve performance compared with default Luma implementations.
## Layer 4: AI search visibility (AEO) - the layer most audits miss
Here is what nearly every Magento SEO audit checklist published in 2026 still leaves out: whether AI systems can find, understand, and recommend your store.
This matters because the behaviour has already shifted. When a customer asks ChatGPT "recommend a [your category] store" or asks Perplexity to compare products, your traditional SEO ranking may not directly apply - these systems appear to draw on different signals, though their exact selection logic is not publicly documented. A store ranked highly on Google can still be absent from AI recommendations.
This is **AEO - Answer Engine Optimization**. It is worth distinguishing clearly from SEO: traditional SEO targets measurable ranking systems like Google Search, with documented signals and guidelines. AEO is an emerging layer focused on how content *may* be interpreted by AI systems - it is not governed by a single ranking algorithm, and the conventions are still forming. The checks below are forward-looking and low-risk, not guaranteed ranking factors.
### AI crawler access
- robots.txt does not unintentionally block AI search crawlers (where platforms use them) - bot names such as `OAI-SearchBot` and `Google-Extended` appear in current documentation but are not guaranteed stable across providers
- If you want AI search visibility, confirm these crawlers are not caught by a broad `Disallow` rule
- You have made a deliberate decision about training-data crawlers (e.g. `GPTBot`) - a separate choice from search visibility
**A common AEO oversight:** Default Magento 2 and some security configurations block crawlers broadly in robots.txt. If the crawlers a platform uses for AI search are blocked, that platform may have reduced ability to discover and process your content - regardless of traditional SEO quality. Bot names and behavior change, so this is worth re-checking periodically.
### AI content signals
- `llms.txt` (an emerging convention, not a formal standard) can be used to provide structured, AI-readable context about your catalog
- Product schema uses JSON-LD (not microdata) with complete `offers.availability`
- Product descriptions are original and descriptive - AI cannot recommend confidently from thin supplier copy
- FAQPage schema on key category and product pages
### AI commerce readiness
- Structured product feeds and merchant data sources used by AI commerce platforms (where available) - if you participate in such programs, keep feeds submitted and current
- Open Graph tags present for social/AI preview
- Canonical tags correct (many AI systems appear to use canonical signals when available)
**How AEO relates to SEO:** AEO does not replace SEO - most AEO best practices (structured content, clean schema, original descriptions) also improve traditional SEO. The difference is that SEO alone no longer covers the full discovery surface. A 2026 audit that stops at Layer 3 is measuring an increasingly incomplete picture.
## What a Magento audit looked like in 2020 vs 2026
The audit hasn't been replaced - it has expanded. The traditional layers remain exactly as important. What changed is the addition of a new layer that didn't exist as a practical concern five years ago.
| 2020 audit | 2026 audit |
| Crawlability & indexation | Crawlability & indexation |
| Metadata & on-page | Metadata & on-page |
| Structured data (schema) | Structured data (schema) |
| Core Web Vitals | Core Web Vitals |
| - | AI crawler accessibility |
| - | Structured AI signals (llms.txt, JSON-LD for AI) |
| - | AI commerce readiness |
If your audit checklist still looks like the 2020 column, it is measuring an increasingly partial view of how customers discover stores. The traditional work matters as much as ever - it is simply no longer the whole job.
## Tools: what covers which layer
| Tool | Covers | Cost |
| Google Search Console | Indexation, Core Web Vitals, coverage errors | Free |
| Screaming Frog | Crawl, broken links, duplicate titles, redirects | Free (500 URLs) / paid |
| Lighthouse / PageSpeed Insights | Performance, Core Web Vitals | Free |
| Google Rich Results Test | Schema validation | Free |
| AEO audit (angeo) | AI search visibility - Layer 4 | Free |
The first four tools are industry-standard for Layers 1-3 and are not Magento-specific. Layer 4 (AEO) is the gap - general SEO tools do not yet check AI crawler access, llms.txt, or AI feed status.
## DIY vs automated audit
For Layers 1-3, a competent in-house developer or SEO specialist can run a thorough audit using the free tools above in a day or two. The checklists in this guide cover the major findings.
For Layer 4 (AEO), the checks are specific and less familiar - AI bot names, llms.txt format, JSON-LD completeness for AI parsing. This is where an automated AEO audit saves time: it checks nine AEO-related signals used in our audit framework at once and returns a prioritised list, rather than requiring you to know each check individually.
**Practical sequence:** Check your Layer 4 (AEO) baseline first, then work through Layers 1-3 with Search Console and Screaming Frog. Layer 4 can surface relatively simple fixes, such as reviewing robots.txt directives and structured-data implementation.
[content truncated]
- [How to Fix robots.txt for ChatGPT and Gemini in Magento 2](https://angeo.dev/magento-2-robots-txt-chatgpt-gemini-ai-bots/): Default Magento 2 robots.txt quietly blocks GPTBot, OAI-SearchBot and Google-Extended. Copy-paste allow rules and how to verify each bot crawls.
Your sitemap is configured. Your Core Web Vitals score is green. Your product catalog is perfectly structured. And yet when a user asks ChatGPT for products you sell, your store doesn't appear.
Most of the time, the reason is a single file: `robots.txt`.
Specifically - a `robots.txt` written for Google in 2019 and never updated for the AI crawlers that now determine your visibility in ChatGPT, Gemini, Claude, and Perplexity. In 2026, there are ten distinct AI bots across four platforms. Most Magento installations have explicit rules for zero of them.
[image: How to Fix robots.txt for ChatGPT and Gemini in Magento 2]
How to Fix robots.txt for ChatGPT and Gemini in Magento 2
## Why robots.txt Is AEO Signal #1
The [angeo/module-aeo-audit](https://packagist.org/packages/angeo/module-aeo-audit) checks robots.txt first and marks it Critical because it is a gate. Every other AEO signal - llms.txt, Product schema, AI product feed - is irrelevant if the AI crawler cannot reach your store in the first place.
OpenAI states this without ambiguity:
> "Sites that are opted out of OAI-SearchBot will not be shown in ChatGPT search answers."
Not "may not appear." Will not appear. If `OAI-SearchBot` is blocked - by an explicit Disallow or caught in a wildcard rule - your store is excluded from ChatGPT search answers regardless of everything else you do.
## The Three Types of AI Bots - Why the Difference Matters
Before listing every bot, you need to understand what each one actually does. AI crawlers fall into three distinct categories with very different purposes - and conflating them causes the most common robots.txt misconfiguration.
| Type | What it does | Examples | Ecommerce recommendation |
| **Search & indexing bots** | Builds the live index used when users ask AI questions. Cites sources, links back to your store. Directly drives product discovery. | `OAI-SearchBot`, `Claude-SearchBot`, `PerplexityBot`, `Google-Extended` | Always allow |
| **User-initiated fetchers** | Fetches your page when a specific user asks AI to visit a URL directly. May cite your product page in the response. | `ChatGPT-User`, `Claude-User`, `Perplexity-User` | Always allow |
| **Training crawlers** | Collects content to train future AI models. No attribution, no direct traffic back to your store. | `GPTBot`, `ClaudeBot`, `Applebot-Extended` | Your choice |
**The most common mistake:** blocking `GPTBot` (training) while believing it removes you from ChatGPT search results. It does not. `GPTBot` and `OAI-SearchBot` are entirely separate bots with separate purposes. Blocking training crawlers has zero effect on AI search visibility - but blocking search crawlers makes you invisible immediately.
## Every AI Bot That Matters for Magento in 2026
| Bot | Platform | Type | Impact if blocked |
| `OAI-SearchBot` | ChatGPT / OpenAI | Search index | Invisible in all ChatGPT search answers and product recommendations. **Most critical.** |
| `GPTBot` | ChatGPT / OpenAI | Training | Content excluded from future GPT training data. Does not affect current search visibility. |
| `ChatGPT-User` | ChatGPT / OpenAI | User-initiated | ChatGPT cannot fetch your pages when a user requests them directly. |
| `Claude-SearchBot` | Claude / Anthropic | Search index | Invisible in Claude's real-time web search answers. |
| `ClaudeBot` | Claude / Anthropic | Training | Content excluded from future Claude training data. |
| `Claude-User` | Claude / Anthropic | User-initiated | Claude cannot fetch your pages when a user requests them directly. |
| `PerplexityBot` | Perplexity | Search index | Invisible in Perplexity answers and product recommendations. |
| `Perplexity-User` | Perplexity | User-initiated | Perplexity cannot fetch your pages for direct user requests. |
| `Google-Extended` | Gemini / Google | Search index + training | Not cited in Gemini AI Overviews or Google Shopping AI features. |
| `Applebot-Extended` | Apple Intelligence | Training | Content excluded from Apple Intelligence training data. |
| `anthropic-ai` | Anthropic | Deprecated | Legacy name for ClaudeBot. Keep rules for backwards compatibility. |
**Anthropic expanded to three bots in early 2026.** Sites that only reference `ClaudeBot` in robots.txt are now missing `Claude-SearchBot` (live search) and `Claude-User` (user-initiated fetching). If your robots.txt was last updated before 2026, this almost certainly applies to your store.
## The Default Magento robots.txt Problem
Magento's default `robots.txt` starts with a wildcard block:
```
User-agent: *
Disallow: /index.php/
Disallow: /*?
Disallow: /checkout/
Disallow: /app/
...
```
This wildcard establishes a baseline that every bot inherits. If your deployment script, hosting provider, or a staging migration has added `Disallow: /` anywhere - AI bots are caught in it silently, with no error logged anywhere.
**Check this right now.** Open `https://yourstore.com/robots.txt` in a browser and look for `Disallow: /` on its own line. If it exists without an explicit `Allow: /` for each AI bot listed above it - every one of those bots is blocked. This affects the majority of Magento stores checked by the AEO audit module.
## Where Magento Stores robots.txt - Two Scenarios
Before editing, identify which method your store uses to serve the file. Editing the wrong one has no effect.
### Scenario A: Magento Admin (most common)
Magento can serve `robots.txt` dynamically from the database. Check whether this is active:
```
# Check if Magento manages robots.txt
bin/magento config:show design/search_engine_robots/default_robots
```
If it returns a value, Magento owns the file. Edit it via: **Content → Design → Configuration → [Store view] → Edit → Search Engine Robots → Edit custom instruction of robots.txt**.
### Scenario B: Static file in pub/
If Magento Admin changes don't show up at `yourstore.com/robots.txt`, a physical file is taking precedence. Check for it:
```
# Check if a static file exists and is being served
ls -la /var/www/html/pub/robots.txt
curl -I https://yourstore.com/robots.txt
# If no X-Magento headers appear, the file is served statically
```
Edit `pub/robots.txt` directly, or remove it to let Magento's Admin configuration take over.
**Multi-store installations:** Each store view can have its own robots.txt in Magento Admin. If you run multiple stores on different domains or subdomains, configure each one separately under Content → Design → Configuration → [select store view]. Do not assume one configuration covers all stores.
## The Complete robots.txt Configuration for Magento 2
This is the recommended configuration for Magento ecommerce stores in 2026. It explicitly allows all AI search and indexing bots, gives you a clear choice on training crawlers, and keeps Magento-specific paths protected.
```
# ============================================================
# AI SEARCH & INDEXING BOTS - Allow (critical for visibility)
# These build the index ChatGPT, Claude, Gemini, and Perplexity
# use to answer product discovery questions.
# Blocking these makes your store invisible in AI search answers.
# ============================================================
User-agent: OAI-SearchBot
Allow: /
User-agent: Claude-SearchBot
Allow: /
User-agent: PerplexityBot
Allow: /
User-agent: Google-Extended
Allow: /
# ============================================================
# USER-INITIATED FETCHERS - Allow
# Fetch your pages when a user directly asks AI about a URL.
# ============================================================
User-agent: ChatGPT-User
Allow: /
User-agent: Claude-User
Allow: /
User-agent: Perplexity-User
Allow: /
# ============================================================
# TRAINING CRAWLERS - your choice
# These collect content for model training. No direct traffic
# back, no attribution. Blocking them does NOT affect search
# visibility. Change Allow to Disallow if you prefer to opt out.
# ============================================================
User-agent: GPTBot
Allow: /
User-agent: ClaudeBot
Allow: /
User-agent: anthropic-ai
Allow: /
User-agent: Applebot-Extended
Allow: /
# ============================================================
# TRADITIONAL SEARCH ENGINES
# ============================================================
User-agent: Googlebot
Allow: /
User-agent: Bingbot
Allow: /
# ============================================================
# ALL OTHER BOTS - Standard Magento rules
# AI bots above are explicitly allowed before this wildcard.
# ============================================================
User-agent: *
Allow: /
# Magento paths - block from all crawlers
Disallow: /admin/
Disallow: /adminhtml/
Disallow: /api/
Disallow: /rest/
Disallow: /graphql
Disallow: /cron.php
Disallow: /var/
Disallow: /lib/
Disallow: /dev/
Disallow: /index.php/
Disallow: /*?SID=
Disallow: /*?___store=
Disallow: /checkout/
Disallow: /customer/
Disallow: /wishlist/
Disallow: /review/
# ============================================================
# SITEMAPS - helps all crawlers discover your pages
# ============================================================
Sitemap: https://yourstore.com/sitemap.xml
Sitemap: https://yourstore.com/llms.txt
```
**Order is not optional.** robots.txt uses first-match semantics per crawler. A bot reads the file top to bottom and stops at the first `User-agent` block that matches it. If `User-agent: *` with `Disallow: /` appears before the AI bot entries, those AI bots are permanently blocked - the rules below are never reached. The AI bot entries must always appear before the wildcard block.
## How to Update robots.txt in Magento Admin
01
Open Design Configuration
Log in to Magento Admin. Navigate to **Content → Design → Configuration**.
02
Select your store view
Click **Edit** next to the store view you want to configure. For multi-store setups: repeat for each store view separately.
03
Open Search Engine Robots
Scroll to the **Search Engine Robots** section and expand it.
04
Paste the configuration
In **"Edit custom instruction of robots.txt file"**, paste the complete configuration from above. Replace `yourstore.com` with your actual domain in the Sitemap lines.
05
Save and flush cache
Click **Save Configuration**. Then run: `bin/magento cache:flush`
06
Verify the output
Open `https://yourstore.com/robots.txt` in a browser and confirm `OAI-SearchBot`, `Claude-SearchBot`, and `PerplexityBot` all have `Allow: /`. If the file hasn't changed, Scenario B above applies - a static file is overriding the Admin configuration.
## How to Update robots.txt via SSH
If Magento Admin is not managing the file, or if you prefer a direct file edit:
```
# SSH into your server
ssh user@yourserver.com
# Navigate to Magento pub directory
cd /var/www/html/pub
# Backup existing file
cp robots.txt robots.txt.backup.$(date +%Y%m%d)
# Edit the file
nano robots.txt
# Paste the configuration, save with Ctrl+O → Enter → Ctrl+X
# Verify it's live
curl https://yourstore.com/robots.txt | grep -E "OAI-SearchBot|Claude-SearchBot|PerplexityBot"
```
## Four Mistakes That Block AI Bots in Magento
### Mistake 1 - Disallow: / left on from a staging environment
Staging environments use `Disallow: /` to prevent Google indexing. This is frequently copied to production during deployments and never removed.
**Where it comes from:**
- **Magento Admin:** Stores → Configuration → General → Design → Search Engine Robots
- **Static file:** Manually edited `pub/robots.txt` from a staging copy
- **Deployment scripts:** CI/CD pipelines that sync the full staging filesystem to production
- **Hosting provider defaults:** Managed hosts (Hypernode, Nexcess, Cloudways) sometimes apply restrictive defaults on new environments
```
# Quick check - if this returns output, you have a problem
curl -s https://yourstore.com/robots.txt | grep -n "^Disallow: /$"
```
[content truncated]
- [Magento 2 Product JSON-LD Schema for AI Search - 2026 Guide](https://angeo.dev/magento-2-product-schema-json-ld-ai-search/): Default Magento 2 product schema fails AI search. Fix offers.availability, the Hyvä gap and the GTM pitfall - with copy-paste JSON-LD and a checklist.
-
TL;DR - 2 minute version
Default Magento 2 outputs microdata - not JSON-LD. AI engines prefer JSON-LD.
- The single most common failure: `offers.availability` is missing - ChatGPT Shopping skips your product entirely.
- AI crawlers do not execute JavaScript - schema via GTM is invisible to OAI-SearchBot and PerplexityBot.
- Hyvä Theme has zero Product schema by default - neither microdata nor JSON-LD.
- This guide gives you the copy-paste fix, Magento-specific pitfalls, Hyvä solution, and a validation checklist.
[image: How to implement Product JSON-LD schema in Magento 2 for AI search engines, ChatGPT visibility and structured data optimization (2026 guide)]
Your Magento store might rank on page one in Google - and still be invisible to ChatGPT, Gemini, and Perplexity. In most cases, the reason is not robots.txt or llms.txt. It is Product schema.
AI search engines need structured product data to answer purchase queries. When they cannot parse your product data from JSON-LD, they skip your store and recommend a competitor whose schema is correct. This guide covers exactly what is missing, why, and how to fix it.
## Before vs After: What Schema Visibility Looks Like
| Setup | ChatGPT Shopping | Gemini product results | Perplexity citations |
| No schema | ❌ Invisible | ❌ Invisible | ❌ Invisible |
| Microdata only (Luma default) | ⚠️ Partially parsed | ⚠️ Partially parsed | ⚠️ Inconsistent |
| JSON-LD, no `offers.availability` | ❌ Feed validation fails | ⚠️ May appear | ⚠️ May appear |
| Full JSON-LD + availability + rating | ✅ Eligible for Shopping | ✅ Product results | ✅ Cited with price |
## Why Magento 2 Fails AI Schema by Default
Default Magento 2 (Luma theme) outputs microdata - the older `itemscope`/`itemprop` HTML attribute format:
```
```
Three problems with this for AI search:
**1. It is microdata, not JSON-LD.** Modern AI crawlers including OAI-SearchBot (ChatGPT) and Google-Extended (Gemini) prefer JSON-LD. Microdata is embedded in HTML that themes and extensions modify - it breaks easily and silently.
**2. `offers.availability` is missing.** This is the single most common failure. Without explicit availability set to a schema.org URI, ChatGPT Shopping feed validation fails automatically.
**3. AI crawlers do not execute JavaScript.** Schema injected via Google Tag Manager or any JavaScript that runs after initial page load is completely invisible to AI crawlers. Schema must be server-side rendered in the HTML source.
> **Critical:** If you use GTM to inject schema, AI engines cannot see it. This is confirmed by how OAI-SearchBot and PerplexityBot work - they parse the raw HTML response, not the rendered DOM. This is the most overlooked Magento AEO mistake.
## The Complete Copy-Paste Product JSON-LD
This is the spec-compliant JSON-LD that passes all AEO audit checks. Copy and adapt with your product data:
```
```
## Required Fields - What AI Engines Actually Need
| Field | Required for AI? | Common mistake |
| `@type: Product` | ✅ Required | Using `IndividualProduct` - both work, `Product` is preferred |
| `name` | ✅ Required | Including HTML tags in the name string |
| `offers.availability` | ✅ Required | Text string instead of URI (see table below) |
| `offers.price` | ✅ Required | Including currency symbol: `"€189"` instead of `"189.99"` |
| `offers.priceCurrency` | ✅ Required | Using symbol `€` instead of ISO code `EUR` |
| `image` | ⚠️ Strongly recommended | Relative URL instead of absolute |
| `sku` | ⚠️ Strongly recommended | Often missing entirely |
| `aggregateRating` | ⚠️ Strongly recommended | Including when `reviewCount` is 0 - this causes validation error |
| `brand` | ⚠️ Recommended | Plain string instead of `{"@type": "Brand", "name": "..."}` |
| `description` | ⚠️ Recommended | Duplicate of page title instead of unique description |
### offers.availability - Correct vs Wrong Format
| Stock status | ✅ Correct value | ❌ Wrong (silently rejected) |
| In stock | `https://schema.org/InStock` | `"In Stock"` / `"instock"` / `"available"` |
| Out of stock | `https://schema.org/OutOfStock` | `"Out of Stock"` / `"unavailable"` |
| Pre-order | `https://schema.org/PreOrder` | `"preorder"` / `"coming soon"` |
| Back order | `https://schema.org/BackOrder` | `"backorder"` |
AI parsers require the full schema.org URI. Text strings are parsed as unknown values and treated as missing. No error is shown - your product just doesn't appear.
## Configurable Products - Correct Structure
Default Magento flattens configurable product schema. If 6 of 8 size variants are in stock and 2 are not, AI engines may see "availability unclear" and suppress the listing. Correct structure uses `AggregateOffer` with per-variant `Offer` objects:
```
{
"@type": "Product",
"name": "Running Shoe",
"offers": {
"@type": "AggregateOffer",
"offerCount": 8,
"lowPrice": "89.99",
"highPrice": "89.99",
"priceCurrency": "EUR",
"availability": "https://schema.org/InStock",
"offers": [
{
"@type": "Offer",
"sku": "RS-42-BLK",
"name": "Size 42 / Black",
"availability": "https://schema.org/InStock",
"price": "89.99",
"priceCurrency": "EUR"
},
{
"@type": "Offer",
"sku": "RS-43-BLK",
"name": "Size 43 / Black",
"availability": "https://schema.org/OutOfStock",
"price": "89.99",
"priceCurrency": "EUR"
}
]
}
}
```
## Hyvä Theme - Why Schema Is Completely Missing
If your store runs on Hyvä Theme, there is zero Product schema by default - neither microdata nor JSON-LD. Hyvä is built on Alpine.js and does not include the Luma-based product template that generates microdata.
Verify:
```
curl -s https://yourstore.com/sample-product.html | grep -c 'application/ld+json'
# Returns 0 → no JSON-LD at all
curl -s https://yourstore.com/sample-product.html | grep -c 'itemscope'
# Returns 0 → no microdata either
```
The fix requires injecting JSON-LD via layout XML. Create `Vendor_Theme/layout/catalog_product_view.xml`:
```
```
> **Note:** JSON-LD injected via `` in layout XML is server-side rendered and visible to AI crawlers. This is exactly where it needs to be.
Or use [`angeo/module-rich-data`](https://packagist.org/packages/angeo/module-rich-data) which handles both Luma and Hyvä automatically without any template editing.
## How to Diagnose Your Current Schema
Run this one-liner to see exactly what schema your product pages output:
```
# Replace with a real product URL from your store
curl -s https://yourstore.com/sample-product.html | \
python3 -c "
import sys, json, re
body = sys.stdin.read()
blocks = re.findall(r'', body, re.DOTALL)
for b in blocks:
try:
d = json.loads(b)
items = d if isinstance(d, list) else [d]
for item in items:
nodes = item.get('@graph', [item])
for n in nodes:
if n.get('@type') in ('Product', 'IndividualProduct'):
print('FOUND Product schema')
offers = n.get('offers', {})
if isinstance(offers, list): offers = offers[0] if offers else {}
print('availability:', offers.get('availability', 'MISSING'))
print('price:', offers.get('price', 'MISSING'))
print('priceCurrency:', offers.get('priceCurrency', 'MISSING'))
print('aggregateRating:', 'present' if n.get('aggregateRating') else 'MISSING')
except: pass
"
```
Four possible outputs:
| Output | Meaning | Action |
| No output | No Product schema at all | Install `angeo/module-rich-data` |
| `availability: MISSING` | Schema exists, offers missing | Fix offers block |
| `availability: InStock` | Wrong format (text string) | Change to full URI |
| `availability: https://schema.org/InStock` | Correct | Re-run CLI audit to confirm |
Or use the CLI audit module for a full 9-signal AEO check:
```
composer require angeo/module-aeo-audit
bin/magento setup:upgrade && bin/magento cache:flush
bin/magento angeo:aeo:audit
```
## Implementation Options
### Option 1 - Module (recommended, 5 minutes)
```
composer require angeo/module-rich-data
bin/magento setup:upgrade && bin/magento cache:flush
```
The [`angeo/module-rich-data`](https://packagist.org/packages/angeo/module-rich-data) module injects server-side JSON-LD for all product pages automatically. Works on Luma and Hyvä. Includes Product, Organization, BreadcrumbList, WebSite, and FAQPage schema. MIT licensed, free.
### Option 2 - Manual phtml template
Create `app/design/frontend/Vendor/Theme/Magento_Catalog/templates/product/json-ld.phtml`:
```
getProduct();
$schema = [
'@context' => 'https://schema.org/',
'@type' => 'Product',
'name' => $product->getName(),
'sku' => $product->getSku(),
'offers' => [
'@type' => 'Offer',
'price' => (string) $product->getFinalPrice(),
'priceCurrency' => $block->getCurrencyCode(),
'availability' => $product->isAvailable()
? 'https://schema.org/InStock'
: 'https://schema.org/OutOfStock',
'itemCondition' => 'https://schema.org/NewCondition',
],
];
?>
```
### Option 3 - GTM
Not recommended for AEO. GTM injects schema after page load via JavaScript. AI crawlers parse raw HTML and do not execute JavaScript - schema injected via GTM is completely invisible to OAI-SearchBot, PerplexityBot, and Google-Extended. If you currently use GTM for schema, you have no AI-visible schema regardless of what Google Tag Manager shows.
## Validation Checklist
- ☐ JSON-LD format (not microdata or GTM-injected)
- ☐ `offers.availability` set to full schema.org URI
- ☐ `offers.price` is a number string without currency symbol
- ☐ `offers.priceCurrency` is ISO 4217 code (EUR, USD, GBP)
- ☐ `image` contains at least one absolute URL
- ☐ `aggregateRating` omitted if `reviewCount` is 0
- ☐ Schema server-side rendered (visible in `curl` output)
- ☐ Hyvä: schema injected via layout XML ``
- ☐ Configurable products use `AggregateOffer` with per-variant `Offer`
- ☐ Validated at [validator.schema.org](https://validator.schema.org) - zero errors
## FAQ
[content truncated]
- [Magento 2 Audit: The Complete 2026 Guide to Technical, SEO, Performance & AI-Visibility Checks](https://angeo.dev/magento-2-audit/): A Magento 2 audit checks four layers - technical, SEO, performance and AI-search visibility (AEO). See what each covers and score your store free.
# Magento 2 Audit: The Complete 2026 Guide to Technical, SEO, Performance & AI-Visibility Checks
A Magento 2 audit is a structured review of a store across four layers - technical health, on-page SEO, performance, and AI-search visibility (AEO) - that produces a scored list of specific, prioritised fixes. This page is the pillar reference: what each layer checks, how to run the checks yourself with free tools, and when a store needs a professional audit instead of a self-assessment.
·
Updated 22 July 2026
*Tooling and platform guidelines change. Verify current Magento versions, Google guidelines, and AI-crawler user-agents as you work through the checks below.*
## TL;DR - what a Magento 2 audit covers in 2026
- A complete Magento 2 audit spans **four layers**: technical, on-page SEO, performance, and - new since 2025 - **AI-search visibility (AEO)**.
- Traditional tools (Screaming Frog, Lighthouse, Google Search Console) cover the first three layers well but say nothing about whether ChatGPT, Gemini, Perplexity, or Claude can find and recommend your store.
- The AEO layer has its own checks: AI-crawler access in `robots.txt`, an `llms.txt` content map, JSON-LD `Product` schema with a valid `offers.availability`, and a spec-compliant product feed.
- You can run a first-pass audit yourself for free; a professional audit adds prioritisation, a written roadmap, and validation against real AI-engine behaviour.
- Run `bin/magento angeo:aeo:audit` (free, open-source, MIT) to score the AEO layer in about two minutes.
## What is a Magento 2 audit?
A Magento 2 audit is a systematic evaluation of an Adobe Commerce or Magento Open Source store that identifies technical defects, SEO gaps, performance bottlenecks, and AI-visibility problems, then ranks them by impact so a team knows what to fix first. It is diagnostic, not cosmetic: the deliverable is a scored report with concrete remediation steps, not a general opinion about the store.
In 2026 the term covers more than it used to. A store can pass a classic SEO audit - clean structure, fast pages, good Google rankings - and still be invisible to AI answer engines, because those systems evaluate a separate machine-readable layer. A modern Magento 2 audit therefore treats AI-search visibility as a first-class layer alongside the three traditional ones.
## The four layers of a Magento 2 audit
### 1. Technical audit - is the store structurally sound?
The technical layer checks the foundations that everything else depends on:
- **Crawlability & indexation** - `robots.txt` rules, XML sitemap validity, canonical tags, noindex leaks, and duplicate URLs from layered navigation.
- **Code & extension health** - core patches applied, third-party module conflicts, deprecated code, and custom code that overrides core classes unnecessarily (the *magento 2 code audit* concern).
- **Platform & security** - running a supported release line, security patches current, and admin/checkout paths excluded from crawling. See the [Adobe Commerce 2.4.7 end-of-life options](https://angeo.dev/adobe-commerce-2-4-7-end-of-life-options/) for supported-version context.
- **Infrastructure** - caching (Varnish/FPC) configured, indexers healthy, cron running, and Redis/OpenSearch tuned.
### 2. On-page SEO audit - can search engines understand each page?
The on-page layer checks how well individual pages communicate their meaning:
- Title tags, meta descriptions, and heading hierarchy across category, product, and CMS pages.
- Structured data - microdata vs JSON-LD, and whether product entities are complete (this overlaps directly with the AEO layer below).
- Internal linking depth, breadcrumb consistency, and orphaned pages.
- Thin, duplicated, or auto-generated product copy that neither shoppers nor AI systems can use.
### 3. Performance audit - is the store fast enough to rank and convert?
The performance layer checks Core Web Vitals and the server-side factors behind them:
- Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift on real category and product templates.
- Time to First Byte, full-page-cache hit rate, and JavaScript bundle size (a recurring Hyvä vs Luma difference).
- Image delivery - modern formats, correct sizing, and lazy-loading that does not hide content from crawlers.
### 4. AI-search visibility audit (AEO) - can ChatGPT, Gemini & Perplexity recommend the store?
This is the layer most audit checklists still skip. AI answer engines pick one or two stores to recommend rather than listing ten links, and they decide using signals that classic SEO tools never inspect:
- **AI-crawler access** - whether search-time agents such as OAI-SearchBot, PerplexityBot, and Claude-SearchBot are allowed in `robots.txt`. Blocking them removes the store from generated answers entirely.
- **Content map** - presence of a valid `llms.txt` served at the domain root without redirects.
- **Product schema** - JSON-LD `Product` with a populated `offers.availability`; without it, ChatGPT Shopping skips the product.
- **Product feed** - a spec-compliant feed for agentic-commerce protocols.
For the full method behind this layer, see the [Magento 2 AEO guide](https://angeo.dev/magento-2-aeo-guide/). To measure it directly, the [free AEO audit](https://angeo.dev/ai-magento-audit/) returns a scored report in about two minutes.
## Which audit layer needs which tool?
| Layer | What it answers | Typical tools | Covered by classic SEO tools? |
| Technical | Is the store structurally sound and secure? | Screaming Frog, Search Console, `bin/magento` CLI | Yes |
| On-page SEO | Can search engines understand each page? | Screaming Frog, Ahrefs/Semrush, Rich Results Test | Yes |
| Performance | Is the store fast enough to rank and convert? | Lighthouse, PageSpeed Insights, WebPageTest | Yes |
| AI visibility (AEO) | Can AI engines find and recommend the store? | `angeo:aeo:audit` CLI, manual crawler-log review, schema validators | No - needs dedicated checks |
*The first three layers are well served by mature tooling. The fourth is where most Magento stores have an untested blind spot in 2026.*
## How to run a first-pass Magento 2 audit yourself
1. **Check supported version & patch level** - confirm the store runs a supported release line and has current security patches.
2. **Crawl the store** - run Screaming Frog to surface broken links, redirect chains, missing titles, and duplicate URLs.
3. **Validate Core Web Vitals** - test real category and product templates in PageSpeed Insights, not just the homepage.
4. **Inspect structured data** - open a product page and check for JSON-LD `Product` with a populated `offers.availability`. See the [Magento 2 Product JSON-LD schema guide](https://angeo.dev/magento-2-product-schema-json-ld-ai-search/).
5. **Review AI-crawler access** - confirm `robots.txt` allows search-time AI agents. See [how to fix robots.txt for ChatGPT and Gemini](https://angeo.dev/magento-2-robots-txt-chatgpt-gemini-ai-bots/).
6. **Score the AEO layer** - run `bin/magento angeo:aeo:audit` or the [2-minute self-assessment](https://angeo.dev/ai-magento-audit/).
## When do you need a professional Magento audit instead?
A self-assessment tells you *where* you stand. A professional audit adds three things a checklist cannot: prioritisation by revenue impact, a written remediation roadmap with effort estimates, and validation against how AI engines actually behave for your category rather than in theory. It is worth it when the store is large, the stakes are a replatform or migration decision, or when repeated internal fixes have not moved the numbers.
angeo.dev runs a structured 3-week [AI Commerce Audit](https://angeo.dev/ai-commerce-audit/) across eight signal categories, delivered as a scored report with a prioritised roadmap. If you only need the AI-visibility layer checked first, start with the [free AEO self-assessment](https://angeo.dev/ai-magento-audit/).
## Magento 2 audit - frequently asked questions
### What is a Magento SEO audit?
A Magento SEO audit reviews how well a store communicates with search engines across technical health, on-page factors, and performance - and, in 2026, how visible it is to AI answer engines. It produces a prioritised list of fixes rather than a single score.
### How long does a Magento 2 audit take?
A free self-assessment of the AI-visibility layer takes about two minutes. A full manual audit of a mid-size store typically takes a few days of analysis; a professional engagement with a written roadmap runs about three weeks.
### What is a Magento 2 code audit?
A Magento 2 code audit is the technical-layer review focused on custom and third-party code: unnecessary core overrides, module conflicts, deprecated APIs, missing patches, and security exposure. It is one part of a complete audit, not a substitute for it.
### Can I audit my Magento store for free?
Yes. Classic layers can be checked with free tools (Screaming Frog's free tier, Lighthouse, Google Search Console), and the AI-visibility layer can be scored with the free, open-source `angeo:aeo:audit` CLI or the 2-minute self-assessment.
### Does a Magento audit cover AI search visibility?
A 2026-appropriate audit does. Most legacy checklists stop at traditional SEO and leave AI visibility untested, which is exactly where many stores lose discovery as shoppers move from searching to asking AI assistants.
## Next step
Start with the [free Magento AEO self-assessment](https://angeo.dev/ai-magento-audit/) to score the layer most likely to be your blind spot, then read the [Magento 2 AEO guide](https://angeo.dev/magento-2-aeo-guide/) for the full remediation method. For a full professional review, book the [AI Commerce Audit](https://angeo.dev/ai-commerce-audit/).
- [AI Visibility for B2B Magento Stores & Agent Procurement](https://angeo.dev/magento-b2b-ai-visibility/): Why B2B is where agentic commerce hits first: what AI procurement agents can't see in Magento B2B by default, and the priority order to fix it - specs first.
# AI Visibility for B2B Magento Stores: When the Buyer Is an Agent, Not a Person
Last verified July 2026. Agentic-commerce protocols and AI procurement behavior are early and moving fast - treat specifics as a snapshot and verify current spec versions before implementation.
**TL;DR - 2 minute version**
- Magento B2B AI visibility matters more than any consumer vertical: agentic commerce arrives here with the most force: procurement is repetitive, spec-driven, and increasingly delegated to AI assistants that shortlist suppliers.
- Magento's B2B feature set (company accounts, shared catalogs, negotiable quotes, tiered pricing) is powerful - but almost none of it is exposed in a machine-readable way an AI agent can act on by default.
- The winning B2B signal isn't a marketing description - it's **structured, accurate spec and availability data** an agent can compare against a requirement.
- Because B2B runs on Adobe Commerce far more than Shopify, this is a *merchant-controlled* AEO problem: you own the stack, so you own the responsibility to make it agent-readable.
## Why B2B is the sharpest case for AI visibility
Consumer discovery through AI is real, but B2B procurement is where the economics bite hardest. A purchasing manager sourcing 400 units of a fastener to a spec doesn't want to browse ten supplier sites - they (or increasingly, an assistant acting for them) want a shortlist of suppliers who demonstrably stock the exact part, at a price, with availability. That is an answer-engine task, not a blue-links task. If your Magento B2B catalog can't be read and compared by an agent, you're not on the shortlist.
## What Magento B2B has - and what AI can't see
| Magento B2B capability | Visible to a human buyer | Visible to an AI agent by default |
| Company accounts & shared catalogs | Yes (after login) | No - gated content is opaque to crawlers |
| Tiered / negotiated pricing | Yes | Rarely - not exposed as structured data |
| Product specs & attributes | Yes, in tabs | Only if emitted as structured, server-rendered data |
| Stock / availability | Yes | Only via `offers.availability` in JSON-LD or a feed |
| Requisition lists / reorder | Yes | Only via an agentic protocol endpoint (ACP/UCP/MCP) |
## The B2B AEO priority order
The general [AEO foundations](https://angeo.dev/magento-2-aeo-guide/) apply, but B2B changes the emphasis:
1. **Structured spec data first.** B2B agents match on specifications, not adjectives. Every filterable attribute should be machine-readable, not buried in a description tab.
2. **Accurate, live availability.** A B2B agent recommending an out-of-stock supplier is worse than useless - `offers.availability` and feed freshness matter more here than anywhere. See the [JSON-LD guide](https://angeo.dev/magento-2-product-schema-json-ld-ai-search/).
3. **Decide what to expose publicly.** Gated pricing protects margin but hides you from agents. A common pattern: expose spec + availability + "request quote" publicly, keep negotiated pricing behind the account.
4. **Agentic endpoints for reorder-heavy catalogs.** Where repeat procurement dominates, an [ACP/UCP](https://angeo.dev/acp-vs-ucp-for-magento-2/) feed or an [MCP checkout](https://angeo.dev/docs/mcp-checkout/) endpoint lets an agent actually transact, not just discover.
**Merchant-controlled by default:** B2B lives on Adobe Commerce / Magento far more than on platform-mediated systems like Shopify. That means no one syndicates your catalog to AI for you - the upside is full control, the cost is that every signal is your job. Background: [Merchant-Controlled AEO](https://angeo.dev/merchant-controlled-aeo/) and [Shopify vs Magento for AI commerce](https://angeo.dev/shopify-vs-magento-ai-commerce-aeo-2026/).
## Where to start
Run the free [AEO self-assessment](https://angeo.dev/ai-magento-audit/) or the CLI audit (`bin/magento angeo:aeo:audit`) to see how much of your B2B catalog is currently readable by an AI agent - then prioritize spec and availability data before anything cosmetic.
## FAQ
### If my B2B pricing is behind login, can AI still recommend me?
Yes, if you expose enough publicly for an agent to know you carry the right product with availability. A common approach is public spec and availability plus a "request quote" path, with negotiated pricing kept behind the account.
### Do B2B agents care about product descriptions?
Less than consumer agents. B2B matching is spec-driven - accurate structured attributes and availability outweigh marketing prose.
### Is this Adobe Commerce only, or Magento Open Source too?
The AEO signals apply to both. Some B2B features (company accounts, shared catalogs) are Adobe Commerce B2B features, but the structured-data and agent-readability work is platform-common.
- [How to Prepare Your Magento 2 Store for ChatGPT Shopping (ACP Feed + Data Requirements)](https://angeo.dev/magento-2-chatgpt-shopping-registration/): Products not showing in ChatGPT Shopping? Magento 2 walkthrough: pre-check, ACP product feed, OpenAI merchant application, and conformance validation.
ChatGPT processes over 50 million shopping queries per day. Appearing in those results is not automatic for Magento stores - it requires a deliberate application process, a spec-compliant product feed, and passing OpenAI's conformance checks.
This guide walks through the entire process: from the pre-check that determines if your store is ready, to the application, to the ongoing cron setup that keeps your feed current.
**Shopify and Etsy merchants:** have integrations, but visibility is not guaranteed. This guide is for Magento.
[image: How to Prepare Your Magento 2 Store for ChatGPT Shopping]
How to Prepare Your Magento 2 Store for ChatGPT Shopping
## Before You Apply: The Pre-Check
OpenAI's conformance checks verify technical requirements before granting production access. Stores that fail the pre-check go into a review queue and receive vague rejection emails. Do the pre-check yourself first.
```
bin/magento angeo:aeo:audit
✓ PASS robots.txt - OAI-SearchBot and GPTBot allowed
✓ PASS llms.txt - store content map present
✓ PASS Product Schema - JSON-LD with offers.availability
✗ FAIL AI Product Feed - no feed found
```
Signal #5 (AI Product Feed) will fail until the next step. Signals #1, #2, and #3 must all PASS before applying.
## Step-by-Step Registration
01
#### Install the product feed modules
`composer require angeo/module-openai-product-feed angeo/module-openai-product-feed-api`
Then `bin/magento setup:upgrade && bin/magento cache:flush`
02
#### Configure seller information
Go to **Stores → Configuration → Angeo → Product Feed API**. Fill in: seller name, target country (ISO 3166 two-letter code, e.g. `US`), and policy page URLs - privacy policy, returns, shipping, terms. These populate `seller.links` on every product and are merchant credibility signals in OpenAI's scoring.
03
#### Generate and verify the feed
Run `bin/magento angeo:aeo:feed:generate` to produce the `.jsonl.gz` feed file. Then spot-check the output:
`bin/magento angeo:aeo:feed:validate`
Confirm: each product has a `variants` array, prices are correct, `availability.status` is present, and `seller.links` has at least two policy URLs.
04
#### Verify promotions output
Active Magento cart price rules should appear automatically as ACP promotions with `active_period`, `benefits`, and `status: "active"`. Run `bin/magento angeo:aeo:feed:validate --type=promotions` to confirm.
05
#### Apply at chatgpt.com/merchants
Submit your store URL and business details. OpenAI tests schema compliance, HTTP response codes, and feed integrity. Onboarding is currently **US-only(availability may vary by region)** and available to approved partners - you will be placed on a waitlist.
06
#### Receive SFTP endpoint and push the feed
After approval, OpenAI provides a **private SFTP endpoint** for your store. Push your `.jsonl.gz` feed file to this endpoint - do not host the feed publicly on your website. Submit a sample first; after it passes validation, push the full catalog.
07
#### Set up 15-minute cron for real-time updates
OpenAI accepts feed refreshes every 15 minutes. Full feed re-submission is required each time - there is currently no incremental update support. Stale availability data - out-of-stock products showing as available - is the most common reason products get suppressed after initial approval.
## Feed Format: What OpenAI Actually Accepts
The original article's feed example showed a JSON structure that resembled the Checkout API payload. The actual product feed format is different.
OpenAI accepts two formats for the product feed file:
| Format | Extension | Notes |
| JSON Lines | `.jsonl.gz` | Recommended. One product object per line. Handles nested variants cleanly. |
| CSV | `.csv.gz` | Works for flat catalogs. Variant structures need to be flattened. |
**Note:** TSV and XML were in OpenAI's original spec announcement but have since been removed from the supported formats. Always check the [official feed spec](https://developers.openai.com/commerce/product-feeds/spec) for the current list.
The feed is pushed to a **private SFTP endpoint OpenAI provides** after merchant approval. It is not a public REST endpoint you expose on your store. This is a key difference from how the original article presented it.
## The Price Format: Minor Units vs Decimal
The single most common implementation error across all ACP integrations. Price must be sent in **ISO 4217 minor units as an integer** - €14.99 = `1499`, $149.00 = `14900`. Sending `14.99` as a float fails schema validation with a non-obvious error message.
The module handles this automatically: `(int) round($price * 100)`. But if you are building a custom integration or mapping from a Google Shopping feed, this is the field to double-check first.
## What OpenAI's Conformance Check Validates
| Check | What it verifies | Module that handles it |
| Feed schema | Required fields present, correct data types, valid URIs | ProductMapper |
| Price format | Integer minor units, ISO 4217 currency code | ProductMapper |
| Availability flags | `enable_search` and `availability.status` present | ProductMapper |
| Promotion schema | `benefits` array with type, dates, `status` field | PromotionMapper |
| Seller links | At least 2 policy URLs present | Admin config → seller.links |
| Product IDs | Unique, stable, no duplicates across the feed | ProductMapper |
## No Fees for Discovery
Product discovery results in ChatGPT are currently organic and unsponsored. There is no cost to submit a product feed or appear in shopping results. The 4% transaction fee that was announced with Instant Checkout applied only to completed in-chat purchases - and OpenAI is now moving away from that model toward merchant-owned checkout experiences. As of April 2026, there are no fees on purchases that start in ChatGPT.
**After approval:** ChatGPT merchant status does not guarantee immediate product appearances. The feed needs to be indexed, which typically takes 48-72 hours after approval. Products with complete Product JSON-LD schema, high availability accuracy, rich descriptions, and active promotions appear first.
## Checklist Before Submitting
- `bin/magento angeo:aeo:audit` - robots.txt, llms.txt, Product schema all PASS
- Feed generates without errors and produces valid `.jsonl.gz`
- Each product has `variants`, correct prices in minor units, `availability.status`
- Seller information complete: name, country, at least 2 policy URLs
- Active promotions appear in promotions output with `status: "active"`
- 15-minute cron configured for post-approval updates
From zero to ChatGPT Shopping in 90 minutes. All modules free, MIT licensed.
[Install Feed API →](https://packagist.org/packages/angeo/module-openai-product-feed-api)
[Free AEO Self-Assessment](https://angeo.dev/ai-magento-audit/)
## Agentic commerce
ACP, UCP and MCP: what each protocol does, which clients use it, and what to implement first.
- [MCP for Magento](https://angeo.dev/magento-mcp-server/): An MCP server gives AI assistants a live connection to your Magento catalogue instead of a static file. What it does, what it does not do, and a real order placed by Claude on video.
# MCP for Magento 2: what a Model Context Protocol server actually does
A shopper asks an assistant whether a product is in stock. Without an MCP server, the answer comes from whatever your store looked like the last time something crawled it - hours ago, or weeks. **With one, the assistant asks your store and reads back what is actually there.** Then, if you let it, places the order.
Everything below is based on a real Magento store, not a mocked demo.
Verified August 2026. The Model Context Protocol is young and client support changes frequently - re-check assistant capabilities against vendor documentation before building on any specific behaviour described here.
## A real order, start to finish
This is not a simulation. Order 000000005 exists in a live Magento store, and Claude placed it.
Catalogue search, cart, a real shipping quote, a placed order - no browser automation, no scripted demo path, nothing staged for the recording.
[image: Claude placing a real order on a Magento 2 store via MCP - video]
▶ Watch the checkout
Recorded on `demo.angeo.dev`. Playback loads YouTube only after you press play - nothing third-party is requested before that.
The same session as a transcript. Every monospace line is a tool call the assistant made to Magento; the shopper never sees these.
Shopper
I want to buy a Fusion Backpack.
→ search_products → get_product
Assistant
Found it - Fusion Backpack, SKU 24-MB02, $59, in stock.
→ create_cart → add_to_cart
Assistant
Added. Subtotal $59.
Shopper
Ship it to me - here are my details.
→ get_shipping_methods → set_shipping_information
Assistant
One method available: Flat Rate, fixed $10.00. Subtotal $59 plus $10 shipping - $69.00 USD. Shall I place the order?
Shopper
Yes.
→ place_order
Assistant
Order 000000005, status pending, $69.00 USD. Here is your payment link.
Transcript of the session in the video above. Price, stock and shipping all resolved through Magento's own rules - the assistant invented none of them.
Three details worth noticing, because each one answers a question people ask next:
The shipping quote is real. Flat Rate at $10.00 came from the store's own configuration, not from a guess about typical delivery costs.
`place_order` ran only after an explicit yes. The assistant presented the full total and stopped - that behaviour is enforced server-side, not asked for in a prompt.
The order came back **pending, with a payment link**. The assistant never touches card details; payment completes through the store's own gateway, outside the conversation entirely. That is a deliberate design decision, and the reason this stays clear of PCI scope. The [full write-up of this session](https://angeo.dev/ai-agent-checkout-in-magento-2-claude-places-a-real-order-via-mcp/) covers the payment question in depth.
## What MCP is
An MCP server is a live API that AI assistants already know how to talk to.
The protocol behind that API - the Model Context Protocol - is an open standard for connecting assistants to external systems. Rather than each vendor inventing its own plugin format, a system exposes one endpoint and any conforming client can use it.
Major assistants, including Claude, ChatGPT, Perplexity, Grok and Mistral Le Chat, support remote MCP servers in varying forms, with availability differing by plan. You implement the protocol once instead of building for each vendor separately.
## Why the answer is current
Everything else in AEO produces artefacts that AI systems fetch on their own schedule. MCP produces a surface they query on yours. The difference shows up as two different paths for the same question:
Without MCP
Shopper asks about a product
↓
Assistant recalls what it crawled or was fed
↓
Snapshot from the last crawl or feed refresh
↓
Answer that may already be wrong
With MCP
Shopper asks about a product
↓
Assistant calls a tool on your endpoint
↓
Magento service layer - live price, live stock
↓
Answer from the store itself
The right-hand path also skips page rendering entirely - no HTML to parse, no JavaScript to wait for.
| Mechanism | Direction | Freshness | Answers | Best for |
| llms.txt | Crawler fetches a file | As fresh as the last cron run | What the store is and sells | Being found and understood |
| ACP feed | Merchant pushes a file | As fresh as the refresh interval | The full catalogue | Appearing in shopping results |
| Product JSON-LD | Crawler reads a page | As fresh as the last crawl | One product, per page | Being extracted correctly |
| MCP server | Agent queries live | Current, per request | Whatever the agent asks | Staying accurate mid-conversation |
None of these replaces another. A feed is how you get into a shopping result; a live connection is how the conversation stays accurate once it starts.
## What an agent can do - and what it cannot
The base server exposes four read-only tools: store information, the category tree, product search with filters, and a full product card with description, attributes, price and stock.
**Nothing in the base install changes state.** It cannot create anything, cannot modify anything, and cannot spend money.
Installing it is safe and reversible. The server only exposes the same catalogue information your storefront already makes public.
Checkout is a separate, deliberate step. Adding the checkout module brings six more tools - the ones visible in the transcript above - for ten in total.
The split matters more than the tool count. Read access and write access are different decisions carrying different risk, so they are different installs rather than a configuration flag you have to remember to leave off. What stops an agent doing damage covers the write side in detail.
## The honest part: this is not a discovery channel
**An MCP server will not make ChatGPT recommend your store.** Nobody finds you through your MCP endpoint. It does nothing until a person has already connected to it - which means they already knew you existed.
This is worth stating plainly because the surrounding marketing rarely does. Discovery is the job of the other signals: crawler access in [robots.txt](https://angeo.dev/magento-2-robots-txt-chatgpt-gemini-ai-bots/), an [llms.txt content map](https://angeo.dev/how-to-generate-llms-txt-for-magento-2-in-5-minutes/), complete [Product JSON-LD](https://angeo.dev/magento-2-product-schema-json-ld-ai-search/), and a [registered product feed](https://angeo.dev/magento-2-chatgpt-shopping-registration/). Those put you in an answer. MCP is what happens after.
One qualifier. Assistant vendors run connector directories - catalogues of MCP servers a user can browse and add. A listing there is a genuine discovery surface, but it is a directory listing rather than a property of the protocol, and it requires being accepted. Treat it as a separate channel to apply for, not something an endpoint earns by existing.
## Who it is for right now
### Repeat and B2B purchasing
A buyer who reorders the same consumables every month does not need to be discovered - they need the reorder to take thirty seconds. Procurement is repetitive and specification-driven, which is exactly the work that gets delegated to an assistant first. This is the strongest near-term case, and [B2B stores are best positioned for it](https://angeo.dev/magento-b2b-ai-visibility/).
### Your own team
The most immediately useful deployment is often internal. Install the read-only server, connect your own assistant, and merchandisers can interrogate the catalogue in plain language - without writing SQL or waiting on a developer.
Example - internal use
"Which products in Outdoor are in stock but have no images?"
"How many SKUs are missing a GTIN?"
"What is the price of SKU 24-MB02 across all four store views?"
Answered in the chat, against live data, by someone who has never opened a database client. No customer needs to be involved for this to pay off in the first week.
### An audience that already follows you
If you have customers who would plausibly add your store to their assistant, the connection is worth offering. If you do not, an MCP endpoint is infrastructure with nobody on the other end.
## What stops an agent doing damage
Letting a language model touch a live store is a reasonable thing to be nervous about. The defences that matter are enforced in Magento, not requested in a prompt - a model that misreads an instruction still cannot exceed what the server permits.
- **Read-only by default.** The base install exposes nothing that changes state.
- **Server-side rate limiting.** An agent stuck in a loop cannot turn your catalogue into an outage.
- **Guest checkout only.** No customer accounts, no order history, no stored payment methods. The exposure of a compromised session is one cart.
- **No card data.** As in the transcript above, the order lands pending and payment completes through your own gateway or a payment link - outside the conversation.
- **Order guardrails.** Configurable caps on order value and item count, plus per-IP limits on placement.
- **Confirmation before purchase.** Order placement is annotated as destructive, so assistants stop and ask. It is never called autonomously.
Design decision worth knowing
If checkout tools are enabled but the endpoint does not require authentication, **the checkout tools hide themselves** and a critical notice appears in the admin. An open checkout endpoint would let anyone on the internet place orders anonymously - so rather than trusting the merchant to notice, the module refuses to expose them. The read-only catalogue tools keep working.
## MCP, ACP and UCP are not competing
They are frequently confused because all three involve AI agents and commerce. They solve different steps:
| Protocol | Job | Who talks to it |
| MCP | Give any assistant live, structured access to a system | Any MCP client |
| ACP | Get a catalogue into ChatGPT's shopping surface | OpenAI |
| UCP | Let an agent verify a merchant and transact on Google surfaces | Google surfaces and conforming agents |
MCP is vendor-neutral and general-purpose; the other two are commerce-specific and tied to particular ecosystems. For the sequencing argument between the commerce protocols, see [ACP vs UCP for Magento 2](https://angeo.dev/acp-vs-ucp-for-magento-2/).
## The part that trips people up
Your store's own `/mcp` path authenticates with a bearer token and has no OAuth flow, which means it cannot be pasted directly into an assistant's connector settings. Assistants expect an OAuth-capable endpoint. Adding a custom connector with your raw store path will fail, and the failure is not obvious from the error.
Plan for that before promising anyone a one-click button. The full connection flow per assistant - including the OAuth requirement and the landing-page pattern for shoppers without an account - is in [the MCP Checkout documentation](https://angeo.dev/docs/mcp-checkout/).
## Getting started
Install the read-only server first and leave it there for a while. It is safe, reversible, and enough to find out whether anyone actually connects.
```
composer require angeo/module-mcp-server
bin/magento setup:upgrade
# confirm the endpoint answers an MCP handshake
curl -s -X POST https://your-store.com/mcp -d '{"method":"initialize"}'
```
Both modules are MIT licensed with no licence key, account or telemetry. Version requirements live in the [compatibility matrix](https://angeo.dev/docs/compatibility/), read from each package's `composer.json` rather than restated here.
Add checkout only once you have a reason to. It does what the video shows - which is the point, and also the reason to exercise it on staging first.
## What to expect
[content truncated]
- [ACP vs UCP for Magento 2: Which Agentic Commerce Protocol Should You Implement First?](https://angeo.dev/acp-vs-ucp-for-magento-2/): ACP vs UCP for Magento 2 - you don't have to pick one. Ship the ACP feed first, prepare the UCP manifest second. Most groundwork is shared.
**TL;DR.**
- The question "ACP or UCP" assumes you have to pick one - you don't.
- [OpenAI's](https://en.wikipedia.org/wiki/OpenAI) **ACP** shifted away from native checkout in March 2026 - it's now a discovery and feed protocol.
- [Google's](https://en.wikipedia.org/wiki/Google) **UCP** is the live agentic-checkout standard - US-only early access in mid-2026.
- For Magento 2 merchants: ship the ACP feed first, prepare the UCP manifest second.
- Most groundwork is shared infrastructure - clean schema, accurate feeds, defined policies - and survives any protocol shift.
Every [Magento](https://en.wikipedia.org/wiki/Magento) merchant we talk to in 2026 asks the same question in some form: "Should I build for [ChatGPT](https://en.wikipedia.org/wiki/ChatGPT) or for [Gemini](https://en.wikipedia.org/wiki/Google_Gemini)? OpenAI or Google? ACP or UCP?"
It's the obvious question. It's also the wrong one. It assumes the two protocols compete for the same job. They don't. Once you understand what each one actually does - and what changed after OpenAI pivoted away from Instant Checkout in March 2026 - the *order* of implementation matters far more than the *choice* between them.
This guide unpacks both protocols at the level a Magento 2 store owner or technical lead needs, compares them side by side, and gives you a phased roll-out. The agentic-commerce landscape is moving fast, so we've also flagged the parts that are most likely to change.
[image: ACP vs UCP for Magento 2 - agentic commerce protocols comparison for ChatGPT and Gemini shopping]
ACP (OpenAI) and UCP (Google) - two agentic commerce protocols, one Magento 2 store.
## Key terms
**ACP - Agentic Commerce Protocol**
[OpenAI's open standard](https://openai.com/index/buy-it-in-chatgpt/), co-developed with [Stripe](https://en.wikipedia.org/wiki/Stripe,_Inc.). Defines a product feed format (`.jsonl.gz`) and an optional checkout layer that was deprecated in March 2026. The feed surface remains active and is the primary discovery channel for ChatGPT Shopping.
**UCP - Universal Commerce Protocol**
[Google's open standard for agentic commerce](https://developers.googleblog.com/under-the-hood-universal-commerce-protocol-ucp/), co-developed with [Shopify](https://en.wikipedia.org/wiki/Shopify), Stripe, Etsy, Walmart, Target, Wayfair, plus 20+ endorsers including [Visa](https://en.wikipedia.org/wiki/Visa_Inc.), [Mastercard](https://en.wikipedia.org/wiki/Mastercard), and [Adyen](https://en.wikipedia.org/wiki/Adyen). Announced at NRF on January 11, 2026. Spec at [ucp.dev](https://ucp.dev/). Includes live agentic checkout on Google surfaces.
**Q: Is ACP dead?**
No. OpenAI moved away from *Instant Checkout*, which was one ACP capability. The feed surface, OAI-SearchBot integration, and ChatGPT Apps platform are all active. ACP feeds have arguably become more important since March 2026, because they're now the primary way to be discovered in ChatGPT Shopping.
**Q: Is UCP a Google-only thing?**
No. UCP is open source, vendor-agnostic, and surface-agnostic. Google built the first reference implementation (AI Mode in Google Search, Gemini), but the protocol is designed for any AI agent, retailer, or payment provider. [Salesforce](https://en.wikipedia.org/wiki/Salesforce), [Stripe](https://en.wikipedia.org/wiki/Stripe,_Inc.), and Commerce Inc. have publicly committed to implementing UCP support.
**Merchant of Record**
The legal entity responsible for the sale - handling taxes, refunds, and customer relationships. Under both ACP and UCP, the Magento merchant remains the Merchant of Record. The protocols are communication layers, not marketplaces.
## What is ACP (after March 2026)
ACP was co-developed by OpenAI and Stripe, open-sourced from day one, and launched in September 2025. The original promise: AI agents complete purchases natively inside ChatGPT.
That direction [changed significantly on March 24, 2026](https://openai.com/index/powering-product-discovery-in-chatgpt/). OpenAI announced it is moving away from a standalone Instant Checkout experience and is "allowing merchants to use their own checkout experiences while we focus our efforts on product discovery." According to industry reporting, only a very small number of Shopify merchants ever went live with native ACP checkout before this shift.
What survived - and matters more than ever:
| ACP component | Status as of mid-2026 |
| Native in-ChatGPT checkout | Discontinued |
| ACP product feed (`.jsonl.gz`) | Active and required |
| ACP promotions feed | Active |
| OAI-SearchBot crawler integration | Active |
| Stripe-as-payment-rail | Optional, used in Apps |
| ChatGPT Apps platform (Walmart-style) | Active, opt-in |
**What ACP means for a Magento merchant today:** ship an OpenAI-compatible product feed, register at [chatgpt.com/merchants](https://chatgpt.com/merchants), get your products into ChatGPT's discovery layer. The purchase itself happens on **your Magento checkout** - much like a regular referral, but the referrer is a chat conversation instead of a Google SERP.
Large merchants can additionally build a dedicated ChatGPT App. Walmart announced one in March 2026, with account linking, loyalty integration, and in-ChatGPT browsing of their catalog. The App platform is optional and best suited to merchants with engineering bandwidth to spare.
→ The Magento module that exposes the ACP feed: [`angeo/module-openai-product-feed-api`](https://packagist.org/packages/angeo/module-openai-product-feed-api)
→ The static file generator: [`angeo/module-openai-product-feed`](https://packagist.org/packages/angeo/module-openai-product-feed)
→ [How to Register Your Magento 2 Store for ChatGPT Shopping](https://angeo.dev/magento-2-chatgpt-shopping-registration/)
## What is UCP
Unlike ACP today, UCP **does** include live agentic checkout. When a Gemini user says "buy these running shoes," Gemini can take the purchase all the way through to confirmation - without the user ever opening your Magento storefront. You remain Merchant of Record, you receive the order through your normal Magento order pipeline, you fulfil and support as usual. UCP is the communication layer; your store is still the seller.
According to Google's current rollout documentation, UCP defines five capabilities:
| Capability | What the agent can do |
| **Discovery (Catalog)** | Read real-time product data - variants, inventory, pricing |
| **Cart** | Add one or more items, including modifications |
| **Checkout** | Complete the purchase on Google surfaces using [Google Pay](https://en.wikipedia.org/wiki/Google_Pay) |
| **Identity linking** | Apply loyalty pricing, member discounts, free shipping tiers |
| **Order management** | Fetch status, tracking, returns post-purchase |
Google states that discovery, identity linking and order management shipped at launch in January 2026; cart and full real-time catalog access were added in the [March 2026 update](https://blog.google/products-and-platforms/products/shopping/ucp-updates/).
UCP requires merchants to publish a manifest at `https://yourstore.com/.well-known/ucp` - a JSON document declaring which capabilities the store supports, plus several Merchant Center attributes (`native_commerce`, `merchant_item_id`, `consumer_notice`) on eligible products.
**Q: Is UCP available outside the US in 2026?**
Not at time of writing. Google has indicated global expansion through 2026 without committing to specific country dates. Until that lands, non-US Magento merchants should prioritise ACP.
**Q: What about [Amazon](https://en.wikipedia.org/wiki/Amazon_(company))'s agents - Rufus, Alexa+, Buy for Me?**
Amazon has not joined ACP or UCP at time of writing. They appear to be building proprietary agents inside their own ecosystem. For a Magento merchant not on Amazon Marketplace, this isn't directly actionable today - but the data hygiene work for ACP and UCP positions you well if Amazon ever opens their protocol.
## ACP vs UCP - side by side
| Dimension | ACP (OpenAI) | UCP (Google) |
| **Primary surface** | ChatGPT, OAI-SearchBot, ChatGPT Apps | Gemini, AI Mode in Google Search, third-party agents |
| **Checkout location** | Merchant site (since Mar 2026) | Google surfaces (UCP) or merchant site (embedded mode) |
| **Discovery format** | `.jsonl.gz` product feed at registered endpoint | `/.well-known/ucp` manifest + Merchant Center feed |
| **Payment rail** | Whatever the merchant's checkout uses | Google Pay (PayPal stated as coming) |
| **Onboarding** | `chatgpt.com/merchants` registration | Google Merchant Center early-access form |
| **Geographic availability** | Global | US only (mid-2026) |
| **Magento native support** | None - community modules only | None - community modules only |
| **Merchant of Record** | Merchant | Merchant |
| **Customer data ownership** | Merchant | Merchant |
| **Maturity in mid-2026** | Mature on discovery; Apps growing | Early access, expanding |
The decision tree is simpler than it looks:
- If your store sells to US customers and you want to be on Gemini, **you need UCP**.
- If you want to be on ChatGPT (US or anywhere else), **you need ACP feeds**.
- If you sell internationally, ACP is your only protocol option this year - UCP isn't there yet outside the US.
- If you do both, that's normal. Most of the groundwork (product attributes, return policy, support contact, schema markup) is shared infrastructure.
### How both protocols sit on top of Magento
At an architectural level, ACP and UCP plug into the same Magento components. The protocol surface differs; what's underneath is the same store.
```
ChatGPT / Gemini / AI Mode
│
┌───────────┴───────────┐
▼ ▼
ACP product feed UCP /.well-known/ucp
(chatgpt.com/merchants) (manifest + capabilities)
│ │
└───────────┬───────────┘
▼
Magento 2 catalog + APIs
(products, inventory, pricing)
▼
Magento checkout + order pipeline
(quote, order, fulfilment)
```
Reading top to bottom: the AI surfaces are at the top, the protocol surfaces in the middle, and your Magento store at the bottom. Both protocols expose Magento data upward in different formats, but the source of truth - your catalog, your inventory, your prices, your checkout - never moves.
This is the practical reason ACP and UCP are sequential, not exclusive: most of the implementation work happens at the bottom two layers, and that work is reusable across both protocols.
## The ecosystem is still moving
Before the roadmap, an honest caveat: this space is volatile. A few things to keep in mind:
- **Specifications are evolving.** Both protocols have shipped material updates since launch. The ACP shift in March 2026 (away from native checkout) and the UCP March 2026 update (cart + catalog) are unlikely to be the last.
- **Rollout timelines can change.** UCP's path to general availability and global expansion is announced quarter-by-quarter. Treat any 2026-end timeline as directional.
- **APIs are early-access.** UCP merchant endpoints are gated and the surface contract can change before GA.
- **Reporting layers don't exist yet.** Google has not shipped UCP-specific conversion reporting in Merchant Center; ACP attribution in [GA4](https://en.wikipedia.org/wiki/Google_Analytics) is partial at best.
- **Adoption data is sparse.** Confident merchant counts and conversion benchmarks for either protocol should be read with caution. Few independent third-party datasets exist this early.
The implication for Magento merchants: optimise for **reusable infrastructure** - clean product data, consistent feeds, allowed AI bots, defined return policy, server-side order attribution - rather than for any single protocol's current shape. That groundwork compounds no matter how ACP and UCP evolve from here.
## The investment order for Magento 2 in mid-2026
### Step 0 - Audit (this week)
[content truncated]
- [What Is UCP? A Store Owner's Guide to Google's Biggest Commerce Shift Since Shopping Ads](https://angeo.dev/what-is-ucp-for-store-owners/): What is UCP? Google's Universal Commerce Protocol lets AI agents discover and buy from your catalog across Search, Gemini, YouTube and Gmail.
*UCP is an actively evolving protocol - capabilities, naming, and rollout status may change. Last verified against UCP spec version 2026-04-08.*
[image: What is UCP - Universal Commerce Protocol explained for eCommerce store owners, covering Google AI Mode, Gemini, and Universal Cart]
UCP connects your Magento catalog to AI agents across Google Search, Gemini, YouTube, and Gmail
### TL;DR - 2 minute version
- **UCP** (Universal Commerce Protocol) is an open standard that lets AI agents discover, browse, and transact with merchant backends
- Announced January 2026 at NRF, significantly expanded at **Google Marketing Live on May 20, 2026**
- Google has announced UCP integration across **AI Mode, Gemini, YouTube Shopping, and Gmail** - rollout timing varies by surface and market
- Launch partners include Nike, Sephora, Target, Walmart, Wayfair, and Shopify merchants
- **Magento has no built-in UCP support.** The `angeo/module-ucp` module generates a spec-compliant UCP profile - currently in beta
- UCP makes your store *discoverable* to AI agents. It does not guarantee recommendations - that depends on catalog quality, pricing, schema, and authority
In this guide · 12 min read
1. The shift that changed commerce
2. What UCP is in plain language
3. What it looks like for a customer
4. How this differs from before
5. Why a store owner should care
6. How UCP works (no code)
7. What UCP does not do
8. What about ACP - the ChatGPT protocol?
9. What this means for Magento stores
10. Where to start
11. Sources and further reading
12. FAQ
Nine days ago, Google made an announcement that most store owners missed.
At Google Marketing Live 2026 on May 20, the company launched Universal Cart - a cross-merchant shopping cart that works across Google Search, Gemini, YouTube, and Gmail. As demonstrated on stage, a customer could add Nike shoes from a YouTube video, skincare from Sephora through Gemini, and check out everything in one tap with Google Pay.
The commerce infrastructure underlying these experiences is built on what Google calls **UCP - the Universal Commerce Protocol**. UCP is one of several emerging standards designed to let AI agents interact with merchant backends.
If you run a Magento store, you are not in that system by default. But it may be possible to change that.
*This guide is part of the [Merchant-Controlled AEO](https://angeo.dev/merchant-controlled-aeo/) architecture - the approach where the merchant owns every signal between their catalog and the AI layer.*
## The shift that changed everything
For twenty years, getting found online meant one thing: rank on Google. You hired an SEO agency, built backlinks, optimised page speed, and waited for position one.
That still matters. But it is no longer the only path to discovery.
In 2025, customers started asking questions instead of searching for links. "Best ergonomic chair under €400." "Which outdoor furniture brand delivers to Belgium?" "Compare these two coffee machines for me."
They are not always typing these questions into Google. They are typing them into ChatGPT, Gemini, and Perplexity - and getting a direct answer: one store, two stores, a specific recommendation. No list of ten results to browse. Just an answer.
As of Google I/O 2026, AI Mode has surpassed one billion monthly users. That number was effectively zero eighteen months ago.
## So what is UCP?
UCP stands for **Universal Commerce Protocol**.
It is an open standard that lets AI agents discover your catalog, build a cart, and - in supported flows - complete a purchase, potentially without the customer visiting your website directly.
The goal is simple: when an AI agent (like Gemini) is asked about what you sell, it can find your store, understand what you offer, and facilitate a transaction.
**Ecosystem context:** UCP was announced on January 11, 2026 at NRF by Google, with Shopify, Etsy, Wayfair, Target, and Walmart listed as co-developers. It is published on GitHub under Apache License 2.0. At Google Marketing Live 2026 (May 20), Google announced that Amazon, Meta, Microsoft, Salesforce, and Stripe have joined to help steer the standard - though the governance structure and decision-making process are not yet publicly documented.
## What does that actually look like?
This is the type of workflow Google demonstrated at Google Marketing Live 2026 and is actively rolling out with launch partners:
A customer opens the Gemini app and says: *"I need a birthday gift for my sister. She likes skincare, budget around €80."*
Gemini searches across UCP-connected stores, finds matching products, and shows them with prices, reviews, and availability - inside the chat. The customer taps "Add to cart." She opens YouTube later and sees a video mentioning a perfume. She adds that too.
Products from different stores sit in one Universal Cart. She can check out with Google Pay or transfer items to the merchant's own checkout page - both paths are supported.
The stores remain the Merchant of Record throughout. They own the transaction, the customer data, and the fulfilment. UCP facilitates the communication between the AI agent and their backend.
**Important context:** Universal Cart began rolling out in the US on May 19, 2026. Canada and Australia are next, per Google's announcements, with the UK to follow. Rollout behavior may vary by market and merchant integration. Not all flows are fully frictionless yet - some result in a cart transfer to the merchant's website rather than in-app checkout.
## How is this different from what we had before?
Before UCP, every AI platform needed its own integration.
ChatGPT built its own shopping system - the Agentic Commerce Protocol (ACP). If you wanted your products in ChatGPT Shopping, you needed to register a separate product feed, meet OpenAI's specific requirements, and wait for approval.
Google had its own integrations. Shopify had its own. Every surface required custom work.
UCP is designed to change this. It is a single protocol - with broad industry participation - that aims to work across any AI surface that supports it. One implementation, multiple platforms.
Google has announced UCP integration across AI Mode, Gemini, YouTube Shopping, and Gmail - though feature completeness varies by surface and market. Microsoft has been named as joining the steering effort. More platforms may follow as the standard matures.
## Why should a store owner care?
Three reasons.
**1. This is where a growing segment of customers is heading.**
Google AI Mode passed one billion monthly users as of May 2026. Universal Cart has begun rolling out in the US. If your products are not accessible through UCP, they cannot appear in Universal Cart, cannot be recommended by Gemini in shopping contexts, and cannot be purchased from YouTube - a growing set of purchase surfaces.
**2. You remain the Merchant of Record.**
This is the part that surprises most store owners. UCP is not Google taking over your transactions. The protocol explicitly preserves the merchant's role: you own the customer relationship, the pricing, the fulfilment, the data. The customer can also choose to transfer items to your website and check out there - Universal Cart supports both in-app checkout and cart transfer.
**3. Several major retailers have announced UCP participation.**
Nike, Sephora, Target, Walmart, and Wayfair are named launch partners. Every Shopify merchant can opt in through their existing platform integration. If you sell in a category where any of these brands compete, their UCP presence means they may appear in AI agent recommendations where you currently do not - though the actual competitive impact depends on your category, market, and how quickly AI-driven shopping adoption grows in your customer base.
## How does UCP work technically? (No code, I promise)
UCP works like a restaurant menu for AI agents.
Your store publishes a small file at a specific address - `yourstore.com/.well-known/ucp` - that tells AI agents what your store can do. Think of it as a menu: "Here is what I sell. Here are the services I offer. Here is how to place an order."
When an AI agent (like Gemini) wants to recommend products from your store, it reads this menu first. Then it knows: can I search the catalog? Can I build a cart? Can I complete a checkout? The agent only uses the capabilities your store explicitly advertises.
This is called **discovery and negotiation**. The merchant declares what they support. The agent declares what it can handle. They compute the intersection and proceed with what both sides agree on.
The menu has five capability areas:
| Capability | What it does |
| **Catalog** | AI agents can search and browse your products |
| **Cart** | AI agents can create and manage shopping carts |
| **Checkout** | AI agents can initiate and complete purchases |
| **Order** | AI agents can check order status and handle returns |
| **Identity Linking** | Customers can connect their store account to their Google account |
You do not need all five on day one. The protocol is modular - you can start with just the discovery profile and add capabilities over time as the spec stabilises and your implementation matures.
## What UCP does not do
UCP makes your store discoverable to AI agents that support the protocol. It does not guarantee that AI agents will recommend your products.
Recommendation depends on factors UCP does not control:
| Factor | Why it matters |
| **Catalog quality** | Complete, accurate product data with real descriptions - not supplier copy |
| **Pricing competitiveness** | AI agents compare across merchants when building recommendations |
| **Review signals** | `aggregateRating` in schema affects recommendation confidence |
| **Entity authority** | How well-known your brand is across the web - mentions, citations, links |
| **Fulfilment reliability** | Shipping times, return policies, in-stock accuracy |
| **Schema completeness** | JSON-LD with all required fields - especially `offers.availability` |
| **Feed freshness** | Stale data (wrong prices, out-of-stock items) erodes AI agent trust |
Think of UCP as opening the door. Everything else determines whether the AI agent walks through it and recommends you. A UCP profile without strong product data is a door with nothing behind it.
**This is why AEO comes before UCP.** The [Magento 2 AEO Guide](https://angeo.dev/magento-2-aeo-guide/) covers the foundational signals - robots.txt, llms.txt, Product schema, product feed - that UCP builds on top of. Implementing UCP without these foundations is like installing a storefront sign on a building with no inventory.
## What about ACP - the ChatGPT protocol?
ACP and UCP are not competitors - they are complementary protocols targeting different AI platforms.
ACP (Agentic Commerce Protocol) is OpenAI's standard for ChatGPT Shopping. UCP is the standard emerging around Google's ecosystem - AI Mode, Gemini, YouTube, and Gmail. They target different AI platforms with different user bases.
Early data from merchants who have implemented both protocols suggests approximately 40% more agentic traffic compared to single-protocol stores - though this figure comes from a limited number of early adopters and may not generalise across all categories.
The practical recommendation: if AI commerce is strategically relevant to your business, implement both. The technical foundations - product feeds, structured data, catalog APIs - overlap significantly.
The Angeo module suite for Magento 2 covers both: `angeo/module-openai-product-feed` handles ChatGPT Shopping (ACP). `angeo/module-ucp` handles Google's Universal Commerce Protocol. Both are open-source and run entirely on your Magento instance.
## What does this mean for Magento stores specifically?
[content truncated]
- [Agentic Commerce for Magento: 12 Questions Merchants Ask Before Implementing](https://angeo.dev/agentic-commerce-magento-questions/): Should Magento merchants implement agentic commerce now? Which protocol first, what to actually build, and what survives a spec change. 12 questions answered.
# Agentic Commerce for Magento: 12 Questions Merchants Ask Before Implementing
Agentic commerce means AI agents discovering products, building carts, and completing purchases directly against your store rather than a shopper browsing your storefront. For Magento 2 merchants the practical questions are narrower than the headlines: which protocol to prepare for, what actually has to be built, and how much of the work survives a protocol shift. Short answers below, with links to the detailed guides.
Updated July 2026
*Agentic-commerce protocols are actively evolving - capabilities, naming, availability, and regional rollout change frequently. Verify current specification versions before implementation.*
## TL;DR - what most merchants need to know
- The protocols are not mutually exclusive - the question is sequencing, not picking a winner.
- Most of the groundwork is **shared infrastructure**: clean structured data, an accurate product feed, and defined policies. That work survives any protocol shift.
- Agentic checkout availability varies by protocol, region, and merchant eligibility - readiness is not the same as being live.
- Magento has no built-in support for these protocols; capability comes from modules you install and control.
## What is agentic commerce, in practical terms?
It is commerce where an AI agent - not a person clicking through your storefront - performs discovery, cart building, and sometimes the purchase itself, communicating with your store through a defined protocol. The merchant typically remains the merchant of record. The canonical definition is on [the agentic commerce protocol definition page](https://angeo.dev/agentic-commerce-protocol-definition/).
## Do I need to implement this now, or is it too early?
The transactional layer is early and uneven; the discovery layer is not. Product feeds and structured data already affect whether you appear in AI shopping surfaces today, and that same work is the prerequisite for agentic checkout later. The defensible position is to ship the discovery groundwork now and stage the checkout integration as availability expands.
## Which should I implement first - ACP or UCP?
The framing assumes you must choose, and you do not. The sequencing argument, with the reasoning behind it, is set out in [ACP vs UCP for Magento 2](https://angeo.dev/acp-vs-ucp-for-magento-2/). The key practical point is that most groundwork is shared, so early work is not wasted whichever protocol matters most to your market.
## Can AI agents actually place a real order in Magento today?
Yes - this is demonstrable rather than theoretical. An assistant can search a catalogue, build a cart, calculate real shipping, and place an order through the Model Context Protocol, with explicit shopper confirmation before purchase. A live worked example with a real order number is documented in [AI agent checkout in Magento 2](https://angeo.dev/ai-agent-checkout-in-magento-2-claude-places-a-real-order-via-mcp/).
## How is MCP different from ACP and UCP?
MCP is a general open standard for connecting assistants to external systems, so one endpoint can serve multiple assistants. ACP and UCP are commerce-specific protocols backed by particular vendors and surfaces. In practice MCP is how you make your store conversational across assistants; ACP and UCP are how you participate in specific vendors' shopping ecosystems. See [the MCP Checkout documentation](https://angeo.dev/docs/mcp-checkout/).
## What do I actually have to build?
Four things, in rough dependency order: accurate structured product data, a spec-compliant product feed, protocol-specific manifests or endpoints, and defined policies for returns, shipping, and availability. The first two are the AEO foundations covered in the [Magento 2 AEO guide](https://angeo.dev/magento-2-aeo-guide/) - which is why AEO work is the entry point to agentic commerce rather than a separate track.
## Does a product feed get crawled, or do I submit it?
For AI shopping surfaces the model is generally push rather than crawl: the merchant delivers a structured file to the vendor's endpoint on a schedule, rather than waiting for a crawler to discover pricing and stock. This is why feed accuracy and refresh frequency matter more than page-level SEO for these surfaces.
## What happens if the protocol changes after I implement it?
This is the main risk, and it is why sequencing matters. Protocol-specific glue - manifests, endpoints, vendor onboarding - can be invalidated by spec changes. The shared layer underneath, clean schema and accurate feeds, does not. Keeping the ratio weighted toward the shared layer is the practical hedge.
## Is my store eligible, or is this only for large retailers?
Eligibility varies by protocol and vendor, and early access has typically been limited by region and merchant type. Readiness is within your control; being live is not entirely. Preparing the feed and data layer costs little and positions you for whenever eligibility opens in your market.
## Does agentic commerce mean losing the customer relationship?
Under these protocols the merchant generally remains the merchant of record and retains fulfilment and customer data, but the discovery relationship does shift - the assistant, not your storefront, mediates the first impression. That is the architectural trade-off examined in [merchant-controlled AEO](https://angeo.dev/merchant-controlled-aeo/).
## Does any of this apply to B2B?
Arguably more than to consumer retail, because procurement is repetitive and spec-driven - exactly the work that gets delegated to agents first. Magento's B2B features are powerful but largely invisible to agents without deliberate configuration. See [AI visibility for B2B Magento stores](https://angeo.dev/magento-b2b-ai-visibility/).
## Where do I start if I only have limited engineering time?
Start with the audit, not the protocol. Score your current signals with the [free AEO self-assessment](https://angeo.dev/ai-magento-audit/), fix schema and feed first, and treat protocol integration as a later phase. Every hour spent on the shared layer counts toward whichever protocol turns out to matter for your market.
## Next step
For the full protocol landscape and current status, see the [Magento Agentic Commerce Hub](https://angeo.dev/magento-agentic-commerce-hub/). To check where your store stands today, run the [free AEO self-assessment](https://angeo.dev/ai-magento-audit/).
- [AI Crawlers and Magento: Which Bots to Allow, Which to Block, and Why](https://angeo.dev/ai-crawlers-magento-questions/): Which AI bots should a Magento store allow? Training, search and user-triggered crawlers explained - plus robots.txt limits, verification and redirect pitfalls.
# AI Crawlers and Magento: Which Bots to Allow, Which to Block, and Why
AI crawlers split into three families that serve different purposes: training crawlers that feed model weights, search crawlers that index for live answers, and user-triggered agents that fetch a page on demand. Allowing the search crawlers is what keeps a Magento store eligible to be cited in AI answers. This page answers the questions merchants ask when deciding a crawler policy.
Updated July 2026
*The bot landscape moves quickly - user-agents are added, split, and deprecated. Re-verify current agent names against vendor documentation before shipping rules, and audit at least quarterly.*
## TL;DR - the crawler decision in four lines
- **Search crawlers determine citability.** Block them and you remove your store from AI answers.
- **Training crawlers are a separate choice.** You can allow search while disallowing training, because they use distinct user-agents.
- **robots.txt is a convention, not enforcement.** Non-compliant crawlers exist; server or WAF rules are the only hard control.
- **Verify the user-agent, don't trust it.** Any client can send any user-agent string.
## What are the three families of AI crawler?
| Family | What it does | Effect if you block it |
| Training crawlers | Collect content in bulk to train foundation models | Your content is excluded from future training data; no direct effect on live answers |
| Search crawlers | Index continuously so the assistant can cite live results | You become ineligible for citation in generated answers |
| User-triggered agents | Fetch a specific URL when a user asks the assistant to look at it | Assistants may fail to open your pages on user request |
*The distinction matters because the families are independently controllable. Blocking "AI bots" as one undifferentiated group is what accidentally removes stores from AI search.*
## Should I block AI crawlers on my Magento store?
For a commerce store, generally no - at least not the search crawlers. Blocking them removes you from the answers where product discovery increasingly happens, and that visibility is hard to recover later. Blocking training crawlers is a defensible separate choice if you have proprietary content you do not want memorised.
## Which AI bots should I allow to be cited in ChatGPT, Claude, and Perplexity?
Allow the search and user-facing agents for each vendor - these are what make you eligible to appear in answers. Vendors document their agents separately from their training crawlers, so consult current vendor documentation for exact names before writing rules, then implement them following [the Magento robots.txt walkthrough](https://angeo.dev/magento-2-robots-txt-chatgpt-gemini-ai-bots/).
## Can I allow AI search but block AI training?
Yes, and this is a common enterprise pattern. Training and search agents are distinct user-agents with independent directives, so you can stay citable in AI answers while opting out of contributing to model training. The trade-off: staying out of training data can reduce long-term familiarity with your brand inside the models themselves.
## Does blocking GPTBot remove me from ChatGPT?
Not by itself - the training crawler and the search crawler are different agents. Blocking only the training crawler leaves you eligible for ChatGPT's search-based citations, provided the search agent is still allowed. Blocking both removes you from both.
## Do AI crawlers actually respect robots.txt?
The major documented crawlers generally do, and you can verify it from your own server logs. But compliance is opt-in: some crawlers have been documented ignoring robots.txt, and user-directed fetches are treated by some providers as user actions rather than crawling, so robots.txt may not apply as site owners expect. Treat the file as a norm, not a guarantee.
## How do I verify that a crawler is really who it claims to be?
Do not trust the user-agent string - anyone can send any header. Verify against the vendor's published IP ranges where available, or fall back to a reverse DNS lookup confirmed by a forward lookup. This matters when you are deciding whether to serve or rate-limit traffic based on identity.
## What happens to redirects and redirect chains?
Search-time agents have low tolerance for extra hops - an unnecessary redirect can be enough for a page not to be used in a generated answer. This applies with particular force to `llms.txt`: if it is served via redirect rather than directly at the root, some crawlers retry the root instead of following, making the file effectively inoperative.
## Should I block anything at all?
Two categories are worth restricting regardless of your AI policy. Keep admin, login, cart, checkout, and account paths disallowed for every crawler - they have no discovery value and should not be fetched. And crawlers documented as non-compliant are better handled at the server or CDN layer, since a robots.txt rule they ignore achieves nothing.
## Does allowing AI crawlers slow down my store?
It adds crawl traffic, which on a large catalogue is worth monitoring. Treat it as a cost-benefit question: measure crawler activity in your logs against citations and referral traffic, and restrict any agent that generates load with no discoverable benefit.
## How often should I review my crawler rules?
At least quarterly. Agents get added, split into separate crawlers, and deprecated - a `robots.txt` copied from an older example can silently exclude you from surfaces that did not exist when it was written.
## Is robots.txt enough on its own for AI visibility?
No. Crawler access is necessary but not sufficient: it lets AI systems reach your pages, while `llms.txt`, complete product schema, and a product feed determine what they can actually do with them. See the [Magento 2 AEO guide](https://angeo.dev/magento-2-aeo-guide/) for the full set, or compare implementation routes in [AEO options for Magento](https://angeo.dev/aeo-options-for-magento/).
## Next step
Check what your store currently allows with the [free AEO self-assessment](https://angeo.dev/ai-magento-audit/), then ship the rules using [how to fix robots.txt for ChatGPT and Gemini in Magento 2](https://angeo.dev/magento-2-robots-txt-chatgpt-gemini-ai-bots/).
- [Why Is My Magento Store Invisible in ChatGPT? 15 Questions Store Owners Actually Ask](https://angeo.dev/magento-chatgpt-visibility-questions/): ChatGPT never mentions your store? Four checks explain most cases - crawler access, llms.txt, product schema and feed. 15 questions answered, shortest first.
# Why Is My Magento Store Invisible in ChatGPT? 15 Questions Store Owners Actually Ask
If ChatGPT, Gemini, or Perplexity never mention your store, the cause is almost always one of four things: AI crawlers are blocked, there is no machine-readable content map, your product schema is incomplete, or you have no product feed. This page answers the questions merchants ask most often, shortest answer first, and points to the detailed fix for each.
Updated July 2026
*AI platform behaviour changes frequently - crawler names, feed specifications, and shopping surfaces may have evolved since publication.*
## Start here: the 60-second diagnosis
Four checks explain the large majority of "my store is invisible" cases:
1. Does `robots.txt` allow search-time AI agents such as OAI-SearchBot, PerplexityBot, and Claude-SearchBot?
2. Is there a valid `llms.txt` at your domain root, served without a redirect?
3. Do product pages output JSON-LD `Product` schema with a populated `offers.availability`?
4. Do you have a product feed submitted to the AI shopping surface you care about?
If any answer is "no" or "not sure", that is your starting point. Score all four automatically with the [free AEO self-assessment](https://angeo.dev/ai-magento-audit/).
## Why can't I find my store in ChatGPT?
In most cases because ChatGPT was never able to read it. A default Magento 2 install commonly blocks AI crawlers in `robots.txt` and ships no machine-readable content map, so the store is absent from the sources the model draws on rather than ranked poorly within them. This is a access problem, not a ranking problem - which is why it can be fixed quickly once identified.
## My products aren't showing up in ChatGPT shopping results - why?
Product results and general answers work differently. ChatGPT does not crawl your catalogue for shopping surfaces the way Google does; merchants push a structured product feed to OpenAI rather than waiting to be indexed. Without a submitted feed, products can still surface from crawled pages, but they miss the richer product treatment. See [preparing your Magento 2 store for ChatGPT Shopping](https://angeo.dev/magento-2-chatgpt-shopping-registration/).
## Why is my brand invisible when customers ask ChatGPT for recommendations?
AI assistants typically name one or two stores instead of listing ten links, so being "somewhere in the results" is not enough - you either get selected or you do not appear at all. Selection depends on machine-readable signals most Magento stores have never configured. The underlying mechanics are explained in [why your store ranks in Google but disappears in ChatGPT](https://angeo.dev/magento-ranks-google-invisible-chatgpt/).
## I rank well on Google - why doesn't that carry over to AI search?
Because AI systems evaluate an additional layer that Google rankings do not require. Fast pages, clean structure, and good rankings satisfy classic SEO while leaving the machine-readable layer - crawler access, content map, complete schema, feed - entirely unconfigured. Strong SEO helps, but it does not substitute for those signals.
## How do I know if ChatGPT can even see my store?
Check whether AI crawler user-agents appear in your server logs, and validate that your `robots.txt` permits them. For a scored answer across all the signals at once, run `bin/magento angeo:aeo:audit` or the [2-minute self-assessment](https://angeo.dev/ai-magento-audit/).
## Common blockers
### Does robots.txt really block ChatGPT by default?
Many Magento installations run a `robots.txt` written years ago for Googlebot that never gained rules for AI crawlers, and some actively disallow them. Blocking the search-time agents removes you from generated answers entirely. The fix is documented in [how to fix robots.txt for ChatGPT and Gemini in Magento 2](https://angeo.dev/magento-2-robots-txt-chatgpt-gemini-ai-bots/).
### Can I allow AI search but block AI training?
Yes - training crawlers and search crawlers are separate user-agents, so you can allow the agents that make you citable while disallowing those that feed model training. Allowing search-time agents is what preserves your eligibility to be cited in AI answers.
### I added llms.txt but nothing changed - what went wrong?
Three frequent causes: the file is served through a redirect rather than directly at the root, it lists pages that AI crawlers are still blocked from fetching, or it is the only signal you added while schema and feed remain incomplete. `llms.txt` is one signal among several, not a switch.
### Why does my product schema pass Google's test but still fail for AI?
Google's rich-results validation tolerates gaps that AI shopping surfaces do not. The most common one is a missing or empty `offers.availability`, which causes products to be skipped. Default Magento also outputs microdata rather than the JSON-LD that AI engines prefer - see the [Product JSON-LD schema guide](https://angeo.dev/magento-2-product-schema-json-ld-ai-search/).
### Does schema added through Google Tag Manager work for AI crawlers?
No. AI crawlers generally do not execute JavaScript, so structured data injected client-side through a tag manager is invisible to them. Schema must be rendered server-side in the page source.
### I'm on Hyvä - does that change anything?
Yes, and it is easy to miss. Hyvä renders price and availability as structured data but does not wrap them in a Product entity, so machine-readable clients cannot reliably extract a coherent product. See [Hyvä's product schema gap](https://angeo.dev/hyva-theme-product-schema-gap/).
## Measuring and fixing
### How do I track whether AI engines send me traffic?
Analytics under-reports it: many AI referrals arrive without an intact referrer and land in Direct. Server-side log analysis alongside analytics gives a fuller picture - the method is in [how to track AI search traffic in Magento 2](https://angeo.dev/track-ai-search-traffic-magento-2/).
### How long until I see results after fixing these signals?
Crawler access and schema changes take effect as soon as the relevant agents re-crawl, which is typically days rather than months. Being cited in answers is not guaranteed by fixing the signals - it becomes possible, where before it was not.
### Who fixes this - my SEO agency or a developer?
It is an engineering task more than a marketing one: the work happens in `robots.txt`, templates, schema output, and feed generation. Traditional SEO agencies often do not cover this layer. The evaluation criteria for choosing a partner are in [how to choose a Magento AI agency](https://angeo.dev/magento-ai-agency/).
### Can I fix this myself for free?
Yes, for the core signals. Free MIT-licensed Composer modules cover llms.txt generation, schema output, crawler access, and auditing - the trade-off is your engineering time. The routes are compared in [AEO options for Magento](https://angeo.dev/aeo-options-for-magento/).
## Next step
Run the [free AEO self-assessment](https://angeo.dev/ai-magento-audit/) to see which of the four signals your store is missing, then work through the [Magento 2 AEO guide](https://angeo.dev/magento-2-aeo-guide/).
- [AI Agent Checkout in Magento 2: Claude Places a Real Order via MCP](https://angeo.dev/ai-agent-checkout-in-magento-2-claude-places-a-real-order-via-mcp/): Watch a Claude AI agent place a real Magento 2 order via MCP - product search, cart, shipping, checkout. No browser automation. Open-source module demo.
AI agents can already *find* products. But can they actually *buy* them - placing a real order in a live Magento 2 store, without browser automation or scraping? With `angeo/module-mcp-checkout` v1.0.0, the answer is yes. This post shows you the full flow, step by step, including a real `order_number` from a live demo store.
## Watch the full checkout flow
## How it works: architecture
```
User (Claude.ai)
↓
MCP Client
↓
Magento MCP Endpoint ← Bearer auth + rate limiter
↓
Magento Service Layer
↓
Quote / Cart
↓
Order ✓
```
## MCP call sequence
Every checkout runs the following tool sequence. Each call maps directly to a Magento service layer operation - no browser, no session, no cookies.
```
Claude
↓
search_products() - find product by keyword
↓
get_product() - verify SKU, price, stock
↓
create_cart() - open guest cart, get cart_id
↓
add_to_cart() - add item by child SKU
↓
get_shipping_methods() - estimate delivery options
↓
set_shipping_information() - apply address + method
↓
[User confirms total]
↓
place_order() - submit cart → order_number
```
`angeo/module-mcp-checkout` exposes these as six MCP tools over a JSON-RPC endpoint, giving AI agents a structured, authenticated interface to complete a full guest checkout:
- `create_cart` - opens a new guest cart
- `add_to_cart` - adds a product by SKU
- `get_cart` - reads current items and totals
- `get_shipping_methods` - estimates available delivery options
- `set_shipping_information` - sets address, email, and chosen method
- `place_order` - submits the order after user confirmation
No browser automation, no scraping. The agent talks directly to your Magento backend through a secure, rate-limited MCP endpoint.
## Security
- ✓ **Bearer Authentication** - every MCP request requires a valid Bearer token; unauthenticated calls are rejected at the endpoint level
- ✓ **Rate limiting** - configurable request throttling prevents abuse and protects store performance
- ✓ **Magento ACL** - MCP tools operate within Magento's standard Access Control Layer; no privilege escalation is possible
- ✓ **HTTPS only** - the MCP endpoint is served exclusively over TLS; plain HTTP is not supported
- ✓ **User confirmation before order placement** - `place_order` is never called autonomously; the agent always presents a full order summary and waits for explicit approval
- ✓ **Configurable agent order limit** - merchants can set a maximum order value for agent-placed orders in the Magento admin
## Live demo: Claude finds a backpack and buys it
The following is a real session run against [demo.angeo.dev](https://demo.angeo.dev). The prompt: *"I want to buy a Fusion Backpack."*
### Step 1 - Product discovery
Claude called `search_products`, then `get_product` on the result. It identified the **Fusion Backpack** (SKU: `24-MB02`) as in-stock at $59.
### Step 2 - Cart creation and item add
`create_cart` returned a fresh `cart_id`. `add_to_cart` confirmed the item was added: subtotal $59, grand total $59.
### Step 3 - Shipping estimation
`get_shipping_methods` returned one available method: **Flat Rate - Fixed at $10.00**.
### Step 4 - Address and method set
`set_shipping_information` applied the customer's name, street, postcode, city, country, phone, and email. Final totals confirmed: subtotal $59 + shipping $10 = **$69.00 USD**.
### Step 5 - User confirms, order placed
The agent presented the full order summary and waited for explicit confirmation. After the user approved, `place_order` submitted the cart:
```
{
"order_number": "000000005",
"status": "pending",
"grand_total": 69,
"currency": "USD"
}
```
A real order, in a real Magento store, placed entirely by an AI agent through MCP - with the user in full control at every step.
## Why this matters for Magento merchants
Agentic commerce is not a future concept - it is happening now. Shoppers are already using AI assistants to research and shortlist products. The stores that close the loop by letting agents *complete* a purchase will capture that intent before it leaks to a competitor.
`angeo/module-mcp-checkout` is MIT-licensed and installs via Composer:
```
composer require angeo/module-mcp-checkout
bin/magento module:enable Angeo_McpCheckout
bin/magento setup:upgrade
```
## What about payment - does Stripe work?
This is the question everyone asks, and it deserves an honest answer.
MCP agents cannot process card payments directly. Stripe requires a PCI-compliant browser form (Stripe.js / Payment Element) to tokenize card data - something fundamentally incompatible with a server-side MCP tool call. This is the same constraint that caused OpenAI to pull their native agentic checkout: collecting card details through an agent violates PCI scope.
`angeo/module-mcp-checkout` sidesteps this by design. The agent places the order with a deferred payment method, setting the order status to `pending`. Payment is then handled separately - outside the agent flow - in one of three ways:
- **B2B / wholesale:** the merchant sends an invoice after order placement - already a standard workflow for many Magento stores.
- **Payment Link:** after `place_order`, the agent generates a Stripe, Mollie, or Adyen Payment Link and returns it to the user to complete in their browser. No PCI exposure, no extra fees beyond standard gateway rates.
- **Store redirect:** the agent hands off to the store's standard checkout page with the cart pre-filled, where the shopper completes payment through the normal payment gateway UI.
There are no additional platform fees - only standard gateway transaction fees apply, exactly as in a normal checkout. A dedicated `get_payment_link` tool supporting Stripe, Mollie, and Adyen is planned for v2.0.0.
## Current v1.0.0 scope
- Configurable products are supported via child SKU selection - dedicated variant tooling with size/color picker is planned for v2.0.0.
- Guest checkout is the current flow - registered customer support is on the roadmap.
- Card payment is not collected by the agent - deferred payment or Payment Link handoff is used instead (see above).
- An optional agent order limit can be configured in the admin - a merchant-controlled guardrail, not a platform constraint.
## FAQ
**Can Claude place a real Magento 2 order?**
Yes. The demo in this post shows a real order (`#000000005`) placed on a live Magento 2 store via MCP, with no browser automation involved.
**Does MCP support Stripe payments?**
Not directly - and deliberately so. Card tokenization requires a PCI-compliant browser form. The module uses deferred payment with an optional Payment Link handoff (Stripe, Mollie, Adyen), keeping the agent flow outside PCI scope entirely.
**Is browser automation required?**
No. The agent communicates with your Magento backend through a JSON-RPC MCP endpoint - no headless browser, no Selenium, no scraping, no Playwright.
**Is Selenium required?**
No. `angeo/module-mcp-checkout` replaces Selenium-based automation entirely. The agent calls structured MCP tools directly against the Magento service layer - faster, more reliable, and easier to maintain than any browser automation approach.
**Does it work with Playwright?**
Playwright is not needed and not used. MCP is a purpose-built protocol for AI-to-application communication - it is a fundamentally better fit for agentic commerce than browser automation tools like Playwright or Puppeteer.
**Is MCP faster than browser automation?**
Yes - significantly. Browser automation must load full page renders, wait for JavaScript, and parse DOM elements. MCP calls hit the Magento service layer directly via JSON-RPC, with no rendering overhead. A full checkout sequence typically completes in under 5 seconds.
**Does this work with Adobe Commerce?**
Yes. The module is compatible with both Magento Open Source and Adobe Commerce 2.4.x.
**Does the agent act autonomously without the user knowing?**
No. `place_order` is only called after explicit user confirmation. The agent presents a full order summary - items, totals, address, shipping - and waits for approval before submitting.
**Is guest checkout required?**
In v1.0.0, yes. Registered customer checkout is on the v2.0.0 roadmap.
## What's next
The v2.0.0 roadmap includes registered customer checkout, a coupon/discount tool, configurable product variant tooling, and a Payment Link tool (Stripe, Mollie, Adyen) for automated payment handoff. If you are running a Magento 2 or Adobe Commerce store and want to be an early tester, [reach out](https://angeo.dev/contact/).
*All tools shown in this post are part of the [angeo.dev](https://angeo.dev) open-source AEO stack for Magento 2. The module will be available on GitHub shortly - follow [angeo.dev](https://angeo.dev) for updates.*
- [Magento Agentic Commerce Hub 2026](https://angeo.dev/magento-agentic-commerce-hub/): The complete resource for Adobe Commerce merchants entering AI-agent shopping: protocol status, module setup, readiness checklists, and AI attribution.
[angeo.dev](https://angeo.dev/)
/
[Magento AEO](https://angeo.dev/magento-aeo/)
/
Agentic Commerce Hub
Magento 2 & Adobe Commerce
ACP · UCP · AP2
Open-source modules
Updated June 2026
# Magento Agentic Commerce Hub 2026
ACP · UCP · multi-protocol readiness · AI attribution - the complete resource for Adobe Commerce merchants entering AI-agent-mediated shopping.
By [Ievgenii Gryshkun](https://angeo.dev/about/) · June 2026 · 15 min read
[Run free AEO audit →](https://angeo.dev/ai-magento-audit/)
Jump to setup
Protocols and platform status change. Verify current spec versions before implementation. Reflects ACP, UCP, and AP2 as of June 2026.
Default Magento 2 install
~25%
- ✗ AI crawlers blocked by default
- ✗ No llms.txt or ACP feed
- ✗ Product schema incomplete
- ✗ No UCP manifest
- ✗ Zero AI attribution
With Angeo AEO suite
87-91%
- ✓ All 10 AI bots permitted
- ✓ llms.txt auto-generated
- ✓ offers.availability live
- ✓ ACP feed validated
- ✓ AI orders attributed in GA4
**TL;DR.** Default Magento has none of the signals AI agents need to discover, understand, or transact with your store. This page maps every signal, every protocol, every open-source module, and every implementation step - in priority order.
The AEO foundation (robots.txt + llms.txt + schema) takes 90 minutes. ACP conformance review adds 1-4 weeks. UCP manifest adds 30-60 minutes once foundations are in place. Multi-protocol payment readiness (AP2, Visa TAP, Mastercard Agent Pay) is handled by your payment processor.
## What is agentic commerce - and what does it mean for Magento?
Agentic commerce is when an AI assistant (ChatGPT, Gemini, Copilot, Perplexity) finds a product and completes the purchase for a user - without the user ever visiting your storefront. The shopper says "order trail shoes under €120 that arrive by Friday" and the agent handles discovery, comparison, and checkout.
For Magento merchants this creates both an opportunity and an infrastructure gap. Platforms like Shopify handle the AI channel relationship centrally - their merchants get default syndication with no individual setup. **Magento merchants own their stack, which means full control and full responsibility. Every AI visibility signal must be configured deliberately.**
The good news: once configured, a Merchant-Controlled AEO stack reaches the same AI commerce channels as platform-mediated approaches - with full auditability, no platform dependency, and no revenue share to a commerce aggregator.
→ See: [Shopify vs Magento for AI Commerce 2026: Platform-Mediated vs Merchant-Controlled AEO](https://angeo.dev/shopify-vs-magento-ai-commerce-aeo-2026/)
## The agentic commerce protocol landscape in 2026
Five protocol families now shape agentic commerce. Magento merchants do not integrate all of them directly - the cards below map what each requires at the merchant level.
ACP - Agentic Commerce Protocol
OpenAI · also adopted by Microsoft Copilot
Product feed + discovery standard. Powers ChatGPT Shopping. Merchants generate a .jsonl.gz product feed and apply at chatgpt.com/merchants.
✓ Live - apply now
Feed-based
UCP - Universal Commerce Protocol
Google · AI Mode, Gemini, YouTube Shopping, Gmail
Live agentic checkout standard. Merchants expose a /.well-known/ucp manifest with GraphQL and REST transport bindings. US early access mid-2026.
⏳ US early access
AP2 - Agent Payments Protocol
Google · open standard
Cryptographic mandate layer between agents and payment networks. Merchants do not integrate AP2 directly - payment processors handle it. Confirm your gateway supports AP2-compliant transactions.
Processor-handled
Visa TAP + Mastercard Agent Pay
Visa · Mastercard
Network-specific agent-payment authorization on card rails. No direct merchant integration - handled by your payment gateway underneath ACP / UCP transactions.
✓ GA - via gateway
**Merchant decision rule:** Implement ACP first (broadest reach, clearest conformance path). Prepare UCP manifest second (Google ecosystem checkout). AP2 / Visa TAP / Mastercard Agent Pay resolve through your payment processor automatically.
→ [ACP vs UCP for Magento 2: Which Protocol Should You Implement First?](https://angeo.dev/acp-vs-ucp-for-magento-2/)
## Implementation path: 25% → 90%+ AEO score
A default Magento 2.4.x install scores approximately 25% on a 9-signal AEO audit. The steps below are sequential - each builds on the previous. Active configuration time: ~90 minutes. Total elapsed including OpenAI review: 1-4 weeks.
1. 1
### Unblock AI crawlers in robots.txt
Default Magento blocks most AI bots via wildcard rules. In 2026 there are 10 distinct AI crawlers across ChatGPT, Gemini, Claude, Perplexity, and Bing. None are explicitly allowed out of the box.
**Module:** `angeo/module-robots-txt-aeo` - explicit Allow rules for all 10 AI bots, append-only, per-store-view support.
⏱ ~10 min
+15 pts
[Full guide →](https://angeo.dev/magento-2-robots-txt-chatgpt-gemini-ai-bots/)
2. 2
### Generate llms.txt catalog map
llms.txt tells AI systems what your store is, what categories exist, and what products you sell - in a format optimized for LLM ingestion. Magento has no native support.
**Module:** `angeo/module-llms-txt` - auto-generates llms.txt and llms.jsonl per store view, regenerates on catalog changes.
⏱ ~15 min
+10 pts
[Full guide →](https://angeo.dev/how-to-generate-llms-txt-for-magento-2-in-5-minutes/)
3. 3
### Complete Product JSON-LD schema
The single most common failure: `offers.availability` missing - ChatGPT Shopping skips those products entirely. Magento's default Luma outputs partial microdata. Hyvä Theme has zero Product schema by default.
**Module:** `angeo/module-rich-data` - server-rendered JSON-LD with offers.availability, aggregateRating, brand, sku, gtin13, priceValidUntil. Works with all frontends including Hyvä.
⏱ ~20 min
+15 pts
[Full guide →](https://angeo.dev/magento-2-product-schema-json-ld-ai-search/)
4. 4
### Generate ACP product feed and apply for ChatGPT Shopping
The ACP product feed is what OpenAI uses to ingest your catalog into ChatGPT Shopping - required fields, image formats, refresh cadence, and conformance rules. Shopify generates this centrally; Magento merchants generate it independently.
**Module:** `angeo/module-openai-product-feed` - spec-compliant .jsonl.gz feed with 15-minute cron refresh. Apply at [chatgpt.com/merchants](https://chatgpt.com/merchants).
⏱ ~25 min + 1-4 weeks review
+15 pts
[Full guide →](https://angeo.dev/magento-2-chatgpt-shopping-registration/)
5. 5
### Configure UCP manifest for Google AI Mode
UCP exposes a `/.well-known/ucp` profile that AI agents use to discover your store's capabilities, then uses Magento's GraphQL API for browsing and REST API for cart operations. Steps 1-4 are prerequisites.
No native Magento module for UCP as of mid-2026 - custom configuration required. See the 10-step checklist.
⏱ ~30-60 min
+10 pts
[10-step UCP checklist →](https://angeo.dev/ucp-readiness-checklist-magento/)
6. 6
### Add AI order attribution
Without attribution, AI-driven revenue appears as direct or dark traffic in GA4. AI referrers (`chatgpt.com`, `perplexity.ai`, `copilot.microsoft.com`, `gemini.google.com`) must be captured at session start and persisted through checkout to `sales_order.ai_referrer`.
This is the difference between knowing "AI drove 12% of orders last quarter" and not knowing.
⏱ ~10 min
Operational signal
### Install all modules in one command
# Install the full Angeo AEO suite
composer require \
angeo/module-aeo-audit \
angeo/module-robots-txt-aeo \
angeo/module-llms-txt \
angeo/module-rich-data \
angeo/module-openai-product-feed \
angeo/module-openai-product-feed-api
bin/magento setup:upgrade && bin/magento cache:flush
# Run audit - see your exact score and what to fix
bin/magento angeo:aeo:audit
✓ PASS robots.txt All 10 AI bots permitted
✓ PASS llms.txt Generated - 12,400 products mapped
✓ PASS Product JSON-LD offers.availability present
✓ PASS ACP product feed Spec-compliant - 15min refresh
✓ PASS MCP server /mcp/v1 active
✓ PASS AI attribution sales_order.ai_referrer active
AEO Score: 91% - Excellent
All modules are MIT-licensed and free on [Packagist](https://packagist.org/packages/angeo/). Implementation help and enterprise configuration are available as [paid services](https://angeo.dev/ai-commerce-optimization/).
## Open-source module reference
[`angeo/module-aeo-audit`](https://packagist.org/packages/angeo/module-aeo-audit)
CLI audit - all 9 AEO signals, 0-100 score, fix commands
MIT · Free
[`angeo/module-robots-txt-aeo`](https://packagist.org/packages/angeo/module-robots-txt-aeo)
Allow rules for all 10 AI bots - per store view, append-only
MIT · Free
[`angeo/module-llms-txt`](https://packagist.org/packages/angeo/module-llms-txt)
llms.txt + llms.jsonl AI catalog map, auto-generated per store view
MIT · Free
[`angeo/module-rich-data`](https://packagist.org/packages/angeo/module-rich-data)
Product JSON-LD - offers.availability, aggregateRating, FAQPage, Hyvä-compatible
MIT · Free
[`angeo/module-openai-product-feed`](https://packagist.org/packages/angeo/module-openai-product-feed)
ACP product feed - .jsonl.gz spec-compliant, 15-min cron refresh
MIT · Free
[`angeo/module-openai-product-feed-api`](https://packagist.org/packages/angeo/module-openai-product-feed-api)
ACP REST API - 6 endpoints for live inventory, pricing, and agent queries
MIT · Free
## AI engine coverage by signal
A fully configured Angeo AEO stack reaches every major AI commerce channel. The table maps which signals each platform uses as primary and secondary inputs.
| AI engine | Primary signal | Secondary signal | Protocol |
| **ChatGPT Shopping** | ACP product feed | OAI-SearchBot + Product JSON-LD | ACP |
| **ChatGPT (editorial)** | OAI-SearchBot crawl | llms.txt + Product JSON-LD | Crawl |
| **Google AI Mode** | UCP manifest | Google-Extended + schema | UCP |
| **Gemini** | Google-Extended crawl | UCP manifest + JSON-LD | UCP / Crawl |
| **Perplexity** | PerplexityBot crawl | llms.txt + Product JSON-LD | Crawl |
| **Microsoft Copilot** | Bingbot + ACP | Product JSON-LD | ACP / Crawl |
| **Claude (Anthropic)** | ClaudeBot crawl | llms.txt | Crawl |
## Agentic commerce timeline - what changed and when
September 2025
Google announces AP2 (Agent Payments Protocol)
Open standard for cryptographic mandate authorization. 60+ launch partners including Mastercard, PayPal, Coinbase. Introduces Intent, Cart, and Payment mandates as W3C Verifiable Credentials.
October 2025
Visa TAP launches with Cloudflare
Network-specific agent-payment authorization. Signs agent identity into HTTP request headers for merchant verification.
January 2026 - NRF
Google announces UCP; Amazon expands "Buy for me"
UCP publicly announced. Mastercard confirms participation in UCP, AP2, ACP, and A2A simultaneously. [UCP explained →](https://angeo.dev/what-is-ucp-for-store-owners/)
March 2026
OpenAI pauses Instant Checkout; ACP becomes discovery/feed protocol
ACP continues as the product feed and discovery standard powering ChatGPT Shopping. [How this affects Magento merchants →](https://angeo.dev/acp-vs-ucp-for-magento-2/)
May 2026 - Google Marketing Live
UCP expands across AI Mode, Gemini, YouTube Shopping, Gmail
UCP integration confirmed across Google's full AI surface. US early-access merchants can apply. [UCP checklist →](https://angeo.dev/ucp-readiness-checklist-magento/)
Mid-2026 - current
Multi-protocol era: five protocol families active
AI referral traffic to e-commerce up 4,700% YoY. Merchants implementing both ACP and UCP reach the broadest AI commerce surface. UCP native module for Magento not yet available - custom configuration required.
## Complete guide library
### Foundation - AEO basics
AEO · Audit
[content truncated]
## Research and case studies
Original data collected by angeo.dev. Methodology is published with every figure.
- [462 Magento stores scanned. 82% of the product pages we could test have no product schema.](https://angeo.dev/aeo-scan-case-study/): We scanned 462 live Magento stores for AEO readiness. 87% have no llms.txt, 82% of product pages lack JSON-LD, and 12% block AI crawlers. See the data - and the fix.
We ran an automated AEO (AI Engine Optimization) readiness scan across 462 live Magento storefronts. The headline: most are hard for AI systems to read - the very systems that increasingly sit between a shopper and a purchase, from ChatGPT shopping and Perplexity to Google's AI Mode. Here is what the data shows, why it matters, and what a store owner can do about it.
## Key findings
- **12%** of stores block GPTBot in `robots.txt`
- **87%** have no `llms.txt` file
- **82%** of product pages ship no JSON-LD `Product` schema
- **24%** of the stores that do have JSON-LD Product still omit `offers.availability`
## Update - 10 August 2026
This scan has since been repeated on a larger, fully reproducible sample: **770 Magento stores** drawn from [Tranco](https://tranco-list.eu/) list **ZJGPG**, top 200,000 domains, scanned on 9 August 2026. The figures moved by a point or two and no conclusion changed:
- GPTBot blocked: 12% here, **13%** in August
- No `llms.txt`: 87% here, **89%**
- No JSON-LD `Product` on a tested product page: 82% here, **83%**
- Missing `offers.availability` among those that have the markup: 24% here, **25%**
The two samples overlap - 382 of the domains here are in the August frame - so the agreement shows the instrument is stable rather than confirming the result independently.
What the repeat did add is a [**store-by-store comparison of the 376 stores measured in both runs**](https://angeo.dev/magento-ai-signals-two-scans/): 94% showed no change in any measured signal, no store added product markup, and every store that edited its AI-crawler rules edited several at once. The list ID, the exclusion file and the classification change log are published with it.
## What AEO is, and why it's not just SEO
Traditional SEO primarily optimises for ranking in a list of search results. AEO optimises for being selected, cited, or acted upon by an AI system. The technical signals overlap, but they are not identical. Robots.txt access rules, structured data, and machine-readable site metadata increasingly determine whether an AI system can confidently retrieve, trust, and recommend a product - and whether an autonomous shopping agent can act on it. This study measures exactly those signals across the live Magento landscape.
## What we scanned, and how
We built the scan specifically for Magento storefronts, using our own open-source audit tooling, and ran it read-only against public pages on 24 July 2026. It targeted 462 domains. Of those, 458 were reachable and 446 were confirmed to be running Magento - that confirmed-Magento set is the denominator for every store-level figure below. During the run, 13 stores returned rate-limiting responses (429/503); those pages were treated conservatively rather than being counted as failures.
For each store, the scanner:
- fetched and parsed `robots.txt`, checking each AI crawler against explicit and wildcard rules;
- confirmed the store was running Magento;
- checked for an `llms.txt` file at the site root;
- located one product page where possible;
- extracted any JSON-LD and Microdata structured data on that page;
- validated the required `Product` fields, including `offers.availability`;
- recorded the result against ten weighted AEO signals.
No store was modified; this was a read-only, outside-in assessment of exactly what a crawler would encounter.
## Finding 1 - 12% of Magento stores block AI crawlers outright
Access is the first gate. If a store's `robots.txt` disallows an AI crawler - explicitly or via a wildcard - nothing downstream matters, because the agent never reads the page.
Share of confirmed-Magento stores blocking each AI crawler (n = 446).
- **GPTBot blocked:** 52 of 446 stores (12%)
- **ClaudeBot blocked:** 54 of 446 stores (12%)
- **PerplexityBot blocked:** 9 of 446 stores (2%)
To put that in human terms: roughly one Magento store in eight is shutting the two largest AI crawlers out of its catalog entirely. The pattern is worth pausing on. GPTBot and ClaudeBot are blocked at almost identical rates while PerplexityBot is blocked at a sixth of that, and we cannot construct a commercial reading of that gap - all three fetch pages for the same purpose. One plausible explanation is that these are not crawler-by-crawler decisions at all but broad "block all AI scrapers" rules copied from a template or shipped by a security plugin, with PerplexityBot simply absent from the list. That is an inference from the shape of a single snapshot, not something this scan measured. A [follow-up study that watched the same stores over time](https://angeo.dev/magento-ai-signals-two-scans/) found no store changing its mind about one crawler on its own, which supports the reading without settling it.
## Finding 2 - 87% of Magento stores have no llms.txt
The `llms.txt` convention gives an AI system a clean, curated map of a site: what the business is, which pages matter, and how the content should be understood. For many stores, publishing one is among the simplest AEO improvements to implement - and adoption is still rare enough that doing it is a genuine differentiator.
llms.txt presence across confirmed-Magento stores (n = 446).
**389 of 446 stores (87%) have no `llms.txt` at all.** Put plainly: nearly nine out of ten Magento stores give AI systems no explicit guidance about which pages represent the business. Only around one store in eight currently exposes this signal - so publishing one puts you ahead of most Magento storefronts we analysed. For a Magento merchant this is close to free: the file can be generated from catalog and CMS data and kept current automatically.
## Finding 3 - 82% of product pages ship no JSON-LD Product schema
To assess product markup fairly, we narrowed to the 223 stores where a product page could be positively identified. Everything in this section uses that 223 as its denominator. The primary split is simple and mutually exclusive: a product page either carries JSON-LD `Product` markup or it does not.
JSON-LD Product presence across stores with a confirmed product page (n = 223).
- **No JSON-LD `Product` markup:** 182 of 223 (82%) - of which 33 fall back on Microdata and 149 expose no product schema at all
- **Has JSON-LD `Product`:** 41 of 223 (18%)
- **Of those 41, missing `offers.availability`:** 10 (24%)
This is the most consequential finding. The vast majority of product pages ship no JSON-LD `Product` markup - the format that is widely supported by modern search engines and AI systems. Within that 82%, a smaller group (33 stores, 15% of the 223) still exposes Microdata: technically machine-readable, but a weaker and less consistently interpreted signal. The remaining pages expose nothing at all.
And even among the minority who did the hard part, nearly a quarter are missing `offers.availability`. That single field is what tells an AI agent whether the item is in stock. Without it, a store can be perfectly indexed and still be passed over at the exact moment a shopper's agent is deciding what to recommend or add to a cart - because the agent cannot confirm the product is buyable.
## Why this matters now
Search is shifting from a list of blue links to a synthesized answer, and increasingly to an agent acting on the shopper's behalf. In that world the winners are not the stores with the prettiest pages - they are the stores whose data is accessible and structured enough for a machine to trust. The scan shows most Magento stores are unprepared on all three fronts at once: some block the crawler, most omit the site-level map, and the great majority ship product pages that machines can't fully read.
The encouraging half of that story is how fixable it is. None of these gaps require replatforming or a redesign. They require correct `robots.txt` rules, an `llms.txt` file, and complete JSON-LD on product pages. Because so few stores have addressed them, the competitive upside for the ones that do is unusually large right now.
## The results at a glance
| Signal | Count | Base | Result |
| GPTBot blocked | 52 | 446 | 12% |
| ClaudeBot blocked | 54 | 446 | 12% |
| PerplexityBot blocked | 9 | 446 | 2% |
| Missing llms.txt | 389 | 446 | 87% |
| No JSON-LD Product | 182 | 223 | 82% |
| Microdata only (subset of the above) | 33 | 223 | 15% |
| Has JSON-LD Product | 41 | 223 | 18% |
| Missing offers.availability | 10 | 41 | 24% |
## How the angeo.dev suite closes each gap
Every gap the scan surfaced maps to an open-source, MIT-licensed module in the `angeo/` suite for Magento 2:
- **Blocked AI crawlers →** `module-robots-txt-aeo` manages an explicit, up-to-date AI-bot allowlist with lossless `robots.txt` round-tripping, so you decide which agents get access instead of a stale template deciding for you.
- **Missing llms.txt →** `module-llms-txt` generates and maintains the file automatically from your catalog and CMS content.
- **Weak or missing product schema →** `module-rich-data` emits complete JSON-LD `Product` markup - including `offers.availability`, shipping details, return policy, and GTIN/MPN - the exact fields the scan found missing.
## A Magento AEO checklist
If you're responsible for a Magento store, start by measuring your own storefront before making any changes, then work through the same signals this scan covered:
- ✓ Verify `robots.txt` - make sure you aren't blocking AI crawlers by accident
- ✓ Publish an `llms.txt` file and keep it in sync with your catalog
- ✓ Emit JSON-LD `Product` markup on every product page
- ✓ Include `offers.availability` so agents can confirm stock
- ✓ Validate your schema against Schema.org and Google's Rich Results Test
The fastest way to see where you stand is `module-aeo-audit`, which runs this same class of checks against your own Magento store from the command line - including `--category` and `--fail-on-severity` flags for CI - so you can measure before and after in under a minute.
## Method and limitations
These figures come from a single automated pass over public pages on 24 July 2026 and are reported as-is. Store-level percentages use the 446 confirmed-Magento domains; product-schema percentages use the 223 stores with a confirmed product page. We publish the denominators alongside every figure so the numbers can be checked rather than taken on trust.
A single-pass scan has real limits worth stating plainly. The scan can under-report signals where a page was rate-limited (13 stores hit 429/503), served from a cache or CDN edge, protected by bot mitigation, gated behind login, or rendered client-side in JavaScript so that structured data isn't present in the initial HTML. Product-page detection is heuristic, which is why we restrict the schema figures to the 223 stores where a product page was positively identified. The results describe what a crawler sees on one visit - a reasonable proxy for what an AI system encounters, but not a substitute for a full per-store audit.
This scan drew its domains without publishing a reproducible list identifier. The [August measurement](https://angeo.dev/magento-ai-signals-two-scans/) does - Tranco list ZJGPG - so that sample can be reconstructed by anyone. That is the main methodological difference between the two, and it is the reason the later one should be cited in preference where the figures agree.
[image: AEO scan of 462 Magento stores: 87% have no llms.txt, 82% ship no JSON-LD product schema, and 12% block AI crawlers.]
- [Perplexity vs ChatGPT vs Gemini: How Each AI Discovers Your Products](https://angeo.dev/perplexity-vs-chatgpt-vs-gemini-how-each-ai-discovers-your-products/): The three AI search engines discover products from completely different sources. A decision guide for Magento 2 merchants on which channel to build first.
**Two Magento stores can carry identical products, identical schema, and identical SEO. One appears inside ChatGPT Shopping. The other never does.**
The difference is not better optimisation. It is that ChatGPT, Google, and Perplexity do not discover products the same way - and a store optimised for one of those pipelines can be structurally invisible to the other two.
Verified July 2026 against vendor documentation and reporting. AI shopping surfaces change monthly - protocol versions, regional availability, and crawler names should be re-checked against primary sources before you implement anything here.
**TL;DR - 2 minute version**
- **Each engine leans on a different primary source.** ChatGPT's shopping results run on a feed you push to OpenAI - but its Shopping Research mode reads retailer product pages directly. Google AI Mode reads the Shopping Graph, built mainly from your Merchant Center feed. Perplexity mostly reads your actual page.
- **"Which AI engine is better" is the wrong question.** You are present on all three or absent from all three. The real decision is sequencing - which channel to build first given your market and platform.
- **For most EU merchants today, Perplexity is the fastest channel to become visible**, because it currently has the fewest onboarding barriers.
- **Crawler access and product feeds serve different surfaces.** Crawlers earn citations in conversational answers. Feeds earn placement in shopping results. Doing one does not deliver the other.
- **The underlying product data is largely shared** across ACP, UCP, and Merchant Center. Build one clean dataset, emit three shapes.
## How AI product discovery actually flows
[image: Three AI product discovery pipelines from one merchant dataset: the website]
Primary paths only. Merchant control decreases from left to right - and ChatGPT's Shopping Research mode adds a second route that reads retailer pages directly, discussed below.
Read left to right, the merchant's control decreases and the platform's mediation increases. On the left you own the artefact outright. On the right you are supplying a database you do not operate, and the shopper may never touch your site at all.
## The distinction that explains everything else
Each of these platforms runs more than one pipeline, and almost every AEO checklist collapses them into one.
The **citation surface** answers "what is the best way to do X" with numbered sources. It is fed by web crawling. Your pages, schema, llms.txt, and robots.txt rules all live here.
The **shopping surface** answers "best waterproof hiking boots under €150" with a product carousel showing prices and availability. On ChatGPT and Google this runs primarily on structured product feeds rather than on a crawl of your site.
This is why merchants who correctly allow every AI crawler and publish flawless JSON-LD still find their SKUs missing from ChatGPT product comparisons. The crawler work was not wasted; it was aimed at a different surface.
ChatGPT complicates the picture in a way worth stating up front, because it cuts against the simple version of this rule. Alongside feed-driven results it runs **Shopping Research**, an agentic mode that browses in real time. OpenAI describes its results as organic and based on publicly available retail sites, reading product pages directly and citing sources, with a separate allowlisting process for merchants who want to be eligible. So on ChatGPT there are effectively three routes, not two - and page quality is an input to one of them.
The practical takeaway is not "pages don't matter for shopping." It is that *feeds and pages feed different surfaces, and neither substitutes for the other.* Everything below follows from that.
## Side by side
| | ChatGPT (OpenAI) | Perplexity | Google AI Mode / Gemini |
| **Primary product source** | ACP feed, pushed by merchant | Live page retrieval + optional Merchant Program | Shopping Graph, from Merchant Center |
| **Reads your product page for shopping?** | Not for feed-driven results; Shopping Research reads retailer pages directly | Yes, primarily | Secondary - schema.org markup contributes to the Shopping Graph |
| **Index crawler** | OAI-SearchBot | PerplexityBot | Googlebot |
| **Training crawler** | GPTBot | - | (controlled via `Google-Extended`) |
| **Live user-triggered fetch** | ChatGPT-User | Perplexity-User | - |
| **Honours robots.txt on live fetch** | Yes | Documented as generally not | n/a |
| **Shopping features available to users** | Broadly available | Broadly available | Rolling out by surface and region |
| **Merchant onboarding barrier** | Direct feed access by application; Shopping Research by allowlist | Free program, ~5 minutes | Merchant Center account; UCP capabilities staged |
| **Agentic checkout** | ACP (scope narrowed March 2026) | Instant Buy, PayPal-backed | UCP + Universal Cart |
| **Strongest reported signal** | Feed completeness | Recency | Feed accuracy + conversational attributes |
| **Citation transparency** | Moderate | High - numbered, linked | Low |
## Where to start: a decision table
| If you are... | Start with... | Because |
| A US merchant | **ACP feed** | Feed access is open to you and it is the primary input to feed-driven shopping results |
| An EU / UK merchant | **Perplexity** | The channel with the fewest onboarding barriers right now |
| A large brand with an existing catalog operation | **Merchant Center** | You already have the feed; depth and conversational attributes are the gap |
| Content-led, not catalog-led | **OAI-SearchBot access** | Your value is citations in answers, not product carousels |
| On Hyvä or headless | **Page-level schema** | Your rendering layer is the constraint before any feed work matters |
| B2B / quote-based | **Page-level schema + llms.txt** | No shopping surface applies; you compete for citations in procurement research |
Two caveats on reading this table. First, "start with" is not "only do" - these channels compound, and the sequence is about where the first month of work returns most. Second, every row assumes the technical floor is already in place: server-rendered content, valid Product schema, and crawler access. Without that floor, no feed rescues you.
## ChatGPT: the feed carries the catalog, the page still carries the story
The consequential fact about ChatGPT's feed-driven shopping results is that product data is not crawled - the merchant pushes a structured file to a secure OpenAI endpoint. Through the Agentic Commerce Protocol, merchants share product feeds and promotions so their catalogs are represented in ChatGPT, with delivery paths including third-party providers such as Salesforce and Stripe.
This changed direction in March 2026, and much published guidance has not caught up: OpenAI stepped away from Instant Checkout and put its weight behind product discovery instead. The ambition of buying without leaving the chat gave way to a more modest, more durable mechanism - get the catalog data right, let the purchase complete on the merchant's site.
Shopping Research sits alongside that. It is an agentic mode that runs real-time searches and assembles a buyer's guide, and OpenAI states plainly that results are organic and based on publicly available retail sites - reading product pages directly, citing sources, and avoiding low-quality sites. Merchants who want to be eligible follow a separate allowlisting process. If you have concluded from the feed architecture that your product pages are irrelevant to ChatGPT, this is the correction: they are irrelevant to one surface and load-bearing on another.
Shopify and Etsy catalogs are already integrated with no additional setup. OpenAI has said a self-serve merchant platform is coming, with expansion to more merchants and regions over time.
The crawlers serve the citation surface. OpenAI runs GPTBot for training, OAI-SearchBot for ChatGPT search visibility, and ChatGPT-User for user-triggered fetches, plus an ads agent. The split is load-bearing: blocking GPTBot opts you out of training while allowing OAI-SearchBot keeps you citable in ChatGPT. Merchants who blanket-block "OpenAI" usually intend the former and accidentally do the latter.
Worth knowing for measurement: log-file analysis suggests ChatGPT-User traffic has declined while OAI-SearchBot crawling has risen, consistent with OpenAI building its own index rather than fetching pages in real time. Monitoring a single user agent will mislead you.
**Strengths**
Largest LLM search audience; merchant-controlled feed data with frequent refresh; results are organic rather than paid; page quality still counts on the Shopping Research surface.
**Limitations**
Direct feed access is gated by application; two separate onboarding paths to manage; feed quality, not page quality, is what drives feed-driven placement.
**Magento path:** [robots.txt rules per bot](https://angeo.dev/magento-2-robots-txt-chatgpt-gemini-ai-bots/) for the citation and research surfaces, [ACP feed](https://angeo.dev/magento-2-chatgpt-shopping-registration/) for the shopping surface.
## Perplexity: the engine where your HTML is the main input
Perplexity's architecture is different, and for a Magento merchant that difference is favourable.
It uses two agents: PerplexityBot builds the search index and obeys robots.txt, while Perplexity-User fetches pages live and, by Perplexity's own documentation, generally ignores robots.txt. A well-structured product page can therefore be read and cited with no feed, no application, and no regional eligibility.
Independent analyses consistently suggest freshness is among the strongest observed signals here - more so than on the other engines - which makes refreshing existing pages higher-yield than publishing new ones. Perplexity does not publish ranking factors, so treat that as an observed pattern rather than a documented rule.
There is an optional layer on top: the Perplexity Merchant Program is free, takes about five minutes to apply for, and provides better product indexing, in-chat checkout capability, and performance data. It is additive rather than gatekeeping.
Measurement is the cleanest of the three. Every answer ships with numbered citations linked to source URLs, which makes it one of the easiest engines for citation-share measurement - you can count citations directly per prompt rather than inferring them.
Two caveats stated plainly rather than buried. Perplexity's crawling practices are contested: Cloudflare published research in August 2025 alleging undeclared "stealth" crawlers reaching content on sites that had blocked all bots, which Perplexity disputed as user-driven, browser-like fetches. And there is active legal exposure - Amazon filed suit in March 2026 accusing Perplexity of scraping product pages and reviews without authorisation, alongside a preliminary injunction granted the same month against the Comet browser agent, on the reasoning that accessing logged-in areas without authorisation constitutes unauthorised access even with user permission. That ruling constrains what any agent may do inside authenticated areas of a store, not just Perplexity's.
**Strengths**
Lowest onboarding barrier of the three; transparent citations make measurement trivial; page quality translates directly into visibility.
**Limitations**
Smaller audience than ChatGPT or Google; legal and reputational volatility; recency requirement means content decays without maintenance.
**Magento path:** this is where server-rendered, schema-complete pages pay off immediately. If you run [Hyvä, check the Product entity gap](https://angeo.dev/hyva-theme-product-schema-gap/) - Perplexity is the engine most likely to be reading that markup rather than a feed.
## Google: the feed is the front door
[content truncated]
- [How We Took Magento AI Visibility from 20% to 86% (Case Study)](https://angeo.dev/magento-ai-visibility-case-study-20-to-86/): A live Magento 2 store went from a 20% to an 86% AEO score - the first jump took under an hour. The exact steps, full audit data, and what we left unchanged.
A live Magento 2 store went from a 20% to an 86% AEO score - and the first jump took under an hour. Here's the exact sequence of changes, the full audit history, what we deliberately left untouched, and the one thing that quietly pulled the score back down.
**TL;DR**
- A default Magento 2 install scored **20% ("Critical")** for AI visibility - generative search engines were effectively locked out.
- With free, open-source modules it reached **86% ("Excellent")**, tracked across 33 audits. The first two fixes alone - done in well under an hour - moved it from 20% to 37%.
- We expected structured data to do the heavy lifting. The first big jump actually came from a one-line `robots.txt` change.
- The score later eased back to **79% ("Good")** - nothing broke; the files simply went stale. **Freshness turned out to matter as much as correctness.**
20%Start · Critical
86%Peak · Excellent
79%After drift · Good
## Methodology
Before the story, the setup - so the numbers are reproducible rather than anecdotal.
StoreMagento Open Source 2.4.x
EnvironmentLive demo store
Period7-27 June 2026 (calendar)
Active workHours, not days
Audits33 (29 in rolling 30 days)
Tool`angeo:aeo:audit` (open-source CLI)
Signals scored15+, individually weighted
A word on timing, since it's easy to misread. The audits span three weeks of *calendar* time, but that's not how long the work took - most days nothing was touched. The hands-on effort was a handful of short sessions: the first two fixes took well under an hour and the full optimization a few hours spread across those sessions. That matches the rule of thumb we quote elsewhere - a typical mid-size store reaches a strong score in roughly 90 minutes of focused work. The calendar span here exists because we also wanted to observe what happens when a store is then left alone (see "the plot twist" below).
The brand-visibility checks rely on querying live AI models directly. As a registered member of the [Anthropic Claude Partner Network](https://claude.com/partners), we test recall and citation against Claude, ChatGPT, Gemini and Perplexity as part of our day-to-day module work - so these measurements come from hands-on practice with the models, not secondhand reporting.
### What we deliberately did *not* change
To isolate the effect of answer-engine optimization, everything outside it was held constant. We did not touch:
| Theme | Hosting / server | Page-speed work |
| Product copy | URL structure | Classic SEO settings |
Whatever moved the score moved because of the AEO layer alone - not faster pages or rewritten content.
## What a 20% score actually means
"20%" sounds abstract until you translate it into how generative search treats the store:
→ ChatGPT may never discover the catalog in the first place.
→ Perplexity can crawl the pages but can't reliably parse the products.
→ AI shopping agents have almost no structured data to trust, so they default to a competitor that does.
A store can rank #1 on Google and still land here. Classic SEO and answer-engine readiness are [different disciplines](https://angeo.dev/seo-vs-geo-vs-aeo-practical-differences-for-e-commerce/): one optimizes for a ranked list of links, the other for being *selected and quoted* inside a single generated answer.
## The starting point: 20%, nine failures
The first audit was blunt:
```
AEO Score: 20% - Critical
✓ Pass: 1 ⚠ Warn: 5 ✗ Fail: 9
```
[image: Magento 2 AEO audit CLI output showing a 20% Critical score on a default install: 1 pass, 5 warnings and 9 failing checks including robots.txt, llms.txt, llms.jsonl, sitemap.xml and Product JSON-LD]
The default Magento 2 install scores 20% ("Critical") in the `angeo:aeo:audit` CLI - the literal out-of-the-box state, not a worst case staged for contrast.
| Check | Status | What generative search sees |
| robots.txt - AI bot access | ✗ FAIL | No explicit rules for AI indexers |
| llms.txt - content map | ✗ FAIL | 404 - no map of the store |
| llms.jsonl - machine catalog | ✗ FAIL | 404 - no structured catalog |
| sitemap.xml | ✗ FAIL | Not in standard locations |
| Product JSON-LD | ✗ FAIL | No product schema on product pages |
| Merchant policies | ✗ FAIL | No schema to attach policies to |
| Organization schema | ✗ FAIL | No brand entity on the homepage |
| UCP profile | ✗ FAIL | 404 - no agentic-commerce profile |
| JSON-LD quality | ✗ FAIL | No WebSite, Product or BreadcrumbList |
The lone pass was canonical/hreflang consistency, which Magento handles natively. Everything an LLM needs to find, understand and trust the store was absent.
## The climb: 20% to 86%
Because every change was re-audited, the trajectory is real telemetry, not a tidy reconstruction.
[image: Angeo AEO Score Trend dashboard for a Magento 2 store, showing a staircase climb from a 20% Critical baseline up to an 86% Excellent peak across the audit history, with each sharp step marking a high-weight check turning to PASS]
The AEO score-trend dashboard: a staircase, not a slope. Each sharp step is a high-weight check flipping to PASS as the store climbs from 20% to 86%.
| Date | Score | P / W / F | What changed |
| Jun 7, 18:32 | 20% - Critical | 1 / 5 / 9 | Baseline |
| Jun 7, ~19:00 | 28% | 2 / 5 / 8 | `robots.txt` - AI bots allowed |
| Jun 7, ~19:03 | 37% | 3 / 5 / 7 | `llms.txt` + `llms.jsonl` |
| Jun 12 | 51% | 4 / 7 / 4 | Product + Organization JSON-LD |
| Jun 12-13 | 60→77% | - | UCP, merchant policies, schema breadth |
| Jun 13, 23:48 | 83% - Good | 9 / 6 / 0 | Last failure cleared |
| Jun 14+ | 86% - Excellent | 11 / 5 / 0 | Full core stack live |
### The surprise: the cheapest fix moved the most
Going in, we assumed Product schema would dominate the score. It didn't. The single highest-leverage change was `robots.txt`.
[image: Magento 2 AEO audit after the robots.txt fix: score rises to 28% with the robots.txt AI bot access check now passing (all 12 AI bots permitted, sitemap declared) while llms.txt and structured-data checks still fail]
After a one-line `robots.txt` change the score jumps from 20% to 28% - the robots.txt check flips to PASS while everything downstream still fails.
Magento's default file was written for Google years ago and names none of the modern AI indexers. Until it explicitly allows them, OpenAI's `OAI-SearchBot`, `GPTBot`, `PerplexityBot`, `ClaudeBot` and `Google-Extended` never reliably crawl the store - so nothing else you do downstream can even be seen.
> We expected structured data to make the biggest difference. The first major jump came from a one-line crawler-access fix. Visibility starts with permission to be crawled - everything else is downstream of that.
### The content map: llms.txt + llms.jsonl
The next step generated two files in one command:
```
bin/magento angeo:llms:generate
```
[image: Magento 2 AEO audit at 37% after generating llms.txt and llms.jsonl: the llms.txt content-map check passes with 3 sections and 220 links, lifting the score above the robots.txt-only baseline]
Generating `llms.txt` and `llms.jsonl` in one command takes the store to 37% - the content-map check now passes with 3 sections and 220 links.
`llms.txt` is a small Markdown file at the site root that tells an LLM what the store is and where its key pages live. It's an [open proposal (llmstxt.org)](https://llmstxt.org/) that crawlers such as Perplexity have publicly supported. The cleanest way to think about it: **where `robots.txt` tells crawlers what *not* to index, `llms.txt` helps reasoning models understand what the site actually contains.** Its sibling, `llms.jsonl`, is a line-delimited catalog where each line is one self-contained product record, which is far easier for a model to ingest than scraping rendered HTML. The run produced a valid `llms.txt` (3 sections, 220 links) and 221 catalog records.
### Structured data carries most of the weight
The heaviest checks (weight 1.0) are Product [JSON-LD](https://schema.org/Product) and the AI product feed. Valid Product schema with `AggregateRating` and `BreadcrumbList`, plus Organization schema for brand-entity disambiguation, is what carried the store from "Good" into "Excellent." By June 14 it held **86% with zero failures**.
## The plot twist: back down to 79%
Most case studies stop at the peak. Here's what happened next. On June 27:
```
AEO Score: 79% - Good
✓ Pass: 9 ⚠ Warn: 7 ✗ Fail: 0
```
[image: Magento 2 AEO audit dropping from 86% to 79% with zero failures: three checks slip from PASS to WARN because llms.txt and llms.jsonl are 12 days old and the sitemap.xml newest lastmod is 233 days old, which AI crawlers may read as an inactive store]
No code changed, yet the score eased to 79%: stale `llms` files (12 days old) and an old sitemap `` (233 days) push three checks from PASS to WARN.
Still zero failures, but seven points below the peak - with no code change. Three checks had slipped from PASS to WARN for one shared reason: **staleness**.
| Check | Status | Why |
| llms.txt | ⚠ WARN | 12 days old - regenerate via cron |
| llms.jsonl | ⚠ WARN | 12 days old - same fix |
| sitemap.xml | ⚠ WARN | Newest `` 233 days old - looks inactive |
To a model revisiting the site, a months-old sitemap and a two-week-old content map read as a store that may no longer be trading - so it gets quietly down-weighted against rivals whose data looks live. The fix is mundane: run Magento cron so these files regenerate on a schedule. The lesson is not: **an AEO setup is something you maintain, not something you finish.**
## What "Excellent" unlocked
The score isn't vanity - the same audit measures real recall inside AI models, and on this store that check passed:
100%Mentioned
67%Recommended
100%URL cited
These rates were measured across **3 representative test prompts** sent to the model and scored for whether the store was mentioned, recommended, and cited by URL. It's a small sample - a directional signal, not a statistical claim - but the direction is unambiguous: a store that was invisible now appears in every test prompt and gets cited each time (overall 87/100, grade B). That's the line between existing and not existing inside an AI-generated answer.
## The three biggest lessons
### If you remember nothing else
1. **Visibility starts with crawlability.** If AI indexers can't enter, no amount of schema matters. Fix `robots.txt` first.
2. **Structured data carries most of the score.** Product, Organization and policy JSON-LD are where the weight lives.
3. **Freshness rivals correctness.** Stale files decay your score on their own. Cron is not optional.
## The replication recipe
1. **Fix `robots.txt`** - allow AI indexers, declare the sitemap. *(Best score-per-effort.)*
2. **Generate the content map** - `llms.txt` + `llms.jsonl`.
3. **Enable & verify the sitemap** - Marketing → SEO & Search → Site Map.
4. **Add Product JSON-LD** - required fields plus `AggregateRating` and `BreadcrumbList`.
5. **Add Organization + policy schema** - `hasMerchantReturnPolicy` and `shippingDetails` have been required by [Google](https://developers.google.com/search/docs/appearance/structured-data/product) and [ChatGPT Shopping](https://chatgpt.com/merchants/) since Jan 2026.
6. **Publish the UCP profile** - `/.well-known/ucp` for agentic commerce.
7. **Run cron - and keep it running.** Everything above decays without it.
## Limitations
Read honestly, this study has boundaries worth stating:
* It measures **technical AI readiness, not traffic or revenue.** A higher score improves discoverability; it does not guarantee a model will recommend you.
* The audit score is **not a published ranking factor** of any AI system - it's a proxy for the signals those systems are known to read.
[content truncated]
- [Magento 2 AI Product Description Generator - Multi-Store, Open Source, Groq vs GPT-4.1 Benchmark](https://angeo.dev/magento-2-ai-product-description-generator/): Free open-source Magento 2 AI product description generator for multi-store setups. Supports OpenAI, Claude, Gemini & Groq with performance benchmark.
`angeo/module-ai-description-updater` is an open-source Magento 2 module for bulk AI-powered product description generation across multiple store views and languages - supporting OpenAI, Anthropic Claude, Google Gemini, and Groq. It is free, MIT-licensed, and runs entirely via CLI without requiring an admin user.
[image: Magento 2 AI product description generator - open source module with Groq, OpenAI, Claude, and Gemini support]
angeo/module-ai-description-updater - multi-store, open-source, MIT-licensed
#### Contents
1. Why existing tools fail multi-store setups
2. The Angeo Multi-Store AI Content Framework
3. Benchmark: Groq vs GPT-4.1
4. Why we made it free
5. Installation and first run
6. Key takeaways
7. FAQ
A client came to us with a Magento 2 store running four store views - English, Dutch, German, and French - and 8,000 SKUs. Their product descriptions were either copied from supplier PDFs or missing entirely. The obvious solution was AI generation. The less obvious problem was that every existing solution had at least one critical flaw.
So we built our own. Then we made it open-source.
## Why existing Magento AI description tools fail multi-store setups
Most Magento AI content modules share the same architectural flaw: they save generated content to the **default store scope**.
In Magento 2, when you call $productRepository->get($sku) without a store ID, you get the product in the admin/global scope. When you save changes back, they override all store views. A Dutch store gets English descriptions. The multi-store architecture works correctly - the tooling ignores it.
**This is not a configuration problem.** Writing to the default scope is simpler to implement. Scope-aware generation requires iterating stores, loading products per store, and saving per store. Every competing module takes the simpler path.
The other failures are predictable:
- **No CLI or automation.** Commercial modules require an admin user clicking product by product. For 8,000 SKUs this is not a workflow - it is a full-time job.
- **Single provider lock-in.** Every module we evaluated supports OpenAI only. Groq - free, 14,400 requests/day - did not exist as an option in any Magento module until we built it.
- **No Google Sheets integration.** Merchandising teams commonly maintain spreadsheets of products that need new content. No existing module can read from or write to a Google Sheet.
| Feature | This module | Commercial alternatives |
| CLI + Cron automation | ✓ | Rarely |
| Multi-store (all store views) | ✓ | Rarely |
| Groq - free tier, no card | ✓ | Nowhere |
| Google Sheets SKU source | ✓ | Nowhere |
| Google Sheets export | ✓ | Nowhere |
| Dry-run mode | ✓ | Rarely |
| MIT license | ✓ | Rarely |
| Price | Free | $99-$299/year |
## The Angeo Multi-Store AI Content Framework
The **Angeo Multi-Store AI Content Framework** is the architecture behind this module. It defines four layers:
- **Provider Layer** - a uniform interface across OpenAI, Claude, Gemini, and Groq.
- **Store Iteration Layer** - resolves all active store views before processing any SKUs.
- **Content Pipeline** - for each store × SKU: load in scope → build prompt → generate → save in scope.
- **I/O Layer** - reads SKUs from catalog, Google Sheet, or CLI. Writes to Magento DB, CSV, and Google Sheets.
```
┌─────────────────────────────────────────────────────┐
│ Angeo Multi-Store AI Content Framework │
├──────────────┬──────────────────┬───────────────────┤
│ SKU Source │ Store Iteration │ AI Provider │
│ ────────── │ ────────────── │ ──────────────── │
│ Catalog │ Store 1 (EN) │ OpenAI │
│ G.Sheets │ Store 2 (NL) │ Claude │
│ CLI --sku │ Store 3 (DE) │ Gemini │
│ │ Store 4 (FR) │ Groq (free) │
├──────────────┴──────────────────┴───────────────────┤
│ Content Pipeline │
│ load(sku, storeId) → prompt → generate → save │
├─────────────────────────────────────────────────────┤
│ Output │
│ Magento DB · Local CSV · Google Sheets API v4 │
└─────────────────────────────────────────────────────┘
```
### Store-scope-aware saving - the core difference
php
copy
```
// ✗ Wrong - saves to default scope, overrides all store views
$product = $this->productRepository->get($sku, editMode: true);
$product->setCustomAttribute('description', $generated);
$this->productRepository->save($product);
// ✓ Correct - loads and saves in store scope
$product = $this->productRepository->get($sku, false, $storeId);
$product->setCustomAttribute('description', $generated);
$this->productService->updateAttributes($sku, $generated, $storeId);
```
The store name flows into the prompt automatically. When store_name is "Dutch Jewellery Store", the model adjusts tone and terminology for that market without additional configuration.
### Provider abstraction
Every AI provider implements a single interface: AiProviderInterface::generate(string $system, string $user): string. Adding a new provider requires one class and one line in di.xml. Nothing else changes.
etc/di.xml
copy
```
- ...OpenAiProvider
- ...ClaudeProvider
- ...GeminiProvider
- ...GroqProvider
```
## Benchmark: Groq vs GPT-4.1 for Magento product descriptions
We ran 200 product descriptions from a real Dutch jewellery store through all four providers with the same system prompt and product names.
### Speed - average response time per description
| Provider | Model | Avg. time |
| Groq | llama-3.3-70b-versatile | 0.8s |
| Groq | mixtral-8x7b-32768 | 0.6s |
| Google | gemini-2.0-flash | 1.2s |
| Anthropic | claude-haiku-4-5 | 1.1s |
| OpenAI | gpt-4.1-mini | 1.4s |
| OpenAI | gpt-4.1 | 2.1s |
| Anthropic | claude-sonnet-4-6 | 2.8s |
For 32,000 generations (8,000 SKUs × 4 store views): **Groq ≈ 7 hours, GPT-4.1 ≈ 19 hours**.
### Cost per 1,000 descriptions (~200 words each)
| Provider | Model | Cost / 1k descriptions |
| Groq | llama-3.3-70b-versatile | $0.00 (free tier) |
| Google | gemini-2.0-flash | ~$0.08 |
| OpenAI | gpt-4.1-mini | ~$0.24 |
| Anthropic | claude-haiku-4-5 | ~$0.32 |
| OpenAI | gpt-4.1 | ~$1.80 |
| Anthropic | claude-sonnet-4-6 | ~$2.40 |
### Quality - manual review of 200 samples
| Criteria | Groq Llama 3.3 | GPT-4.1-mini | GPT-4.1 | Claude Sonnet |
| Factual accuracy | ★★★★☆ | ★★★★☆ | ★★★★★ | ★★★★★ |
| Language fluency | ★★★★☆ | ★★★★☆ | ★★★★★ | ★★★★★ |
| SEO keyword use | ★★★☆☆ | ★★★★☆ | ★★★★☆ | ★★★★☆ |
| HTML formatting | ★★★★☆ | ★★★★☆ | ★★★★★ | ★★★★★ |
**Recommendation:** Start with Groq to validate workflow and prompt templates - it costs nothing and runs fast. Switch to GPT-4.1-mini for production if SEO keyword density matters. Use GPT-4.1 or Claude for flagship products where copy quality directly affects conversion.
## Why we made it free
The honest answer is strategy. We are building [angeo.dev](https://angeo.dev) as the default source for AI commerce tooling for Magento. Making modules free and MIT-licensed is how we get distribution.
The business model is professional services - AEO audits, full-stack Magento development, AI commerce implementation for stores that need expert help. The modules are how stores discover we exist. This is not a new model - it is how most successful open-source developer tools operate. The code is free. The expertise applied to a specific store's situation is not.
## Installation and first run
bash - installation
copy
```
composer require angeo/module-ai-description-updater
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento cache:flush
```
### First run with Groq (free, 5 minutes)
1
Get a free Groq API key
Create an account at [console.groq.com](https://console.groq.com) - no credit card required. Generate an API key (starts with gsk_).
2
Configure the module
Stores → Configuration → Angeo → AI Description Updater. Set AI Provider → **Groq (Free)**. Paste your API key.
3
Enable dry-run and test
Set **General → Dry Run → Yes** and run the command below. Check the log to see generated content before committing.
4
Run on a single SKU first
Disable dry-run, then: bin/magento angeo:ai-description:run --sku=YOUR-SKU. Verify in product edit.
5
Run full batch
bin/magento angeo:ai-description:run - processes all active store views automatically.
bash - CLI options
copy
```
# All active store views (default)
bin/magento angeo:ai-description:run
# Single SKU across all stores
bin/magento angeo:ai-description:run --sku=MY-SKU-001
# Single store view only
bin/magento angeo:ai-description:run --store=2
# Dry-run - generate but do not save
bin/magento angeo:ai-description:run --dry-run
# Combine
bin/magento angeo:ai-description:run --sku=MY-SKU --store=2 --dry-run
```
### Key takeaways
- **Magento multi-store AI generation requires store-scope-aware architecture.** Saving without an explicit store ID writes to the default scope - a silent data error affecting every competing module.
- **CLI-first automation scales better than admin UI workflows.** For stores with more than a few hundred products, cron-based generation is the only viable approach.
- **Groq is currently the best free provider for bulk ecommerce AI generation.** 14,400 requests/day, no credit card, Llama 3.3 70B quality. The limitation is SEO keyword density.
- **GPT-4.1-mini provides the best quality/cost balance for production stores.** Comparable output to GPT-4.1 at ~17% of the price.
- **The Angeo Multi-Store AI Content Framework** - provider abstraction + store iteration + scope-aware save - is a reusable pattern for any Magento content generation module.
- **Open-source AI tooling is becoming a competitive advantage in Magento.** Stores that automate content generation now build a corpus of unique descriptions that competitors without tooling cannot replicate at scale.
## Frequently asked questions
Does this work with Adobe Commerce (Magento Enterprise)?
Yes. The module is compatible with Magento 2 Open Source, Adobe Commerce, and Adobe Commerce Cloud. The store-scope architecture is identical across all editions.
Is there a free AI provider for Magento product description generation?
Yes. The module supports Groq, which provides Llama 3.3 70B with 14,400 free requests per day - no credit card required. Get a free API key at [console.groq.com](https://console.groq.com).
What is the difference between Groq and GPT-4.1 for product descriptions?
Groq (Llama 3.3 70B) is free and fast (0.8s average) but produces less SEO-optimised copy. GPT-4.1-mini costs ~$0.24 per 1,000 descriptions and produces better keyword density. GPT-4.1 and Claude Sonnet 4.6 produce the highest quality but cost 10-30× more than free Groq.
Can this module read SKUs from a Google Sheet?
Yes. Enable Google Sheets as SKU source in configuration, provide the Spreadsheet ID from the URL, and set the zero-based column index containing SKUs. The sheet must be publicly readable ("Anyone with the link can view").
Does it overwrite existing descriptions?
Yes - by default it overwrites whatever is currently saved. Use --dry-run first to preview what would change, then filter your SKU list to only target products with empty or thin descriptions.
How do I add a custom AI provider?
Implement Angeo\AiDescriptionUpdater\Api\AiProviderInterface, register it in di.xml under AiProviderService::providers with a unique key, and add a corresponding entry to the AiProvider source model. No other changes required.
## Related open-source modules
[content truncated]
## Comparisons and buyer guides
Vendor and architecture comparisons. Each states its method, verification date and conflict of interest.
- [Migrating from Adobe Commerce (Cloud) to Magento Open Source: Is it worth it?](https://angeo.dev/migrating-from-adobe-commerce-cloud-to-magento-open-source-is-it-worth-it/): Thinking about migrating from Adobe Commerce Cloud to Magento Open Source? Compare real costs, features, and what actually changes for your dev team.
For many eCommerce businesses, Adobe Commerce (formerly Magento Enterprise/Cloud) has been the trusted platform for many years. It offers strong features, a stable base, and support from Adobe. However, things have changed. Over time, the **license price has increased**, and the platform has become **less flexible** for companies that want to grow, move faster, or customize their store freely and they used to use Magento.
Because of this, many brands - small and mid‑size especially - have started to ask a simple but important question: 👉 **Is it time to move to Magento Open Source?**
**Why are more businesses thinking about migration**
Many companies reach a point where Adobe Commerce no longer fits their needs. For example:
- They do not use most of the paid Enterprise features.
- They feel limited by Adobe's strict hosting environment.
- They want faster updates and more control over development.
- They want to reduce long‑term costs.
- They need a more modern storefront or new integrations.
**Understanding the Initial Migration Process**
Before moving from Adobe Commerce to Magento Open Source, businesses usually go through several early steps:
1. **Business Review** - Check what features you use now and what you actually need. Many merchants discover they pay for features they never use.
2. **Technical Audit** - Developers review your current Magento setup, extensions, custom modules, theme, and hosting environment.
3. **Cost & Benefit Analysis** - Compare the cost of staying with Adobe Commerce vs. moving to Open Source. This includes license fees, development costs, and future scaling needs.
4. **Risk & Dependency Check** - Identify possible issues, such as modules that depend on Adobe-only features or areas that require custom replacements.
5. **Planning the Roadmap** - Create a clear migration plan with a timeline, stages, fallback options, and test steps.
These actions help businesses understand whether migration is the right decision and what effort is required.
💰** Cost of Ownership: Adobe Commerce vs. Magento Open Source**
| **Category** | **Adobe Commerce (Cloud)** | **Magento Open Source** |
| **License** | from $22,000-40000/year and up | Free |
| **Hosting** | included (limited control) | any hosting(e.g., Hypernode) |
| **Support** | Adobe support (shared queue) | Dev partner or in-house team |
| **Flexibility** | tied to Adobe ecosystem | full code and architecture control |
| **Release cycles** | Adobe-driven | on your terms |
For mid-size businesses (up to ~$3M annual GMV), switching to Open Source can reduce platform costs by **40-60%**, saving **$100K-$250K over 5 years** - funds better invested in:
- Customer acquisition
- New development teacher based on a niche
- UX improvements
- Marketing automation
- Conversion optimization
⚙️** What Actually Changes**
Both platforms share the same Magento core framework, meaning nothing to change.
**What Changes for Developers**
Adobe Commerce includes proprietary modules like:
- B2B Suite
- Adobe Sensei AI
- Gift Cards
- Visual Merchandiser
On Magento Open Source, you can replace them with alternatives provided by 3d party vendors or develop any customisation that suits you more:
**Additional Technical Considerations for Developers**
1. **Module Compatibility** - Some existing Adobe Commerce modules may not work directly on Open Source, requiring code adjustments or replacements.
2. **Database Structure** - Magento Open Source uses the same database schema as EE, but some EE-specific tables and data (like B2B features, row_id and entitity_id usage) need mapping or migration.
3. **Performance Tuning** - Developers can now choose any hosting or caching strategy (Varnish, Redis, CDN), leading to improved site speed and Core Web Vitals.
4. **Custom Integrations** - Open Source allows seamless integration with external systems such as ERP, CRM, marketing platforms, and headless CMS solutions.
5. **Theme & Front-End** - You have full control over the front-end stack. With modern frameworks, you can improve performance, accessibility, and UX without Adobe restrictions.
6. **Testing & Deployment** - Migration encourages implementing CI/CD pipelines, automated testing, and staging environments to improve developer workflow and reduce errors.
7. **Security Updates** - Developers have full control over when and how to apply Magento security patches, rather than relying on Adobe Cloud release schedules.
**Development Advantages After Migration**
- Cleaner codebase without Adobe-locked modules
- Full control over deployment (CI/CD, Git workflows, dev/stage/prod)
- Ability to choose performance-oriented hosting (e.g., Hypernode)
- No forced upgrades tied to Adobe release cycles
🧭** When It's the Right Time to Migrate**
Consider migration if:
- Your Adobe license is $20-40K+/year, but you only use core features
- You want more control over UX, infrastructure, or release cycles
- Adobe Cloud performance is limiting growth
- You want to reduce long-term platform risk and cost
🧩** Final Thoughts**
Migrating from Adobe Commerce to Magento Open Source is not merely a cost‑cutting decision - it is a **strategic investment in flexibility, autonomy, and long‑term platform stability**. As more merchants shift toward headless architecture, custom customer journeys, and faster deployment cycles, the limitations of Adobe's closed ecosystem become more apparent.
Magento Open Source provides merchants and developers with the freedom to:
- build without licensing restrictions,
- optimize performance with any hosting stack,
- integrate modern tools without compatibility barriers,
- experiment and innovate quickly,
- truly own every layer of their commerce platform.
**Is migration worth it?**
For most mid‑market companies, the answer is increasingly **yes**. The financial savings alone are significant - but the greater value comes from the ability to adapt, scale, and differentiate your business faster than competitors.
If your current Adobe Commerce setup limits your growth, slows your development team, or consumes too much budget, migrating to Magento Open Source can unlock new levels of performance and freedom.
The future of eCommerce belongs to brands with **control**, **speed**, and **technical independence**. Magento Open Source gives you exactly that - without sacrificing the power and extensibility that Magento is known for.
Is Magento Open Source really free?
Yes - the platform itself is free to download and use. You pay for hosting, development, and third-party extensions, but there is no annual license fee.
How long does migration from Adobe Commerce to Magento Open Source take?
For a typical mid-size store, the migration takes 2-4 months. This includes technical audit, data migration, replacing Adobe-specific modules, testing, and go-live.
What features do you lose when migrating from Adobe Commerce?
Adobe Commerce includes proprietary modules like B2B Suite, Adobe Sensei AI, Visual Merchandiser, and Gift Cards. These can be replaced with third-party extensions or custom development.
Will my data be safe during migration?
Yes, if done correctly. Both platforms share the same Magento core database structure. A proper migration includes full data backup, staging environment, and rollback plan.
How much can I save by switching to Magento Open Source?
Mid-size businesses typically save 40-60% on platform costs - $100,000-$250,000 over 5 years.
Do I need a developer to migrate?
Yes. Migration involves database mapping, module replacement, theme adjustments, and infrastructure setup. You will need an experienced Magento developer or certified agency.
- [Adobe Commerce 2.4.7 End of Life: What the June 2028 Decommission Policy Means and Your Four Options](https://angeo.dev/adobe-commerce-2-4-7-end-of-life-options/): Adobe Commerce 2.4.7 support ends, and Cloud environments face a June 1, 2028 upgrade enforcement date. Compare 4 options: upgrade, migrate, stay, or exit.
*This guide reflects Adobe's published lifecycle policy as of June 2026. License figures are independent third-party estimates - Adobe does not publish official pricing. Always verify dates against the [Adobe Commerce Lifecycle policy](https://experienceleague.adobe.com/en/docs/commerce-operations/release/planning/lifecycle-policy) and request a direct quote from Adobe before making budget decisions.*
## TL;DR - the 2-minute version
- Adobe is enforcing version upgrades on Adobe Commerce **on Cloud**. If you run **2.4.7**, the upgrade enforcement date is **June 1, 2028** - after which Adobe may enforce decommissioning of environments still on that version (it reserves the right, rather than guaranteeing an automatic shutdown).
- Adobe Commerce 2.4.7 support ends in stages: **regular support May 31, 2027**; **extended support May 31, 2028**.
- Adobe officially lists **two** supported paths: upgrade to the latest Adobe Commerce, or migrate to Adobe Commerce as a Cloud Service (SaaS).
- Outside Adobe's official scope, two more compatible options exist - **Magento Open Source** and **Mage-OS** - which remove the license fee entirely. These are not endorsed by Adobe.
- Separately from the lifecycle policy: a migration is a practical moment to also fix AI visibility, since most Magento stores are invisible to ChatGPT, Gemini, and Perplexity by default.
- Adobe explicitly states it **reserves the right** to decommission affected environments, rather than guaranteeing automatic shutdown on the date.
- *This guide is informational and does not constitute Adobe guidance.*
[image: Adobe Commerce 2.4.7 end of life timeline - upgrade enforcement date June 1, 2028]
Adobe Commerce 2.4.7 lifecycle: regular support ends May 2027, extended support May 2028, upgrade enforcement June 1, 2028.
**Planning a migration?** If you also want to check how visible your store is to AI search engines, there's a free open-source self-assessment - no signup required. Entirely optional and separate from the migration decision below.
[Get the free assessment →](https://angeo.dev/ai-magento-audit/)
## What the Adobe Commerce 2.4.7 end-of-life notice actually says
If you received the email, the wording is blunt: *"Failure to act by the due date may result in your commerce environment being decommissioned and your store being offline."* That is not marketing language - it's a lifecycle enforcement policy with a hard date.
Here is the Adobe Commerce lifecycle for version 2.4.7 on Cloud, straight from Adobe's policy:
| Milestone | Date |
| Regular support ends | May 31, 2027 |
| Extended support ends | May 31, 2028 |
| Upgrade enforcement date | June 1, 2028 |
On the enforcement date, Adobe states it will stop maintenance of Cloud environments still running 2.4.7 and reserves the right to decommission them - the policy grants Adobe the authority to do so, rather than guaranteeing every store goes offline on that date. The reasoning is legitimate: Adobe is responsible for the security and PCI compliance of the hosted infrastructure, and once the underlying software dependencies (PHP versions, OS packages) hit end-of-life, Adobe can no longer guarantee that coverage. PHP 8.2, for example, reaches end of life on December 31, 2026 - after which the PHP project ships no further security patches, creating a PCI compliance risk for anyone still running it afterward.
So the deadline is real. The question is which direction you move in - and the notice quietly narrows your field to two options when there are four.
## What Adobe officially offers
Adobe's lifecycle enforcement policy provides **two** supported paths:
1. **Upgrade to the latest Adobe Commerce on Cloud version**
2. **Migrate to Adobe Commerce as a Cloud Service (SaaS)**
These are the only options explicitly covered by Adobe in its lifecycle communication.
## What exists outside Adobe's official scope
In the broader Magento ecosystem, two more deployment models exist. **They are not part of Adobe's lifecycle policy and are not endorsed by Adobe** - but they remain technically compatible paths for merchants who choose to leave Adobe's commercial ecosystem:
- **Magento Open Source** - self-hosted, free license.
- **Mage-OS** - a community-governed fork of Magento Open Source.
[image: Comparison of four migration paths: Adobe Commerce, Cloud Service, Magento Open Source and Mage-OS]
Four paths off Adobe Commerce 2.4.7 - two official Adobe options plus two market alternatives.
## All four paths side by side
*Reminder: only the first two paths below are part of Adobe's official lifecycle policy. Magento Open Source and Mage-OS are market alternatives, not Adobe-endorsed options.*
Taken together - Adobe's two official paths plus the two market alternatives - here is the full field. All four sit on the same Magento 2 foundation; the difference is who owns the stack, who pays for what, and how much control you keep.
| Path | License cost | Hosting | Best fit |
| **1. Upgrade Adobe Commerce on Cloud** | Revenue-based (~$40K-$190K+/yr) | Adobe-managed (PaaS) | Complex B2B, needs Adobe support & SLA |
| **2. Adobe Commerce as a Cloud Service** | SaaS subscription | Adobe full-stack (auto-patched) | Want zero infrastructure responsibility |
| **3. Magento Open Source 2.4.8** | $0 | Your own / any host | Have a dev team, want full control |
| **4. Mage-OS** | $0 | Your own / any host | Want independence from Adobe's roadmap |
### Option 1 - Upgrade to the latest Adobe Commerce on Cloud
This keeps your deployment model and moves you to a supported software stack (2.4.8, supported until May 2028, or the newer 2.4.9). You keep the native B2B suite, Adobe Live Search, Page Builder, and Adobe support. The catch Adobe states plainly in the notice: *"this path does not eliminate future version upgrade obligations."* You'll be doing this again at the next enforcement date.
### Option 2 - Migrate to Adobe Commerce as a Cloud Service (SaaS)
Adobe positions this as its recommended long-term destination. Adobe manages all infrastructure, patching, and upgrades automatically, so the version-enforcement problem doesn't recur. The trade-offs are inherent to the SaaS model: less control over the stack, a degree of vendor lock-in and reduced data portability compared with self-hosting, and extension and customisation limits relative to the open codebase of on-premises Magento. You also remain inside Adobe's commercial ecosystem and its pricing. For organisations prioritising operational simplicity over customisation flexibility, it may nonetheless be the preferred option.
### Option 3 - Magento Open Source 2.4.8
Same core codebase as Adobe Commerce - the same PHP 8.2-8.4 runtime, the same EAV catalog model, the same checkout flow, the same Composer extension system. What you give up: the native B2B suite, Adobe Live Search (Sensei), and Adobe's support contract. What you gain: zero license fee and no vendor lock-in - host anywhere. For a store with engineering capacity in-house or via an agency, this can be a suitable option - though the right call depends on your architecture, B2B needs, and how much you relied on Adobe-specific features.
### Option 4 - Mage-OS
Mage-OS is a nonprofit, community-governed fork of Magento Open Source. It's 100% compatible with Magento 2 extensions and themes. At the dependency level the switch can be relatively quick - it's primarily a `composer.json` change plus `composer update` - but a full migration still includes testing, QA, and deployment planning, so treat any single-figure time estimate as the code step only, not the whole project. The current line, Mage-OS 3.x, is built on Magento Open Source 2.4.9 and adds PHP 8.5 support alongside 8.3 and 8.4; it publishes security updates within days of Adobe's monthly patch releases rather than on a quarterly cadence. Note that Mage-OS 3 dropped PHP 8.2 support (minimum is now PHP 8.3) and moved to Symfony 7.4 LTS, so for a store still on PHP 8.2 the move includes a required PHP upgrade, not only a Composer change. If independence from Adobe's commercial priorities matters to you, this is the option the notice will never mention.
## Adobe Commerce vs Magento Open Source vs Mage-OS: feature comparison
This is the comparison most merchants actually want when they hit the 2.4.7 deadline. All three run the same Magento 2 core; the differences are in the commercial layer, governance, and cost. *Note: of the three, only Adobe Commerce is covered by Adobe's lifecycle policy - Magento Open Source and Mage-OS sit outside Adobe's official scope.*
| Feature | Adobe Commerce | Magento Open Source | Mage-OS |
| License cost | Revenue-based ($$$) | Free | Free |
| Core codebase | Magento 2 | Magento 2 | Magento 2 (fork) |
| Native B2B suite | Yes | No (extension) | No (extension) |
| Live Search / Sensei AI | Yes | No | No |
| Page Builder | Yes | Yes (since 2.4.3) | Yes |
| Vendor lock-in | High | None | None |
| Hosting | Adobe (PaaS/SaaS) | Any host | Any host |
| Security patch cadence | Adobe quarterly | Adobe quarterly | Days after Patch Tuesday |
| PHP roadmap control | Adobe | Adobe | Community (PHP 8.5, min 8.3) |
| Extension compatibility | Full | Full | Full |
| Adobe support / SLA | Yes | No | No |
| Recurring upgrade enforcement | Yes | Self-managed | Self-managed |
*Features vary by edition and implementation.*
## Adobe Commerce alternatives in 2026
The 2.4.7 deadline is also a natural moment to ask a bigger question: should you stay on the Magento platform at all? For most established Magento merchants the answer is yes - the migration cost and operational disruption of leaving the ecosystem rarely pay off when a same-core option (Magento Open Source or Mage-OS) removes the license fee without a replatform. But it's worth understanding the full field of Adobe Commerce alternatives before committing.
### Same-platform alternatives (no replatform)
These run the identical Magento 2 core, so your catalog, extensions, and team knowledge carry over with minimal disruption:
- **Magento Open Source** - the free, self-hosted edition. Zero license fee, full codebase access, host anywhere. The most direct alternative to Adobe Commerce for teams that don't need the native B2B suite or Adobe support.
- **Mage-OS** - the community-governed fork. Same compatibility as Open Source, with a community-managed release cadence and independent governance. Worth considering if your concern is long-term independence from Adobe's commercial roadmap.
### Different-platform alternatives (full replatform)
These are genuinely different systems. Moving to any of them means rebuilding your storefront, re-integrating systems, and migrating data - a much larger project than staying on the Magento core. They're worth considering only if your reasons for leaving go beyond cost:
- **Shopify Plus** - a fully hosted SaaS platform. Fast to launch and operate, with strong native AI-commerce distribution, but far less control over the stack and a transaction-fee model. Suits merchants who want to offload all infrastructure and accept platform-mediated rules.
- **BigCommerce** - another SaaS option with open APIs and no platform transaction fees, positioned between Shopify's simplicity and Magento's flexibility.
- **WooCommerce** - the WordPress-based, open-source option. Lower ceiling for large complex catalogs, but a fit for content-led stores already living in WordPress.
For a merchant who simply received a 2.4.7 notice and wants to control cost, a full replatform to Shopify Plus, BigCommerce, or WooCommerce is usually the most expensive and disruptive answer to a problem that Magento Open Source or Mage-OS solves with the same codebase. Replatforming makes sense when the business reason is the platform itself - not the Adobe license.
### Modernising the frontend, whichever platform you keep
[content truncated]
- [Adobe Commerce Pricing 2026 - Real Costs vs Magento Open Source](https://angeo.dev/adobe-commerce-pricing-2026/): Adobe Commerce starts at $22,000/year - but real annual cost is 2-3x higher. See the full breakdown: license tiers, hidden costs, and Magento Open Source comparison.
**Note on pricing data:** Adobe Commerce does not publish official pricing. The figures in this article are based on publicly available partner reports, merchant community discussions, G2 and Clutch reviews, and agency experience. Actual pricing depends on your GMV, contract terms, and negotiation. Always request a direct quote from Adobe. Ranges are estimates, not official Adobe prices. See the source methodology section for full details.
*Last updated: May 2026. Adobe Commerce pricing structures and tier thresholds change - verify current figures with Adobe directly before making budget decisions.*
[image: Adobe Commerce pricing 2026 vs Magento Open Source cost comparison]
Adobe Commerce pricing breakdown 2026 - license, hosting, and hidden costs compared to Magento Open Source
### TL;DR - key numbers at a glance
- Adobe Commerce license starts at approximately **$22,000-$40,000/year** for stores under $1M GMV - but that is only the starting point
- Real annual cost including hosting, support, extensions, and upgrades reaches **$100,000-$250,000+** for a mid-size store. Most teams underestimate this.
- Magento Open Source total annual cost for the same store: **$40,000-$100,000**, with full infrastructure control
- The 5-year cost difference is typically **$100,000-$350,000** depending on GMV and contract history
- Adobe Commerce makes financial sense for B2B enterprises above $10M GMV that actively use the B2B Suite - for B2C and lighter B2B use cases, the cost-per-feature equation is worth examining carefully
Jump to section:
How pricing works
Adobe Commerce tiers
Hidden costs
Open Source real cost
Pricing comparison
5-year TCO
Feature decision matrix
When Adobe wins
Migration risks
Cloud architecture
Other platforms
Who should NOT migrate
Negotiation tips
Migration decision
Data & sources
FAQ
If you have tried to find Adobe Commerce pricing online, you already know the problem: Adobe does not publish a price list. Every page ends with "Contact us for a quote." This is not an accident - the pricing model is complex enough that a single number would be misleading.
This article pulls together what is publicly known from merchant communities, agency experience, and platform migration projects. The goal is not a definitive price tag. The goal is a **framework for thinking about the real cost** - the visible line items, the ones that surprise you at renewal, and a grounded comparison with Magento Open Source so you can walk into an Adobe sales conversation with realistic expectations.
## How Adobe Commerce pricing works
### Why Adobe pricing is difficult to estimate publicly
Adobe Commerce pricing is genuinely difficult to publish as a simple price list - and it is worth understanding why before evaluating any specific number. Several structural factors make standardised pricing impractical:
- **Contract variability.** Each Adobe Commerce contract is individually negotiated. Two merchants with identical GMV and feature requirements can end up with materially different rates based on timing, sales team incentives, and competing bids on the table.
- **GMV threshold structure.** Adobe uses GMV tiers, but the thresholds themselves are not publicly documented and can shift between contract cycles. A merchant at $4.8M GMV may be in a different tier than the published wisdom suggests.
- **Bundled add-ons.** Adobe Experience Cloud components - Analytics, Target, Marketo, AEM - are frequently bundled into Commerce contracts at custom rates that bear little resemblance to their standalone list prices.
- **Negotiated renewals.** Renewal pricing depends heavily on prior contract terms, GMV trajectory, and merchant negotiation. The same store could see a 5% increase, a 25% increase, or a 10% decrease at renewal depending entirely on how the conversation is handled.
- **Enterprise procurement dynamics.** Larger merchants negotiate through procurement teams with master service agreements, multi-product Adobe contracts, and volume commitments that override standard pricing entirely.
This is why community-aggregated ranges are the best signal available without direct negotiation - and why a written quote from Adobe is the only way to know your actual price.
### Pricing model basics
Adobe Commerce uses a **GMV-based licensing model** - your annual license fee scales with your store's gross merchandise volume. Two merchants running identical stores can pay very different amounts based on their revenue.
| Product | Hosting | Infrastructure control | Typical use case |
| **Adobe Commerce (on-premise)** | You choose and manage | Full | Enterprises with own DevOps team |
| **Adobe Commerce Cloud** | Included (Adobe-managed) | Limited - Adobe controls the stack | Teams without infrastructure resources |
Most mid-size merchants end up on **Adobe Commerce Cloud** because managing Magento infrastructure in-house requires significant DevOps investment. This guide focuses on the Cloud product - but the licensing cost structure applies to both.
**How GMV-based pricing works in practice:** Adobe sets pricing tiers based on annual GMV. When your store grows past a tier threshold, your license cost increases at renewal - sometimes significantly. This is where many teams get surprised: the invoice arrives and the price has jumped, not because you negotiated a bad deal, but because your business grew. A store that moved from $800K to $1.5M GMV has realistically crossed into the next tier and should budget for a 40-60% renewal increase on the license alone.
**Merchant example (anonymised):** A EU B2B retailer doing approximately $4M GMV reported a renewal increase from ~$48,000 to ~$71,000 after crossing the next GMV tier - without any new features added to the contract. The increase was triggered entirely by revenue growth. Their dev team had not budgeted for it.
## Adobe Commerce pricing by GMV tier (2026 estimates)
Based on publicly reported figures from merchant communities, agency partners, and platform comparison reports, here are the approximate license cost ranges merchants have reported. These are *license costs only* - not total cost of ownership.
| Annual GMV | Reported license range / year | Cloud hosting add-on | Approx. total platform cost |
| Up to $1M | $22,000 - $40,000 | $12,000 - $18,000 | $34,000 - $58,000 |
| $1M - $5M | $40,000 - $75,000 | $15,000 - $25,000 | $55,000 - $100,000 |
| $5M - $25M | $75,000 - $125,000 | $20,000 - $40,000 | $95,000 - $165,000 |
| $25M+ | $125,000 - $300,000+ | Custom | $150,000 - $400,000+ |
Community-reported ranges, not official Adobe pricing. Your actual quote depends on negotiation, contract length, included add-ons, and Adobe's current structure. Use as a starting reference only.
## The hidden costs of Adobe Commerce
The license and hosting are the visible part of the bill. The invoice shock usually happens later - when mandatory upgrades, support escalations, and extension replacements land in the budget. These are the costs that consistently surprise teams new to the platform.
| Cost category | Typical annual range | Notes |
| **License** | $22,000 - $125,000+ | GMV-based, escalates at renewal as you grow |
| **Adobe Cloud hosting** | $12,000 - $40,000 | Limited infrastructure control, fixed tiers |
| **Priority support SLA** | $8,000 - $20,000 | Base support included; faster response costs extra |
| **Third-party extensions** | $5,000 - $30,000 | Search, PIM, loyalty, advanced checkout - none included |
| **Mandatory platform upgrades** | $15,000 - $50,000 per major version | Required to maintain security support; dev cost is yours |
| **Development & maintenance** | $40,000 - $120,000 | Adobe Cloud has more constrained CI/CD workflows and deployment flexibility compared to self-managed infrastructure |
| **Adobe Experience add-ons** | $30,000 - $80,000 | Analytics, Target, Marketo - often bundled into enterprise contracts |
| **Realistic annual total (mid-size store)** | **$100,000 - $250,000+** | For a store doing $1M-$5M GMV |
**The upgrade trap - most merchants underestimate this:** Adobe Commerce major version upgrades are not optional. Once a version reaches end-of-life, security patches stop. Each major upgrade typically requires $20,000-$50,000 in development work - retesting customisations, replacing incompatible extensions, rebuilding anything that depended on deprecated APIs. This is not in the license cost. It lands in your development budget, usually with 3-6 months notice.
**Merchant example (anonymised):** A mid-size fashion retailer in the $2-3M GMV range described their experience with a mandatory upgrade cycle: "We budgeted $15,000. It ended up at $38,000 because three of our key extensions were incompatible and needed either replacement or custom redevelopment. The timeline also slipped by 6 weeks." This pattern - underestimating upgrade scope - is consistently reported across the community.
## What Magento Open Source actually costs
The license is $0. That does not mean the platform is free to run - but the cost structure is fundamentally different, and the key difference is not just the number. **It is the control.** With Open Source, every line item is a choice. You invest more in development and less in hosting, or vice versa, depending on your priorities. Adobe Commerce locks you into their hosting tier, their upgrade cycle, and their support queue.
| Cost category | Typical annual range | Notes |
| **License** | $0 | MIT-licensed open source |
| **Hosting (Hypernode, Cloudways, AWS)** | $2,400 - $9,600 | Full control over infrastructure, scaling, CDN |
| **Extensions** | $3,000 - $15,000 | Wider marketplace, no vendor lock-in, one-time purchases common |
| **Development & maintenance** | $30,000 - $80,000 | Agency or in-house; full CI/CD and Git deployment freedom |
| **Security patches** | $0 - $5,000 | Free patches; developer time to apply and test them |
| **Support** | $0 - $15,000 | Dev partner SLA or in-house - your choice of provider and price |
| **Realistic annual total (mid-size store)** | **$40,000 - $100,000** | For a store doing $1M-$5M GMV |
Open Source costs tend to stabilise over time - the initial setup and migration investment depreciates, hosting costs don't escalate with GMV growth, and you are not on a mandatory upgrade calendar. Adobe Commerce costs typically increase as your business grows, precisely when budget pressure is highest.
## Adobe Commerce vs Magento Open Source pricing: direct comparison
The numbers side by side, for a store doing $2M GMV annually:
| Cost category | Adobe Commerce Cloud | Magento Open Source | Difference |
| License | $55,000 - $75,000 | $0 | -$55,000-75,000 |
| Hosting | $18,000 - $25,000 | $4,000 - $8,000 | -$10,000-21,000 |
| Extensions | $8,000 - $20,000 | $5,000 - $15,000 | -$3,000-5,000 |
| Development | $60,000 - $100,000 | $40,000 - $80,000 | -$20,000 |
| Support SLA | $10,000 - $20,000 | $5,000 - $15,000 | -$5,000 |
| Mandatory upgrades (amortised) | $8,000 - $15,000 | $3,000 - $8,000 | -$5,000-7,000 |
| **Annual total** | **$159,000 - $255,000** | **$57,000 - $126,000** | **$60,000-130,000 saved** |
The development line is where most comparisons go wrong. Open Source development is not cheaper per hour - good Magento developers cost the same on both platforms. What changes is the *scope*: Adobe Cloud's more constrained deployment workflows, mandatory upgrade retesting, and extension compatibility requirements consistently add to dev budgets compared to equivalent Open Source projects. The exact premium varies by team and project - 20-40% is a commonly reported range, not a guarantee.
[content truncated]
- [Shopify vs Magento for AI Commerce in 2026: Platform-Mediated vs Merchant-Controlled AEO](https://angeo.dev/shopify-vs-magento-ai-commerce-aeo-2026/): Shopify won AI distribution. Magento owns AI infrastructure. Full 2026 comparison of Agentic Storefronts vs Merchant-Controlled AEO - capabilities, retrieval tests, key findings.
**In March 2026, Shopify announced that its merchant ecosystem was positioned for default discovery inside ChatGPT via Agentic Storefronts - with no individual setup required from merchants. One week after reporting its fastest quarterly revenue growth in four years, the stock fell 16%.**
Both facts are true simultaneously. They describe where AI commerce actually sits in 2026: infrastructure that is genuinely transformative, deployed into a market uncertain whether the near-term economics hold.
For merchants choosing between platforms - or managing existing Adobe Commerce / Magento 2 infrastructure - the question is narrower than the stock story: which architecture gives you the most controllable path to AI commerce visibility right now?
This article frames the answer through a single distinction: **platform-mediated AI distribution** (Shopify's bet) versus **[Merchant-Controlled AEO](https://angeo.dev/merchant-controlled-aeo/)** (the approach Magento merchants must build themselves, and increasingly the more defensible long-term position).
[image: Shopify vs Magento for AI Commerce in 2026 - platform-mediated AI distribution via Agentic Storefronts compared to Merchant-Controlled AEO on Adobe Commerce]
## Key findings (as of May 2026)
1. **Shopify wins distribution.** Agentic Storefronts positioned millions of merchants for default ChatGPT visibility in March 2026 - onboarding effort is near-zero for eligible US merchants.
2. **Magento wins control.** A default Adobe Commerce install scores ~25% on a 9-signal AEO audit. With free open-source modules, 80-90% is achievable in approximately 90 minutes.
3. **Both reach the same AI channels.** ChatGPT, Microsoft Copilot, Google AI Mode, Gemini, and Perplexity are technically accessible from either platform.
4. **Retrieval quality is platform-agnostic.** JavaScript-rendered content is invisible to AI extraction on both Shopify and Magento by default. The Agentic Commerce Protocol (ACP) feed solves discovery; it does not solve on-page extraction.
5. **Auditability differs sharply.** Magento's AEO signals are inspectable with one CLI command. Shopify's distribution layer is largely opaque to the individual merchant.
6. **Multi-store and B2B favor Magento.** Per-store-view AEO configuration, B2B price books, and ERP integration remain Magento-native territory.
>
**TL;DR** - Shopify wins distribution. Magento wins control. Both can reach the same AI channels. The platform choice matters less than the AEO implementation you build on top of it.
## The two paths to AI commerce visibility
The fundamental difference between the two platforms is architectural, not cosmetic:
```
SHOPIFY - Platform-Mediated AI Distribution
Merchant catalog
↓
Shopify Catalog (platform-managed)
↓
Agentic Commerce Protocol (ACP) syndication
↓
OpenAI / Microsoft Copilot / Google AI Mode / Gemini
↓
AI recommendation
MAGENTO - Merchant-Controlled AEO
Merchant catalog
↓
robots.txt - OAI-SearchBot, PerplexityBot, Google-Extended access
llms.txt - machine-readable catalog map
Product JSON-LD schema (with offers.availability)
ACP product feed (generated locally)
MCP server endpoints (live agent access)
Server-rendered content (extractable by AI crawlers)
↓
AI crawler access + retrieval + feed ingestion
↓
AI recommendation
```
Shopify handles the distribution layer on the merchant's behalf. Magento exposes the full stack - each signal configured, testable, and auditable by the merchant.
Neither path is inherently superior. They reflect different philosophies about who controls the infrastructure between a merchant and an AI platform.
## The state of play: what each platform delivers
### Shopify - platform-mediated AI distribution
Shopify's AI commerce strategy is the most significant platform-level AEO development of 2026. Via Agentic Storefronts, [Shopify positioned its merchant ecosystem for default discovery inside ChatGPT, Microsoft Copilot, Google AI Mode, and the Gemini app](https://www.shopify.com/news/agentic-commerce-momentum) - managed centrally from the Shopify Admin, with no app installation or separate feed submission required from merchants.
The architecture is technically significant: [Shopify describes syndicating real-time pricing, inventory, images, and variants](https://www.shopify.com/news/shopify-open-ai-commerce) from the Shopify Catalog to OpenAI's shopping layer via the Agentic Commerce Protocol (ACP). Per Shopify's announcements, merchants who had done nothing specific for AI visibility were positioned for product discoverability inside ChatGPT by default - though actual retrieval consistency and ranking behaviour within ChatGPT's shopping layer are not independently verified.
Shopify has also announced native Model Context Protocol (MCP) server support via its AI Toolkit - described as enabling AI agents to access live store data including inventory and specifications. Production MCP adoption in commerce is still early-stage and independently validated agentic commerce workflows remain limited, but the infrastructure appears designed for that direction as the ecosystem matures.
Early reported metrics suggest meaningful traction: [Shopify reported AI-driven traffic surging 8× year-over-year in Q1 2026, with orders from AI-powered searches up nearly 13×](https://finance.yahoo.com/markets/stocks/articles/shopifys-ai-push-sustain-more-161700877.html) - from a small but growing base.
>
**What this means:** A US-based DTC merchant on Shopify who has done literally nothing for AEO is positioned for ChatGPT visibility by default. That is unprecedented for the SMB segment.
### Magento - [Merchant-Controlled AEO](https://angeo.dev/merchant-controlled-aeo/)
Adobe Commerce / Magento 2 has no equivalent platform-level arrangement with OpenAI or other AI platforms. Every AEO signal must be configured deliberately. The default Magento 2 installation scores approximately 25% on a 9-signal AEO audit - based on audits across 50+ stores - with three consistent failure points:
1. **robots.txt blocks AI crawlers** - default wildcard rules prevent OAI-SearchBot, PerplexityBot, and Google-Extended from accessing the store
2. **No llms.txt** - no machine-readable catalog map is present
3. **Product schema missing `offers.availability`** - required field for ChatGPT Shopping ACP conformance checks
Fixing these takes approximately 90 minutes with the right open-source modules. Reaching ChatGPT Shopping eligibility requires a separate application at chatgpt.com/merchants, ACP feed generation, and passing OpenAI's conformance review. There is no automatic path - but the same AI commerce channels are technically reachable through Merchant-Controlled AEO implementation.
Each pillar adds an independent, measurable contribution. By Pillar 4 (ACP feed), retrieval performance becomes competitive with Shopify Agentic Storefronts on the same AI channels.
>
**What this means:** Magento's "disadvantage" is the cost of one afternoon. The "advantage" is that you own and can audit every signal in the stack - which matters more as AI platforms diversify and feed terms evolve.
## Real audit output - what Merchant-Controlled AEO looks like
The abstract comparison becomes concrete when you see what the audit actually returns. Here is the output from `bin/magento angeo:aeo:audit` on a fully configured Adobe Commerce 2.4.7 store (mid-market apparel, ~14k SKUs, EU multi-store):
```
$ bin/magento angeo:aeo:audit --store=default
Running AEO audit for store: default
─────────────────────────────────────────────────────────────
✓ PASS robots.txt All 10 AI bots permitted
OAI-SearchBot, ChatGPT-User, GPTBot,
PerplexityBot, Google-Extended,
ClaudeBot, Claude-Web, Bingbot,
CCBot, Applebot-Extended
✓ PASS llms.txt Generated - 12,400 products mapped
Last regenerated: 2026-05-24 03:00 UTC
Per-store-view: 4 variants active
✓ PASS Product JSON-LD offers.availability present
aggregateRating present (8,200 / 12,400)
brand, sku, gtin13 present
priceValidUntil present
✓ PASS ACP product feed Spec-compliant - 12,400 products
Refresh interval: 15 min
Last successful sync: 2026-05-25 09:15 UTC
OpenAI conformance: PASSED 2026-04-12
✓ PASS MCP server endpoint /mcp/v1 active
Live inventory + pricing exposed
Authentication: bearer token configured
✓ PASS Server-side rendering Product description visible in HTML
No JavaScript-only critical content
✓ PASS FAQPage schema On 8 CMS pages
Average 6 Q&A pairs per page
✓ PASS AI order attribution sales_order.ai_referrer column active
Q1 2026: 1,847 orders attributed
Top source: ChatGPT (62%)
⚠ WARN Canonical consistency 3 product URLs with conflicting hreflang
See: var/log/angeo_aeo_warnings.log
─────────────────────────────────────────────────────────────
AEO Score: 91% - Excellent
Time elapsed: 4.2s
```
On Shopify, AI visibility is largely a black box. You can observe whether products appear in ChatGPT responses. You cannot inspect what `offers.availability` value Shopify is transmitting for a specific variant via ACP, verify the exact feed format OpenAI is receiving, or audit which products are failing conformance checks and why. If a product is not appearing, the debugging path is indirect.
That difference - a 4-second CLI output versus an opaque distribution layer - is what "Merchant-Controlled AEO" means in practice.
## Retrieval tests - what AI engines actually surface
The capability tables describe theoretical reach. Retrieval tests describe what AI engines actually do with the available signals. These are spot-check results from controlled queries run in May 2026 across three store configurations in the same category (industrial test equipment, identical product catalogs replicated across platforms for benchmarking purposes):
| Query | Shopify (Agentic SF) | Magento (default) | Magento (Merchant-Controlled AEO) |
| "best Siemens thermal imaging camera under €2k" | Surfaced - product card | Absent | Surfaced - product card + spec citation |
| "Fluke 87V vs Keysight U1242C" | Surfaced - comparison | Absent | Surfaced - citation in editorial answer |
| "thermal camera with USB-C and 320×240 sensor" | Partial - generic recs | Absent | Surfaced - exact-spec match |
| "recommend a megohmmeter for industrial use" | Surfaced - top 3 | Absent | Surfaced - top 3 with cited specs |
| "who sells calibrated multimeters in the EU" | Partial - US-bias | Absent | Surfaced - EU retailer cited |
ChatGPT retrieval spot-checks, May 2026. Same catalog across configurations. Results are illustrative of architectural difference, not exhaustive ranking benchmarks. AI retrieval is non-deterministic; individual query outcomes vary across sessions.
Two observations from the test pattern:
1. **Default Magento is invisible.** Blocked AI bots, missing llms.txt, incomplete schema, and no ACP feed compound into zero retrieval surface.
2. **Configured Magento matches Shopify on retrieval - and sometimes exceeds it on EU-specific and spec-driven queries.** Agentic Storefronts is currently US-weighted. Detailed spec retrieval depends on schema depth, which Magento exposes more granularly than Shopify's standard product templates.
>
**What this means:** The distribution-versus-control framing is not theoretical. Once a Magento store is configured with Merchant-Controlled AEO, retrieval performance is competitive - and the merchant retains diagnostic control Shopify does not provide.
## Full capability comparison
Each AI engine reachable through at least one primary signal, with secondary signals providing redundancy. Pillar 6 (attribution) is operational - it measures AI traffic rather than enabling it.
| Capability | Shopify | Magento (configured) | Magento (default) |
| **ChatGPT Shopping (ACP)** | ✅ Platform-level via Agentic Storefronts | ✅ Manual - ACP feed + application | ✗ Not configured |
[content truncated]
- [llms.txt for Magento 2: Free vs Paid Module Comparison (2026)](https://angeo.dev/llms-txt-magento-2-free-vs-paid-module-comparison/): llms.txt for Magento 2: free vs paid module comparison. 6 options scored on price, admin UI, CLI & llms.jsonl. Find the right fit in 2 minutes.
### TL;DR - skip to what you need
- Based on publicly available vendor offerings as of May 2026, we identified **six Magento 2 llms.txt solutions we identified during research** - one fully free and five commercial offerings
- Feature sets are **more similar than vendor marketing suggests** - the main differences are admin UI depth, pricing, and output format
- **Does llms.txt improve Google rankings?** No direct signal. The benefit is AI system understanding of your catalog.
- **Which AI platforms read llms.txt?** Perplexity has been one of the strongest public supporters of the llms.txt proposal. Others vary - details in the guide.
- **Time to implement:** 5 minutes with a module. Manual creation is reasonable for small stable catalogs.
[image: llms.txt for Magento 2 - free and paid module comparison 2026]
### Quick answer
The right choice depends on your workflow:
- **Need a free option** → `angeo/module-llms-txt` (MIT, Composer)
- **Need admin-driven content management** → Magedelight, Webkul, Plumrocket, or Eleventex
- **Need documented llms.jsonl support** → verify vendor documentation before purchase; not all extensions support it
- **Need only basic AI crawl visibility** → any actively maintained llms.txt module is sufficient
- **Very small stable catalog** → manual file creation, no module needed
**AI Summary**
Magento stores can generate llms.txt manually or with one of six identified extensions.
The main differences are workflow, automation, and output formats.
llms.txt is not a Google ranking factor, but may help AI systems understand store content more accurately.
In this guide · 14 min read
1. Why Magento stores are talking about llms.txt
2. What is llms.txt?
3. llms.txt vs robots.txt vs sitemap.xml
4. Does llms.txt improve Google rankings?
5. Which AI systems actually read llms.txt?
6. What is llms.jsonl?
7. Module comparison: free vs paid (2026)
8. Installation guide
9. How to verify your setup
10. Manual creation: when and how
11. Can AI agents use llms.txt directly?
12. Sources
13. FAQ
## Why Magento stores are suddenly talking about llms.txt
For most of Magento's history, visibility meant one thing: Google rankings. Then in late 2023 and through 2024, a measurable share of eCommerce discovery began happening inside AI assistants - ChatGPT, Perplexity, Gemini - where users ask product questions and receive recommendations without visiting a search results page.
The shift created a new problem: most Magento stores are opaque to AI systems. A typical product page returns 200-400 KB of HTML - navigation menus, JavaScript bundles, cookie banners, schema fragments, and marketing copy - from which an AI crawler must infer what the store sells, what categories it carries, and whether products are in stock.
`llms.txt` addresses this directly. A 50 KB plain-text file can describe an entire catalog more clearly than 10,000 HTML pages parsed individually. AI systems that support structured content discovery - either directly or as a supplementary signal - can use it to build a more accurate model of your store.
The practical trigger for most Magento merchants: running an AEO audit and discovering their store is invisible in Perplexity results, or being described inaccurately when a potential customer asks an AI assistant about their product category. llms.txt is typically one of the fastest fixes.
## Module comparison: free vs paid (2026)
Features are based solely on publicly documented functionality available on vendor websites as of May 2026. Some vendors may support additional features not publicly listed. Verify with the vendor before purchase. ? = status unclear from public documentation.
**Disclosure:**
We maintain and publish the open-source
`angeo/module-llms-txt` extension referenced in this comparison.
Feature information for competing extensions was collected from publicly
available vendor documentation as of May 2026.
We have no commercial relationship with any of the paid vendors listed.
| Module | Price | llms.txt | llms.jsonl | CLI | Admin UI | Cron | Multi-store |
| **angeo/module-llms-txt** | Free (MIT) | Documented ✓ | Documented ✓ | Documented ✓ | Documented ✓ | Documented ✓ | Documented ✓ |
| **Magedelight** | $129/yr (then $89/yr) | Documented ✓ | Unclear | Unclear | Documented ✓ | Documented ✓ | Documented ✓ |
| **Webkul** | $149/licence | Documented ✓ | Unclear | Unclear | Documented ✓ | Documented ✓ | Unclear |
| **Plumrocket** | Contact vendor | Documented ✓ | Unclear | Unclear | Documented ✓ | Documented ✓ | Documented ✓ |
| **Eleventex** | Contact vendor | Documented ✓ | Unclear | Unclear | Documented ✓ | Documented ✓ | Documented ✓ |
| **Magefan SEO** | Part of paid SEO suite | Documented ✓ | Unclear | Unclear | Documented ✓ | Documented ✓ | Documented ✓ |
¹ Webkul multi-store not explicitly documented on their product page as of May 2026 - confirm directly before purchase.
² Plumrocket and Eleventex pricing requires direct contact or account login - not publicly listed. All prices verified as of May 30, 2026 and may change.
³ Magefan llms.txt generation is available through their SEO extension packages rather than as a standalone llms.txt extension.
**Where paid modules add real value:** Most paid options include a richer admin UI for content selection - choosing which product attributes, categories, or CMS pages to include - and fields for company metadata and usage policy text. For non-technical teams who need to control output from the Magento admin panel without code changes, this is a genuine differentiator. Scheduling granularity (daily/weekly/monthly vs standard Magento cron intervals) also varies.
### Which Magento llms.txt module should you choose?
| Your situation | Recommended approach |
| Small store, stable catalog (under 50 products) | Manual `llms.txt` - full control, no module needed |
| Merchandising or marketing team (non-technical) | Paid module with admin UI - content selection, metadata fields, no CLI required |
| Developer or Composer-first team | Free or paid Composer-based module - CLI generation, cron, no licence key friction |
| Large catalog with frequent price / stock changes | Any module with automated cron - daily regeneration recommended |
| Multi-store Magento setup | Verify per-store-view support with vendor before purchase - not all modules document this |
| AI pipeline integrations or structured catalog work | Module with explicit `llms.jsonl` output support (verify with vendor documentation) |
### When to choose each
### angeo/module-llms-txt
FREE · MIT · Packagist
- You manage Magento via Composer and are comfortable with CLI
- You need `llms.jsonl` output for AI pipeline or structured catalog work
- You use the [AEO audit module](https://angeo.dev/magento-2-aeo-guide/) - llms.txt is Signal #2 in the scored audit
- You want no licensing fees, no external keys, no SaaS dependency
### Paid modules (Magedelight / Plumrocket / Eleventex / Webkul)
PAID · $79-$149/yr
- Your team manages content from the Magento admin panel rather than CLI
- You need fine-grained control over which products, categories, or pages are included
- You want company metadata fields and usage policy text in the generated file
- You are purchasing as part of a broader SEO or AI extension suite (e.g. Magefan)
During our May 2026 research, we identified six Magento 2 llms.txt solutions available at the time of review. There may be others - particularly on GitHub or newer marketplace listings. If you find a comparison error or a missing module, the guide will be updated. This comparison is based on publicly available vendor documentation - including the differences vendors don't advertise.
*This guide is part of the [Merchant-Controlled AEO](https://angeo.dev/merchant-controlled-aeo/) architecture. For the broader picture, see the [Magento 2 AEO Guide 2026](https://angeo.dev/magento-2-aeo-guide/).*
**Disclosure:** We maintain and publish the open-source `angeo/module-llms-txt` extension referenced in this comparison. Feature information for competing extensions was collected from publicly available vendor documentation as of May 2026. We have no commercial relationship with any of the paid vendors listed.
## What is llms.txt?
`llms.txt` is a plain-text Markdown file placed at your store root - `yourstore.com/llms.txt` - that gives AI systems a structured summary of what your website contains. The proposal was introduced by Jeremy Howard in late 2024 and formalised at [llmstxt.org](https://llmstxt.org).
The concept is straightforward: as AI assistants increasingly browse the web to answer questions, a clean, curated file is easier to parse than thousands of pages of HTML with navigation menus, cookie banners, and JavaScript widgets.
For an eCommerce store, a well-generated `llms.txt` typically includes store name and description, category list with URLs, product entries with names, SKUs, prices, and descriptions, key CMS pages, and contact and policy information.
**The standard is still evolving.** llmstxt.org defines a recommended format, but there is no enforcement mechanism and no formal adoption by major AI platforms as of May 2026. Individual platforms vary in how - or whether - they use the file during content discovery. This is low-effort to implement and unlikely to cause harm; the uncertainty is about upside, not risk.
## llms.txt vs robots.txt vs sitemap.xml
| File | Purpose | Who reads it | Format |
| `robots.txt` | Permission layer - tells crawlers what they can access | All crawlers (Googlebot, GPTBot, OAI-SearchBot) | Plain text, directive syntax |
| `sitemap.xml` | URL index - lists all pages for crawlers to find | Search engine crawlers | XML |
| `llms.txt` | Content map - curated summary of what the site contains | AI assistants, LLM crawlers (varies by platform) | Markdown |
| `llms.jsonl` | Machine-readable catalog - structured product data | AI pipelines, vector databases | Line-delimited JSON |
These files are not alternatives - they are layers. `robots.txt` controls access. `sitemap.xml` enables URL discovery. `llms.txt` provides content context. A well-configured Magento store has all three (plus `llms.jsonl` if structured product data for AI pipelines is relevant to your use case).
**Common mistake:** Using `llms.txt` to block AI crawlers. The file has no enforcement capability - it is a content map, not a permission file. To control AI crawler access, use `robots.txt`. The [robots.txt guide for Magento 2](https://angeo.dev/magento-2-robots-txt-chatgpt-gemini-ai-bots/) covers the correct directives for all major AI bots.
## Does llms.txt improve Google rankings?
No - not directly. Google has not announced that `llms.txt` is a ranking signal for traditional Google Search, and Googlebot does not use it as an indexing instruction.
The question of indirect benefit through AI Overviews and Gemini is less clear. `Google-Extended` - Google's separate crawler for AI products - may use structured content signals alongside page content when building AI Overviews summaries. Google has not publicly documented whether or how it uses `llms.txt` specifically in this context.
The more defensible claim is narrower: stores with accurate, structured `llms.txt` files are more likely to be represented correctly when AI systems attempt to summarise their catalog - regardless of whether that triggers a direct ranking benefit. Incorrect AI summaries (wrong categories, outdated products, misrepresented niche) are a real problem that `llms.txt` helps mitigate.
**The practical test:** Search your store name or category in Perplexity and check whether the description matches what you actually sell. If it misrepresents your catalog, updating `llms.txt` is the fastest fix.
## Which AI systems actually read llms.txt?
[content truncated]
- [Best Magento 2 UCP Modules Compared (2026): Discovery, Checkout & AI Agent Support](https://angeo.dev/magento-ucp-modules-compared/): Compare the 4 Magento 2 UCP modules of 2026 - angeo, gtstudio, MSR & spyrosoft - by scope, license and production readiness. Pick the right one once.
What is a Magento 2 UCP module?
A Magento 2 UCP module adds support for the **Universal Commerce Protocol (UCP)** - an open protocol that lets agentic commerce systems discover merchants, read catalog data, build carts, and complete purchases through standardized APIs. Magento 2 has no built-in UCP support, so the capability comes from a module. As of June 2026 there are four publicly available options: **angeo/module-ucp** (discovery-only, MIT), **gtstudio/module-ucp** (full checkout, BSL 1.1), **mahesh-rajawat/module-agentic-ucp** (broad coverage, MIT), and **spyrosoft/magento2-google-ucp** (proof of concept, Apache-2.0).
*UCP is an actively evolving protocol - module capabilities, naming, and the spec itself change frequently. This comparison reflects the state of the available Magento 2 modules and UCP spec version 2026-04-08 as of June 2026, based on each module's public repository and Packagist listing. We update this guide when the landscape shifts.*
[image: Magento 2 UCP modules compared - Universal Commerce Protocol options for Magento store owners covering discovery, checkout, and agentic commerce integration]
*Four publicly available UCP modules now exist for Magento 2 - and they solve very different problems.*
**Universal Commerce Protocol (UCP) is an open protocol that lets agentic commerce systems discover merchants, access catalog information, build carts, and complete purchases through standardized APIs.** For Magento 2, that capability is not built in - it comes from a module. This guide compares the four publicly available options.
### TL;DR - 2 minute version
- Magento has **no built-in UCP support.** To be discoverable by Google-powered shopping surfaces that implement UCP (including AI Mode and Gemini), you need a module - or you build it yourself.
- There are now **at least four publicly available Magento 2 UCP modules**, plus middleware/SaaS bridges. They are **not interchangeable** - some only publish a discovery profile, others implement full agent-driven checkout. **Licenses differ too** (MIT, Apache-2.0, and one Business Source License) - check before you adopt.
- **The single biggest decision:** do you need *profile-only discovery* (low risk, fast to install) or *functional checkout endpoints* (more surface area, more to maintain while the spec is unstable)?
- **Don't install any of them until your AEO foundations are in place.** A UCP profile on a store with blocked crawlers and missing schema is a door with nothing behind it.
- This guide compares the four modules on scope, license, risk, and who each one is for - so you pick once instead of twice.
## First: do you even need a UCP module yet?
Before comparing modules, answer this honestly. UCP makes your store *discoverable* to shopping agents that support the protocol. It does not guarantee recommendations, and UCP-powered shopping features are rolling out gradually, beginning with the US market. International expansion has been announced, but timelines vary by region.
So the case for installing a module *now* is not "instant sales." It's two things:
1. **Early-mover positioning.** Public Magento UCP implementations remain relatively uncommon. Establishing a spec-compliant profile now means you're indexed and ready when your market's agent-shopping surfaces go live, rather than starting from scratch afterward.
2. **It's cheap at the discovery layer.** Publishing a `/.well-known/ucp` profile is, on a compatible Magento environment, a short job rather than a multi-day project.
The case *against* rushing: the checkout side of the spec is still moving. Implementing full agent-driven checkout today means maintaining endpoints against a moving target. That trade-off is exactly what separates the modules below.
If you're not sure where you stand, the honest first step isn't a UCP module at all - it's an [AEO audit](https://angeo.dev/ai-magento-audit/), because UCP sits *on top of* the foundational signals (robots.txt access, JSON-LD with `offers.availability`, llms.txt, product feed). More on that at the end.
## How UCP modules differ: the two layers that matter
Every UCP module addresses some combination of two distinct layers. Understanding this split is the whole game.
**Layer 1 - Discovery (the profile).** Your store publishes a signed file at `yourstore.com/.well-known/ucp` that advertises what it can do - catalog, cart, checkout, order, identity linking. Shopping agents read this "menu" first. Publishing it is low-risk: it's a static, signed declaration, and you only advertise the capabilities you actually support.
**Layer 2 - Execution (the endpoints).** The actual REST endpoints an agent calls to search your catalog, build a cart, and drive a checkout session to completion. This is where the real work - and the real maintenance risk - lives, because these endpoints must track the evolving spec and map cleanly onto Magento's quote/order model.
A module that does only Layer 1 makes you *findable*. A module that does Layer 1 + Layer 2 makes you *transactable*. Neither is "better" - they suit different timelines and risk appetites.
## The four Magento 2 UCP modules, compared
Here's the current landscape, verified against each module's Packagist listing and repository in June 2026. All run on your own Magento instance (no third-party SaaS in the loop), but their scope and licensing differ sharply.
| Module | License | Latest (date) | Production readiness | Scope | Best for |
| **`angeo/module-ucp`** | MIT | 0.1.1-beta (May 2026) | Early-stage / discovery only | Discovery profile only. Serves `/.well-known/ucp` at spec 2026-04-08 with ECDSA P-256 signing, per-store-view capability toggles. Catalog/cart/checkout endpoints are on the roadmap. | Stores wanting early, low-risk presence and an incremental path |
| **`gtstudio/module-ucp`** | **BSL 1.1** | 1.0.0 (Mar 2026) | Production checkout | Discovery profile **+ five checkout session endpoints** (create/get/update/complete/cancel), Magento quote-state mapping, registered shopping-agent tools. | Stores that want functional agent checkout today |
| **`mahesh-rajawat/module-agentic-ucp`** (+ `-checkout` companion) | MIT | 1.0.1 (Apr 2026) | Experimental / broad coverage | Base module: agent discovery, DID authentication, policy enforcement, admin agent registry. Companion adds catalog/cart/checkout/order/tracking REST endpoints. | Stores wanting runtime agent registration and policy control |
| **`spyrosoft/magento2-google-ucp`** | Apache-2.0 | 1.1.0 (Mar 2026) | Proof of concept | Checkout/fulfillment/order capabilities, Google Pay via Przelewy24, DI-based extensibility. Catalog and cart are roadmap, not yet implemented. | Teams evaluating/extending UCP with custom payment handlers |
A few things worth pulling out of that table:
**`angeo/module-ucp` is deliberately the most conservative.** It ships the discovery profile first and adds endpoints as the spec stabilises. The philosophy: don't build functional checkout against a moving target until the target slows down. Lowest maintenance burden, lowest risk - but you are *findable*, not yet *transactable*. MIT-licensed; requires Magento 2.4.7+, PHP 8.2+, and the OpenSSL extension for ECDSA signing.
**`gtstudio/module-ucp` goes furthest on checkout in a single package.** It implements the five UCP checkout session endpoints and maps Magento quote state (`incomplete → ready_for_complete → completed | cancelled`) directly onto UCP session state, and even seeds a `ucp_checkout` agent with a UCP-aware system prompt. If you want an agent to actually complete a purchase against your store today, this is the most direct route. Two trade-offs: you're maintaining checkout logic against an unstable spec, **and it's licensed under the Business Source License 1.1 - which is source-available, not OSI open-source.** Read the BSL terms (usage restrictions, delayed open-source conversion date) before adopting it commercially.
**`mahesh-rajawat/MSR` splits identity from checkout** across a base + companion module, both MIT. Its differentiator is runtime governance: no hardcoded agents - real agent DIDs are registered in the admin panel, with policy enforcement and per-agent isolated guest carts. If your concern is *which* agents you let transact and under what rules, this architecture leans into that.
**`spyrosoft/magento2-google-ucp` is openly a PoC** (Apache-2.0). Its value is extensibility - clean DI surfaces for plugging in custom payment handlers, validators, and response builders. Two caveats: it currently implements checkout, fulfillment, and order capabilities but **not catalog or cart** (both are on its roadmap), and in its current release **Google Pay is powered by a hard dependency on the Przelewy24 payment module** - relevant if that PSP doesn't fit your market.
## Capability matrix (June 2026 snapshot)
A quick visual of what each module actually implements today (not roadmap). Verified against current repositories, June 2026.
| Capability | angeo | gtstudio | MSR | spyrosoft |
| Discovery profile (`/.well-known/ucp`) | ✓ | ✓ | ✓ | ✓ |
| Checkout session endpoints | ✗ (roadmap) | ✓ | ✓ | ✓ |
| Catalog | ✗ (roadmap) | ✗ | ✓ | ✗ (roadmap) |
| Cart | ✗ (roadmap) | ✗ | ✓ | ✗ (roadmap) |
| Order / fulfillment | ✗ (roadmap) | partial | ✓ | ✓ |
| Agent registry / DID auth | ✗ | ✗ | ✓ | ✗ |
| Signed profile (ECDSA P-256) | ✓ | - | - | - |
| License | MIT | BSL 1.1 | MIT | Apache-2.0 |
*Capabilities change rapidly as the UCP specification evolves. Treat this matrix as a point-in-time comparison rather than a permanent feature list - "partial" means implemented as part of the checkout session lifecycle rather than as a standalone capability. Always confirm against the module's current release before relying on any single cell.*
## A decision path, not a winner
There's no single "best" module, because the right choice is a function of your timeline and your tolerance for spec churn. Walk this:
**Are your AEO foundations done?** (robots.txt allows AI bots, Product JSON-LD with `offers.availability`, llms.txt, product feed.) → If no, **stop.** Fix those first. UCP adds nothing on top of a store AI can't read. Run the [AEO audit](https://angeo.dev/ai-magento-audit/).
**Do you need functional agent checkout *this quarter*?**
- **No - you want presence and readiness** → `angeo/module-ucp`. Profile-only, fast to install on a compatible environment, minimal maintenance, incremental upgrade path as the spec settles, MIT-licensed.
- **Yes - agents must be able to transact now** → `gtstudio/module-ucp` for the most complete single-package checkout (mind the BSL license), **or** `mahesh-rajawat/MSR` if you want MIT licensing plus runtime agent registration and policy control.
**Do you have engineering capacity and want to own the implementation?** → `spyrosoft/magento2-google-ucp` as an Apache-2.0 extensible PoC base - checking the Przelewy24 payment dependency fits your stack.
**A pragmatic combined play many stores will consider:** ship a low-risk discovery profile today (e.g. `angeo/module-ucp`), and prototype checkout separately in staging with one of the full-checkout modules - so your *public* surface stays stable while you experiment with the volatile part out of production.
## What none of these modules do for you
A UCP module gets your store onto the protocol. It does **not** make an agentic commerce system choose you. That depends on factors no module controls:
- **Catalog quality** - complete, real product data, not supplier boilerplate.
- **Pricing competitiveness** - agents compare across merchants when they build recommendations.
- **Review signals** - `aggregateRating` in your schema affects recommendation confidence.
- **Entity authority** - how well-known your brand is across the web.
- **Schema completeness** - JSON-LD with `offers.availability`, the field default Magento most often omits.
[content truncated]
- [Which AEO Options Are Designed for Integration with Magento? A 2026 Buyer's Guide](https://angeo.dev/aeo-options-for-magento/): Which AEO options integrate with Magento? Compare the three routes - open-source, platform-mediated and agency - and choose the right one for your store.
# Which AEO Options Are Designed for Integration with Magento? A 2026 Buyer's Guide
Magento 2 stores have three practical AEO routes: a merchant-controlled open-source approach using free Composer modules, a platform-mediated approach that outsources AI-channel relationships, and a done-for-you agency engagement. Because Magento merchants own their stack - unlike Shopify, where AI-commerce syndication can be handled at the platform level - every AI-visibility signal on Magento must be configured deliberately. This guide explains the options, how they differ, and how to choose.
·
Updated 22 July 2026
*Written by a vendor in this category. AEO tooling and AI-crawler behaviour move fast - verify current specifications and user-agents before implementation.*
## Short answer: the three AEO options for Magento
For a Magento 2 or Adobe Commerce store, the AEO options that integrate at the platform level fall into three categories:
1. **Merchant-controlled, open-source (DIY)** - free MIT-licensed Composer modules that generate `llms.txt`, add JSON-LD `Product` schema, fix AI-crawler access in `robots.txt`, and export AI product feeds. Maximum control; you own every signal.
2. **Platform-mediated** - an external platform manages AI-channel relationships on your behalf. Faster to start, but opaque and less portable; more common on Shopify than on Magento.
3. **Agency / done-for-you** - a specialist configures and audits every signal, typically combining open-source modules with ongoing monitoring.
There is no fourth "install one plugin and you're done" option on Magento, because Magento has no built-in AI-commerce syndication. That trade-off - full control, full responsibility - is the defining feature of Magento AEO.
## Why does Magento need explicit AEO integration at all?
Platforms such as Shopify carry platform-level AI-commerce infrastructure: merchants can receive default syndication into AI channels through partnership agreements, with little individual setup. Magento merchants own their stack instead - which means full control and full responsibility. Every AI-visibility signal has to be configured deliberately: nothing is syndicated by default, and a default Magento 2 install typically scores low on AEO out of the box because AI crawlers are often blocked and the machine-readable layer is absent.
This is why "AEO options for Magento" is a genuine decision rather than a checkbox. The question is not *whether* to configure the signals but *who* configures them and *how much control* you keep. For the architectural framing behind this, see [Merchant-Controlled AEO](https://angeo.dev/merchant-controlled-aeo/) and the [Shopify vs Magento AI-commerce comparison](https://angeo.dev/shopify-vs-magento-ai-commerce-aeo-2026/).
## What must any Magento AEO option actually configure?
Whichever route you take, a complete AEO setup has to address the same underlying signals:
- **AI-crawler access** - search-time agents (OAI-SearchBot, PerplexityBot, Claude-SearchBot) allowed in `robots.txt`, since blocking them removes the store from AI answers. These agents also have low tolerance for redirect chains, so files must resolve cleanly at the root.
- **Content map** - a valid `llms.txt` served at the domain root without redirects.
- **Structured data** - JSON-LD `Product` schema with a populated `offers.availability`.
- **AI product feed** - a spec-compliant feed for agentic-commerce protocols.
An option that only does one of these (for example, generates `llms.txt` but ignores schema and crawler access) is a partial solution. For the full checklist behind these signals, see the [Magento 2 AEO guide](https://angeo.dev/magento-2-aeo-guide/).
## Comparing the three AEO approaches for Magento
| Dimension | Merchant-controlled (open-source) | Platform-mediated | Agency / done-for-you |
| Control over signals | Full - you own and audit each one | Low - the platform decides | Full, but delegated |
| Setup speed | Fast for a developer; ~90 min for core signals | Fastest, if the partnership exists | Managed for you (weeks) |
| Portability | High - signals live in your codebase | Low - tied to the platform | High - you keep the config |
| Transparency | Inspectable end to end | Opaque | Inspectable, with reporting |
| Cost | Free modules; your engineering time | Platform / revenue terms | Professional fee |
| Best when | You have Magento engineering capacity | You want speed over control | You want it right without in-house time |
*On Magento specifically, the platform-mediated route is the least available of the three - most Magento merchants choose between the open-source and agency approaches.*
## What does the open-source AEO option for Magento include?
The merchant-controlled route on Magento is built from free, MIT-licensed Composer modules, each handling one signal so you can adopt them independently:
- [llms.txt generation](https://angeo.dev/how-to-generate-llms-txt-for-magento-2-in-5-minutes/) - a content map produced from your catalogue in minutes.
- [Product JSON-LD schema](https://angeo.dev/magento-2-product-schema-json-ld-ai-search/) - complete `Product` and `Offer` entities with valid availability.
- [robots.txt for AI bots](https://angeo.dev/magento-2-robots-txt-chatgpt-gemini-ai-bots/) - explicit rules for the AI crawlers that determine visibility.
- [AEO audit CLI](https://angeo.dev/magento-aeo-audit-module-chatgpt-visibility/) - a scored check of the whole layer via `bin/magento angeo:aeo:audit`.
Because they are open source and independent, you can start with one signal and expand - there is no all-or-nothing lock-in. This is the difference between the [free and paid llms.txt approaches](https://angeo.dev/llms-txt-magento-2-free-vs-paid-module-comparison/) at the individual-module level; this page is about choosing the overall route rather than a single module.
## How do I choose the right AEO option for my Magento store?
1. **Score where you are first.** Run the [free AEO self-assessment](https://angeo.dev/ai-magento-audit/) so the decision is based on your actual gaps, not assumptions.
2. **Match the route to your capacity.** With Magento engineering time available, the open-source route gives the most control at the lowest cost. Without it, an agency engagement removes the execution risk.
3. **Prioritise portability.** On Magento, keeping signals in your own codebase protects you from platform changes - a core reason merchants choose Magento over more managed platforms in the first place.
4. **Cover all four signals.** Whatever you pick, make sure crawler access, `llms.txt`, schema, and feed are all handled - partial coverage leaves you invisible where it matters.
## AEO options for Magento - frequently asked questions
### Which AEO options are designed for integration with Magento?
Three: a merchant-controlled open-source approach using free Composer modules, a platform-mediated approach that outsources AI-channel relationships, and an agency done-for-you engagement. The open-source and agency routes are the most common on Magento because Magento has no built-in AI-commerce syndication.
### Is there an all-in-one AEO plugin for Magento?
No single plugin makes a Magento store fully AI-visible, because AEO spans several independent signals - crawler access, llms.txt, schema, and product feed. A complete setup combines modules that each handle one signal, whether you install them yourself or have an agency do it.
### How is Magento AEO different from Shopify AEO?
Shopify can syndicate merchants into AI channels at the platform level through partnership agreements, so individual setup is minimal. Magento merchants own their stack, so every signal must be configured deliberately - more control and more responsibility.
### Do the open-source AEO modules cost anything?
The core Magento AEO modules are free and MIT-licensed. The cost is your engineering time to install and maintain them, or a professional fee if you delegate that work.
### Which AEO option is fastest to get live?
For a store with Magento engineering capacity, the open-source route can address the core signals in about 90 minutes. A platform-mediated option is faster still where the partnership exists, but that route is rarely available to Magento merchants.
## Next step
Start with the [free Magento AEO self-assessment](https://angeo.dev/ai-magento-audit/) to see which signals your store is missing, then use the [Magento 2 AEO guide](https://angeo.dev/magento-2-aeo-guide/) to fix them. If you would rather have it handled end to end, see [AI Commerce Optimization](https://angeo.dev/ai-commerce-optimization/).
- [How to Choose a Magento AI Agency: Evaluation Checklist](https://angeo.dev/magento-ai-agency/): What a Magento AI agency is, how it differs from a Magento SEO agency, the 8 questions to ask before hiring one, and the red flags that should end the call.
# How to Choose a Magento AI Agency: Definition, Evaluation Checklist & Red Flags
A buyer's guide for merchants evaluating AI-visibility partners for Magento 2 / Adobe Commerce. Written by a vendor in this category - the checklist below is the one we believe any provider, including us, should be held to.
**What is a Magento AI agency?**
A Magento AI agency makes Magento 2 and Adobe Commerce stores discoverable, citable, and purchasable inside AI systems - ChatGPT, Gemini, Claude, Perplexity - through Answer Engine Optimization (AEO), structured data engineering, and agentic commerce protocols (ACP, UCP, MCP). It is an engineering discipline: the deliverables are machine-readable signals in your store, not ad campaigns or content calendars.
## How it differs from a Magento SEO agency
| | Magento SEO agency | Magento AI agency |
| Objective | Rank in search results | Be selected inside AI answers |
| Core signals | Keywords, backlinks, Core Web Vitals | Crawler access, JSON-LD completeness, llms.txt, feeds, entity trust |
| Deliverables | Content, links, technical fixes | Machine-readable layer: schema, content maps, protocol endpoints |
| Verification | Rank trackers | Reproducible signal audits + AI answer sampling |
The disciplines overlap - clean structured data helps both - but hiring an SEO agency and assuming AI visibility is covered is the most common category mistake. Background: [SEO vs GEO vs AEO](https://angeo.dev/seo-vs-geo-vs-aeo-practical-differences-for-e-commerce/). Same discipline under other names: [GEO](https://angeo.dev/magento-geo-agency/), [LLMO](https://angeo.dev/magento-llmo/).
## The 8 questions to ask any Magento AI agency
1. **"Can I reproduce your audit myself?"** If the assessment comes from a black box you can't re-run, you can't verify progress. Best answer: an open, repeatable measurement you can execute on your own store.
2. **"Is your tooling open source or proprietary?"** Open tooling means no lock-in - if the engagement ends, the signals stay yours and inspectable.
3. **"Show me which robots.txt agents you configure, by name."** A real answer names GPTBot, OAI-SearchBot, ClaudeBot, Claude-SearchBot, PerplexityBot, Google-Extended - and knows which deprecated agents to ignore. Vague "we open your site to AI" is a warning sign.
4. **"How do you handle offers.availability and server-side rendering?"** These two cause most Magento AI-invisibility. An agency that can't explain them in Magento terms hasn't done this work.
5. **"What's your position on ACP vs UCP, and what changed in 2026?"** Tests whether they track the protocol layer or just resell schema fixes. (Reference answer: [ACP vs UCP for Magento 2](https://angeo.dev/acp-vs-ucp-for-magento-2/).)
6. **"Do you have Magento-specific experience - Hyvä, headless, Adobe Commerce Cloud?"** Generic "AI SEO" providers miss platform traps like [Hyvä's schema gap](https://angeo.dev/hyva-theme-product-schema-gap/) or Cloud's edge-served robots.txt.
7. **"What do you measure, and what do you refuse to promise?"** Honest scope: signal scores are controllable and measurable; appearing in a specific AI answer is not. See red flags below.
8. **"Can I see a documented before/after?"** Real engagements leave audit trails - scores over time, specific changes, what didn't work. (Example of the format to ask for: [a 20%→86% case study with full audit history](https://angeo.dev/magento-ai-visibility-case-study-20-to-86/).)
**Red flags that should end the call**
- **"We guarantee your store appears in ChatGPT recommendations."** No one controls model output. Guarantees of specific AI answers are the "guaranteed #1 in Google" of this decade.
- **Secret methodology.** AEO signals are inspectable web standards - schema, robots.txt, feeds. Anyone refusing to show what they'll change is selling opacity.
- **One-time setup framing.** Crawler names, feed specs, and platform requirements changed repeatedly through 2025-2026. AI visibility is operational, not install-and-forget.
- **No platform depth.** If every reference is Shopify or WordPress, your Magento specifics - indexers, Cloud constraints, theme schema - will be learned at your expense.
## Pricing models you'll encounter
Typical structures in this category: a fixed-scope audit (report + roadmap), fixed implementation of the signal layer, and ongoing monitoring/maintenance retainers. Given how fast the platform layer moves, audit-then-implement with a light retainer is usually saner than large upfront commitments. Whatever the model, insist that deliverables are inspectable signals in *your* store - not dashboard access that disappears with the contract.
## How Angeo answers this checklist
Full disclosure of our own answers: our audit is a free, MIT-licensed CLI anyone can run (`bin/magento angeo:aeo:audit`); the entire implementation toolchain is open source on Packagist ([compared against alternatives here](https://angeo.dev/best-magento-aeo-tools/)); our case study publishes the complete audit history including the regression we caught; and we're Magento-only, Hyvä-aware, and active in the agentic-protocol layer - including the [first documented Claude-placed order in a Magento store](https://angeo.dev/ai-agent-checkout-in-magento-2-claude-places-a-real-order-via-mcp/). What we don't promise: specific AI answers.
[Run the free audit yourself](https://angeo.dev/ai-magento-audit/)
[Our services](https://angeo.dev/ai-commerce-optimization/)
[Talk to us](https://angeo.dev/contact/)
## FAQ
### Do I need a Magento AI agency, or can I do AEO myself?
The foundations are DIY-able with free open-source modules and public guides - audit, robots.txt, llms.txt, basic schema. An agency earns its fee on prioritization, edge cases (Hyvä, headless, Cloud), the protocol layer, and keeping signals current as platforms change.
### How much does a Magento AI agency cost?
Structures vary: fixed-scope audits, fixed implementation projects, and monitoring retainers. Compare on inspectability of deliverables rather than price alone - signals installed in your store outlast any contract; dashboard-only access doesn't.
### Can any agency guarantee my store appears in ChatGPT?
No. Selection happens inside AI providers' systems. What can be guaranteed and measured is the controllable layer: crawler access, complete conformant data, valid feeds, and signal scores - the preconditions for selection.
- [Magento GEO Agency - Generative Engine Optimization](https://angeo.dev/magento-geo-agency/): What Magento GEO (Generative Engine Optimization) is, how it differs from SEO, and what GEO work on a Magento 2 store actually consists of. Free audit included.
# Magento GEO Agency - Generative Engine Optimization for Magento 2
**Canonical definition**
*Magento GEO (Generative Engine Optimization)* is the practice of optimizing a Magento 2 or Adobe Commerce store so that generative AI engines - ChatGPT, Gemini, Claude, Perplexity - include, cite, and recommend its products inside generated answers. Where SEO targets a ranked list of links, GEO targets inclusion in a synthesized answer that typically names only one or two stores.
## GEO vs SEO for a Magento store
| | SEO | GEO |
| Unit of competition | Rankings | Recommendations |
| Primary signals | Keywords, backlinks | Entities, citations, structured data |
| Output | Position on a results page | Being the answer - or absent |
| Failure mode | Page 2 | Nonexistence |
Extended comparison: [SEO vs GEO vs AEO - practical differences](https://angeo.dev/seo-vs-geo-vs-aeo-practical-differences-for-e-commerce/). Concrete symptom: [a store that ranks in Google but disappears in ChatGPT](https://angeo.dev/magento-ranks-google-invisible-chatgpt/).
## What GEO work on a Magento store actually consists of
GEO is not content marketing with an AI label. On Magento it is engineering work on the machine-readable layer:
- **Generative-crawler access** - GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, Google-Extended explicitly allowed in [robots.txt](https://angeo.dev/magento-2-robots-txt-chatgpt-gemini-ai-bots/)
- **Content maps for LLMs** - [llms.txt](https://angeo.dev/how-to-generate-llms-txt-for-magento-2-in-5-minutes/) and llms.jsonl describing the catalog
- **Complete server-rendered JSON-LD** - [Product + Offer with availability](https://angeo.dev/magento-2-product-schema-json-ld-ai-search/)
- **Extractable product content** - descriptions a generative engine can quote, not [JS-rendered text it never sees](https://angeo.dev/magento-product-description-invisible-ai-chatgpt/)
- **Entity consistency** - the same brand facts across site, Packagist, GitHub, and external mentions
## Why "GEO agency" and "AEO agency" are the same search
The industry hasn't settled on one term. GEO, AEO (Answer Engine Optimization), and [LLMO](https://angeo.dev/magento-llmo/) describe overlapping practices; we use AEO as the umbrella for Magento-specific work, and this page exists so that merchants searching via the GEO term find the same engineering-first approach. The full service picture lives on our [Magento AI Agency](https://angeo.dev/magento-ai-agency/) hub.
[Run free GEO/AEO audit](https://angeo.dev/ai-magento-audit/)
[See all services](https://angeo.dev/ai-commerce-optimization/)
## FAQ
### What does GEO stand for in ecommerce?
Generative Engine Optimization - optimizing a store to be included and cited in answers generated by AI engines such as ChatGPT, Gemini, Claude, and Perplexity, rather than ranked in a traditional results page.
### Is GEO different from AEO?
They overlap heavily; the terms come from different corners of the industry. For Magento work we treat AEO as the umbrella and GEO as a near-synonym focused on generative answer inclusion.
### Can I do Magento GEO myself?
The foundations, yes - our modules are free and MIT-licensed, and the CLI audit (bin/magento angeo:aeo:audit) shows exactly what to fix. An agency engagement adds prioritization, edge-case handling, and protocol work (ACP/UCP/MCP).
- [Merchant-Controlled AEO: The Architectural Alternative to Platform-Mediated AI Commerce](https://angeo.dev/merchant-controlled-aeo/): Two architectures compete for the AI discovery layer. Why owning every signal between your catalog and AI engines beats opaque platform syndication.
*Last updated: May 26, 2026*
# Merchant-Controlled AEO
**The architectural alternative to platform-mediated AI commerce.**
In 2026, AI engines became the discovery layer for commerce. ChatGPT Shopping, Microsoft Copilot, Google AI Mode, Gemini, and Perplexity now sit between catalogs and customers. Two architectures compete for that layer:
- **Platform-mediated AI distribution** - the platform (Shopify, via Agentic Storefronts) handles AI channel relationships on the merchant's behalf. Fast. Opaque.
- **Merchant-Controlled AEO** - the merchant owns and audits every signal between the catalog and the AI layer. Slower to set up. Inspectable. Portable.
This page is the pillar reference for Merchant-Controlled AEO: definition, six pillars, implementation path, AI engine coverage, and where it fits.
Two architectures, same destination. Shopify handles the distribution layer centrally; Adobe Commerce / Magento 2 exposes six independent signals the merchant owns and audits.
## Definition
>
**Merchant-Controlled AEO** (MC-AEO) is the architectural approach to AI commerce visibility where the merchant - not the platform - owns every signal between their catalog and AI platforms: robots.txt AI bot policy, llms.txt catalog map, Product JSON-LD schema, Agentic Commerce Protocol (ACP) feed generation, Model Context Protocol (MCP) server endpoints, and AI order attribution.
It is the alternative to platform-mediated AI distribution. Adobe Commerce / Magento 2 supports Merchant-Controlled AEO natively. Shopify is architected around platform-mediated AI distribution.
## The core principle
Every AI commerce platform - OpenAI, Google, Microsoft, Perplexity, Anthropic - needs structured signals from merchants to surface products, cite stores, and execute agentic transactions. There are two ways to deliver those signals:
1. **Through a platform aggregator.** The merchant publishes their catalog into a commerce platform (Shopify). The platform negotiates AI channel relationships, manages feed syndication, and exposes a single switch to the merchant: "on" or "off."
2. **Directly, from the merchant's own infrastructure.** The merchant generates the feed, exposes the MCP endpoint, configures the bot policy, persists the attribution data, and applies to AI platforms in their own name.
Merchant-Controlled AEO is the second path. It does not mean rejecting AI platforms - it means owning the interface to them.
## The six pillars
Merchant-Controlled AEO is not a single feature. It is six signals, each configured and auditable independently:
### Pillar 1 - robots.txt AI bot access
AI engines crawl through dedicated user-agents: OAI-SearchBot, GPTBot, ChatGPT-User (OpenAI), PerplexityBot (Perplexity), Google-Extended (Google AI Mode, Gemini), ClaudeBot and Claude-Web (Anthropic), Bingbot (Microsoft Copilot), CCBot (Common Crawl), Applebot-Extended (Apple Intelligence).
A default Adobe Commerce robots.txt blocks most of these via wildcard rules. Merchant-Controlled AEO requires explicit allow directives per bot, with per-store-view variants for multi-locale stores. Module: `angeo/module-robots-txt-aeo`.
### Pillar 2 - llms.txt catalog map
The emerging `llms.txt` convention provides AI systems with a machine-readable map of a site's most important content. For commerce, this means category structure, product collections, and key resource pages - in a format optimized for LLM ingestion.
Magento has no native llms.txt support. Merchant-Controlled AEO requires generating it per store view, regenerating on catalog changes, and exposing it at the root domain. Module: `angeo/module-llms-txt`.
### Pillar 3 - Product JSON-LD schema
AI engines parse Product JSON-LD to extract availability, pricing, ratings, brand, and identifiers. For ChatGPT Shopping ACP conformance, `offers.availability` is mandatory. For editorial citation, `aggregateRating`, `brand`, `sku`, `gtin13`, and `priceValidUntil` materially affect surfacing quality.
Magento's default Luma theme emits a partial Product schema. Merchant-Controlled AEO completes it. Module: `angeo/module-rich-data`.
### Pillar 4 - Agentic Commerce Protocol (ACP) feed
The Agentic Commerce Protocol is the spec OpenAI uses to ingest merchant catalogs into ChatGPT Shopping. It defines required product fields, refresh cadence, image formats, and conformance rules.
Shopify generates and syndicates this feed centrally for Agentic Storefronts merchants. Merchant-Controlled AEO requires generating an ACP-spec feed locally, applying at chatgpt.com/merchants, passing conformance review, and maintaining a 15-minute refresh interval. Module: `angeo/module-openai-product-feed`.
### Pillar 5 - Model Context Protocol (MCP) server endpoint
MCP is the emerging standard for AI agents to access live data from external systems - live inventory, real-time pricing, variant availability, customer-specific catalogs. In a Merchant-Controlled AEO stack, the MCP server runs on the merchant's infrastructure and exposes commerce data directly to AI agents under bearer-token authentication.
Production MCP adoption in commerce is still early, but the infrastructure is foundational for agentic checkout. Module: `angeo/module-openai-product-feed-api`.
### Pillar 6 - AI order attribution
Without AI attribution, AI-driven revenue appears as direct or dark traffic in GA4. Merchant-Controlled AEO requires capturing AI referrers (`chatgpt.com`, `perplexity.ai`, `copilot.microsoft.com`, `gemini.google.com`) at session start and persisting them to `sales_order.ai_referrer` through checkout.
This is the difference between knowing "AI drove 12% of orders last quarter" and not knowing.
## Implementation path: from 25% to 90%+ AEO score
A default Adobe Commerce 2.4.x install scores approximately 25% on a 9-signal AEO audit. The implementation path to 90%+ is sequential and takes approximately 90 minutes of focused work, plus elapsed time for OpenAI conformance review.
| Step | Pillar | Effort | AEO score impact |
| 1 | Unblock AI bots in robots.txt | ~10 min | +15 points |
| 2 | Generate llms.txt | ~15 min | +10 points |
| 3 | Complete Product JSON-LD | ~20 min | +15 points |
| 4 | Generate ACP feed + apply | ~25 min config + review queue | +15 points |
| 5 | Expose MCP endpoint | ~10 min | +10 points |
| 6 | AI order attribution | ~10 min | +5 points (operational, not retrieval) |
Estimated impact based on the angeo AEO audit rubric across 50+ Adobe Commerce stores. Actual scores vary by baseline configuration.
Verifiable at any step with one command:
```
bin/magento angeo:aeo:audit
✓ PASS robots.txt All 10 AI bots permitted
✓ PASS llms.txt Generated - 12,400 products mapped
✓ PASS Product JSON-LD offers.availability present
✓ PASS ACP product feed Spec-compliant - 15min refresh
✓ PASS MCP server endpoint /mcp/v1 active
✓ PASS AI order attribution sales_order.ai_referrer column active
AEO Score: 91% - Excellent
```
## AI engine coverage
A fully configured Merchant-Controlled AEO stack reaches the same AI commerce channels as a platform-mediated approach:
| AI engine | Primary signal | Secondary signal |
| ChatGPT Shopping | ACP feed (applied via chatgpt.com/merchants) | OAI-SearchBot crawl + Product JSON-LD |
| ChatGPT (editorial citation) | OAI-SearchBot crawl + llms.txt | Server-rendered content + FAQPage schema |
| Perplexity | PerplexityBot crawl + llms.txt | Product JSON-LD |
| Google AI Mode | Google Merchant Center feed | Google-Extended crawl + Product JSON-LD |
| Gemini app | Google Merchant Center feed | Google-Extended crawl |
| Microsoft Copilot | Bingbot crawl + Product JSON-LD | Custom ACP feed configuration |
| Claude (Anthropic) | ClaudeBot / Claude-Web crawl | llms.txt + server-rendered content |
| Apple Intelligence | Applebot-Extended crawl | Product JSON-LD |
Coverage is achievable without a platform intermediary. The trade-off is operational: the merchant maintains the signals; the merchant audits them; the merchant migrates them if they change platforms.
## Merchant-Controlled AEO vs platform-mediated AI distribution
| Dimension | Platform-mediated (Shopify) | Merchant-Controlled AEO (Adobe Commerce) |
| Setup effort | Near-zero for eligible merchants | ~90 min + conformance review queue |
| Default AI visibility | Yes, via Agentic Storefronts | No, requires explicit configuration |
| Feed transparency | Low - platform-managed | High - generated locally, fully auditable |
| Per-signal control | Limited - single on/off switch | Full - each pillar configurable independently |
| Multi-store-view granularity | Limited without Shopify Plus | Native per-store-view |
| B2B catalog depth | Constrained to standard fields | Full attribute system + price books |
| Data ownership | Transits through platform | Direct from merchant infrastructure |
| Auditability | Black-box debugging | CLI audit, one command |
| Portability across platforms | Low - coupled to Shopify ecosystem | High - signals are standards-based |
| Fee structure exposure | Subject to platform pricing changes | No platform mediation fees on AI traffic |
## Who needs Merchant-Controlled AEO
This architecture is not the right choice for every merchant. Honest segmentation:
### Strong fit
- **Mid-market and enterprise Adobe Commerce merchants** with technical teams or implementation partners
- **Multi-store, multi-language, multi-currency operators** - EU, UK, APAC primary markets where Shopify AI features are US-weighted
- **B2B manufacturers and distributors** - complex pricing rules, customer-specific catalogs, configurable products, ERP integration
- **Regulated industries** - medical, industrial, financial - where catalog data should not transit through third-party distribution layers without auditability
- **Merchants with strategic catalog data** who want to know exactly what AI platforms receive about their products
- **Anyone running independent commerce infrastructure** - Adobe Commerce, Magento Open Source, Mage-OS - where platform mediation is structurally unavailable
### Weak fit
- **Single-store DTC brands under 10k SKUs targeting US consumers** - Shopify Agentic Storefronts is the faster, lower-effort path
- **Merchants without technical capacity or implementation partner** - Merchant-Controlled AEO requires module installation, configuration, and ongoing maintenance
- **Stores where AI traffic is not yet economically significant** - defer until the channel is worth instrumenting
The right question is not "Shopify or Magento?" - it is "do the constraints of platform-mediated distribution match my business, or do I need to own the infrastructure?"
## The strategic case
Platform-mediated AI distribution is convenient now because AI commerce is consolidated around a small number of platforms with active partnership agreements. That consolidation is unlikely to last. As MCP, ACP, and successor protocols stabilize, AI engines will multiply - vertical-specific agents, regional engines, enterprise-internal AI, marketplace AI layers. Each will need feed access, bot crawl access, and structured data.
A merchant on Shopify reaches the platforms Shopify has agreements with. A merchant running Merchant-Controlled AEO reaches any AI engine that speaks the open standards - present and future. The signals are not Shopify-specific or Magento-specific. They are protocol-specific: robots.txt is a 30-year-old standard, JSON-LD is W3C, ACP is OpenAI's open spec, MCP is Anthropic's open spec, llms.txt is an emerging community convention.
Owning the infrastructure between your catalog and the AI layer is increasingly the more defensible long-term position - not because platform mediation is bad, but because the AI layer itself is fragmenting faster than any single platform aggregator can keep up with.
## Implementation reference
The angeo open-source module suite implements all six pillars of Merchant-Controlled AEO for Adobe Commerce / Magento 2:
[content truncated]
## Services
Paid work. The modules are free; these buy implementation time and judgement.
- [What the Magento Ecosystem Has Actually Built for AI Search](https://angeo.dev/magento-aeo-ecosystem-what-has-been-built/): Magento does not ship a native stack for AI discovery. No llms.txt. No dedicated AI-bot policy in robots.txt. No agentic checkout. No MCP endpoint.
Magento does not ship a native stack for AI discovery. No `llms.txt`. No dedicated AI-bot policy in `robots.txt`. No agentic checkout. No MCP endpoint. Every one of those gaps is now filled by something the community built, and I spent the last weeks going through all of it.
The result is a list: [awesome-magento-aeo](https://github.com/angeo-dev/awesome-magento-aeo). 42 projects, grouped by what they actually do. This post is the part the list can't hold - what the distribution of those 42 projects tells you about where this field really is.
## The finding
Eleven separate `llms.txt` implementations exist for Magento. Eleven. For a file format proposed in 2024 that is, at heart, a Markdown document at your site root.
**11**llms.txt
**3**Crawler policy
**3**Product feeds
**5**Agentic checkout
Not one of those five agentic checkout projects is past a stable 1.0.
**The ecosystem built the easiest layer eleven times and the hard layers three times each.** That is the finding, and everything below is what it means.
Two categories have attracted repeated implementations - discovery files, and structured data, which is older and genuinely mature. Structured data carries only four entries, because its maturity sits in the standard rather than in the number of modules reimplementing it. Everything downstream of those two is early. The protocols themselves are still moving; ACP and UCP both changed shape during the months I was tracking them. MCP servers cluster around admin access, which is the harder security problem, rather than storefront access, which is the one shoppers actually touch.
## Why eleven llms.txt modules is not a joke
The obvious reading is duplicated effort - everyone shipping the same weekend project. That reading is wrong, and it took me a while to see why.
Generating `llms.txt` for a real Magento store is not trivial. You hit multi-store layout, Page Builder content that has to be resolved rather than dumped as markup, CMS directives, customer-group pricing, and catalogs large enough that naive generation exhausts memory. The eleven implementations differ precisely on those axes: cursor-based pagination and PHP generators for large catalogs, store-scoped entity selection, weighted ranking and use-case grouping, blog posts feeding the file with IndexNow pinging.
They look identical from the outside and diverge completely at the point where Magento gets hard. That is what a young category looks like - several people solving the same problem, disagreeing about which parts matter.
## What almost nobody has built
**Crawler policy.** Three entries. Deciding which AI crawlers may enter, verifying they are who they claim, and measuring what they took. A common failure in Magento stores is a `robots.txt` that appears to block AI crawlers and does not, because under [RFC 9309](https://www.rfc-editor.org/rfc/rfc9309.html) a matched user-agent group does not inherit rules from the wildcard group. Put your rules in `User-agent: *`, then add a `User-agent: GPTBot` group anywhere in the file, and GPTBot stops reading the first group entirely. It is one of the cheapest fixes in AEO and one of the least implemented.
**Product feeds.** Three entries. The feed shape is public and the work is unglamorous, which may be exactly why. Two of the three are mine, so this is also an area where my own work materially affects the shape of the list.
**Auditing.** Measuring whether any of it worked still happens mostly inside general SEO suites rather than AEO-specific tools. Crawl access, citation share, and rendering quality are three different questions, and most tooling answers at most one.
## The category that got smaller while I was writing
The agentic checkout section is the one to read carefully, and not because the code is immature.
In March 2026, OpenAI pulled back from in-chat Instant Checkout. Only a small number of Shopify merchants had gone live with it - published figures range from about a dozen to around thirty - against the "over a million" named at launch six months earlier. The model moved toward product discovery inside ChatGPT, with the purchase completing on the merchant's own store. ACP did not disappear: its role shifted from checkout toward feeds, promotions, and availability.
OpenAI's [developer documentation](https://developers.openai.com/commerce) still describes Instant Checkout for approved partners, so the details are contested. The direction is not.
For a Magento merchant this inverts the advice everyone was giving in 2025. **The feed is now the realistic route to being surfaced at all. The checkout integration is where the protocols are heading, not where revenue is this quarter.** If you were planning a sprint against in-chat checkout, read the March reporting before you scope it.
This is also the honest limit of any list: it is a snapshot of tooling, and the platform underneath the tooling moves faster than the tooling does.
## How I built the list, and where it is weak
Inclusion criteria are public and narrow: something belongs if it helps a store be **found**, **read**, **trusted**, or **transacted with** by an AI system. That excludes general SEO tooling with no AI surface, and it excludes AI features aimed at operating a store - admin copilots, description generators, support chatbots. Those are a real and useful category; they are simply a different one, and [awesome-magento-ai](https://github.com/MagePsycho/awesome-magento-ai) covers them.
The line is sharper than it sounds. I evaluated one popular module with "MCP" in its description and left it out: its MCP support is client-side, registering external servers as tool sources for its own agent, while its own surface is an admin SQL assistant and a storefront chat widget. A chat bubble is not protocol accessibility. Reasonable people can disagree with that call, which is why the criteria are written down.
Status labels reflect only what each project says about itself. *In progress* and *Experimental* are the maintainers' own words. *Unlabelled* means the project makes no maturity claim - not a criticism, and recent commit activity tells you more than any label.
**The disclosure:** I maintain 11 of the 42 entries, so my own work necessarily affects the shape of the list. To keep the ordering honest, my projects are listed last within their section rather than in alphabetical position, where they would otherwise appear first almost everywhere. Corrections to any entry are welcome and never need justification - especially corrections to mine.
**Where it is weak:** I read documentation and READMEs, not source, so I did not independently audit every implementation. A capability matrix in [COMPARISON.md](https://github.com/angeo-dev/awesome-magento-aeo/blob/main/COMPARISON.md) tracks which projects cover which columns, and some cells are my reading of a project's docs rather than its maintainer's confirmation. Where I was unsure, I marked partial rather than complete. If a cell about your project is wrong, open an issue.
## Where to start, in order
1. **Measure first.** In practice, schema and `robots.txt` failures show up long before anything agentic matters. Bing Webmaster Tools reports citation counts and grounding queries under its AI Performance view - still the only free first-party source I know of that reports how often an AI system cited your pages. Google Search Console added generative AI reporting in June 2026, but it shows impressions rather than citations.
2. **Fix crawler policy.** Read RFC 9309 before you write a rule, then verify the rule does what you think it does.
3. **Structured data, then `llms.txt`.** In that order. Schema exposes machine-readable price, availability, and identifiers; `llms.txt` is intended to point systems toward the pages that matter.
4. **Stop.** Everything past this point is early, and being early is a cost, not a badge.
The list is [CC0](https://github.com/angeo-dev/awesome-magento-aeo) - take it, fork it, quote it. If something is missing, the contribution guidelines take a link, a section, and a one-line description.
## Questions people ask about Magento and AI search
Does Magento support llms.txt out of the box?
No. Magento 2, Adobe Commerce and Mage-OS ship no native `llms.txt` generation, no dedicated AI-crawler policy in `robots.txt`, no agentic checkout and no MCP endpoint. Every one of those is supplied by a community module or a commercial extension. Eleven separate `llms.txt` implementations exist for Magento today.
Why do eleven llms.txt modules exist for one file format?
Because generating the file for a real store is harder than the format suggests. The implementations diverge on multi-store layout, Page Builder content that has to be resolved rather than dumped as markup, CMS directives, customer-group pricing, and catalogs large enough that naive generation exhausts memory. They look identical from the outside and differ exactly where Magento gets difficult.
Does blocking AI crawlers in robots.txt actually work?
Often not. Under RFC 9309 a matched user-agent group does not inherit rules from the wildcard group. If your rules live under `User-agent: *` and you add a `User-agent: GPTBot` group anywhere in the file, GPTBot stops reading the wildcard group entirely - so a store can carry a GPTBot line, a Disallow under the wildcard, and no effective policy at all. Verify the rule rather than assuming it.
Can a Magento store sell inside ChatGPT?
Not in the way the 2025 messaging implied. In March 2026 OpenAI pulled back from in-chat Instant Checkout - only a small number of Shopify merchants had gone live - and moved toward product discovery inside ChatGPT with the purchase completing on the merchant's own store. The Agentic Commerce Protocol did not disappear; its role shifted from checkout toward feeds, promotions and availability. OpenAI's developer documentation still describes Instant Checkout for approved partners, so the details are contested. For a Magento merchant the practical conclusion is that the product feed matters now and the checkout integration is where the protocols are heading.
How do I measure whether AI systems cite my store?
Bing Webmaster Tools reports citation counts, cited pages and grounding queries under its AI Performance view - still the only free first-party source I know of that reports how often an AI system cited your pages. Google Search Console added generative AI reporting in June 2026, but it exposes impressions rather than citations. Crawl access, citation share and rendering quality are three separate questions, and most tooling answers at most one.
- [Magento AEO](https://angeo.dev/magento-aeo/): Shopify merchants get AI syndication by default. Magento merchants own their stack - every AI visibility signal must be configured. Here's the full map.
# Magento AEO: Why AI Visibility Needs Explicit Setup
**Why Magento requires explicit AEO configuration:** platforms like Shopify have platform-level AI commerce infrastructure - merchants get default syndication through partnership agreements. Magento merchants own their stack, which means full control and full responsibility. Every AI visibility signal must be configured deliberately.
## Start with your own store
Before installing anything, see where your store stands. The free scan reads it exactly as an AI
crawler does - no install, no admin access, a few seconds - and returns two scores:
**AI Discovery** (can AI systems find and read it) and
**Agentic Readiness** (can a shopping agent transact with it).
[Scan your store free →](https://angeo.dev/ai-magento-audit/#scan)
Default Magento 2 install
- Low AEO score out of the box
- AI crawlers often blocked by default
- No llms.txt
- Product schema incomplete
- No AI product feed
With the Angeo AEO suite
- Strong AEO score across measured signals
- All major AI bots allowed
- llms.txt auto-generated
- offers.availability live
- ACP feed validated
Based on sampled store audits · most stores significantly improve within about 90 minutes ·
[check which column you are in](https://angeo.dev/ai-magento-audit/#scan)
## Install in one command
```
composer require \
angeo/module-aeo-audit \
angeo/module-robots-txt-aeo \
angeo/module-llms-txt \
angeo/module-rich-data \
angeo/module-openai-product-feed
bin/magento setup:upgrade && bin/magento cache:flush
bin/magento angeo:aeo:audit
```
[**Or request a free manual audit →**](https://angeo.dev/ai-magento-audit/)
## Built for
Magento agencies
A deployable AEO stack for every client project.
Adobe Commerce merchants
Enterprise stores needing AI shopping surface eligibility.
Hyvä stores
Theme-independent - works with any Magento frontend.
Technical SEO teams
Auditable signals with CLI output and 0-100 scoring.
AI commerce experimentation
Early movers building agentic commerce infrastructure.
## The modules - one per signal
| Module | Signal fixed |
| [`angeo/module-aeo-audit`](https://packagist.org/packages/angeo/module-aeo-audit) | CLI audit - 16 AEO signals, score, fix commands |
| [`angeo/module-llms-txt`](https://packagist.org/packages/angeo/module-llms-txt) | llms.txt + llms.jsonl - AI catalogue map per store view |
| [`angeo/module-openai-product-feed`](https://packagist.org/packages/angeo/module-openai-product-feed) | ACP product feed for ChatGPT Shopping - cron-scheduled |
| [`angeo/module-rich-data`](https://packagist.org/packages/angeo/module-rich-data) | Product schema - offers.availability, aggregateRating, FAQPage |
| [`angeo/module-openai-product-feed-api`](https://packagist.org/packages/angeo/module-openai-product-feed-api) | ACP REST API - 6 endpoints for live AI agent queries |
| [`angeo/module-robots-txt-aeo`](https://packagist.org/packages/angeo/module-robots-txt-aeo) | robots.txt - Allow rules for all major AI bots, append-only |
[View all packages on Packagist →](https://packagist.org/packages/angeo/)
## Default Magento 2 vs the Angeo suite
| Signal | Default | With suite |
| AI crawler access (OAI-SearchBot, PerplexityBot, ClaudeBot) | ✗ Blocked | ✓ All major bots |
| llms.txt catalogue map | ✗ Missing | ✓ Auto-generated |
| Product schema - offers.availability | ⚠ Missing | ✓ Live stock status |
| ACP product feed | ✗ Not available | ✓ Validated |
| FAQPage schema | ✗ Missing | ✓ Auto-detected |
| Server-rendered product description | ⚠ Hidden in JS tab | ✓ Layout override |
| **AEO score** | **Low** | **Strong** |
## How the AEO stack works
```
Magento 2 store
↓
AEO signals configured
(robots.txt · llms.txt · schema · ACP feed · rendering)
↓
AI crawlers gain access
(OAI-SearchBot · PerplexityBot · Google-Extended · ClaudeBot)
↓
Content extraction + retrieval
↓
AI commerce platforms
(ChatGPT Shopping · Perplexity answers · Gemini AI Mode)
↓
AI recommendation → high-intent shopper
```
Default Magento 2 fails at the first step - AI crawlers are blocked before extraction begins.
## Two scores, because they measure different things
**AI Discovery** asks whether AI systems can find, fetch and read the store: crawler access,
llms.txt, sitemap, Product schema, Open Graph, canonical tags. This is the half that pays off today -
ChatGPT, Perplexity and Gemini are already citing merchants that get it right.
**Agentic Readiness** asks whether an agent can *transact*: a UCP profile at
`/.well-known/ucp`, a reachable MCP endpoint, the well-known discovery matrix. Adoption here is
early, and that is exactly why it is scored separately - merged into one number, a near-universal zero
would drown out the discovery work that is already worth doing.
The scan reports both. So does [`angeo/module-aeo-audit`](https://packagist.org/packages/angeo/module-aeo-audit),
on the same weights, so an external scan and an in-store audit can be compared directly.
[ACP vs UCP - which to implement first →](https://angeo.dev/acp-vs-ucp-for-magento-2/)
## Why open-source?
AEO is infrastructure - it should not be locked behind a paywall. Every Magento merchant should be able to allow AI crawlers, generate llms.txt, and add proper Product schema without a subscription. The modules are **MIT licensed and free on Packagist**.
Implementation help, custom AEO configuration, and enterprise consulting are available as paid services. [Free audit →](https://angeo.dev/ai-magento-audit/)
## Featured guides
- [**Complete Magento 2 AEO Guide**](https://angeo.dev/magento-2-aeo-guide/) - all signals, CLI commands, theory, benchmarks
- [What scanning live Magento stores actually found](https://angeo.dev/aeo-scan-case-study/) - measured results across a sample
- [The product description that AI can't read](https://angeo.dev/magento-product-description-invisible-ai-chatgpt/) - JavaScript rendering gap and fix
- [Shopify vs Magento for AI commerce 2026](https://angeo.dev/shopify-vs-magento-ai-commerce-aeo-2026/) - AEO capabilities compared
- [ACP vs UCP for Magento 2](https://angeo.dev/acp-vs-ucp-for-magento-2/) - which agentic protocol to implement first
[View all articles →](https://angeo.dev/blog/)
## Frequently asked questions
### How do I check my Magento store's AEO score?
Two ways. The [free scan](https://angeo.dev/ai-magento-audit/#scan) reads your store the way an AI crawler does and needs no
installation - it returns an AI Discovery score and an Agentic Readiness score in a few seconds. For a full
audit, [`angeo/module-aeo-audit`](https://packagist.org/packages/angeo/module-aeo-audit)
runs inside Magento and measures 16 signals, including ones no external tool can see - such as whether
Product schema is rendered server-side or assembled by JavaScript after the crawler has left. Both use the
same weights, so the two scores are directly comparable.
### What is AEO for Magento 2?
AEO (AI Engine Optimization) is the practice of configuring a Magento 2 store so AI assistants - ChatGPT, Gemini, Perplexity, Claude - can discover, read, and recommend it. Key signals: allowing AI crawlers in robots.txt, generating llms.txt, adding `offers.availability` to Product schema, and submitting an ACP product feed. Default Magento 2 installations typically fail most of these checks. [Complete guide →](https://angeo.dev/magento-2-aeo-guide/)
### Does ChatGPT crawl Magento stores?
ChatGPT uses OAI-SearchBot to crawl the web for live query answers. By default, Magento 2's robots.txt can block OAI-SearchBot via wildcard rules - making the store invisible in ChatGPT search results. Adding an explicit `Allow: /` rule for OAI-SearchBot before any wildcard Disallow is one of the most impactful AEO fixes for most stores. [robots.txt fix guide →](https://angeo.dev/magento-2-robots-txt-chatgpt-gemini-ai-bots/)
### What is llms.txt and does Magento support it?
llms.txt is a plain-text file at `yourstore.com/llms.txt` - a structured catalogue map for AI systems, similar to sitemap.xml but for AI assistants. Default Magento 2 does not generate it. The free [angeo/module-llms-txt](https://packagist.org/packages/angeo/module-llms-txt) generates spec-compliant llms.txt and llms.jsonl per store view with cron-based auto-regeneration. [Generation guide →](https://angeo.dev/how-to-generate-llms-txt-for-magento-2-in-5-minutes/)
### Does Magento 2 support ChatGPT Shopping?
Yes, but it requires manual configuration. Magento merchants apply at [chatgpt.com/merchants](https://chatgpt.com/merchants), generate a spec-compliant ACP product feed, and pass OpenAI's conformance checks - including `offers.availability` in Product schema, which default Magento omits. The free [angeo/module-openai-product-feed](https://packagist.org/packages/angeo/module-openai-product-feed) handles feed generation. [Registration guide →](https://angeo.dev/magento-2-chatgpt-shopping-registration/)
### What is the difference between AI Discovery and Agentic Readiness?
AI Discovery measures whether AI systems can find, fetch and read a store: robots.txt access, llms.txt,
sitemap, Product schema, Open Graph, canonical tags. Agentic Readiness measures whether a shopping agent can
transact with it: a UCP profile at `/.well-known/ucp`, a reachable MCP endpoint, and the
well-known discovery matrix. They are scored separately because agentic adoption is early - a store can be
perfectly discoverable and still have no agentic surface at all, and merging the two would hide that.
### Is this compatible with Hyvä Theme?
Yes. All modules operate at the Magento core level - compatible with Luma, Hyvä, and any custom frontend. Hyvä stores have one additional consideration: product descriptions rendered via Alpine.js `x-show` may have reduced AI extraction reliability. [Rendering guide →](https://angeo.dev/magento-product-description-invisible-ai-chatgpt/)
### Is Adobe Commerce supported?
Yes. All modules support Magento 2.4.x on both Open Source and Adobe Commerce. Adobe Commerce Cloud requires a Fastly cache purge after any robots.txt change.
## Audit it from inside
The free scan sees what a crawler sees. The module sees everything - including signals no external
tool can reach, like whether your product schema is rendered server-side or assembled by JavaScript after
the crawler has left.
```
composer require angeo/module-aeo-audit
bin/magento setup:upgrade
bin/magento angeo:aeo:audit
```
Same weights as the scan above, so the two scores are directly comparable. The CLI prints the exact
Composer command to fix each failing signal.
[Request a free manual audit →](https://angeo.dev/ai-magento-audit/)
[View all modules on Packagist](https://packagist.org/packages/angeo/)
Part of the [AI Commerce Optimization](https://angeo.dev/ai-commerce-audit/) service suite · [Open-source modules on Packagist](https://packagist.org/packages/angeo/)
- [How to Check If Your Magento Store Is Visible to ChatGPT - Free AEO Audit Module](https://angeo.dev/magento-aeo-audit-module-chatgpt-visibility/): A free Magento AEO audit module that scores your store's AI visibility from the CLI - robots.txt, llms.txt, schema and feed checks in one command.
Most Magento developers spend hours manually checking robots.txt, schema markup, and sitemap configurations.
Then they wonder why their store still doesn't appear in ChatGPT or Gemini recommendations.
There is now a faster way.
[image: How to Check If Your Magento Store Is Visible to ChatGPT - Free AEO Audit Module]
## The Problem: No Standard AEO Checklist for Magento
SEO has Lighthouse. SEO has Search Console. SEO has dozens of audit tools built into every CI pipeline.
AEO - AI Engine Optimization - has almost nothing.
Magento developers who want to know whether their store is AI-visible have to check manually:
- Is `GPTBot` allowed in `robots.txt`?
- Does the store have a `llms.txt` file?
- Is Product JSON-LD schema present on PDP pages?
- Is there an AI-readable product feed for ChatGPT Shopping?
- Does the homepage have FAQPage schema for answer-box eligibility?
This takes time, requires domain knowledge, and produces no consistent score to track over time.
## Introducing: angeo/module-aeo-audit
`angeo/module-aeo-audit` is an open-source Magento 2 CLI module that runs a complete AEO audit with one command.
```
composer require angeo/module-aeo-audit
bin/magento setup:upgrade
bin/magento angeo:aeo:audit
```
The module checks 8 signal categories, scores your store, and tells you exactly what to fix - with specific commands.
## What It Checks
The audit evaluates the same signals AI search engines use to discover, index, and cite ecommerce stores.
Critical
robots.txt - AI bot access
GPTBot, ClaudeBot, PerplexityBot, anthropic-ai, Google-Extended
Critical
llms.txt - AI content map
The new standard for guiding LLMs to your priority pages
Important
Product JSON-LD schema
ChatGPT & Gemini extract product data from structured markup
Important
FAQPage schema
Increases AI citation probability for answer-style queries
Important
AI Product Feed
Required for ChatGPT Shopping and Gemini product cards
Standard
sitemap.xml
AI crawlers rely on sitemaps for complete page discovery
Standard
Open Graph tags
AI engines use og:description as content fallback
Standard
Canonical tags
Prevents AI indexing of duplicate Magento URL variants
## What the Output Looks Like
╔══════════════════════════════════════════╗
║ Angeo AEO Audit - angeo.dev ║
║ AI Engine Optimization for Magento 2 ║
╚══════════════════════════════════════════╝
Store: default - https://mystore.com/
+------------------------------------------+--------+-----------------------------------------------+
| Check | Status | Message |
+------------------------------------------+--------+-----------------------------------------------+
| robots.txt - AI Bot Access | ✓ PASS | All 7 AI bots are permitted in robots.txt. |
| llms.txt - AI Content Map | ✗ FAIL | llms.txt not found. |
| sitemap.xml - Search Engine Discovery | ✓ PASS | sitemap.xml found (1,243 URLs). |
| Product Schema - JSON-LD Structured Data | ✓ PASS | Product JSON-LD schema found. |
| FAQPage Schema - AI Answer Eligibility | ⚠ WARN | No FAQPage schema on homepage. |
| AI Product Feed - ChatGPT/Gemini | ✗ FAIL | No AI-readable product feed found. |
| Open Graph - Social & AI Preview Tags | ✓ PASS | All required Open Graph tags found. |
| Canonical Tags - Duplicate Content | ✓ PASS | Canonical tag found on homepage. |
+------------------------------------------+--------+-----------------------------------------------+
AEO Score: [██████████░░░░░░░░░░] 50% - Needs Improvement
✓ Pass: 5 ⚠ Warn: 1 ✗ Fail: 2
Critical fixes needed:
→ Install angeo/module-llms-txt and generate your llms.txt
→ Install angeo/module-openai-product-feed and run: bin/magento angeo:product-feed:generate
💡 Fix issues with angeo modules:
composer require angeo/module-llms-txt
composer require angeo/module-openai-product-feed
Every failed check includes a specific recommendation. Not just "fix your schema" - but exactly what to run.
## Three Output Formats
The module supports table, JSON, and Markdown output - useful both for developers and for integrating into dashboards or reports.
```
# Default - readable table in terminal
bin/magento angeo:aeo:audit
# JSON - for dashboards or automated processing
bin/magento angeo:aeo:audit --format=json --output=/tmp/aeo-report.json
# Markdown - for Notion, docs, or sharing with clients
bin/magento angeo:aeo:audit --format=markdown --output=/var/www/html/aeo-report.md
# Specific store only
bin/magento angeo:aeo:audit --store=en_gb
```
## CI Pipeline Integration
One of the more useful features: `--fail-on` exits with code 1 if the AEO score drops below a defined threshold.
```
# Fail the build if AEO score drops below 70%
bin/magento angeo:aeo:audit --fail-on=70
```
This means AEO readiness can be enforced in GitHub Actions, GitLab CI, or any deployment pipeline - the same way code quality tools work. If a deploy breaks AI visibility, the build fails.
> Treat AEO the same way you treat code quality. Automate it. Enforce it.
## How It Fits the Angeo Suite
`module-aeo-audit` is the diagnostic layer. It tells you what's missing. The other Angeo modules fix those gaps.
[angeo/module-aeo-auditDiagnose - score your AI readiness across 8 signals
THIS MODULE](https://packagist.org/packages/angeo/module-aeo-audit)
[angeo/module-llms-txtFix - auto-generate llms.txt and llms.ljson, cron-ready
FIX](https://packagist.org/packages/angeo/module-llms-txt)
[angeo/module-openai-product-feedFix - generate AI product feed for ChatGPT Shopping
FIX](https://packagist.org/packages/angeo/module-openai-product-feed)
[angeo/module-openai-instant-checkoutExtend - Agentic Commerce Protocol, buy directly from ChatGPT
EXTEND](https://packagist.org/packages/angeo/module-openai-instant-checkout)
A typical workflow after running the audit for the first time:
01
Run the audit
`bin/magento angeo:aeo:audit` - get scored report with specific failures
02
Fix critical signals first
robots.txt AI bots + llms.txt + Product schema - these have most impact
03
Install fixing modules
`composer require angeo/module-llms-txt angeo/module-openai-product-feed`
04
Re-run and enforce in CI
`bin/magento angeo:aeo:audit --fail-on=80` to lock in the score
## Installation
**Requirements:** PHP 8.2+, Magento 2.4+. Compatible with Magento Open Source and Adobe Commerce Cloud.
```
composer require angeo/module-aeo-audit
bin/magento setup:upgrade
bin/magento cache:flush
```
One CLI command registered: `angeo:aeo:audit`. No admin configuration. No database changes. Clean uninstall.
## Why This Module Exists
ChatGPT referral traffic converts at 4-5× the rate of standard organic search. Gemini is now embedded across every Google product used by over a billion people.
Most Magento stores have at least 2-3 critical AEO issues they don't know about. A `robots.txt` that accidentally blocks `GPTBot`. A product page with no JSON-LD schema. No `llms.txt` while competitors already have one.
The audit takes 30 seconds to run. The fixes usually take less than an hour.
> The window to establish AI visibility before competitors do is still open - but it's closing fast.
Install the module - or run the free web-based self-assessment if you're not on Magento.
[View on Packagist →](https://packagist.org/packages/angeo/module-aeo-audit)
[Free Web Self-Assessment](https://angeo.dev/ai-magento-audit/)
- [AI Commerce Audit](https://angeo.dev/ai-commerce-audit/): A 3-week professional audit: technical AI-visibility analysis, scored PDF report with a prioritised roadmap, and a strategy session. Magento and Shopify Plus.
AI Commerce Audit
# Full AI Visibility Audit for Your Ecommerce Store
Find out whether ChatGPT, Gemini, and Perplexity can find and recommend your store - and what to fix first. Start with a €400 Quick Audit, or the full three-week engagement.
See Quick Audit →
[Free Self-Assessment First](https://angeo.dev/ai-magento-audit/)
For Magento · Adobe Commerce · Shopify Plus · B2B platforms
Free Self-Assessment
€0 · 2 min · self-serve
AEO Quick Audit
€400 · 48 hours
Full AI Commerce Audit
from €2,500 · 3 weeks
## AEO Quick Audit
€400fixed · 48h turnaround
A fast, human-reviewed check of whether AI systems can find and recommend your store - the core signals, scored, with the top fixes named. For stores that want a real answer before committing to the full three-week audit.
### What's included
- Automated scan of the core AEO signals - crawler access, llms.txt, product schema, feed
- Manual review of what the scan can't see - how your store actually appears when queried in ChatGPT
- A 3-5 page PDF: score, the critical issues, and the top fixes in priority order
- A 30-minute call to walk through the findings
### What's not included
- Implementation of the fixes - available as a separate engagement
- Category benchmarking and brand-entity analysis - part of the full audit
- The 30-90 day roadmap and strategy session - part of the full audit
- Ongoing monitoring
[Book Quick Audit - €400 →](https://calendly.com/angeo-dev/30min)
Report delivered within 48 hours · fixed price, no scoping call needed
## What the Audit Covers
Eight signal categories, spanning the 15-signal AEO framework - evaluated against how ChatGPT, Gemini, Perplexity, and Claude index and recommend stores.
### AI Bot Access (robots.txt)
Whether GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, and Google-Extended can crawl your store, or are blocked by default.
### llms.txt - AI Content Map
Presence, structure quality, and completeness of llms.txt for LLM indexing.
### Structured Data (Schema)
Product JSON-LD, FAQPage, BreadcrumbList, Organization - checked against AI citation standards.
### AI Product Feed
Whether your catalogue is accessible as a structured feed for ChatGPT Shopping and AI commerce surfaces.
### Sitemap & Crawlability
Sitemap.xml completeness, robots.txt references, orphaned pages, and internal linking.
### Agentic Commerce Readiness
Compatibility with the Agentic Commerce Protocol (ACP) and Universal Commerce Protocol (UCP) for AI-driven checkout.
### Brand & Entity Signals
How AI systems interpret your brand authority, expertise, and trust signals.
### GEO Readiness Score
A Generative Engine Optimization readiness score across the measured signals.
## What You Receive
Concrete deliverables, not a generic report.
✓
### AI Commerce Readiness Score
Scored across eight signal categories, with a benchmark comparison for your ecommerce vertical.
✓
### Detailed Audit Report (PDF)
Findings per signal category with severity classification: critical, important, standard.
✓
### Prioritised Fix List
Ranked by impact and implementation effort. Includes specific Composer commands for Magento modules where applicable.
✓
### 30-90 Day Implementation Roadmap
A phased action plan your dev team can execute immediately, with quick wins in Week 1.
✓
### Strategy Walkthrough Session
A 60-minute call to review findings, answer questions, and align on implementation priorities.
## Who This Is For
The full audit suits stores where AI discovery is a real revenue factor. Smaller stores usually start with the €400 Quick Audit above.
Best fit
Stores where AI discovery affects revenue - from growing brands to €1M+ merchants
Platform
Magento 2, Adobe Commerce, Shopify Plus, B2B platforms
Situation
Investing in AI transformation or noticing declining organic reach
Team
Has a dev team or agency to implement findings
**Not sure if you need a full audit?** Run the free 2-minute Magento AEO self-assessment first - it checks the core signals and gives a scored report with specific fixes.
[Free Self-Assessment →](https://angeo.dev/ai-magento-audit/)
## Audit Process
About 3 weeks from kickoff to strategy session.
Week 1
### Technical Analysis
Full technical and AI-visibility evaluation across all eight signal categories - an automated CLI audit plus a manual brand-interpretation review.
Week 2
### Audit Report Delivery
A PDF report with scored findings, severity classification, prioritised fix list, and 30-90 day roadmap, delivered for your team to review.
Week 3
### Strategy Walkthrough Session
A 60-minute call to walk through findings, answer questions, and align on implementation priorities.
## Frequently Asked Questions
### What's the difference between the Quick Audit and the full audit?
The **AEO Quick Audit** (€400, 48 hours) is a fixed-price check of the core signals with a short PDF and a 30-minute call - enough to know where you stand. The **full AI Commerce Audit** (from €2,500, ~3 weeks) adds category benchmarking, brand-entity analysis, a 30-90 day roadmap, and a strategy session.
### How is this different from an SEO audit?
An SEO audit evaluates Google ranking factors. The AI Commerce Audit evaluates how AI systems - ChatGPT, Gemini, Perplexity, Claude - read, interpret, and recommend your store. Different signals, different fixes.
### How long does the audit take?
About 3 weeks from kickoff call to strategy walkthrough. Week 1: analysis. Week 2: report delivery. Week 3: strategy session.
### Is there a free option first?
Yes. Magento developers can run a [free AEO self-assessment](https://angeo.dev/ai-magento-audit/) that checks the core signals in about two minutes. The full audit adds brand analysis, benchmarking, and the strategy session.
### Do you implement changes after the audit?
Implementation support is available as a separate engagement. Angeo also provides [open-source Magento 2 modules](https://packagist.org/packages/angeo/) that directly fix the most common AEO issues - installable via Composer.
### Which platforms do you support?
The audit covers any ecommerce platform. Angeo's open-source modules and deepest technical expertise are for Magento 2 and Adobe Commerce.
## Book Your Audit
Ready for the €400 Quick Audit, or want to discuss the full three-week engagement? Send a message and I'll confirm fit and next steps.
[Book a 30-min Call →](https://calendly.com/angeo-dev/30min)
Or email directly: [info@angeo.dev](mailto:info@angeo.dev)
Part of the [AI Commerce Optimization](https://angeo.dev/ai-commerce-optimization/) service suite ·
[Open-source modules on Packagist](https://packagist.org/packages/angeo/)
- [AI Commerce Optimization | Make Your Ecommerce Store Visible in AI Search](https://angeo.dev/ai-commerce-optimization/): Done-for-you AEO implementation for Magento 2: robots.txt, llms.txt, Product schema, and ChatGPT Shopping feed - typically live within one business day.
AI Commerce Optimization
# Make Your Ecommerce Store Visible to ChatGPT, Gemini & Perplexity
AI is replacing traditional search. Stores that AI cannot read are already losing discovery, traffic, and revenue. We fix that.
[Book AI Commerce Audit →](https://angeo.dev/ai-commerce-audit/)
[Free Self-Assessment](https://angeo.dev/ai-magento-audit/)
For Magento & Adobe Commerce · Open-source modules on Packagist
## Search Has Changed. Has Your Store?
AI assistants now control product discovery for millions of buyers. They don't show a list of links - they pick a winner and recommend it directly.
When a user asks ChatGPT "best running shoes under €120" - it recommends one or two stores. Not ten. If your store is not AI-readable, you are not in that list.
**AI chooses which brands appear**Based on structured signals, not just rankings
**Product comparisons are automatic**AI reads your catalog and compares for users
**Agentic checkout is live**ChatGPT can now complete purchases directly
**Traditional SEO is not enough**New signals required: llms.txt, schema, AI feeds
## What We Do
Full-stack AI Commerce Optimization - from technical audit to agentic checkout implementation.
[01 - Audit
### AI Commerce Audit
Full evaluation of your store's AI visibility: robots.txt, structured data, llms.txt, product feed, and agentic readiness. PDF report + strategy session.
Book Audit →](https://angeo.dev/ai-commerce-audit/)
[02 - Self-Assessment
### Free AEO Check
Quick self-assessment for Magento developers. Check 8 AEO signals in 2 minutes - get a scored report with specific Composer commands to fix each issue.
Run Free Check →](https://angeo.dev/ai-magento-audit/)
[03 - Modules
### Open-Source Magento Modules
llms.txt generator, AI product feed, instant checkout (ACP), and AEO audit CLI. Install via Composer. MIT licensed.
View on Packagist →](https://packagist.org/packages/angeo/)
04 - Implementation
### Technical Implementation
Full implementation of AI Commerce stack: structured data, llms.txt, ChatGPT product feed, and Agentic Commerce Protocol for Magento 2.
[Contact →](mailto:info@angeo.dev)
## How It Works
From audit to implementation in 4 steps.
01
### AI Commerce Audit
We evaluate your store's AI visibility across 8 signal categories. Technical analysis + brand interpretation review.
02
### Opportunity Mapping
Prioritized list of highest-impact fixes - from a 5-minute robots.txt update to a full llms.txt and product feed implementation.
03
### Implementation
We install Angeo modules or provide guidelines for your dev team. Magento 2 and Adobe Commerce Cloud compatible.
04
### Continuous Monitoring
Monthly AEO score tracking. We monitor AI citation share and update strategy as ChatGPT and Gemini evolve.
## Expected Outcomes
What changes after AI Commerce Optimization.
Visible in ChatGPT Shopping results
Cited in Gemini AI Overviews
AI-readable product catalog
Higher recommendation probability
Agentic checkout ready
No duplicate URL indexing
## Frequently Asked Questions
### What is AI Commerce Optimization?
AEO prepares ecommerce stores to be discovered, recommended, and purchased through AI systems - ChatGPT, Gemini, Perplexity, and Google AI Overviews. It requires different signals than traditional SEO: structured data, llms.txt, and AI product feeds.
### How is this different from an SEO audit?
An SEO audit checks Google ranking factors. An AI Commerce Audit checks whether AI systems can read, trust, and recommend your store - robots.txt AI bot access, llms.txt, Product schema, FAQPage schema, AI product feed.
### Which platforms do you support?
Angeo specializes in Magento 2 and Adobe Commerce. Open-source modules are available via Composer on Packagist. Strategy and audit services apply to any ecommerce platform.
### How do I start?
For Magento developers: run the free 2-minute self-assessment at [angeo.dev/ai-magento-audit](https://angeo.dev/ai-magento-audit/). For a full audit with PDF report: book a call at [angeo.dev/ai-commerce-audit](https://angeo.dev/ai-commerce-audit/).
## Ready to Become AI-Visible?
Start with a free 2-minute self-assessment or book a full AI Commerce Audit.
[Book AI Commerce Audit →](https://angeo.dev/ai-commerce-audit/)
[Free Self-Assessment](https://angeo.dev/ai-magento-audit/)
- [Contact](https://angeo.dev/contact/): Talk to a Magento 2 AEO specialist. AEO audits, implementation, and full-stack Magento development. Reply within 24 hours. info@angeo.dev
Contact - Magento 2 AEO Agency
# Contact our *Magento 2 AEO agency*
angeo.dev is a Magento 2 AEO agency that makes ecommerce stores visible in
ChatGPT (OpenAI), Gemini (Google), Claude (Anthropic), and Perplexity. Whether you
need a quick AEO audit, ongoing monitoring, or a full Magento 2 build, tell us about
your store and we'll reply within 24 hours with a concrete next step - not a sales pitch.
-
### AEO Audit
Not sure where you stand? Start with the
[free self-assessment](https://angeo.dev/ai-magento-audit/)
or book a full [AI Commerce Audit](https://angeo.dev/ai-commerce-audit/).
-
### AEO Implementation
Done-for-you setup of all signals.
See [AI Commerce Optimization](https://angeo.dev/ai-commerce-optimization/).
-
### AEO Monitoring
Monthly score reports, feed refresh, and llms.txt regeneration on catalog changes.
-
### Magento 2 Development
Full-stack builds, Hyvä theme, migrations, performance, and custom modules.
Prefer email? Write directly to
[**info@angeo.dev**](mailto:info@angeo.dev)
Based in the Netherlands · Working with Magento since 2015
Reply within 24 hours
No automated sequences
A real person replies
Start the conversation
Tell us about your store and what you're trying to achieve.
No spam. No automated sequences. A real person replies.
## Why work with a specialist Magento 2 AEO agency
A default Magento 2 install typically scores low on AEO. AI crawlers are often blocked
in robots.txt, there is no llms.txt, Product JSON-LD schema is incomplete, and no AI
product feed is registered. As a focused Magento 2 AEO agency, we close those gaps so
ChatGPT, Gemini, Perplexity, and Claude can discover, understand, and recommend your store.
Most stores significantly improve their AEO score within about 90 minutes of implementing
our open-source module suite.
AEO (AI Engine Optimization) is the same work others call Generative Engine Optimization
(GEO), AI Search Optimization, or AI Visibility - getting a catalog discovered and
recommended by AI assistants. We work with Magento Open Source and Adobe Commerce, including
Hyvä Theme builds and migrations. Every project starts with a clear diagnosis: an audit of
the signals AI engines actually read, followed by a prioritised fix list you can act on
immediately. You can install the same modules we use, free under the MIT licence, from our
[packages on Packagist](https://packagist.org/packages/angeo/).
Angeo participates in Anthropic's Claude Partner Network and builds with Claude alongside
OpenAI and Google AI, choosing the right model per task. Based in the Netherlands and working
with Magento since 2015, we reply to every enquiry within 24 hours. Use the form above, or
email [info@angeo.dev](mailto:info@angeo.dev) directly, and tell us where your
store stands today and where you want it to appear in AI search.
## About
Who publishes this.
- [Privacy Policy](https://angeo.dev/privacy-policy/): Privacy policy and data handling practices for angeo.dev - Magento 2 AEO tooling and consulting by Ievgenii Gryshkun.
-
Last updated: August 4, 2026
## 1. Who we are
This website, angeo.dev, is operated by:
**Ievgenii Gryshkun**
Netherlands
[info@angeo.dev](mailto:info@angeo.dev)
For the purposes of the General Data Protection Regulation (GDPR), Ievgenii Gryshkun is the data controller responsible for your personal data. This policy covers angeo.dev and the AEO scan service at api.angeo.dev.
## 2. What data we collect
We collect only the data you voluntarily provide:
**Contact form** - name, email address, store URL, and message content when you submit the contact form.
- **Newsletter subscription** - email address when you subscribe to our blog updates. Brevo also records your IP address and the date of sign-up as proof of consent.
- **AEO scan** - when you run a scan we record the address of the store scanned, the two scores it received, and the time. We do not record who you are, your IP address, or your browser. If you never submit an email address, a scan leaves nothing that identifies you.
- **AEO scan - full report** - if you ask to unlock the full report we additionally store your email address, the store you scanned and its scores, a shortened version of your IP address, and whether you asked for marketing email.
- **Technical data** - IP address and browser information collected automatically by hosting infrastructure and Google reCAPTCHA to prevent spam.
We do not collect payment information, sensitive personal data, or data about minors. The scan reads only what any visitor or AI crawler can already fetch from a store - it never has access to your Magento admin, your customers, or your orders.
## 3. Why we collect it
| Purpose | Legal basis |
| Responding to your enquiry via the contact form | Legitimate interest (Art. 6(1)(f) GDPR) |
| Sending newsletter and blog updates | Consent (Art. 6(1)(a) GDPR) |
| Producing the AEO report you asked for, and answering questions about your result | Performance of the service you requested (Art. 6(1)(b) GDPR) |
| Keeping a free public tool from being used to scan the web at scale | Legitimate interest (Art. 6(1)(f) GDPR) |
| Preventing spam via reCAPTCHA | Legitimate interest (Art. 6(1)(f) GDPR) |
**The report and the newsletter are separate.** The marketing checkbox on the scan form is unticked by default, and ticking it is **not** required to see your report. Declining it changes nothing about the results you receive, and you can withdraw consent later without losing anything you already have.
## 4. Who we share data with
We use the following third-party services that may process your data:
- **Brevo (Sendinblue)** - email marketing platform where newsletter subscribers are stored. Brevo stores data on three geographically distinct servers within the EU and is ISO 27001:2022 certified. Brevo records subscriber IP addresses as proof of consent. [Brevo Privacy Policy](https://www.brevo.com/legal/privacypolicy/).
- **WPForms** - contact form plugin. Form submissions are stored in your WordPress database hosted on our server.
- **Google reCAPTCHA** - spam protection service operated by Google LLC. Subject to [Google's Privacy Policy](https://policies.google.com/privacy).
- **Hostinger** - our hosting provider, which necessarily processes data as part of running the server, under their own data processing terms.
AEO scan data is **not** shared with any of the above beyond hosting. It is not sent to a CRM, an analytics platform or a mailing service - it sits in ordinary files on our own EU server. We do not sell, rent, or trade your personal data to any third parties.
## 5. How long we keep your data
- **Contact form submissions** - retained for up to 12 months, then deleted.
- **Newsletter subscribers** - retained until you unsubscribe. Every email includes an unsubscribe link.
- **Scan records** - the store scanned and its scores are kept indefinitely as anonymous statistics. They contain nothing about who ran the scan.
- **AEO report requests** - your email address, the store you scanned and its scores are retained until you ask us to erase them.
- **Saved report pages** - deleted automatically 30 days after the scan.
## 6. The AEO scan in detail
**Your report link.** When you unlock a report we give you a long, unguessable web address where it stays for 30 days. We cannot reconstruct that address from our own records - we store only a one-way hash of the token it comes from. That makes the link safe to keep, and it also means **anyone who has the link can open the report**, so treat it as you would any other private link. We cannot recover it for you if it is lost; running the scan again takes a few seconds and gives a current result.
The report page asks search engines not to index it.
**Scanning a store you do not own.** The scan fetches public pages, exactly as a search engine or an AI crawler does. It does not log in, submit forms, or place orders. If you scan a store you do not own, that store's server may record a request from `api.angeo.dev` - the same record it keeps for any other visitor. We never learn who ran a scan, so we could not identify you to them even if asked.
**Rate limiting.** To stop the tool being used to scan the web at scale, we count recent requests against a shortened form of your IP address - the last part is removed, so it identifies a network rather than a device. These counters are discarded within the hour.
## 7. Your rights
Under GDPR you have the right to:
- **Access** - request a copy of the data we hold about you.
- **Rectification** - ask us to correct inaccurate data.
- **Erasure** - ask us to delete your data ("right to be forgotten"). For the AEO scan this removes every record of your address, not only the marketing flag.
- **Restriction** - ask us to limit how we use your data.
- **Portability** - receive your data in a structured, machine-readable format.
- **Withdraw consent** - unsubscribe from the newsletter at any time via the link in any email, or by emailing us. Withdrawing consent does not affect a report you have already received.
- **Object** - object to processing based on legitimate interest.
To exercise any of these rights, email us at [info@angeo.dev](mailto:info@angeo.dev). We will respond within 30 days. You do not need to give a reason, and none of these requests costs anything.
## 8. Cookies
This website uses the following cookies:
- **Strictly necessary cookies** - set by WordPress for session management. These cannot be disabled.
- **Google reCAPTCHA cookies** - set by Google to distinguish humans from bots. Subject to Google's cookie policy.
The AEO scan tool sets no cookies and uses no browser storage of any kind.
We do not currently use analytics or advertising cookies. If this changes, this policy will be updated.
## 9. Complaints
If you believe we are handling your data incorrectly, you have the right to lodge a complaint with the Dutch data protection authority: [Autoriteit Persoonsgegevens](https://autoriteitpersoonsgegevens.nl), or with the supervisory authority in your own country.
## 10. Changes to this policy
We may update this policy from time to time. The date at the top of this page shows when it was last revised. Continued use of angeo.dev after changes constitutes acceptance of the updated policy.
Questions? Contact us at [info@angeo.dev](mailto:info@angeo.dev)
- [Privacy Policy - Angeo MCP Checkout](https://angeo.dev/privacy-mcp/): How the Angeo MCP checkout connector handles data: no conversation data, minimal logs, EU hosting, GDPR-compliant.
**Last updated:** 11 July 2026
This Privacy Policy explains how the Angeo MCP Checkout connector ("the Connector", "we", "us") handles data when it is used through an AI assistant such as Claude. It applies to the Model Context Protocol (MCP) endpoint operated at `mcp.angeo.dev` and to the open-source module `angeo/module-mcp-checkout` when connected to an AI assistant.
## 1. Who we are
The Connector is operated by Angeo (angeo.dev), based in the Netherlands. Angeo is the data controller for the limited operational data described in section 5. For questions about this policy or your data, contact us at [info@angeo.dev](mailto:info@angeo.dev).
## 2. What data we process
The Connector enables an AI assistant to complete a guest checkout on a Magento 2 / Adobe Commerce store. To do this, it passes through the following data that you provide during a checkout conversation:
- **Contact details:** first name, last name, email address, and telephone number
- **Shipping address:** street, city, region/state, postcode, and country
- **Order details:** the products, quantities, and totals you choose to purchase
- **Optional company name**, if provided
The Connector does **not** collect, request, or process payment card data. Card payment, where applicable, is completed separately through the store's own PCI-compliant payment gateway or a payment link, entirely outside the Connector. The Connector never holds, transfers, or has access to funds.
## 3. What we deliberately do NOT collect
The Connector is designed for data minimisation. It does **not**:
- collect, read, or store your conversation with the AI assistant, or any part of it, including for logging purposes;
- access, query, or store the AI assistant's memory or your previous chats;
- access, query, or store your files;
- store the contents of the requests or responses that pass through it (see section 5);
- use your data to train any AI model;
- serve advertising, sponsored content, or product placements.
The Connector requests only the data strictly necessary to place the order you have asked for, and nothing else.
## 4. How we use this data
The data listed in section 2 is used solely to create and place your order in the merchant's store. Specifically, it is passed to the connected Magento store to:
- Create a guest shopping cart and add the products you select
- Calculate shipping options for your address
- Set the shipping and billing details on the order
- Place the order in the store on your instruction and after your explicit confirmation
We do not use your data for advertising, profiling, or any purpose unrelated to completing the order you requested. Under the GDPR, our legal basis for this processing is the performance of a contract you have requested (Art. 6(1)(b)), and, for the security logging described in section 5, our legitimate interest in operating the service securely (Art. 6(1)(f)).
## 5. Data storage and retention
**The Connector does not maintain a persistent store of your personal data.** The checkout data you provide is passed through to the connected merchant's Magento store, where it becomes part of that store's order records and is subject to *the merchant's own privacy policy and retention practices*. The Connector does not retain a copy.
**Operational log.** For security, rate-limiting, and abuse prevention, the Connector writes a minimal technical log entry per request containing *only*:
- a timestamp;
- the identifier of the connecting application and the authorised session;
- the name of the tool that was invoked (for example, `search_products`);
- whether the request succeeded, and how long it took.
This log deliberately excludes the contents of requests and responses. It therefore contains **no** names, addresses, email addresses, telephone numbers, order contents, order references, or payment information. Access tokens are never logged.
**Retention.** Operational log entries are retained for a maximum of 90 days and are then deleted. Authorisation records (issued access and refresh tokens) are retained only for the lifetime of the token and are deleted or invalidated on expiry or on disconnection.
**Location.** Data processed by the Connector is stored on servers located in the European Union. No personal order data is retained by the Connector outside the pass-through described above.
## 6. Sharing with third parties
Your order data is shared only with:
- **The merchant's Magento store** you are checking out on - this is the destination of your order and the essential purpose of the Connector.
- **Infrastructure providers** used to host and operate the endpoint, acting solely as processors on our behalf, under contract and within the European Union.
We do not sell your personal data, we do not share it with advertisers, and we do not share it with any unrelated third party.
## 7. The AI assistant
The Connector is invoked through an AI assistant (for example, Claude, operated by Anthropic). Your conversation with the assistant is governed by that assistant provider's own privacy policy, not by this one. The Connector receives only the specific checkout data the assistant sends to it in order to fulfil your request, and has no visibility into the rest of your conversation.
## 8. Security
The Connector applies the following safeguards:
- All traffic is served exclusively over HTTPS (TLS). Plain HTTP is rejected.
- Access is authenticated using OAuth 2.1 with PKCE (S256). Unauthenticated and invalid requests are rejected.
- Every access token is verified on every request, including its signature, issuer, expiry, and intended audience. Tokens issued for a different service are rejected.
- Your access token is never forwarded to the merchant's store. The Connector authenticates to the store with its own separate credential, so your credentials are never re-used elsewhere.
- Rate limiting protects against abuse.
- Order placement requires explicit user confirmation and is never performed autonomously.
## 9. Your rights
Because order data becomes part of the merchant's store records, requests to access, correct, or delete that data should be directed to the merchant operating the store, who is the controller of those records. For the limited operational data processed by the Connector (section 5), you may contact us at [info@angeo.dev](mailto:info@angeo.dev) to exercise your rights.
Depending on your location, you may have the right to access, rectify, erase, restrict, or object to processing of your personal data, the right to data portability, and the right to lodge a complaint with a supervisory authority. In the Netherlands, this is the Autoriteit Persoonsgegevens.
## 10. Disconnecting
You can disconnect the Connector at any time in your AI assistant's settings. On disconnection, the assistant removes its stored tokens. You may also contact us at [info@angeo.dev](mailto:info@angeo.dev) to request that we invalidate any tokens issued to you.
## 11. Children
The Connector is not directed at children and is not intended to be used by anyone under the age required to enter into a purchase contract in their jurisdiction.
## 12. Changes to this policy
We may update this policy from time to time. The "Last updated" date at the top of this page reflects the most recent revision. Material changes will be reflected on this page.
## 13. Contact
For any questions about this Privacy Policy or about how the Connector handles data, contact:
Angeo
Email: [info@angeo.dev](mailto:info@angeo.dev)
Web: [https://angeo.dev](https://angeo.dev)
- [About](https://angeo.dev/about/): Ievgenii Gryshkun - Magento 2 engineer and founder of angeo.dev. Full-stack Magento development and AEO for stores that want to be visible in ChatGPT, Gemini & Claude.
[image: Ievgenii Gryshkun, Magento 2 engineer and founder of angeo.dev]
# Ievgenii Gryshkun
Magento 2 Engineer & Founder, angeo.dev - working with Magento since 2015
[LinkedIn](https://www.linkedin.com/in/ievgenii-gryshkun-34a381230/)
[GitHub](https://github.com/angeo-dev)
[Packagist](https://packagist.org/packages/angeo/)
[info@angeo.dev](mailto:info@angeo.dev)
## Background
I'm a full-stack Magento 2 engineer with over 10 years building, optimising, and migrating Magento and Adobe Commerce stores. Over that time I've worked across the full stack - custom module development, Hyvä Theme implementations, Adobe Commerce Cloud integrations, performance engineering, and complex third-party integrations.
I like infrastructure problems that sit below the UI layer - the things users never see directly but that determine whether systems can discover, trust, and transact with your store correctly. That's what drew me to Magento in the first place, and it's what eventually led me to AEO.
While auditing Magento stores for AI visibility, I kept finding the same pattern: stores with strong Google rankings were completely absent from ChatGPT results. The problem wasn't content or SEO - it was a specific set of technical signals that traditional optimisation never touched. robots.txt blocking AI crawlers, missing llms.txt, incomplete Product schema, no AI product feed. The same gaps, store after store.
"A store can rank #1 on Google and still be invisible in ChatGPT. They use completely different indexing systems - and almost nobody was fixing the AI side."
That pattern became angeo.dev: an open-source module suite and audit toolchain built around a 15-signal AEO framework, designed to take a default Magento install from a low AEO score to a strong one - and to help stores meet the technical requirements for ChatGPT Shopping visibility.
Open-source is the natural fit for this kind of infrastructure work. The problems are shared across every Magento installation. The fixes should be too.
## Why work with one person
angeo.dev is intentionally lean. Every audit, every module, every line of implementation code comes from me directly - not an account manager, not a junior developer working from a brief.
For technical ecommerce teams, this matters. You get a direct line to the person who built the tooling, understands the Magento internals, and has audited the same signals across Magento Open Source and Adobe Commerce stores of every size. There are no handoffs, no translation layers, no miscommunication between sales and delivery.
When the scope grows, I work with a trusted network of Magento specialists - but the technical ownership stays with me.
## Open-source work
All core Angeo modules are MIT-licensed and free on Packagist. No SaaS, no licence fees, no data sent anywhere - everything runs on your own Magento instance.
AUDIT
angeo/module-aeo-audit
CLI audit scoring 15 AEO signals, with a score-trend dashboard and CI enforcement via `--fail-on`.
VISIBILITY
angeo/module-aeo-brand-visibility
Live AI brand visibility - recall and citation rate across ChatGPT, Claude, Perplexity, Gemini and Groq. The 16th signal on top of the audit.
LLM
angeo/module-llms-txt
Spec-compliant llms.txt, llms-full.txt and streaming JSONL from your live catalogue. Multi-store, cron-ready.
SCHEMA
angeo/module-rich-data
Injects spec-compliant Product, Organization, BreadcrumbList, FAQPage and WebSite JSON-LD.
ROBOTS
angeo/module-robots-txt-aeo
AI crawler rules (OAI-SearchBot, GPTBot, PerplexityBot, ClaudeBot and more) added to robots.txt without overwriting your existing rules.
FEED
angeo/module-openai-product-feed
Product feed for ChatGPT Shopping registration - cron-scheduled, multi-store.
API
angeo/module-openai-product-feed-api
Full ACP REST API - 6 endpoints for feeds, products (with pagination and variants) and promotions.
UCP
angeo/module-ucp
Universal Commerce Protocol profile generator - serves `/.well-known/ucp` with ECDSA P-256 signing keys.
CONTENT
angeo/module-ai-description-updater
Bulk AI product descriptions via OpenAI, Anthropic Claude or Google Gemini - multi-store, per-store prompts, cron.
ACP
angeo/module-openai-instant-checkout
Agentic Commerce Protocol Instant Checkout - AI-driven purchases via a custom Agentic Checkout API.
[See all packages on Packagist →](https://packagist.org/packages/angeo/)
## Technical stack
Magento 2 Open Source & Adobe Commerce
Adobe Commerce Cloud Cloud infrastructure
Hyvä Theme Frontend performance
PHP 8.2+ Backend
GraphQL Headless APIs
OpenSearch Search & indexing
Redis & Varnish Caching layer
MySQL 8 Database
ACP & UCP Agentic commerce protocols
OpenAI / Claude / Gemini AI integration
Stripe Payments
GitHub Actions CI / CD
Tailwind CSS Frontend styling
Alpine.js Frontend interactivity
JSON-LD / Schema.org Structured data
PHPStan & PHPUnit Code quality
## What I work on
My focus is Magento 2 and Adobe Commerce - from greenfield builds to complex migrations, performance engineering, and AI commerce readiness. Most projects fall into one of three categories:
**AEO audits and implementation** - a full assessment of your store's AI visibility across the 15-signal framework, followed by hands-on implementation of the Angeo module stack. Most stores significantly improve their AEO score within about 90 minutes.
**Full-stack Magento 2 development** - custom module development, Hyvä Theme implementation, Adobe Commerce Cloud setup, third-party integrations, and performance optimisation.
**AEO monitoring** - ongoing monthly score tracking, feed refresh on catalogue changes, llms.txt regeneration, and priority support.
## Work together
If you're running a Magento 2 or Adobe Commerce store and want to understand your AI visibility - or need full-stack development done properly - get in touch.
I usually reply within 24 hours with three things: the likely root cause of what you're seeing, whether it's worth fixing given your setup, and the fastest implementation path. No sales pitch, no discovery call required to get a straight answer.
[info@angeo.dev](mailto:info@angeo.dev)
- [Blog](https://angeo.dev/blog/): Technical guides for Magento 2 AEO optimization - robots.txt for AI bots, llms.txt generation, Product schema, ChatGPT Shopping setup, and AI traffic attribution.
## Articles
Everything else, most recently updated first.
- [AI assistants named 458 shops](https://angeo.dev/ai-readability-and-being-named/): A pre-registered study of 458 businesses AI assistants named. FourAI-readability signals did not separate the ones named often fromcomparable ones named once - and 71% of llms.txt files were identical.
Two earlier pieces measured how Magento stores are configured for AI assistants: a [baseline scan, since repeated on a larger frame](https://angeo.dev/aeo-scan-case-study/), and a [store-by-store repeat that found 94% unchanged](https://angeo.dev/magento-ai-signals-two-scans/). Both measured configuration. Neither measured visibility. This one asks whether four observable technical signals distinguish businesses that assistants name repeatedly from businesses they name once. None of the four was more common among the repeatedly named group by the margin I pre-registered. One of them, `llms.txt`, was significantly *less* common there - the opposite of what the field assumes. I wrote down what I expected before I had the data, hashed it, and sent it to the other party to hold - what follows is that prediction against the result, including the parts where I was wrong.
## Key findings
- The **primary analysis did not meet** the pre-registered refutation condition; a separate pre-specified runA-only check did, on a four-store cell that is not interpretable
- **3%** of the businesses an assistant named run Magento; I had predicted under 15%
- **71%** of the `llms.txt` files found came from one template rather than 113 separate decisions to publish
- Strip those and adoption is **10%** here against 11% on the Magento frame - most of the apparent difference between the two populations was that template
## The question
Do businesses that AI assistants name repeatedly differ, on measurable technical signals, from businesses the same assistants name exactly once?
Note what that does *not* ask. Every business in this study was named at least once, so nothing here estimates the chance of being named at all. It estimates the difference between repeated and one-off mentions among businesses already in the answers.
Four signals, all visible from outside a store: whether `robots.txt` blocks any of eight AI crawlers; whether the site serves an `llms.txt`; whether a product page publishes JSON-LD `Product`; and whether that node carries `offers.availability`.
## Where the data comes from, and what I did not control
The answers are not mine. They come from connexion.me, who ran a paired home-decor study across ChatGPT, Gemini and Perplexity for this one: 44 product-level buying questions asked twice, once plain and once with a constant extra sentence, giving two arms of 264 answers each (44 questions × 3 engines × 2 runs). Questions like *where can I buy blackout curtains for a bay window, three drops to one length* - specific enough that an engine has to reach past the marketplaces.
One thing to fix in the reader's head before any number: this measures which businesses these three engines named, under this question set, on these days. That is not the same as AI visibility in general, and nothing below should be read as though it were.
I did not write the questions. I never saw the store list they produced until after my analysis plan was sealed, and they never saw my sample frame, my scan results or my thresholds. That blinding is deliberate: if either of us could see the other's data, someone could reasonably say the questions were written toward the shops or the thresholds toward the answers.
Their roster carries 669 businesses, the union of both runs and both arms, with per-run mention counts and, where resolvable, a domain.
The paired home-decor study is not on their public site yet - by agreement it goes up after this piece. Their published boards, which document the same method on a different category, are at [connexion.me/c/crmctx](https://connexion.me/c/crmctx/); the figures on that page are theirs and are not used here.
**What that leaves me unable to check.** The engines' answers, the extraction prompt, the name-folding rules and the domain resolution are all theirs. I re-cut their normalisation from the pre-normalisation strings they ship and got their published counts back, which is a check on the arithmetic, not on the instrument.
## What I predicted, before any of it
Sealed 10 August, SHA-256 `9b4ccf12629e...`, amended twice, both amendments sent and hashed before the data they concern existed. The predictions:
**Under 15% of named businesses would be running Magento.** My frame was Magento stores from the top of Tranco; the businesses an engine names for a bay-window blind are not that.
**No signal would separate the groups by more than 15 percentage points.** My reasoning was my own baseline: JSON-LD `Product` sits at 10% and `llms.txt` at 11% across 762 Magento stores, and in a 376-store panel measured twice, not one store added product markup. A market where almost nobody does the thing cannot show much difference between those who do and those who do not.
**I would be wrong if any of the four differed by 20 points or more with the named group higher.**
Those are two different thresholds and it matters which is which. The 15 points was my expectation. The 20 points with the named group higher was the pre-registered failure criterion, written that way because the study exists to test whether these signals help, and a difference in the other direction would not answer that question.
And, in the document: *a null result is a result and gets published as one.*
## How the groups were built
Cases and controls both come out of the same corpus: every business in either group was named in at least one answer. The grouping variable is mention frequency - cases were named repeatedly, controls exactly once.
- **Head excluded first:** anything named in 53 or more of the 264 answers in that arm - 20%. In the generic arm that removes Amazon, Etsy, Wayfair, Target and Home Depot; in the context arm, Amazon and Etsy.
- **Cases:** a total of three or more mentions across the two runs combined, *and* present in both of them. The presence rule matters: of the businesses named exactly once in the first run, only 42% were named at all in the repeat.
- **Controls:** a combined total of exactly one mention across the two runs.
- Both counts are aggregates over the pair of runs, not per-run figures.
Then the losses, which are large and which I would rather state than bury:
| Roster rows | 669 |
| No resolvable domain, so unscannable | -186 |
| Dropped: resolved domain belongs to a different company | -3 |
| Excluded: marketplaces and listing surfaces (list of 14 hosts, 12 of them present here) | -12 |
| Duplicate rows collapsed onto a domain already counted | -10 |
| **Unique domains analysed** | **458** |
| Of those, scanned successfully | 455 |
Group sizes: **58 cases against 196 controls** in the generic arm, **53 against 139** in the context arm.
That leaves most of the 455 unaccounted for, so here is where they all go. **Each column independently accounts for all 455 scanned domains. Do not add the Generic and Context columns together.** A business can be a case in one arm and neither in the other.
| Of the 455 scanned domains | Generic | Context |
| Cases: 3+ across both runs, present in both | 58 | 53 |
| Controls: exactly 1 across both runs | 196 | 139 |
| Named exactly twice - between the two definitions | 86 | 90 |
| Never named in this arm at all | 113 | 172 |
| 3+ but absent from one of the runs | 2 | 1 |
| **Total** | **455** | **455** |
**The case and control counts are arm-specific samples from the same 455-domain universe. They are not mutually exclusive subsets and must not be added across arms.** The universe is the union of businesses appearing in either arm, so "never named in this arm" means named only in the other one, not absent from the study.
Nothing is left unaccounted for in this 455-domain table. The businesses named exactly twice fall between two definitions that were fixed before the data existed, and moving either threshold to collect them would be choosing a group after seeing the answers.
## The result
P-values are two-sided Fisher exact tests on the 2×2 table for each signal. Generic arm; percentages are of the stores where the signal was observable. The two schema signals need a product page, and the scanner found one for only 10 of 55 cases and 46 of 181 controls here, and 13 of 52 cases and 33 of 131 controls in the context arm.
| Signal | Cases | Controls | Diff | p |
| Blocks an AI crawler | 1/55 (2%) | 7/181 (4%) | -2.0 | .685 |
| Serves `llms.txt` | 10/55 (18%) | 61/181 (34%) | **-15.5** | .030 |
| JSON-LD `Product` | 3/10 (30%) | 15/46 (33%) | -2.6 | 1.000 |
| `offers.availability` | 3/10 (30%) | 13/46 (28%) | +1.7 | 1.000 |
Context arm.
| Signal | Cases | Controls | Diff | p |
| Blocks an AI crawler | 0/52 (0%) | 7/131 (5%) | -5.3 | .194 |
| Serves `llms.txt` | 10/52 (19%) | 48/131 (37%) | **-17.4** | .023 |
| JSON-LD `Product` | 4/13 (31%) | 8/33 (24%) | +6.5 | .717 |
| `offers.availability` | 4/13 (31%) | 4/33 (12%) | +18.6 | .196 |
Pooled across the two arms - a case if it clears the threshold in either arm, a control if its higher arm total is one - 81 cases against 250 controls. This is the cut named in the amendment, and it is a union-of-arms classification rather than a conventional pooled estimate: a business enters the case group on its better arm, which is a selection effect worth naming.
| Signal | Cases | Controls | Diff | p |
| Blocks an AI crawler | 1/78 (1%) | 11/232 (5%) | -3.5 | .307 |
| Serves `llms.txt` | 16/78 (21%) | 83/232 (36%) | **-15.3** | .012 |
| JSON-LD `Product` | 5/18 (28%) | 16/53 (30%) | -2.4 | 1.000 |
| `offers.availability` | 5/18 (28%) | 13/53 (25%) | +3.2 | .763 |
**The refutation condition was not met in the primary analysis.** No signal differs by 20 points or more with the named group higher, in either arm or in the pooled cut. A separate runA-only check specified in the sealed plan did produce one such result; it is reported below because the rule was pre-specified, and its four-store case cell makes it uninterpretable. On the question the study set out to answer - do these four signals separate repeatedly named businesses from other businesses in the same named-business corpus that were named once - this study found no measurable evidence that they do.
**Magento:** the scanner classified 13 of the 455 successfully scanned domains as Magento - 2.9%, against the under-15% I specified before the analysis. Useful context, and worth stating plainly: the shops an assistant reaches for a specific home decor purchase are overwhelmingly not on the platform I build for. It is not an estimate of Magento's share of AI-visible commerce generally; this is one category, three engines, two days.
## Where I was wrong
**The 15-point expectation failed.** I wrote that no signal would separate the groups by more than 15 points. `llms.txt` separated them by 15.5, 17.4 and 15.3 across the three cuts, with p between .012 and .030. The refutation condition survived because it specified a direction and this went the other way - but the expectation as written did not, and I am not going to pretend the direction clause was foresight.
**And in the runA-only cut, the refutation condition was nominally met.** I kept the analysis as originally registered - one run, threshold three - so it could be checked against the sealed document. In that cut `offers.availability` differs by +22.5 points with cases higher, which is exactly the number I said would mean I was wrong.
It is not interpretable as evidence of an effect. The case group there is four stores with an observable product page. Two of four against eleven of forty, p = .570. I am reporting it because it is in the document I sealed, and a refutation condition you quietly drop when it fires on n=4 is not a refutation condition. But no one should read anything into it, including me.
## The one number that went the other way
[content truncated]
- [376 Magento stores, measured twice: 94% did not change](https://angeo.dev/magento-ai-signals-two-scans/): The same 376 Magento stores scanned in July and August 2026. Almostnothing moved: no store added product markup, and every store thatedited its AI-crawler rules edited several at once.
In July I scanned a set of live Magento storefronts for four signals that affect how legible a store is to an AI assistant. In August I scanned a larger set built the same way. 376 stores appear in both runs and answered both times. Two things came out of pairing them: the signals barely moved at all, and where crawler rules did move, no store changed its mind about one crawler - it changed several at once, every time.
## Key findings
- **94%** of the 376 stores showed no change in any measured signal
- **Zero** stores added JSON-LD `Product` markup between the runs
- **9 of 9** stores that edited an AI-crawler rule edited two or more agents at once
- **12%** of stores had a different product page sampled on the second visit - enough to manufacture changes that never happened
## Why measure the same stores instead of a new sample
Two aggregate percentages moving from 13% to 15% tells you very little. The same shift is produced by six stores improving, by sixty improving while fifty-four regress, or by a slightly different sample. The only way to tell those apart is to hold the stores fixed and look at each one.
462 domains were scanned in July and 770 in August, both drawn from the [Tranco](https://tranco-list.eu/) list. 382 domains are in both files, and **376 returned a usable result in both runs**. That set of 376 is the panel, and everything below is about them.
A store that answered in one run and not the other is excluded. Not observing a signal is not the same as observing its absence, and treating a timeout as a missing `llms.txt` would quietly inflate every number here.
## Finding 1 - 94% of the panel did not change at all
**354 of the 376 stores showed no change in any of the signals or crawler rules measured.** Twenty-two stores changed something.
Stores measured in both runs, by whether any measured signal or crawler rule changed (n = 376).
That is a claim about four checks and eight crawler rules, not about the sites. A store can have replaced its theme, its catalogue and its hosting in between and still sit in that 354.
| Signal | July | August | Gained | Lost |
| Serves `llms.txt` | 50 (13%) | 55 (15%) | 6 | 1 |
| Blocks an AI crawler | 40 (11%) | 41 (11%) | 3 | 2 |
| JSON-LD `Product` * | 19 (11%) | 18 (10%) | **0** | 1 |
| `offers.availability` * | 16 (9%) | 15 (9%) | **0** | 1 |
* over the 173-store sub-panel explained in the next section, not the full 376.
`llms.txt` is the only signal with a net directional movement in this panel: six stores added it, one dropped it. Six out of 376 is not a trend, and I have not tested whether it is distinguishable from chance. It is simply the only column where the two directions are not roughly balanced.
## Finding 2 - the sampling catch, which changed one of the answers
The two schema signals depend on which product page the scanner happened to sample. It finds one by following a candidate product link from the homepage - a link whose URL or text matches common product-path patterns - and that heuristic does not always land on the same page twice.
Of the 196 stores where a product page was found in both runs, **23 - 12% - had a different page sampled the second time.** At one retailer the scanner tested a bicycle in July and a paperback in August. At another it tested a bicycle, then a delivery-information page.
Compared naively, both of those stores appear as *lost their JSON-LD markup*. Neither changed anything. The apparent loss is the scanner looking somewhere else.
So the schema figures above are computed only over the 173 stores where the identical URL was tested in both runs. On that stricter footing the JSON-LD result is cleaner and duller: **zero stores gained `Product` markup and one lost it**, and that one is an online course provider rather than a shop. The `offers.availability` figure moves with it, for the same store and no other. Microdata was unchanged in both directions - 26 stores before, 26 after.
If you do this kind of before-and-after work, pin the URL. Otherwise the sampling heuristic can manufacture changes that never happened, and at 12% here, often enough to swamp the real signal.
## Finding 3 - nobody changed their mind about one crawler
Each store's `robots.txt` was checked against eight AI crawlers: GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-SearchBot, Claude-User, PerplexityBot and Google-Extended. A rule counts whether it names the agent or the agent inherits it from a wildcard group.
Nine stores in the panel changed at least one of those rules between the runs. This is how many agents each of them moved:
The nine stores that edited an AI-crawler rule, by how many of the eight agents they moved at once. The bottom row is the finding.
**Not one of the nine changed a single agent on its own.** All nine moved GPTBot and ClaudeBot together. Four rewrote all eight rules at once. The smallest edit anyone made touched two agents.
In the [July write-up](https://angeo.dev/aeo-scan-case-study/) I noted that GPTBot and ClaudeBot are blocked at four times the rate of PerplexityBot and suggested this looked more inherited than decided. That was an inference from a cross-section, and a reader was entitled to answer that operators might simply hold different views of different crawlers.
The panel does not settle that, but it constrains it. **Over those sixteen days it shows no store making an independent, crawler-by-crawler change.** Every observed change touched several agents at once, which is more consistent with bundled policy edits - a pasted `robots.txt` snippet, a plugin updating its bot list, a security vendor changing a default - than with per-crawler judgements.
It does not rule per-crawler policy out. Nine stores over sixteen days is a thin base, and a store can hold a considered position without editing it in the window I happened to watch. What it does mean is that anyone arguing these are deliberate per-crawler decisions now has to account for nobody making one.
## What this is good for
A baseline that does not move is worth more than a baseline that does.
The next study in this series asks whether businesses carrying these signals are named more often by AI assistants than comparable businesses without them. That question has an obvious objection: stores change, assistants change, and any difference you find might be drift.
This measurement puts a number on that. Across the panel, 94% of stores showed no change in any measured signal, and the schema signals moved in no store at all where the comparison was clean. Whatever a visibility measurement turns up, large-scale reconfiguration of these particular signals is unlikely to be the explanation.
## What this does not show
**The two samples overlap, so this is not an independent replication.** 382 of the 462 July domains are in the August frame. The stronger evidence of measurement stability is not that the two runs' aggregate percentages agree - it is that 354 individual stores returned identical results in both.
**The window is short.** Sixteen days. A market that looks frozen over two weeks may well move over a year, and "nothing changed" is a much weaker claim at this timescale than it would be at that one.
**This is not a representative sample of Magento stores.** Both frames are drawn from the top of Tranco, so the sample is biased toward more prominent sites. Small independent stores may behave differently - and they are also the ones with the most to gain from being findable.
**Each run is a single observation of a live site.** A store that was rate-limited, served from a CDN edge, or rendering its structured data client-side can look emptier than it is. Twelve stores in the panel encountered rate limiting during the August run; they still returned a usable result and are included rather than dropped, so their values are less reliable than the rest.
## Method and reproduction
The July scan ran on 24 July 2026 and the August scan on 9 August 2026, the latter over a frame drawn from [Tranco](https://tranco-list.eu/) list **ZJGPG**, top 200,000 domains. Both runs, the domain-level comparison, the list IDs, the exclusion file and the classification change log are published.
The scanner identifies itself in every request, obeys `robots.txt` including `Crawl-delay`, waits at least two seconds between requests to the same host, keeps no page content, and can be blocked in two lines. The [crawler policy](https://angeo.dev/magento-ai-visibility-statistics/) has the details, including why no individual store is named in this article.
Previous instalment: [the July baseline across 462 stores](https://angeo.dev/aeo-scan-case-study/).
- [AngeoBenchmarkBot crawler policy](https://angeo.dev/magento-ai-visibility-statistics/): A low-rate research crawler measuring how Magento 2 stores are set up for AIassistants. What it requests, what is stored, and how to block it.
**AngeoBenchmarkBot** is a low-rate research crawler for an open
study of how Magento 2 stores are set up for AI assistants - the
crawlers and answer engines behind ChatGPT, Claude, Perplexity and Google's
AI features. It is run by Ievgenii Gryshkun
([angeo.dev](https://angeo.dev/)),
an independent Magento 2 solution architect based in the Netherlands.
**In short.** It reads a handful of publicly served pages,
obeys `robots.txt`, waits at least two seconds between requests,
never interacts with your store, keeps no page content, and publishes
aggregate figures only. If you found it in your access logs, nothing is
wrong.
It does not collect customer data, submit forms, create accounts, log in,
add products to a cart, follow checkout links, or request admin paths. It
does not build a mailing list, and nobody is contacted as a result of being
crawled.
The exact User-Agent string, for grepping your logs:
```
AngeoBenchmarkBot/1.0 (+https://angeo.dev/magento-ai-visibility-statistics/; research scan; contact info@angeo.dev)
```
## What it requests
Between two and six requests per site, spread over a few minutes. Then it
leaves and does not return until the next round of the study.
| Path | What is measured |
| `/` | Whether the site runs Magento 2, from public markup traces. The title, meta description and `html lang` are read to classify the shop by what it sells. |
| `/robots.txt` | Whether each of eight AI crawlers is allowed or disallowed: GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-SearchBot, Claude-User, PerplexityBot, Google-Extended. |
| `/llms.txt` | Whether the file exists, returns 200 and is not empty. The contents are not parsed, stored or analysed - only that boolean. |
| One product page, reached from a homepage link | Two booleans from JSON-LD: whether a `@type: Product` node exists, and whether any of its `offers` carries an `availability` value. Prices, SKUs, brands and images are not read or recorded. |
## How it behaves
- Reads `robots.txt` before anything else and obeys it, including `Crawl-delay`.
- Waits at least two seconds between requests to the same host.
- Honours `Retry-After` and backs off on `429` or `503`, then gives up rather than pushing.
- Reads at most the first few hundred kilobytes of a response.
- Runs single-threaded per host, from one machine.
## What is stored
One record per domain: the domain, its rank in the public source list, the
homepage title, description and language, whether the site was reachable,
the allow/disallow status of the eight crawlers above, the booleans in the
table, the URL of the single product page tested, and a timestamp.
**No page content is retained.** HTML is parsed in memory and
discarded; nothing is archived, cached or republished. No personal data is
collected - the crawler reads shop pages, not customers, and records no IP
addresses of anyone. Records are kept while the study runs and for twelve
months after publication so the figures can be checked, then deleted. They
are used for this benchmark only: not sold, not shared, not used for
prospecting.
## What gets published
Aggregate numbers only - for example, *"X per cent of the stores measured
publish JSON-LD product data"*. No individual store is named, ranked,
scored or identified in any publication without the written consent of its
owner.
The sample frame comes from the public
[Tranco](https://tranco-list.eu/)
list. The list ID, the date, and any domains excluded from the frame are
published with the results, so the sample can be reconstructed and the work
checked independently.
## How to keep it out
Add this to your `robots.txt`:
```
User-agent: AngeoBenchmarkBot
Disallow: /
```
It is read and obeyed on the next visit. You can also email
[info@angeo.dev](mailto:info@angeo.dev)
with your domain and it will be excluded from the frame permanently - no
reason needed, no reply expected. Exclusion requests are honoured before the
results are compiled, not after.
## Contact
Questions, complaints, or a request to see the stored record for your own
domain:
[info@angeo.dev](mailto:info@angeo.dev).
A record is sent to whoever can demonstrate control of the domain, and
deleted on request.
A User-Agent string is a claim, not proof - anything can send one. If
something using this name is hitting you hard, or behaving differently from
what is described above, please send me a log excerpt. It is not mine, and I
would rather know.
Last updated: 8 August 2026.
- [Magento Product Descriptions in the Age of AI Search](https://angeo.dev/magento-product-descriptions-in-the-age-of-ai-search/): Generate Magento 2 product descriptions automatically using OpenAI, Claude, Gemini or Groq (free). Bulk CLI, cron, multi-store, Google Sheets. MIT license.
There's a shift happening in e-commerce search that most Magento store owners haven't noticed yet.
When a customer types *"best ergonomic office chair under €500"* into Google, they get a list of blue links. When they ask the same question to ChatGPT or Perplexity, they get a curated answer - with specific product recommendations, comparisons, and sometimes direct links to stores.
The stores that appear in those AI answers share one thing in common: rich, specific, well-structured product content. The stores that don't? Most of them have descriptions that look like this:
[image: Magento Product Descriptions in the Age of AI Search - AI-enriched ecommerce content improving visibility in ChatGPT, Perplexity, and AI search systems]
## The content gap that's costing you AI visibility
Here's a real-world example of what the problem looks like:
Supplier description
```
Bluetooth headphones with ANC.
Black color. USB-C charging.
40h battery.
```
AI-generated description
```
The QuietSound X200 wireless headphones
combine adaptive active noise cancellation
with 40-hour battery life, making them the
ideal companion for daily commuting,
open-plan office work, and long-haul flights.
The dual-microphone array filters ambient
noise at up to 35dB, while USB-C fast
charging delivers 5 hours of playback
from a 15-minute charge.
```
The difference isn't cosmetic. The second description gives the AI model use cases, specific features, differentiators, and purchase context - exactly what it needs to form a confident recommendation.
Here's what that looks like when a real query hits an AI assistant:
Simulated query - Perplexity
"best noise-cancelling headphones for commuting under €150"
Before
*Perplexity lists three competitor products with detailed use-case breakdowns. Your store is not mentioned.*
After
"The QuietSound X200 from [store] stands out for commuters - adaptive ANC at 35dB, 40-hour battery, and USB-C fast charge (5h from 15 min). Available under €150 with free delivery."
The enriched description gave the model specific, retrievable signals: use case, technical spec, battery claim, urgency detail, price context. The supplier description gave it nothing to work with. This is AI Engine Optimization in its most concrete form.
## Why manual AI workflows don't scale
At this point, some merchants think: *"I can just use ChatGPT and a CSV."*
You can - for 20 products. Here's why that breaks at scale:
| Manual ChatGPT + CSV | module-ai-description-updater |
| Copy/paste per product | Fully automated CLI + cron |
| No store scope awareness | Per store view, per language |
| No attribute targeting | description, short_desc, meta fields |
| No retry handling | Built-in error recovery |
| No logging | Full per-SKU audit trail |
| No provider switching | 4 providers, zero code changes |
| Manual Magento import | Native attribute save per store scope |
| No Google Sheets sync | Bidirectional integration |
A store with 5,000 SKUs across three language store views means 15,000 individual description fields. The manual approach doesn't survive contact with that reality. The module runs unattended overnight.
## How the processing pipeline works
For developers evaluating this module, here's the full per-product per-store-view flow:
1.
Load batch
N products from catalogue. Filter: only missing descriptions, or all - configurable.
2.
Resolve store scope
Iterate active non-admin store views. Inject `{{store_name}}` into prompt.
3.
Build prompt
System role + user prompt template with product name, SKU, store name placeholders.
4.
Call AI provider
OpenAI / Claude / Gemini / Groq. Token limit, timeout, and retry count all configurable.
5.
Validate response
Non-empty check, minimum word count, HTML structure check.
6.
Save attributes
Writes `description`, `short_description`, and optional meta fields to the correct store view scope.
7.
Log result
Status (updated / dry_run / skipped / error), provider, tokens, latency → `var/log/angeo_ai_description_updater.log`
**Architecture notes:** synchronous CLI (no queue dependency), cron-safe batch sizing, dry-run mode writes nothing to DB, store scope isolation prevents cross-contamination.
## Provider benchmark
Measured across a 100-product test batch (mixed categories, ~80 words output average):
| Provider | Model | Avg latency | Cost / 1,000 products | Quality |
| **Groq** | Llama 3.3 70B | ~1.8s | **Free** | Good |
| **Gemini** | 2.0 Flash | ~2.1s | Very low | Good |
| **Claude** | Haiku 4.5 | ~3.5s | Medium | Very good |
| **OpenAI** | GPT-4.1 Mini | ~4.2s | Low | Excellent |
**Recommendation:** start with Groq to validate quality at zero cost. Switch to GPT-4.1 Mini or Claude Haiku for production if your category needs higher output quality.
*Results vary by prompt complexity, product category, and provider region. Use these as rough starting points.*
## Prompt template: what the AI actually receives
Default templates - fully editable per store view in Admin → Stores → Configuration → Angeo AEO.
**System role:**
```
You are an expert e-commerce copywriter. Write clear, benefit-focused
product descriptions that help customers make confident purchasing decisions.
Use HTML formatting. Avoid generic marketing language.
```
**User prompt:**
```
Write a professional and SEO-friendly product description for
"{{product_name}}" (SKU: {{product_sku}}) for our {{store_name}} online store.
Include:
- Key features and technical specifications
- Primary use cases and who this product is for
- Key benefits (not just features)
- Compatibility or size information where relevant
Format using HTML paragraphs. 150-250 words.
Do not include a headline - start directly with the first paragraph.
```
Different store views can hold different templates - enabling language-appropriate tone for each market without code changes.
## Why this matters for AI Engine Optimization
AEO applies the same principles as technical SEO - but to AI retrieval systems instead of search crawlers. AI models weight several signals when deciding whether to recommend a store:
- **Specificity** - does the description describe *this* product, or generic filler?
- **Use case coverage** - are the purchase contexts named explicitly?
- **Semantic density** - enough signal for the model to form a confident answer?
- **Language match** - content in the language the user is asking in?
Thin descriptions fail all four. AI-generated descriptions - when prompted correctly - pass all four, because they're built from product context and written to be understood, not just indexed.
## Open-source architecture: no SaaS, no lock-in
- **Configurable prompts** - full control over what the AI writes
- **Extendable provider architecture** - add a new provider by implementing one interface
- **Developer-first** - CLI-first, full logging, dry-run, CI-safe
- **Magento-native** - attribute saving, store scope, cron via Magento infrastructure
- **No SaaS dependency** - your API keys, your data, your server
- **No per-seat pricing** - install on as many stores as you run
## Installation
```
composer require angeo/module-ai-description-updater
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento cache:flush
```
Requires PHP 8.2+ and Magento 2.4.x.
## Getting started in 5 minutes (free, no credit card)
**Step 1** - Get a free Groq API key at [console.groq.com](https://console.groq.com). No credit card. Key starts with `gsk_`.
**Step 2** - Configure: **Stores → Configuration → Angeo AEO → AI Description Updater**
- Enable Module → `Yes`
- Dry Run Mode → `Yes`
- AI Provider → `Groq`
- Groq API Key → paste `gsk_...`
- Generate Description → `Yes`
[image: Admin config panel - provider selection, prompt template editor, cron settings (Stores → Configuration → Angeo AEO → AI Description Updater)]
**Step 3** - Test on one product:
```
bin/magento angeo:ai-description:run --sku=YOUR-SKU --dry-run
tail -f var/log/angeo_ai_description_updater.log
```
Review output in the log. Tune prompt if needed. Disable dry-run when satisfied.
**Step 4** - Run at scale:
```
# All products, all store views
bin/magento angeo:ai-description:run
# Specific store only
bin/magento angeo:ai-description:run --store=2
```
[image: CLI run output - per-SKU status, provider, latency (bin/magento angeo:ai-description:run)]
**Step 5** - Automate: enable cron in config (`0 2 * * *`), set batch size, run unattended.
## What the module includes
| Feature | angeo/module-ai-description-updater |
| Price | **Free, MIT** |
| AI providers | OpenAI, Claude, Gemini, Groq (free) |
| CLI automation | ✓ |
| Cron scheduling | ✓ |
| Multi-store / multi-language | ✓ |
| Dry-run mode | ✓ |
| Configurable prompt templates | ✓ per store view |
| Google Sheets input / export | ✓ |
| Full per-SKU logging | ✓ |
| Self-hosted, no SaaS | ✓ |
| meta_title / meta_description | ✓ optional |
## Frequently asked questions
Does this module work with Magento 2 Open Source, or only Adobe Commerce?
+
The module is fully compatible with both Magento 2 Open Source (Community Edition) and Adobe Commerce (Enterprise Edition). It uses only standard Magento APIs - no Commerce-only dependencies. Requires PHP 8.2+ and Magento 2.4.x.
Is there a truly free option, or does every AI provider require a paid API key?
+
Groq is completely free - no credit card required, no billing setup. You create a free account at console.groq.com, generate an API key, and start generating descriptions immediately. Groq's free tier allows up to 14,400 requests per day, which covers even large catalogues when combined with cron scheduling. Google Gemini also has a free tier with daily limits. OpenAI and Anthropic Claude require paid API keys, but their per-request costs are very low for description generation.
Will the module overwrite existing product descriptions I've already written manually?
+
By default, the module is configurable to process only products where the description field is empty - skipping any product that already has content. You can also enable overwrite mode explicitly if you want to regenerate all descriptions. Before running at scale, always use `--dry-run` first: it generates content and writes it to the log without touching the database, so you can review output quality before committing.
How does multi-store and multi-language support work?
+
When you run the CLI command without a `--store` flag, the module iterates every active non-admin store view in sequence. For each store view, it resolves the `{{store_name}}` placeholder in your prompt template and saves the generated description to that store view's scope - not the global default. This means a store with English, German, and French views gets three separate AI-generated descriptions per product. Each store view can also have its own prompt template, so tone and language are fully customisable per market.
Can I control the tone and style of the generated descriptions?
+
Yes - both the system role prompt and the user prompt template are fully editable in the admin panel under Stores → Configuration → Angeo AEO → AI Description Updater. The system role sets the overall tone (e.g. "luxury brand copywriter", "technical B2B writer", "friendly consumer tone"). The user prompt controls what the model is asked to include. Different store views can have different prompt configurations, so your English store can have a different writing style than your German or French store.
How long does it take to generate descriptions for a large catalogue?
+
[content truncated]
- [The Future of eCommerce is Changing: How Artificial Intelligence and Agentic Commerce Protocol Are Transforming Online Shopping](https://angeo.dev/the-future-of-ecommerce-is-changing-how-artificial-intelligence-and-agentic-commerce-protocol-are-transforming-online-shopping/): How AI is changing ecommerce: product discovery moves into assistants, agents build carts, and protocols like ACP handle checkout. What merchants face.
The eCommerce industry is going through significant changes. New technologies, particularly **artificial intelligence** (AI) and innovative approaches like **Agentic Commerce Protocol** (ACP), are dramatically changing the customer experience and business processes in online retail. These technologies enable more personalized experiences for customers, automate many aspects of trade, and predict demand with unprecedented accuracy.
**How Artificial Intelligence is Changing the Customer Experience**
**1. Personalized Recommendations: Accuracy at a New Level**
**Artificial Intelligence** is actively used to create personalized product recommendations in online stores. Machine learning systems analyze customer behavior, previous purchases, and other factors to offer products that might interest them. This increases **conversion rates** and customer satisfaction.
**Example:** Platforms like **Amazon** use recommendation systems based on customer behavior to suggest products that best match their preferences.
**2. Chatbots and Virtual Assistants: 24/7 Support**
Intelligent AI-powered **chatbots** have become an essential tool for providing high-quality customer service. They can search for products, offer advice, and give personalized recommendations, all while working around the clock.
**Example:** **Sephora** uses a chatbot to offer personalized recommendations for cosmetics based on each user's preferences.
**3. Visual Search and Image Recognition**
**AI-powered visual search** technologies allow customers to search for products using images instead of just text queries. This greatly simplifies the shopping process and improves search accuracy.
**Example:** **Pinterest** and **Google** already use visual search, enabling users to find similar products based on images.
**How AI Optimizes Business Processes in eCommerce**
**1. Demand Forecasting and Inventory Management**
AI helps predict product demand with high accuracy, reducing storage costs and optimizing inventory management. It also helps avoid stockouts or overstock situations.
**Example:** **Walmart** uses AI for demand forecasting and automatically adjusting warehouse inventory, which significantly reduces logistics costs.
**2. Automated Marketing Campaigns**
AI allows businesses to automate marketing strategies, including creating personalized advertising campaigns. By analyzing large volumes of customer data, platforms can tailor ads to the products most relevant to the individual.
**Example:** Platforms like **Google Ads** and **Facebook Ads** use AI algorithms to automatically adjust advertising campaigns to achieve the best results.
**Implementing the Agentic Commerce Protocol (ACP): A New Stage in eCommerce Development**
**Agentic Commerce Protocol** is an innovative protocol that allows flexible, autonomous management of online retail through intelligent agents. Implementing ACP enables the creation of autonomous agent systems that can make purchases, predict demand, and interact with users independently.
**1. Autonomous Agents for Shopping**
ACP allows the creation of autonomous agents that can analyze customer behavior and make purchases based on the data collected. This significantly reduces the need for customer involvement and speeds up transaction processing.
**2. Personalized Agent Interactions**
Intelligent agents using ACP can tailor their actions to each individual customer, providing personalized recommendations and interactions in real-time.
**3. Integration with Voice Assistants and Mobile Platforms**
ACP integrates with various voice assistants like **Amazon Alexa** and **Google Assistant**, enabling users to make purchases via voice commands. This opens up new possibilities for integration with mobile platforms and enhances shopping convenience.
**4. Advanced Analytics and Prediction**
By using ACP, businesses can gain deeper insights into customer behavior and accurately forecast demand, which helps them quickly adapt sales and marketing strategies.
**Why Should You Implement AI and ACP in Your Online Store?**
1. **Process Automation:**
Implementing AI and ACP helps automate many business processes, such as transaction handling, demand forecasting, and marketing campaign creation.
2. **Personalized Customer Interaction:**
AI and ACP enable you to create personalized offers for each customer, improving satisfaction and boosting conversion rates.
3. **Intelligent Inventory Management:**
These technologies help forecast demand accurately, allowing you to optimize inventory management and reduce logistics costs.
4. **Increased Sales:**
With high levels of personalization and automation, your online store can provide a better shopping experience for customers and significantly increase sales.
**Conclusion**
**Artificial Intelligence** and the **Agentic Commerce Protocol** are technologies that are already changing the face of online retail. They allow for more personalized customer experiences, automate business processes, and improve the effectiveness of eCommerce. If you want to stay competitive and maximize your business potential, integrating these technologies into your online store is a must.
# The Future of eCommerce: How AI and Agentic Commerce Protocol Are Transforming Online Shopping
**Agentic commerce** is redefining how consumers shop online. Instead of browsing and manually checking out, AI agents can now search, compare, and complete purchases on behalf of users. Powered by the **Agentic Commerce Protocol (ACP)**, this new model is turning conversations into transactions.
## What Is Agentic Commerce?
Agentic commerce refers to AI systems that don't just recommend products - they execute transactions autonomously within user-defined limits.
- Interpret natural language intent
- Search across retailers
- Compare pricing and constraints
- Complete secure checkout
**Example:** "Find me a lightweight camping tent under €150 and order it with free shipping."
An AI agent can handle the entire flow - from search to payment.
## How Agentic Commerce Works
Here is a simplified workflow:
The **Agentic Commerce Protocol (ACP)** ensures secure, permission-based transactions between AI systems, merchants, and payment providers.
## Real-World Adoption
### 1. ChatGPT Instant Checkout
OpenAI introduced *Instant Checkout*, allowing users to purchase directly within ChatGPT conversations without redirects.
### 2. Retail & Payment Integrations
Partnerships with major retailers and payment platforms are enabling conversational checkout experiences across ecosystems.
### 3. Grocery & Marketplace Expansion
AI-assisted grocery shopping and multi-merchant cart support are expanding agentic commerce into everyday purchasing.
## Benefits of Agentic Commerce
### For Consumers
- Faster shopping via conversation
- Personalized recommendations
- Reduced friction
- Integrated payment methods
### For Merchants
- New AI-driven sales channels
- Higher conversion rates
- Access to structured shopping intent
- Automated workflows
## Challenges & Risks
**Data Readiness:** AI agents require structured, machine-readable product data.
**Authorization & Trust:** Clear permission systems are required to prevent unintended purchases.
**Privacy:** AI systems must handle personal data with transparent consent and governance.
## How to Prepare for Agentic Commerce
### For Merchants
1. Structure product data (SKU, pricing, inventory).
2. Implement ACP-compatible APIs.
3. Ensure secure checkout endpoints.
4. Monitor AI-driven transactions.
### For Developers
- Build agent-ready APIs.
- Simulate AI purchase flows.
- Enable logging and audit trails.
## The Future of Online Shopping
By 2030, a significant percentage of ecommerce transactions may be initiated by AI agents. Businesses that adapt early to structured commerce protocols and conversational checkout systems will have a competitive advantage.
## Final Thoughts
AI is no longer just assisting shopping - it is executing it. With the Agentic Commerce Protocol enabling secure interoperability, ecommerce is becoming autonomous, conversational, and frictionless.
- [SEO vs AEO: How Search Optimization and AI-Enhanced Optimization Are Changing Digital Marketing](https://angeo.dev/seo-vs-aeo-how-search-optimization-and-ai-enhanced-optimization-are-changing-digital-marketing/): SEO vs AEO: search engines rank links, answer engines pick one recommendation. What actually differs in signals, measurement and content strategy.
SEO vs AEO: How Search Optimization and AI-Enhanced Optimization Are Changing Digital Marketing Learn the difference between SEO and AEO (AI-Enhanced Optimization) and how AI is transforming digital marketing, content optimization, and ecommerce strategies. [image: AI and SEO in Ecommerce Banner]In the modern digital world, where search traffic drives a large portion of website visits, SEO and AEO (AI-Enhanced Optimization) are becoming essential aspects of marketing. The emergence of AI and large language models (LLM) has changed the rules of the game. This article explains the difference between SEO and AEO and explores how AI is reshaping digital marketing and whether businesses should adopt it for optimization.
## What Are SEO and AEO?
[image: SEO vs AEO workflow diagram]**SEO (Search Engine Optimization)** is the process of designing website content and structure to improve visibility in search engines. This includes using keywords, optimizing titles and meta descriptions, creating high-quality content, infographics, and other technical aspects.
**AEO (AI-Enhanced Optimization)** uses artificial intelligence to automate marketing optimization, content creation, and customer interactions. AI can analyze large datasets, identify trends, suggest optimizations, and predict the effectiveness of different strategies.
## Key Differences Between SEO and AEO
### 1. Time and Cost
**SEO:** Manual process requiring significant planning, analysis, and site adjustments.
**AEO:** AI automates many parts of the optimization process, significantly reducing time and costs.
### 2. Handling Large Data Volumes
**SEO:** Traditional SEO can struggle with processing large datasets.
**AEO:** AI can quickly analyze massive amounts of data and discover trends invisible to humans.
### 3. Predictive Capabilities
**SEO:** Forecasting results requires extensive analysis.
**AEO:** AI predicts outcomes accurately based on large datasets, aiding decision-making.
### 4. User-Centric Optimization
**SEO:** Focused on keywords and search ranking improvement.
**AEO:** AI analyzes user behavior, interests, and preferences to provide personalized and effective optimizations.
## Impact on Digital Marketing
### Increased Efficiency
AEO identifies problems quickly and finds optimal solutions to improve marketing performance, lowering ad costs and increasing ROI.
### Enhanced Personalization
AI provides accurate recommendations for content and marketing campaigns, tailoring strategies for each user based on behavioral data.
### Automated Testing
AEO automates many phases of testing, enabling faster insights and site or campaign adjustments.
### Analytics and Forecasting
AI gives marketers powerful data analysis capabilities, including sales forecasting, trend monitoring, and data-driven decisions.
## AI Integration Examples in SEO / AEO
Developers and marketers can integrate AI into platforms like Magento 2 using open-source modules from Packagist:
- Automated product content generation
- AI product feeds for marketplaces
- Enhanced customer interactions
Thees modules help AI systems like ChatGPT, Claude, Gemini, and other large language models (LLMs) understand your site structure and content for better indexing, AI recommendations, and enhanced visibility.
The **LLMs.txt** module helps generate structured, AI-friendly content that can be used by modern AI systems and agents.
👉 More information: [https://packagist.org/packages/angeo/module-llms-txt](https://packagist.org/packages/angeo/module-llms-txt)
## Summary
- SEO provides the foundation for site visibility.
- AEO adds speed, analytics, and personalization.
- Combining SEO and AEO allows maximum results in digital marketing.
- AI helps process large datasets and deliver accurate answers and recommendations to users.
Start integrating AI into your marketing strategies today using modules and tools that automate processes, enhance personalization, and optimize content for AI-driven search.
### What is the difference between SEO and AEO?
SEO focuses on ranking in search engines, while AEO is designed for AI-driven search and answer engines.
### Is AEO necessary for ecommerce?
Yes, especially if your store integrates with AI platforms or chat assistants to provide direct answers to users.
### How to combine SEO and AEO?
Optimize content for both traditional keywords (SEO) and AI-ready formats like FAQ schema, structured data, and natural language answers (AEO).
Ready to go further? See how stores become invisible to AI and what the new commerce infrastructure looks like: [Why Your Store Is Invisible to ChatGPT - and How to Fix It →](https://angeo.dev/why-your-store-is-invisible-to-chatgpt-and-how-to-fix-it/)
[image: AI-Enhanced Optimization Banner]
- [How LLMs and TXT Files Help eCommerce Businesses Attract More Clients](https://angeo.dev/how-llms-and-txt-files-help-ecommerce-businesses-attract-more-clients/): llms.txt for ecommerce is a plain-text content map for AI assistants. What it contains, which engines use it, and how it fits alongside your sitemap.
In the competitive world of **eCommerce**, attracting and converting potential customers is more challenging than ever. If you run a **Magento 2** store, integrating **LLMs (Large Language Models)** with **TXT/JSONL-based content workflows** can significantly improve your lead generation, SEO visibility, and customer engagement.
You can find a ready-to-use [LLMs.txt Magento module](https://packagist.org/packages/angeo/module-llms-txt) on Packagist.
[image: LLMs and TXT files integration for eCommerce lead generation in Magento 2]
AI-driven content automation for Magento 2 eCommerce growth
## Why Lead Generation in eCommerce Requires Smarter Content
Modern customers expect personalized experiences, fast answers, and relevant product recommendations. Search engines reward websites that publish unique, high-quality, and optimized content.
By combining LLMs with structured JSONL/TXT data exported from Magento 2, stores can automate content production while improving organic traffic and conversion rates.
## How LLMs Drive More Potential Clients to Your Magento 2 Store
- **SEO-optimized product descriptions** that rank higher in search engines
- **Automated blog and landing page content** targeting commercial search intent
- **Personalized email marketing** campaigns
- **Customer behavior analysis** for better targeting
Instead of manually writing hundreds of product descriptions, LLMs can generate keyword-rich, conversion-focused content in minutes using JSONL feeds exported from your Magento 2 catalog.
## Why JSONL/TXT Files Make Automation Scalable
JSONL files provide a simple and universal way to store and process large volumes of structured content data. In Magento 2, these files can be used to:
- Export product specifications and metadata
- Store SEO templates and product descriptions
- Feed structured prompts into AI models for content generation
- Process reviews or categories in bulk
This makes your content pipeline efficient, scalable, and ready for growth.
## Practical Lead Generation Strategies Using AI in Magento 2
### 1. Generate SEO Landing Pages at Scale
Using your JSONL product feed, you can automatically generate optimized landing pages for high-intent keywords like "buy online", "best price", or "fast delivery". This increases visibility and attracts ready-to-buy visitors.
### 2. Automate Email Funnels
Feed structured product and category data into AI models to generate personalized abandoned cart emails, product recommendations, and promotional offers that convert visitors into paying customers.
### 3. Analyze Customer Reviews and Product Data
By ingesting product, category, and brand JSONL files into an AI system, you can identify common objections, optimize descriptions, and improve messaging - boosting trust and conversions.
## Example JSONL Feed for AI Ingestion
Here's a sample product entry from your Magento 2 AI feed:
```
{
"id": "SKU-123",
"type": "product",
"store": "default",
"locale": "en_US",
"title": "Apple iPhone 14 Pro",
"content": "Experience the latest iPhone 14 Pro with stunning display, advanced camera, and unmatched performance.",
"metadata": {
"price": 999,
"currency": "USD",
"categories": ["Electronics", "Phones"],
"brand": "Apple",
"image": "https://example.com/media/catalog/product/i/m/image.jpg",
"last_updated": "2026-03-01 12:00:00",
"stock": true
}
}
```
## LLM Workflow with Magento JSONL
The process works like this:
- **Step 1:** Magento 2 generates AI feeds (`ai_feed_default.jsonl`, `ai_categories_default.jsonl`, `ai_brands_default.jsonl`).
- **Step 2:** The JSONL files are ingested into an AI system (OpenAI, LangChain, or Claude).
- **Step 3:** LLM processes the data to generate product descriptions, landing pages, email content, or reports.
- **Step 4:** Generated content is automatically deployed to Magento 2 or marketing systems.
## AI Query Example
You can query your AI knowledge base directly. Example:
```
User Query → AI searches JSONL feed → Outputs relevant products:
Query: "List all Apple smartphones under $1000 in stock"
Result:
1. Apple iPhone 13 - $799
2. Apple iPhone SE - $429
```
## Business Benefits for eCommerce Owners
- Automated SEO-optimized product content
- Increased organic traffic and visibility
- Reduced content production costs
- Faster campaign execution without growing your team
- Actionable insights from customer reviews and product performance
## Conclusion: Turn AI into a Client Acquisition Engine
For Magento 2 store owners, combining LLMs with structured JSONL/TXT feeds is a strategic growth decision. It helps attract qualified traffic, engage potential customers, and convert them into loyal buyers automatically.
If you have any questions, feel free to contact us at
[info@angeo.dev](mailto:info@angeo.dev).
- [How to Prepare a Magento 2 Store for AI Search and Increase Ecommerce Sales](https://angeo.dev/how-to-prepare-a-magento-2-store-for-ai-search-and-increase-ecommerce-sales/): Prepare Magento 2 for AI search: the crawler access, structured data and product content that decide whether AI assistants recommend your store.
[image: Magento 2 AI search integration for ecommerce stores]
Product discovery is changing. Instead of relying solely on traditional search engines, more users are asking AI assistants to recommend products directly. For online stores, this creates a new source of traffic: **AI recommendation traffic**.
Typical AI queries include:
- "Suggest a gift under 40€"
- "Find a minimalist accessory for everyday use"
- "What is a good affordable present?"
AI systems analyze multiple sources and recommend specific products and stores. If your catalog is structured and accessible, your products can appear directly in these AI recommendations.
## Why This Matters for Ecommerce Businesses
Traditional SEO works like this:
1. User searches in Google
2. Search engine returns websites
3. User clicks one result
AI search works differently:
1. User asks a question
2. AI analyzes product data
3. AI recommends products with direct links
Stores that provide structured product data have a much higher chance of being recommended.
## The Problem with Most Magento 2 Stores
Many Magento 2 stores are optimized for SEO but not for AI systems. Common issues include:
- Product data only available as HTML pages
- Complex JavaScript storefronts
- No structured product API
- No AI-friendly data formats
AI systems work best when product catalogs are available as structured data, enabling faster indexing and more accurate recommendations.
## AI-Ready Catalog Endpoints for Magento 2
One practical solution is exposing your product catalog via simple AI endpoints:
```
/ai/store
/ai/products
/ai/categories
/ai/search
/ai/catalog.md
/ai/sitemap.json
```
These endpoints allow AI systems to:
- Retrieve store information
- Access the full product catalog
- Understand category structures
- Perform searches on products
## Example Product Catalog Endpoint
Endpoint:
```
/ai/products
```
Example JSON response:
```
{
"products": [
{
"name": "Minimalist Silver Ring",
"sku": "RING-001",
"price": 39.95,
"currency": "EUR",
"category": "rings",
"url": "https://store.com/product/ring-001"
}
]
}
```
## Markdown Product Catalog
Another effective format is Markdown:
```
/ai/catalog.md
```
Example content:
```
## Minimalist Silver Ring
SKU: RING-001
Price: 39.95 EUR
Category: Rings
URL: https://store.com/product/ring-001
```
Markdown is easily parsed by language models and AI crawlers.
## Semantic Product Search
Semantic search goes beyond keyword matching and understands the *meaning* of queries. Example:
| User Query | Relevant Product |
| minimalist gift | simple ring |
| daily accessory | bracelet |
| cheap elegant jewelry | classic ring |
Endpoint example:
```
/ai/semantic-search?q=minimalist+gift
```
## AI Product Recommendations
Another useful endpoint:
```
/ai/recommendations?q=minimalist+gift
```
Example response:
```
{
"products": [
{
"name": "Minimal Silver Ring",
"price": 39.95,
"url": "https://store.com/product/ring-001"
},
{
"name": "Simple Bracelet",
"price": 29.95,
"url": "https://store.com/product/bracelet-002"
}
]
}
```
## Magento Marketplace & Large Catalog Use Cases
### Large Catalog Store
A store with thousands of products benefits from AI search because:
- AI can analyze the entire catalog
- Products can appear in AI recommendations
- Internal search quality improves
### Gift Marketplace
Users searching for gift ideas benefit when AI can recommend products directly from the catalog:
- Gift under 30€
- Minimalist accessory
- Small birthday present
### Multi-vendor Marketplace
Large multi-vendor marketplaces can use AI endpoints to:
- Analyze the catalog
- Find relevant products
- Recommend items to users
## Business Benefits
- New AI-driven traffic source
- Better product discovery
- Improved internal search
- Preparation for AI shopping agents
## Implementation Plan for Magento 2
1. Create AI endpoints
2. Expose the product catalog as JSON
3. Add a Markdown catalog
4. Create an AI sitemap
5. Implement semantic search
## Conclusion
AI search is becoming an important discovery channel for ecommerce. Magento 2 stores that make their catalogs AI-friendly gain a competitive advantage and can attract traffic directly through AI recommendations.
[image: AI product recommendations for online stores]
AI product recommendations in Magento 2
- [Agentic Commerce Protocol: The Next Evolution in E-Commerce](https://angeo.dev/agentic-commerce-protocol-the-next-evolution-in-e-commerce/): What is agentic commerce? AI agents that discover products, build carts and complete purchases directly - and what it changes for ecommerce stores.
**Turning conversations into conversions - and redefining how merchants connect with customers.**
E-commerce is shifting fast. Customers no longer limit their shopping to web stores or mobile apps - they chat with AI assistants, ask questions through smart devices, and expect instant, contextual shopping experiences.
**Enter Agentic Commerce Protocol** (ACP) - a new OpenAI-led framework that allows AI agents, chat interfaces, and voice assistants to handle product discovery and purchasing directly, while merchants retain control of payments, fulfillment, and customer data.
For Magento 2 developers, this marks a significant opportunity to extend your store's reach beyond screens - bringing your catalog and checkout into the AI-driven ecosystem.
💡 Why ACP Matters for Developers and Merchants
As digital interactions become more conversational, traditional checkout flows risk becoming outdated. ACP bridges that gap with four key advantages:
Massive reach - Surface your catalog in AI-powered environments like ChatGPT and third-party assistants.
Zero rebuilds - Integrate seamlessly with your existing Magento stack - catalog, order management, and payment systems remain intact.
Cross-platform flexibility - Works across devices, channels, and payment methods.
Merchant control - You own the customer relationship, fulfillment, and revenue - not the AI intermediary.
In short: ACP adds a new conversational sales channel to Magento without disrupting your current operations.
https://www.youtube.com/watch?v=C6qcZdtIv54
🧩 Core Components of ACP Integration
**1. Product Feed**
Your product feed is the foundation of ACP. It enables agents to discover and understand your product catalog - pricing, inventory, variants, and metadata - in real time.
Map your Magento 2 catalog into ACP's Product Feed Spec.
Automate updates through a scheduled cron or web service to keep inventory and pricing in sync.
Validate fields: product identifiers, availability, variants, and localized descriptions.
Ready-to-install starting point: For Magento 2 shops, there's a module you can install right now:
[angeo/module‑openai‑product‑feed](https://packagist.org/packages/angeo/module-openai-product-feed) (available via Packagist). It's a Magento 2 module designed specifically to generate the OpenAI product feed.
You can use this module to accelerate your product feed work, get a working feed format faster, and adapt/customize it as needed for your unique product model and variants.
**2. Checkout API (Agentic Checkout Spec)**
The Checkout API acts as your communication layer between the AI agent and your Magento order flow.
Implementation highlights:
Expose REST endpoints (e.g. /checkout/create, /checkout/status) compliant with the Agentic Checkout Spec.
Accept contextual metadata (user, session, selected products) from the AI agent and map it to Magento's quote and order models.
Return structured responses (checkout URL, payment link, order status, errors) for the agent to present to the user.
Implement webhooks to notify AI agents about updates (order confirmed, canceled, refunded, etc.).
Ready-to-install starting point: For Magento 2 shops, there's a module you can install right now:
[angeo/module-openai-instant-checkout](https://packagist.org/packages/angeo/module-openai-instant-checkout) (available via Packagist). It's a Magento 2 module designed specifically to integrate Magento 2 with ChatGPT using the Agentic Commerce Protocol. Enable Instant Checkout and support AI-driven purchases through your custom Agentic Checkout API
**3. Payment Integration (Delegated Payment Spec)**
ACP relies on Delegated Payment Spec, currently supported by Stripe Shared Payment Tokens.
**4. Certification and Production Readiness**
Before going live, OpenAI requires your implementation to pass conformance and reliability checks - covering order accuracy, security, inventory updates, and error handling.
🌍 Real-World Business Value
Integrating ACP is more than a tech upgrade - it's a strategic move. Here's how it translates into measurable value:
Expanded visibility: Your Magento catalog becomes discoverable in AI chat apps and assistants.
Higher conversions: Conversational purchase flows reduce friction and increase impulse purchases.
Full control: You keep your payment gateways, customer data, and fulfillment pipeline.
Future-ready commerce: As AI adoption grows, your store is already part of the next wave.
Brand differentiation: Early adopters of ACP stand out in a saturated e-commerce market.
🧠 Summary Notes
ACP represents a paradigm shift: it turns your Magento 2 store into an AI-ready commerce hub.
Build your feed, expose your checkout, integrate payments - and your Magento store becomes conversational-commerce ready.
ACP introduces a new frontier - where UX becomes a dialogue, not a page.
Whether you're an agency, extension developer, or merchant with a custom Magento build, embracing ACP early will give you a competitive edge. This isn't just about AI - it's about meeting customers where they already are: in the conversation.
#Magento 2 #OpenAI #Agentic Commerce Protocol #ACP #ChatGPT #Instant Checkout
- [How OpenAI's Product Feed Can Improve Your Online Shopping Experience](https://angeo.dev/how-openais-product-feed-can-improve-your-online-shopping-experience/): The OpenAI product feed - not crawling - decides which products appear in ChatGPT shopping results. How the feed works and what merchants control.
In the ever-evolving world of online shopping, the experience you get from visiting a website can be significantly impacted by how well the store understands your preferences. You've probably noticed that some e-commerce platforms seem to know exactly what you're looking for before you even type it in the search bar. This is thanks to technologies like AI (artificial intelligence), which power features like personalized product recommendations and smarter search results.
One of the ways AI is transforming e-commerce is through **product feeds** - a system that helps stores better organize and display their products to match what you, as a shopper, are most likely to enjoy or need. But how exactly does this work?
**What is OpenAI's Product Feed?**
At its core, **OpenAI's product feed** is a system designed to help e-commerce stores understand and organize their products in a smarter way. Imagine a store where, when you search for "wireless headphones," it doesn't just show you random products - it shows you the best options based on your preferences, budget, and even what's trending in real-time.
This is possible because OpenAI's product feed helps stores organize their product data in a format that AI can understand, allowing the platform to make recommendations based on how similar shoppers behaved or what they've bought before.
**Why Should You Care About Product Feeds?**
You might be wondering: **how does this affect me, the shopper?** Well, here's how:
1. **Smarter Recommendations**: Ever wish a store could suggest products you actually want, not just what they want to sell you? OpenAI's product feed can analyze your past purchases and browsing behavior to show you products that match your tastes. This means you'll spend less time searching and more time enjoying relevant options.
2. **Better Search Results**: When you search for a product, you probably don't want to see 100 irrelevant options. With OpenAI-powered product feeds, e-commerce platforms can better understand the context behind your search and show you the most accurate results - whether it's a particular brand, style, or price range.
3. **Improved Product Descriptions**: No more guessing what a product is! AI helps stores create clearer, more detailed descriptions and tags for each product. For example, if you're looking for a smart watch, the feed could automatically highlight features like "heart rate monitor," "fitness tracking," or "waterproof" based on what you typically search for.
4. **Automatic Product Categorization**: The product feed helps stores automatically categorize items in a way that makes sense, meaning less time spent trying to figure out where things belong. Whether it's shoes, electronics, or beauty products, AI ensures that products are grouped together logically, making it easier for you to browse.
**How Does This Work for E-Commerce Stores?**
For those of you who aren't familiar with the behind-the-scenes magic, stores use something called a **product feed** to upload all their product data (like name, description, price, and image) into a system. Traditionally, this data is manually updated and categorized by store managers. But OpenAI's product feed uses **artificial intelligence** to make sense of all that data, optimizing it in real-time based on your preferences and behaviors.
For example, let's say you've recently bought a new phone case from an online store. The next time you visit that site, the AI might recommend related accessories, like screen protectors or wireless chargers, based on what similar shoppers bought after purchasing a phone case.
**Real-World Example: How You'll See the Benefits**
Let's imagine you're shopping for **wireless Bluetooth headphones**. Here's how OpenAI's product feed can enhance your shopping experience:
- **Personalized Search**: When you type "wireless Bluetooth headphones" into the search bar, the AI immediately filters through thousands of products to show you options that best match your preferences - whether you're looking for noise-cancelling features, a particular color, or a specific price range.
- **Tailored Recommendations**: If you've been browsing other electronic gadgets or accessories on the same site, the feed can suggest related products based on your browsing history - like a matching Bluetooth speaker or even the best headphones for gaming.
- **Smarter Filters**: Sometimes it's hard to figure out which products fit your needs, especially when you're comparing lots of options. The product feed can automatically highlight important details like battery life, sound quality, and wireless range, helping you make a more informed decision.
- **Real-Time Updates**: If the store updates its inventory - maybe a new version of your favorite headphones is in stock - the AI-powered feed can make sure you see those changes right away.
**How Can You Spot AI in Your Shopping Experience?**
If you're shopping on a site that uses OpenAI's product feed, here's what you might notice:
1. **Relevant Product Suggestions**: After adding an item to your cart, you might see suggestions like "Customers who bought this also liked..." or "You may also be interested in..." These are powered by AI and based on what similar customers have purchased.
2. **Dynamic Sorting**: Instead of seeing products just based on popularity or price, you might notice more tailored sorting options, like "Trending Right Now" or "Recommended for You."
3. **Easier Comparison**: If you're deciding between different options, the product descriptions might be clearer and more consistent, thanks to the AI's ability to categorize items effectively.
**What This Means for the Shopper**
In short, OpenAI's product feed means that your online shopping experience can become much more **personalized, streamlined, and efficient**. Instead of getting overwhelmed by endless product lists and irrelevant recommendations, AI helps narrow down your options to what's most relevant to **you**. This not only saves time but also enhances your shopping experience by making it more enjoyable and less frustrating.
E-commerce stores can offer smarter product recommendations, clearer descriptions, and more accurate search results - all thanks to AI technology working behind the scenes. And while all of this happens automatically, it ultimately makes the shopping process feel more intuitive and connected to your needs.
**In Conclusion**
The future of online shopping is **personalized**, and OpenAI's product feed is a key part of that future. By making the product feed smarter and more dynamic, e-commerce platforms can give you a more personalized, relevant, and seamless shopping experience. So next time you notice those smart product suggestions or find the perfect item faster, you'll know it's AI at work - making your shopping experience a whole lot better!
- [Magento AI Brand Visibility: Does ChatGPT Recommend Your Store?](https://angeo.dev/magento-2-ai-brand-visibility/): See if ChatGPT, Claude, Perplexity, Gemini and Groq recommend your Magento store - a free module that scores your AI brand visibility 0-100.
**Short answer:** when your customers ask ChatGPT, Claude or Perplexity *"where should I buy this?"*, you currently have no idea whether your store appears in the reply. [Angeo AEO Brand Visibility](https://github.com/angeo-dev/module-aeo-brand-visibility) is a free, open-source **Magento 2** module that measures exactly that: it runs brand-probing prompts across the five major AI models and scores your real-world **AI brand visibility** from 0 to 100.
Search no longer means only Google. More buying research now starts inside an AI assistant that returns one synthesized answer naming a few stores. **AI Engine Optimization (AEO)** is the work of making sure your brand is one of those names - and this module tells you, in minutes, whether it is.
## Why AI brand visibility matters for Magento merchants
AI answers are *winner-takes-most*. Where a search results page lists ten links, an AI assistant usually names two or three stores. If you are not in that shortlist, you are invisible to that buyer - there is no "page two". Traditional SEO tools can't see this: they measure rankings, backlinks and crawl health, not what a model actually *says* when prompted. That blind spot is what AEO Brand Visibility closes.
## How Magento AI brand visibility tracking works
You set your brand name, domain, category and a few top products. The module sends natural shopping prompts - "What are the best online stores to buy {category}?", "Tell me about {brand}", "Compare {brand} with similar stores" - to every enabled AI provider. Each response is analysed for five signals, scored, cached and saved to a history log so you can watch the trend over time.
### Supported AI providers
| Provider | Why it's included | Free tier? |
| **ChatGPT** (OpenAI) | The most-used assistant; the default benchmark for AI recall. | No |
| **Claude** (Anthropic) | Strong reasoning; common for research-style queries. | No |
| **Perplexity** | Live web search - the best signal for what the internet says about you right now. | No |
| **Gemini** (Google) | Tied into Google's ecosystem; generous free tier. | Yes |
| **Groq** | Fast, free Llama hosting - ideal for zero-cost testing. | Yes |
Enable any combination. Start with the free providers (Gemini and Groq) to validate your setup at zero cost, then add paid providers for the most commercially relevant picture.
### The five visibility signals
1. **Mentioned** - your brand or a configured alias appears anywhere in the answer.
2. **Recommended** - the model actively suggests you (recommendation language near your mention, or you appear in a ranked list).
3. **URL cited** - your domain is referenced in the response, the strongest trust signal.
4. **First result** - you appear in the first quarter of the answer, i.e. top-of-mind.
5. **Positive sentiment** - favourable language sits close to your mention.
Each signal is weighted and combined into a single **0-100 score** with an A-F grade, so a non-technical stakeholder can read the result at a glance while your team digs into the per-provider breakdown.
## What you get in the Magento admin
- **Run Audit** - one click queries every enabled model and shows live scores, per-provider chips and signal rates.
- **Statistics & trend chart** - average, best and worst scores plus a score-over-time graph from your fresh (non-cached) runs.
- **Audit History** - your recent runs, each expandable to the full prompt-by-prompt detail.
- **Action Plan** - a prioritised, time-bounded roadmap of what to fix first to lift your score.
- **Single Query Tester** - send one prompt to one provider and inspect the raw response for debugging.
## Automate it: CLI, cron and CI gates
AI brand visibility drifts as content, reviews and the web change, so the module ships a CLI command and a cron job to track it continuously - and it can even fail a CI build if your score drops below a threshold.
```
# Run a full audit across all enabled providers
bin/magento angeo:aeo:brand-visibility
# Force fresh queries (bypass the cache)
bin/magento angeo:aeo:brand-visibility --refresh
# Test a single provider / prompt
bin/magento angeo:aeo:brand-visibility --provider=perplexity --prompt=brand_direct
# Machine-readable output for dashboards
bin/magento angeo:aeo:brand-visibility --format=json
# Gate a pipeline: exit 1 if the score falls below 60
bin/magento angeo:aeo:brand-visibility --fail-on=60
```
## Built to extend angeo/module-aeo-audit
AEO Brand Visibility plugs into [angeo/module-aeo-audit](https://angeo.dev/magento-aeo-audit/) as a live-signal checker, sitting alongside the 15 built-in technical checks (robots.txt, llms.txt, structured data and more). Your brand-recall score becomes part of the same unified AEO report your team already runs - one command, one dashboard, technical and real-world signals together.
## Security & privacy
Provider API keys are stored with Magento's encrypted backend model and never written to logs. Outbound calls are HTTPS-only and don't follow redirects, admin endpoints are protected by ACL and form keys, and all AI-provider text is escaped before rendering in the admin UI. Serialization uses Magento's `SerializerInterface` throughout. In short, it behaves like a Magento module should.
## Installation
```
composer require angeo/module-aeo-brand-visibility
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento cache:flush
```
Then open **Stores → Configuration → Angeo AEO → Brand Visibility**, add at least one provider API key, set your brand name and domain, and hit **Run Audit**.
## How to improve your AI brand visibility score
- **Low mention rate?** Publish an `llms.txt` file (see [angeo/module-llms-txt](https://angeo.dev/magento-llms-txt/)) and keep your store name consistent across every page.
- **Domain not cited?** Strengthen your backlink profile and reference your canonical URL explicitly in structured data and `llms.txt`.
- **Not being recommended?** Improve product content quality and implement review schema so models have reasons to vouch for you.
- **Appearing late in answers?** Build topical authority with category-focused content so you become the default association for your niche.
## Frequently asked questions
**Is the Magento AI brand visibility module free?** Yes. The module is open source under the MIT license. You only pay for the AI provider usage you choose - and you can run it entirely free using the Gemini and Groq free tiers.
**Which AI models does it check?** ChatGPT (OpenAI), Claude (Anthropic), Perplexity, Gemini (Google) and Groq. You can enable any combination and configure the model, token limit and timeout per provider.
**Will running audits cost a lot in API fees?** No, if configured sensibly. Results are cached for a configurable time-to-live, you control how many prompts run, and you can stick to the free Gemini and Groq tiers. Total queries equal enabled providers multiplied by active prompts, so keep that product modest for routine monitoring.
**What Magento versions are supported?** Magento 2.4.6, 2.4.7 and 2.4.8 (Adobe Commerce and Mage-OS), on PHP 8.2, 8.3 or 8.4. It requires angeo/module-aeo-audit v3.0 or newer.
**How is this different from SEO tools?** SEO tools measure search rankings and crawlability. This module measures what AI assistants actually say when asked shopping questions - whether you are mentioned, cited and recommended in the generated answer itself.
## Start measuring your AI visibility today
AI assistants are already recommending stores in your category. The only question is whether they're recommending *you*. Install [angeo/module-aeo-brand-visibility](https://github.com/angeo-dev/module-aeo-brand-visibility), run your first audit, and find out in minutes.
[Get the module on GitHub](https://github.com/angeo-dev/module-aeo-brand-visibility)
[View on Packagist](https://packagist.org/packages/angeo/module-aeo-brand-visibility)
**Related Angeo modules:** [aeo-audit](https://angeo.dev/magento-aeo-audit/) (the 15-signal technical AEO audit), [llms-txt](https://angeo.dev/magento-llms-txt/) (publish llms.txt), [rich-data](https://angeo.dev/magento-rich-data/) (Organization & Product schema), and [ai-description-updater](https://angeo.dev/magento-ai-description-updater/) (AI-written product content).
- [Why Your Store Is Invisible to ChatGPT - and How to Fix It](https://angeo.dev/why-your-store-is-invisible-to-chatgpt-and-how-to-fix-it/): ChatGPT recommends competitors and ignores your store? The 5 technical reasons AI assistants can't see your catalog - and the fix for each. Free 2-min audit.
Customers no longer search first - they ask AI.
If your store isn't visible to ChatGPT or AI assistants, you are already missing a new generation of high-intent customers.
Here's why it happens and how modern eCommerce brands are fixing it.
[image: Why Your Store Is Invisible to ChatGPT Banner]
## The Shift Nobody in eCommerce Fully Realized Yet
For more than two decades, online growth followed a predictable formula:
**SEO → Traffic → Conversion → Revenue**
Search engines were the gateway to customers. But in 2025-2026, behavior changed fundamentally.
>
Users no longer search - they ask AI.
Instead of browsing results, customers now request recommendations directly from AI assistants like ChatGPT. The assistant delivers answers, not links.
This marks the beginning of **AI Commerce**.
---
## The New Visibility Problem
Many stores rank well in Google yet never appear inside AI recommendations.
- Strong SEO performance
- Optimized product pages
- Healthy conversion rates
Yet AI never mentions them.
**Why?** Because AI does not discover websites like search engines do.
Google indexes pages. AI evaluates knowledge, trust, and machine-readable commerce data.
---
## From SEO to AEO to ACO
### SEO - Search Engine Optimization
Optimizing pages for keywords and rankings.
### AEO - Answer Engine Optimization
Creating content designed to appear in AI-generated answers.
### ACO - Agent Commerce Optimization
Preparing stores for autonomous AI agents that recommend and transact.
Most businesses are still operating at SEO level while AI commerce already operates at ACO.
---
## Why ChatGPT Doesn't Recommend Your Store
### 1. Built for Crawlers, Not Reasoning Systems
Keyword-focused pages rarely provide contextual expertise required by AI systems.
### 2. Lack of Topical Authority
AI recommends experts, not catalogs. Stores without educational content lack authority signals.
### 3. Weak Brand Entity Presence
AI validates brands through mentions across the web, not only website ownership.
### 4. Products Are Not Machine-Readable
Most stores expose product information only for humans, not for AI agents.
- Unstructured attributes
- No AI-compatible feeds
- Human-only checkout flows
AI cannot recommend what it cannot interpret.
---
## Agentic Commerce & The Technical Visibility Layer
This is where AI commerce fundamentally diverges from traditional SEO.
Visibility is no longer only about content. It is about **connectivity**.
### What Is Agentic Commerce?
Agentic Commerce describes a model where AI agents:
1. Understand user intent
2. Discover products
3. Evaluate options
4. Initiate transactions
The buying journey becomes:
```
User → AI Agent → Store Infrastructure → Purchase
```
---
### The Technical Visibility Layer
#### AI Product Feeds
Structured feeds expose product data in formats optimized for AI reasoning and recommendations.
#### Agent-Compatible APIs
AI assistants can verify inventory, configure products, and prepare orders automatically.
#### Emerging Magento Integrations
Modern Magento integrations already expose catalogs directly to AI systems and enable agent-driven checkout flows - an early version of future commerce infrastructure.
**Stores without an AI interface layer will gradually disappear from AI recommendations.**
---
## Why This Changes Lead Generation Forever
Traditional funnel:
```
Search → Compare → Trust → Buy
```
AI-driven funnel:
```
Ask → Trust AI → Visit → Buy
```
AI traffic arrives pre-qualified, reducing decision friction and increasing conversion probability.
---
## The New AI Visibility Stack
### Content Layer
- Guides
- Educational articles
- Problem-solving content
### Authority Layer
- Brand mentions
- External validation
- Ecosystem presence
### Technical Layer
- Structured product feeds
- Agent APIs
- AI-compatible commerce infrastructure
---
## What Smart eCommerce Brands Are Doing Now
- Designing content for AI answers
- Structuring product knowledge
- Exposing machine-readable catalogs
- Preparing agent-ready checkout flows
Websites are no longer the first touchpoint. AI is.
---
## Final Thought
Your store is not invisible because marketing failed.
It is invisible because commerce infrastructure has changed.
>
The future belongs to stores that AI can understand, trust, and transact with.
[image: Why Your Store Is Invisible to ChatGPT Banner Bottom]
- [The Magento product description that AI can't read](https://angeo.dev/magento-product-description-invisible-ai-chatgpt/): Most Magento stores pass every AEO check - and still lose to competitors in ChatGPT recommendations. The problem is not robots.txt or schema. It is how product descriptions are rendered.
**You installed robots.txt rules for GPTBot and OAI-SearchBot. You generated llms.txt. You added Product schema. The AEO audit is mostly green.**
And ChatGPT still recommends your competitor.
There is a good chance the problem is not in any of those signals. It is in your product page itself - and specifically in how Magento renders product content relative to what AI extraction systems actually process.
[image: The Magento product description that AI can]
The Magento product description that AI can't read
## How your product page travels through an AI recommendation system
Before fixing anything, it helps to understand what actually happens between a crawler visiting your store and your product appearing - or not appearing - in a ChatGPT recommendation.
```
Magento HTML response
↓
AI crawler fetches raw HTML
(limited or inconsistent JavaScript rendering)
↓
Extraction layer
parses text, headings, structured data
↓
Content chunking
splits page into retrievable units
↓
Relevance scoring
ranks chunks against query intent
↓
LLM answer synthesis
selects candidates for the response
↓
Citation / recommendation
```
The extraction layer is where most Magento stores lose. If your product description is difficult to find, collapsed behind interaction, or rendered in a way that makes structural parsing ambiguous - your product may never become a strong candidate during retrieval and ranking for comparative prompts like:
- *"best trail running shoes under €150"*
- *"comfortable sneakers for all-day walking"*
- *"running shoes with visible air cushioning"*
In comparative recommendation prompts, extraction systems rarely evaluate your product in isolation. They compare extracted chunks from multiple stores simultaneously. The cleaner and earlier your product information appears in the HTML, the more competitive your product becomes during candidate selection - against every other store that sells the same thing.
This is not an indexing problem. It is a retrieval problem. The distinction matters because it affects what you need to fix.
## Content visibility is not binary
Traditional SEO treats content as either indexed or not. For AI extraction systems, the picture is more granular. In practical audits across Magento stores, product page content tends to fall into at least four levels:
| Level | How the content exists | Extraction reliability |
| **1** | Server-rendered, early in HTML | High |
| **2** | Server-rendered but hidden or collapsed | Reduced - parser-dependent |
| **3** | Present in DOM only after JS execution | Low - often inconsistent |
| **4** | Loaded asynchronously after interaction | Very low and highly inconsistent |
Traditional SEO often treats levels 2, 3, and 4 as "indexable enough" - and for Googlebot, which runs a full headless Chrome rendering pipeline, that is broadly true. Most AI crawlers do not reliably execute full client-side rendering flows the way modern browsers do. Even where partial rendering exists, JavaScript-dependent content is significantly less reliable for AI extraction and answer synthesis than server-rendered HTML.
Many extraction pipelines also prioritise early-page content, semantic structure, headings, and concise HTML regions. Content that sits deep in nested containers, behind collapsed UI, or delayed by hydration often receives lower extraction priority due to token and latency constraints - even when it is technically present in the DOM.
For AI systems, the question is not just "is this content in the HTML?" but "will the extraction layer find it, chunk it correctly, and score it as relevant during answer synthesis?"
## What typically happens on a default Magento product page
Magento 2's standard product page layout wraps descriptions and attribute groups inside a tabs widget defined in `Magento_Catalog::product/view/details.phtml`. The initialisation uses `data-mage-init='{"tabs": {...}}'` - a RequireJS-driven widget.
The behaviour varies by implementation:
- In most Luma configurations, the description *is* present in the server-rendered HTML - but marked inactive, collapsed, and positioned deep in the document after significant structural scaffolding
- In some configurations, content is injected only after the tab receives a click event
- Across all standard configurations, the description typically appears after hundreds of characters of navigation markup, widget configuration JSON, form keys, and boilerplate
Even at Level 2 - technically in the HTML - the position and surrounding structure affect how reliably the extraction layer treats the content. A product description that appears as the eighth or ninth region of meaningful content, inside a collapsed tab container, competes poorly against a competitor's description that appears as clean prose high in the document.
Run this to see your actual HTML output:
```
curl -s "https://yourstore.com/your-product-url.html" \
| python3 -c "
import sys, re
html = sys.stdin.read()
text = re.sub(r']+>', ' ', html)
text = re.sub(r'\s+', ' ', text).strip()
print(text[:3000])
"
```
What you want: product description text - materials, specifications, benefits - appearing clearly in those first 3000 characters, in readable form.
What commonly appears: product name, price, SKU, breadcrumb, button text, widget boilerplate, and very little substantive content until deep into the response.
[image: The Magento product description that AI can]
## Test what AI actually sees in 60 seconds
**Method 1 - Source view:**
Right-click your product page → "View Page Source" (not Inspect, which shows the rendered DOM). Use Cmd/Ctrl+F to search for the first sentence of your product description.
If it is not there - Level 3 or below. If it is there but appears after significant boilerplate - Level 2 with extraction risk.
**Method 2 - curl test:**
```
curl -s "https://yourstore.com/your-product.html" \
| grep -c "your product description phrase"
```
Zero means Level 3 or 4. A result means at least Level 2 - but position and context still matter.
**Method 3 - ask an AI directly:**
```
What can you tell me about this specific product? [paste your product URL]
```
A generic response ("This appears to be a product page...") rather than one specific to your product's actual attributes and benefits typically means the indexing pipeline did not extract your description meaningfully - regardless of which level it sits at technically.
## Three approaches to improve extraction reliability
These are ordered by implementation effort. The right choice depends on your theme and how your content is currently structured.
### Approach 1 - Make the description tab active by default
The lowest-effort fix for a Level 2 situation. Setting the description tab as active on load means the content is not hidden at the CSS level when the page is fetched.
```
-
- true
```
This keeps the tab UI intact for human visitors while ensuring the description is exposed at page load. It moves content from Level 2 collapsed to Level 2 visible - a useful quick fix while you plan a more structural change.
### Approach 2 - Render description directly in product info, above tabs
A structural fix that moves description content to Level 1 - early in the HTML, clearly associated with the product entity, before any tabs infrastructure. This gives extraction systems a clean, unambiguous target.
```
```
```
getProduct()->getData('description');
if (!$description) return;
?>
= /* @noEscape */ $description ?>
```
This renders the description as server-side HTML, early in the document. You can keep the tabs further down the page for human navigation - the description appears in both places, but the extraction-friendly version is unconditional and structurally clean.
### Approach 3 - Render all tab content into the initial HTML response
The most comprehensive approach. Override `details.phtml` to render all tab content into the HTML at page load. Tab visibility is then controlled by CSS on the active state rather than by content toggling.
```
getGroupChildNames('detailed_info') as $alias): ?>
getLayout()->getBlock($alias); ?>
= $childBlock->toHtml() ?>
```
The full content of every tab - description, specifications, additional attributes - is present in the initial HTML response. The tabs widget hides all but the active tab via CSS for human visitors. AI parsers reading the raw HTML see all of it cleanly.
## Hyva Theme
Hyva replaces RequireJS tabs with Alpine.js components. The default Hyva product page uses `x-show` directives for tab visibility:
```
```
In Hyva, the description content is typically present in the HTML source - it does not require a click to inject. However, `x-show` directives and Alpine data bindings add structural noise around the content, and the relationship between the content and its context may be less clear to an indexing pipeline that does not evaluate the Alpine scope.
The most reliable fix for Hyva is progressive enhancement: render the description once outside the interactive container, as a clean server-side HTML block, early in the product layout. This gives the extraction layer an unambiguous target independent of the Alpine component state - not a crawler-specific workaround, but a standard architectural pattern that happens to be exactly what AI parsers prefer.
```
```
One clean, server-rendered block. Early in the document. No Alpine dependencies. Structurally unambiguous.
## Server-side JSON-LD matters for the same reason
The same principle applies to Product schema. If your JSON-LD is generated by a JavaScript block, injected via GTM, or hydrated client-side, in many observed cases AI extraction systems do not see it - regardless of how complete the schema is.
[content truncated]
- [Why Your Magento Store Ranks in Google But Disappears in ChatGPT](https://angeo.dev/magento-ranks-google-invisible-chatgpt/): Good Google SEO doesn't transfer to AI search. ChatGPT, Perplexity and Gemini use completely different signals. Here's what's blocking your Magento store - and how to fix it.
-
AEO · AI Search · Magento 2
Your Magento store is already doing everything right - for Google. Fast load times, clean structure, solid content, good rankings. But AI systems evaluate different signals. When someone asks ChatGPT for exactly what you sell, your store may not appear - not because your SEO is wrong, but because AI visibility requires an additional machine-readable layer that most Magento stores haven't set up yet.
TL;DR - 2 minute version
Google ranks you. **AI engines decide if you exist.**
- SEO alone is not enough for AI visibility - AI systems still use web signals, but require additional structured layers most stores lack.
- AI uses different signals: **robots.txt access, structured schema, llms.txt, product feeds.**
- A store with excellent SEO and zero AEO work scores ~23% on AI visibility - blocked by default.
- The fix takes under 2 hours and uses free open-source Magento modules.
[image: Why Your Magento Store Ranks in Google But Disappears in ChatGPT]
## Two Different Questions
Google and ChatGPT are answering two fundamentally different questions when a user searches for something.
**Google asks:** "Which pages are most relevant and authoritative?"
Result: a ranked list of links. You click, browse, decide.
**ChatGPT asks:** "What should this person buy, and where can they buy it?"
Result: a recommendation. Either your store is in it - or it isn't.
This distinction matters because these two questions require fundamentally different answers from your store's infrastructure. AI systems still use web signals - authority and content quality still matter - but they also require machine-readable layers that traditional SEO work doesn't address.
This distinction matters more than most Magento store owners realise. When ChatGPT recommends a product, the user doesn't comparison-shop across ten results. They follow the recommendation. Conversion rates from AI-referred traffic are significantly higher than from organic search - because the filtering already happened before the click.
But to get into that recommendation, you have to play by AI's rules. And those rules have almost nothing to do with the SEO work you've been doing for years.
## What Google Cares About vs What AI Cares About
Google
Backlinks and domain authority
AI engines
robots.txt access for AI crawlers
Google
Page speed and Core Web Vitals
AI engines
llms.txt - a structured content map of your store
Google
Keyword density and content length
AI engines
Product JSON-LD schema with offers.availability
Google
Internal linking structure
AI engines
ACP product feed for ChatGPT Shopping
Google
Mobile-first indexing
AI engines
Organization schema - merchant identity verification
Notice that almost none of the AI signals overlap with traditional SEO. Your domain authority, your backlink profile, your Core Web Vitals score - none of these directly affect whether ChatGPT or Perplexity recommends your store. They are measuring completely different things.
## The Specific Problem with Default Magento
Default Magento 2 was designed before AI search existed. Its configuration makes perfect sense for Google - but creates a specific set of problems for AI engines.
### Problem 1: robots.txt blocks AI crawlers by default
Most Magento installations have a `robots.txt` that was set up years ago and never touched since. It typically allows Googlebot and Bingbot - and says nothing about the AI crawlers that have emerged in the last two years.
When a bot is not explicitly mentioned in `robots.txt`, behavior depends on your wildcard rules. In many Magento setups, AI crawlers like `OAI-SearchBot` (ChatGPT) and `PerplexityBot` are either blocked or not explicitly allowed - which can result in limited or inconsistent crawling.
Check yours right now:
```
curl https://yourstore.com/robots.txt | grep -E "OAI-SearchBot|PerplexityBot|Google-Extended"
```
If you get no output, those bots have no explicit permission. Depending on your wildcard rules, they may be blocked entirely. This is the single most common reason a well-optimised Magento store is invisible in AI search - and it takes five minutes to fix.
### Problem 2: Product schema is missing the one field AI needs most
Magento's default product templates output microdata - the older HTML attribute format. AI engines prefer JSON-LD. More critically, the default microdata is missing `offers.availability`.
This one missing field causes ChatGPT Shopping feed validation to fail automatically. The product technically exists in ChatGPT's index, but it cannot be shown as a purchasable item. For a shopping recommendation engine, a product that can't be confirmed as purchasable simply doesn't get recommended.
The correct format is:
```
"availability": "https://schema.org/InStock"
```
Not `"In Stock"`, not `"instock"`, not `true`. The full schema.org URI. AI parsers silently reject everything else.
### Problem 3: No llms.txt means AI crawlers are guessing
When an AI crawler visits your store without `llms.txt`, it parses random product pages and tries to infer what your store is about. This works poorly for ecommerce - navigation menus, cookie banners, related products, and promotional banners all create noise that obscures the actual product data.
`llms.txt` is a plain text file at your store root that tells AI engines exactly what you sell, what your main categories are, and which pages are most important. Perplexity has specifically documented it as a crawl signal. Without it, discovery is slower, less accurate, and less complete.
### Problem 4: ChatGPT Shopping requires a separate feed
ChatGPT Shopping product cards - the feature that shows prices, images, and buy links directly in a chat response - are not populated from organic crawl. They require a separate ACP (Agentic Commerce Protocol) product feed submitted to OpenAI's merchant program.
Good Google SEO, good organic rankings, even a perfect product page - none of these get you into ChatGPT Shopping. It requires a deliberate registration process and a spec-compliant feed.
> A store can appear in ChatGPT's general answers (via OAI-SearchBot crawl) without appearing in Shopping product cards (which require ACP feed registration). These are two separate paths to AI visibility.
## How AI Decides What to Recommend
Understanding why AI visibility requires different signals starts with understanding how AI shopping systems make decisions. The process has five layers - and a store needs all of them to be eligible for product recommendations:
1. **Crawl access** - AI crawlers must be able to reach your pages. If `robots.txt` blocks or doesn't explicitly allow AI bots, the process stops here.
2. **Structured data confidence** - AI parsers need Product JSON-LD with valid fields to understand what you're selling. Ambiguous or incomplete schema is treated as unreliable.
3. **Product availability** - Without `offers.availability` set to a schema.org URI, AI cannot confirm a product is purchasable. An unconfirmed product doesn't get recommended.
4. **Merchant trust signals** - Organization schema, consistent brand identity, and `llms.txt` help AI systems verify who is selling the product.
5. **Feed presence** - For ChatGPT Shopping product cards specifically, a registered ACP product feed is required. Organic crawl alone is not enough for shopping results.
Most Magento stores pass layers 2 and 3 partially - but fail at layers 1, 4, and 5 entirely. This is why strong SEO doesn't automatically translate into AI visibility: SEO optimizes for a different decision process.
## The Pattern Across Magento Stores
In audits across Magento stores, the pattern is consistent: strong SEO, invisible in AI results.
A store with excellent domain authority, page one rankings, and years of SEO investment can score 23% on AI visibility - because it blocks `OAI-SearchBot` in `robots.txt`, has no `llms.txt`, and outputs microdata without `offers.availability`. None of these issues show up in a Google audit. All of them block AI visibility entirely.
Meanwhile, a newer store that spent an afternoon on AEO - allowed AI crawlers, added JSON-LD schema, generated `llms.txt` - scores 79% and appears in ChatGPT results for the same queries.
SEO authority doesn't transfer to AI recommendations. The technical layer is what matters - and it's almost entirely within your control.
## The AEO Score: Where Most Magento Stores Stand Today
Based on auditing 50+ Magento stores, the average AEO score for a store that has done zero AI-specific work is around 21-28%. Here is a representative example of what a real audit looks like before and after fixes:
**Example audit - mid-size outdoor gear store:**
**Before:** OAI-SearchBot blocked in robots.txt · Product schema: microdata only, no availability · llms.txt: missing · ACP feed: missing
**Score: 26%**
**After:** AI bots allowed · JSON-LD with offers.availability · llms.txt generated · ACP feed submitted
**Score: 81%**
Time to implement: approximately 90 minutes.
Here is what the signal breakdown typically looks like across default Magento installations:
| Signal | Default Magento status | Impact |
| robots.txt - AI bot access | Usually blocked | Zero crawl visibility |
| llms.txt | Missing | Poor catalog discovery |
| Product JSON-LD schema | Partial (microdata, no availability) | Shopping feed fails |
| AI product feed (ACP) | Missing | No ChatGPT Shopping cards |
| Organization schema | Missing | Weak merchant trust |
| sitemap.xml | Usually present | - |
| Open Graph tags | Partial | - |
| Canonical tags | Usually present | - |
The good news: the four failing signals - robots.txt, llms.txt, Product schema, and ACP feed - are all fixable with free open-source Magento modules. The bad news: most stores haven't fixed them yet, which means the window for early-mover advantage is still open.
## What Fixing It Looks Like
These fixes can be implemented manually by editing templates and configuration files directly. Using modules significantly speeds up the process - here is the fastest path:
```
# Step 1: Fix robots.txt - allow AI crawlers
composer require angeo/module-robots-txt-aeo
# Step 2: Generate llms.txt and llms.jsonl
composer require angeo/module-llms-txt
# Step 3: Fix Product schema + Organization schema
composer require angeo/module-rich-data
# Step 4: Generate ACP product feed for ChatGPT Shopping
composer require angeo/module-openai-product-feed angeo/module-openai-product-feed-api
bin/magento setup:upgrade && bin/magento cache:flush
```
Total time including reading the docs: under 90 minutes. ChatGPT Shopping registration (at chatgpt.com/merchants) requires a separate application and is currently US-focused - but fixing the technical layer first means you're ready the moment eligibility expands.
To see exactly what's blocking your store before you start:
```
composer require angeo/module-aeo-audit
bin/magento setup:upgrade && bin/magento cache:flush
bin/magento angeo:aeo:audit
```
This gives you a weighted score across 13 signals with the exact fix command for each failure.
## Why This Is Happening Now
AI shopping is not growing gradually - it's being injected directly into existing user behavior. ChatGPT has over 400 million weekly users. Perplexity has become the default search for a significant segment of tech-savvy buyers. Google's AI Overviews appear on the majority of commercial queries.
The shift is not "AI search will matter in a few years." It's "AI search is already part of how your potential customers look for products today." The stores that haven't adapted yet aren't missing a future opportunity - they're invisible in a channel that already exists.
[content truncated]
## Optional
Endpoints and repositories outside the website itself. Safe to skip when context is short.
- [Angeo MCP endpoint](https://mcp.angeo.dev/): Live Model Context Protocol endpoint for conversational catalogue search and checkout against a Magento demo store.
- [Packagist - angeo](https://packagist.org/packages/angeo/): Every package, installable with Composer.
- [GitHub - angeo-dev](https://github.com/angeo-dev): Source for every module, MIT-licensed.
[comment]: # (Generated by Angeo LLMs Files v1.1.2 - 2026-08-25 17:55 UTC)