llms.txt and structured data: the machine-readable layer of a company website

A company website has two audiences. People read the pages. Machines — search engine crawlers, AI assistants, feed readers, link previews — read the pages too, but they read them differently. They look for signals that tell them, without guessing, what an organisation is, who runs it, what each page is about and which pages matter.

The machine-readable layer is where those signals live: llms.txt, schema.org structured data, sitemaps, robots.txt and a few related files. None of them is magic. Together they remove ambiguity, which is most of what "being understood" means for a machine.

This article explains what each piece does and what oryvelon.com publishes. We run a group of independent companies with their own domains, so our setup has one extra job: describing the relationship between a parent group and its companies clearly, without blurring them into one entity. The broader approach to discoverability is in Search and AI visibility for companies.

What the machine-readable layer is for

Before the details, it helps to be clear about the goal. Structured data and llms.txt do not make a weak page strong. They do three narrower, useful things.

1. Identify entities. They state, in a fixed vocabulary, that this is an organisation with this name, this logo, these founders and these related organisations.
2. Classify pages. They say that this page is an article, that one is an FAQ, this other one is a contact page.
3. Point to what matters. They list the pages worth reading and when they last changed.

A machine could often work these out from the visible page. But "often" is the problem. When a group has a parent brand, eight companies and two founder sites, inference goes wrong in predictable ways: a company gets described as a product of the group, the group gets described as an agency, a founder gets associated with the wrong brand. Explicit markup reduces those errors.

llms.txt: a curated map for AI systems

What it is

llms.txt is a proposed convention rather than a formal standard. It is a Markdown file served at /llms.txt that gives AI systems a short, readable overview of a site: a title, a one-paragraph summary, and lists of the most important links with a sentence about each. Some sites also publish a longer companion file, commonly llms-full.txt, with the full text of key content.

The reasoning is practical. A language model or an AI retrieval tool that visits a site has limited attention. Navigation menus, cookie banners, scripts and layout markup all compete with the actual content. A clean Markdown file puts the essentials first, in a format models handle well.

What it is not

It is worth being honest about the limits. llms.txt is not a ranking signal that search engines have committed to. Not every AI system reads it. It does not control how your content is used — that is what robots.txt and the terms of individual crawlers are for. Think of it as a well-written press kit left on the front desk: helpful to those who pick it up, harmless to those who do not.

What oryvelon.com publishes

Our llms.txt has four parts:

• A heading and summary. One paragraph that says what Oryvelon is — a digital company builder and venture group that builds and operates independent digital businesses — and what it is not. It states plainly that Oryvelon is not an agency and that services are provided by its company WeAreMedia. It names the founders.
• Key pages. Links to Companies, About, How we build, FAQ, Press and Contact, plus a link to the full-facts file.
• Companies. One line per company: the name, a link to its page on oryvelon.com, its one-sentence description and its own website.
• Insights. Each article's title, link and summary.

Our llms-full.txt goes further. It contains the group description, the full FAQ in question-and-answer form, a section for each company (problem, what it does, who it is for, business model and principles), and the full text of every Insights article.

Both files are generated at build time from the same data that produces the visible pages. That detail matters more than the file format. If the llms.txt summary were written by hand, it would drift from the site within weeks. Because it is generated, a change to a company's description in our content data changes the company page, the structured data and the llms files together.

Writing a good llms.txt summary

The summary paragraph is the part most likely to be quoted, so we write it like a definition:

• Start with the name and the category in one sentence.
• Add what it does, in concrete terms.
• Add the most common misconception and correct it.
• Name who is behind it.

Avoid marketing language. "We build and operate independent digital businesses" is quotable. "We reimagine the future of digital ventures" is not — a model cannot do anything useful with it.

schema.org Organization: identity with stable IDs

The basics

schema.org is a shared vocabulary for describing things on the web, supported by the major search engines. It is usually embedded as JSON-LD in a <script type="application/ld+json"> block. For a company site, the most important type is Organization.

A good Organization entry includes the name, URL, logo, a description, contact details and — this is the part many sites skip — a stable @id. The @id is a URL-like identifier that lets different pages and different markup blocks refer to the same entity. Ours is the site root with a fragment, https://oryvelon.com/#organization. Every page that mentions the organisation as publisher or subject points to that same identifier, so machines do not see twenty slightly different Oryvelons.

