Coder Legion - Recent posts tagged magento2

How to Let an AI Agent Complete a Magento 2 Checkout via MCP

Thu, 09 Jul 2026 17:04:21 +0000

AI agents can already find products in your store. This tutorial shows how to let them actually buy — completing a full guest checkout in Magento 2 through the Model Context Protocol (MCP), with no browser automation.

We'll use angeo/module-mcp-checkout, an open-source MIT module, and walk through the tool sequence, the payment problem, and how to install it.

What you'll build

A Magento 2 store that exposes checkout as six MCP tools, so an AI agent (Claude, ChatGPT, or any MCP client) can:

Search products
Create a cart and add items
Get shipping methods
Set the shipping address
Place a real order — after user confirmation

The MCP tool sequence

Every checkout runs the same sequence. Each call maps directly to a Magento service-layer operation — no browser, no session, no cookies.

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 SKU
get_shipping_methods()     → estimate delivery options
set_shipping_information() → apply address + method
place_order()              → submit cart → order_number

Step 1 — Install the module

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

This exposes a JSON-RPC MCP endpoint at https://your-store.com/mcp with Bearer auth, rate limiting, and logging built in.

Step 2 — Connect an AI agent

In Claude: Settings → Connectors → Add custom connector, then paste your endpoint URL. In ChatGPT: enable Developer Mode, then add it as a custom app. The same endpoint works with Perplexity, Grok, and Mistral too — MCP is an open standard.

Step 3 — Run a checkout

Ask the agent: "Find me a backpack and help me check out." It will call search_products, then walk through cart, shipping, and confirmation. Here's the response from a real place_order call:

{
  "order_number": "000000005",
  "status": "pending",
  "grand_total": 69,
  "currency": "USD"
}

The order lands in your Magento admin like any other.

The payment problem (important)

MCP agents can't process card payments directly. Card tokenization needs a PCI-compliant browser form — incompatible with a server-side MCP tool call. This is exactly what forced OpenAI to pull its native agentic checkout.

The workaround: the agent places the order with a deferred payment method (status pending), and payment is handled separately — a merchant invoice, a Stripe/Mollie/Adyen payment link, or a redirect to the store's normal checkout page. The whole agent flow stays outside PCI scope. No extra fees beyond standard gateway rates.

Security notes

Bearer authentication on every request
Configurable rate limiting
Operates within Magento's standard ACL
HTTPS only
place_order never fires without explicit user confirmation

Current scope (v1.0.0)

Guest checkout only (registered customer support planned)
Configurable products added by child SKU
Deferred payment / payment link handoff
Optional agent order limit in admin

Wrapping up

That's a full agentic checkout in Magento 2 — no Selenium, no Playwright, no scraping. The module is MIT-licensed and part of the open-source angeo.dev Agentic Readiness Suite for Magento 2 / Adobe Commerce.

Have you tried building MCP tools for commerce? I'd be curious how others are handling the payment handoff — drop a comment.

Tracking ChatGPT, Perplexity & Gemini Traffic in Magento 2 (GA4 Guide, 2026)

Mon, 06 Jul 2026 21:18:09 +0000

The problem: you did the AEO work — robots.txt allows GPTBot, llms.txt is live, Product schema is complete — and GA4 shows... nothing. That's not because the work failed. It's because AI referral traffic hides in the wrong buckets: ChatGPT clicks land in Direct, Perplexity clicks land in generic Referral.

Here are four methods, from zero-effort to most-accurate.

1. GA4's native "AI Assistant" channel (new — May 2026)

GA4 now auto-classifies ChatGPT, Gemini, and Claude referrals into a native AI Assistant channel (medium ai-assistant). No setup. Check it: Reports → Acquisition → Traffic acquisition → primary dimension "Session default channel group".

Caveats:

Forward-only — nothing before 2026-05-13 is reclassified
Referrer-dependent — mobile apps, in-app browsers, copy-paste still show as Direct
Documented coverage is ChatGPT/Gemini/Claude only. Perplexity is not confirmed — verify in your own data

2. Custom Channel Group (5 min — covers Perplexity)

GA4 Admin → Data display → Channel groups → new group "AI Search". One condition per domain, Session source contains, OR between rules:

perplexity.ai
gemini.google.com
claude.ai
copilot.microsoft.com
you.com
phind.com
poe.com
kagi.com

