How to Customize Shopify’s agents.md, llms.txt and llms-full.txt Templates — A Practical Guide for Transparency and Compliance

How to Customize Shopify’s agents.md, llms.txt and llms-full.txt Templates — A Practical Guide for Transparency and Compliance

Table of Contents

  1. Key Highlights
  2. Introduction
  3. Why these endpoints matter: legal, customer, and operational reasons
  4. How Shopify maps paths to theme templates
  5. Creating and customizing the templates: step-by-step
  6. Choosing a content strategy for each endpoint
  7. Practical template examples
  8. How to structure content for different audiences
  9. Internationalization and translations
  10. Testing and validating your templates before publishing
  11. Handling caching, CDN, and propagation
  12. Security and privacy considerations
  13. Common use cases and real-world examples
  14. Troubleshooting common issues
  15. Best practices and publishing checklist
  16. Integrating with internal processes and audits
  17. When to consult legal or privacy teams
  18. Deployment patterns for multi-theme retail operations
  19. Example migration: from default content to a structured disclosure
  20. How auditors and third parties can consume these files
  21. Governance: who owns the content and who signs off
  22. Accessibility and linking strategy
  23. Example: a minimal policy for merchants who use AI-generated content
  24. When to use /llms-full.txt as JSON vs YAML vs plain text
  25. Final operational recommendations
  26. FAQ

Key Highlights

  • Shopify exposes a default agents.md file at /agents.md, and /llms.txt and /llms-full.txt map to the same content unless you add dedicated templates for each path.
  • Add templates under Online Store > Themes > Edit code as templates/agents.md.liquid, templates/llms.txt.liquid, and templates/llms-full.txt.liquid to serve different content per path; if a template is missing, Shopify falls back to agents.md template, then to a Shopify-generated default.
  • Use these files to deliver plaintext or Markdown disclosures about automated agents and LLMs used on your storefront; follow best practices for clarity, privacy, and discoverability, and test templates in theme previews and production before publishing.

Introduction

Shop operators face increasing expectations around transparency when they deploy automated agents and AI-driven features on customer-facing sites. Shopify provides three simple public endpoints out of the box — /agents.md, /llms.txt, and /llms-full.txt — that can host human-readable and machine-friendly disclosures about the automated systems operating on a store. Those endpoints map to theme templates you can edit, enabling consistent, version-controlled, and theme-aware disclosure pages.

This article explains how Shopify maps those paths to template files, how to create and structure template content, and how to use each endpoint effectively for legal compliance, customer trust, and internal record-keeping. You’ll get step-by-step instructions, sample templates tailored to common use cases (chatbots, content-generation models, and full technical inventories), troubleshooting tips, and a recommended checklist for publishing these files safely.

Why these endpoints matter: legal, customer, and operational reasons

Public-facing disclosures about automated agents and large language models serve three distinct purposes.

  • Regulatory and legal compliance: Some jurisdictions increasingly require that businesses disclose when they use automated systems to interact with people or generate content. A clearly accessible page at a predictable path makes compliance audits simpler.
  • Customer trust and experience: Shoppers appreciate transparency when they encounter chatbots, automated product descriptions, or personalization driven by LLMs. A short explanation and a contact point reduce confusion and complaints.
  • Operational traceability: Maintaining a machine-readable file (or files) that list active models, providers, and versions helps security, privacy, and machine-learning operations teams know exactly what’s in production at any given time.

Shopify’s default placement of these files at the root of a storefront — /agents.md, /llms.txt and /llms-full.txt — follows common patterns used for robots.txt, humans.txt, and other operational endpoints. That consistency makes it easy to link these files from your privacy policy or site footer and to include them in third-party audits.

How Shopify maps paths to theme templates

Shopify associates these three public paths with template files inside your active theme. You can override the default content by adding template files to the templates folder of the theme. The mapping and fallback behavior is simple:

  • templates/agents.md.liquid controls the content served at /agents.md. It also serves as the default content provider for /llms.txt and /llms-full.txt when dedicated templates for those paths are absent.
  • templates/llms.txt.liquid controls only /llms.txt.
  • templates/llms-full.txt.liquid controls only /llms-full.txt.

If a specific template is missing for a given path, Shopify falls back to the agents.md template. If the agents.md template does not exist, Shopify serves a Shopify-generated default.

