How Website Scorer calculates a result

The scoring model

Website Scorer evaluates one submitted public page and a small set of essential resources. Individual checks receive a pass, warning or fail result. A pass contributes full points, a warning contributes partial points and a fail contributes no points for that check. Category scores are normalised to 100 before the overall weighting is applied.

Data sources

Direct public-page inspection

The service retrieves the submitted page using a limited server-side HTTP request. It reads the final status, response headers and up to a bounded amount of public HTML. It does not log in, submit forms, execute attacks or crawl private network addresses.

AMP detection

The AMP result is a direct YES or NO signal. YES means that the retrieved HTML declares the AMP document attribute and loads the AMP runtime. It is a detection result, not a certificate that every AMP validation rule passes, and it does not add or remove points from the Website Score.

AI visibility / llms.txt

When the Poland lab worker runs the audit, Website Scorer also checks whether the site publishes /llms.txt at the domain root. llms.txt is an optional emerging convention that can help AI tools understand key public pages.

The llms.txt checker reads the file as Markdown / plain text, not as HTML. It checks for a main Markdown title using #, optional summary text using blockquote syntax (>), Markdown sections using ##, Markdown links and a limited sample of linked URLs.

Missing llms.txt remains an informational signal only. It is not a scored SEO failure and does not replace robots.txt, sitemap.xml, structured data or normal SEO. Website Scorer does not claim that llms.txt improves Google rankings.

Google PageSpeed Insights

When the external service is available, Website Scorer requests separate mobile and desktop Lighthouse assessments for performance, accessibility, best practices and SEO. Mobile data remains the primary PageSpeed input to the combined Website Score when it is available, while both device profiles appear in the report. If PageSpeed is unavailable or rate-limited, the report remains available and uses the local fallback checks instead.

Lighthouse Scoring Calculator

Each available Mobile and Desktop lab report links to Google's official Lighthouse Scoring Calculator with the measured FCP, LCP, TBT, CLS, Speed Index, TTI when available, device profile and Lighthouse version prefilled. The calculator explores how those inputs affect the Performance score; it does not run a new website measurement.

Chrome UX Report

Recent real-user metrics are requested separately from the dedicated Chrome UX Report API at origin level for phone and desktop visitors. CrUX represents an aggregated rolling 28-day dataset and is available only when Google has enough eligible measurements. A missing CrUX record is not an audit failure and does not prevent the Lighthouse or local checks from being shown.

Essential site resources

The audit may request the origin's robots.txt and sitemap.xml and may check the HTTP version of the domain to assess redirection to HTTPS. The service does not crawl an entire website.

One report instead of several separate tools

Website Scorer combines several common website checks into one report. A single audit can show Lighthouse lab results, network waterfall timing, resource weight, SEO basics, AMP detection, Open Graph preview, robots.txt, sitemap.xml, structured data, security headers, CMS login exposure signals, llms.txt readiness and conversion readiness checks.

The goal is to give a practical first technical view without requiring the user to open separate tools for speed testing, waterfall analysis, AMP detection, social preview checks, security headers, robots.txt, sitemap.xml and AI visibility signals.

Full Network Waterfall

Website Scorer captures a full network waterfall for mobile and desktop lab tests when the Poland worker is available. The waterfall is built from Chromium network events and shows how the browser loads the tested page over time.

Each request can include its resource type, HTTP status, first-party or third-party classification, transfer size, start time, total duration, DNS timing, TCP timing, TLS timing, request phase, TTFB / waiting time and download phase when those values are available.

The waterfall is designed to show the loading sequence behind the score. It helps identify slow server responses, render-blocking files, large images, delayed fonts, third-party scripts, failed requests and resources that increase load time.

In the report, click a file name in the waterfall to open the full URL.

Resource weight, slowdown opportunities and waterfall timing

Website Scorer separates three related but different performance views.

• Page Load Summary groups total requests and transfer size by resource type.
• Heaviest Resources lists the largest files by transfer size. A large file is not always the slowest or most blocking file.
• Largest Slowdown Opportunities highlights Lighthouse-estimated improvements such as render-blocking requests, unused JavaScript, image delivery and duplicated JavaScript.
• Full Network Waterfall shows request order and timing on a browser loading timeline.

Informational signals

Some report items are shown to help interpretation without necessarily reducing the Website Score. AMP detection, llms.txt readiness, sample link checks, missing CrUX data and some optional metadata signals may be informational depending on the context.

A missing optional convention does not automatically mean the website is defective. The report should be read as a prioritised technical screening, not as a certification.

Safe public testing

Website Scorer only performs safe checks against public pages and public metadata. It does not log in, submit credentials, brute force forms, bypass access controls, exploit vulnerabilities or test private authenticated areas.

CMS login panel checks and Java app login panel checks are limited to safe public exposure detection. They indicate whether common login surfaces appear publicly reachable; they do not prove whether a system is vulnerable.

Score bands

• 90-100 - Excellent: strong automated foundations with relatively small remaining improvements.
• 75-89 - Strong: a solid website with identifiable opportunities.
• 60-74 - Needs work: several material issues should be prioritised.
• 40-59 - Weak: important technical or user-experience foundations are missing.
• 0-39 - Critical: major problems limit confidence in the page.

Scores are decision aids, not certifications. A high automated score does not prove legal compliance, security, search rankings, accessibility conformance or commercial performance.

Known limitations

• The audit focuses on one public page, not every route or user journey.
• JavaScript-rendered content may not appear in the server-retrieved HTML.
• Geography, hosting load and third-party availability can affect timing data.
• Automated accessibility checks cannot replace testing by people, assistive technologies and experts.
• Security checks cover visible transport and headers only; no vulnerability exploitation is attempted.
• Content and conversion checks indicate the presence of common elements, not their strategic quality.