llms.txt and Schema, in Plain English

Schema markup is a set of hidden labels you add to your website that tell machines (search engines, AI assistants, browsers) what your content actually means. To a machine, raw HTML is just a wall of words; schema turns that wall into facts it can read: this is a business, this is a person, this is a question and the answer that goes with it. llms.txt is a plain-text file you place at the root of your site as an index for AI engines: a short, curated list of your most important pages and what each one covers. Add both, and your site becomes far easier for an AI system to read, understand, and quote back to the person who asked. Both tools are part of the broader visibility infrastructure that determines whether your service business gets found in traditional search and AI-powered answers alike.

Neither one is magic, and neither moves a number on its own. They're the quiet plumbing underneath everything else, the part nobody photographs, the part that decides whether an AI confidently names you or quietly leaves you out. What follows is how each one works, which kinds of schema actually earn their keep for a small business, and what "AI-readable" means once you strip the buzzword off it.

What is schema markup?

Schema markup is a second layer of meaning that sits on top of your page, written for machines rather than people. A visitor reads your homepage and instantly gets that you run a bookkeeping firm two towns over. A crawler reading the same page sees a string of text with no built-in clue about what any of it represents. Schema closes that gap by wrapping your content in a shared vocabulary, maintained by Schema.org, that every major search engine and AI platform already agrees to read the same way.

In practice it lives inside a <script type="application/ld+json"> block: a compact JSON object that names the things on your page. Your visitors never see it. It quietly tells the machine what it's actually looking at, so the machine stops inferring and starts knowing.

The payoff is concrete. Schema is the reason one Google result shows star ratings, an FAQ accordion, and a breadcrumb trail while the one below it shows ten plain words and a link. It's why some businesses earn a Knowledge Panel (the summary box that surfaces on the right side of a search) and why an AI tool can pull a clean, accurate description of you instead of stitching one together from scraps. A crawler without those labels has to work much harder, and a crawler working that hard tends to either get you wrong or skip you for an easier source.

There's a bigger structure behind this called the Knowledge Graph: Google's database of real-world entities that powers the Knowledge Panel and feeds a lot of AI answers. Landing in it generally takes a web of corroborating references pointing at the same entity, not one tidy file on your own domain. Wikidata, the open knowledge base, now feeds that graph directly, which is why a Wikidata entry for your business quietly carries more weight than it looks like it should. Schema on your own site is one thread in that web. It won't get you in by itself, but the entity rarely holds together without it.

Which schema types matter for a small business?

Five schema types do almost all the work for a service business: Organization, LocalBusiness, Article, FAQPage, and Person. Schema.org defines hundreds more, and almost none of them are about you. Here is what each of the five earns its place doing:

• Organization. The anchor. It establishes that your site stands for a real company with a name, URL, logo, and contact details. Everything else you add eventually points back here.
• LocalBusiness (or a tighter subtype like PlumbingService or LandscapingBusiness). Adds your service area, hours, and the local signals Google leans on when it decides whether to drop you into the map pack.
• Article (or BlogPosting). Flags a page as editorial content: who wrote it, when it ran, and what it belongs to, the details that make a page worth citing.
• FAQPage. Labels your questions and answers as exactly that, so a search engine can render them as a rich result and an AI engine can lift them without guessing where one ends and the next begins.
• Person. Names a real individual (an author, a founder) with credentials and one consistent identity across the web. Authorship signals are weighing heavier and heavier in how AI tools size up whether a source can be trusted.

A bare-bones Organization block reads like this:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Summit Services",
  "url": "https://example.com"
}
</script>

That's a starting point and nothing more: four fields, a minute of typing. In production you'd hang your logo, address, and sameAs links to your Google Business Profile and social accounts off of it, then wire it to your LocalBusiness entity. The shape never changes, though: a small, well-formed object that lets a machine identify and describe you without improvising.

The leverage shows up when you stop treating these as separate tags and start chaining them. When a BlogPosting points to an author that resolves to a real Person, and that person resolves to your Organization, you've built a graph: a small web of facts that hang together. A machine reading that chain can state plainly that this article was written by this named person who works for this verified company. A machine reading a loose, unconnected page is back to guessing. When we add a chained graph like that to a client's site, the cleaner signal we notice first isn't a ranking move. It's that an answer engine starts attributing a page to the actual author instead of "an article on the site."

What is llms.txt, and why did it appear?

