# llms.txt and JSON-LD in Webasyst and Shop-Script

> How to get llms.txt and structured data in Webasyst and Shop-Script: what each app contributes, how files and markup are refreshed, and what to check after installation

Page: https://llms-full-txt.ru/en/guides/webasyst/
Site index: https://llms-full-txt.ru/en/llms.txt

In Webasyst both machine-readable layers are built from data the apps already hold: products, pages, posts, discussions, questions and answers, photos.

There are two layers, and they are independent. An `llms.txt` extension builds a map of the site's material. A JSON-LD extension adds to every page a description of what is on it. Either can be installed alone; together they cover both steps: where to go and where you have arrived.

Each app has its own extension, because each app holds different data.

## Two layers on one site

- What comes from where
- The map
- App data
- categories, products, pages, posts
- A scheduled build
- or a button in settings
- llms.txt and llms-full.txt
- at the root of the domain
- The meaning
- Page data
- product, post, topic, question, photo
- Built on render
- cached for an hour
- A JSON-LD block
- in the code of every page

## What each app contributes

| App | What goes into `llms.txt` | What JSON-LD describes |
|---|---|---|
| Shop-Script | categories, products, brands, information pages, contacts; prices and availability optionally | `Product`, `Offer`, `Brand`, rating and reviews, breadcrumbs, the store |
| Site | published pages, the site name and contacts | `WebPage` with dates, `Organization`, `WebSite`, breadcrumbs |
| Blog | posts, categories and tags | `BlogPosting` with author and dates, `Person`, the stream and categories as collections |
| Hub | public sections and published topics | `DiscussionForumPosting`, comments, votes, `QAPage` when a solution is marked |
| Helpdesk | public FAQ and pages | `FAQPage` with a question and its answer, breadcrumbs |
| Photos | public albums and pages | `ImageObject` with caption and dimensions, `ImageGallery` |

Only published, public content takes part in either layer. Helpdesk tickets and correspondence, hidden albums and unpublished topics never reach the files or the markup.

## The llms.txt layer

- **Files are built in advance.** The extension assembles `llms.txt` and `llms-full.txt` and stores them with the installation data. Routing serves the stored file at `/llms.txt`. There is no physical file in the web root.
- **Rebuilds run on a schedule.** Editing a product or a page sets a "changed" flag. The file itself is rebuilt by a scheduler job or by a button in settings. The site owner adds the schedule once: a nightly full build and a frequent check of the flag.
- **Helpdesk reports no edits.** The app does not notify extensions about changes, so its map is refreshed by the schedule only.
- **A large catalog is split.** When the full file exceeds a set size, sections move into separate files named `llms-full-<section>.txt`.
- **One root file per domain.** When several apps share a domain, the app at the root owns the map and the others are included in it.
- **Prices in the file are a choice.** A store can include price, old price and availability, or keep names and addresses only.
- **Staleness is visible.** Settings warn when a file has not been rebuilt for a long time.

The result is an ordinary file: a title, a short summary, sections of links. It is checked like one written by hand: [Validating files and markup](https://llms-full-txt.ru/en/guides/validation/).

## The JSON-LD layer

- **The block is printed in the page code.** No theme edits are needed.
- **Markup is built when a page is rendered** and cached for an hour. A change of price or text changes the cache key at once. A change the key does not see reaches the markup within the hour.
- **Entities are linked.** A page points to the site, the site to the organization, a post to its author, a comment to its topic.
- **The company card is filled in settings.** Phone and address are taken from Shop-Script when it runs on the same domain.
- **Pages closed to indexing are not marked up.**

### What a product page gets

In Shop-Script product markup comes in two editions.

| What | Base edition | Extended edition |
|---|---|---|
| Product and offer | `Product`, `Offer`: name, SKU, price, currency, availability | the same |
| Brand | from the attribute the owner nominated | plus the manufacturer as a separate property |
| Rating and reviews | `AggregateRating`, up to 20 reviews with replies | the same |
| Images | up to 20, with dimensions | plus video |
| Breadcrumbs | yes | plus the category chain and category pages |
| Variants | one product for the selected SKU | `ProductGroup` with a price, SKU and availability per variant |
| Barcode and part number | no | `gtin` with a check-digit test, `mpn` |
| Store | name, site address, logo | contacts, address, opening hours, pickup points, shipping, returns, payment methods |
| Storefronts | one domain | every storefront |

A few things are handled strictly:

- **Availability** takes three values: in stock, out of stock, back order. The third appears only when the store allows selling without stock.
- **Price** is published in the storefront currency, not in the currency a visitor picked.
- **A product without a price** gets no offer.
- **`AggregateOffer` is not used.** Variants of one product are described by separate offers.
- **Brand and barcode are never guessed.** No nominated attribute, no property.
- **A variant group** is built when variants differ by color, size, material or pattern. SKUs that differ by something else produce one product.

### Markup and feed from one source

The answer to "which attribute holds the brand, the barcode, the color, the size" is stored in the store once. Both the markup and the product feed extension read it, so the page and the feed name the same source for the same fact.

Why it matters: [Markup and the product feed](https://llms-full-txt.ru/en/guides/json-ld/#markup-and-the-product-feed).

## What is left to do by hand

1. Add scheduler jobs that rebuild `llms.txt`: without them the file will not refresh.
2. In the markup settings, name the product attribute that is the brand and the one that is the barcode.
3. Fill in the company card: name, logo, phone, address.
4. Make sure the site theme does not print its own markup of the same type.
5. Open `/llms.txt` and confirm a `200` response that is text, not HTML.
6. Run two or three pages through the [Google](https://search.google.com/test/rich-results) and [Schema.org](https://validator.schema.org/) validators.
7. Confirm that `robots.txt` does not block the files from the robots you want.

## What not to expect

**Confirmed**

- Files and markup are built from app data and refreshed without manual editing.
- Only public content reaches either layer.
- Google and [Yandex](https://yandex.ru/support/webmaster/en/json-ld/about) read product markup: their documentation says so.

**Not proven**

- That `llms.txt` will affect rankings or the number of citations.
- That a particular AI system will read the store's markup directly.

**What it does not mean**

- Markup is not refreshed instantly on every change: the cache lives up to an hour.
- `llms.txt` does not refresh by itself: a scheduler is required.
- An extension will not fix a price or a description that is wrong in the catalog.

## Extensions for llms.txt

## Extensions for structured data

## What to read next

- [An AI-ready site](https://llms-full-txt.ru/en/guides/ai-ready-site/) - every layer in order
- [Structured data and JSON-LD](https://llms-full-txt.ru/en/guides/json-ld/) - which markup fits which site
- [What is llms.txt](https://llms-full-txt.ru/en/guides/what-is-llms-txt/) - why a map is needed
- [Validating files and markup](https://llms-full-txt.ru/en/guides/validation/) - how to confirm it all works