Someone’s furnace dies on a cold night. They don’t start opening browser tabs and comparing sites. They ask an assistant — the one on their phone — “who can fix a furnace near me tonight?” The assistant goes and reads a handful of local business websites, then answers with names, numbers, and a plain sentence about who’s open.
If your site is one of the ones it read, you have a shot at that job. If your site is one of the ones it couldn’t read, you were never in the running — and here’s the part that should bother you more than a lost Google click: you don’t get a notification for the visit that didn’t happen. No 404 in your logs, no bounce in analytics. The assistant just quietly moved on to the next business and answered the customer without you. A missed search ranking at least shows up as a missed impression. A missed agent read shows up as nothing at all.
The honest complication, first
Before I make the case for any of this, I want to deal with the part that undercuts a lot of the hype: agentic shopping has not gone the way its loudest promoters said it would. The highest-profile attempts to let an assistant complete a purchase end to end — buy the item, check out, done — have been rolled back or scaled back after launch. The technology to browse a catalog and hand a summary to a human turned out to be a lot more solid than the technology to close a transaction unsupervised. If you’ve seen a headline calling agentic commerce a settled, arrived channel, be skeptical of it. It isn’t, yet.
That matters, but it also isn’t the whole story, and conflating the two parts is where a lot of confused advice comes from. The buying stalled. The reading did not. An assistant answering “who’s nearby, who’s open right now, and does this business do the thing I need” is not a future capability someone is still trying to ship — it is a thing that already happens, today, every time someone asks a phone assistant a local question instead of typing it into a search bar. That’s the distinction the rest of this post is built on: not “AI will transact for your customers soon,” but “AI is already reading and summarizing your business right now, whether or not you’ve done anything to make that possible.”
Why this hits local businesses first and hardest
Big-catalog ecommerce has to solve inventory, payment, fraud, and returns before an agent can safely buy anything. A local service business doesn’t carry that same problem, because a local question is an eligibility question, not a purchase question. Is this business near me? Is it open? Does it do this specific job?
Often nobody has to ask “near me” explicitly — many assistants already have a rough sense of where the person is and fold that into the read, though this varies by product and by whether location permission is granted. That means the local answer is often the easiest one for an agent to give confidently, which also means it’s an answer that gets given with or without your input. For a furnace repair company, a plumber, a roofer — the question an assistant is answering on your behalf isn’t “should I buy this,” it’s “should I recommend this,” and that recommendation is shaped in part by what the agent could actually read off your site.
What actually blocks an agent from reading your site
None of these are exotic. They’re mistakes a site can make by default, not by decision.
- Bot protection nobody configured on purpose. A lot of hosting and security stacks ship with aggressive crawler blocking turned on out of the box. Nobody sat down and decided to block AI assistants — it just came bundled with “protect the site from bad traffic,” and an AI reader looks enough like unwanted automated traffic to get caught in the net.
- No robots.txt, or one that blocks the wrong things. A missing robots.txt is a missed opportunity to say “you’re welcome here.” A robots.txt copied from a template years ago may block crawlers wholesale without anyone realizing an AI assistant’s reader is one of them.
- Business facts that only exist after JavaScript runs. Hours, service area, phone number — if those are injected into the page by client-side script after the initial HTML loads, a lot of readers never see them. They see an empty shell and move on.
- No structured data. Without something machine-readable describing what the business is, where it operates, and when it’s open, an agent is left inferring those facts from prose — and that’s a plausible place for a busy assistant to give up and move to the next result instead.
Any one of these can be enough to take a business out of the answer entirely.
What a real study found — and what it doesn’t tell you
I don’t want to make up a number for how common this is among local trade sites, because I don’t have one, and inventing one would be exactly the kind of thing I’m asking you not to do on your own site. What I can point to instead is a study Crazy Egg published in 2026, in which they ran more than 120 shopping prompts through ChatGPT and Google AI Mode and scanned 1,100 ecommerce sites — and found that, of those 1,100, roughly 15% had a robots.txt file, roughly 13% had a sitemap, and about 41% blocked their agent-readiness scanner outright with bot protection.
A few things worth being precise about. That’s Crazy Egg’s research, not ours — ANTHONY didn’t run this study and hasn’t independently verified the underlying crawl. It measured ecommerce storefronts, a different animal from a local trade business’s marketing site, with different platforms, different plugins, and different default configurations. I’m not going to translate Crazy Egg’s ecommerce figures into a number for your industry — that isn’t what was measured, and borrowing someone else’s data across an unrelated market is exactly the kind of invented statistic I’m trying to avoid here. What the study is useful for is a general, indicative pattern: default web infrastructure — the bot protection, the robots.txt, the sitemap — routinely wasn’t set up with AI readers in mind, across a large sample of sites in a different market than yours. That’s a reasonable thing to take a lesson from. It is not a measurement of your site, or your industry.
What to actually do about it
None of this requires hiring anyone, including us.
- Check what a plain fetch of your homepage actually returns. Not what you see in a browser with JavaScript running — what a bare request gets back.
curl -A "GPTBot" https://yoursite.comfrom a terminal is a quick gut check. If the response is empty or missing your actual content, that’s your first problem. - Make sure your hours, service area, and phone number are in the HTML, not assembled after the fact by a script. If they’re rendered server-side or built into the static page, a reader sees them immediately.
- Add LocalBusiness structured data. Name, address, phone, hours, service area, and geo, marked up so a machine reader doesn’t have to guess it out of paragraph text.
- Look at your own robots.txt and bot protection, and don’t block the crawlers you actually want reading you.
llms.txtand a/.well-known/ai-config.jsonmanifest are worth knowing about too — they’re emerging conventions right now, not settled standards, and no site is broken or penalized for not having them yet. But an explicit allowlist for known AI crawlers costs you nothing and removes the guesswork.
None of that is a sales pitch for a rebuild. It’s a checklist you can run against your own site this week.
The proof, not the pitch
I’d rather show this than argue for it. Every site we build ships with this handled by default — not as an add-on, not as a paid tier, just the standard build. No one can promise you a spot in an assistant’s answer — not us, and not anyone who tells you otherwise. What you control is whether the site can be read when an assistant goes looking. If you want to see it work instead of taking my word for it, see the live demo: it’s a real agent call you can run yourself, in your own browser, against a site we actually built this way. Watch what it can read, and compare that to what your own site would hand back.