Why Drupal sites get read and cited by AI

AI systems already crawl articles, open product pages during live conversations and follow links while preparing answers. Sometimes they cite the source. Often they read hundreds of pages and send almost no traffic back.

Cloudflare estimates that automated bots now generate roughly 57% of all web requests. Machine traffic has overtaken human traffic. AI crawlers and agents are part of that change, although not every bot is connected to AI.

A March 2026 analysis of one month of Cloudflare logs found that AI crawlers fetched 1,241 pages for every citation sent by an AI answer engine. The same logs showed GPTBot, OAI-SearchBot, ClaudeBot and other crawlers requesting both regular HTML pages and alternative Markdown versions.

The practical question is whether an AI system can understand what it finds. Can it identify the product name, price, unit and availability? Does the structured data agree with the visible page? Will it find the current value, or a copy that has not been updated since last year?

Drupal sites cited by AI depend on one stored value appearing on the page, in JSON-LD, in a Markdown version, in a product feed and through an API. Editors update it once. Every generated version can change with it. Read also: getting your company recommended by AI: supplier shortlist facts - why published specs matter once fetchers can read the page.

JSON:API is part of Drupal core. Contributed modules add Markdown, llms.txt, feeds, authentication and MCP tools. Some have worked for years; others are new.

In this article:

• Do AI crawlers already visit your website?
• What does AI need before it can quote your page?
• How do Drupal fields make facts easier for AI to understand?
• How does Drupal publish the same content in formats AI can read?
• How is Drupal content available beyond individual pages?
• What does Drupal still need beyond good modules?
• Is Drupal ready for the web shaped by LLMs?
• Common questions

Do AI crawlers already visit your website?

Cloudflare's crawler report shows that 52% of crawler requests were related to AI training by June 2026, up from 22% in spring 2025. AI is not the only source of automated traffic, but it now represents a large part of crawling activity.

These requests serve different purposes. GPTBot gathers training content, OAI-SearchBot supports search, and ChatGPT-User can open a page during a live conversation. A robots.txt rule for one does not necessarily control the others.

You can see this in your server logs:

203.0.113.50 - - [13/Dec/2025:10:15:30 +0000] "GET /products/pump-a HTTP/1.1" 200 1234 "-" "GPTBot/1.0"

The entry identifies the URL, bot and response status. Analytics tools often miss crawler traffic because bots do not run browser scripts, so use server, CDN or WAF logs.

Getting fetched is still a long way from being cited. The ratio above makes that clear. The page still needs a useful, direct and current answer.

What does AI need before it can quote your page?

An AI system needs six things from a company website. Drupal has a practical answer to each one.

1. Fetchable pages: robots.txt, a WAF challenge, a login wall or client-rendered JavaScript can stop a crawler. Drupal renders complete HTML on the server by default, so the main content does not depend on JavaScript. See Can an AI actually read your website? for the checks outside the CMS.
2. Explicit facts: a model can use “Delivery takes 10 business days” more reliably than “We deliver quickly.” Drupal stores values such as dimensions, standards, minimum order sizes and service limits in named fields.
3. One meaning everywhere: if the page says EUR 120, the JSON-LD says EUR 99 and the PDF says “contact us,” the system has to choose. Drupal can generate the page, structured data, feed and API response from the same field.
4. Current information: a visible update date helps, but the publishing process matters more. Drupal's entity updates and cache metadata can refresh every output that depends on a changed price or specification.
5. Content separated from layout: models can parse HTML, but menus, banners and repeated elements consume context. Drupal keeps the content model separate from the theme and can publish the same entity in cleaner formats when needed.
6. A way to search larger collections: opening 5,000 product pages one by one is wasteful. Drupal provides Views, feeds and JSON:API, while MCP modules can expose bounded tools for agents.

The same Drupal feature sits underneath most of these answers: fields.

How do Drupal fields make facts easier for AI to understand?

Suppose a manufacturer sells a pump with a 12 V power supply, a maximum flow rate of 4,500 litres per hour, an IP68 rating and a two-year warranty.

Those values can be written into the body field as one paragraph. This is quick. It also makes each value hard to reuse. A developer has to parse the prose or copy the data into a product table, schema markup and external feed. The copies begin to drift as soon as someone edits one of them.

In Drupal, each value can have its own field:

The product page displays those fields. JSON-LD labels them, a View builds a comparison table, JSON:API returns them to an application, and an MCP tool searches them using parameters.

One value, several uses.

When an editor changes the availability, Drupal can invalidate the relevant cache entries and regenerate each output from the new value. The team does not have to remember that the same sentence was copied into three templates and two files.

