DEV Community: Ievgenii Gryshkun

llms.txt v2: What the Spec Says, and What 137,000 Domains Show

Ievgenii Gryshkun — Sun, 20 Sep 2026 19:17:36 +0000

Originally published on angeo.dev.

Checked against llmstxt.org v2, revised 10 August 2026, and against the published request data as of September 2026.

We shipped a validator that could certify a broken llms.txt file as valid.

The bug was simple. The spec recommends a short summary in a blockquote under the title. Our checker looked for a line starting with >. It never looked at what came after it. A store with no meta description produced a bare > and nothing else, and our tool ticked the box.

Fixing it sent us back to two things we had not read carefully enough. The specification had been revised on 10 August 2026, quietly, without a corresponding launch announcement. And Ahrefs had published server-log data from 137,210 domains showing that almost nobody requests these files at all.

Both matter, and most writing about llms.txt engages with neither. This article covers the evidence first, then the spec, then four claims about the spec that do not survive a check against the source. One of those four was ours.

What the request data shows

97% — of valid llms.txt files received zero requests in May 2026
137,210 — domains in the Ahrefs sample
19.5% — of the fetches that did happen came from named AI tools
~55% — of live files have the recommended shape (separate sample)

In June 2026 Ahrefs published a study of every domain in its Web Analytics data that received traffic in May 2026 — 137,210 of them. It checked each domain root for an llms.txt returning HTTP 200, confirmed the file was real Markdown rather than an HTML error page, and then looked at every request to those paths in its bot analytics.

The headline numbers:

28% of those domains publish an llms.txt. Ahrefs attaches its own caveat: its customers skew more technical and SEO-aware than the web at large, so 28% is an upper bound, not a web-wide figure.
Of roughly 38,000 valid files, 97% received zero requests in May 2026. Not few requests. None.
Only about 1,100 files received any traffic at all.
AI bots never requested llms.txt on domains where it did not exist. They are not probing for it. A crawler that wanted the file would ask and collect 404s.

The breakdown of the 3% that were fetched is more interesting than the headline, and it cuts both ways.

About 19.5% of fetches came from named AI tools, with GPTBot first and Claude-Code second — ahead of every AI search and assistant bot. Roughly 12% came from the industry inspecting itself: GEO and AEO tools, llms.txt checkers, researchers. Chrome's Lighthouse llms.txt audit accounted for about one fetch in a thousand.

Read that carefully, because it is easy to quote in either direction. The file is not universally ignored — where it is fetched, a fifth of the fetches are named AI tools. But the tools at the top are coding assistants reading documentation, not the retrieval crawlers that decide whether a shop gets cited in a shopping answer. Separate reporting of the same dataset puts AI retrieval bots at around 1% of total requests.

That pattern matches what Google has said. John Mueller described llms.txt in June 2025 as not being done for search, closer to a stopgap that saves tokens for AI coding tools reading developer documentation. In June 2026, Google added a note to its AI optimisation guidance stating that these machine-readable text files neither help nor harm Search rankings, because Search ignores them.

There is a second finding worth more than the adoption headline. In June 2026 Chris Humphrey fetched /llms.txt for the top 10,000 Majestic Million domains. Of the 1,050 that returned HTTP 200, 313 were serving an HTML soft 404 rather than a file. And of the 737 real files, only about 55% had the recommended shape: a title, a summary, and at least one section of curated links.

Nearly half of the published files are malformed. Hold that thought — it comes back later.

What changed in llms.txt v2

Against that background, the specification was revised. From its own change notes:

Link relations were added. A page can declare where its Markdown version lives, and which llms.txt describes it. This is the main addition.
Both Markdown URL forms are allowed. The earlier version described appending .md to the full page URL (page.html.md); v2 also allows replacing the extension (page.md).
Files at subpaths are defined. An llms.txt covers the pages under its own path, and the most specific file wins.
## Optional lost its mechanical semantics.
Links should lead to LLM-friendly content, meaning the Markdown versions of pages where those exist.

Now the four claims about all this that do not hold up.

Mistake 1: "llms-full.txt is part of the spec"

Short answer: llms-full.txt is not defined by the llms.txt specification.

The spec does not define it. The companion files it describes are llms-ctx.txt and llms-ctx-full.txt, generated by the llms_txt2ctx tool — and that context-expansion mechanism is no longer defined by the v2 specification either.

llms-full.txt — one large file holding the full text of a site — grew out of that pattern and was popularised when Mintlify rolled it out platform-wide in November 2024. Different name, different mechanism. People are half-remembering something that existed, which is why the mistake is sticky.

We got this wrong ourselves. Our audit module told merchants with large files to "split into llms.txt + llms-full.txt per spec." That sentence made a claim about a specification that the specification does not make. It is fixed.

The distinction was already documented publicly. Stack Exchange's design system made exactly this point in a pull request in May 2026 while splitting its own files, and others have since. We are not adding a new fact here, only repeating one that has not displaced the wrong version.

"Not part of the spec" does not mean "useless." The correct claim is not don't publish it. It is don't call it part of the specification, and know that support for it is an ecosystem convention.

Mistake 2: "There is a W3C draft"

Short answer: W3C issue #506 is not a W3C Working Draft.

Several articles published in mid-2026 describe a June 2026 W3C proposal to standardise llms.txt. They tell readers to audit their file against "the W3C draft's strict Markdown subset," and to submit comments to "the W3C working group." Some add that the draft forbids llms.txt at subpaths and requires a version header.

The W3C item people appear to be referring to is issue #506 in the w3c/strategy repository, opened by xfq on 27 April 2025, labelled AI, and still open. Its own text says the proposal is at an early stage and does not introduce any new format. That is a request to consider a topic, not a working draft.

The subpath claim also contradicts the actual specification. v2 explicitly permits files at subpaths — /llms.txt, /docs/llms.txt, /de/llms.txt — and explains how they resolve: a file covers the URLs under its path, and where several apply, the most specific wins. That is what makes a per-language file valid on a multi-store setup.

You can check this in under a minute. Open the issue, read the first paragraph, compare it to the article's claim.

Mistake 3: "## Optional tells the AI what it can skip"

Short answer: ## Optional is now a convention, not a mechanical omission rule.

This one needs care, because the correction is easy to overshoot.

In the earlier version, ## Optional had a defined mechanical meaning: it was used by the context-expansion mechanism to determine which URLs could be omitted. v2 removed that mechanism, and the special meaning went with it.

What remains is real but weaker. The spec still describes ## Optional as a convention for secondary information — links an agent may skip when a shorter context is needed. So it is not meaningless. It is no longer a rule any parser is expected to implement.

The practical difference for a shop: many Magento llms.txt files put the whole product list under ## Optional, on the theory that a context-constrained model will drop the catalogue and keep the categories. That theory rested on the mechanical semantics, and those are gone. Products are the primary content of a store, and secondary is precisely what they are not.

We changed our own default for this reason.

Mistake 4: "There's a blockquote, so the summary is fine"

Short answer: An empty > is not a meaningful summary.

This is the one worth reading twice, because it is not about the spec. It is about what validation misses — and, given that nearly half of published files are malformed, it is not a rare problem.

The spec recommends a short summary in a blockquote directly under the H1, containing key information about the site. The H1 is the only element it requires; the summary is recommended, not mandatory. That distinction matters, and not in the direction you might expect: an omitted summary is a defensible choice, while an empty blockquote claims to be one and is not.

Our validator checked for a line beginning with >.

A Magento store with no meta description and no custom summary produced this:

# Demo Store

>

## Categories

An empty blockquote. Our validator reported the file as valid. So did our audit module. Both saw a blockquote marker, counted it, and moved on. The file was broken in the exact place the check existed to protect, and the check was the thing confirming it was fine.

The failure is easy to name once you see it: the checker tested for the shape of the summary rather than its content. A parser that accepts the Markdown structure can therefore encounter an empty blockquote where the summary should be — worse than no summary at all, because an absent summary is at least visibly absent.

Both our tools now treat a bare > as an error. If you run any llms.txt validation, this is worth five minutes: put an empty blockquote in a test file and see whether your tool complains.

What v2 asks you to add

The link relations are the substantive new work. The point is that an agent holding a page URL should not have to guess where the Markdown version lives.

In the page head:

<link rel="alternate" type="text/markdown" href="https://shop.example/blue-shirt.html.md">
<link rel="describedby" href="https://shop.example/llms.txt">

For the Markdown resource itself, the spec describes the HTTP Link: header, since that resource has no HTML head to carry tags:

Link: <https://shop.example/llms.txt>; rel="describedby"

Three things to get right beyond that:

Support both URL forms if you can. v2 permits page.html.md and page.md. Serving either one is compliant. Supporting both is a compatibility choice for implementations that may assume either form.
Point llms.txt links at the Markdown versions where you serve them.
Do not declare a relation that 404s. A broken rel="alternate" can be worse than no relation at all, because a client may follow it and fail.

How we found out we were wrong about our own store

Our audit module runs against our demo store on every release. After we shipped v2 support, the new link-relations check failed — on our own store.

The cause was configuration, not code. Markdown mirrors were switched off, so the head tags were correctly suppressed and the .md URLs correctly returned 404. One setting. Once enabled, the check passed.

We include this because the alternative — writing the post after quietly fixing it — leaves out the useful part. A checker that has only ever shown green on the author's own site has not been tested against anything.

What to check on your store

Five commands. Replace the host and the product URL with your own.

# 1. Fetch the file and inspect its opening lines
#    -f makes curl fail on an HTTP error instead of piping the error page
curl -fsS https://shop.example/llms.txt | head -3

