Quality Metrics (Performance, SEO and Agentic Readiness)

Accessibility tells you whether people can use your pages. It does not tell you whether those pages load quickly, whether search engines can index them, or whether an AI agent can understand and operate them.

Every scheduled scan can therefore collect three additional quality metrics alongside its accessibility results:

Metric	What it measures
Performance	How quickly the page becomes visible, stable and responsive - load speed, layout stability and main-thread blocking
SEO	Whether the page follows the technical practices search engines rely on to find, index and list it
Agentic Readiness	Whether the page can be understood and operated by AI agents and assistants

All three are scored 0-100, use the same colour convention as your accessibility scores, and are reported at three levels: per site, per scan run, and per individual page.

Note: These metrics are collected by Scheduled Scanning only. Real-Time Scanning runs inside your visitors' browsers and continues to report accessibility results exclusively.

Where You See Them

Screen	What it shows
My Sites	One gauge per metric on each site card, alongside the site's accessibility gauge
Scan Results	Overall results for a whole scan run, plus a per-page table
URL Scan Details	One page's results, including every individual finding behind the score
Scan History	A score-over-time chart per metric, across the configuration's runs

On the two scan screens, the four categories - Accessibility, Performance, SEO and Agentic Readiness - are presented as tabs. Accessibility is selected when the page opens, and looks exactly as it did before; the other three tabs each have their own summary and their own supporting detail.

Above the tabs, a Scan Information block holds the facts that describe the run or the page rather than any one metric, so it stays in place whichever tab you are on - Total URLs Scanned and Scan Duration on Scan Results, and the page's address, screenshot, scan time and status on URL Scan Details.

The selected tab is kept in the page address, so a link you bookmark or send to a colleague opens on the same tab you were looking at. Clicking a page in the Scan Results table also carries your tab across, so you stay on Performance instead of landing back on Accessibility.

Reading a Score

Every score uses the same colour bands as accessibility scores, so a colour always means the same thing across the product:

Score	Status	Colour
85-100	Good	Green
60-84	Average	Amber
1-59	Poor	Red

Because the colour describes health rather than the metric, each gauge is labelled with its metric name and an icon. On My Sites the band's status word is also printed under the ring, so the result does not depend on colour alone. Screen readers announce the metric, its value and its status.

Scanned, Not Scanned and Failed

Performance, SEO and Agentic Readiness are optional, so a missing score is normal and is never shown as a zero. Three states are distinguished:

State	How it looks	What it means
Scanned	The score, in its colour band	The metric was collected and this is the result
Not scanned	A dash (-) in a plain light-grey ring, labelled Not Scanned	Quality metrics were not enabled for this scan, or the run predates them. Nothing is wrong
Scan failed	A warning symbol in a red ring, with no number, labelled Scan Failed	The audit was attempted but did not complete for this page or run

A score of 0 is treated as not scanned rather than as a failing grade, and looks identical to it. None of these metrics returns a genuine 0 for a page that was really measured, so a zero means "not scored yet" - showing it as a red zero would report a problem that does not exist.

These states render identically for accessibility and for the three quality metrics, so "no result" always looks the same wherever you meet it.

In the per-page table on Scan Results, the same three states appear in the Status column as Scanned, Not scanned and Failed.

Desktop and Mobile

Quality metrics are collected separately for a desktop and a mobile rendering of each page, exactly as accessibility results are. The Desktop / Mobile toggle sits next to the metric tabs and applies to all four of them, so switching device changes the Performance, SEO and Agentic Readiness results as well.

Mobile scores are frequently lower than desktop scores for the same page - a mobile audit assumes a slower device and a slower connection. Compare mobile against mobile over time rather than against desktop.

The gauges on My Sites are single figures that combine both devices, because that screen has no device toggle.

Performance

The Performance tab reports an overall score and the five underlying measurements:

Measurement	What it tells you
LCP (Largest Contentful Paint)	How long until the main content of the page is visible
CLS (Cumulative Layout Shift)	How much the page jumps around while it loads
TBT (Total Blocking Time)	How long the page is unable to respond to clicks and typing
FCP (First Contentful Paint)	How long until anything at all appears
Speed Index	How quickly the visible part of the page fills in

Times are shown in milliseconds; CLS is a ratio with no unit. A dash means the value is not available for this page or device.

How to read a Performance score

A How to read this score note sits under the Performance gauge whenever a score is present. Performance is not a fixed property of your site - it depends on the device and connection of the person opening the page, so the same page can score high on a fast laptop and much lower on an older phone.

QualiBooth deliberately measures on a low-end device profile, with a throttled CPU and network. That is the slow end of what real visitors use, so the score is close to a worst case: if it looks good under these conditions, the page will perform at least as well for most of your visitors. Use the Desktop / Mobile toggle to compare both profiles.

