AEO schema and llms.txt: what your website actually needs

You do not need to buy a special schema package or an llms.txt file to meet Google’s requirements for AI search visibility. You do need accurate public content, appropriate access controls and a website that works. Optional technical additions should solve a named problem rather than stand in for that work.

Google’s current AI optimisation guide says no special schema or AI file is required. It also says Google ignores llms.txt for Search visibility and ranking. That is a statement about Google Search, not a universal claim about every AI application.

What each component is for

Use structured data to describe reality

Start by deciding which real thing the page describes: an organisation, person, article, service or breadcrumb trail. Choose a suitable vocabulary and any applicable platform-supported implementation. A valid vocabulary type is not necessarily a Google rich-result feature.

The content must agree with what a visitor can verify. Google’s structured-data policies require accurate, relevant markup and do not guarantee enhanced presentation when a test passes. Do not invent reviews, ratings, qualifications, locations or prices to make the markup look more impressive.

For example, a consultancy page might visibly explain its trading name, services and contact details. Its structured data should describe those same facts. If the website does not show a fixed price because projects vary, adding an unsupported low offer price is not an optimisation.

Ask the developer to check both syntax and meaning. A syntactically valid statement can still be wrong. Compare the rendered page with the markup, inspect representative templates and check that old business details are not repeated in a site-wide component.

Keep useful FAQs, drop the rich-result promise

Answering real buyer questions is still useful. A good FAQ can clarify exclusions, preparation, payment stages or whether a service is suitable. Place the answer where it helps someone decide, rather than adding a long block of unrelated questions to every page.

Do not sell FAQ markup on an outdated Google benefit. Google’s documentation changelog records that FAQ rich results stopped appearing on 7 May 2026 and that the documentation was subsequently removed. A visible answer can remain valuable without a special result format.

For a service page, three questions drawn from genuine enquiries may be more useful than thirty generic definitions. Keep their answers consistent with the service description. If scope or pricing changes, update both places together.

Check bots by purpose, not by the word AI

A blanket “allow all AI” instruction is too crude for a technical brief. According to OpenAI’s crawler documentation, OAI-SearchBot concerns search discovery while GPTBot concerns potential model training. Their settings can be managed independently.

Write down which outcome you want before changing a rule: public search discovery, training preference or protection of a private area. Check the relevant provider’s current documentation and preserve deliberate restrictions. A crawler visit proves only a request; it is not evidence that the page became an answer source.

A practical first review

1. Pick three important pages. Use the main service page, a supporting explanation and a contact or booking page. Confirm the content is visible and the journey works.
2. List the essential facts. Include business identity, service coverage, scope, price information and contact route. Mark contradictions before adding any new code.
3. Inspect current markup. Identify duplicate entities, obsolete details and claims absent from the visible page. Fix those before introducing another plugin.
4. Review access choices. Check robots rules and other inclusion settings against the owner’s intention. Record any proposed change and the reason.
5. Validate the final pages. Recheck content, markup and links after publication. Save the findings with dates, rather than issuing an unexplained “AI-ready” score.

This is a starting review, not a promise that every issue fits into half an hour. Complex sites may need template or infrastructure work. A supplier should explain that dependency and quote it separately.

Buy a clear outcome

Ask what the proposed technical change fixes and how that fix will be verified. “Install llms.txt” is a task, not a commercial result. Use our Google eligibility checklist, ChatGPT search checklist and wider audit guide to assess the proposal. Our answer engine optimisation service starts with the problems and priorities before implementation.

Official guidance checked on 27 October 2026.