Shopping Cart
Module features and benefits
- Markdown built from PrestaShop objects, not by converting the rendered page — the document contains no menu, footer, forms, or code from other modules.
- Radically lower token cost on the agent side: the X-Markdown-Tokens-Estimate header in every response provides an estimated document size, and the panel shows a Markdown versus HTML comparison for the selected entity.
- Two independent delivery channels — content negotiation at the canonical URL and separate .md URLs — so the agent reaches the content regardless of whether it sends the Accept header.
- A diagnostic safeguard before enabling negotiation: the module does not allow the feature to be activated until it verifies with real HTTP requests that the caching intermediary will not poison the shared cache.
- The rule “the agent never sees more than a guest” implemented as a rule, not as isolated exceptions — store visibility settings apply to agents exactly as they do to an anonymous visitor.
- Prices calculated in the guest context, with explicit currency and country resolution, so the cache will not store one customer’s price and serve it to everyone else.
- Full multistore and multilingual support: settings, llms files, cache, and counter are maintained separately for each store and each language.
- Zero external dependencies — no Composer, no external libraries, no calls to third-party services; the module does not send your store data anywhere beyond the response to the request.
- It does not collect personal data: the hit counter stores only the day, store, channel, and client family, without IP addresses, sessions, full URLs, or the full User-Agent.
- Compatibility from PrestaShop 1.7.1.0 to 9.x and from PHP 7.0 to 8.5, verified against real source trees, not just declared.
Key module functionalities
- Content negotiation on canonical store URLs: a request with Accept: text/markdown receives a Markdown document, while a browser request receives unchanged HTML.
- The Vary: Accept header and the Link: rel="alternate" tag on HTML pages covered by the module, so intermediaries and agents know that an alternative version exists.
- Parallel markdown/{typ}/{id}.md URLs for products, categories, CMS pages, and manufacturers, under their own prefix so they do not conflict with other modules rewriting URLs.
- The llms.txt file — a curated list of the store’s most important sections: top-level categories, information pages, and a link to the full index.
- The llms-full.txt file — a compact entity index: title, canonical URL, .md URL, price, availability, SKU, and summary; automatically split into parts after exceeding the configured size.
- Generation of llms-full.txt exclusively through a token-protected cron endpoint, never during a visitor request, with a time budget and interrupted rebuild resumption.
- A separate cron token for each store, compared in constant time, with a ready-to-copy curl command in the panel.
- Generated Markdown cached in the database with a configurable lifetime and invalidation via hooks when a product, combination, promotional price, price rule, stock status, category, CMS page, or manufacturer changes.
- Diagnostics tab: seven checks performed with real HTTP requests against the module’s own probe endpoint, with separate distinction between the failures “HTML served to the agent” and “Markdown served to the browser”.
- Informational check of the real catalog URL after enabling negotiation, presented separately and not gating the feature.
- Document preview in the panel for the selected entity type and ID, together with a Markdown versus HTML token counter and an explicit entity visibility verdict.
- Files tab: status of llms files for each language (presence, size, date, entity count, part count), a manual rebuild button with a time budget, and the cron command.
- Agent hit counter: aggregate day × store × channel × client family, split into negotiation, .md route, and llms channels, and openai, anthropic, perplexity, google, bing, script, browser, and other families.
- Response headers aligned with the purpose of the content: X-Robots-Tag: noindex, nofollow on Markdown documents, X-Content-Type-Options: nosniff, ETag with 304 support, and a differentiated Cache-Control policy for the canonical URL and the .md URL.
- Product data in the document header: type, ID, canonical URL, Markdown URL, title, SKU, brand, gross and net price, currency, tax information, availability, pack flag, personalization requirement, product condition, categories, language, and update date.
- Regular price as well as the discount amount and percentage when the product is on promotion — the agent will not see the promotional price as if it were the regular one.
- Variant table with price, quantity, availability, and combination ID, so the agent can point to a specific variant instead of only describing it.
- Contents of product packs with quantities and links to the Markdown documents of individual items.
- Information about required personalization fields, excluding fields belonging to other modules that PrestaShop does not display on the front end.
- Selection of entity types made available to agents, enforced consistently across all channels: on .md routes, in llms files, and in the alternative version tag.
- The module’s working directory secured against direct web access, and llms files served exclusively through the module controllers.
- Respect for store maintenance mode and geolocation — a store closed to visitors is also closed to agents.
- Panel in the PD convention with the module header and tab bar, with hints next to settings that have costly consequences, such as CDN cache fragmentation.
Business use cases
- For PrestaShop stores that want to be correctly read by shopping assistants and AI agents, instead of relying on the model to clean up the HTML page on its own.
- For merchants who want to control exactly what reaches agents — the scope of entity types, the visibility of prices and quantities, and the publication method.
- For stores with a large catalog, where the difference between a full HTML page and a Markdown document translates into a real cost difference on the querying side.
- For multistore deployments, where each store requires its own settings, its own llms files, and its own cron token.
- For companies that want to base decisions about further investment in this channel on data — the hit counter shows whether agents are actually querying, and through which path.
- For stores operating behind a CDN or reverse proxy, where enabling content negotiation on your own without verification could result in serving the wrong page version to regular customers.
What the module does not do
- It is not an SEO module and does not improve the store’s ranking in Google search results — Markdown documents are explicitly marked as non-indexable.
- It does not modify the appearance, content, or performance of the HTML page seen by customers; a page covered by the module receives only additional headers indicating the existence of an alternative version.
- It does not send store data to any external service and does not require an account or API key.
- It does not translate the structural labels of the document — field names remain fixed and in English because they are intended for machines, while the entity content is always in the store language.
Compatibility
- PrestaShop: 1.7.1.0 - 9.x
- PHP: 7.0 - 8.5
- No Composer and no external libraries
- Multistore: yes, settings and files maintained separately for each store
- Multilingual: yes, documents and llms files for each active language