Practical implications:

  • Each theme contains its own versions of these templates. When you switch themes, the content at those paths will change to match the active theme.
  • Edit these templates from the theme editor (Online Store > Themes > Actions > Edit code). Changes are tracked in the theme and can be deployed with standard theme deployment workflows (GitHub integration, Theme Kit, or manual editing).
  • The file extensions (.md.liquid and .txt.liquid) determine how you author content (Markdown for .md, plaintext for .txt) and how browsers and crawlers interpret it.

Creating and customizing the templates: step-by-step

Follow these steps to add or update templates for the three paths. The instructions assume you have the required shop admin access.

  1. Open Shopify admin and navigate to Online Store > Themes.
  2. For the theme you want to modify, choose Actions > Edit code.
  3. Under the Templates directory, choose Add a new template.
  4. Select the appropriate type and name the file exactly:
    • agents.md.liquid (for /agents.md)
    • llms.txt.liquid (for /llms.txt)
    • llms-full.txt.liquid (for /llms-full.txt)
  5. Author the content using Liquid, Markdown (for .md.liquid), or plain text (for .txt.liquid).
  6. Save and publish the theme (or test in the theme preview first).

Because templates live inside themes, use your normal theme deployment process to propagate changes to staging and production environments. Keep a copy of any template text in your repository or changelog so you can audit historic changes.

Choosing a content strategy for each endpoint

A common way to structure these three files is to serve progressively more detailed disclosures from /agents.md to /llms-full.txt:

  • /agents.md — short, human-readable page explaining what automated agents exist on the site (e.g., chatbots, support bots, recommendation engines), where they are used, and how visitors can contact the store for clarification. Markdown formatting is allowed and preferable for readability.
  • /llms.txt — a concise, machine-friendly list of the LLMs in use (model names, major providers). A plaintext format works well for automated audits and scanning tools.
  • /llms-full.txt — an extended, machine- and human-readable inventory. Include model name, provider, version, endpoint, purpose, date deployed, risk classification, and a pointer to your privacy policy or more detailed technical documentation. JSON or YAML are good formats for programmatic access.

This layered approach matches both human needs (a short explanation) and operational needs (a full inventory), enabling consumers and auditors to access the appropriate level of detail.

Practical template examples

Below are three practical examples you can adapt. These examples demonstrate Markdown, plaintext, and JSON/YAML-like content and illustrate how to reference theme assets and translations.

Example 1 — templates/agents.md.liquid (Markdown; human-friendly)

# Automated Agents and AI Used by {{ shop.name }}

We use automated agents and AI systems to improve customer support, search relevance, and product descriptions. This page lists the categories of systems currently active on this storefront and how they are used.

## Active Agents
- Support chatbot (visible on product pages and the support center): handles order lookup and frequently asked questions.
- Recommendation engine: suggests related products on product pages and cart views.
- Automated description generator: assists merchants with product copy; final copy is reviewed by humans before publication.

If you have questions about how these systems use your data or would like human assistance, contact us at: {{ shop.email | default: "privacy@yourstore.example" }}.

For detailed technical information about the models and providers we use, see /llms.txt and /llms-full.txt.

Example 2 — templates/llms.txt.liquid (plaintext; concise machine-friendly)

# LLMs used by {{ shop.name }}
OpenAI/gpt-4o-mini
Anthropic/claude-2.1
Cohere/command-nightly

Example 3 — templates/llms-full.txt.liquid (JSON-like; extended)

{
  "store": "{{ shop.name }}",
  "last_updated": "{{ 'now' | date: '%Y-%m-%d' }}",
  "models": [
    {
      "name": "gpt-4o-mini",
      "provider": "OpenAI",
      "purpose": "Customer support summarization and query routing",
      "deployed_at": "2026-03-14",
      "data_handling": "No user PII stored. Conversation logs retained for 30 days for analysis.",
      "access": "API via vendor",
      "contact": "{{ shop.email | default: 'privacy@yourstore.example' }}"
    },
    {
      "name": "claude-2.1",
      "provider": "Anthropic",
      "purpose": "Automated product description generation (merchant review required)",
      "deployed_at": "2026-01-09",
      "data_handling": "Merchant-provided product data only. Logs retained 90 days.",
      "access": "Vendor-hosted API",
      "contact": "{{ shop.email | default: 'privacy@yourstore.example' }}"
    }
  ]
}

