Enterprise content teams are navigating two challenges that are intensifying at the same time: rising pressure to meet web accessibility compliance standards, and a fundamental shift in how AI systems discover, evaluate, and cite online content.
dotCMS has introduced tools to address both — built directly into the visual editing workflow.
The Accessibility Compliance Burden
Web accessibility is now a legal requirement across multiple jurisdictions — including the ADA in the United States, the AODA in Ontario, Canada, and the European Accessibility Act, which began applying to economic operators on 28 June 2025. The technical standard behind all of them is WCAG, and the consequences of falling short are real.
Domino's faced six years of litigation after a blind customer couldn't order through its website and app — the case reached the U.S. Supreme Court, which in 2019 declined to hear Domino's appeal, leaving in place a Ninth Circuit ruling that the ADA applies to commercial websites. Years earlier, Target paid $6 million to settle a class-action brought by the National Federation of the Blind over Target.com's inaccessibility — the first major precedent establishing that the ADA reaches e-commerce. The 2025 WebAIM Million report found that 94.8% of the top one million home pages had detectable WCAG failures, with an average of 51 errors per page — over 50 million accessibility errors in total. Most of those errors persist for a simple reason: content teams have no way to check for them before they publish.
The AI Discoverability Problem
How content gets found on the web is shifting at a speed most organizations haven't fully absorbed. Gartner projected in February 2024 that traditional search engine volume would drop 25% by 2026 as AI chatbots and virtual agents take over. That trend is already visible — Google AI Overviews now appear on a majority of U.S. search queries, according to BrightEdge data, and when they do, Seer Interactive's analysis of 3,000+ informational queries found organic click-through rates fell 61% from mid-2024 levels.
Unlike traditional search, AI engines synthesize answers and cite only a handful of sources, meaning brands either earn a citation or receive no exposure at all — regardless of their search ranking. The same Seer study found that brands cited in AI Overviews earned 35% more organic clicks than those not cited. Research published at the 2024 ACM SIGKDD conference found that pages with external citations, statistics, and attributed quotations receive up to 40% more visibility in AI-generated responses — signals that are measurable in a page's HTML, but that content teams currently have no in-CMS way to evaluate.
The Common Problem
Both issues share the same pattern: they go undetected until after content is published, because the signals that matter — rendered HTML, schema markup, alt text, contrast ratios, citation structure — aren't visible inside the CMS editorial workflow. The result is content that carries compliance risk and limited AI discoverability, published by teams who simply didn't have the right information at the right moment.
Introducing Page Health in dotCMS
dotCMS is introducing Page Health, a new diagnostic capability built into the Universal Visual Editor (UVE). The first two scanners — the Accessibility Scanner and the GEO Scanner — ship in Q2 2026. Both analyze the fully rendered HTML of a page, the same content that a browser, a search crawler, or an AI engine would actually see, and surface specific, actionable findings before publish.
The Accessibility Scanner (WCAG Checker)
The Accessibility Scanner uses the Axe JavaScript library — the same engine used widely by accessibility professionals — integrated via dotCMS's Node.js serverless function infrastructure. When triggered, it fetches the rendered page HTML and runs it through a full WCAG 2.1 AA audit.
Results appear in the UVE sidebar, organized by severity (critical, serious, moderate,minor), with a plain-English explanation of each violation and specific remediation guidance. For teams in compliance-critical environments, the scanner can be configured to block publish on critical violations — making accessibility part of the editorial process rather than a post-publish review.
Coverage supports ADA (U.S.), AODA (Canada), and EAA (EU) compliance requirements.
The GEO Scanner (AI Readiness Checker)
The GEO Scanner evaluates a page across four categories and twenty signal checks, producing a 0–100 readiness score:
Citability (30%) — External source citations, statistics, expert quotations, content depth, and answer structure.
Structured Knowledge (25%) — Schema.org markup presence, validity, and completeness; heading hierarchy; internal linking.
Content Authority (25%) — Author attribution, publish date, image alt text, title specificity, and HTTPS.
Discoverability (20%) — Meta description, canonical tag, indexability, Open Graph tags, and language declaration.
Each signal returns a score and a specific message. Issues below the threshold surface as high, medium, or low severity, sorted by impact. An editor sees a prioritized action list — concrete and specific rather than a generic recommendation to improve content quality.
The GEO Scanner is available both as a UVE panel for editorial use and as a REST endpoint (POST /api/geo-score) for developers building automated quality gates, CI/CD checks, or custom dashboards.
What Changes for Teams
With Page Health, accessibility compliance and GEO readiness become visible at the point where content is being created and reviewed — not discovered during an audit or after traffic has declined. Editors see specific issues and specific fixes, in the same environment where they work.
For teams managing content that must be WCAG compliant, this means pre-publish WCAG validation that is continuous and integrated rather than periodic and external. For marketing and content teams, it means measurable, page-level signals tied directly to what the research shows drives AI citation — not general guidance on content quality.
Because both scanners run against rendered HTML, they evaluate the actual page — with all rendering applied — rather than raw content fields. That matters because many accessibility failures and GEO gaps only appear in what the browser and AI engine actually receive.
Getting Started
Page Health is available to dotCMS customers now. Both scanners are included with dotCMS — no additional tooling or cost required. To enable the Accessibility Scanner or the GEO Scanner on your instance, contact your dotCMS support agent or account team.
Closing
Accessibility compliance requirements are tightening across jurisdictions at the same time that AI systems are reshaping how web content is found and surfaced. These aren't future concerns — the regulatory deadlines are set, the traffic shifts are documented,
and the costs of non-compliance are established.
Page Health gives content teams and platform engineers the visibility they need to act on both challenges before publish, with guidance specific enough to be useful. That is the direction dotCMS is building toward: content governance that connects what's created to how it performs — across compliance, discoverability, and the editorial workflow where all of it starts.
FAQs
1. What is Page Health in dotCMS?
Page Health is a diagnostic capability built into the Universal Visual Editor (UVE) that analyzes the fully rendered HTML of a page before it's published. It currently includes two scanners — the Accessibility Scanner and the GEO Scanner — that surface specific, actionable issues alongside the content as editors work on it.
2. When is Page Health available, and is there an additional cost?
Both scanners are available to dotCMS customers now. They are included with dotCMS at no additional cost. To enable them on your instance, contact your dotCMS support agent or account team.
3. Which accessibility standards does the Accessibility Scanner cover?
The scanner runs a full WCAG 2.1 AA audit, which is the technical standard underpinning ADA (United States), AODA (Canada), and the European Accessibility Act (EU). It uses the Axe JavaScript library — the same engine widely used by accessibility professionals — integrated via dotCMS's Node.js serverless function infrastructure.
4. How is this different from running Axe or a third-party accessibility tool externally?
External tools run after publish, in a separate workflow, often by a different team. The Accessibility Scanner brings the same audit inside the editorial workflow — results appear in the UVE sidebar, organized by severity, with plain-English explanations and remediation guidance. For compliance-critical environments, the scanner can be configured to block publish on critical violations, making accessibility a pre-publish gate rather than a post-publish review.
5. What is GEO, and why does it matter?
GEO stands for Generative Engine Optimization — preparing content to be discovered, evaluated, and cited by AI answer engines like Google AI Overviews, ChatGPT, and Perplexity. Unlike traditional search, AI engines synthesize answers and cite only a handful of sources per query, so brands either earn a citation or receive no exposure. Research has identified specific HTML-level signals that drive AI citation; the GEO Scanner makes those signals measurable inside the CMS.
6. What does the GEO Scanner actually check?
The scanner evaluates a page across four weighted categories and twenty signal checks, producing a 0–100 readiness score:
Citability (30%) — external citations, statistics, expert quotations, content depth, answer structure
Structured Knowledge (25%) — Schema.org markup, heading hierarchy, internal linking
Content Authority (25%) — author attribution, publish date, image alt text, title specificity, HTTPS
Discoverability (20%) — meta description, canonical tag, indexability, Open Graph tags, language declaration
Each signal returns a score and a specific message. Issues are sorted by severity and impact so editors see a prioritized action list rather than generic recommendations.
7. Can developers integrate the GEO Scanner into automated workflows?
Yes. The GEO Scanner is available both as a UVE panel for editorial use and as a REST endpoint (POST /api/geo-score) for developers building automated quality gates, CI/CD checks, or custom dashboards.
8. Why does it matter that both scanners analyze rendered HTML?
Many accessibility failures and AI discoverability gaps only appear in what a browser, search crawler, or AI engine actually receives — not in raw content fields inside the CMS. By evaluating the fully rendered page, both scanners surface issues that field-level validation would miss.
9. Who is Page Health for?
The Accessibility Scanner is built for content teams operating in compliance-led environments — healthcare, financial services, government, telecommunications, manufacturing — where WCAG conformance carries legal and reputational risk. The GEO Scanner is built for marketing and content teams whose audiences increasingly find them through AI-generated answers rather than traditional search results. Most enterprise content teams need both.
10. Will more scanners be added to Page Health?
The Accessibility Scanner and GEO Scanner are the first two capabilities in Page Health. dotCMS is building toward broader page-level diagnostics that connect what's created in the CMS to how it performs across compliance, discoverability, and the editorial workflow.