How we scan

Everything here is checkable. This page states what the scanner fetches, what it measures, how the score is assembled, and — the part most tools leave out — what it refuses to claim.

The process, step by step

1. Resolve and reach the domain We normalise the address, resolve it in public DNS and request the home page over HTTPS with an honest user agent. If the site is unreachable, the scan says so rather than scoring around it — availability is the heaviest single check in the hosting pillar.

2. Discover a representative sample From the sitemap and internal links we select a bounded sample of sub-pages. Fetch budgets are capped, so a large site is sampled rather than crawled exhaustively, and the report distinguishes sampled evidence from a complete inventory.

3. Collect the public record Response headers, the TLS certificate, the served HTML, robots.txt, the sitemap, and public DNS records for hosting and email. Where configured and available we add external measurements such as PageSpeed, always labelled with their source.

4. Apply the check registry Each check has a key, a weight, a severity, a threshold table and a written explanation, all stored in the engine registry and versioned. The registry is what the report cites, so a score change can always be traced to either your site or a named engine version.

5. Assemble and order the findings Pillar scores roll up into one figure by weight. Findings are then ordered by the effort each fix takes — quick configuration changes separated from work that touches architecture — rather than by severity alone.

How the score is calculated

Each check produces a value between 0 and 100 against published thresholds. Checks roll up into their pillar by weight, and pillars roll up into the final score by weight. Nothing in that chain is a judgement call, and the same input always produces the same output.

Conditional checks are skipped rather than failed. A domain that sends no email is not penalised for having no DKIM key; a business with no physical location does not lose points on local SEO. A skipped check is reported as skipped, not silently counted as zero.

The registry is versioned. When a check or weight changes, the engine version changes with it, so a difference between two scans can be attributed to your website or to our method — and not confused for the other.

The eight pillars and their weights

Weights below are read live from the scoring registry, so they match the version that produced your report. A ninth pillar, local SEO, is conditional and excluded from the score for non-local businesses.

SEO — On-page optimisation and indexability: titles, descriptions, headings, canonical tags, sitemap, robots rules and internal linking.

Performance — Speed and Core Web Vitals: TTFB, page weight, compression, caching and render-blocking resources.

Security — Certificate and TLS, the six security headers, mixed content, HSTS, cookie flags and content security policy quality.

Accessibility — Alt attributes, form labels, landmarks, language declaration and heading order, plus axe-core violations where available.

Trust and content — Credibility signals: company identity, contact details, social profiles, reviews, authorship and content depth.

Hosting and DNS — Infrastructure: availability, DNS correctness, nameserver and address redundancy, CDN, DNSSEC, CAA and HTTP/3.

Email — Email authentication: SPF, DKIM, DMARC, MX, plus MTA-STS, TLS-RPT and BIMI.

AI readiness — Whether AI assistants can read the page and are permitted to: robots policy, extractability, content in raw HTML, structured data and attribution.

Local SEO — Conditional. Location signals for businesses with a physical address: NAP, opening hours, map and LocalBusiness schema. Skipped, and excluded from the score, for non-local businesses.

What this method cannot do

Static fetching cannot establish behaviour that only appears after JavaScript runs. Where a renderer is configured we compare raw and rendered HTML; where it is not, that content is reported as unmeasured rather than assumed absent.

One scan is one moment. We do not measure uptime, and response times vary with load. If you suspect variance, scan again at a different hour.

We do not see inside your application. The security pillar grades what a browser can observe and enforce on first contact. It is a hardening assessment, not a penetration test.

We do not measure rankings or AI citations. Both are personalised and unobservable from an anonymous external scan. We measure the conditions that precede them and say nothing about the outcome.

The full check list

Every check in the engine — its key, weight, threshold table, explanation and remediation advice — is published on the Polish methodology page. Those entries are written in Polish and have not been translated; the keys and weights are the same ones used on your report in either language. Open the full Polish check registry