Any CMS with a strict content model can deliver some of these benefits. Drupal's advantage is that permissions, cache metadata, Views and JSON:API already understand the same entities and fields. The same pattern sits at the centre of structured content operations at scale.

How does Drupal publish the same content in formats AI can read?

The web is testing several ways to make content easier for LLMs to read: cleaner HTML, JSON-LD, Markdown versions, llms.txt and new discovery files. Some are established standards. Others are experiments with mixed evidence behind them.

Drupal's advantage is practical. It can support all of them from the same content model, without asking editors to maintain separate copies. For each format, the useful questions are the same: what does it solve, how much evidence supports it, and what can Drupal provide today?

Why does the normal HTML page matter most?

AI crawlers already understand HTML. Google explicitly says that separate AI files are not required for its generative Search features. A well-built Drupal page is therefore the first priority, not a fallback after JSON-LD, Markdown or llms.txt. 10 SEO features a modern CMS should have covers the crawlability baseline Drupal already supports.

The main facts should exist in the initial HTML response. Headings should describe their sections. Tables should be real HTML tables, not screenshots. Videos should have transcripts. Important information should not live only in a PDF.

Stable URLs matter too. Pathauto creates predictable aliases, while Redirect preserves old links. Last-Modified and ETag let a server return 304 Not Modified, and JSON-LD should take dateModified from the entity's real change date.

Drupal's position: this requirement is already covered by the platform's normal architecture. Drupal renders complete HTML on the server, stores content in fields, creates stable aliases and has mature tools for redirects, sitemaps and cache metadata. A correctly configured Drupal site starts from the format every crawler already understands.

Why does generated JSON-LD stay consistent with the page?

JSON-LD describes a page using schema.org types and properties. A product can have a name, brand, identifier and offer. An article can identify its author and modification date. An organization can list its official profiles.

On an existing Drupal site, Metatag and Schema.org Metatag provide the common implementation. For field-level mapping and CI validation, see JSON-LD in Drupal: Schema.org Metatag from content fields.

Metatag defines defaults per content type. Tokens pull values from the entity. Schema.org Metatag prints a JSON-LD script in the page head. A product mapping might use:

• the node title for name,
• dedicated specification fields for additionalProperty,
• the price field for price,
• the currency field for priceCurrency,
• the entity change date for dateModified.

Editors do not paste JSON into a text editor. They update the product.

This distinction matters. Handwritten JSON-LD can disagree with the page after the next content change. Generated JSON-LD reads the same fields as the visible template, so both outputs move together.

Schema.org Blueprints can instead build a new Drupal content model from schema.org definitions. It suits a new catalogue; do not combine both mapping systems on one content type without a clear reason.

JSON-LD helps a system identify what a value means. It does not guarantee a citation or ranking, but it is an established way to describe products, articles, organizations and other entities.

Drupal's position: support is mature. Metatag and Schema.org Metatag generate JSON-LD from the same fields that build the visible page. Editors change the fact once, and Drupal updates both versions. New projects can go further with Schema.org Blueprints and build the content model around schema.org types from the start.

What do Markdown versions add, and what do they not?

Markdown removes much of the code and repeated layout around an article. Headings, paragraphs, links, lists and tables remain. Navigation, banners and decorative wrappers can disappear.

In the same March 2026 analysis, the site owner added Markdown to every page and then reviewed a month of crawler traffic. Dedicated .md URLs received real requests. Around 35% of GPTBot requests and 23% of OAI-SearchBot requests went to Markdown files. Amazonbot and ClaudeBot used them less often. ChatGPT-User and PerplexityBot barely touched them.

The evidence is mixed. None of the ten measured bots requested Markdown through content negotiation. Bots also downloaded both HTML and Markdown, increasing crawler traffic by about 7%. The test did not establish that Markdown led to more citations, and Google says it does not need separate Markdown files for Search.

This means Markdown is a reasonable experiment, not a replacement for good HTML. If a site publishes it, a dedicated .md URL with a discovery link is more useful than relying on an Accept: text/markdown header.

Drupal's position: Drupal already supports the experiment properly. Markdownify generates Markdown from the normal Drupal page and can publish dedicated .md URLs, a /markdownify/ path or a ?_format=markdown response. Version 1.2 supports Drupal 9, 10 and 11. The content stays in Drupal, and the Markdown version changes with it. A team can test the format without creating a second publishing workflow.

Where does llms.txt help and where does it not?

The proposed llms.txt format gives an AI system a short Markdown guide to a website. It can describe the organization and point to preferred documentation, service pages or reference material. It is a new convention, and the industry has not agreed on how much it matters.

