How we score: no black box

Start at 100, deduct for real issues

Every site starts at 100. We score 69 checks across 7 categories, all measured directly by the scan. The check list also links 11 practice guides: guides to engineering practices a crawler cannot see, such as keeping a staging environment, and the score does not count them. Each failed check deducts a fixed number of points by severity (with a cap per category so no single area can sink the whole score):

One question before your score

Before the score, we ask one thing: does SEO matter to you? Answer no and the SEO category shows as Skipped and keeps its full points, so a site that does not need search traffic is not marked down for it. How you build and run the site (staging, monitoring, how often you deploy) no longer changes the score: it reflects only what the scan measured.

7 categories

What we request, and the two exceptions

The scan reads what your site's own page already sends any visitor: the document, its scripts, and the requests your browser makes while rendering it. Beyond that it requests exactly two well-known paths, both named below, and nothing else. There is no directory guessing and no hunting for files you did not publish: no /admin, no /.env, no backup or dump filenames. That stays out of scope for every free scan.

The first is the redirect probe. To check whether your site redirects http:// to https://, we make one extra request to the plain-HTTP version of your site's bare address (http://yourdomain/), not the specific page you asked us to scan, and the same request regardless of which page that was. That's the redirect configuration your server already advertises to every visitor who types your bare domain, and every security scanner reads it the same way. If your server doesn't answer on port 80 at all, we report that check as "not determined" rather than guess. We never turn silence into a failing grade.

The second is /robots.txt. Whether a page can appear in search results is decided in three places, and a robots meta tag and an X-Robots-Tag header are only two of them. Reading the first two and reporting a page as indexable while a Disallow rule blocks it would be a confident answer to a question we had only partly asked. So we fetch it, at the one address every crawler fetches it from, and treat the most restrictive of the three as the answer. If it times out, refuses, or comes back as something we cannot parse, that check reports as not determined too, on the same principle as the redirect above.

What has changed

A method you cannot audit is not a method. When a change alters what a scan can determine, it is recorded here with the date and with the direction it moves a score.

1. Only the site is scored, not your process answers

   2026-10-22 ruleset v16

   Before the score we now ask one question: whether SEO matters to you. Your answers about staging, monitoring, dependency scanning, Search Console and the other team practices no longer change the score, so it reflects only what the scan measured on the site.

   • Some scores rise The fixed deductions for practice answers (no staging environment, no monitoring, no dependency scanning, no Search Console and the rest) are gone, so a site that lost points for an answer scores higher.

2. A whole-site scan is scored once per check

   2026-10-20 ruleset v15

   A scan of several pages reaches the score as one result per check across all of them. A single-page scan scores exactly as before.

   • Some scores fall In a whole-site scan, a check fails for the site when it fails on any scanned page, at the worst severity found, so a problem on one inner page now counts.

3. New findings, and one problem counts once

   2026-10-20 ruleset v14

   The scan finds more real problems and stops counting the same problem twice. Scoring itself is unchanged.

   • Some scores rise When the accessibility engine ran, it alone reports image alt text, the page language and heading order, so one problem is one finding instead of two.
   • Some scores fall New findings: framework hydration warnings, declared URLs on another host, duplicate or certificate-failing www and bare-domain copies, hreflang without x-default, and a home page that copies /en/. Content-hashed files must be cached for a year as immutable, and content revealed on scroll is now tested for accessibility.

4. Security advice fits the site

   2026-10-20 ruleset v13

   Security findings now take the site into account, so advice that does not apply to it costs less or nothing. Scoring itself is unchanged.

   • Some scores rise A missing cookie flag is major only on a site with a login. A short preference cookie is not asked for HttpOnly, and under HSTS its missing Secure flag is a note. A report-only CSP is told to enforce only when its reports are collected and it allows no unsafe script source.

5. Technology and session cookies need real evidence

   2026-10-19 ruleset v12

   A technology or a session cookie is only named on evidence from the site itself. Scoring itself is unchanged.

   • Some scores rise A technology is named only from a technical signal (a file or API path, a header, a cookie, the generator tag or how the markup is built), never from the words on the page. A cookie is called session-like only on a site with a login, when no script wrote it.

6. Only the site's own code is scored

   2026-10-19 ruleset v11

   Problems that come from another company's code are listed as vendor notes and no longer cost the site points. Scoring itself is unchanged.

   • Some scores rise Requests, scripts and accessibility issues inside frames from other sites, libraries a vendor's script loaded, and cookies a vendor's script wrote are vendor notes, never scored. The site's own backend on a platform subdomain is not counted as third-party, and cookies written by the page's scripts are not asked for HttpOnly.

