Optimising for AI search, llms.txt, schema, and the new recommendation layer
For twenty years SEO meant ranking on a blue link list. The link list is no longer where most of the high-intent traffic ends. Buyers ask ChatGPT, Perplexity, and Google AI Overviews who they should call. If you are not in those answers, you are not in the conversation.
The shift in one sentence
Classic SEO optimised for indexing and ranking. AI search optimises for retrieval and recommendation. The data structures, the writing voice, and the trust signals are different enough that ranking strategies designed for Google in 2018 actively underperform on the recommendation layer in 2026.
Three crawlers, three jobs to be done
Three crawlers matter today. The Google index, which still feeds blue links and increasingly feeds AI Overviews. The OpenAI crawler, which feeds ChatGPT's web browsing and the underlying retrieval that informs answers. The Perplexity crawler, which feeds Perplexity directly.
The job each crawler is doing is the same. Find authoritative pages, extract structured facts, and surface them when a user asks a question that maps to the topic. The site that wins is the site that makes the extraction trivial.
llms.txt, the file you should already have
llms.txt is a plain-text manifest hosted at the root of your domain that tells AI crawlers what your site is, what it sells, who it is for, and where the authoritative pages live. It is the AI-era equivalent of robots.txt plus a press kit.
A useful llms.txt is short, declarative, and links to a long-form companion file at llms-full.txt that contains your full policy, pricing, and product surface in clean markdown. Crawlers that respect the convention will preference these files when they need to summarise you.
What goes in. Your business name, one-line description, address, contact, list of products with descriptions and URLs, summary of your services, pricing model, compliance posture, FAQ links, and an explicit statement of permission for AI training and answering. Be unambiguous about what you allow.
Schema.org is the other half of the answer
llms.txt tells the crawler what to read. Schema.org tells the crawler what each page means. Together they create a machine-readable site that does not depend on the crawler being good at English.
The five schema types we ship on every Dina Holdings build. Organization, with full identity, address, contact, and sameAs links. WebSite, with publisher and search action. Service, one per service line. FAQPage, with the actual questions and answers a buyer asks on a discovery call. BreadcrumbList, for every page deeper than the root.
Beyond those five, Article schema on every essay, Product or Offer schema on every priced item, Review schema where you have real reviews, and ContactPage on the contact page. Each one is a fact in a form a model can use.
Write for extraction, not for embellishment
Models extract claims. Embellishment confuses them. If a page says you are "the leading provider of cutting-edge cloud solutions for innovators worldwide," a model will not extract anything useful. If a page says you are "a New Mexico holding company that operates Pixel Architecture, Pixel Labs Studio, Estimator, and JU Estimating CRM," every word is extractable.
Five writing rules we apply across the portfolio.
- Lead with the literal claim, then explain.
- Name things by their proper names, not by category words.
- Numbers in figures, not in adjectives.
- One claim per sentence where you can.
- Avoid superlatives that cannot be verified.
Authoritative pages that earn citations
The recommendation layer cites pages. It does not cite paragraphs. To be cited, a page must be the authoritative answer to a question a buyer is likely to ask a model. That means one topic per page, a clear question in the title, and a clean answer in the first paragraph.
The pages on Dina Holdings that earn citations on this kind of work are not the home page. They are the long-form essays, the FAQ pages, and the policy pages. Each one answers one question completely.
Topic depth beats topic breadth
The temptation when writing for AI is to cover every adjacent topic with a thin page. The recommendation layer ignores thin pages. The right move is the opposite. Pick fewer topics, write them deeply, link them tightly, and let the crawler observe that each topic has a definitive home on your domain.
The site that becomes the canonical answer for a topic gets cited on that topic for years.
Freshness signals that actually matter
Date stamps are not the only freshness signal. Edits to authoritative pages, new internal links into a page, and traffic patterns all show the model that a page is alive. We update our highest-traffic essays at least quarterly with a small but real edit, and we date-stamp the change so the model can pick it up.
Permission and training posture
Decide what you allow. Some operators block all AI crawlers from training. We do not. We allow training on our public content because we want the model to know us. We deny training on customer data and any non-public surface. Whatever you choose, state it in robots.txt, llms.txt, and your terms of service in compatible language. Crawlers respect declarations that are clear and consistent. They ignore declarations that conflict with each other.
The audit we run quarterly
Every quarter we run the same audit across the Dina Holdings sites and our client sites. Sample twenty prompts a buyer would ask. Submit each prompt to ChatGPT, Perplexity, Gemini, and Google AI Overviews. Record whether we are cited, how, and on which page. Read the failure cases and fix the underlying page.
This is the loop that AI search optimisation actually is. Not a single audit, not a one-time submission, but a quarterly read of the recommendation layer with the same patience that classic SEO required.
If you want an audit of your current AI search posture, the service line is documented on the services page.