Applies to new sessions after 24–48h. Most stores immediately discover Perplexity traffic that was sitting in Referral all along. Keep this running in parallel with the native channel — it preserves your historical trend line (the native channel doesn't).

3. UTM parameters in llms.txt (the only real ChatGPT fix)

ChatGPT strips referrers on most link types, so the only reliable attribution is UTMs on URLs you expose to AI systems:

# llms.txt
- [Wireless Headphones XM5](https://store.com/headphones-xm5?utm_source=chatgpt&utm_medium=ai_referral&utm_campaign=aeo)

Limitation: when ChatGPT renders the URL as plain text, users copy-paste and UTMs get lost. UTMs capture confirmed clicks, not total AI-influenced traffic.

4. Server logs (most complete picture)

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

# Which pages GPTBot crawls most (recommendation candidates)
grep "GPTBot" /var/log/nginx/access.log \
  | awk '{print $7}' | sort | uniq -c | sort -rn | head

# Real Perplexity users vs the bot
grep "perplexity.ai" /var/log/nginx/access.log | grep -v "PerplexityBot" | wc -l

Bonus leading indicator: Search Console → Settings → Crawl stats → filter by GPTBot / OAI-SearchBot. Crawl frequency rises 1–2 weeks after you unblock the bots — traffic follows weeks later.

What to expect

Directional benchmarks (community/early-adopter data, not guarantees): stores with no AEO see ~0.1–0.5% AI share of sessions; basic AEO (robots.txt + llms.txt) 0.5–2%; strong AEO (schema, rich descriptions, UTMs) 2–6%; niche authority stores 5–12%.

And be honest with stakeholders: attribution stays probabilistic. Safari strips referrers, in-app browsers pass nothing, cross-device journeys are invisible. Track the trend, not the absolute number — if AI sessions go 80 → 140 month-over-month, that trend is real even if it undercounts by half.

Full version with debugging flowcharts and a GA4 Explore dashboard walkthrough: angeo.dev. Open-source Magento 2 AEO modules (llms.txt, robots.txt, schema): Packagist `angeo/`.*

The Magento product description that AI can't read

Fri, 15 May 2026 07:26:22 +0000

Originally published on angeo.dev

You installed robots.txt rules for GPTBot. You generated llms.txt. You added Product schema. The AEO audit is green. ChatGPT still recommends your competitor.

The problem is not what you added. It is how Magento renders product content — and whether AI extraction systems can actually reach it.

The extraction layer problem

AI recommendation systems don't browse your store like a customer. They fetch raw HTML, parse it through an extraction layer, chunk the content into retrievable units, score those chunks against query intent, and synthesise an answer.

The extraction layer is where most Magento stores lose the race.

Content visibility for AI falls into four practical levels:

Level	State	Extraction reliability
1	Server-rendered, early in HTML	High
2	Server-rendered but hidden/collapsed	Reduced
3	In DOM only after JS execution	Low
4	Loaded async after user interaction	Very low

Googlebot handles levels 2–4 fine — it runs a full headless Chrome pipeline. Most AI crawlers do not. For AI, server-rendered HTML early in the document is what gets extracted reliably. Everything else is a gamble.

What Magento actually serves

Default Magento 2 wraps product descriptions inside a RequireJS tabs widget:

data-mage-init='{"tabs": {...}}'

In most Luma installations, the description is in the server-rendered HTML — but:

marked as inactive (collapsed tab)
positioned deep in the document after navigation, widget JSON, form keys, boilerplate
structurally ambiguous to an extraction parser

Run this to see your actual first impression on AI crawlers:

curl -s "https://yourstore.com/your-product-url.html" \
  | python3 -c "
import sys, re
html = sys.stdin.read()
text = re.sub(r'<[^>]+>', ' ', html)
text = re.sub(r'\s+', ' ', text).strip()
print(text[:3000])
"

If your product description text is not clearly readable in those first 3000 characters — you are at Level 2 at best, and competing at a structural disadvantage against every store that renders their description at Level 1.

Fix 1 — Activate the tab by default (quick win)

<!-- catalog_product_view.xml in your theme -->
<referenceBlock name="product.info.details">
    <arguments>
        <argument name="config" xsi:type="array">
            <item name="settings" xsi:type="array">
                <item name="active" xsi:type="boolean">true</item>
            </item>
        </argument>
    </arguments>
</referenceBlock>

Keeps the tab UI for visitors. Removes the CSS-hidden state so the description is exposed at page load. Level 2 collapsed → Level 2 visible. Takes 5 minutes, no module required.

Fix 2 — Render description above tabs (structural fix)

<!-- catalog_product_view.xml -->
<referenceContainer name="product.info.main">
    <block class="Magento\Catalog\Block\Product\View\Description"
           name="product.description.above.tabs"
           template="YourVendor_Theme::product/description-visible.phtml"
           after="product.info.price">
</referenceContainer>

<?php
// description-visible.phtml
$description = $block->getProduct()->getData('description');
if (!$description) return;
?>
<section class="product-description-aeo" itemprop="description">
    <?= /* @noEscape */ $description ?>
</section>

Description is now at Level 1 — unconditional, server-rendered, early in the document. Keep the tabs further down for UX. Both coexist without conflict.

Fix 3 — Render all tab content server-side (comprehensive)

Override details.phtml so all tab content is in the initial HTML response. The tabs widget handles visibility via CSS only — active tab is visible, others are hidden. AI parsers reading raw HTML see everything.

Hyva Theme note

Hyva uses Alpine.js x-show instead of RequireJS tabs. Description is usually in the HTML source — but Alpine bindings add structural noise. Most reliable fix: render description once outside the Alpine component, as a clean server-rendered block, early in the layout. Same pattern as Fix 2 above, same result.

Check your JSON-LD delivery

Same principle applies to schema. If JSON-LD is injected via GTM or hydrated client-side, AI parsers often miss it entirely.

curl -s "https://yourstore.com/your-product.html" \
  | grep -o '"@type": "Product"'

No output = client-side schema = invisible to most AI extraction pipelines.

Server-rendered JSON-LD in <head> is the only reliable delivery method for AI systems.

Bottom line

AEO guides focus on what to add. This problem is about how content is exposed — position in the document, server vs client rendering, structural clarity for extraction parsers.

Most Magento stores have the right content. It just never reaches the layer that determines whether their products become AI recommendation candidates.

The fix takes under an hour. No new modules, no API keys — layout XML overrides in your theme.

Run the curl test on your top-selling product now.

Full article (all three fix approaches with complete code, Hyva deep-dive, schema delivery comparison): angeo.dev →

Free AEO audit tool (CLI, MIT licensed): angeo/module-aeo-audit