7. A slow load no longer raises the accessibility score

   2026-10-16 ruleset v10

   A page too slow to test lost a fixed 7 accessibility points, fewer than the real problems the same page showed whenever it was tested, so an unchanged site scored higher on its slowest day. The accessibility test now gets a second, longer try, and a page still too slow to test reuses its most recent real result. Scoring itself is unchanged.

   • Scores move both ways The accessibility test retries with a 10-second wait instead of 5, and now also runs on a page that loads in 10 to 20 seconds. When it finishes, the page is scored on what it found, like any other scan.
   • Some scores fall When a page is still too slow to test, its accessibility is your organization's most recent real result for that site from the last 30 days, scored the same way and labelled with the date of that scan. The fixed 7-point loss applies only when there is no earlier result.

8. Load time costs points gradually

   2026-10-16 ruleset v9

   A slow load used to cost 2 points up to 5 seconds and 5 points past it, so the same site measured at 4.8 and then 7.2 seconds minutes apart moved its Performance score by 15. Load time now costs one point for each started 1.5 seconds past 2.5 seconds, up to 5 points, so a rescan moves only as much as the load time really changed.

   • Some scores rise A page that loads in 2.5 to 4 seconds now loses 1 point for load time instead of 2, and one that loads in 5 to 8.5 seconds loses 2 to 4 points instead of 5. Pages that load in under 2.5 seconds, in 4 to 5 seconds, or after 8.5 seconds score as before.

9. Accessibility is tested once the page has loaded

   2026-10-15 ruleset v8

   The accessibility engine now waits for the page to finish loading before it runs. A scan where our own engine failed used to read accessibility as perfect; it is now not scored at all, and the next scan tries again. Pages that load in time score exactly as before.

   • Some scores fall A page that takes more than 10 seconds to load is marked too slow to test and loses 7 accessibility points. A page that has not loaded after 20 seconds is marked as unreachable and loses all of its accessibility points.
   • Some scores fall When one of our own checking engines fails twice on a scan, that scan is not scored and you are asked to try again, instead of the missing part counting as a pass. Rescans of the same site no longer jump when our accessibility engine times out.

10. Indexability is read from all three sources

    2026-07-29 ruleset v6

    Whether a page can appear in search results is decided in three places, and we were reading two of them. This closes the last check that could report a pass over something it had not established. The ruleset is unchanged: what moved is what the scan looks at, not how a finding is scored.

    • Some scores fall The scan now fetches /robots.txt and honours a Disallow rule that covers the scanned page, alongside the robots meta tag and the X-Robots-Tag header, with the most restrictive of the three deciding. A site blocking the page in robots.txt was previously reported as indexable, and our own guidance already told owners we checked that file. This is a second well-known path the scan requests, and What we request above now names both.
    • No score change When robots.txt times out, refuses, or comes back as something we cannot parse, the check reports as not determined rather than assuming the file permits everything. A missing file is different and still passes, because no robots.txt disallows nothing.

11. Accuracy fixes across the scanner

    2026-07-29 ruleset v6

    These changed what the scan can determine and how correctly it reads a page. None of them changed how a finding is scored: the ruleset is still v6 and the arithmetic is identical. For the sites described below, a score from before this date and one from after are not strictly comparable, which is the reason this entry exists.

    • No score change A check that could not determine anything no longer reports a pass. Checks across security, performance, accessibility and the HTTP to HTTPS redirect probe can now report needing review instead. A page whose asset sizes never arrived is no longer called light, and an accessibility engine that failed to run is no longer indistinguishable from a clean result.
    • No score change A scan of a site not served over HTTPS no longer reports HSTS as enabled. The header cannot apply without TLS, so the check is set aside rather than passed.
    • Some scores fall A noindex directive is now found whatever order its attributes are written in, in every robots meta tag on the page rather than only the first, in the X-Robots-Tag response header, and in the content="none" form that means the same thing. Sites that were quietly deindexing themselves were previously reported as indexable.
    • Scores move both ways Server software disclosure is judged on what the header value actually says rather than on whether it contains a digit. Edge headers such as ECS (sjc/4E44) no longer count as a version, and an X-Powered-By header now counts as a disclosure even without a version number.
    • Some scores rise Viewport, canonical, Open Graph, favicon and lang declarations are now recognised whatever order, spacing or quoting their attributes use. Pages that were correct and were being marked as missing these tags now pass.
    • Some scores fall Requests that never received a response, from a DNS failure, a refused connection or a dropped certificate, are now counted. They were previously invisible to the failed-requests check, which reported no failures.