AI Readiness Audit
The AI Readiness Audit crawls every page on your site (or a filtered subset) and scores each one across seven dimensions that influence how effectively AI systems can discover, understand, and cite your content. You get a per-page breakdown plus an aggregate site score so you can identify exactly where to invest your optimization efforts.
What You'll Learn
In this guide, you'll learn:
- What the seven scoring dimensions are and why they matter
- How each dimension is scored (thresholds, weights, and methodology)
- How to launch an audit, filter pages, and save page groups
- How to read and act on your results
- How pricing and usage work for different plan types
The Seven Dimensions
Every page that is audited receives a score from 0 to 100 on each applicable dimension. Some dimensions are not applicable to every page type — when a dimension is not relevant to a page's detected intent (e.g., Readability on a homepage), it is excluded from that page's overall score and the remaining weights are re-normalized.
| Dimension | Weight | What It Measures |
|---|---|---|
| Static Content Ratio | 22% | How much content is visible without JavaScript |
| Citation Readiness | 20% | How well content is structured for AI to cite |
| Structured Data | 18% | Whether the right JSON-LD schemas are present and complete |
| Performance for AI | 14% | How fast and efficiently content is delivered to AI crawlers |
| E-E-A-T Signals | 14% | Trust and authority signals at the brand and page level |
| Readability | 10% | Whether content is written at an appropriate reading level |
| Accessibility | 10% | Whether the page meets core accessibility standards |
The overall page score is a weighted average of all non-null dimension scores. If a dimension returns N/A for a particular page, its weight is redistributed proportionally among the remaining dimensions.
The overall site score is the average of all individual page overall scores.
Dimension Details
Static Content Ratio
AI crawlers — including Googlebot for Gemini, GPTBot, and ClaudeBot — typically do not execute JavaScript. If your page content is rendered client-side (e.g., with React, Vue, or another SPA framework), these crawlers may see little or no content at all.
This dimension compares the text extracted from a plain HTTP fetch (no JavaScript) against the text extracted from a fully JavaScript-rendered version of the page.
How it works:
- We fetch your page's raw HTML without executing JavaScript and extract readable text
- We render the page in a headless browser with full JavaScript execution and extract readable text
- We count the tokens in each version and compute a ratio:
static tokens / rendered tokens
Scoring thresholds:
| Ratio | Score Range | Status |
|---|---|---|
| 80% or above | 80–100 | Green |
| 50–79% | 40–79 | Yellow |
| Below 50% | 0–39 | Red |
| No rendered content | 0 | Red |
What a low score means: AI crawlers are missing a significant portion of your content. Consider server-side rendering (SSR), static generation (SSG), or ensuring that critical content is present in the initial HTML response.
Citation Readiness
This dimension uses an LLM to evaluate how well your content is structured for an AI system to reference and cite. The evaluation criteria vary based on the type of page.
Evaluation profiles:
- Informational content (articles, research, technical docs, support pages): Evaluated on direct answer quality, information density, structural clarity, source attribution, comprehensiveness, freshness signals, grounding efficiency, and meta description alignment
- Product content (product pages, pricing, purchase flows): Evaluated on product clarity, specification density, differentiators, social proof, purchase context, comparison readiness, and meta description alignment
- Service/brand content (homepages, corporate pages, community, events, careers): Evaluated on service definition, audience clarity, process transparency, trust signals, outcome specificity, contact paths, and meta description alignment
Pre-filter checks:
- Pages with fewer than 50 words receive an automatic score of 0
- Missing
<h1>heading: −15 points - Missing
<h2>or<h3>subheadings: −10 points - Missing meta description: −10 points
- Meta description shorter than 120 characters: −5 points
- Boilerplate/generic meta description (e.g., "Welcome to...", "Learn more about..."): −5 points
Why the meta description matters for AI: Research by QueryBurst and RESONEO has shown that AI search pipelines like ChatGPT use a multi-stage selection process. Before a page's content is ever read, a lightweight selection model filters candidate pages using only SERP metadata: title, meta description, and URL. A missing, generic, or mismatched meta description reduces the chance the page is even fetched by the AI system. This makes the meta description a critical selection gate — not just a click-through optimization for human searchers.
The audit evaluates whether your meta description:
- Accurately previews the page's core content so a selection model can determine relevance without reading the page
- Matches the page's intent — a product page's meta description should name the product and its key differentiator; an informational page should state the topic it covers
- Is specific rather than generic — boilerplate phrases like "Welcome to [Brand]" or "Official page for..." provide no signal to selection models
- Falls within optimal length (120–160 characters) — the range most reliably displayed in search results
At the site level, the audit also detects duplicate meta descriptions — pages sharing the same meta description with more than two other pages are flagged, since identical descriptions suggest templated content that provides no unique selection signal.
Skipped intents: Authentication and Legal pages are not evaluated for citation readiness (scored as N/A).
Score thresholds: Green ≥ 70 | Yellow 40–69 | Red 0–39
What a low score means: Your content may be technically accurate but not structured in a way that AI systems can easily extract, summarize, and cite. Focus on clear headings, concise answers to likely questions, well-organized sections, and a meta description that clearly previews the page's content and intent.
Token Chunk Quality Analysis
In addition to the LLM evaluation, Citation Readiness includes a token chunk quality analysis that examines how well your content is structured for the 128-token processing windows used by AI systems like ChatGPT.
Background: Research by QueryBurst shows that ChatGPT's search pipeline and GPT-OSS-20B use a sliding attention window of approximately 128 tokens. Content that doesn't align with these windows — or that spans long stretches without structural markers — risks being partially skipped or misinterpreted during extraction.
How it works:
Before any chunk analysis can happen, we need to isolate your page's actual content from the surrounding boilerplate (navigation menus, footers, sidebars, cookie banners, cart drawers, etc.). This is done in three stages:
-
Main content container extraction — We use a prioritized list of CSS selectors to find the most specific content container in the raw HTML. The first matching selector whose content meets minimum size thresholds (at least 100 characters and at least 5% of the total body size) is selected. If no container matches, we fall back to the full
<body>. -
Defuddle cleanup — The isolated HTML is passed through Defuddle, which removes remaining boilerplate elements that made it through the container extraction: sidebars, filter/sort UI, cookie banners, comment sections, ad elements, and mobile menu remnants.
-
Markdown conversion — The cleaned HTML is converted to Markdown using Turndown with ATX-style headings (
##), fenced code blocks, and-bullet markers. Link URLs are stripped (only anchor text is kept) and images are converted to a lightweight[Image: alt text]format.
Content container selectors by platform:
The selector list is checked in priority order — the first match wins. This table shows the selectors we check, grouped by platform. If your site uses a platform or theme not listed here and we're not correctly isolating your content, let us know and we can add support.
| Priority | Platform | Selectors |
|---|---|---|
| 1 | Semantic HTML5 (all platforms) | <main>, [role="main"] |
| 2 | Common IDs (cross-platform) | #main-content, #MainContent, #main, #content, #primary, #page-content, #site-content |
| 3 | Common classes (cross-platform) | .main-content, .page-content, .site-content, .content-area, .entry-content, .post-content |
| 4 | Shopify | #shopify-section-template--main, [data-section-type="collection-template"], [data-section-type="product-template"], [data-section-type="article-template"], .shopify-section--main |
| 5 | WordPress | #primary .entry-content, article.post, article.page, .hentry |
| 6 | Wix | #PAGES_CONTAINER, #SITE_PAGES |
| 7 | Squarespace | .Main-content, #page |
| 8 | Generic (fallback) | <article>, [role="article"] |
Why this matters for chunk quality: If the content extraction fails to isolate the main content, the Markdown will include navigation links, footer boilerplate, and other non-content text. These waste tokens and create structural deserts that reduce chunk quality scores. Sites using semantic HTML5 (<main> or [role="main"]) get the most reliable extraction because these elements are unambiguous signals of the content boundary.
After content extraction is complete:
- The Markdown is tokenized using the GPT-4o tokenizer (
o200k_baseencoding) - A token-to-character offset map is built so results can be displayed against the original content
- Three checks are performed:
Image alt text handling: Rather than stripping images entirely (losing valuable context) or keeping full Markdown image syntax (wasting ~10 tokens per image on URLs), the analysis preserves image alt text in a lightweight [Image: descriptive alt text] format. This retains the semantic signal from alt text — which supports EEAT (demonstrates visual content exists) and provides accessibility context — while eliminating URL tokens that carry no meaning for chunk analysis. Images with empty or missing alt text are dropped entirely. The [Image: marker is treated as a structural boundary, so images with descriptive alt text naturally break structural deserts. Note that this representation differs slightly from how LLMs actually "see" a page (they don't see images at all in most search pipelines), but we include it because alt text is a meaningful content signal that influences how AI systems understand the page's completeness and authority.
Check 1: Structural Desert Detection
A "structural desert" is a span of consecutive tokens with no heading, list item, paragraph break, blockquote marker, or image alt text marker. Long deserts mean the AI system may process multiple 128-token chunks with no structural context.
- Deserts between 200–384 tokens are flagged as warnings (yellow)
- Deserts longer than 384 tokens are flagged as critical (red)
- Each desert over 256 tokens incurs a scoring penalty (−10 points, capped at −30)
Check 2: Window-Start Alignment
This check evaluates what percentage of 128-token windows start at a structural boundary (heading, list item, paragraph break) or a sentence boundary. Windows that start mid-sentence or mid-paragraph may result in fragmented extraction.
- ≥50% aligned: full marks (40 points)
- 40–49%: 30 points
- 30–39%: 20 points
- Below 30%: 0 points
Check 3: Best-Chunk Self-Containedness
The analysis identifies the most topic-relevant 128-token chunk (by overlap with the page title and H1/H2 headings) and evaluates whether it would make sense as a standalone citation:
- Starts at boundary — does the chunk begin at a sentence or structural boundary?
- Ends at boundary — does the chunk end at a sentence or structural boundary?
- Contains complete sentence — does the chunk include at least one full sentence?
If all three conditions pass, the chunk is self-contained (30 points). Two conditions: partial (15 points). Fewer: fragmented (0 points).
Composite Chunk Quality Score:
The three checks combine into a 0–100 score: 100 − desert penalty − alignment penalty − self-containedness penalty. This score is then blended 20/80 with the LLM's citation readiness evaluation, meaning 80% of the Citation Readiness score comes from the LLM's content quality assessment and 20% from the structural chunk analysis.
Visualization:
In the page detail view, the Chunk Analysis tab shows a rendered preview of your page content with inline emoji markers indicating where chunk boundaries, deserts, and the best chunk fall:
- 🏅⏵ / ⏴🏅 — Best chunk start and end. This is the 128-token window with the highest keyword overlap with your page title and headings — the chunk most likely to be selected when an AI cites your page.
- 🟠⏵ / ⏴🟠 — Desert start and end. Long runs of text with no structural markers (headings, lists, paragraph breaks). AI systems may process several consecutive windows within a desert with no structural context.
- 🟢 — Aligned window boundary. This 128-token window starts at or near a sentence boundary or structural element (heading, list item, paragraph break). When a window starts at a clean boundary, the AI system receives a coherent chunk of text.
- 🔴 — Unaligned window boundary. This window starts mid-sentence. The AI system's processing window begins partway through a thought, which may cause fragmented extraction or lost context.
Each toggle in the toolbar controls which markers are visible. The "Windows" toggle shows the count of aligned vs. total windows (e.g., "2/8 aligned").
Understanding window alignment — why green matters:
AI search pipelines like ChatGPT's process your content by splitting it into fixed-size windows of approximately 128 tokens. These windows start at fixed token offsets (token 0, 128, 256, 384...) regardless of your content structure. A window that happens to start at a sentence boundary or heading gives the AI a clean, coherent chunk to work with. A window that starts mid-sentence means the AI's first few tokens are the tail end of a previous thought — context that may be discarded or misinterpreted.
A higher percentage of green (aligned) windows means more of your content will be processed as coherent, self-contained units. This directly improves the quality of AI citations and reduces the chance of your content being partially skipped or garbled in AI responses.
How to improve window alignment:
You cannot directly control where the 128-token boundaries fall — they're determined by the tokenizer. But you can influence alignment by adjusting your content structure:
- Use more headings and subheadings. Each heading creates a structural boundary. More headings mean more chances for a window to start at one.
- Break long paragraphs into shorter ones. Paragraph breaks (
\n\n) are structural boundaries. A wall of text spanning 500+ tokens guarantees that multiple windows will start mid-sentence. - Use bullet and numbered lists. Each list item is a structural boundary. Converting a long paragraph into a bulleted list dramatically increases alignment.
- Keep sections focused and concise. Shorter sections naturally create more boundary points per token, increasing the probability that window starts coincide with meaningful breaks.
The goal is not to artificially inflate the score — it's to structure your content so that when AI systems split it into windows, each window contains a coherent thought. Well-structured content is also better for human readers, so this optimization aligns with general content quality best practices.
Skipped intents: Authentication and Legal pages are not analyzed (same as Citation Readiness). Pages with fewer than 256 Markdown tokens are also skipped as they don't contain enough content for meaningful window analysis.
Structured Data
Structured data helps AI systems understand what your page is about without ambiguity. This dimension checks whether the correct JSON-LD schemas are present for your page type, whether the right @type values are used, and whether key fields are populated.
How it works:
- We detect the page's intent (e.g., Product, Informational, Homepage)
- We look up which JSON-LD schema types are required and which are bonus for that intent
- We check whether the required schemas are present, whether the
@typevalues match, and what percentage of key fields are populated
Example schema requirements:
| Page Type | Required (any of) | Bonus |
|---|---|---|
| Homepage | Organization, WebSite | FAQPage, SiteNavigationElement |
| Product | Product, Offer | FAQPage, Review, AggregateRating |
| Informational | Article, BlogPosting | FAQPage, HowTo, BreadcrumbList |
| Support | FAQPage, HowTo | BreadcrumbList |
| Careers | JobPosting | Organization |
Scoring tiers:
| Condition | Score |
|---|---|
| No JSON-LD found | 0 |
| JSON-LD present but wrong types | 40 |
| Required schema present | 75 base |
| + Field completeness bonus | up to +15 |
| + Bonus schemas present | up to +10 |
| Intent has no schema mapping | N/A (excluded) |
Freshness in structured data: For Article, BlogPosting, TechArticle, and NewsArticle schemas, datePublished is treated as a required field — its absence reduces the field completeness score. If datePublished is present but dateModified is missing, the audit generates a recommendation to add it. Including dateModified signals to search engines and AI pipelines that the content is actively maintained, which is especially important for pages that target recency-filtered queries.
What a low score means: Add or fix JSON-LD markup on the page. Use Google's Rich Results Test to validate your markup, and ensure key fields like name, description, image, and intent-specific properties are populated.
Performance for AI
AI crawlers don't render pages in a browser — they fetch raw HTML. This dimension measures how quickly and efficiently your server delivers content.
Metrics checked:
| Metric | Green | Yellow (−15) | Red (−35) |
|---|---|---|---|
| Time to First Byte (TTFB) | < 800 ms | 800 ms – 2 s | > 2 s |
| HTML Transfer Time | < 1 s | 1–2 s | > 2 s |
| HTML Document Size | < 500 KB | 500 KB – 2 MB | > 2 MB (−30) |
Scoring starts at 100 and deducts points per metric. The content-to-markup ratio is measured for informational purposes but does not affect the score.
What a low score means: Your pages are slow to respond or bloated with HTML. Improve server response times, reduce unnecessary markup, and consider caching strategies for AI crawler traffic.
E-E-A-T Signals
E-E-A-T stands for Experience, Expertise, Authoritativeness, and Trustworthiness. While there is no published or accepted standard for exactly how search engines evaluate E-E-A-T, it is widely understood to be a significant factor in how Google and other AI systems assess content quality and trustworthiness.
Our E-E-A-T scoring combines a number of signals that we believe to be factors in how Google evaluates this quality metric. The score has two components:
Brand-Level Signals (40% of E-E-A-T score)
These are checked once per audit across your entire site:
| Signal | Points |
|---|---|
Organization schema with sameAs links | 18 |
| About page exists | 15 |
| HTTPS enabled | 15 |
| Contact page exists | 12 |
| Privacy policy page exists | 10 |
| Terms of service page exists | 10 |
| robots.txt exists | 8 |
| HSTS header present | 8 |
| Content Security Policy header | 4 |
| Total possible | 100 |
Page-Level Signals (60% of E-E-A-T score)
These are checked per page, with relevance varying by page type:
| Signal | Base Weight | Applicable To |
|---|---|---|
| Author byline present | 30 | Articles, research, technical content |
| External citations (unique domains) | 22 | Articles, research, informational content |
| Publication/modified dates | 20 | All page types |
| Reviews or testimonials | 18 | Product, pricing, purchase pages |
| Machine-readable freshness signals | 10 | Informational, research, technical, support, product, pricing |
Only signals that are relevant to the page's intent are included. Weights for irrelevant signals are redistributed among the remaining applicable signals.
Machine-Readable Freshness Signals
Research by RESONEO (February 2026) documented explicit recency filters applied in the ChatGPT search pipeline: queries are tagged with freshness windows of 1 day, 7 days, 14 days, or 30 days. These filters operate on whatever date signal the underlying search engine has extracted for the page before the selection model ever sees it. If a page has no machine-readable date, the search engine may not associate it with any date, making it ineligible for recency-filtered queries.
This is distinct from the existing check for "publication dates visible on the page" (which is about human trust). Freshness signals are about machine-readable dates that search engines and AI pipelines can extract and filter on.
The audit checks three layers of date signals:
Layer 1: JSON-LD date properties (40 points)
For pages with Article, BlogPosting, NewsArticle, TechArticle, or WebPage schema:
datePublishedis present and is a valid ISO 8601 datedateModifiedis present and is a valid ISO 8601 datedateModified≥datePublished(a modified date before the published date is flagged as a data error)- Both dates are realistic (not in the future, not before the year 2000)
Both present and valid: full credit (40 points). Only datePublished: partial credit (25 points). Neither present: zero credit. Invalid or inconsistent dates: zero credit with a specific finding.
Layer 2: Open Graph date tags (30 points)
Checks for article:published_time and article:modified_time meta tags. Their presence earns 30 points. If both OG dates and JSON-LD dates are present, the audit checks that they agree within 24 hours — conflicting signals between layers are flagged.
Layer 3: HTTP Last-Modified header (10 points)
If the server sends a Last-Modified response header, 10 points are awarded. Missing HTTP Last-Modified is noted at low severity — many CDNs and single-page applications don't send this header, so its absence is common and less severe than missing schema dates.
Cross-layer consistency (20 points)
The highest-value check: do the date signals across all three layers tell a consistent story? Points are deducted if:
- JSON-LD and OG published dates differ by more than 24 hours
- HTTP
Last-Modifiedpredates JSON-LDdateModifiedby more than 30 days (suggests the schema date was updated without the page actually being re-deployed)
Applicability:
- Full check (all three layers): Informational, Research, Technical, Support pages
- Partial check (JSON-LD only): Product, Pricing pages — these benefit from
dateModifiedto signal active maintenance, but OG date tags and HTTP Last-Modified are less relevant - Skipped: Homepage, Legal, Authentication, and other non-content page types
What a low score means: Your site or page is missing trust signals. Start with site-wide improvements (about page, contact info, privacy policy, HTTPS) for the biggest impact, then add page-level signals like author attribution and dates. For freshness signals specifically, ensure your article schemas include both datePublished and dateModified, and consider adding article:published_time and article:modified_time Open Graph tags.
Readability
Content written at an appropriate reading level is easier for AI systems to parse, summarize, and present to users. If AI decides to include your content in a response, if it is not written at a level that fits other content the LLM may choose to rewrite it. If this happens, the effort you put into carefully wordsmithing your content will be wasted.
This dimension evaluates three aspects of your writing.
Applicable page types: Informational, Research, Technical, and Support pages only. All other page types receive N/A.
Sub-metrics:
| Sub-metric | Green (no penalty) | Yellow | Red |
|---|---|---|---|
| Flesch Reading Ease | 45–65 | 30–44 or 66–80 (−20) | Below 30 or above 80 (−40) |
| Flesch-Kincaid Grade Level | Grades 8–11 | Grades 12–16 (−15) | Above grade 16 (−30) |
| Average Sentence Length | ≤ 25 words | Above 25 words (−15) | — |
Scoring starts at 100 and deducts points per sub-metric. The ideal range targets a college-level reading audience — technical enough to be authoritative but accessible enough for AI summarization.
Minimum content requirement: Pages with fewer than 100 characters of readable text receive a score of 0.
What a low score means: Your content may be too dense or too simple for effective AI summarization. Aim for clear, well-structured paragraphs with a mix of sentence lengths.
Accessibility
Accessible pages are better structured, use semantic HTML, and follow standards that also benefit AI interpretation. We run a focused set of axe-core accessibility checks against a browser-rendered version of each page.
Rules checked:
image-alt, heading-order, document-title, html-has-lang, landmark-one-main, region, color-contrast, link-name, label, list, meta-viewport, empty-heading
Scoring deductions per violation:
| Severity | Points per occurrence | Maximum deduction |
|---|---|---|
| Critical | −10 | −40 |
| Serious | −5 | −30 |
| Moderate | −3 | −20 |
| Minor | −1 | −10 |
Scoring starts at 100 and deducts per individual element that violates a rule (not per rule type).
What a low score means: Fix accessibility violations, starting with critical and serious issues. Common quick wins include adding alt text to images, fixing heading hierarchy, and ensuring form labels are present.
Grounding Coverage (Informational)
In addition to the seven scored dimensions, each page receives a grounding coverage estimate. This is not a scored dimension — it appears in the page detail findings as informational context for Citation Readiness.
Grounding coverage estimates what percentage of your page content would be selected by Google's Gemini grounding system when citing your page. This is based on research by DEJAN AI which found that Google's grounding system typically selects approximately 540 words from any page, regardless of page length.
Key insight: Pages under 1,000 words get roughly 61% coverage, while pages over 3,000 words get approximately 13% coverage. If your goal is to maximize the portion of your content that gets cited, density beats length. Concise, well-structured content performs better than detailed but lengthy articles.
When a page exceeds 2,000 words, the audit will include a finding suggesting you consider splitting the content into shorter, more focused pages.
Launching an Audit
Selecting Pages
You can select pages for an audit in three ways:
By page type (intent): Choose one or more page types — Homepage, Product, Informational, Technical, Support, etc. Only pages matching the selected types will be audited.
By path pattern: Enter glob-style path patterns to match specific sections of your site. For example:
/blog*— matches all pages whose path starts with/blog(including/blog,/blog/my-post,/blog/category/seo)/products/*— matches all pages under/products//docs*— matches/docs,/docs/getting-started, etc.
Important: Path patterns use * as a wildcard. The pattern /blog will only match the literal path /blog. To match all blog pages, use /blog* or /blog/*.
From a saved group: Select a previously saved page group to quickly re-run an audit on the same set of pages.
Saving Page Groups
After configuring your page selection (by type or by path), you can save the configuration as a named group for future use. Click Save as group, give it a descriptive name (e.g., "Blog pages", "Product section"), and it will appear in the Saved tab for future audits.
Email Notification
Larger audits may take several minutes, and a site over 1,000 pages could take an hour or more to process. You can click the mail icon next to a running audit to receive an email notification when it completes. The email includes the overall score, number of pages analyzed, and counts of critical issues and warnings.
Reading Your Results
Summary Panel
The summary panel at the top of a completed audit shows:
- Overall site score (0–100) with a circular progress indicator
- Pages analyzed and duration in the subtitle
- Critical issues count (pages scoring below 40)
- Dimension score breakdown with circular indicators for each of the seven dimensions, plus distribution bars showing green/yellow/red page counts
- Common issues grouped by type (e.g., "16 pages have citation issues")
- Scores by page type showing the average score and page count per intent
Page Results Table
The table lists every audited page with columns for:
- Page URL (hover for title and path; click the external link icon to visit the page)
- Intent (detected page type, color-coded)
- Overall score
- Individual dimension scores (Static Content, Performance, Structured Data, E-E-A-T, Readability, Citation, Accessibility)
Score colors: Green (70–100), Yellow (40–69), Red (0–39). N/A indicates the dimension is not applicable to the page's intent. ERR indicates a check that failed during processing (see Failed Checks below).
Filtering
Use the filters above the table to narrow results:
- Intent filter: Show only specific page types
- Score range: Show only Critical (0–39), Warning (40–69), or Good (70–100) pages
- Search: Filter by URL path
Page Detail Panel
Click any row to expand the detail panel, which shows:
- Metrics grid with detailed sub-scores and findings per dimension
- Findings tab with specific issues, recommendations, and contextual information
- Screenshots tab showing before (static HTML) and after (JavaScript-rendered) captures of the page, so you can visually compare what AI crawlers see versus what browser users see
CSV Export
Click the Export CSV button on a completed audit to download all results. The CSV includes:
- Summary header rows (domain, date, overall score, dimension averages, configuration details)
- One row per page with path, title, intent, and all seven dimension scores
Failed Checks
Some pages have configurations that our tooling cannot fully process. When a check fails, the affected dimension shows ERR in the results table and the page's overall score is computed from whichever dimensions did succeed.
Why checks fail
The most common causes are:
- Aggressive Content Security Policies (CSP): Some sites (notably Shopify storefronts and certain enterprise platforms) use strict CSP headers that prevent our accessibility scanner from injecting its analysis script. When this happens, the Accessibility dimension shows ERR but all other dimensions are scored normally.
- Heavy JavaScript or infinite loading: Pages with complex JavaScript that never reaches a stable "idle" state can cause our browser-based checks (Accessibility, Static Content Ratio, screenshots) to time out. Static-fetch-based dimensions (Performance, Structured Data, EEAT, Readability, Citation Readiness) are unaffected.
- Non-HTML content types: Pages that return RSS feeds, XML sitemaps, JSON, or other non-HTML/non-Markdown content types are marked as ERR immediately since they are not auditable web pages.
- Rate limiting or bot blocking: Some servers block or throttle automated requests. If a page cannot be fetched at all, all dimensions show ERR.
How billing works for failed checks
You are only charged for pages that complete successfully. If a page has any dimension errors, it is still charged as long as it received an overall score. Pages that fail entirely (e.g., non-HTML content type, fetch failure) are not charged.
If every page in an audit fails, no credits are deducted.
Will re-running the audit help?
In most cases, no. If the audit failed due to the site's configuration (CSP policy, bot blocking, heavy JavaScript), the same pages will likely fail again on subsequent runs. The underlying issue is on the website side, not ours.
To resolve these failures, the site owner would need to address the root cause — for example, relaxing CSP rules for known audit tools, optimizing JavaScript loading, or ensuring pages return proper HTML content types.
If you believe the failure is intermittent (e.g., caused by temporary rate limiting), you can try re-running the audit, but we recommend waiting at least an hour before doing so.
Pricing and Usage
Agency Plans (Core and Pro)
Agency plans include a monthly budget of pages that can be audited:
- Agency Core: 5,000 pages per month
- Agency Pro: 15,000 pages per month
Each audit draws from your monthly page budget. For example, auditing 300 pages on an Agency Core plan leaves you with 4,700 remaining pages for the month.
If you need to audit more pages than your monthly allocation, the audit will use credits for the overage at the standard rate (see below).
Pay-As-You-Go Plans
Pay-as-you-go customers are charged in credits:
- 1 credit per 50 pages (or fraction thereof)
- Minimum 1 credit per audit, regardless of page count
For example:
- A 35-page audit costs 1 credit
- An 89-page audit costs 2 credits
- A 423-page audit costs 9 credits
Credits are checked before the audit launches and debited after it completes, based on the actual number of pages analyzed. If an audit fails, you are not charged.
Best Practices
Start With a Full-Site Audit
Run your first audit across all page types to get a baseline. This reveals site-wide patterns and helps you prioritize.
Focus on High-Weight Dimensions First
Static Content (22%), Citation Readiness (20%), and Structured Data (18%) together account for 60% of the overall score. Improvements to these dimensions have the largest impact.
Use Page Type Filters for Targeted Follow-Up
After your baseline audit, filter by page type to focus improvements. For example, run an audit of just your blog content to track readability and citation improvements over time.
Address Site-Wide Issues First
E-E-A-T brand-level signals (about page, contact info, privacy policy) affect every page on your site. These are often the highest-leverage improvements.
Save Page Groups for Repeat Audits
If you regularly audit specific sections of your site, save them as page groups. This makes it easy to re-run the same audit and track progress.
Monitor Scores Over Time
Run periodic audits to track whether your optimization efforts are reflected in improved scores. Compare overall scores and dimension breakdowns between audit runs.
Related
- Property Pages - View and manage the pages indexed for your property
- AI Visibility Reports - Run AI visibility reports to see how AI systems recommend your brand
- Citation Intelligence - Track how often AI systems cite your content