How ActiScore scores a website

Rubric version: v4 · Last updated 2026-10-06

This document exists so that any score ActiScore produces can be explained, challenged and independently verified. If a prospect disputes a grade, this is the page to hand them.

It is deliberately explicit about which checks rest on published standards, which rest on industry convention, and which are ActiScore's own editorial judgment. Conflating those three is how scoring tools lose credibility.

1. How a score is produced

fetch page  →  extract signals  →  apply deduction table  →  weight categories  →  grade
                                   (deterministic)           (deterministic)

1. The target page is fetched server-side once, following up to 5 redirects, over ports 80/443 only, capped at 5 MB, HTML content types only.
2. Signals are extracted from the response body and headers — presence, counts and lengths of well-known tags and headers. No JavaScript is executed and the page is not rendered.
3. Each category starts at 100. Every failed check subtracts a fixed deduction. Category scores are floored at 0.
4. The composite is a weighted mean of the ten category scores (weights in section 3), rounded.
5. Letter grades are assigned from fixed score bands.

Scores are pure arithmetic. A language model writes the explanatory text and the remediation advice, and is given the already-final scores with instructions that it may not change or reinterpret them. It has no path to alter a number.

2. Reproducibility

Verified: 25 real domains × 200 iterations = 5,000 scoring runs produced byte-identical output every time. Scoring is also insensitive to the key order of the input object. There is no use of the clock, randomness, locale formatting or environment state anywhere in the scoring path.

The honest caveat. That guarantee is "same signals → same score." It is not "same website next week → same score," because the website controls what it returns. A CDN node serving a different Cache-Control, an A/B test, geographic routing, bot detection or personalisation can all change the signals legitimately. In practice two independent live captures of all 25 baseline domains produced identical scores — encouraging, but that is two samples, not a study.

Every scan is stored with its full result and its rubric version, so any past score can be reconstructed exactly and shown to have been computed correctly.

3. Category weights

These weights are ActiScore's editorial judgment, not an industry standard. No standards body publishes a weighting for website quality. Security leads because ActiScore is used by managed service providers whose value to a client is security posture first. A marketing agency would reasonably weight this differently, and the weights live in one constant so they can be changed.

v4 added Content & UX and Trust and took their weight proportionally from the other eight. A report scored from signals recorded before v4 has neither new category; it is not given a free 100 in them — they are left out and the other weights re-normalised.

Before v2 the composite was an unweighted mean of six categories. That let a nearly empty page score 58 (a D) by riding a fast, unremarkable Performance score and a Best Practices score it could not fail.

4. Grade bands

These bands are arbitrary — they mirror US academic grading because it is instantly legible, not because it is derived from data.

They are also demonstrably harsh. Across the 24 baseline sites captured on 2026-10-06, including Stripe, GitHub, Cloudflare and Mozilla, exactly one reached an A (securafy.com, run by Securafy, which uses ActiScore every day). Stripe scores 80. This is a known open question, recorded rather than hidden.

5. The checks

104 checks across ten categories. Each check lists the maximum deduction and its basis:

• Standard — a published specification or documented platform requirement.
• Convention — widely-followed industry practice with no published authority.
• Judgment — ActiScore's own choice.

Deduction magnitudes are judgment in every case, even where the check itself is a standard. A check marked v4 was added on 2026-10-06; on a scan whose signals were recorded before then it reads not checked and deducts nothing.

Security — 24% of composite

Scored two ways, and the report always says which. When DNS and TLS have been measured for a domain the full rubric below applies and the category is marked measured. On a cold first scan — before the background lookup has landed — only the response headers and the page are available, the header-only weights apply, and the category is marked inferred with a note saying so. A settled report is always measured, because the settle pass performs the lookups itself.

Full rubric (measured). Deductions total exactly 100.

Header-only rubric (inferred). HTTPS 30, CSP 19, HSTS 13, X-Frame-Options 8, X-Content-Type-Options 7, Referrer-Policy 5, Permissions-Policy 5, plus the four v4 page checks at the weights above — 100 in total.

A check that could not be completed never deducts. An unreachable resolver is reported as not checked — it is not evidence about the domain. This is distinguished from an authoritative "no such record", which is a real finding.

Limitations. These are presence and configuration checks, not a security assessment. A site can score 100 here and still be vulnerable — this does not test for injection, authentication flaws, open ports or anything requiring active probing.

SEO — 15% of composite

Limitations. The character-length windows are the softest numbers in the whole rubric. Google has never published a title or description length limit; these ranges come from observed search-result truncation.

Performance — 14% of composite

Measured whenever PageSpeed data is available; every report states which path produced the score.

#### Measured path — real Core Web Vitals

Thresholds are Google's published Core Web Vitals bands, not ours:

A metric absent from the payload is skipped rather than penalised.

#### Inferred path — static fallback

The report labels an inferred score "estimated from page structure", so an estimate is never presented as a measurement.

Mobile Usability — 10% of composite

Deductions total 100.

Limitations. Static analysis only — tap-target sizing and horizontal overflow need a rendered page and are not assessed.

Local SEO — 8% of composite

AEO (Answer Engine Optimisation) — 8% of composite

This category measures readiness — whether a page carries the markup and content patterns answer engines are known to consume. It does not measure whether the brand appears in AI answers; that is measured separately, by asking the assistants themselves — see section 6.

Accessibility — 8% of composite

