A buyer asks an AI assistant whether your product supports a particular integration. Your website contains the answer, but it appears only after an interaction. Another page gives an outdated answer. Which version can the assistant retrieve?
A Drupal AI-readability audit examines these gaps: whether intended AI services can access your content, whether the delivered pages contain useful answers, and whether your website describes the same facts consistently. Read also: getting your company recommended by AI: supplier shortlist facts - the business case for published specs once a fetcher can reach your HTML.
The business goal is practical. Help prospective customers find accurate information, and give your team a clear view of what needs fixing. Drupal provides a strong foundation through structured fields, reusable entities, and control over delivery. Configuration and editorial decisions determine how much that foundation helps when assistants compare suppliers.
In this article:
- What SEO foundations stay the same for AI-assisted discovery?
- Can intended AI services access your Drupal content?
- Does delivered HTML contain the answers fetchers need?
- Does your Drupal site answer the questions buyers ask?
- Do visible content, metadata, and JSON-LD describe the same facts?
- Are company facts consistent across languages and other outputs?
- What should a useful AI-readability audit report tell your team?
- How do you build on SEO and close AI readability gaps?
What SEO foundations stay the same for AI-assisted discovery?
AI-assisted discovery still depends on familiar website fundamentals. Pages need reliable delivery, sensible navigation, useful metadata, and discoverable URLs. Sitemap coverage, indexing controls, accessible media, and mobile usability remain part of the picture.
Google's guidance on AI features retains established SEO practices. It does not introduce a separate set of technical requirements for appearing in AI Overviews or AI Mode.
That guidance concerns Google. Other providers have their own retrieval systems and access policies, so a Drupal AI-readability audit should distinguish between them.
For the broader business case, see 5 benefits of SEO audit. Technical SEO still covers crawlability, status codes, and markup that matches visible content before you extend the checklist into AI readability.
The five layers below build on those foundations. They focus on accessible answers, consistent facts, and the company context an assistant may need when comparing suppliers.
Can intended AI services access your Drupal content?
Can the intended service reach the content your company wants it to read?
A public Drupal page can still encounter restrictions elsewhere. Drupal controls publication and permissions, while a content delivery network, firewall, or bot-protection service can apply separate rules.
Those layers can disagree. A browser visitor might receive the page while an automated request receives a challenge, denial, or different status code. For a focused walkthrough of bots, WAF rules, and HTML delivery, see can an AI actually read your website?
The access layer covers:
- Robots directives relevant to the intended services.
- Drupal publication status and access restrictions.
- CDN and web application firewall rules, including bot categories.
- Response behavior for relevant automated requests.
- Whether observed restrictions match company policy.
Access is a policy decision.
Search crawling, user-triggered retrieval, and model training serve different purposes. A company may want its public product pages available for search and retrieval while restricting training access. OpenAI's bot documentation distinguishes these uses and their associated controls.
The audit should therefore identify unintended barriers separately from deliberate restrictions. Allowing every bot is not a default recommendation.
A useful access finding names the affected service, the content involved, the observed barrier, and the responsible system. It should also state what remains uncertain. A user-agent label alone does not establish the identity of a requesting service.
Does delivered HTML contain the answers fetchers need?
Does the content a service receives contain the answer?
A page can look complete to a person and still deliver little useful text in its initial HTML. Product specifications may arrive through a later request. A location selector may reveal purchase conditions. A comparison table may depend on a frontend component.
Support for JavaScript and interaction varies by service. An audit should avoid assuming either that every service renders everything or that none can process JavaScript.
Instead, this layer distinguishes information present in the delivered HTML from information that depends on additional rendering or interaction. Relevant facts include:
- Product or service descriptions.
- Specifications and supported integrations.
- Availability, eligibility, and geographic restrictions.
- Purchase, delivery, or contract conditions.
- Links to supporting documentation.
The finding may concern delivery rather than writing. Editors could have filled out every required Drupal field, yet the theme might expose those values only through an interactive component. When key facts live inside images or client-only widgets, text in images and SEO explains why fetchers may never see them.
Drupal gives teams several places to address this: field display settings, templates, frontend components, and caching behavior. The recommendation should identify the responsible layer rather than simply ask editors to add more copy.
Freshness matters here, too. An updated entity and an outdated cached page can present different facts. The audit should distinguish missing information from information that exists but reaches readers too late.
Does your Drupal site answer the questions buyers ask?
Does the website answer the questions a prospective customer actually asks?
A retrievable page may still leave the reader guessing. "Integrates with your existing systems" says little about supported products, versions, or implementation requirements.
This layer assesses answer coverage against the agreed set of buyer questions. It also examines whether the site clearly explains who the company serves, what it provides, where it operates, and what evidence supports its claims. Editorial patterns such as answer-first writing for AI search help each section state the direct answer before the explanation expands.
Different gaps need different fixes:
| Answer gap | What it means | Likely response |
|---|---|---|
| Missing | The site does not provide the required fact. | Obtain and publish the information. |
| Buried | The answer exists, but its placement makes it difficult to find or connect to the question. | Bring it into the relevant page or section. |
| Ambiguous | The wording supports multiple interpretations. | Add precise terms, limits, or conditions. |
| Conflicting | Pages give different answers to the same question. | Establish the current fact and update dependent content. |
Word count is not the target. A short, precise specification may answer a question more effectively than several paragraphs.
Evidence and ownership also matter. Technical claims may need supporting documentation. Expert guidance may need an identifiable author or reviewer. Freshness should reflect actual review and changes, rather than a recently refreshed date on unchanged content.
Recurring gaps often point to the content model. If editors repeatedly omit service regions, compatibility details, or eligibility conditions, Drupal content modeling for answer coverage can give those facts a consistent home. Editorial ownership will still be necessary: a field cannot decide whether a statement remains true.
Do visible content, metadata, and JSON-LD describe the same facts?
Do page content, metadata, and structured data describe the same thing?
Structured data can help machines interpret an organization, product, article, or relationship. Its presence alone does not establish correctness.
This layer examines:
- Appropriate structured data and required properties for the chosen use.
- Stable identity for organizations, products, and other entities.
- Agreement between markup and visible content.
- Metadata and heading structure that reflect the page's purpose.
- URL patterns and canonical signals.
- Internal links that connect related information.
Consider a hypothetical product page that says "Out of stock" while its JSON-LD declares InStock. Both statements are machine-readable. They conflict.
The recommendation should address the source of that disagreement. If a template contains a hard-coded availability value, editing the page copy will not resolve it. Map fields to markup with JSON-LD in Drupal and Schema.org Metatag so one edit updates both representations.
Drupal's entity reference fields support explicit relationships between content records. Field mappings can also let visible content and markup draw from the same maintained values. These capabilities help reduce duplicate sources of truth, but the implementation must use them consistently.
Valid markup does not guarantee a citation. Nor does every page need every schema type. The aim is accurate, appropriate descriptions, not the largest possible block of JSON-LD.
Are company facts consistent across languages and other outputs?
Does the same company remain recognizable wherever its information appears?
A multilingual site may carry different product descriptions, service regions, or legal details across language versions. Some differences reflect real market conditions. Others reflect an outdated translation.
An audit should distinguish between them.
This layer covers translation relationships, language and market distinctions, obsolete local content, and applicable documents. Drupal-side recommendations may concern translation workflows, shared fields, entity references, or editorial responsibility. For governance across locales and market-specific facts, see Drupal multilingual websites and AI-assisted translation workflows.
External profiles require a separate view. A company name, address, or service description on a third-party profile may disagree with the website. A useful finding identifies the discrepancy and its supporting evidence without treating every external platform as mandatory. Wikipedia or Wikidata presence is not a universal requirement.
Alternative formats belong here, too.
Drupal content can support HTML, JSON-LD, API responses, feeds, and Markdown. Existing Markdown or llms.txt-related outputs should have an intended consumer and a maintenance path. Otherwise, they can become another place for outdated facts to persist.
The audit should ask what purpose those outputs serve and whether they remain consistent with current published content. Optional files are not universal eligibility requirements for AI discovery.
Security boundaries still apply. An alternative representation should preserve the publication and access rules that govern the underlying content.
What should a useful AI-readability audit report tell your team?
A report earns its place when your team can act on it. Length is not the deliverable.
Findings should connect a concrete issue to its business significance, responsible area, and likely effort. Cost to fix belongs beside the expected effect, with uncertainty stated plainly.
The following examples are illustrative, not reported client results:
| Issue | Significance | Responsible area | Finding type |
|---|---|---|---|
| An intended retrieval service encounters an edge challenge on public pages. | The service may be unable to retrieve those pages. | Infrastructure and security | Confirmed access barrier, if observed |
| Integration pages omit supported versions. | Buyers lack a fact needed for comparison. | Content owner and Drupal content model | Content improvement |
| Product markup disagrees with visible availability. | The site publishes conflicting facts. | Drupal development and product data | Consistency defect |
| The company deliberately restricts training crawlers. | Access reflects a business decision. | Security, legal, and business owner | Policy choice |
| An existing Markdown output contains retired service details. | An alternative representation publishes outdated information. | Content owner and integration team | Optional-output maintenance |
Unassessed areas should remain visible. "Outside scope" does not mean "passed."
Tracking whether assistants mention you belongs in a separate measurement program. How to measure whether AI recommends you explains baselines and limits without treating visibility scores as proof that a specific page defect was fixed.
What does an illustrative availability finding look like?
Finding: Product availability conflicts between visible content and JSON-LD.
Affected area: A product page using an availability field for its visible message and a separate value for structured data.
Evidence: The visible page states "Out of stock." The JSON-LD declares https://schema.org/InStock.
Why it matters: Systems reading different representations receive contradictory facts about whether a buyer can purchase the product.
Recommended change: Make the page and markup use the same authoritative availability value. If markets have different availability, preserve that distinction in both representations.
Responsible area: Drupal development, with the product owner confirming the intended availability rules.
Effort considerations: A single hard-coded template value may require a contained change. Separate inventory systems or market-specific rules may expand the work.
Expected effect: Remove the contradiction. This finding does not establish that an assistant used the incorrect value or that correcting it will produce citations.
That is enough to support a decision without claiming an outcome the evidence cannot prove.
How do you build a baseline for the next audit?
The audit should preserve the assessed scope, date, relevant access policy, affected content, and evidence behind each finding. It should distinguish unavailable answers from incomplete answers and contradictory ones.
That record gives a later Drupal AI-readability audit something concrete to compare: whether an access barrier remains, whether missing facts now appear, and whether outputs agree.
AI recommendation visibility is a separate outcome. It can change for reasons beyond the website, so it should not substitute for evidence that a particular defect has been corrected.
Whether your team conducts the assessment or brings in outside help, the scope should remain understandable. External support can provide time, Drupal expertise, and coordination across infrastructure, development, and content teams. It should not depend on a secret definition of "AI-ready."
How do you build on SEO and close AI readability gaps?
Drupal gives teams control over content structure and delivery. A Drupal AI-readability audit examines whether those capabilities produce accessible answers and consistent facts across the places that matter.
Start with the barriers. Separate policy choices from defects. Give missing information an owner, and keep alternative outputs connected to maintained content.
There is no universal AI-readability badge. There are specific problems your team can identify, understand, and fix.
Want help defining the scope for your Drupal website? Explore Droptica's Drupal SEO audit service and tell us which audiences, languages, and AI services matter to your business. We will help define the assessment around those needs.
