# Your Next Visitor Is a Machine When a buyer asks an AI assistant "who should I use for this?", the assistant doesn't take anyone's word for it. It goes and reads - your site, your rivals' sites, whatever it can reach - and assembles an answer from what it found. The buyer never sees your homepage. They see the answer, with you in it or not. That reading is happening now, on your site, whether or not you've planned for it. A growing share of the "visitors" in your traffic aren't people at all; they're machines reading on a person's behalf. And they are the least forgiving audience you have: a human visitor squints past a broken layout, a machine reader takes what it can parse and moves on. This article covers what serving that reader means in practice: every technique in it is running on this site, one click away, and each chapter shows you where to look. The list beside this article is the chapter map. ## The reader you can't see The old shape of being found online: a person searches, sees a list of links, clicks yours, and lands on your homepage - where your design, your photos and your words get their chance. The new shape inserts a reader between you and the buyer. The person asks a question; an assistant reads the candidate sites; the person gets a written answer. Your site's chance to persuade happens inside that machine's reading, or never. ![Diagram: a buyer asks an assistant, which reads your site and two rivals' sites on their behalf and assembles the answer the buyer sees; one rival's site needs scripts the machine can't run, reads as blank, and is missing from the answer; the buyer then visits the winning site in person - today still to make the purchase themselves](/diagrams/machine-ch1-two-readers.svg) A large share of the web is invisible to that reader. Most modern sites lean on scripts: the page arrives half-empty and JavaScript fills in the content after it loads. Human browsers run those scripts without you noticing. The machine readers mostly don't: when Vercel and MERJ [tracked the major AI crawlers](https://vercel.com/blog/the-rise-of-the-ai-crawler) across months of live traffic in late 2024, the readers from OpenAI, Anthropic and Perplexity executed no JavaScript at all - of the big names, only Google's and Apple's readers render a page the way a browser does. Point one of the others at a script-dependent site and it reads the part that arrived in the first response: sometimes a header and a cookie notice, sometimes nothing. Absence is the whole penalty: the site simply never enters the answer, and nobody is told. The buyer asked a real question with money behind it. The assistant answered from what it could read. A business that would have been the right answer wasn't in the reading. A worked example of the difference: every page on this site arrives as complete text in the first response - no script needs to run before the words exist. That single property moves a site from the unreadable bucket to the readable one, and it was a build decision, not an optimisation bolted on later. The rest of this article is the layers on top: giving the reader a clean text version, a map of the site, and pages that say what they are - then an automatic check that keeps all of it true as the site grows. The human step hasn't disappeared - it has moved to the end of the chain. The buyer reads the answer, picks the winner, and then visits that site in person: to look them in the eye, and to buy. Today that final step still belongs to the person; the direction of travel is visible, though, with assistants that can complete a booking or a purchase already arriving, and buyers will hand that step over exactly as fast as they come to trust it. Which reframes what your website is for. The machine's reading decides whether you make the shortlist; the human's visit decides whether you win it - and everything about serving that human visitor well, the design, the navigation, the readability, is its own subject for its own article. Before the chapters walk through them one by one, here is the full set in one place - every machine-readable surface this site ships, live right now. Each link opens the artifact itself, in a new tab: | Surface | What it is | |---|---| | [This article, plain text](/resources/your-next-visitor-is-a-machine.md) | The `.md` twin of this page: the full content with the design stripped away (chapter 2) | | [llms.txt](/llms.txt) | The machine map: what this business is and where every page lives, one line each (chapter 3) | | [llms-full.txt](/llms-full.txt) | The whole site's text in a single file, for readers that digest rather than skim (chapter 3) | | [sitemap.xml](/sitemap.xml) | The classic crawler map, listing every indexable page (chapter 3) | | [rss.xml](/rss.xml) | The feed that announces new posts to anything subscribed (chapter 3) | | Structured data | Not a separate file: it lives inside each page's HTML, declaring what the page is (chapter 4) | > [!IMPORTANT] One reader between you and the buyer > You don't get to choose whether AI systems read your site on buyers' behalf - that's already happening. You only get to choose what they find: a site that hands over its content plainly, or one that reads as a blank page and quietly falls out of the answer the buyer sees. Next: the simplest of the machine surfaces - a plain-text twin of every page. ## The plain-text twin A web page is words wrapped in design. The wrapping is for people: layout, type, colour, photographs, the things the last article on this site is about. A machine reader wants the words and has to dig them out of the wrapping - navigation repeated on every page, cookie banners, decorative markup, the scaffolding that makes a page look right and read badly. So this site gives the machine its own version. Every page here has a plain-text twin at the same address with `.md` on the end: the full content, in reading order, headings marked, links intact - and nothing else. No layout, no scripts, no design to trip over. You're reading the styled version of this article now; [here is this article's plain-text twin](/resources/your-next-visitor-is-a-machine.md). Same words, built for a different reader. ![Diagram: the same page twice - the styled version with layout and images for human eyes, and its plain-text twin at the same address plus .md, just the words in order; a gold arrow marks the twin as the version the machine reader takes](/diagrams/machine-ch2-twin.svg) The twin does two jobs. The obvious one is reliability: a reader that gets clean text can't mis-parse the design, because there's no design to mis-parse. The quieter one is cost. Machine readers work within limits on how much they can take in per request; a styled page spends most of that allowance on wrapping. The twin spends nearly all of it on your actual content, which means more of what you wrote survives into what the machine knows about you. Every page on this site carries one - articles included - and each styled page announces its twin in its metadata, so a reader that lands on the styled version is told where the clean one lives. The signpost is one line, sitting in this very page's head right now: ```html ``` One line per page, generated automatically, and no machine reader ever has to guess whether a clean version exists or where to find it. What should you take from this if your site is a normal site? Not that you need this exact mechanism tomorrow. The transferable point is the principle: the words are the product, and there should be a version of your site where the words are available without a fight. If your content only exists inside a page builder's output, wrapped in six layers of styling markup and assembled by scripts, then the words you paid to have written are, for this new kind of reader, barely there. > [!IMPORTANT] Words a machine can carry away > A machine reader takes your words and leaves your design behind. A clean text version of every page - full content, no wrapping - is the difference between a reader that quotes you accurately and one that reconstructs you from fragments. Next: a reader that can read every page still needs to know which pages exist. The site should hand over the map. ## Handing over the map Reading one page well solves half the problem. The other half: which pages exist, and which matter? A machine reader arriving at a site it's never seen has to crawl - follow links, guess importance, hope the navigation reflects the structure. Crawling is expensive and patchy, and readers doing it at scale spend as little time per site as they can get away with. A site that's easy to map gets read more completely than one that has to be explored. The web's answer is a small convention called `llms.txt`: one file at a fixed address that tells an AI reader what the site is and where its content lives. Ours is [live at /llms.txt](/llms.txt). It opens with a plain-language summary of what this business does, then lists every page with a one-line description and a pointer to its plain-text twin. A reader that fetches that one file knows the whole shape of the site - what exists, what each thing is, where the clean version lives - without crawling anything. ![Diagram: a machine reader arrives at llms.txt, an index listing every page with a one-line description, each pointing to its plain-text twin; beside it, llms-full.txt carries the whole site's text in one request](/diagrams/machine-ch3-map.svg) Alongside it sits the fuller version, `llms-full.txt`: the same map with the actual content inlined - the whole site's text, one request. For a reader that intends to genuinely digest the site rather than skim it, that single file replaces dozens of fetches. And the older machine surfaces still matter and still ship: a sitemap listing every indexable page for the search-engine crawlers, and a feed announcing new posts. Different readers arrive with different habits; the site keeps a door open for each of them. There's a subtlety in the summary line that's worth an owner's attention, because it's a writing decision, not a technical one. The paragraph at the top of the map is, for many machine readers, the first and sometimes only description of your business they'll ingest. It deserves the same care as your homepage headline: who you are, what you do, who it's for - in plain words, without slogans. A map that opens with marketing copy tells the machine nothing it can use; a map that opens with a clear description gets repeated back to buyers more or less verbatim. The takeaway travels to any site: you already tell human visitors where things are - that's your navigation. The machine equivalents are three small text files, cheap to generate and entirely invisible to your human audience. There is no trade-off to weigh. A site with the map serves both readers; a site without it merely hopes the crawler works everything out. > [!IMPORTANT] Don't make the reader guess > A machine reader gives every site a limited slice of attention. Spend that slice well: hand over an index that says what the site is and where the content lives, and the reader spends its attention on your words instead of on finding them. Next: beyond words and maps - pages that state, in a machine's own terms, what they are. ## Pages that say what they are Clean text tells a machine what a page says. It still leaves the reader inferring what the page *is*. Is this an article or a product listing? Is the business behind it a company or a person? Is the name in the byline the founder, an employee, a guest? People resolve this from a hundred visual cues. Machines resolve it from a purpose-built layer: structured data - a block of labels, in a standard vocabulary, in which the page states plainly what it is. Every page on this site carries that layer. This page declares itself an article, with its title, its description, its dates, and its publisher. The publisher is declared once as an organisation - name, address of record, logo, founder - and every other page points at that same declaration rather than repeating it. The founder is declared as a person, linked to an external profile so a machine can confirm that the Mark Brownlie here and the one on LinkedIn are the same Mark Brownlie. Each label references the others, so the pages assemble into one consistent story rather than a pile of disconnected claims. Here is what that actually looks like - an excerpt from this very page's declaration, trimmed for reading but otherwise as shipped: ```json { "@type": "TechArticle", "headline": "Your Next Visitor Is a Machine", "datePublished": "2026-07-19", "author": { "@type": "Person", "name": "Mark Brownlie" }, "publisher": { "@id": "https://backstage.playhouse.digital/#organization" } }, { "@type": "Organization", "@id": "https://backstage.playhouse.digital/#organization", "name": "Playhouse Digital", "founder": { "@type": "Person", "name": "Mark Brownlie", "sameAs": ["https://www.linkedin.com/in/markbrownlie/"] } } ``` Notice the `@id` doing the joining: the article doesn't repeat who the publisher is, it points at the one declaration of the organisation, and the organisation's founder carries the external link that pins down which Mark Brownlie. Four page types on this site - home, articles, listings, service pages - each declare their own shape, and all of them reference the same business entity. ![Diagram: a declared page carries linked labels - I am an article, published by this business, founded by this person - each referencing the others; an undeclared page sits surrounded by question marks: probably a company, maybe an article, author unknown](/diagrams/machine-ch4-declared.svg) Why go to the trouble? Because answer engines prefer material they can lift cleanly, and declared, structured content is the easiest material there is. The easier a claim is to extract and verify, the more likely it is to be used. Structured data is that idea applied to the page itself. The same logic reshapes the writing, which is where this stops being a developer topic and becomes an owner one. Content that machine readers quote well leads with the answer: a heading that asks the reader's actual question, followed by a self-contained couple of sentences that answer it before elaborating. Short paragraphs. Real tables for real comparisons. Claims with numbers, numbers with sources. None of this harms the human reading experience - it's roughly what good writing advice said anyway - but it now has a second audience with no patience for throat-clearing at all. For your own site, the question to ask is unglamorous: does any page on it say what it is, in the machine layer? Most owner-managed sites answer no - the page builder didn't add it and nobody asked. It's a modest piece of work with an outsized effect, because it upgrades every page from "words a machine must interpret" to "claims a machine can use". > [!IMPORTANT] What gets quoted gets chosen > Answer engines build from the most extractable material available. A page that declares what it is, leads with answers, and sources its numbers is doing the machine's work for it - and the sources a machine finds easy to use are the sources that end up in front of buyers. Next: the one thing underneath all of it that most sites get wrong - speed. ## Site speed Underneath the named surfaces are the ordinary things any decent site should do: one `h1` per page, headings in order, regions labelled for what they are, alt text on every image, a canonical URL so nothing's indexed twice. We do all of it, and it puts us ahead of most: these pages score 100 for accessibility on Google's Lighthouse tool, where the typical site sits around 85 ([HTTP Archive, 2025](https://almanac.httparchive.org/en/2025/accessibility)). The one thing here that actually matters is weight. Every page is built in advance as a finished file. Nothing's assembled when you arrive - no database call, no scripts stitching the content together after it loads. Measured live in July 2026, our pages come in at 12 to 23 kilobytes. The median web page is 2.6 megabytes ([HTTP Archive, 2025](https://almanac.httparchive.org/en/2025/page-weight)), and it climbs every year. A machine notices that. It reads to a budget - so much content per request, so much time per site. A page that arrives whole in 20 kilobytes gets read in full. A 2.6-megabyte page, half of it scripts the reader won't run, gets skimmed or skipped. The buyer from chapter one lands on the same light page and just feels it as fast. ![Diagram: two pages side by side. On the left, this site's page - gold-outlined, 12 to 23 kilobytes, arriving complete with no script to run, read in full. On the right, a typical page - 2.6 megabytes, most of its weight in scripts the reader won't run, content arriving late, sampled and then dropped by a reader working to a budget](/diagrams/machine-ch5-anatomy.svg) Want to check your own site? Run it through Google's PageSpeed Insights - the diagnostics show the total page size in kilobytes. Most page-builder sites come back heavy, weighed down with scripts. That's the page a machine gives up on. > [!IMPORTANT] Weight is the differentiator > Clean structure and alt text are basics - every decent build has them. Weight is what separates sites. A page that arrives whole in kilobytes gets read; a script-heavy, multi-megabyte one gets skimmed and dropped. Machines feel it first, buyers second. Next: all of this is easy to break later without anyone noticing - so nothing ships until the build has checked it. ## It checks itself All of this is easy to set up once and easy to break later. Add a page next month, forget its plain-text twin, and nothing errors - the map just goes on describing a site that's no longer there. Nobody notices, because the readers it fails don't complain. So none of it relies on anyone remembering. Every build runs the same check over every page: has it got its plain-text twin, is it on the site map, does it say what it is? Miss any one and the build stops and names the gap - nothing ships until it's fixed. The next page you add meets the same check, whether anyone's thinking about it or not. ![Diagram: pages flow toward publication through a gold gate asking three questions of every page - plain-text twin present, on the site map, says what it is; complete pages ship, and one bare page is bounced back with the missing pieces named](/diagrams/machine-ch6-guard.svg) We tested it the only way worth testing: added a broken page on purpose - no twin, no map entry, no declaration - and ran the build. It stopped and named the gaps. A check you've never seen fail isn't one you can trust; this one catches. For your own site, three quick checks, none of them technical. Put your address into an AI assistant and ask what the business does and who it's for - what comes back is what your site taught it, gaps and all. Add `/llms.txt` to your address and see if there's a map or a 404. And ask whoever builds your site: "what does a machine reader see when it visits us?" Text without scripts, a map, and pages that say what they are is a good answer. A blank look is also an answer. > [!IMPORTANT] No upkeep > You shouldn't have to remember any of this. Set it up once and let the build enforce it: every page checked automatically, nothing published until it passes. A site that was readable last year won't stay readable on its own.