The site recorded 52 requests for /llms.txt during the month-long test. Every request came from an SEO audit tool. No AI crawler or answer engine requested it. Across Acquia's hosting platform, roughly 5,000 out of 400 million requests went to llms.txt. That is 0.001%, again mostly audit tools.

Google's guidance for AI features in Search says website owners do not need new AI text files, special markup or Markdown to appear in generative results. Google may crawl many formats, but gives them no special treatment. Maintaining llms.txt “won't harm (nor help)” visibility because Search ignores it.

There is still a real use case. Coding agents can use llms.txt as an entry point to API documentation. If developers load your docs into Cursor, Claude Code or another coding assistant, the file can save them time. For a marketing site, it remains a low-cost bet rather than a proven route to citations.

Drupal's position: if you want llms.txt, Drupal is ready. The llms.txt module publishes it at /llms.txt, supports reusable sections, tokens, environment-specific content and cache invalidation, and provides an administration screen. Drupal treats the file as managed content instead of a forgotten text file on the server. The standard may or may not become widely used, but a Drupal site can support it cleanly today.

What are new AI discovery modules trying to solve?

Some tools are already looking beyond llms.txt. They need to discover APIs, authentication methods, MCP servers and actions a website allows an agent to perform.

The Drupal AI Agent Readiness module explores this direction. It generates /llms.txt and /llms-full.txt from Drupal entities and can publish an API catalogue, agent-skills index, MCP server card, OAuth metadata and /auth.md. It respects Drupal access rules and supports headless installations.

This package was only weeks old when this article was prepared and was not covered by Drupal's security advisory policy, so it still needs a production review. Yet its existence shows how quickly the Drupal ecosystem is responding to new AI discovery conventions.

Drupal's position: the conventions are still emerging, but Drupal already has an implementation that connects them to real entities, permissions and access rules. A team can follow the standards as they mature without moving its content into another system.

How is Drupal content available beyond individual pages?

Pages work for reading. APIs, feeds and MCP tools help software search or compare a larger set without opening thousands of URLs one by one.

This is different from ordinary AI citations. ChatGPT, Google and other answer engines can crawl public HTML without a direct integration. They do not automatically discover and use every JSON:API endpoint or MCP server they encounter. A feed, API or MCP tool becomes useful when a specific application, partner or agent is connected to it. These features prepare Drupal for direct machine use; they are not ranking signals.

Why does core JSON:API give Drupal a head start?

JSON:API is part of Drupal core. Once enabled, it exposes Drupal entities and fields through predictable endpoints under /jsonapi. See headless CMS: REST API and JSON:API in Drupal for exposure patterns and access control.

It uses Drupal's existing access checks and ships in read-only mode. An anonymous request can read only what the anonymous role may view. It cannot create or change content unless the site deliberately enables write operations and grants permission.

The default API is broad. JSON:API Extras can disable resources, remove fields, rename types and replace internal paths with clearer ones. A team can therefore test a content API without building it from scratch. The first job is deciding what to expose.

Drupal's position: structured content APIs are not a future add-on. JSON:API is already in core, read-only by default and governed by Drupal's existing permissions. JSON:API Extras provides the control needed for a smaller, clearer public interface.

How do Drupal feeds stay consistent with the website?

Some consumers need a file. Drupal Views selects entities, fields and filters, while Views Data Export produces larger CSV, JSON and XML exports in batches. The View reads the same fields as the product page, so editors do not maintain two sources.

Large batched exports should sort by a unique value such as the node ID. Without stable sorting, records can move between batches and appear twice or disappear.

Drupal's position: Views already gives site owners a visual query builder, and Views Data Export turns the same query into CSV, JSON or XML. The page and the feed continue to read the same fields.

How does Drupal control who can access the data?

Public product data may use Drupal's anonymous permissions. Partner prices or private documentation need authentication.

Key auth attaches an API key to a Drupal user. The user's roles still decide what is available. For OAuth, Consumers and Simple OAuth provide registered clients, bearer tokens and scopes.

This structure supports a common commercial rule: anonymous users see a price range, while an authorized partner can request the exact contracted price.

Drupal's position: machine access uses the same users, roles and permissions as the website. Public data, API keys and OAuth clients can all sit inside one access model instead of becoming separate security systems.

How does Drupal keep API responses and feeds current?

Drupal attaches cache tags to rendered pages and API responses. These tags identify the entities and configuration used to build the response.

When an editor changes a product price, Drupal knows which cached output depends on that product. Purge can send that invalidation to a CDN or reverse proxy. The affected object is removed. The rest of the cache stays warm.