# 2. No empty blockquote — this should print nothing
curl -fsS https://shop.example/llms.txt | grep -n '^>[[:space:]]*$'

# 3. Link relations in the page head (presence check, not full validation)
curl -fsS https://shop.example/blue-shirt.html \
  | grep -i 'rel="alternate"\|rel="describedby"'

# 4. Link header on the Markdown file — GET, not HEAD, because caching
#    layers do not always return identical headers for a HEAD request
curl -fsS -D - -o /dev/null https://shop.example/blue-shirt.html.md \
  | grep -i '^link:'

# 5. Markdown URL forms
curl -so /dev/null -w '%{http_code}\n' https://shop.example/blue-shirt.html.md
curl -so /dev/null -w '%{http_code}\n' https://shop.example/blue-shirt.md

What to expect: command 2 prints nothing; command 3 shows both relations; command 4 shows a Link: header; command 5 returns a successful response for each Markdown URL form that you serve — in our implementation, 200. If you support only one form, the other may legitimately return 404. Command 5 tests what your implementation supports, not whether it is compliant.

Command 3 is deliberately loose. It finds the relations but does not verify that rel="alternate" also carries type="text/markdown", so a malformed tag will still match. Read the output rather than trusting the exit code.

If you want command 2 in CI, remember that grep exits 1 when it finds nothing, which is the passing case here. Invert it:

if curl -fsS https://shop.example/llms.txt | grep -q '^>[[:space:]]*$'; then
  echo "ERROR: empty summary blockquote"
  exit 1
fi

So should a Magento store implement this?

Disclosure. We build and maintain the open-source Magento 2 module that generates these files, and the audit module that checks them. Read what follows with that in mind.

Not as a traffic tactic. The request data does not support it, Google states plainly that Search ignores the file, and no major model provider has committed to reading it in production. If someone sells you llms.txt as an AI-visibility lever, ask them for request logs.

Possibly as developer-facing infrastructure. The one place the data shows real consumption is coding assistants reading documentation — GPTBot and Claude-Code lead the fetches. If you publish API documentation or a developer portal alongside your store, that use case is measurable today.

Reasonably, as cheap optionality. A generated file costs a build step and stays current automatically. The failure mode to avoid is not publishing one; it is publishing a stale, hand-maintained one, or a broken one — and given that roughly half of live files are malformed, that risk is the realistic one.

And do not let it displace the work that does have evidence behind it. For a shop, structured product data, correct canonical and schema markup, and pages an agent can actually parse have measurable effects. llms.txt does not, yet.

The most useful thing v2 changes for a merchant is not visibility. It is that the file, the Markdown mirrors and the link relations together give an agent a defined way to move from a page to a machine-readable version of it. That is worth having ready. It is not worth overselling.

What we do not know

We have no evidence that AI systems or agents follow the v2 link relations. They are new, correct per the spec, and cheap to serve. Whether anything follows them is unmeasured, including by us.
Adoption figures depend entirely on the population sampled. Ahrefs found 28% among a technical, SEO-aware customer base and said so itself. Humphrey found 7.4% in the Majestic top 10,000. As he put it: there is no single universal adoption rate, only the rate inside a defined slice.
The request data is one month, one vendor's panel. May 2026, Ahrefs Web Analytics. It is the largest public dataset of its kind and it is still one month of one panel.
Absence of observed consumption is not proof of no value. It is what the logs currently show. That could change if a major provider commits to reading the file — and the v2 link relations exist partly to make that easier.
v2 may not be the last revision. The first version stood for nearly two years before the specification changed. If you build tooling against it, build in a way to notice when it moves.

Sources

Primary

The specification: llmstxt.org. Published 3 September 2024, revised 10 August 2026.
What changed in v2: llmstxt.org/changes.html.
Request data: Ahrefs, "We Analyzed 137K Sites", 15 June 2026.
The W3C item: issue #506, w3c/strategy, opened 27 April 2025, still open.

Background

Independent coverage of the Ahrefs dataset: Search Engine Journal, 16 June 2026.
Adoption and file-quality sampling across the Majestic top 10,000, and a summary of the vendor statements: macmdviewer, 31 July 2026.
The original 2024 proposal, including the llms-ctx.txt / llms-ctx-full.txt companion files: answer.ai.
The llms-full.txt convention as its originator documents it: Mintlify.
The spec-versus-convention distinction, documented in May 2026: Stack Exchange Stacks PR #2283.
Tooling support: Chrome Lighthouse agentic browsing audits.

We maintain an open-source Magento 2 module that generates these files, and an audit module that checks them. Both are MIT licensed. The two bugs described above were in our own code and are fixed in the current releases.

I pre-registered a study on AI visibility signals. The main result was null.

Ievgenii Gryshkun — Sun, 06 Sep 2026 18:55:47 +0000

Originally published on angeo.dev. Full tables, p-values and the sealed plan are there.

Most claims about AI visibility are untestable by design: publish the signals, wait, attribute anything good that happens to the signals.

I wanted a version I could not fudge, so I wrote the analysis plan first, hashed it, and sent the hash to the other party before I had any data.

The question

Do businesses AI assistants name repeatedly differ, on observable technical signals, from businesses the same assistants name once?

Every business in the corpus was named at least once, so this says nothing about how to enter an answer. It compares repeat against one-off mentions inside a named-business corpus.

Four signals, all externally observable:

Signal	Check
Crawler access	Does `robots.txt` block any of 8 AI crawlers
Content map	Does the site serve `/llms.txt`
Structured data	Does a product page emit JSON-LD `Product`
Buyability	Does that node carry `offers.availability`

Study setup

The answers came from a partner (connexion.me), who ran 44 product-level home-decor buying questions across ChatGPT, Gemini and Perplexity, twice, in two arms — 264 answers per arm.

Blinding was deliberate. I did not write the questions and did not see their store list until my plan was sealed; they never saw my frame, my scan results or my thresholds.

Roster rows                                    669
  no resolvable domain                        -186
  resolved to a different company               -3
  marketplaces and listing surfaces            -12
  duplicate rows collapsed                     -10
Unique domains analysed                        458
  scanned successfully                         455

Cases: 3+ mentions across both runs and present in both. Controls: exactly one mention across both runs. Head excluded first — anything in 53+ of 264 answers (Amazon, Etsy, Wayfair, Target, Home Depot).

The pre-registration

Sealed 10 August, SHA-256 9b4ccf12629e…:

Under 15% of named businesses would be Magento
No signal would separate the groups by more than 15 points
Refutation condition: any signal differing by 20+ points with the named group higher

Result — generic arm

Two-sided Fisher exact. Percentages are of stores where the signal was observable.

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

The refutation condition was not met — in this arm, in the context arm, or pooled. No signal separates the repeatedly named group from the once-named group in the direction the field assumes.

Magento share of the 455 scanned domains: 13 stores, 2.9%.

The one that went backwards

llms.txt is more common among businesses named once than among those named repeatedly. Same direction in all five cuts, diffs of −15.3 to −17.4, nominal p between .012 and .030. Four signals across five cuts, no multiplicity correction — report them, do not treat them as confirmatory.

Before reading that as "llms.txt hurts you", I fetched the flagged files and read the first line of each:

113 of 159 llms.txt files — 71% — matched the same generated heading, differing only in the brand name. Not 113 independent decisions to publish. One generator.

Narrowed to the analysis universe: 146 of 455 serve the file (32%); 104 of those 146 are the template. Strip it and adoption is 9%, against 11% on my separately measured frame of 762 Magento stores.

I was about to publish 32% as adoption. Most of the apparent difference between the two populations was boilerplate.

The engineering lesson, if you want one

Three things I would do again on any measurement like this:

Write the failure condition before the data exists, and publish it when it fires. Mine fired in a secondary cut on a case group of four stores. Uninterpretable — and reported anyway, because a refutation condition you drop when it is inconvenient was never one.
Record presence, then inspect content separately. The scanner keeps no page content by policy. That is correct for a crawler, and it is also why the template finding needed a second, explicit pass.
Watch what your sampling heuristic does. In a related panel, 12% of stores had a different product page sampled on the second visit. That alone manufactures schema "changes" that never happened.

Caveats that matter

Two of four signals need a product page. Effective samples: 10 of 55 cases, 46 of 181 controls. Too small to conclude anything, and the missingness is probably not random — discovery works worst on large sites, which dominate the case group.
Losses are not random: shops behind bot mitigation returned 403/429, and those shops may also be more likely to block AI crawlers.
Crawler access is one route into an answer, not the only one — indexes, caches, feeds and listing sites all bypass it.
One category, three engines, two days.

Reproducing it

Sealed plan and both amendments with hashes, the marketplace exclusion list, the dropped-domain list, the per-business analysis rows and the scanner are all published. The scanner identifies itself, obeys robots.txt, keeps no page content and can be blocked in two lines.

Full write-up with every table: AI assistants named 458 shops

Earlier instalments: 462 stores scanned in July, 762 in August · 376 stores measured twice, 94% unchanged

I maintain a set of MIT-licensed Magento 2 modules for this layer — llms.txt generation, robots.txt AI-bot management, JSON-LD, MCP and UCP endpoints — on Packagist under angeo/. If you have run a similar measurement and got a different direction on llms.txt, I would genuinely like to see it.

Your robots.txt probably does not block the AI crawler you think it blocks

Ievgenii Gryshkun — Mon, 17 Aug 2026 19:25:48 +0000

Here is a rule that looks like it blocks OpenAI's crawler:

User-agent: *
Disallow: /checkout/
Disallow: /customer/

User-agent: GPTBot
Crawl-delay: 10

It blocks nothing. GPTBot reads its own group, finds one Crawl-delay line and no Disallow, and crawls everything — including /checkout/ and /customer/.