Founders

On the pages where it belongs, our Organization entry includes a founder list with two Person entries: Uğur Keser and Sinem Keser. Each has a url pointing to their own authority site and sameAs links to profiles that describe the same person. This ties the group to the people behind it without making the group site into a personal page. How the founder sites relate to the group is covered in Founder authority sites.

subOrganization: describing a group without merging it

This is the part most specific to a company builder. schema.org has a subOrganization property for exactly the relationship we need: a parent organisation with related organisations beneath it.

On oryvelon.com, the full Organization entry lists each company as a subOrganization. Each entry has:

• its own @id, based on the company's page on oryvelon.com, for example https://oryvelon.com/company/merchnivo/#org;
• the company's name;
• a url pointing to the company's own domain, such as https://merchnivo.com/;
• the same one-sentence description used on the page and in llms.txt.

Each company page on oryvelon.com then carries its own Organization entry using that same @id, with a parentOrganization reference back to the group's @id. The parent's list and the company's page describe one entity, not two, and the relationship is stated from both directions.

The choice of url is deliberate. The company's authoritative home is its own domain. Oryvelon's page about MerchNivo is a description from the parent, not MerchNivo's website. That mirrors how we think about the companies in general: they share infrastructure with the group but stand on their own. See Designing every company so it could stand alone and Naming, domains and brand architecture.

On each company's own website, the company's Organization markup is its own. It can mention the parent through parentOrganization if the company chooses to, in line with the light "An Oryvelon company" endorsement. It never adopts the group's @id or pretends to be the group.

What we leave out

We do not add properties we cannot support. No aggregateRating without real, visible reviews. No award, no numberOfEmployees, no foundingDate unless it is accurate and stated on the page. Structured data is a set of claims. Claims should be true and verifiable on the page they appear on.

Article markup for long-form content

Each Insights article carries Article markup with:

• a stable @id for the article;
• headline, matching the visible title;
• description, matching the summary shown on the page;
• datePublished and dateModified;
• articleSection and wordCount;
• author and publisher, pointing to the Organization @id;
• the canonical URL.

The Insights index uses Blog with a list of BlogPosting entries. Category pages use CollectionPage with the articles they contain. Every page has a BreadcrumbList that matches its visible breadcrumb.

The rule we apply is that every value in the markup must be visible on the page in some form. If the markup says the article was published on a date, the page shows that date. If the markup has a description, readers can see that description. Markup that says more than the page is at best ignored and at worst treated as an attempt to mislead.

FAQPage: questions answered in one or two sentences

Every Insights article ends with three frequently asked questions, and each company page has its own FAQ. Those questions are marked up as FAQPage, with each Question and its acceptedAnswer.

We write these answers with machines in mind as much as people:

• Self-contained. Each answer makes sense without the question in front of it. "No. Each product has its own AI project, keys and logs" is weaker than "The gateway does not share data between companies; each product has its own AI project, keys, prompts and logs."
• Short. One or two sentences. Long answers get truncated wherever they are shown.
• Accurate and visible. The same text appears on the page, not only in markup.
• Real questions. The questions are ones people actually ask — "Is Oryvelon an agency?" — not keyword variations dressed as questions.

Search engines have reduced how often they show FAQ rich results, so we do not add FAQs to chase a visual feature. We add them because a clear question with a clear answer is the most quotable unit of content there is, for search snippets and for AI assistants alike.

Other schema types we use

A few more types round out the site. We use them because they describe pages accurately, not to decorate.

Where several entities appear on one page, we put them in a single @graph, with cross-references by @id. That keeps the structure explicit: this page is part of that website, published by that organisation, which has these sub-organisations.

Sitemaps, feeds and crawler access

Sitemaps

A sitemap is the oldest machine-readable courtesy on the web, and still one of the most useful. It lists the URLs you want indexed and when each last changed.

On oryvelon.com, the main sitemap.xml lists indexable pages with honest lastmod dates. A second sitemap lists Insights articles. Pages that should not be indexed — the contact form's thank-you page, internal templates, the admin panel — are excluded, and a page is never both in the sitemap and marked noindex.

Honest lastmod values matter. If every page claims to have changed today, crawlers learn to ignore the field. We only update it when the content actually changes.

RSS feed

Insights also publish an RSS feed. It is a simple, well-supported way for readers, aggregators and some AI tools to pick up new articles with their titles, links, dates and summaries.