Checked from markup only. Colour contrast, focus visibility and screen-reader order need a rendered page and are not assessed, and the report says so.

Content & UX — 6% of composite (v4)

Whether a visitor finds enough to read, a way around, and an obvious next step. Read from markup, so it finds what is missing, not whether the writing is good. Deductions total 100, and every threshold is judgment.

Trust — 4% of composite (v4)

What a first-time visitor looks for before handing over a phone number or a card. Read from links and copy, so it finds whether a signal exists, not how convincing it is. Deductions total 100.

Long pages keep these signals in the footer, so the last 256 KB of a page is read for them as well as the first 512 KB.

Content & UX and Trust read the page's HTML as served. A page that builds itself in the browser can carry almost no text in that HTML; when it has under 50 words both categories say so on the report, because their scores may understate it.

Best Practices — 3% of composite

6. AI visibility and the Deep AI Audit

Whether AI assistants actually name a business is measured by asking them, never estimated from the page. It is reported beside the score, not folded into it: a grade moves only when the website changes, and assistants' answers move on their own.

On every report. Each configured assistant (ChatGPT, Claude, Gemini and Perplexity where the keys exist) is asked five buyer questions for the business's industry and location, each assistant separately. The report shows which answers named the business and which competitors were named instead. Up to eight of those competitors are then graded with this same rubric and shown side by side. Results are kept for seven days, so repeat reports in that window show the same answers.

The Deep AI Audit goes further, on request:

• Twenty-five questions: seventeen that never name the business, the way a buyer actually asks ("who should I call for…"), and eight that do, to see what the assistants say about it.
• Up to eight assistants, each asked directly through its own service: ChatGPT, Claude, Gemini and Perplexity with live web search; Grok and DeepSeek from what the model knows, without search, so they cite no sources by design; and Google AI Overviews and AI Mode, read from Google's real results page through DataForSEO, never imitated with another model.
• For every answer it records whether the business was named, its position in the answer, the tone when named (positive, neutral or negative), the competitors named, and the sources cited.
• Results stay per assistant. There is no blended visibility score: "named by Perplexity but not by Gemini" is the finding, and an average would hide it.
• A search where Google shows no AI answer — common for local searches, which get a map instead — is left out of that surface's rate, not counted as a miss. A failed request is retried, and one that still fails is shown as unrecorded.

Limitations. Assistants' answers vary from one asking to the next, so a single audit is a sample, not a permanent ranking; comparing audits over time is more reliable than any one result. Whether an answer names the business is decided by a fixed brand-name matcher, not by a model, so the headline count cannot drift with a model's judgment; a business whose name is a common word can still be matched where it was not meant. The order of the businesses named and the tone are read by a language model, which can misjudge an ambiguous answer. Copilot is not measured: it answers from OpenAI's models and offers no API that returns what its users see.

7. Outreach threshold

A composite below 70 sets a triggerOutreach flag, used to mark a scanned site as worth a sales conversation.

This is a sales heuristic, not a quality judgment. It was tuned against the 25-domain baseline: the previous threshold of 80 fired on 72% of real sites including Cloudflare and Mozilla, which makes the signal useless and the sender look uninformed. At 70 it fires on 32%.

8. What ActiScore does not do

Stated plainly, because the absences matter as much as the checks:

• Does not execute JavaScript or render the page. A single-page app that builds its head tags client-side will score poorly on signals that are present after hydration.
• Does not run its own speed test. Performance uses Google's Lighthouse measurements; a first scan without them is estimated and labelled as such.
• Does not score more than one page. The headline is always the homepage's score. The multi-page crawl on paid plans shows which issues repeat across interior pages without changing that number.
• Does not perform a penetration test. Security reads response headers, DNS mail-authentication records and the TLS certificate — no active probing, port scanning, vulnerability testing or credential checks.
• Does not blend AI visibility into the score. It is measured and reported separately — see section 6.
• Does not judge content quality, design, or commercial effectiveness.

9. Change control

The rubric is changed in place rather than versioned per tenant, because Securafy's public grader and every tenant embed share one scoring core — a fix should reach both at once.

To make that safe:

• 25 real domains have their extracted signals and resulting scores frozen as a committed baseline, spanning grades A through F and including Securafy's own sites and real prospect domains.
• An automated gate fails the build on any scoring change, printing a per-domain, per-category old-to-new table.
• A rubric change is reviewed against that table before deploy, and any letter-grade move on a live prospect domain is flagged individually.
• Every stored scan records the rubric version that produced it, and the history view refuses to silently compare scores computed under different versions.

The v1→v2 delta table is recorded in docs/plans/2026-08-15-rubric-change-delta.txt, and v3→v4 in docs/plans/2026-10-06-rubric-v4-delta.txt: on identical input the composite moved a mean of 0.0 points, no site changed letter grade, and the largest single move was 5 points.

10. Open questions

Tracked honestly rather than quietly:

1. Grade A is close to unreachable — 1 of 24 real sites in the October 2026 capture, and that one is a site tuned against this rubric. The A boundary may need lowering or the deduction tables loosening. Still open.
2. Length windows for title and meta description rest on the softest evidence in the rubric and deserve a review against current search-result behaviour.
3. AEO should be renamed to reflect that it measures readiness, not visibility. Real visibility is now measured separately (section 6), which makes the distinction easier to blur and the rename more pressing.

Closed in v3: Performance moved from inference to measurement; the favicon check left Performance and the cookie-banner check left Security.