Under RFC 9309, a crawler that matches a specific user-agent group uses only that group. It does not inherit from User-agent: *. Naming a bot anywhere in the file switches off the wildcard rules for that bot entirely.

So the moment you add a named group to be more careful, you become less careful. And the failure is invisible: the file reads as though it says something.

I found this while doing something else, and the something else is the rest of this post.

The something else

I spent a few weeks cataloguing every project that helps an ecommerce store be found, read, trusted or transacted with by an AI system — for Magento specifically, because that is the platform I work on. The result is a list of 42 projects: awesome-magento-aeo, CC0, fork it if it is useful.

The interesting part is not the list. It is the distribution.

Category	Projects
`llms.txt` discovery files	11
Specifications	7
MCP servers	6
Agentic checkout	5
Structured data	4
Crawler policy	3
Product feeds	3
Auditing	3

Eleven implementations of llms.txt. For a file format proposed in 2024 that is, at heart, a Markdown document at your site root.

Three for crawler policy — the layer where the RFC 9309 trap above lives.

The ecosystem built the easiest layer eleven times and the hard layers three times each.

Why eleven is not the joke it looks like

My first read was duplicated effort: everyone shipping the same weekend project. That read is wrong.

Generating llms.txt for a real store is not trivial. You hit multi-store layouts, page-builder content that has to be resolved rather than dumped as markup, CMS directives, customer-group pricing, and catalogues large enough that naive generation exhausts memory.

The eleven implementations differ precisely on those axes — cursor-based pagination and generators for large catalogues, store-scoped entity selection, weighted ranking, blog content feeding the file with IndexNow pinging.

They look identical from outside and diverge completely at the point where the platform gets hard. That is what a young category looks like: several people solving the same problem and disagreeing about which parts matter.

The category that shrank while I was writing

In March 2026 OpenAI pulled back from in-chat Instant Checkout. Published figures put live merchants somewhere between about a dozen and 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 site.

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. The direction is not.

Not one of the five agentic checkout projects on the list is past a stable 1.0.

If you were scoping a sprint against in-chat checkout, the feed is the realistic route to being surfaced at all. The checkout integration is where the protocols are heading, not where revenue is this quarter.

Where I would start

Measure first. 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.
Fix crawler policy. Read RFC 9309 before you write a rule, then verify the rule does what you think it does.
Structured data, then llms.txt. In that order. Schema exposes machine-readable price, availability and identifiers; llms.txt points systems at the pages that matter.
Stop. Everything past this point is early, and being early is a cost rather than a badge.

The disclosure

I maintain 11 of the 42 entries on that list. My own projects are listed last within their sections rather than in alphabetical position, where they would otherwise appear first almost everywhere. I read documentation and READMEs rather than source, so I have not independently audited every implementation, and where I was unsure I marked partial rather than complete.

Corrections are welcome and never need justification — especially corrections to mine.

The full write-up, with the inclusion criteria and the parts I left out, is on my site.

Perplexity vs ChatGPT vs Gemini: how each one actually finds your products

Ievgenii Gryshkun — Fri, 31 Jul 2026 17:30:07 +0000

Two stores. Identical products, identical schema, identical SEO. One shows up inside ChatGPT Shopping, the other never does.

The difference isn't optimisation quality. The three engines don't read the same thing to find a product — and a store optimised for one pipeline can be structurally invisible to the other two.

Two pipelines, not one

Every one of these platforms runs two separate systems, and almost every AEO checklist conflates them.

The citation surface answers "what's the best way to do X" with numbered sources. Fed by web crawling. Your pages, schema, llms.txt and robots.txt rules all live here.

The shopping surface answers "best waterproof boots under €150" with a product carousel. On ChatGPT and Google this runs primarily on structured feeds rather than on a crawl of your site.

That's why you can allow every AI crawler, ship perfect JSON-LD, and still be missing from ChatGPT product comparisons.

ChatGPT complicates this, and it's worth stating up front because it cuts against the simple version of the rule. Alongside feed-driven results it runs Shopping Research, an agentic mode that browses in real time. OpenAI states plainly that results are organic and based on publicly available retail sites — reading product pages directly, citing sources, with a separate allowlist for merchants who want to be eligible.

So there are three routes on ChatGPT, not two. Pages are irrelevant to one and load-bearing on another. The lesson isn't "pages don't matter for shopping" — it's that feeds and pages feed different surfaces and neither substitutes for the other.

Who reads what

	ChatGPT	Perplexity	Google AI Mode
Product source	ACP feed, pushed	Live page retrieval	Shopping Graph (Merchant Center)
Reads your page for shopping?	Not for feed-driven results; Shopping Research reads retailer pages	Yes	Secondary — schema.org markup contributes
Index crawler	OAI-SearchBot	PerplexityBot	Googlebot
Training crawler	GPTBot	—	`Google-Extended` (token, not a bot)
Merchant onboarding	Feed access by application; Shopping Research by allowlist	Free, ~5 min	Merchant Center; UCP staged

The OpenAI crawler split is load-bearing and widely misconfigured. GPTBot is training. OAI-SearchBot is search visibility. Blocking "OpenAI" wholesale usually means someone intended the first and accidentally did the second — which removes you from ChatGPT citations entirely, feed or no feed.

User-agent: GPTBot
Disallow: /

User-agent: OAI-SearchBot
Allow: /

Check what's actually hitting you

Don't trust anyone's summary, including this one:

grep -Eo "GPTBot|OAI-SearchBot|ChatGPT-User|PerplexityBot|Perplexity-User|Googlebot" \
  /var/log/nginx/access.log | sort | uniq -c | sort -rn

You want OAI-SearchBot and PerplexityBot showing up regularly — those are the index builders. Their absence usually means a robots.txt rule, a WAF rule, or a CDN bot-management setting doing something you didn't intend.

Worth knowing: firewall blocking is invisible in robots.txt. Your rules can be perfectly permissive while Cloudflare silently rejects the request. The log is the only ground truth.

The geography bit

Two things get reported as one here, and separating them changes the plan.

Shopping features available to users are broad — shoppers in most markets can already ask these engines for product recommendations.

Merchant onboarding is not. Direct ACP feed access runs through an application with staged rollout. UCP checkout began in the US and reached Canada, Australia and the UK by May 2026, arriving by cohort. Perplexity's Merchant Program is free and open anywhere.

So your customers may already be asking about products like yours while your ability to push structured data to two of the three is still queued. Perplexity is the channel where good server-rendered markup produces results today, with no application and no wait.

That reorders the work. Page-level readability first — it's what Perplexity reads now, what OAI-SearchBot indexes for citations now, and what feeds the schema.org half of the Shopping Graph. Feeds second, built and validated so the application is a formality when your region opens.

What I'm not sure about

How much ChatGPT's two shopping surfaces overlap is unclear. Feed-driven results and Shopping Research are documented separately; how presence in one affects the other is not spelled out.
Ranking mechanics are undocumented on all three. Any "top 3 ranking factors" claim here is inference from correlation, not a vendor statement.
Perplexity's crawling practices are contested — Cloudflare alleged undeclared crawlers in August 2025, Perplexity disputed the characterisation. I have no independent basis to adjudicate.
Regional availability moves faster than any published guide. Re-verify before it drives a budget decision.
I build open-source Magento AEO modules, so "prioritise page-level readability" aligns with what my tooling does. Check the claim rather than take it.

Full version with the decision table by merchant type, the Magento-specific paths, and the source list: original post on angeo.dev

Modules are MIT-licensed on Packagist if useful.

ACP vs UCP: two agentic commerce protocols, and why 'which one' is the wrong question

Ievgenii Gryshkun — Fri, 24 Jul 2026 22:51:30 +0000

ACP or UCP? The question assumes you have to pick one. You don't — and by mid-2026 they aren't even doing the same job.

ACP and UCP are not two competing implementations of the same standard. They sit at different layers, and most of the work required for one is the same work required for the other.

Protocol status as of June 2026. Both specs are moving. Verify current spec versions before you implement — I've dated every claim below for that reason.

What changed in March 2026

ACP — the Agentic Commerce Protocol, backed by OpenAI and Stripe — launched as the standard behind ChatGPT Instant Checkout. Agent finds product, agent buys product, merchant stays merchant of record.

In March 2026 that shifted. ACP moved away from native checkout, and what remains in practice is a discovery and feed protocol: a structured, spec-conformant product feed you publish, OpenAI ingests, and ChatGPT uses to decide whether your products belong in an answer.

UCP — the Universal Commerce Protocol, Google-backed, announced at NRF in January 2026 and substantially expanded at Google Marketing Live on 20 May 2026 — went the other direction. It is the live agentic-checkout standard: discovery, cart construction, and transaction, with announced integration across AI Mode, Gemini, YouTube Shopping and Gmail. Early access has been US-first; rollout varies by surface and market.

So: one protocol tells AI systems what you sell. The other lets them buy it.

Side by side

	ACP	UCP
Backers	OpenAI + Stripe	Google
Role in mid-2026	Discovery / product feed	Discovery + agentic checkout
Surfaces	ChatGPT	AI Mode, Gemini, YouTube, Gmail
Merchant artifact	Spec-conformant product feed	`/.well-known/ucp` manifest + signed endpoints
Identity / trust	Merchant application + conformance checks	ECDSA-signed manifest
Availability	Application-based	US-first early access
Merchant of record	You	You

The last row is the one people miss. Neither protocol takes over the transaction relationship. You are still the merchant of record, you still own fulfilment, returns and support. What changes is where the buying intent gets captured.

The part that's actually shared