This avoids clearing the whole cache after every edit. When another system needs an immediate signal, a webhook can tell it to fetch only the changed record.

We used this pattern for ProjektMagazin's AI document chatbot. The retrieval system connects to Drupal through JSON APIs and indexes multiple content types with their taxonomy, author and custom metadata. Webhooks update changed content, with a scheduled synchronization as a fallback. Newly published information becomes available to the chatbot within seconds.

Drupal remains where editors manage content. The AI application receives current, structured data without crawling the visual website again.

Drupal's position: cache tags and entity events tell Drupal exactly what changed. Pages, APIs, feeds, CDNs and external AI indexes can update from the same editorial action.

How does MCP Server expose Drupal to AI agents?

An API exposes endpoints. An MCP server describes tools an AI assistant can understand and choose.

The Drupal MCP Server module is built on the official PHP MCP SDK. It supports MCP tools, resources, saved prompts, sampling and authentication. Version 2.0 works with Drupal 10 and 11.

The module uses Drupal's Tool API. A plugin defines an operation with typed inputs and outputs. An administrator exposes it at /admin/config/services/mcp-server/tools, names it and chooses whether it requires authentication.

Useful tools could include:

• search_products, with a category and specification filters,
• get_product_details, with a stable product identifier,
• find_document, with a query and document type,
• request_quote, with required fields and validation.

The description tells an agent when to call a tool, which parameters it accepts and what it returns. Local assistants can connect through STDIO with vendor/bin/drush mcp:server; remote clients use HTTP at /_mcp.

Simple OAuth 2.1 can protect individual tools with bearer tokens and scopes. A public documentation search may allow anonymous read access. A quote request or content-changing operation should require authentication and Drupal permissions.

The 2.0 release was beta when checked, already supported the full MCP protocol and was recommended for new Drupal implementations. The earlier mcp project is being merged into it. Start with one useful tool, then expose more operations through the same architecture.

Drupal's position: Drupal has a working MCP server today. It supports the full protocol and connects tools to Drupal permissions, authentication and typed operations. The integration is new, but the platform does not have to wait for MCP support.

What is WebMCP and how is it different from MCP Server?

WebMCP helps an AI agent operate a website in a browser. Without it, the agent has to inspect the page, find a button or form field, guess what each control does, enter values and interpret any errors. A small change to the layout can break that sequence.

WebMCP lets the page describe an action as a tool with a name, purpose and defined inputs. For example, a Drupal quote page could expose request_quote with fields for product ID, quantity, country and email address. The browser agent sees that definition, collects the missing information from the user and calls the tool. It no longer has to work out which visible input contains the product code or which button submits the form.

There are two ways to define a tool. The declarative API adds information to a normal HTML form, so the same form continues to work for a person. The imperative API uses JavaScript and navigator.modelContext.registerTool() for actions that need more logic, such as filtering a catalogue, checking a booking slot or preparing a configured product. The action still runs on the website and can update the page in front of the user.

This is different from Drupal's MCP Server. MCP Server exposes Drupal tools from the backend through STDIO or an HTTP endpoint. A connected assistant can use them without opening the website in a browser. WebMCP tools exist inside a page and become available after a compatible browser visits it. They can use the current page state and keep the user in the visible interaction.

For Drupal, a simple WebMCP integration could annotate an existing Webform. A more advanced one would live in the theme or a custom module that attaches JavaScript to selected routes. The Drupal form, validation and submission handlers would still perform the real work. WebMCP would give the browser agent a reliable way to call them.

Google and Microsoft wrote the proposal together. It is currently a W3C Community Group draft, not a W3C standard. Chrome offers an early preview behind a flag, while other browsers have not committed to support. It should therefore be added as an enhancement with a normal HTML fallback. It does not replace backend MCP Server, JSON-LD or an accessible form.

Drupal's position: WebMCP is still a browser proposal, so there is no mature Drupal module to install. Drupal is well placed to support it because Webform, Form API and custom modules already separate the action and validation from the visible interface. The same Drupal operation can serve a person today and a browser agent when the proposal matures.

Why should forms and agent requests use the same validation?

An agent requesting a quote should not bypass the rules applied to the website form.

Both routes should require the same fields, validate them in the same way and store the result in the same place. If a missing email address produces an error on the form, it should also produce a clear error through the API or MCP tool.

Drupal Webform can remain the central submission system. An endpoint or MCP tool passes data into the same validation and handlers. Agent requests can be marked and sent to a review queue.

Drupal's position: Drupal does not need a second intake system for agents. Form API and Webform can keep validation, storage and business rules in one place while different interfaces call them.

What does Drupal still need beyond good modules?

