JSON-LD, llms.txt and feeds in Shopware: what really improves visibility

With structured data, llms.txt and machine-readable feeds you give search engines and AI systems the most important information about your shop in a form they can read. This article shows which JSON-LD rich snippets in Shopware actually make a difference, how to output product, category, organisation and FAQ data centrally, and which requirements apply.

You get concrete use cases, the limitations of the solution, notes on compatibility (Shopware 6.5 to 6.7) and on the benefit you can realistically expect.

How can you tell that missing structured data is a real problem for your shop?

If your search results show no price, availability or rating information and your category pages have little context in the SERPs, structured data is a possible cause.

To diagnose it, start by looking at the search results and at AI answers, then work through it systematically. Open a few product and category pages and search the page source for <script type="application/ld+json">. If there is no JSON-LD block at all, the finding is clear. If a block exists, check whether the most important fields (Offer with price and priceCurrency, availability, aggregateRating or review information) are actually filled or only contain empty placeholders.

Further useful checks:

• Rich result and schema validators: the official tools report errors and show missing property assignments.
• Search Console: the enhancement and structured data reports often already list missing or faulty elements.
• Server logs and bot access: check whether crawlers retrieve the JSON-LD resources without errors. Some bots see a simplified, cached or differently rendered version.
• AI test queries: ask an AI or internal retrieval systems product-related questions. If the answers do not reflect prices, availability or variants correctly, machine-readable input is often missing or not available in a standardised form.

Typical error patterns: visible content contradicts the JSON-LD (the price in the front end changes, the JSON-LD stays old), a page contains duplicate or contradictory JSON-LD blocks, identifiers such as GTIN or MPN are missing on variant pages, or the JSON-LD is only inserted client-side via JavaScript, so some indexers do not reliably see it.

If the problem affects individual, unimportant pages, a targeted fix is enough. If it occurs systematically, for example on many product pages, on all category pages or for typical user questions to an AI, a central solution makes more sense than lots of individual quick fixes.

How does the effort compare: manual markup maintenance or central JSON-LD output?

Maintaining structured data by hand per template or product scales poorly and leads to inconsistencies.

The differences in effort and risk:

• Scaling and drift: with manual maintenance you have to adjust the markup fields for every template, every theme update and every new product page. That means more testing at each release and more inconsistencies, for instance when developers use different naming conventions.
• A single data source: generating JSON-LD centrally from the product master data (PIM or shop database) needs just one mapping logic. Product data, prices, shipping profiles and return rules are brought together once and output from there to the front end, to feeds and to llms.txt.
• Deployment and testing: centrally generated schemas are easier to unit-test than JSON fragments spread across many templates. Automated snapshot tests for schema generation and validation in the CI pipeline are worthwhile.
• Performance and invalidation: central also means planning your caching. Prices and stock levels change frequently, so you need a sensible invalidation approach (for example tying cache keys to the price or stock version, or invalidating on events). Without central control this is more error-prone.

Common implementation patterns:

• Server-side generation: the JSON-LD is inserted at render time. This is the most reliable option for search engines and external crawlers.
• Service layer: a dedicated microservice or endpoint delivers the structured representation as an API that the front end and feeds call.
• Template helper: a central renderer as a library that the templates call, so that the output format stays the same everywhere.

Typical pitfalls when centralising are incomplete field mappings between PIM and shop database, relying on central logs without real end-to-end checks, and oversized JSON-LD blocks with unnecessary internal metadata. Central output improves quality and consistency, but it does not guarantee rich results or AI mentions. That decision lies with the indexers.

How does central output of product, category, FAQ and organisation data work in practice?

The plugin generates Google-compliant JSON-LD snippets for products, categories, organisation and FAQ and provides them centrally.

Architecture and mapping in detail:

• Data source: the master data comes from the PIM or the shop back end (product identifiers, prices, shipping profiles, return rules, reviews). The maintained fields should be clearly defined, for example what really counts as a GTIN and at which level (parent product or variant) it is stored.
• Schema structure: generate separate blocks for Product, Offer, AggregateRating/Review, BreadcrumbList, ItemList, Organization and FAQPage. Use @id for entities so that schemas can be linked unambiguously across pages.
• OfferShippingDetails and MerchantReturnPolicy: these details should come from the shipping profiles and return settings. Declarative fields instead of free text make sure that machines can process the information.
• Category structure: category pages need an ItemList with ListItem entries that reference the @id of the products. With pagination, make sure not to output contradictory itemListElement positions, and set canonical and rel-next/rel-prev correctly so that the list remains readable as a whole.
• Variants and identification: output GTIN or MPN only where they clearly belong to a variant. Parent products get a clear label, and the variant pages provide the exact identification.
• FAQ integration: the FAQ data should contain exactly the questions and answers that users see. Keep the accordion in the front end in sync with the FAQPage schema so that no discrepancy arises.

Technical notes and sources of error:

• Some indexers recognise client-side generated JSON-LD less well. Server-side embedding is better.
• Avoid contradictory information: if the front end shows a price, the Offer object must contain the same price. Otherwise trust suffers and search engines may devalue the data.
• Content Security Policy: some shops have restrictive CSP rules that block inline scripts. In that case the JSON-LD has to be delivered externally or via a suitable CSP configuration.
• Visibility: do not output data in the JSON-LD that users cannot see on the page. This can be regarded as misleading.