Here's why "pick one" is a trap. Strip both specs down to what they demand from your backend and you get almost the same list:

Clean, complete product data — SKU, title, description, price, currency, availability, images, identifiers (GTIN/MPN). Both protocols reject or silently deprioritise incomplete records.
Accurate real-time stock and price. A feed refreshed nightly is a feed that lies for 23 hours. Both ecosystems penalise this — one with conformance failures, the other with bad agent experiences.
Explicit machine-readable policies — shipping, returns, warranty. Not a CMS page written for humans.
Crawler and endpoint access that doesn't depend on JavaScript execution.
Structured data on the page itself — the fallback path when feeds are stale or absent.

That's not protocol work. That's catalog hygiene. It survives ACP pivoting again, UCP renaming itself, and whatever the third protocol turns out to be.

The build order I'd argue for

Phase 0 — foundations (do this regardless).
Fix crawler access. Get Product + Offer structured data rendering server-side with availability as a full schema.org URI. Publish an LLM-readable content map. None of this is protocol-specific and all of it pays off in ChatGPT, Gemini and Perplexity today.

Phase 1 — ship the ACP feed.
It's the lower-effort artifact, the audience is already there (ChatGPT handles enormous volumes of shopping-intent queries), and building it forces you to fix the data quality problems you'd hit in UCP anyway. Cron it at a real interval — 15 minutes is a sane starting point for a catalog with moving stock, not nightly.

Phase 2 — prepare the UCP manifest.
Publish /.well-known/ucp, generate your ECDSA signing keys, get the profile validated. Even if agentic checkout hasn't reached your market yet, the manifest is cheap to maintain and the queue is real.

Phase 3 — decide about checkout deliberately.
Letting an agent complete a purchase is a policy decision as much as a technical one: order value caps, confirmation requirements, fraud posture, what happens when an agent gets it wrong. Have that conversation before you flip the switch, not after.

Where the payments problem still sits

Worth stating plainly because it shapes everything: an agent operating over a server-side protocol cannot tokenize a card. Stripe's card flows require a PCI-compliant browser context — Stripe.js, Payment Element — which is fundamentally incompatible with a backend tool call.

Every current agentic-checkout design works around this rather than through it: offline/invoice methods, stored tokens tied to an authenticated customer, or a handoff to a hosted payment page at the last step. Anyone claiming an agent "pays with your card" via a pure API protocol is describing something with a browser hidden inside it.

This is the honest ceiling on agentic commerce in 2026, and it's the thing to design around.

If you're on Magento 2

There's no built-in support for either protocol — Magento gives you full control of the stack and full responsibility for it. There are open-source options for both sides; I maintain some of them (angeo/module-openai-product-feed for ACP, angeo/module-ucp for the UCP profile and signing keys — MIT, Composer). Disclosure: I wrote those, and there are alternatives with different licences and coverage worth comparing.

But module choice is the last 10%. The first 90% is whether your catalog data is actually correct, and no module fixes that for you.

What's your read — is anyone here building against UCP checkout in production yet, or is everyone still in feed-and-wait mode? Genuinely interested in what the early-access experience looks like from the US side.

AI Agent Checkout in Magento 2: Claude Places a Real Order via MCP

Ievgenii Gryshkun — Thu, 09 Jul 2026 16:57:32 +0000

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?

I built angeo/module-mcp-checkout to answer that, and the short version is: yes. This post walks through the full flow, the architecture, and the one problem everyone asks about — payments.

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 same 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

The module exposes these as six MCP tools over a JSON-RPC endpoint:

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 the Magento backend through a secure, rate-limited MCP endpoint.

Security

✅ Bearer Authentication — every MCP request requires a valid Bearer token
✅ Rate limiting — configurable throttling protects store performance
✅ Magento ACL — MCP tools operate within Magento's standard Access Control Layer
✅ HTTPS only — the endpoint is served exclusively over TLS
✅ User confirmation before order placement — place_order is never called autonomously
✅ Configurable agent order limit — merchants set a max order value in admin

Live demo: Claude finds a backpack and buys it

Real session against demo.angeo.dev. The prompt: "I want to buy a Fusion Backpack."

Step 1 — Product discovery. Claude called search_products, then get_product. It identified the Fusion Backpack (SKU: 24-MB02), in-stock at $59.

Step 2 — Cart. create_cart returned a fresh cart_id. add_to_cart confirmed the item — subtotal $59.

Step 3 — Shipping. get_shipping_methods returned Flat Rate — Fixed at $10.

Step 4 — Address. set_shipping_information applied name, street, postcode, city, country, phone, email. Total: $69.

Step 5 — Confirm & place. After explicit user confirmation, 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 control at every step.

The payment problem

This is the question everyone asks, and it deserves an honest answer.

MCP agents can't process card payments directly. Card tokenization requires a PCI-compliant browser form (Stripe.js / Payment Element) — fundamentally incompatible with a server-side MCP tool call. This is the same constraint that killed OpenAI's native agentic checkout: collecting card details through an agent violates PCI scope.

My approach sidesteps this by design. The agent places the order with a deferred payment method (status pending). Payment happens separately:

B2B / wholesale: merchant invoices after order placement — already standard for many stores
Payment Link: the agent generates a Stripe / Mollie / Adyen payment link for the human to complete in-browser. No PCI exposure.
Store redirect: hand off to the store's normal checkout page with the cart pre-filled

No extra platform fees — only standard gateway rates apply. A dedicated get_payment_link tool (Stripe, Mollie, Adyen) is planned for v2.0.0.

Current v1.0.0 scope

Configurable products via child SKU selection — variant tooling coming in v2.0.0
Guest checkout only for now — registered customer support on the roadmap
Card payment handled via deferred payment / payment link handoff
Optional agent order limit configurable in admin

FAQ

Is browser automation required? No. JSON-RPC MCP endpoint — no headless browser, no Selenium, no Playwright.

Is MCP faster than browser automation? Significantly. No page rendering, no DOM parsing. A full checkout completes in under 5 seconds.

Does this work with Adobe Commerce? Yes — Magento Open Source and Adobe Commerce 2.4.x.

Does the agent act autonomously? No. place_order only fires after explicit user confirmation.

Install

composer require angeo/module-mcp-checkout
bin/magento module:enable Angeo_McpCheckout
bin/magento setup:upgrade

MIT-licensed, part of the open-source angeo.dev Agentic Readiness Suite for Magento 2.

Disclosure: I built this module. It's open-source MIT. Genuinely curious what other Magento devs think about agentic checkout as a direction — happy to answer anything about the architecture or MCP tool design in the comments.

Your ChatGPT Traffic Is Hiding in 'Direct' — How to Track AI Search Referrals in Magento 2

Ievgenii Gryshkun — Mon, 06 Jul 2026 20:47:21 +0000

Originally published on angeo.dev. AI platform behavior changes frequently — referrer policies and crawler names may have evolved since publication (July 2026).

You updated your robots.txt. You generated llms.txt. You fixed your Product schema. Your AEO audit score went from 25% to 85%. And then you opened GA4 — and saw nothing unusual.

This is the most common frustration after implementing AEO (AI Engine Optimization) on a Magento 2 store. Not because the work didn't help, but because standard analytics tools were not built to track AI referral traffic. The signals exist — they're just hidden in the wrong buckets.

TL;DR

Since May 13, 2026, GA4 has a native "AI Assistant" channel that auto-detects ChatGPT, Gemini, and Claude referrals — zero config, but only for sessions with an intact referrer
ChatGPT still strips referrers on most link types — in-app browsers, mobile apps, and copy-paste all land in Direct
A custom Channel Group still matters: it catches platforms outside GA4's documented list (Perplexity!) and preserves historical trends (the native channel is forward-only)
The most reliable way to attribute ChatGPT clicks today is still UTM parameters in your llms.txt
Search Console Crawl Stats show GPTBot / OAI-SearchBot activity — a leading indicator that precedes traffic by weeks
If AI traffic converts several times better than organic (early anecdotal data suggests 2–5×), misclassifying it as Direct means you can't measure ROI on any of your AEO work

Why AI traffic disappears in your analytics

Each platform handles referral data differently, which is why no single tracking method covers all of them:

Platform	Referrer passed?	What GA4 sees by default	Crawler UA
ChatGPT	❌ No	Direct / (none)	GPTBot, OAI-SearchBot
Perplexity	✅ Yes	Referral — unclassified	PerplexityBot
Google Gemini	⚠️ Partial	Referral from gemini.google.com	Google-Extended
Claude	✅ Yes	Referral from claude.ai	ClaudeBot
Microsoft Copilot	⚠️ Partial	Referral from copilot.microsoft.com	Bingbot (shared)
ChatGPT Shopping	❌ No	Direct / (none)	OAI-SearchBot

On ChatGPT specifically: behavior depends on where the link appears. Inline links in conversational answers and links opened via the mobile app typically arrive with no Referer header. OpenAI has been appending UTM parameters to some links in ChatGPT Search's "More sources" since mid-2025, but it's not documented as guaranteed behavior. Published estimates of how many ChatGPT sessions arrive with a usable referrer range from ~10% to ~40% depending on the source — verify against your own server logs instead of trusting any single benchmark.

The practical upside: Perplexity, Gemini, and Claude together likely represent more trackable eCommerce referral traffic than ChatGPT right now — and all three are addressable today.

Method 0: GA4's native "AI Assistant" channel (0 minutes)

On May 13, 2026, Google added a native AI Assistant channel to GA4's Default Channel Group. When GA4 detects a referrer matching a recognized AI assistant, it automatically assigns:

Medium: ai-assistant
Campaign: (ai-assistant)
Default Channel Group: AI Assistant — right next to Organic Search, Direct, etc.
Source: stays the originating domain (chatgpt.com, gemini.google.com) so you can still break down by platform

