AI-ready content is content stored as structured, retrievable data rather than as formatted body text. What makes it AI-ready lives in the content model: discrete fields, a controlled taxonomy, schema generated from those fields, server-rendered text, and clean canonical URLs. Rewriting page copy does not change any of those things.
Answer engine optimization, or AEO, is the practice of making content retrievable and citable by AI answer engines such as ChatGPT, Perplexity, Google AI Overviews, and Gemini. Most AEO checklists circulating right now say roughly the same thing.
Put the answer in the first hundred words. Phrase your headings as questions. Keep passages self-contained. Define your entities before you narrate.
I have published those recommendations myself. They are reasonable. They are also, on their own, a writing exercise.
The distinction matters because the two things cost very different amounts and decay at very different rates. Rewriting two hundred pages is a project. Changing what a page is made of is an architecture decision, and it holds after the person who ran the retrofit has moved on.
What Does “AI-Ready Content” Actually Mean?
Functionally, it means a retrieval system can find, parse, and attribute the content accurately without guessing.
Three properties do most of the work: the content is reachable by a crawler, it exists as text rather than as a rendering artifact, and its meaning is carried by explicit structure rather than by visual layout.
That definition is deliberately unglamorous. It contains no writing advice at all.
The reason is that answer engines do not read a page the way an editor does. They retrieve candidates, rank them, place some of them in a context window, and generate from what is there. Prose quality influences the last stage. Structure and access influence whether you reach it.
Why Doesn’t Rewriting Your Pages Make Them AI-Ready?
Rewriting pages for AI has weaker evidence behind it than the checklists imply, and in some measured settings it makes retrieval worse.
On 15 May 2026, Google published official guidance on optimizing for generative AI search with a myth-busting section that is unusually direct. Per that guidance, there is no requirement to break content into small pieces, no need to write in a particular way for AI systems, and no special schema.org markup required.
The academic picture is less blunt but points the same way. A July 2026 critical survey of 45 generative engine optimization studies found that topical relevance and position in the retrieved context are the most reproducible levers, while formatting changes on their own have weak effects.
A competitive benchmark in that corpus found only three of 54 method and domain combinations produced a significant positive effect, and none in question answering.
The most consequential finding comes from an end-to-end test that reinstated the retrieval and reranking stages rather than measuring generation in isolation. Across 171,003 documents and 2,700 queries, optimizing the body text alone reduced average presence in the top 20 by roughly 9 percent, presence in the top 10 after reranking by 16 percent, and final citation by 6 percent. A rewrite can help once a document is already in the context window and still cost you the chance to get there.
What Does the Evidence Actually Support?
The evidence supports relevance, access, verifiable specifics, and measuring each engine separately.
It also supports humility about scope. Google speaks only for Google. Citation audits found that 53 percent of domains cited by Google AI Overviews did not appear in the organic top ten, and 27 percent were absent from the top hundred. Cross-engine source overlap is low enough that treating ChatGPT, Perplexity, and AI Mode as one surface produces the wrong roadmap.
There is a practical consequence most teams miss. OpenAI states that ChatGPT search uses third-party search providers, Bing among them, so being indexed is not only a Google question. Indexability is the shared floor under all of these systems, and it sits below anything you could change by editing copy.
Self-contained passages earn partial credit rather than dismissal. They are not a Google requirement. They are still useful for retrieval systems that embed and rank at passage level, and for readers who arrive mid-page from an AI answer.
Keep the practice. It is hygiene, not strategy.
Does an llms.txt File Help?
Not for Google Search. An llms.txt file is a plain-text manifest placed at a site's root to describe its content for AI systems.
Google's generative AI search guidance, published 15 May 2026 and since revised, states that site owners do not need to create llms.txt files or other special machine-readable markup to appear in its generative AI features, that maintaining one for other services will neither harm nor help Google visibility because Google Search ignores these files, and that discovering a file type does not mean treating it specially.
Note the scope: that statement covers Google Search, not every AI surface, which is the revision Google itself made to the original wording. Some other services and agent systems do read these files, so maintaining one is a low-cost bet on future tooling rather than a current visibility tactic. It is not a substitute for being crawlable and indexable, which is the floor under every engine.
Rewrite or Remodel? A Direct Comparison
Rewrite under roughly a hundred pages and one or two content types. Remodel above that, and wherever many editors publish through many content types.
Rewriting and remodeling are usually discussed as if they were the same kind of work at different scales. They are not: they differ on who enforces them, how fast they decay, and what the evidence says about each.
Rewriting page copy compared with changing the content model
Rewriting pages
Changing the content model
What it changes
How existing text reads
What every future page is made of
Who enforces it
The person who ran the retrofit
The CMS, on every save
When it decays
The day the next page is published outside the retrofit
When the model itself is changed
Cost profile
Recurring; scales with page count
One-time; scales with content types
Evidence for AI visibility
Weak. Body-only rewrites measurably reduced retrieval in end-to-end testing
Untested as a citation lever. Establishes the access and structure layer beneath it
When it is the right call
Under roughly a hundred pages, one or two content types
Multisite estates, many editors, many content types
The evidence comparison above is deliberately asymmetric. The literature does not show that remodeling content wins citations. It shows that rewriting body text alone can cost retrieval. Those are different claims, and only the second one is measured.
Where Does the CMS Actually Change the Outcome?
The CMS changes the outcome at the point where content stops being a document and starts being data.
Seven AI-Readiness Properties That Live in the Platform, Not in the Copy
Four of these are settled in the content model itself:
Fields instead of body blobs. When a course, a service, or a grant lives in discrete fields, its facts are addressable. When it lives in one rich-text field, they are a paragraph.
Taxonomy as an entity vocabulary. Controlled vocabularies give a machine a stable name for a thing across thousands of pages. Free-text tags give it noise.
Server-rendered text. Content that only exists after JavaScript executes is content some retrievers will not see.
Canonical and locale discipline. Duplicate locale paths split authority and fragment attribution. Multilingual estates feel this first, and Arabic and English variants of the same page are where we see it most often.
The other three are configuration decisions, and each is where teams most often get caught.
Does Structured Data Still Matter if Google Says It Isn't Required?
Yes, for economic reasons rather than semantic ones. Google's guidance is that structured data is not required for AI features, and that where you do use it, it should match the visible text. Generating it from the same fields that render the page is how that stays true at scale rather than drifting after the third editor.
The reason to keep investing is cost, not compliance. Structured data is far cheaper for a retrieval system to consume than unstructured prose, a point Jarno van Driel makes well: it is cheaper for any party to consume structured data than to derive structure from text. Nobody has to formally require it for that incentive to hold.
Can a Snippet Directive Remove a Page From AI Answers?
Yes, and usually nobody notices. A nosnippet directive does not just suppress a search snippet. Google's robots meta documentation states it also prevents the content from being used as a direct input for AI Overviews and AI Mode. In Drupal, that is a Metatag default applied at the bundle level, which means one configuration decision can quietly disqualify an entire content type.
Who Controls Whether AI Crawlers Reach Your Site?
In Drupal, most of this is a modeling decision rather than a module hunt. Schema.org Blueprints exists specifically to build content types around Schema.org types from the start, and Schema.org Metatag outputs JSON-LD from field values.
Varbase, our enterprise Drupal distribution, ships with opinionated content types and metatag configuration already wired, which moves part of the access and structure layer described above from a build decision to a default the editor inherits.
Your edge configuration does, and it decides what any retriever sees before your content model gets a vote.
From 15 September 2026, Cloudflare applies new defaults that block crawlers classified as Training or Agent on pages displaying ads, while Search crawlers stay allowed. Multi-purpose crawlers that combine search and training are caught by the Training default.
The change applies to new customers, new sites added by existing customers, and existing free-tier accounts. Paid customers keep their current configuration, and any site owner can opt out before that date.
Most university, nonprofit, and intergovernmental estates carry no ads and will see nothing change. The point is not that this default will catch you. It is that most teams have never checked who owns that setting.
Our View: The Durable Unit Is the Field, Not the Paragraph
AI readiness decays for the same reason accessibility does, and it decays for a reason that has nothing to do with writing quality: nothing in the CMS enforces it.
A retrofit is a snapshot of one person’s judgment applied to the pages that existed the week they did it. Six months later, a department has published forty pages through a WYSIWYG field, and none of them carry the structure the retrofit added. The audit score was real. It was also perishable.
In the multisite estates Vardot inherits, and university installs in particular, the failure is never that editors write badly.
It is that the content type gave them one field and no constraints, so the only structure available was the structure they typed. Where dozens of departments publish independently through the same permissive content type, the variance across those pages is not an editorial problem. It is a modeling problem wearing an editorial costume.
That reframes what the work is. If the answer is a rewrite, you buy it once and buy it again. If the answer is a content model, the structure is produced by the act of publishing, and the editor does not have to know what a self-contained passage is.
I would add one uncomfortable corollary. Google’s own guidance says non-commodity content influences visibility more than anything else in its guide. No content model rescues a page that restates what fifty other pages already say.
When Should You Not Do This?
Several organizations reading this should not start a content modeling project.
Don’t do it if your pages aren’t being retrieved at all. If your CDN blocks AI crawlers, your key content renders client-side, or your pages are not indexed, remodeling content changes nothing measurable. Fix access first. That is usually a week of infrastructure work, not a project.
Don’t do it if you publish under a hundred pages through one or two content types. The overhead exceeds the return. Write better pages and check your crawler settings.
Don’t do it mid-migration. If you are moving off Drupal 10 ahead of its end of life on 9 December 2026, the content model gets revisited during the migration anyway. Running a parallel remodeling project duplicates the cost and creates two sources of truth.
Don’t do it to hit a citation number. The literature does not establish a stable, cross-platform link between structural optimization and downstream traffic or conversions. Any promise of one runs ahead of the published evidence.
The recommendation depends on where your bottleneck actually sits, and for a meaningful share of the sites we look at, it is not the content model.
How Do You Tell Whether Your Content Model Is the Problem?
Answer these six as facts about your own site, not as aspirations. This is the same diagnostic we run in the Align stage of the Vardot Delivery System, before any blueprint work begins.
Six-Point Content Model Readiness Check
Your key facts live in dedicated fields. Dates, locations, eligibility, fees, and contacts each have their own field rather than sitting inside a body paragraph.
Your taxonomy is controlled and used consistently. Editors select terms from a governed vocabulary rather than typing free text.
Your structured data is generated from those fields. Nobody maintains JSON-LD by hand, and nobody can let it drift from the visible text.
Your important text renders server-side. Disable JavaScript and the substance of the page is still there.
You have one canonical URL per piece of content per language. No duplicate locale paths competing for the same content.
You know which content types carry a nosnippet default. Somebody has checked recently, rather than assuming.
If you answered yes to five or six, your content model is not your constraint. Your gap is the material itself: original data, first-hand accounts, expertise that is not already on the web. Restructuring will not produce those.
If you answered yes to three or four, you have a targeted fix rather than a rebuild. Usually it is schema generation, snippet directives, and canonical hygiene, and it is weeks of work.
If you answered yes to two or fewer, editors are being asked to produce structure by typing it. That is the case where a rewrite is the expensive option and the content model is the cheap one, which is the opposite of how it is usually budgeted.
Why Do AI Citations Change From Day to Day?
Because instability is a property of these systems, not a fault in your site.
Published audits report page overlap of 18 percent across two months for AI Overviews against 45 percent for organic Google, and 9 to 28 percent of decisions changing between repeated runs even at temperature zero. The prompt set Vardot monitors behaves the same way.
Track each engine separately, run a fixed prompt set on a cadence, and read the trend. A single check tells you almost nothing, and treating one strong day as proof an optimization worked is the most common measurement error we see.
If you want to know which of the six you would actually pass, that is what an AI readiness review is for. We look at the content model, the rendering path, and crawler access before we look at a single page of copy, and the output is a diagnosis rather than a rewrite queue. If the answer is that your model is fine, we will tell you that.
Nauras Abul-Haija is the Content and SEO Manager at Vardot, where she built and leads the agency's content and SEO function: editorial strategy, search, and content operations aimed at the nonprofit, higher education, media, and healthcare organizations Vardot works with. She is multilingual, which shapes how she approaches search across languages and content built to travel between markets. Her writing covers search performance and AI-era discovery most often, alongside content operations, digital strategy, and the occasional detour outside her lane.
AI-ready content is content a retrieval system can reach, parse, and attribute without guessing. It requires three properties: the page is crawlable, its substance exists as text rather than as a JavaScript rendering artifact, and its meaning is carried by explicit structure such as fields and taxonomy rather than by visual layout. It is a data property, not a writing style.
Instability is a property of these systems, not a fault in your site. The practical consequence is that a single check tells you almost nothing. Track each engine separately, run the same prompt set on a fixed cadence, and read the trend rather than any one result. Treating one strong day as evidence that an optimization worked is the most common measurement error we see.
Not for Google Search, which ignores llms.txt files entirely per Google's own documentation. Creating one neither helps nor harms Google visibility. Some other services and agent systems do read these files, so maintaining one is a low-cost bet on future tooling rather than a current visibility tactic.