Notes about examples:

  • Use Liquid placeholders (shop.name, shop.email) to keep the content accurate and theme-aware.
  • Format the long inventory in a machine-consumable way (JSON/YAML/plaintext columns) to support automated auditing.
  • Keep the human-facing /agents.md concise and link to the two machine-readable files for further technical detail.

How to structure content for different audiences

Tailor each page to its primary consumer.

  • Consumer-friendly best practices (/agents.md)
    • Keep language short and plain.
    • Name the visible agents and where they appear on the site.
    • Provide a contact email and a link to the privacy policy.
    • Explain whether agent outputs are reviewed by humans and how customers can request human interaction.
  • Security and privacy team best practices (/llms-full.txt)
    • Include model identifiers, deployment dates, data retention, and vendor contact details.
    • Record whether the model runs on vendor-hosted infrastructure or on-premises.
    • Note any third parties that receive model logs (analytics providers, security teams, etc.).
  • Compliance and audit needs (/llms.txt)
    • Provide a compact list of model names and vendors for automated scanners and auditors.

Balancing readability and completeness reduces the risk of misinterpretation while preserving the operational usefulness of the files.

Internationalization and translations

Stores that operate in multiple languages should present human-facing disclosures in appropriate languages. Since template files are theme assets, you have two main approaches:

  1. Use Shopify’s locales/*.json translation files and the t filter to render localized strings in your agents.md template. Maintain translated strings in your theme’s locales files and switch copy based on request locale.
  2. Use theme settings or metafields that contain translations and render content conditionally based on storefront locale. Store translations in metafields or theme settings for per-theme customization.

Avoid creating separate language-specific endpoints for these three paths unless you plan to manage different themes per locale. Keep /llms.txt and /llms-full.txt machine-friendly and consistent across languages; machines generally prefer canonical identifiers and dates.

Testing and validating your templates before publishing

Follow these validation steps before publishing changes:

  • Preview changes in the theme preview link (Actions > Preview). If your store uses a custom domain redirect or CDN, test that the preview reflects your edits correctly.
  • Use curl or a browser to fetch the endpoint and inspect headers:
  • Ensure content-type headers match expectations:
    • .md.liquid typically returns text/markdown or text/plain.
    • .txt.liquid typically returns text/plain.
  • Validate JSON or YAML syntax in /llms-full.txt if you use structured formats. Use a linter as part of your CI pipeline to avoid syntax errors.
  • Confirm that links to these pages from your footer and privacy policy work and that they point to published content on the live site.

Remember: templates are part of a theme. If you edit an unpublished theme, the live site will not show changes until you publish that theme. Use the preview URL or publish during a maintenance window if necessary.

Handling caching, CDN, and propagation

Shopify serves theme assets through Shopify’s CDN. Changes to theme files propagate quickly, but you may encounter caching by browsers, CDNs, or corporate proxies. To minimize propagation surprises:

  • Clear your browser cache or request the endpoint with cache-control headers when testing (curl -H "Cache-Control: no-cache" ...).
  • If you rely on external auditors to fetch the files, notify them of the publish time and ask them to re-fetch after a brief interval.
  • Avoid embedding frequently changing operational parameters (like real-time model health or load) in these static files; use internal monitoring endpoints for dynamic status.

Security and privacy considerations

Disclosing AI infrastructure publicly is an exercise in balance. Provide enough information to meet legal and trust goals while avoiding operational details that could be exploited.

What to include:

  • Model names and providers, general purpose (e.g., "support chatbot," "content generation").
  • Contact email and links to your privacy policy.
  • Basic data retention and data types processed (e.g., "conversation text retained 30 days for quality assurance, no payment info stored").
  • Whether human review occurs and how users can request human intervention.

What to avoid:

  • Precise internal IPs, API keys, or detailed architecture that would aid an attacker.
  • Real-time telemetry or secrets in a publicly accessible file.

Data protection compliance:

  • Document how personal data flows to vendors, where it is stored, and the legal basis for processing if you operate in jurisdictions with strong privacy laws (GDPR, CCPA). Link to a separate, more detailed privacy or processing addendum where necessary.
  • Provide instructions for data subject requests (DSARs) and a contact route.

Common use cases and real-world examples

  1. Customer support chatbot: A fashion retailer uses a hosted chatbot for order status. Their /agents.md explains the chatbot assists with tracking orders; /llms.txt lists "OpenAI/gpt-4o-mini" and /llms-full.txt records retention policies and the vendor contract reference number for audits.
  2. Content generation for merchant product listings: A marketplace uses human-reviewed generated descriptions. /agents.md clarifies the merchant is responsible for the final copy. /llms-full.txt includes model version, deployment date, and a link to the merchant-facing interface used to refine output.
  3. Personalized recommendations: An electronics retailer uses a proprietary recommendation engine and a third-party LLM for title optimization. Their disclosures separate the two capabilities, with /llms.txt enumerating the external LLM and /llms-full.txt listing the vendor and the purpose (title optimization only).

These examples reflect practical distinctions between visible features (chatbots) and backend processes (batch content generation).

Troubleshooting common issues

Problem: Changes to a template aren’t appearing on the live site.

  • Verify you edited the template in the published theme. Edits in an unpublished theme do not affect the live site.
  • Try accessing the raw URL (https://yourstore.example/agents.md) in an incognito window and include a cache-control header to bypass caches.

Problem: The file returns a 404 or Shopify’s default content.

  • Confirm the template filename is exact (templates/agents.md.liquid).
  • If you created llms.txt.liquid but /llms.txt still falls back to agents.md, ensure agents.md.liquid exists if you intended to use it as the primary source. Remember the fallback chain: specific template → agents.md → Shopify default.

Problem: JSON syntax errors in /llms-full.txt

  • Validate the content with a JSON linter. Since Liquid injects values, render the resulting page and download it for validation.
  • Use development tooling (local theme builds or CI) to catch syntax issues before publishing.

Problem: Robots or indexing problems

  • If you don’t want these pages indexed, manage crawling via robots.txt or add disallow rules where appropriate. If you need site-level SEO changes, consult Shopify’s documentation or support for the best pattern for your store.

Problem: Multiple themes cause inconsistent content

  • Remember templates are theme-scoped. Either standardize templates across themes or maintain a changelog that lists the active template content per theme.

Best practices and publishing checklist

Before publishing any changes, walk through this checklist:

  • Content accuracy: Names, purposes, and contacts are current.
  • Privacy alignment: Data handling statements match your privacy policy and vendor contracts.
  • Machine-readability: /llms.txt and /llms-full.txt use consistent, parseable formats.
  • Security review: No secrets, service credentials, or sensitive internal endpoints are present.
  • Version control: Template edits are recorded in your theme repository or documented in a changelog.
  • Testing: Previewed in the theme preview URL and validated via curl and a content linter.
  • Accessibility: Links from the footer or privacy policy work and lead to the live, published page.
  • Communication: Notify internal stakeholders, security teams, and relevant vendors of the deployed content.

Maintain a cadence for updates — quarterly reviews are a common minimum for AI inventories; more frequent reviews are necessary if you rapidly deploy or change models.

Integrating with internal processes and audits

Treat these templates as part of your operational documentation:

  • Use your /llms-full.txt as a canonical inventory that security, privacy, and procurement teams can reference during audits.
  • Automate the generation of llms.txt/llms-full.txt where possible: if your internal systems track model deployments, produce the files as part of your CI/CD pipeline and push them into the theme repository.
  • Keep vendor contract references or internal ticket IDs in the extended inventory to speed audits.

Real-world automation example:

  • A store’s MLOps pipeline writes a JSON inventory file at build time. The build process updates the theme repository and triggers a theme deployment, ensuring /llms-full.txt always reflects deployed models.

When to consult legal or privacy teams

If your store uses models that process personal data, or if you operate in regulated sectors (financial services, healthcare, children’s products), consult legal and privacy early. Issues to escalate:

  • Cross-border data transfer when vendor infrastructure is located outside the customer’s jurisdiction.
  • Models that process sensitive personal data or are used for credit, housing, or employment decisions.
  • Contracts that lack sufficient data-processing terms or security assurances.

A short, accurate public disclosure does not replace the need for legally robust vendor contracts and internal data processing agreements.

Deployment patterns for multi-theme retail operations

If you run multiple themes for seasonal campaigns or A/B tests, maintain a single source of truth for these templates:

  • Store canonical template content in your repository or a central documentation system.
  • Use theme build scripts to ensure each theme’s templates are consistent with the canonical content before publishing.
  • For localized variations, place only the human-facing templates under theme control and keep machine-readable /llms.txt and /llms-full.txt consistent across themes.

This reduces the risk that different customer segments see contradictory AI policies.

Example migration: from default content to a structured disclosure

A merchant that inherited a storefront with no explicit disclosures took the following steps:

  1. Audit: Security and product teams cataloged all agent-like systems and LLMs in use.
  2. Draft: Legal drafted concise consumer-facing copy and technical inventory entries.
  3. Template creation: An engineer added templates/agents.md.liquid with the human copy and templates/llms-full.txt.liquid with JSON inventory.
  4. Review: Privacy and security teams validated data handling statements.
  5. Publish: The team published the theme and linked /agents.md from the site footer and privacy policy.
  6. Monitor: Quarterly review dates were set and automated inventory extraction added to CI.

This process reduced incoming support tickets about chatbots and simplified vendor audits.

How auditors and third parties can consume these files

The standard paths make automated checks simple:

  • A crawler or audit script can fetch https://yourstore.example/llms.txt to quickly enumerate model names.
  • For detailed audits, fetch /llms-full.txt and validate fields like deployed_at, data_handling, and contacts.
  • Use a standardized format (JSON or a line-based CSV) to simplify automatic parsing across multiple stores.

Encourage auditors to re-fetch the files during each audit and include a timestamp field in /llms-full.txt to reduce confusion about stale inventories.

Governance: who owns the content and who signs off

Assign clear ownership for these files:

  • Product or engineering should own accuracy of the model and deployment entries.
  • Legal or privacy should approve data handling language.
  • Security should review any technical detail for risk.
  • Marketing or merchant operations should own the human-facing language for tone and clarity.

Create a simple approval workflow: draft → legal/privacy review → security review → publish. Keep records of approvals and changes in a changelog or version control.

Accessibility and linking strategy

Make the human-facing page discoverable without forcing customers through multiple clicks:

  • Add a single-line link in the footer (e.g., “Automated Agents” or “AI disclosures”) that points to /agents.md.
  • Link to /llms.txt and /llms-full.txt from an “Advanced disclosures” section on /agents.md for auditors and researchers.
  • Ensure links are keyboard accessible and that the text remains readable on mobile.

For SEO considerations: these files are primarily operational and disclosure-focused. If you prefer they not be indexed, manage crawling via robots.txt or canonical strategies. Consult your SEO team when making decisions about indexing.

Example: a minimal policy for merchants who use AI-generated content

Merchants often need a concise public statement they can adapt. Here’s a minimal template you can drop into agents.md.liquid and customize:

# Use of Automated Systems

Some content and interactions on this site are generated or assisted by automated systems. We use these systems to improve product descriptions, assist with customer support, and personalize recommendations. All content generated for product listings is reviewed by humans before publication.

Questions? Contact: {{ shop.email | default: 'privacy@yourstore.example' }}

This short disclosure covers basic transparency obligations while keeping the consumer-facing copy simple.

When to use /llms-full.txt as JSON vs YAML vs plain text

Choose the format that best fits your consumers:

  • JSON: Best for programmatic audits and standardized tooling. Many auditors expect JSON payloads and can validate schema automatically.
  • YAML: Human-friendly and still machine-readable, though some auditors prefer JSON.
  • Plain text or CSV: Fast to read and sufficient for small inventories. Easier for simple scanning tools.

If your organization supports automated tooling, JSON is the safest choice. Include a schema or sample in your internal documentation so auditors know what fields to expect.

Final operational recommendations

  • Treat these templates as part of your production documentation and include them in the theme repo and the store’s change control process.
  • Update the files whenever you deploy or decommission a model; use automation where possible.
  • Maintain a conservative disclosure posture: name vendors and models and provide clear contact and retention details without exposing sensitive internal architecture.
  • Conduct regular reviews with legal, privacy, and security teams.

Being proactive about transparency reduces friction with customers and auditors and helps internal teams manage risk.

FAQ

Q: Where are these templates edited in Shopify? A: In Shopify Admin, go to Online Store > Themes, then Actions > Edit code for the theme you want to change. Add or edit templates under the Templates directory: templates/agents.md.liquid, templates/llms.txt.liquid, or templates/llms-full.txt.liquid.

Q: Which file controls /llms.txt and /llms-full.txt by default? A: By default, /llms.txt and /llms-full.txt point to the content in /agents.md. The template templates/agents.md.liquid is the default for all three paths unless you add specific templates for the other two paths.

Q: What happens if I don’t create any template files? A: If no template is present for a given path, Shopify falls back first to your agents.md template (if present) and then to a Shopify-generated default. To provide custom content, add the templates described above.

Q: Should I expose detailed technical configuration in /llms-full.txt? A: Include model identifiers, purpose, deployment date, and data-handling and contact information. Avoid exposing secrets, API keys, internal IPs, or operational telemetry that might be exploited.

Q: Are these files indexed by search engines? A: They may be indexed unless you exclude them via robots.txt or other site-level controls. If you prefer not to have them indexed, coordinate with your SEO or site admin to set crawling rules.

Q: How frequently should I update these files? A: Update when you add, remove, or materially change a model or agent. Many teams adopt a quarterly review cadence and immediate updates for any deployment that changes data handling or privacy posture.

Q: Can I automate updates to these templates? A: Yes. Include generated files in your theme repository or push updates during your CI/CD pipeline. Automating the generation of /llms-full.txt from internal deployment records reduces manual errors.

Q: What formats are recommended for /llms-full.txt? A: Use JSON for machine automation and validation, YAML for human readability, or structured plaintext/CSV for simple inventories. Choose the format that best supports your audit and tooling requirements.

Q: How do I localize /agents.md for multiple languages? A: Use theme locale files (locales/*.json) and Shopify’s translation mechanisms or use theme settings and metafields to serve localized strings. Keep the machine-readable /llms.txt and /llms-full.txt canonical and language-neutral where possible.

Q: Who should own review and sign-off of content in these templates? A: Product or engineering should maintain the factual accuracy. Legal/privacy should approve data statements. Security should review for sensitive disclosures. Assign a single owner for coordination.

Q: Where do I point customers who want more information or to exercise privacy rights? A: Provide a contact email on /agents.md and link to your privacy policy for data-subject requests. Include vendor contact or contract reference numbers in /llms-full.txt for auditors.

Q: Can templates differ between themes? A: Yes. Templates are theme-scoped, so content varies by the active theme. Maintain canonical content in your theme repository or deploy the same template to multiple themes for consistency.

Q: If I add templates, do they immediately replace Shopify’s default? A: Yes, once the theme with the templates is published. If you edited an unpublished theme, changes will be visible only in the preview for that theme until you publish it.

Q: Is there a recommended public format for llms.txt? A: A simple line-based list of provider/model identifiers (e.g., "OpenAI/gpt-4o-mini") works well for automated scanning. Keep the list terse and canonical.

Q: Who should I contact in Shopify if I have questions or issues deploying templates? A: Use Shopify Support or your merchant success contact. For developer-focused assistance, consult Shopify’s developer documentation and community forums for template naming and theme behaviors.

POWER your ecommerce with our weekly insights and updates!

Stay aligned on what's happening in the commerce world

Email Address

Handpicked for You

How to Customize Shopify’s agents.md, llms.txt and llms-full.txt Templates — A Practical Guide for Transparency and Compliance

28 May 2026 / Blog

How to Customize Shopify’s agents.md, llms.txt and llms-full.txt Templates — A Practical Guide for Transparency and Compliance
Read more Icon arrow
Shopify adds Preact-based App Home UI extensions (admin.app.home.render) — what developers need to know

27 May 2026 / Blog

Shopify adds Preact-based App Home UI extensions (admin.app.home.render) — what developers need to know
Read more Icon arrow
Shopify renames headless checkout silent SSO parameter to `sso=silent` — what developers need to know

26 May 2026 / Blog

Shopify renames headless checkout silent SSO parameter to `sso=silent` — what developers need to know
Read more Icon arrow