Occasionally an audit runs on a scanner worker that was itself overloaded at the time. When that happens, a note above the findings says so and reports the worker's performance index, because the timing metrics understate the page rather than reflecting a problem with your site. Re-run the scan for a reliable figure.

Performance findings

On a single page's details, the measurements are followed by the individual findings behind the score - diagnostics (what is slowing the page down) and insights (what could be saved by fixing it). Findings that quantify a saving state it in the Value column, for example Est savings of 0.5 s, and expanding one lists the estimated saving per metric.

SEO

The SEO tab reports an overall score, and on a single page's details the individual checks behind it - for example whether the page has a meta description, a document title, descriptive link text, valid hreflang values, crawlable links and a usable robots.txt.

A page can legitimately have a score with no findings listed, when none of the checks applied to it. In that case the findings list states that there is nothing further to report.

Agentic Readiness

Agentic Readiness describes how well a page can be consumed and operated by AI agents - assistants that read a page, decide what to do and act on the user's behalf.

Two figures are always shown together, at equal prominence:

• The score (0-100)
• Checks passed, as passed / applicable

Both are shown because the score on its own can mislead: low-weight and informational checks influence it, so a page can pass most checks and still score in the middle. Treat the checks-passed figure as the primary result and the score as a summary.

Six named checks contribute:

Check	What it verifies
Accessibility tree is well-formed	The page exposes its content and controls in a structure an agent can read - the same underlying structure assistive technology uses
Cumulative layout shift is minimal	The page does not move under an agent mid-interaction, which would make it act on the wrong element
llms.txt is present and well-formed	The site publishes an llms.txt file giving agents a curated summary of what it offers
WebMCP tools registered	The page registers WebMCP tools, letting an agent call defined actions instead of guessing at the interface
WebMCP tools cover the page's forms	The registered tools cover the forms actually on the page, so no interaction is left without one
WebMCP tool schemas are valid	The registered tools describe their inputs correctly, so an agent can call them without trial and error

Checks that do not apply to a page - for example the three WebMCP checks on a page with no WebMCP integration - are listed as Not applicable. They are shown rather than hidden, so you can see what was not evaluated, and they are excluded from the checks-passed figure. They never count as failures.

Findings and Checks

On a single page's details, each of the three tabs lists the individual findings behind its score in the same table, with the same behaviour as the accessibility issues table: select a row, or its arrow, to expand it. Everything is reachable by keyboard.

An expanded finding shows:

• What the check evaluates and why it matters
• Why this page got this result, where the check is a qualitative one - most Agentic Readiness checks carry this, so you can see, for example, which form a WebMCP tool failed to cover
• Estimated savings per metric, for Performance findings that quantify one
• The resources the finding is about - the specific scripts, images, requests or page elements to fix, with their URLs, sizes (in KiB), timings and DOM selectors as applicable. Without these, a finding such as Reduce unused JavaScript would tell you something is wrong but not what to change. Where a finding has more resources than the scan stored, the table says so - for example Showing 20 of 143 resources - rather than presenting a subset as the whole list

Each row carries a status:

Status	Meaning
Pass	The check was met
Needs improvement	Partially met - worth attention, but not a failure
Fail	The check was not met
Informational	Reported for context only; it does not affect the score
Not applicable	The check does not apply to this page, and is excluded from any pass/fail count

Partial Coverage in a Run

Within one scan run, some pages may have quality metrics while others do not - a page can fail its audit, or be added to the configuration after earlier runs. A run's overall figures are calculated only from the pages that actually have data for that metric; pages without data are never counted as zero.

When a run's coverage is partial, the overall statistics say so, for example Based on 42 of 50 scanned pages. If the note is absent, every scanned page contributed.

Agentic Readiness is the exception to averaging: its checks-passed figure is a total across contributing pages, not an average.

Availability

Quality metrics are an optional part of a scan configuration, and are collected only for runs where they were enabled. This means:

• Runs completed before quality metrics were available show Not scanned on all three tabs. Existing results are never recalculated - re-run the configuration to collect the new metrics.
• One configuration for a site can collect quality metrics while another does not, so a site's gauges reflect its most recent completed run.
• Enabling quality metrics makes a run take longer, because each page is audited a second time, once per device.
• Accessibility results, accessibility scores and compliance reporting are completely unaffected by these metrics.

Related Pages

• Scan Results - reviewing a whole run
• URL Scan Details - reviewing a single page
• Scan History - how a metric has moved across runs
• My Sites - the gauges on each site card
• Accessibility Scoring System - how accessibility scores, which are separate from these metrics, are calculated