To verify it's live on your property: Reports → Acquisition → Traffic acquisition, set primary dimension to Session default channel group, look for an "AI Assistant" row. If it's missing, expand the date range to 90 days — the rollout was gradual, and zero qualifying sessions is also normal at this stage.

Three limitations to know:

Not retroactive. Everything before May 13, 2026 stays classified as Direct/Referral. No clean YoY comparisons for a while.
Still referrer-dependent. Mobile apps, in-app browsers, copy-paste → still Direct. The structural gap didn't go away; it's just easier to see what you're missing.
Documented coverage is ChatGPT, Gemini, Claude. Some third-party sources claim broader coverage (Perplexity, Copilot, Grok...), but Google's own docs don't consistently confirm it. Treat Perplexity via the native channel as unconfirmed until you see it in your own data.

Method 1: Custom Channel Group (5 minutes)

Still worth it, even with the native channel — mainly for Perplexity coverage and a continuous historical trend line.

GA4 Admin → Data display → Channel groups → Create new channel group
Name it "AI Search", condition type Session source contains — one rule per domain, OR logic between rules
Add the domains below
Save, wait 24–48h (applies to new sessions only)

perplexity.ai          # Perplexity
gemini.google.com      # Google Gemini
bard.google.com        # legacy
claude.ai              # Anthropic Claude
copilot.microsoft.com  # Microsoft Copilot
bing.com/chat          # Bing Chat
you.com                # You.com
phind.com              # Phind
poe.com                # Poe
kagi.com               # Kagi

After saving, go to Traffic acquisition and switch the primary dimension to your new channel group. Most stores discover Perplexity traffic they didn't know existed — it was sitting in Referral all along.

Native channel vs custom group, side by side:

Capability	Native AI Assistant	Custom Channel Group
Setup	None	~5 min
Historical data	Forward-only from 2026-05-13	As far back as configured
Coverage	ChatGPT, Gemini, Claude (documented)	Any domain you add
Referrer required	Yes	Yes
Maintenance	Google maintains list	You update quarterly

Method 2: UTM parameters in llms.txt (30 minutes)

Since ChatGPT strips referrers on most link types, the most practical way to attribute at least part of ChatGPT traffic is UTM parameters on URLs exposed through AI discovery layers — llms.txt and experimental commerce feeds. UTMs reach GA4 regardless of the missing referrer.

# llms.txt — with UTM tracking

