The SiteRoot team7 min read
Someone opens ChatGPT and types "who does emergency plumbing in Brunswick". A few seconds later they get four sentences naming two or three businesses, with a couple of links under them. No map, no ten blue links, no ads. Just an answer and a very short list.
Two completely different mechanisms can produce that answer, and it matters a great deal which one is running. The first is the model's own memory, absorbed during training from a snapshot of the web that is months or years old and cannot be updated on request. The second is a live fetch: the assistant runs a search behind the scenes, pulls back a handful of pages, reads the text in those pages and writes an answer from what it just read. The second one is the one that decides most local recommendations, and it is the only one a small business can do anything about. So the practical question is not "how do I get into the model". It is "when the assistant fetches a handful of pages about plumbers in Brunswick, is mine one of them, and can it be read once it arrives".
What actually happens when someone asks an assistant for a plumber
The assistant decides it needs current information, which for anything local it always does. It writes a search query of its own, often several, and sends them to a search index. It then fetches some small number of the results, usually a handful rather than dozens, because reading pages costs it time and money. It reads the text that comes back. Then it writes an answer, increasingly showing which pages it used.
Two gates, then: you have to be in the list the search returns, and you have to be readable once it fetches you. The second is newer, and a lot of sites quietly fail it.
Why it matters that these crawlers do not run JavaScript
This is the single most important technical fact in this post, so here it is plainly.
When a browser loads a modern website, it does two things: it downloads the page, and then it runs the scripts on the page, which often go and fetch the actual words and draw them in. A person never notices the difference because it happens in a fraction of a second.
Many of the fetchers used by AI assistants only do the first half. They request the page, take the text that comes back in that one response, and move on. They do not wait around running scripts. If your site is built so that the page arrives as an almost empty shell and the content appears a moment later, then what the assistant receives is the shell. Not a thin version of your site. Effectively a blank one.
You can check your own site in thirty seconds. Open it, right click, choose "View page source", then use the browser's find to look for a sentence you know is on the page. If it is there, you are fine. If the source is mostly script tags and none of your sentences are in it, that is what an assistant sees too.
This is not an exotic problem. It is the default behaviour of several popular ways of building websites, and the people who built them were optimising for a browser, which is reasonable right up until the most important visitor stops being one.
Why an assistant needs facts stated rather than implied
The second half of readability is about writing rather than engineering.
A human visitor infers enormous amounts from layout. A photo of a van with a Brunswick number plate, a hero image of a bathroom, a phone icon in the corner: a person assembles "local plumber, does bathrooms, ring here" without reading a word. A model reading the text of that page gets a heading, three two-word labels and a phone number, and has nothing to say about you.
So state things. Not keyword-stuffed, just the way you would say them out loud.
- Say what you are. "We are a plumbing business based in Brunswick" beats a logo and an implication.
- Say where you go, in a sentence. "We cover Brunswick, Coburg, Pascoe Vale and Fawkner" is a quotable fact. A footer list of forty suburbs is not.
- Say what you do, in prose. Each service deserves a paragraph, not an icon with two words under it.
- Say when. "Open 7am to 4pm weekdays, with emergency call outs after hours" is exactly the kind of sentence that gets lifted into an answer.
- Say the boring details. Licence number, ABN, how long you have been going. These are what a careful answer wants to include.
The test is simple. If someone read only the text of your page aloud, with no pictures, would they be able to answer "who are they, where are they, what do they do and how do you reach them"? If not, an assistant cannot either.
Why your price list as a PDF or an image is invisible
Two formats swallow information whole.
An image of text, whether that is a menu photographed and uploaded or a price list exported as a picture, contains no text as far as most fetchers are concerned. It is a rectangle of pixels.
A PDF is better but inconsistent: whether it gets read depends on the tool. Anything that matters enough to be quoted back to a customer belongs as ordinary text on an ordinary page.
The same goes for anything that only appears after a click: an accordion that loads its answer when opened, or a chat widget holding all your service details. If it is not in the page when the page arrives, treat it as not there.
Does this replace search, or sit on top of it
Sit on top, at least for now, and that is good news.
Most assistants search a conventional index underneath. Being findable the traditional way is still the entry ticket, so nothing you already do stops mattering. What changes is what happens after: instead of ten links to choose from, the person gets two or three names and a paragraph. A shortlist is harsher than a page of results.
That is the honest downside. It also means the work is the same work, done properly: be readable, be specific, be current.
What can a small business actually do about it
A short list, in order of how much it matters.
- Check that your words are in the page source. If they are not, nothing else on this list will help.
- Write the facts as sentences. Who, where, what, when, how much roughly, how to make contact.
- Give each real service its own page, with prose on it rather than a grid of labels.
- Keep it current. An assistant quoting your 2023 hours is worse than one not mentioning you.
- Publish an llms.txt file, a short plain text summary of your business at the root of your site that AI tools can read directly.
- Be mentioned elsewhere. Directories, associations, local media. Assistants assemble from several sources and corroboration counts.
What you cannot do is buy a position in an answer, or be promised one. There is no auction and no submission form, and nobody selling AI ranking services has a mechanism behind the offer.
What SiteRoot does about it
Every site we build serves its words as real text in the page, so what a fetcher receives in that first response is the same content a person sees. That is a build decision, and it is the one that matters most here.
On top of that, each site publishes an llms.txt file describing the business in plain words, a file listing every page for search engines that is refreshed on every publish, a block of facts on each page naming the specific business type Google publishes for that trade, and contact details written as text rather than baked into an image. You can see all of this on the sites people have already published, like priority-plumbing.siteroot.com.au or danthu-dental.siteroot.com.au.
None of that is a promise that an assistant will name you. Nobody controls that. What it does mean is that if one goes looking, there is something there to read.
