Answer Engine Optimization for Small Businesses: What I Shipped on My Own Site
Answer engines don't need a new marketing religion. They need your site to state facts a machine can read — and to say something when the JavaScript doesn't run.
The pitch showing up in my inbox is that answer engine optimization is a brand-new discipline, sold by the same people who sold SEO packages last year, and that I need a retainer to survive it. That's mostly wrong, and the part that's right is smaller and more boring than the pitch. Answer engines — the AI assistants people now ask instead of typing keywords — don't need a new marketing religion. They need your site to state facts in a form a machine can read, and to still say something when the JavaScript doesn't run. Most small business sites fail the second test without anyone noticing.
I rebuilt my own site around that idea, so everything below is something I shipped and can check, not a theory I'm selling.
What an answer engine actually needs from you
A search engine ranks pages. An answer engine composes a reply and decides whether to cite you inside it. That changes what matters. It isn't enough to be relevant — your page has to contain a claim the machine can lift, attribute, and be confident about. Vague positioning copy gives it nothing to quote. A sentence that says who you are, where you are, what you build, and for whom gives it everything.
So the work splits into two questions. Can the machine read your page at all? And once it reads it, does it find checkable facts or marketing fog?
The four things I shipped on my own site
A plain-text summary at a known address. My site serves an llms.txt file: a short, machine-readable description of what the company is, where the canonical pages are, and who the founder is. I'll be honest about its status — this is a proposed convention, not a standard any engine promises to honor. It costs almost nothing to publish and it forces you to write one paragraph that says what you do without adjectives, which is useful even if no crawler ever fetches it.
Structured data that states facts, not adjectives. The homepage carries organization and local-business markup with the address, the phone number, the founding year, the certifications and the service lines, and the FAQ page carries question-and-answer markup. This is the difference between a machine inferring what you might do and a machine reading what you are. Keep it truthful and keep it matching the visible page — markup that claims something the page doesn't say is a liability, not a trick.
Content that survives with no JavaScript. This is the one that bites small businesses hardest, and I'll explain why below.
A sitemap, and a way to tell engines the moment something changes. When I publish a post, the sitemap regenerates and the new address is submitted through IndexNow, which hands it to Bing and the engines built on it, including Microsoft Copilot. Submission doesn't guarantee indexing. It removes the waiting.
The JavaScript problem nobody warns you about
Modern sites are often single-page applications: the server sends a nearly empty shell, and JavaScript paints the content in the browser. Humans never notice. Crawlers that snapshot a page before running scripts see the empty shell — a headline-free, text-free document that says nothing about your business.
My site is built that way too, so I ship a static block of real content inside the initial HTML: the company description, the service list, the contact address. Crawlers that read before executing scripts get the substance; visitors never see it, because the page replaces it immediately. You can check your own site in one line from a terminal, fetching the raw HTML and looking at what comes back before any script runs. If the answer is an empty div, that is what a machine knows about you.
What I would not do
I wouldn't buy an AEO retainer that produces volume. Answer engines quote you, and that cuts both ways: a fabricated statistic or an invented client story doesn't just sit on your site, it gets repeated in a reply with your name attached. The honesty discipline I apply to my own posts — every claim traceable to real work — is not a moral flourish here. It's the risk control.
I also wouldn't block the AI crawlers reflexively. Mine are allowed, deliberately, because being quotable is the point of publishing. That's a business decision rather than a technical one, and the opposite choice is defensible if your content is the product. Just make it on purpose.
How to tell whether any of it is working
Set the vanity metrics aside and check three things. Fetch your own homepage the way a crawler does and read what comes back. Confirm your pages are actually in Bing's index, not just Google's, since that index feeds assistant answers. Then ask the assistants themselves about your company, by name and by the service you want to be found for, and read what they say about you — including what they get wrong. The wrong answers are the useful ones: they tell you exactly which fact your site failed to state plainly.
None of this is a new discipline. It's the old one, with the assumption of a human reader removed. Write things that are true, put them where a machine can read them without running your code, and make it easy to tell engines when something changed. The businesses that get cited are the ones that made themselves answerable.
Frequently asked questions
Is answer engine optimization different from SEO?
It's the same work with a stricter reader. Search engines forgive a vague page because a human clicks through and figures it out. An answer engine has to restate your position in one paragraph, so an unclear page simply isn't used. Everything that already made you rank still applies.
Do I need an llms.txt file?
You don't, in the sense that no engine requires one. Publish it anyway if writing one takes you an hour, because the exercise of stating your business in plain sentences is the actual value, and the file is trivial to maintain. Don't pay anyone a retainer for it.
My site was built on a modern framework. Am I invisible?
Not necessarily, but you should verify rather than assume. Fetch the raw HTML of your own page and see whether your services and location appear in it. If they don't, the fix is to render that content on the server or include a static block in the initial HTML — a contained change, not a rebuild.