Maintenance: if a shipping profile, a return option or the URL structure changes, central generation should pick this up automatically. Tests and monitoring help you spot discrepancies early.

When do llms.txt and machine-readable feeds make sense for AI search systems?

llms.txt and machine-readable feeds are worthwhile if AI search systems are meant to retrieve structured product and category data from your shop in a targeted way.

What are they for, and how do they differ from JSON-LD in the HTML?

• llms.txt is a pointer file for LLM indexers. It shows where relevant feeds or rules for crawling and usage can be found. Like robots.txt, it is an entry point for orientation and does not force anyone to use it.
• Machine-readable feeds (JSON, CSV, XML) provide a simple endpoint for large, regular retrievals. For extensive indexing this is far more efficient than reading every page individually.

When you should consider feeds and llms.txt:

• If external AI providers, comparison portals or internal retrieval pipelines are to have comprehensive access to your structured catalogue.
• If your catalogue is very large or changes frequently and you need a high-performance, tiered retrieval process (for example full and delta feeds).
• If you want precise control over which data is openly accessible and at what granularity (for instance only product metadata without personal data or order information).

What to bear in mind in operation:

• Choice of format: JSON is usually the most practical for AI systems because it represents nested structures well. CSV is enough for simple attributes. XML is less common in AI pipelines but suits some legacy systems.
• Delta and full feed: offer both if frequent updates are required. This includes clear change metadata (lastUpdated, changeType) and reliable versioning of the schema.
• Security and governance: decide which data you disclose. Authenticated feeds or signed URLs are suitable for sensitive information. Document the terms of use and the licence so that third parties know how they may use the data.
• Monitoring: keep an eye on access to your feeds, set a rate limit and check whether external systems actually process the data. Logs help you trace faulty feed versions and access by external indexers.

Important: llms.txt and feeds increase the chance that AI systems see your data. They cannot force the data to be used or preferred. The same legal requirements also apply as for any data access, so pay attention to data protection and to contractual terms with third parties. You can read more about visibility in AI search on our page about GEO, AEO and LLM optimisation.

Which requirements, limitations and use cases apply to the central solution?

The extension is compatible with Shopware versions 6.5.0.0 to 6.7.13.0. While a subscription is active, updates and support from us as the manufacturer are included, and there is a free trial month.

Requirements for a successful integration:

• Access to master data: you need clean product master data (PIM or shop database) with correct IDs, prices, availability, shipping and return information and review data.
• Server-side rendering or another reliable way of delivering JSON-LD. Inserting it client-side is convenient but not robust enough for all crawlers.
• The ability to adjust schemas and the CSP so that JSON-LD blocks are not blocked.

Limitations:

• Platform dependency: the plugin is limited to Shopware versions. Other platforms need a port or a different solution.
• No guarantee of rich results: structured data increases the chance of enhanced listings but does not guarantee them. Search engines and AI products decide what is displayed.
• Special formats: if third parties require a proprietary data format, the plugin cannot map every individual structure.

When the solution is particularly useful:

• You run an extensive catalogue and want to offer consistent, machine-readable product and category data from a single source.
• You want to support external AI indexers or comparison portals and provide controlled, documented feeds and llms.txt for them.
• You want to maintain schemas centrally and safeguard them with CI tests instead of spreading markup across many templates.

When the solution is not a good fit:

• If your system needs highly customised, proprietary data exports outside the standardised schemas.
• If your infrastructure does not allow server-side embedding of JSON-LD or you lack the tools for cache control and invalidation.

Structured data is a technical aid and does not replace work on content. You still need to look after product copy, image quality, reviews and pricing. Plan the introduction as part of an overall process of technical delivery, automated testing, monitoring and ongoing content optimisation. How we approach technical SEO for Shopware is described on the page Shopware SEO.

Frequently asked questions

Does the plugin support GTIN, MPN and product dimensions?

Yes. The plugin supports the Product schema including GTIN and MPN as well as details on dimensions and properties. This information is output in the JSON-LD.

Does the extension manage hreflang and canonical tags automatically?

According to the feature description, the extension offers canonical and pagination handling as well as automatic hreflang. With special multi-domain set-ups you should check compatibility with your implementation.

Is there a guarantee that Google will show rich results?

No. The plugin delivers Google-compliant JSON-LD snippets, but the search engine decides whether rich results are displayed. Structured data increases the chance, it is not a guarantee.

Can the plugin set noindex for account or checkout areas?

Yes. The extension offers noindex/nofollow control for the account, checkout and wishlist as well as for individual categories and static pages.

Conclusion

If you output JSON-LD for products, categories, organisation and FAQ centrally and also provide llms.txt and machine-readable feeds, you save maintenance effort and give search engines and AI systems standardised signals. Check Shopware compatibility (6.5.0.0 to 6.7.13.0) and your project requirements beforehand.

You can find the plugin in the Shopware Store: Rich Snippets JSON-LD & SEO/AI visibility.