llms.txt is a convention that surfaced in late 2024, once AI web crawlers went from rare to everywhere. The mechanics are plain: you write a plain-text file at yourdomain.com/llms.txt listing your most important pages, each with a one-line description. Crawlers that honor the convention treat it as a head start (a hand-drawn map of your content) instead of grinding through your whole site to work out what's where.

It borrows its shape from two files you may already know: robots.txt, which tells search crawlers what to skip, and sitemap.xml, which lists every page you've got for indexing. The job is different, though. Where those two handle access and inventory, llms.txt is an editorial call: you're telling an AI engine which handful of pages best capture how you think and what you actually know. It reads less like a directory and more like a recommendation: start here if you want to understand us.

Nobody owns the convention, there's no penalty for skipping it, and not every crawler reads it yet. What it buys you is less work for the machine that does. A machine that has to do less work to understand you tends to describe you more accurately and more generously. For a file that takes half an hour to write once, that's a lopsided trade in your favor.

The format stays deliberately thin: a heading per section, then a list of URLs with short, human-readable notes. No markup, no syntax to memorize. If you want, a companion file at /llms-full.txt can carry the full text of your key pages, for engines that would rather download the content outright than chase links to find it.

How do they make you AI-readable?

They split the work an AI engine has to do: schema makes your content clean to extract, and llms.txt makes your best pages easy to find. An AI answer gets built in two moves: find pages that hold the right information, then decide which of those pages to trust enough to repeat. Schema and llms.txt each take one of those moves off the machine's plate, which is the whole reason they work together rather than overlapping.

Schema makes the extraction clean. When a crawler reads your FAQPage and sees that a specific block of text is the answer to a specific question, it stops interpreting. It knows what the text is, who wrote it, when it was last touched, and which company stands behind it. That certainty is the line between a passage that gets lifted into an AI answer word-for-word and one that gets mangled into something you wouldn't recognize, or dropped because the machine couldn't tell what it was.

llms.txt makes the finding easier. Rather than crawl everything and reverse-engineer what matters, an agent can read your index and head straight for the pages that show your best work. That matters most for a smaller site that hasn't piled up enough inbound links to look authoritative the old-fashioned way. The file lets you say "these are the ones to trust" without waiting years for the rest of the web to vouch for you first.

That number points at something larger than statistics. Format itself is a signal. A page with clear numbers, an explicit structure, and labeled answers is simply easier to process, and machines reward what they can process without friction. Schema is the technical half of that signal; llms.txt is the navigational half. Read together, they tell an AI system that you've already done the work of organizing this for it, and here's where the good stuff lives.

The reassuring part is that none of this means rewriting what you've already published. It means wrapping the words you've got in a structure a machine can follow. We saw this play out on lyfework.io itself: after we added the schema graph and an llms.txt, the AI crawlers started reaching our resource pages directly instead of bouncing around the site, and the first AI citation pickup followed not long after. The writing was already there. The labels were what let the engines use it.

For a fuller walkthrough of becoming the source an assistant names out loud, read how to get cited in ChatGPT and AI search, where schema and llms.txt are two of the five systems it covers. And for why AI visibility is now the same infrastructure problem as ordinary search, see how customers find businesses now.

How can you see this in the wild?

Open a real file: the fastest way to understand what these look like is to read one that's already live. Ours lives at /llms.txt, and it lists the pages we think best show how we work: this blog, the service pages, the tools. It's not an auto-generated sitemap dump; it's a short list written for a reader that happens to be a model. Across the client sites we've shipped it on, the pattern holds: most of the sites we've added it to now get cited by name when someone asks an assistant about their specialty.

The schema on this very page runs on the same logic. Every article in this blog ties to a BlogPosting node that points at a Person author node that resolves to the Lyfework Organization node. The FAQPage below is labeled explicitly, so its questions and answers come out whole instead of interpreted. Open the page source, search for application/ld+json, and you're looking at exactly what a crawler sees.

You don't need a developer to check any of this. Every major browser ships a developer-tools panel for reading the source. Google's Rich Results Test will tell you whether your schema is valid and which rich features it earns you. Schema.org's own docs describe each type in plain words. The barrier here is genuinely low, and the real obstacle for most owners is simply not knowing these tools exist, which is the entire reason this post does.

The systems that make a business findable (schema, llms.txt, a clean site structure, a content engine that keeps producing) never look impressive from the outside. They're the technical floor under the three layers of getting found: the unglamorous infrastructure that decides who an AI assistant surfaces and who it forgets when a customer asks a question. Lay that groundwork and visibility tends to follow. Leave it out and you're betting the whole thing on luck. Our full capabilities list covers how Lyfework builds these systems for service businesses on Florida's Treasure Coast.