# Products
- [Wireless Headphones XM5](https://store.com/headphones-xm5?utm_source=chatgpt&utm_medium=ai_referral&utm_campaign=aeo)
- [Running Shoes ProGrip](https://store.com/shoes-progrip?utm_source=chatgpt&utm_medium=ai_referral&utm_campaign=aeo)

# Categories
- [Headphones](https://store.com/headphones?utm_source=chatgpt&utm_medium=ai_referral&utm_campaign=aeo)

If you're testing experimental OpenAI commerce feed integrations, tag those URLs too — with a distinct source so you can separate feed-driven clicks from organic ChatGPT referrals:

{
  "id": "sku-001",
  "name": "Wireless Headphones XM5",
  "url": "https://store.com/headphones-xm5?utm_source=chatgpt_shopping&utm_medium=ai_feed&utm_campaign=aeo",
  "price": {"amount": 249.00, "currency": "EUR"},
  "availability": "InStock"
}

Known limitation: ChatGPT sometimes renders URLs as plain text rather than clickable links. Users copy-paste, and UTMs often get stripped on paste. UTM tracking captures confirmed intentional clicks — it will undercount total AI-influenced traffic. There's no reliable client-side fix; server logs (Method 4) fill the gap.

A note on llms.txt itself: adoption is still developing and platforms vary in how — or whether — they consume it. Treat it as a best-practice signal layer, not a guaranteed crawler instruction standard. Adding UTMs to it is low-effort and worth doing anyway.

Method 3: Search Console Crawl Stats (2 minutes)

GSC doesn't show AI referral traffic — it shows AI crawler activity, which is a leading indicator that precedes recommendation traffic by days or weeks.

Search Console → Settings → Crawl stats → See all crawl requests, then filter by user agent:

User agent	Platform	Rising crawl frequency means...
`GPTBot`	ChatGPT	Your pages are far more likely to be considered for answers
`OAI-SearchBot`	ChatGPT Search	OpenAI indexing you for real-time results
`Google-Extended`	Gemini	Gemini / AI Overviews data collection
`PerplexityBot`	Perplexity	Content may appear in Perplexity answers
`ClaudeBot`	Claude	Claude retrieval + training

After unblocking AI bots in robots.txt and publishing llms.txt, GPTBot crawl frequency should rise within 1–2 weeks. That's your first measurable confirmation the AEO changes are working — before any traffic hits GA4.

Method 4: Server logs (15 minutes, most accurate)

Server logs capture every HTTP request — including AI crawler visits and referrers where available. It's the only method that confirms GPTBot activity independently of GSC.

# Count AI bot requests
grep -E "(GPTBot|OAI-SearchBot|PerplexityBot|Google-Extended|ClaudeBot)" /var/log/nginx/access.log \
  | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# Which pages is GPTBot crawling most?
grep "GPTBot" /var/log/nginx/access.log \
  | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

# Perplexity referral clicks (real users, not bot)
grep "perplexity.ai" /var/log/nginx/access.log \
  | grep -v "PerplexityBot" | wc -l

High GPTBot frequency on your top product pages is a good signal — those pages are strong candidates for ChatGPT recommendations. On Hypernode hosting, logs live at /var/log/nginx/access.log with daily rotation; the commands work as-is.

Putting it together: the funnel view

Stage	Where to measure	What it means
AI bots crawling	GSC → Crawl Stats	Indexed and eligible for AI recommendations
AI referral sessions (ChatGPT/Gemini/Claude)	GA4 native AI Assistant channel	Users clicking through — forward-only
AI referral sessions (Perplexity + others)	GA4 custom "AI Search" group	Coverage beyond Google's documented list
ChatGPT UTM sessions	GA4 → utm_source=chatgpt	Confirmed intentional clicks
Conversions	GA4 → AI channels → Purchase	Revenue attributable to AEO

In GA4 Explore, build one exploration filtered on channel group = "AI Assistant" OR "AI Search" — a session can only belong to one channel group definition at a time, so there's no double-counting.

If you export to BigQuery (free on all GA4 properties), you can go further: correlate GPTBot crawl events from server logs with session spikes in the following 48 hours, or segment AI sessions by product category to see which parts of your catalog get recommended.

Benchmarks: how much AI traffic is "normal"?

Directional ranges from community reports and early adopter data — not guarantees:

Store profile	AI share of sessions	Primary source
No AEO work	0.1–0.5%	Perplexity (mostly untracked)
Basic AEO (robots.txt + llms.txt)	0.5–2%	Perplexity, Gemini
Strong AEO (schema, descriptions, UTMs)	2–6%	Perplexity, ChatGPT (UTM)
Niche authority store	5–12%	Multiple platforms
B2B / specialist	3–10%	Perplexity, Claude

One anonymised example: a Magento apparel store went from ~0.3% to ~2.1% AI share over ~90 days after four changes — allowing GPTBot, adding llms.txt, rewriting supplier-copy descriptions, fixing Product schema. Perplexity drove most measurable referrals early; ChatGPT attribution stayed partial and UTM-dependent.

The honest part: attribution stays probabilistic

Setting up all four methods gives you a significantly better picture — not a perfect one. The gap is structural:

Gap	Why	Workaround
Dark ChatGPT traffic	No referrer; paste strips UTMs	UTMs catch intentional clicks; logs catch crawls
Safari / privacy browsers	Referer removed cross-site	UTMs bypass referrer policy
In-app browsers	ChatGPT iOS app may pass nothing	None reliable — lands in Direct
Cross-device journeys	See on mobile, buy on desktop	GA4 User ID if logged in
URL canonicalisation by AI	ChatGPT may surface a clean URL	Short UTM values; watch server logs

Practical framing: treat AI traffic measurement as a directional signal. If your AI channel shows 80 sessions this month and 140 next month, the trend is real — even if absolute numbers understate AI-influenced traffic by 40–60%.

Debugging: "I see zero AI traffic"

First, the common AEO gaps: robots.txt blocking GPTBot/OAI-SearchBot, llms.txt returning 404, Product schema missing offers.availability (ChatGPT Shopping skips those products), supplier-copy descriptions AI can't confidently recommend. If those are fixed and your channel group is set up — give it 4–8 weeks; the crawl-to-traffic lag is real.

If bots are crawling but sessions still land in Direct, check: Safari/Firefox ETP/privacy-extension referrer stripping, Cloudflare Transform Rules dropping the Referer, 301/302 redirect chains (referrer dies on hops), GA4 Consent Mode blocking pre-consent data, wrong match type in the channel group condition, Magento URL rewrites stripping UTMs.

Quick diagnostic: visit a product URL with ?utm_source=test_ai&utm_medium=debug from incognito, check GA4 Realtime → Traffic sources. UTM shows up → GA4 is fine, the problem is upstream. Doesn't show → the problem is your data stream or Magento URL handling.

I maintain a set of MIT-licensed open-source Magento 2 modules for AEO (llms.txt generation, robots.txt AI-bot management, structured data, MCP/UCP endpoints) — all on Packagist under angeo/ and GitHub. Questions about the setup above — happy to answer in the comments.

Adobe Commerce 2.4.7 EOL: the upgrade notice lists 2 options. There are 4.

Ievgenii Gryshkun — Fri, 26 Jun 2026 17:02:52 +0000

If you run Adobe Commerce on Cloud and got the end-of-life notice for 2.4.7, here's the short version: the upgrade enforcement date is June 1, 2028. After that, Adobe stops maintaining Cloud environments still on 2.4.7 and reserves the right to decommission them.

Per Adobe's published lifecycle table, the 2.4.7 timeline is:

Milestone	Date
End of standard support	May 31, 2027
End of extended support	May 31, 2028
Cloud upgrade enforcement	June 1, 2028

The notice is real. But it quietly narrows your options to two when there are four.

Why the deadline exists (and it's a good reason)

2.4.7 runs on PHP 8.2. PHP 8.2 reaches end of life on December 31, 2026 — after that the PHP project ships no more security patches for it. Adobe hosts the infrastructure, so Adobe owns its PCI compliance. Running an EOL PHP runtime on a payment-handling store is a PCI DSS problem, not just a hygiene one. That's the actual logic behind enforcement, not pure commercial pressure.

The four paths

Adobe officially lists two:

Upgrade to the latest Adobe Commerce on Cloud — 2.4.8 (supported to May 2028) or 2.4.9
Migrate to Adobe Commerce as a Cloud Service — SaaS, fully managed, no future enforcement deadlines

Two more exist outside Adobe's scope, fully compatible with the same Magento 2 core, with no license fee:

Magento Open Source 2.4.9 — same core, self-hosted, $0 license
Mage-OS 3.x — community-governed fork, $0 license, ships security patches on a faster community cadence

Adobe's notice will never mention 3 and 4. That doesn't make them less viable.

What changes with each

Path	License	Hosting	Recurring enforcement?
Adobe Commerce on Cloud	Revenue-based (~$40K–$190K+/yr)	Adobe-managed	Yes
Adobe Commerce Cloud Service	SaaS subscription	Adobe full-stack	No
Magento Open Source 2.4.9	$0	Your own	No
Mage-OS 3.x	$0	Your own	No

All four require the same infrastructure work: 2.4.8/2.4.9 need PHP 8.3+ and OpenSearch 2.19 (Elasticsearch is deprecated). That work happens regardless of path.

The license math

Adobe Commerce is revenue-participation — the bill scales with GMV automatically:

Under $1M GMV → ~$40K/yr on Cloud
$1M–$5M GMV → ~$55K–80K/yr on Cloud
$5M–$25M GMV → up to ~$190K/yr on Cloud

For a $3M GMV store moving to Magento Open Source or Mage-OS, the license line goes to zero. Over three years the difference comfortably exceeds $150K.

(Figures are independent third-party estimates; Adobe doesn't publish official pricing.)

What actually transfers

Because Adobe Commerce and Magento Open Source share the same Magento 2 core, moving between them is not a replatform. The CLI commands are identical, every Marketplace extension installs the same way, and theme/catalog/checkout logic carries over.

What needs planning when you drop the Adobe commercial layer:

Native B2B suite — company accounts, shared catalogs, quote-to-order need extensions or custom dev
Live Search / Sensei — replaceable with OpenSearch + best-of-breed tools
PHP & search engine upgrade — required on all paths anyway

The Mage-OS detail worth knowing

A common stale claim is "Mage-OS only has 2.3 with PHP 8.5." That's already outdated. Mage-OS 3.0 and 3.1 are out, built on Magento Open Source 2.4.9, with PHP 8.5 support alongside 8.3 and 8.4.

One gotcha most write-ups miss: Mage-OS 3 dropped PHP 8.2 support — minimum is now PHP 8.3 (8.4 recommended), and Symfony moved 6.4 → 7.4 LTS, so extensions that extend Symfony CLI command classes may need updates. Worth scoping before you commit.

Fresh install is one command:

composer create-project --repository-url=https://repo.mage-os.org/ \
  mage-os/project-community-edition

For an existing Magento 2.4.8+ store, Mage-OS ships an automated migration script (run it in developer mode on staging first). Mage-OS also publishes security updates within days of Adobe's monthly Patch Tuesday, rather than waiting on Adobe's quarterly cadence.

A worked $4M GMV migration

Typical mid-market project:

Platform: Adobe Commerce on Cloud 2.4.7 → Magento Open Source 2.4.9 + Hyvä
Duration: ~6 weeks (audit, migration, QA, staged cutover)
License savings: ~$72K/year
Hosting cost reduction: ~38% vs Adobe Cloud
Checkout downtime: none via staged cutover

The heaviest lift is not the platform swap — it's replacing Adobe-specific features (B2B workflows, Live Search) and modernising the infra stack.

Who should stay on Adobe Commerce

This isn't anti-Adobe. Stay if you're:

Large enterprise B2B relying on native company accounts, shared catalogs, quote-to-order
A team that needs Adobe SLAs for procurement or compliance
Deep in Adobe Experience Cloud — Analytics, Target, Real-Time CDP
High-GMV where Live Search + managed cloud measurably beat the license fee in conversion lift

For those, Options 1 or 2 are rational. The license only looks expensive when you're not using what it buys.

While the stack is open: AI crawler access

One efficiency note, since a 2.4.7 migration means re-deploying robots.txt, schema, and frontend templates anyway. A default Magento 2 install — any edition — blocks AI crawlers in robots.txt, has no llms.txt, and ships incomplete Product JSON-LD. That means it's effectively invisible to ChatGPT, Gemini, and Perplexity, even if it ranks #1 on Google. The fixes touch the same files you're already editing. There's an open-source CLI to check where a store stands if you want to fold it into the same project. Optional, unrelated to the lifecycle decision — just cheaper to do once.

The clock

June 1, 2028 sounds far away. A properly scoped mid-market migration runs 6–10 weeks. The decision comes down to one question: do you need Adobe's commercial layer enough to justify a fee that scales with revenue? If yes → Option 1 or 2. If no → 3 or 4.

Full breakdown of all four paths with a feature matrix and FAQ: angeo.dev/adobe-commerce-2-4-7-end-of-life-options/

Lifecycle dates from Adobe's published policy. License figures are independent third-party estimates — Adobe doesn't publish official pricing. Verify against the Adobe Commerce lifecycle policy and request a direct quote before budget decisions.

Magento AI Brand Visibility: Does ChatGPT Recommend Your Store?

Ievgenii Gryshkun — Sat, 13 Jun 2026 07:17:29 +0000

Note: set published: true when you're ready. The canonical_url above tells Google the original lives on angeo.dev, so this cross-post won't compete with it. Replace cover_image with the uploaded featured image URL.

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 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're not in that shortlist, you're 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 — best signal for what the internet says about you now.	No
Gemini (Google)	Tied into Google's ecosystem; generous free tier.	Yes
Groq	Fast, free Llama hosting — ideal for zero-cost testing.	Yes

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

Mentioned — your brand or a configured alias appears anywhere in the answer.
Recommended — the model actively suggests you (recommendation language near your mention, or you appear in a ranked list).
URL cited — your domain is referenced in the response, the strongest trust signal.
First result — you appear in the first quarter of the answer, i.e. top-of-mind.
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.

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.
Single Query Tester — send one prompt to one provider and inspect the raw response.

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 — and it can 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 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 — 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. Serialization uses Magento's SerializerInterface throughout.

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 (angeo/module-llms-txt) and keep your store name consistent across every page.
Domain not cited? Strengthen backlinks and reference your canonical URL in structured data and llms.txt.
Not being recommended? Improve product content quality and implement review schema.
Appearing late in answers? Build topical authority with category-focused content.

FAQ

Is the module free? Yes — MIT licensed. 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, Claude, Perplexity, Gemini and Groq. Enable any combination.

Will audits cost a lot in API fees? Not if configured sensibly. Results are cached, you control how many prompts run, and total queries equal enabled providers × active prompts.

What Magento versions are supported? 2.4.6, 2.4.7 and 2.4.8 (Adobe Commerce and Mage-OS), PHP 8.2–8.4. Requires angeo/module-aeo-audit v3.0+.

How is this different from SEO tools? SEO tools measure rankings and crawlability. This measures what AI assistants actually say when asked shopping questions.

AI assistants are already recommending stores in your category — the only question is whether they're recommending you. Install angeo/module-aeo-brand-visibility, run your first audit, and find out in minutes. You can also run a free 30-second AEO audit.

Originally published at angeo.dev.

The 4-Layer Magento 2 AEO Stack: Making Your Store Visible to ChatGPT, Claude & Gemini (2026)

Ievgenii Gryshkun — Sat, 06 Jun 2026 19:06:09 +0000

I've written here before about fixing robots.txt for the AI bots and checking your store's ChatGPT visibility with a free audit module. This post zooms out and puts the whole thing in one place: the four layers that decide whether an AI assistant can find, trust, and recommend your Magento store — and the honest data on which layers actually matter in 2026.

Default Magento 2 typically scores around 23% on an AEO audit across the stores I've measured. Not because anything is broken — because every one of these signals ships off by default and nobody flipped them on.

Here's the stack, in priority order.

Layer 1 — robots.txt: you're probably blocking the bots you want

The most common failure, and almost always accidental. A robots.txt written for Google in 2019 says nothing about the AI fleet, and some security/hardening configs block unknown bots — which now includes the crawlers feeding ChatGPT, Claude, Gemini, and Perplexity.

There's no single user-agent to allow. In 2026 you're dealing with ~10 distinct AI bots across four platform families. Minimal explicit allow-list:

User-agent: GPTBot
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: ChatGPT-User
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Google-Extended
Allow: /

Sitemap: https://yourstore.com/sitemap.xml

Key gotcha: Google-Extended is not Googlebot. Blocking it doesn't touch your Google ranking — it only governs whether Google's AI products may use your content. Tons of sites blocked it during the 2023–24 anti-scraper panic and never revisited. If you want AI visibility, reconsider it.

Highest-leverage 20 minutes in the whole stack. Do it first.

Layer 2 — JSON-LD: Magento ships the wrong format and skips the one field that matters

This one is Magento-specific and it's the difference between being eligible for AI Shopping answers and being silently dropped.

Default Magento 2 outputs product structured data as microdata, not JSON-LD. AI extraction systems strongly prefer JSON-LD — a clean, self-contained block they can parse without reconstructing meaning from scattered HTML attributes.

And the field that quietly kills you:

offers.availability is frequently missing — and ChatGPT Shopping will skip a product with no availability signal entirely.

From the model's side, it's assembling a purchasable recommendation. A product it can't confirm is in stock is a liability, so it drops it. No warning. You just don't appear.

Correct, AI-friendly block:

<script type="application/ld+json">
{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Pre-Seasoned Cast Iron Skillet 12\"",
  "sku": "CAST-SKILLET-12",
  "brand": { "@type": "Brand", "name": "YourBrand" },
  "offers": {
    "@type": "Offer",
    "url": "https://yourstore.com/cast-iron-skillet-12",
    "priceCurrency": "EUR",
    "price": "59.00",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.7",
    "reviewCount": "212"
  }
}
</script>

Three traps:

Don't inject schema via GTM. AI crawlers generally don't execute JavaScript, so tag-manager-injected schema is invisible to them even though it validates in DevTools. It must be server-rendered.
Hyvä themes ship with zero product schema by default — neither microdata nor JSON-LD. If you migrated to Hyvä for speed, you may have silently dropped your structured data. Check now.
Bind availability to real stock, never a hardcoded InStock. A model that recommends your out-of-stock item once learns to distrust your feed.

Verify it's in the raw HTML (no JS):

curl -s https://yourstore.com/your-product | grep -A30 'application/ld+json'

Nothing returned = the AI layer sees nothing.

Layer 3 — llms.txt: ship it, but not for the reason you've been sold

llms.txt is a Markdown file at your root giving AI systems a curated map of your store — to LLMs what robots.txt is to crawlers, but editorial rather than access-control.

Now the honest part. The "llms.txt boosts your AI rankings" pitch isn't supported by 2026 data:

A 300k-domain study found ~10% adoption; among the 50 most AI-cited domains, only one had the file.
One vendor logged 62,100 AI bot visits over 90 days — 84 hit llms.txt. That's 0.1%. Another tracking 500M+ bot events found GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot and Google-Extended overwhelmingly skip it and crawl HTML directly.
OpenAI, Anthropic, and Perplexity haven't committed to reading it automatically.

So why ship it? Because it's a Business-to-Agent (B2A) play, not an SEO play. Agentic and IDE-style tooling already fetches it, agentic commerce is heading the same way, and conventions like this often get published before platforms formally commit (robots.txt predated official search-engine support). It's half a day of cheap insurance.

# YourStore

> Premium cast iron and carbon steel cookware. EU-based, ships across Europe,
> 30-day returns, mid-range pricing.

## Categories
- [Cast Iron Skillets](https://yourstore.com/cast-iron)
- [Dutch Ovens](https://yourstore.com/dutch-ovens)

## Buying Guides
- [Cast iron vs carbon steel](https://yourstore.com/guides/cast-vs-carbon)

## Policies
- [Shipping & Returns](https://yourstore.com/shipping)

Ship it, spend the half day, then stop optimizing it and put your energy into Layers 1, 2, and 4. And remember: a stale llms.txt is worse than none — wrong stock claims train models to distrust you.

Layer 4 — ACP & UCP: the part that's actually about money

The 2026 shift bigger than schema tweaks: AI is moving from discovery ("here are some pans") to transaction ("I bought the pan for you"). Two protocols define that layer, and Magento merchants — unlike Shopify merchants — wire it up themselves.

ACP (OpenAI + Stripe) — live in ChatGPT since late 2025; settled into a discovery-and-feed role. You submit a spec-compliant feed, ChatGPT surfaces products, checkout uses delegated single-use payment tokens, with a transaction fee on completed Instant Checkout orders.
UCP (Google + Shopify + 20-plus partners incl. Walmart, Target, Visa, Mastercard) — announced at NRF Jan 2026, expanded at Google Marketing Live in May. Broader, protocol-agnostic (REST, MCP, A2A), spanning discovery → cart → checkout → post-purchase across Google AI Mode, Gemini, YouTube, Gmail. Agents discover capabilities via /.well-known/ucp.

Reality check:

It's not "pick one." They target different agent ecosystems; dual-protocol merchants reportedly see meaningfully more agentic traffic.
Most groundwork is shared — clean schema, an accurate live feed, defined shipping/return/pricing policies are prerequisites for both and survive any spec reshuffle (ACP already pivoted away from native checkout once).
Sensible Magento order: solid Layers 1–3 → ship ACP feed → prepare UCP manifest.

Shopify gets much of this by partnership default. Magento/Adobe Commerce: you own the stack — full control, full responsibility.

TL;DR priority order

Fix robots.txt so the AI fleet can crawl you. (~20 min, highest leverage)
Emit server-rendered JSON-LD with a live offers.availability. (Hyvä users: confirm you have any schema.)
Verify with no-JS curl. Not in raw HTML = invisible.
Ship llms.txt as cheap B2A insurance, then leave it.
Build the shared commerce substrate, attach ACP, then UCP.

Google decides whether you rank. AI engines increasingly decide whether you exist in the answer. Two separate jobs now.

The open-source modules behind this (AEO audit CLI, llms.txt generator, multi-store AI description tooling) are on Packagist and documented at angeo.dev. The llms.txt and ACP/UCP figures come from independent 2026 studies — verify current spec versions as you implement, this area moves monthly.

If you've pulled your own AI-bot server logs on a Magento store, drop the numbers in the comments — real crawler data is still scarce and I'd like to compare.

llms.txt for Magento 2: Free vs Paid Modules (2026 Review)

Ievgenii Gryshkun — Mon, 01 Jun 2026 07:06:32 +0000

This is a cross-post. The original — with the full module-by-module comparison table, feature breakdown, and FAQ — is on angeo.dev.

AI systems are increasingly shaping how users discover products.

Instead of browsing category pages, users now ask:

"best hiking boots under €150"

and get a synthesized answer immediately.

This shift creates a new problem for eCommerce: your store content is no longer consumed only as HTML. llms.txt is an attempt to provide AI systems with a cleaner, structured summary of a website.

TL;DR

Multiple Magento 2 llms.txt solutions exist (free and paid)
Differences are mostly about workflow, not output quality
There is no confirmed evidence that llms.txt impacts search rankings
Value comes from better AI interpretation of store structure
JSONL-style structured feeds may become more important long-term

Why this matters

Modern LLM-based assistants compress pages, reconstruct product context, and may misinterpret or ignore important catalog structure.

This can lead to:

outdated product descriptions in AI answers
missing categories
incorrect pricing context

llms.txt tries to reduce that ambiguity by providing a simplified representation of the store.

What is llms.txt?

A llms.txt file is a Markdown-based endpoint typically located at:

https://yourstore.com/llms.txt

It can include:

store overview
category links
product references
policies and informational pages

It is not a formal standard and is still evolving.

llms.txt vs sitemap.xml vs robots.txt

File	Purpose	Consumers
robots.txt	crawler rules	search engines, bots
sitemap.xml	URL discovery	search engines
llms.txt	content summary	AI systems (varies)

These are complementary layers, not replacements.

Does it improve SEO?

There is no verified evidence that llms.txt directly influences Google rankings.

Its impact is more likely indirect:

clearer AI summaries
more consistent product descriptions in LLM outputs
reduced hallucination risk in catalog interpretation

Magento 2 implementation approaches

In practice, implementations fall into three categories.

1. Manual file (small stores)

Simple Markdown file maintained by hand. Works well when:

catalog changes rarely
under 50–100 products
no automation required

2. Admin-driven modules (business teams)

Paid extensions usually add an admin UI, content selection controls, scheduling (cron), and multi-store support. Useful when marketing teams manage content directly.

3. Developer / automation-driven modules

Open-source or CLI-based tools typically provide CLI generation, cron updates, and JSONL output in some cases. This approach fits dynamic catalogs better.

For the full feature-by-feature comparison of specific paid and free modules (Magedelight, Webkul, Plumrocket, Eleventex, Magefan, and the open-source option), see the complete comparison table on angeo.dev.

Example structure

A typical llms.txt might look like:

# Store Name

## Categories
- Hiking: https://store.com/hiking
- Climbing: https://store.com/climbing

## Featured Products
- Trail Boot X3 — €149 — waterproof hiking boot
- Summit 40L Pack — €89 — lightweight backpack

## Policies
- Shipping: EU delivery 2–3 days
- Returns: 30 days

What surprised me during research

A few observations stood out:

Most vendor implementations are structurally very similar
Marketing differences are larger than technical differences
JSONL-style structured output is rarely implemented, despite being more machine-friendly
There is still no confirmed adoption standard among major AI platforms

In other words: the ecosystem is early and still converging.

Key takeaway

For most Magento stores:

You don't need a complex solution to start
Manual or lightweight generation is often enough
Automation only matters at scale or high change frequency

The real long-term value is not the file itself, but how consistently your product data is structured for machines.

Final thought

llms.txt should not be treated as a magic SEO layer. It is better understood as:

a compatibility layer between eCommerce content and AI systems

Whether it becomes important depends less on Magento and more on how AI platforms evolve ingestion of structured web data.

Full comparison with module table, pricing, and FAQ: angeo.dev/llms-txt-magento-2-free-vs-paid-module-comparison/

Shopify vs Magento for AI Commerce in 2026: Platform-Mediated vs Merchant-Controlled AEO

Ievgenii Gryshkun — Thu, 28 May 2026 16:16:18 +0000

In March 2026, Shopify positioned its eligible merchants for default discovery inside ChatGPT via Agentic Storefronts — no per-merchant setup required. Two months later, the same week Shopify reported its fastest quarterly revenue growth in four years, the stock fell 16%.

Both facts are true. 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 developers and architects working with Adobe Commerce, Magento 2, or any non-Shopify e-commerce stack, the question is narrower than the stock story: which architecture gives the merchant the most controllable path to AI commerce visibility — and what does the implementation actually look like in code?

This article frames the answer through a single distinction: platform-mediated AI distribution (Shopify's bet) versus Merchant-Controlled AEO (the approach Magento merchants build themselves, and increasingly the more defensible long-term position).

Read the full version with embedded diagrams on angeo.dev.

Key findings (as of May 2026)

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.
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.
Both reach the same AI channels. ChatGPT, Microsoft Copilot, Google AI Mode, Gemini, and Perplexity are technically accessible from either platform.
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.
Auditability differs sharply. Magento's AEO signals are inspectable with one CLI command. Shopify's distribution layer is largely opaque to the individual merchant.
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 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 — 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 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, 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× — 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

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:

robots.txt blocks AI crawlers — default wildcard rules prevent OAI-SearchBot, PerplexityBot, and Google-Extended from accessing the store
No llms.txt — no machine-readable catalog map is present
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.

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:

Default Magento is invisible. Blocked AI bots, missing llms.txt, incomplete schema, and no ACP feed compound into zero retrieval surface.
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

Capability	Shopify	Magento (configured)	Magento (default)
ChatGPT Shopping (ACP)	✅ Platform-level via Agentic Storefronts	✅ Manual — ACP feed + application	✗ Not configured
Perplexity discovery	✅ Via Shopify Catalog integration	✅ Via llms.txt + PerplexityBot access	✗ Bot blocked by default
Google AI Mode / Gemini	✅ Via Agentic Storefronts opt-in	✅ Via Google Merchant Center + Google-Extended access	⚠ Partial
Microsoft Copilot	✅ Active integration	⚠ Requires custom ACP feed configuration	✗
MCP (Model Context Protocol) live agent access	✅ Native in Shopify Admin	✅ Via angeo/module-openai-product-feed-api	✗
llms.txt	⚠ No native generation	✅ angeo/module-llms-txt — per store view	✗
Product JSON-LD schema	✅ Better defaults than Luma — incomplete for full ACP compliance	✅ angeo/module-rich-data — availability, aggregateRating	⚠ Missing offers.availability
AI order attribution	✅ Native in Shopify Analytics	⚠ Requires custom observer to persist to sales_order	✗ GA4 dark traffic only
robots.txt AI bot access	✅ Managed by Shopify	✅ angeo/module-robots-txt-aeo	✗ Blocked by default
Multi-store / B2B / custom data	⚠ Limited without Shopify Plus	✅ Native — multi-store, B2B, ERP integration	✅ Same
AEO audit CLI	⚠ No CLI audit — manual checking only	✅ angeo/module-aeo-audit — 9 signals, one command	✅ Same

Where Shopify's advantage is real

Platform-level distribution via ACP

The Shopify–OpenAI partnership, based on public announcements, is a structural distribution advantage — not a parity feature. Per Shopify's documentation, eligible merchants were positioned for default ChatGPT discoverability through Agentic Storefronts and the Agentic Commerce Protocol without individual action. No equivalent arrangement exists for Adobe Commerce or Magento merchants. Adobe has not announced a comparable platform-level integration with any AI shopping platform.

Native AI attribution

Shopify Analytics natively filters sessions and orders by AI referrer. For Magento, even basic AI attribution requires custom observer code to persist referrer data to sales_order. The measurement infrastructure Shopify includes by default takes several hours of custom development on Magento.

Speed to AI visibility

For a merchant starting from zero, Shopify's path to AI commerce visibility is measured in hours — or zero, given Agentic Storefronts default activation. For Magento, the path requires sequential steps: AEO audit, robots.txt fix, llms.txt generation, schema update, ACP feed generation, merchant application, and OpenAI conformance review. Total elapsed time: days to weeks.

The Shopify thesis in one sentence: If you accept platform-mediated AI distribution, Shopify delivers it faster and more completely than any alternative on the market.

Where Magento's advantage is real

Control and auditability — the Merchant-Controlled AEO position

Every AI signal in Magento's AEO stack is explicitly configured, testable, and auditable with a single CLI command (see the audit output above). On Shopify, AI visibility is largely a black box. You can observe whether products appear in ChatGPT responses. You cannot inspect what ACP feed payload Shopify is transmitting for a specific variant, verify the exact format OpenAI is receiving, or audit which products are failing conformance checks and why.

Multi-store architecture

Shopify's AI capabilities are primarily designed for single-brand storefronts. For merchants running multiple stores with different catalogs, languages, currencies, or B2B price books — Magento's native multi-store architecture provides per-store control over every AEO signal. Separate llms.txt per store view, different schema configurations per locale, precise ACP feed control per market.

Open standards, no vendor lock-in

The signals Merchant-Controlled AEO is built on are open standards:

robots.txt — 30-year-old RFC
JSON-LD — W3C standard
Agentic Commerce Protocol (ACP) — OpenAI's open spec, adoptable by any merchant
Model Context Protocol (MCP) — Anthropic's open spec
llms.txt — emerging community convention

A merchant running Merchant-Controlled AEO reaches any AI engine that speaks these protocols — present and future. A merchant on Shopify reaches the platforms Shopify has agreements with. The first scales with the protocol layer; the second scales with the platform's BD team.

Data ownership

When a Shopify merchant uses Agentic Storefronts, their product data — pricing, inventory, variant configuration — flows through Shopify's infrastructure to AI platforms via ACP. The merchant does not control the update frequency beyond what Shopify allows, or verify the representation of their products in AI responses. On Magento, the ACP feed is generated locally, validated locally, and transmitted directly. The merchant controls exactly what AI platforms receive.

The Magento thesis in one sentence: If you want to own the infrastructure between your catalog and AI platforms — and audit it — Merchant-Controlled AEO on Adobe Commerce is the only mainstream option that delivers it.

The gap neither platform fully solves

Both Shopify and Magento share a structural limitation independent of platform choice: JavaScript rendering.

AI extraction systems do not reliably execute client-side rendering. Shopify's standard product themes use JavaScript for variant selection and dynamic content. Magento's Luma theme uses RequireJS tabs that collapse the product description on load.

In both cases, content hidden behind JavaScript is often invisible to AI extraction pipelines — regardless of how comprehensive the ACP structured data feed is. The feed provides product data for shopping interfaces; crawled page content provides context for retrieval and editorial recommendations. Both matter. Agentic Storefronts solve the feed discovery problem. They do not solve the on-page extraction problem for content-based AI visibility.

Which platform for which merchant

Merchant profile	Better fit	Primary reason
DTC brand, <10k SKUs, US market, speed priority	Shopify	Agentic Storefronts positions catalog for ChatGPT by default via ACP
Multi-store, multi-language, EU / APAC primary	Magento	Per-store AEO configuration; Shopify AI features US-first
B2B manufacturer or distributor	Magento	Complex catalog depth, B2B pricing, ERP integration
Mid-market brand, existing Shopify store	Shopify	Native AI attribution, ACP feed management, Copilot integration live
Enterprise Adobe Commerce, technical team	Magento (Merchant-Controlled AEO)	Data ownership, auditability, custom AEO implementation

The real shift isn't Shopify vs Magento

The platform debate is the surface. The deeper question — the one that will define commerce infrastructure for the next decade — is whether AI commerce becomes platform-mediated or merchant-controlled.

Shopify is betting on centralized AI distribution. Agentic Storefronts, native ACP syndication, Shopify-managed MCP endpoints, AI attribution baked into Shopify Analytics — every piece reinforces a single architectural premise: the platform sits between the merchant and the AI layer, and that is the value proposition.

Adobe Commerce / Magento 2 still allows direct infrastructure ownership. The ACP feed is generated locally. The MCP server runs on the merchant's stack. The llms.txt is regenerated by the merchant's cron. The AEO audit is the merchant's CLI command. Every signal in the AI commerce pipeline is the merchant's to inspect, change, version-control, and migrate.

For SMB DTC, platform-mediated distribution is probably the right trade. The merchant gets ChatGPT visibility without learning ACP. Shopify takes the operational complexity.

For mid-market and enterprise — especially merchants with multi-store architecture, B2B obligations, regulatory locality requirements, or strategic catalog data that should not transit through a third-party distribution layer — Merchant-Controlled AEO is increasingly the more defensible position. Not because Shopify's offering is weak, but because the value of owning the infrastructure between your catalog and the AI layer grows as that layer becomes more economically significant.

Shopify won the first round of AI commerce distribution. The second round — retrieval quality, content accuracy, citation authority, attribution measurement, multi-channel feed control — is more level, and increasingly favors merchants who can own and audit their stack.

In 2026, the choice between platform-mediated AI distribution and Merchant-Controlled AEO is more consequential than the choice between storefront features themselves.

This article was originally published on angeo.dev with embedded architecture diagrams and AEO score progression charts. The angeo/module-aeo-audit checks all 9 Merchant-Controlled AEO signals for Adobe Commerce / Magento 2 stores in one CLI command.