← Platform guides

PrestaShop: Onboard Shoppers Through the Assistant They Already Use

2026-07-19 · Platform guides · prestashopoperational layeronboardingecommerce

PrestaShop merchants run their own stack — and in the agent era, that's suddenly a superpower. When a shopper's AI agent arrives to compare stores and complete a purchase, the store that publishes an operational layer — machine-readable files declaring its catalog, cart, checkout, and account operations behind a consent gate — is the one the agent adopts. Hosted platforms make you fight for every file path. On self-hosted PrestaShop, you own the web root. You can ship a complete operational layer today with nothing but file uploads, and harden it with a small module when you're ready.

What an agent sees on your PrestaShop store today

Theme HTML (Smarty-rendered), category and product pages, probably some microdata depending on your theme, and a sitemap if you've configured one. PrestaShop also has a Webservice API (/api/), but it's disabled by default, key-authenticated, and built for back-office integration — not something a visiting agent can use. So the agent sees a describable store, not an operable one: no declared operations, no input requirements, no consent statement. Everything it would need to act is locked in markup it has to guess at.

Step 1 — Write your llms.txt (root access: use it)

Self-hosted PrestaShop means you can place files directly in your web root alongside robots.txt. Write a one-page llms.txt — store name, what you sell, shipping regions, return summary, key categories, manifest pointers, consent declaration — and upload it via SFTP or your hosting file manager to resolve at https://yourstore.com/llms.txt. No module required. (If you're on PrestaShop managed hosting or a locked-down server, check you can write to the docroot; otherwise use the module route in Step 5.)

Step 2 — Publish JSON manifests (.json twins) for key pages

Create static .json twins for home, top categories, and your CMS policy pages — purpose, operations, inputs, expected results — in a /manifests/ directory at the root. Static files are ideal: fast, cacheable, immune to theme changes. When your catalog changes often, regenerate the category twins on a schedule or move them into a module (Step 5) that renders them live.

Step 3 — Add the consent gate and transparency declaration

In llms.txt and every manifest:

The published layer identifies the authorized store publisher and explains that supported operations remain subject to the user's confirmation. Payment stays in the store's normal human-confirmed checkout.

Open publication and explicit confirmation make the source and authority easier to assess, but do not eliminate prompt-injection, authorization, or platform-specific risks.

Step 4 — Map the five commerce operations in a Service Control Map

Browse catalog, add to cart, checkout, account, support — in Adoption + Operation categories (evaluate · enroll · transact · configure · use · manage), each with its actuation (API endpoint, function/action, or interface control):

{
  "service": "Example Boutique (PrestaShop)",
  "layer": "operational",
  "consent_gate": "Explicit user consent required before any operation; checkout is human-confirmed.",
  "operations": [
    {
      "id": "evaluate.browse_catalog",
      "type": "interface_control",
      "url": "https://example.com/{category-slug}/",
      "notes": "Product pages follow /{id}-{product-slug}.html on default URL schemes; verify against your friendly-URL settings"
    },
    {
      "id": "transact.add_to_cart",
      "type": "interface_control",
      "url": "https://example.com/cart?add=1&id_product={product_id}&qty={quantity}",
      "inputs": ["product_id", "quantity"],
      "notes": "Cart controller parameters vary by version/theme — test on your store and adjust"
    },
    {
      "id": "transact.checkout",
      "type": "interface_control",
      "url": "https://example.com/order",
      "notes": "Hand off to the human user for address and payment confirmation"
    },
    {
      "id": "enroll.account",
      "type": "interface_control",
      "url": "https://example.com/registration",
      "inputs": ["firstname", "lastname", "email", "password"]
    },
    {
      "id": "manage.support",
      "type": "interface_control",
      "url": "https://example.com/contact-us",
      "inputs": ["email", "subject", "message", "order_reference?"]
    }
  ]
}

Save as /agent.json. Two honesty notes baked in above: PrestaShop URLs depend on your friendly-URL configuration and theme, so verify every mapped URL on your live store; and the Webservice API should stay out of your public layer unless you deliberately run an open integration program — never publish keys.

Step 5 — Link it for discovery (module or override)

Add the discovery pointers sitewide:

• Quick route: in your theme's head.tpl / layout template, add <link rel="alternate" type="application/json" href="/agent.json" title="Operational layer"> and a footer line: "This store publishes an operational layer for AI agents — /llms.txt". Theme edits are lost on theme replacement, so prefer a child/override approach.
• Clean route: a tiny module hooked to displayHeader (for the link tag) and displayFooter (for the line). A module survives theme updates, can serve /llms.txt and the manifests via a front controller if you lack docroot write access, and can regenerate category twins from live data. Any developer can build this in a day; overrides of the front controller achieve the same with less structure.

Honest limitations on PrestaShop

• URL schemes genuinely vary (friendly URLs, multilang prefixes like /en/, theme rewrites). A map with wrong URLs is worse than no map — verify each one.
• Multistore setups need one layer per shop domain.
• Front-office caching (server-side or CDN) can serve stale manifests; purge after catalog changes.
• CAPTCHA or anti-fraud modules on registration/contact forms will block agent submission; where they exist, map the operation as a human handoff.
• Version drift (1.7 vs 8.x) changes controllers and hooks — re-verify the map after upgrades.

FAQ

Should I expose the PrestaShop Webservice API to agents?

No, not the keyed back-office API. The public operational layer maps public storefront operations. If you want agent-facing endpoints, build dedicated, unauthenticated read endpoints in your module.

Module or plain files — which first?

Plain files today (root access makes this trivial), module when you want the layer to survive theme updates and stay current automatically.

Does this help me rank in Google?

It's orthogonal. SEO keeps you in the search index; the operational layer keeps you in the agent index — where recommendations and completed purchases increasingly originate.

Want it generated for you?

The Free plan makes your store's most important page agent-ready — one hosted page, free, forever. The Basic plan (14-day trial, then $29/month) covers your full store, and Pro ($99/month) keeps a managed layer current as agent platforms evolve.

swa:1:aHR0cHM6Ly9zaGFyZXdpdGhteWFnZW50LmFpL3BsYXRmb3Jtcy9wcmVzdGFzaG9wLmpzb24

Keep reading