Methodology
One number for the condition beneath your interface.
Your website can function while carrying outdated architecture, exposed headers, heavy pages and no readiness for AI-driven discovery. The score makes that visible and comparable over time. Here is exactly how it is built.
What does the assessment read from your site?
It fetches your homepage and follows up to four redirects. It records the response status, headers, content type and timing. Then it parses the markup for titles, descriptions, canonicals, viewport and language declarations, heading counts, JSON-LD blocks, script and image counts, lazy loading and semantic elements. That is the whole first pass (nothing hidden in it).
From the homepage, it picks up to eight more public pages on the same domain, chosen to cover different templates, and reads their headings and main text. Every request identifies itself with a named user agent. But it stays on the public side of the line. No login, no form submission, no private address.
How is each pillar scored?
Each of the eight pillars gets a score from 0 to 100. A model reads the measurements and the sampled text against a fixed schema and must return one finding per pillar, the evidence behind it and one recommendation. Prose from your pages can inform a finding. It can never raise or lower a number on its own, because only measured evidence moves the score.
The result shows the evidence under every pillar. So you can check it against your own pages and challenge it where it is wrong.
How do the weights turn eight numbers into one?
Your score is the weighted sum of the eight pillar scores, divided by 100. Operational health carries 16%. Architecture and performance carry 15% each, security and search 12% each, and schema, AI readiness and editorial experience 10% each. The weights are fixed and published here, so two readings months apart are comparable. Nothing shifts underneath you (no quiet reweighting).
A single very weak pillar can pull a strong site below 80. That is intended. An unmaintained dependency or a missing security header is a condition of the whole site, and averaging doesn't turn it into a detail.
What does each pillar look at?
Architecture
15%Rendering model, dependency age, and how tightly content is coupled to presentation. And then the generator and framework signals, which point either to a maintained stack or to one that quietly stopped getting attention.
Performance
15%What your pages ship: script and image weight, lazy loading, module scripts, render pattern and response time. Field Core Web Vitals can't be read from outside (no tool can fake that), and the report says so plainly.
Security
12%HTTPS, Strict-Transport-Security, Content-Security-Policy and the other response headers. Markup that exposes versions or admin paths counts too. It hands visitors a map they never needed, and some of them will use it.
Search
12%Titles, descriptions, canonicals, robots directives and heading structure. Then come the internal links between your sampled pages, which show how the site actually hangs together (or doesn't).
Schema
10%Structured data: how much JSON-LD is present, whether it parses, and whether the types match the page.
AI readiness
10%Do you allow AI crawlers? Are your passages clear enough to quote? Does an llms.txt or equivalent index exist? But the real question underneath all three is whether machines can find you at all.
Editorial experience
10%Reading order, heading hierarchy, language and viewport declarations, and how the sampled pages hold together as a set.
Operational health
16%Caching headers, redirects, response consistency across pages and the signals of a site that is maintained rather than left.
What do the four bands mean for you?
- 80 to 100
- Good standing. Hold the standard. Keep measuring.
- 60 to 79
- Constrained. Specific pillars need work. The platform may not.
- 40 to 59
- At risk. Cost and risk outrun value. Scope a structured response.
- 0 to 39
- Legacy condition. Constraints exceed value. Treat the next decision as urgent.
Select or focus a pillar to read this example
Questions, answered.
01Why is there no accessibility pillar?
No single part of a site produces conformance. So accessibility is read inside architecture, editorial experience and operational health (not as its own score), rather than collapsed into one number a team can treat as a finish line. Accessibility work needs its own review, and a score can't stand in for it.
02Can the score replace a professional audit?
No. It is a baseline of your public surface. A commissioned review adds authenticated systems, field data, dependency analysis and interviews. Use the score to decide whether that deeper work is worth scoping, and then to measure the result afterwards.
03Why might two runs give slightly different scores?
The sampled pages can differ between runs, and the model's read of evidence is directional. Big movements mean your site changed. Small ones usually mean the sample did. So compare pillars, not only the total.
04Does a low score mean you must rebuild?
No. The pillar evidence tells you whether to repair, upgrade, decouple or replace. A platform is never judged by name. Only what it ships to the public right now counts, and that is the only fair test.
Free automated assessment