llms.txt and JSON-LD in Webasyst

The map

1. App datacategories, products, pages, posts
2. A scheduled buildor a button in settings
3. llms.txt and llms-full.txtat the root of the domain

The meaning

1. Page dataproduct, post, topic, question, photo
2. Built on rendercached for an hour
3. A JSON-LD blockin the code of every page

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.

• 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.

• 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.

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.

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.

What is known and what is not

Confirmed

• Files and markup are built from app data and refreshed without manual editing.
• Only public content reaches either layer.
• Google and Yandex 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.

The extensions remove manual work. They promise nothing about search results or AI answers.

• An AI-ready site - every layer in order
• Structured data and JSON-LD - which markup fits which site
• What is llms.txt - why a map is needed
• Validating files and markup - how to confirm it all works