Drupal provides strong building blocks. It does not make every Drupal website easy for AI to use.

A value hidden in a long body field stays hidden until someone moves it into a dedicated field. The same failure mode appears when specs live only in images; see text in images and SEO. An empty product description remains empty after JSON-LD is added. An MCP tool cannot return a useful warranty period if the site never stored one.

Modules do not write the answer. They publish, label and expose the information the organization has chosen to maintain.

Configuration matters too. JSON:API can expose unnecessary fields, schema mappings can be incomplete, and a CDN can serve an old response when invalidation is missing. Write-enabled MCP tools need narrow authentication and permissions.

Drupal fits substantial content, many attributes, several languages, integrations and strict access rules. A five-page brochure site may not need this machinery. A multilingual catalogue or documentation library benefits because one entity model replaces repeated work across templates, scripts and repositories.

This is why Drupal configuration matters so much. The content types, fields, permissions, metadata, cache rules, API resources and MCP tools have to describe the same system. Drupal provides all these parts, but the project team still has to connect them correctly. A good configuration makes one content update appear everywhere it should. A poor one leaves useful data buried, duplicated or exposed to the wrong users.

Is Drupal ready for the web shaped by LLMs?

LLMs are placing new demands on websites. Pages need clear server-rendered HTML and structured facts. The same content may also need JSON-LD, Markdown, discovery files, feeds, APIs or tools that an agent can call.

Drupal supports this whole range. Core provides structured fields, HTML rendering, multilingual content, permissions, Views, cache metadata and JSON:API. Mature contributed modules add JSON-LD, stable URLs, redirects, exports and authentication. Newer modules already cover Markdown, llms.txt, AI discovery files and the full MCP protocol.

Not every new convention will survive. Markdown has mixed results, llms.txt has no measured citation benefit, and WebMCP is still a browser proposal. Drupal does not force a team to bet the website on any of them. It lets the team add a format or interface when it becomes useful, while the same content, permissions and editorial workflow stay in place.

That is the real advantage. Drupal does not solve AI visibility with one fashionable module. Its architecture already supports the established requirements and gives teams a practical route to adopt the new ones. As LLMs change how websites are read and used, Drupal is one of the platforms best prepared for that change. Once fetchers can read your pages, how to measure whether AI recommends you shows how to track mentions and citations with a fixed question set.

Common questions

Is Drupal good for AI SEO?

Yes, especially when a website has structured content. Drupal fields can supply visible pages, JSON-LD, feeds, JSON:API and MCP tools from the same source. Drupal also renders HTML on the server by default and has mature modules for URLs, metadata, sitemaps, multilingual content and cache invalidation.

These features remove technical obstacles but cannot guarantee a recommendation. The site still needs direct, credible answers.

Do I need a special Drupal module to be cited by ChatGPT?

No. ChatGPT and other assistants can cite a normal public HTML page. Start with server-rendered content, stable URLs, clear headings and explicit facts.

Schema.org Metatag adds JSON-LD, Markdownify adds .md pages, JSON:API exposes entities, and MCP Server provides tools. None creates useful content on its own.

Should we publish llms.txt?

Publish it for developer documentation or tools that follow the convention. Do not expect a Google gain: Google says Search ignores llms.txt, and the measured requests came from SEO audit tools rather than major answer engines.

Do we need Markdown versions of our pages?

They are optional. Some OpenAI crawlers fetch dedicated .md URLs, while Google says they are not needed for Search. If Markdownify is a small change, enable it, keep HTML canonical and check the logs.

Is there an MCP server for Drupal?

Yes. The MCP Server module supports the full protocol, including tools, resources, prompts, sampling, STDIO, HTTP and OAuth 2.1. Tool API plugins can be exposed as MCP tools through Drupal configuration.

Version 2.0 was beta when this article was prepared, already provided the complete server architecture and was recommended for new implementations. The older mcp project is being merged into it.

What do we get without adding new modules?

Drupal core provides fields, server-rendered HTML, multilingual content, permissions, cache metadata, Views and JSON:API. Contributed modules add JSON-LD, Markdown, llms.txt, exports, API authentication, cache purging and MCP.

Want to make your Drupal site easier for AI to read and cite?

For ProjektMagazin we built an AI document chatbot that connects to Drupal through JSON APIs and indexes multiple content types with taxonomy, author and custom metadata. Webhooks update changed content within seconds, with scheduled synchronization as a fallback. The retrieval system has run in production for months.

Interested in JSON-LD, APIs or MCP tools on your Drupal platform? We design content models, structured data and agent integrations, then build and maintain the site. Visit our content management solutions page to see how we can help.