robots.txt

Our robots.txt allows crawling of public pages, blocks form handlers, the thank-you page and the admin panel, and lists both sitemaps. It explicitly allows the major search engine crawlers and the named crawlers of well-known AI assistants to read public content. That is a choice: our public pages exist to explain what the group is, and we would rather assistants describe us from our own words than from secondary sources.

Each company makes this choice for itself. A company with content that it does not want used for model training can allow search-oriented crawlers and disallow training crawlers where the operators distinguish between the two. The setting belongs in each company's source of truth, not in a group-wide default.

Change notifications

When pages change, we can notify search engines that support the IndexNow protocol, using a key file published at the site root. It shortens the delay between publishing and recrawling. It is optional and costs almost nothing.

Keeping the machine layer honest

The most common failure with structured data is not a syntax error. It is drift: the page changes and the markup does not, or a hand-written llms.txt describes a product as it was a year ago.

We avoid drift with one rule: generate the machine-readable layer from the same data as the visible page. On oryvelon.com, company names, descriptions, FAQs and article metadata live in one place. The build produces the HTML page, the JSON-LD, the sitemap entries, the feed and the llms files from that single source. Change it once and everything agrees.

This is the same idea as a company's source-of-truth document, applied to a website. It also follows the principle we use in our AI products: verified data decides what is true, and generated text only presents it. See AI explains, verified data decides.

We also check the output rather than trusting it. The things worth checking are simple: that JSON-LD parses, that every @id referenced actually exists on the page or site, that FAQ markup matches visible questions, and that sitemap URLs return a success status and are not blocked by robots.txt. Checks like these take seconds and catch most mistakes before they ship.

How the companies set this up

Every company inherits the same pattern on its own domain, adjusted to what it is.

• MerchNivo marks up the organisation and its product pages, with FAQs about data sources and what the assistant does and does not do. Its llms.txt makes the key point early: numbers come from the store, never from the model.
• KeşifAtlası is careful about FAQ markup. Answers about eligibility describe how the rules database works, never a specific person's outcome, and they state that the product does not give legal advice. See Rules engines for eligibility.
• Noveniq is a store, so product markup matters most: name, images, price, availability — all drawn from the live catalogue so markup and page agree. Stock status that lies is worse than none. See Inventory truth.
• EduRelia keeps its public markup about the organisation and its offering. Nothing about students appears in any public machine-readable file.

The group site describes all of them. Each company describes itself. Neither contradicts the other, because both start from the same fixed facts.

A short checklist

• Publish /llms.txt with a definitional summary, key pages and a one-line description of each important section; optionally add /llms-full.txt.
• Give your Organization a stable @id and reference it everywhere.
• Describe related organisations with subOrganization (or parentOrganization from the child), each with its own @id and its own website URL.
• Add Article, FAQPage and BreadcrumbList markup that matches what is visible.
• Keep sitemaps limited to indexable pages with honest lastmod dates.
• Decide deliberately which crawlers to allow, per company.
• Generate every machine-readable file from the same data as the page, and validate after every build.

Summary

llms.txt and structured data are the machine-readable layer of a website: they identify the organisation, classify each page and point machines to what matters. On oryvelon.com we publish llms.txt and llms-full.txt, schema.org Organization markup with stable IDs, founders and a subOrganization entry for each company pointing to its own domain, Article and FAQPage markup that matches the visible page, honest sitemaps, an RSS feed and a deliberate robots.txt. All of it is generated from the same source as the pages people read, so the group and its companies are described consistently and never merged into one entity.

Questions and answers

What is llms.txt?

llms.txt is a proposed convention: a Markdown file at the root of a website that gives AI systems a concise summary of the site and links to its most important pages. It is a courtesy file, not a ranking mechanism.

How does Oryvelon mark up its companies in schema.org?

The Oryvelon Organization lists each company as a subOrganization with its own @id, name, description and website URL, and each company page on oryvelon.com carries its own Organization entry with the same @id.

Does structured data guarantee rich results or AI citations?

No. Structured data helps machines understand a page accurately, but search engines and AI assistants decide independently what to show. Its main value is removing ambiguity.

Published by Oryvelon, a digital company builder · About the group · Our companies · More in Growth, Search & Measurement

NextUTM standards across brands: one naming convention for a group of companies →