How LLMs Interact with Your Online Shop
LLM INTEGRATION EXPLAINER
Distinguish reading, retrieval and authorised action
A language model does not automatically know a store’s current catalogue or have permission to change it. Information may arrive through indexed pages, a merchant feed, retrieved records or an application tool. Each route has different freshness, access and accountability.
01 – READ
Public pages and search
Crawlers and search systems can process eligible visible content under their technical rules and controls.
02 – RETRIEVE
Feeds and controlled context
A provider or application can supply structured products, policies or selected records with defined ownership and freshness.
03 – ACT
APIs and narrow tools
An application may create a cart or draft only when the merchant grants permission and validates every request.
Map the interaction route for one proposed use case
Identify what the model can see, where each fact comes from, what it may do, how the merchant validates it and how access can be revoked.
A large language model can interact with an online shop in several ways, and those ways should not be collapsed into one idea. It may generate an answer from public web content discovered through a search product, use a merchant product feed, retrieve selected store records inside an application, or call an authorised tool. The merchant needs to know which route applies before judging accuracy, privacy or operational risk.
Read the AI product-search guide for the customer journey, the data-sovereignty guide for processing questions, and the ecommerce integrations service for implementation.
1. Public web and search interaction
Search systems may crawl pages that their bots can access and use indexed content to support search experiences. Google states that pages eligible as supporting links in AI features must meet normal Search technical requirements and that there is no special AI schema or separate AI file required. Site owners can use established crawl, indexing and snippet controls according to the documented behaviour of the service.
| Layer | Typical input | Merchant control |
|---|---|---|
| Public page | Visible product, policy and guide content | Publishing, crawl and snippet controls |
| Structured data | Machine-readable representation of visible entities | Accurate markup matching the page |
| Merchant feed | Submitted products, offers and promotions | Field mapping, terms and feed suspension |
| Application retrieval | Selected private or operational records | Identity, permissions and data minimisation |
| Tool call | Requested action such as find order or create cart | Independent validation and audit |
2. Merchant feeds
OpenAI’s March 2026 product-discovery update describes ACP product feeds and promotions, including Shopify Catalog integration for Shopify merchants and merchant-owned checkout as the current direction. OpenAI’s merchant-feed terms assign responsibilities under the applicable agreement. A feed is a deliberate publication channel; it should be generated from approved product and offer data, monitored for errors and stopped when it becomes unreliable.
3. Retrieval inside an application
A merchant application may retrieve a relevant policy, product record or authenticated order and include it as context for a model. This is often called retrieval-augmented generation. Retrieval should enforce the user’s role, business purpose, record scope and freshness. The model should cite or retain the source IDs used, and conflicting records should create an exception rather than an invented reconciliation.
4. API and tool interaction
WooCommerce provides REST APIs for store data. Access to an API does not mean a model should receive a general credential. Wrap capabilities in narrow tools such as search approved products, get current order status, create a draft cart or request a refund review. Each tool validates identity, permissions, fields and business state independently of the generated instruction.
- Read-only retrieval before write permission
- Draft creation before final execution
- Explicit confirmation for customer-impacting action
- Amount, quantity and frequency limits
- Idempotency keys to prevent duplicate requests
- Audit log with user, tool, input, result and error
5. Separate model knowledge from current store truth
A model may have general knowledge but cannot be assumed to know current price, stock, delivery or policy. Retrieve those facts at the time of the task and validate again at checkout or posting. Avoid prompts that invite the model to estimate a missing product specification or decide compatibility from a similar name.
6. Protect personal and confidential data
Map the fields sent to every provider, the processing purpose, retention, training settings, subprocessors, access and deletion. Replace direct identifiers with controlled references where the task allows. Do not include payment secrets, passwords or unrelated customer history. South African businesses should obtain appropriate advice for POPIA and cross-border processing.
7. Monitor and revoke
Track retrieval failures, stale answers, rejected tool calls, incorrect product representation, duplicate actions and customer corrections. Store integration owner, credential scope and expiry. The merchant must be able to disable a tool, revoke a provider and continue the core store without losing the transaction record.
8. Test prompt, tool and retrieval abuse
Test a user requesting another customer’s order, asking the assistant to ignore policy, embedding instructions inside uploaded content, repeating a timed-out action and requesting fields outside the tool’s purpose. The application must enforce identity and permission outside the model, treat retrieved text as data rather than authority, and check whether an action already completed before retrying. Record blocked attempts and review unusual patterns without exposing sensitive prompt content unnecessarily.
Worked interaction map
A support assistant answers an order-status question. Public help pages explain general delivery policy, but the authenticated application retrieves only the customer’s selected order and shipment events. The model summarises the recorded state and cannot edit the order. An address-change request calls a separate tool that checks identity and dispatch status; because the parcel has shipped, the tool rejects the change and opens a human case. The model never receives a general WooCommerce administrator key.
Sources checked
- Google Search Central: AI features and your website
- Google Search Central: Product structured data
- OpenAI: Powering Product Discovery in ChatGPT
- WooCommerce: REST API documentation
Reviewed by
Mitrend Digital editorial team
2026-07-17
Evidence used for this page
Reviewed against current Google AI-features and structured-data guidance, OpenAI product-discovery documentation, merchant-feed terms and WooCommerce REST API documentation. Includes an original interaction-layer map.
Turn the guide into a practical next step
This resource provides general implementation guidance. Verify platform settings, tax, legal, payment and operational requirements against the current business context before making a live change.