How PerfoMetrix scores websites
A report checks one page of a website from the outside, the way a visitor's browser would see it, and turns 193 checks into a few scores and grades. This page explains where every number comes from, what we can see from outside and what we can't.
Reading a score
Every score runs from 0 to 100 and gets a letter grade. The colour on a score ring follows the same bands: green for scores of 90 and above, amber for 60 to 89, red below 60. The letters tell B, C and D apart inside the amber band.
- F<60F: <60 (Poor)
- D60–69D: 60–69 (Needs work)
- C70–79C: 70–79 (Needs work)
- B80–89B: 80–89 (Needs work)
- A90+A: 90+ (Good)
The ticks on each ring mark 60 and 90: amber from 60, green from 90.
Next to a score you'll see one of three labels: Good (green), Needs work (amber) or Poor (red). A section that couldn't be measured shows Not measured instead of a number.
The overall score
The overall score is a weighted average of three sections: Performance, Security and SEO. The weights are:
Each section score is multiplied by its weight and the results are added up, then rounded. If a section couldn't be scored at all (for example, the performance test was unavailable), it is left out and the other weights are rescaled so they still add up to 100%. The overall score is empty only when none of the three sections could be scored.
Draft, under review Why these weights: Performance carries the most weight (40%) because it affects every visitor on every visit and is measured with real-user data where it exists. Security (35%) is close behind: one weak setting can expose visitors, but many of its checks are configuration details that don't change what a visitor sees. SEO (25%) matters for being found, and its checks are the easiest to fix.
AI Readiness, Site Profile and Malware Signs have their own scores and are shown on their own; they are not part of the overall average (see what each section measures).
Section scores
A section score is the share of its checks that pass, weighted by how much each check matters. Every check has a severity, and the severity sets its weight:
- Critical ×10
- High ×6
- Medium ×3
- Low ×1
- A check that passes earns its full weight; a partial pass (shown as "needs attention") earns half; a failure earns nothing.
- Checks we couldn't run ("could not test"), information-only checks and diagnostics that explain a metric already scored are left out, so they neither help nor hurt.
- The score is earned weight divided by possible weight, times 100, rounded to a whole number.
A worked example
Suppose a scan of example.com ran these 8 security checks (the real checks, picked by severity; one couldn't run):
| Check | Severity | Result | Weight | Earned |
|---|---|---|---|---|
| Served over HTTPS | Critical | Failed | 10 | 0 |
| HTTP redirects to HTTPS | High | Passed | 6 | 6 |
| No redirect from HTTPS to HTTP | High | Passed | 6 | 6 |
| CSP avoids 'unsafe-inline' scripts | Medium | Needs attention | 3 | 1.5 |
| HSTS covers subdomains | Low | Passed | 1 | 1 |
| HSTS preload | Low | Passed | 1 | 1 |
| CSP sets object-src and base-uri | Low | Passed | 1 | 1 |
| Referrer-Policy | Low | Could not test | — | — |
| Total | 28 | 16.5 | ||
16.5 ÷ 28 × 100 = 59, grade F. Six of seven scored checks passed, yet one critical failure pulls the section below the pass line: that is the point of the weights. One serious problem outweighs many small wins.
What each section measures
Performance (40% of the overall)
How fast the page loads and responds. Measured by Google's PageSpeed Insights, which runs Lighthouse on the page from Google's infrastructure with a simulated mobile device and network, and adds real-user Core Web Vitals from the Chrome UX Report where the page or site has enough traffic. Our section score is not the Lighthouse performance score: that score is one high-severity check among the metrics (LCP, CLS, TBT, FCP, Speed Index, TTFB), the real-user vitals, page weight, compression and HTTP version. Paid accounts also get a desktop run; it adds a desktop screenshot and check, not a different score. What it doesn't measure: how the page performs from your visitors' own locations or on logged-in pages.
Security (35% of the overall)
What a visitor's browser receives: HTTPS and the certificate, the negotiated TLS version, HSTS and the other security headers, Content Security Policy details, cookie flags, version disclosure, mixed content, known-vulnerable JavaScript libraries by name and version, security.txt, and the domain's mail and DNS records (SPF, DKIM, DMARC, DNSSEC, CAA, MTA-STS, blocklists). What it doesn't measure: anything that needs an attack to find. We never send payloads, guess paths or test logins, so a good Security score means the visible setup is sound, not that the application has no vulnerabilities.
SEO (25% of the overall)
Whether search engines can crawl, understand and present the page: status and redirects, title and description, headings, canonical and indexing tags, structured data, Open Graph and X cards, hreflang, robots.txt and the sitemap, links, images, readability, and the Lighthouse accessibility, SEO and best-practice audits. What it doesn't measure: rankings, traffic, backlinks from other sites, or pages other than the one scanned.
AI Readiness (scored separately)
How well AI crawlers and assistants can read and cite the page: crawler access by role (search, user fetchers, training), content present in the HTML rather than loaded later, schema, author and date information, quotable structure, llms.txt. It is shown with its own score and stays out of the overall.
Site Profile (scored separately)
What the site runs on and how fresh it is: detected technologies and their versions against published support dates, known vulnerabilities for those versions, domain registration and expiry, name servers, hosting location and provider, IPv6, popularity rankings. Its score reflects software freshness; the details are shown to signed-in users.
Malware Signs (scored separately)
Whether anything visible from outside suggests the site has been compromised. It has its own rules, explained next.
Malware Signs
This section asks one question: are there signs of infection visible from outside? It never claims the opposite. Signs come in three levels, and the most serious one found sets the section's ceiling.
| Level | What it means | Score ceiling |
|---|---|---|
| Blocklist listing | A third-party blocklist lists the page, one of its scripts or a frame it loads. Browsers and security products warn visitors about such sites or block them. | 5 |
| Strong sign | A pattern that rarely appears on a healthy site, such as fake "verify you are human" instructions that ask visitors to paste a command, hidden spam links, code outside the page's HTML, or spam pages in the sitemap. | 30 |
| Weak sign | Something worth a look that can have an innocent explanation: scripts from a very new domain, heavily packed inline scripts, hidden frames, live connections to unknown servers, a robots.txt that points at someone else's sitemap. | 75 |
Malware Signs: the worst sign wins
No averaging. The most serious sign found sets a ceiling:
- Blocklist listingmax 5
- Strong signmax 30
- Weak signmax 75
Each further sign at that level takes 5 more points, never below the next ceiling (weak signs stop at 31, strong signs at 6). A sign is one rule that fired, however many times.
Exception: a blocklist listing also caps the overall score at 59, which is grade F.
Two weak signs found together on the same site can count as a strong one. Only blocklist listings can ever be "confirmed": no setting can turn a pattern into a confirmed finding. The blocklist exception also reaches the overall score: a listed site's overall is capped at 59, grade F, however well its other sections do.
Inconclusive results
When the site answers our request with a bot challenge instead of the page, or with something that isn't HTML, the page-based signs are reported as "could not test", never as clear. The same happens if a blocklist couldn't be reached.
What reports show
Reports are unlisted and marked not to be indexed, but anyone with the link can open one. Every finding is shown there with cautious wording ("a sign worth checking"); what exactly each sign matched is shown only to signed-in users. Signs never appear on share images or any public listing.
What we can't see from outside
Not visible from outside: files on the server (web shells, backdoors), the database, pages behind a login, and code that only runs for some visitors. We often notice signs before blocklists do, but a clean result here isn’t a guarantee.
If your site is listed
- Open the blocklist operator's own status page for your domain to see what was found and when.
- Look for recently changed files, unknown admin users, scheduled tasks and injected scripts; restore from a clean backup if you have one.
- Update the CMS, plugins and server software, and change every password and API key.
- Request a review from the blocklist operator once the injected code is gone; a new scan here shows whether the listing has been lifted.
How a scan works
A scan fetches the page you entered plus a handful of well-known files, with at most 16 requests in total: the page and its redirects, its http:// and www/non-www variants to test redirects, robots.txt, the sitemap, security.txt, llms.txt, one random address to see how the site answers for a missing page, and the favicon and share image the page names. Requests are plain GET or HEAD, carry our documented user agent, stop after 5 MB of page and time out after 15 seconds. We don't run a browser ourselves: the page's HTML is parsed as received, and rendering comes only from Google's Lighthouse run. One TLS handshake and a set of DNS lookups complete the picture.
The scan is passive. We never submit forms, send payloads, guess paths, scan ports or download the site's scripts. A site can opt out with a robots.txt rule described on the bot page, and we refuse the scan before fetching the page.
Plans. Every plan runs the same checks. Pro accounts also get a desktop performance run, the desktop screenshot, the full link list and the PDF view; signed-in users see the Site Profile details, the AI crawler table and what each malware sign matched. Scores and issues are identical whoever runs the scan.
Data sources
Besides the site itself, a scan consults these services. Only the information noted leaves our server; we never send the report or who requested it.
- Google PageSpeed Insights (lab performance test (Lighthouse) and Chrome real-user data): sends page URL.
- Google Web Risk (browser blocklist lookup): sends page and script URLs.
- Cloudflare and Google public DNS (public DNS resolvers): sends domain name.
- RDAP registries (domain registration data (dates and registrar only)): sends domain name.
- Tranco (popularity ranking, looked up from a local copy): sends nothing.
- Open PageRank (link-authority estimate): sends domain name.
- The Green Web Foundation (green hosting directory): sends domain name.
- endoflife.date (software release and support dates): sends product name.
- WordPress.org plugin directory (plugin release data): sends product name.
- Retire.js (vulnerable JavaScript library data, kept locally): sends nothing.
- DB-IP Lite (IP location and network data, kept locally): sends nothing.
- Chrome UX Report (popularity by country, kept locally): sends nothing.
- crt.sh (certificate transparency log search): sends domain name.
- Common Crawl (open web archive index): sends domain name.
- SpamCop, PSBL, UCEPROTECT, DroneBL (DNS-based mail and web server blocklists): sends server IP.
- DNS threat feed (switched off until its terms are confirmed): sends domain name.
Limitations
- A snapshot. The report describes one page at one moment. Caches, A/B tests, geographic routing and ongoing changes can make the next scan differ.
- Lab conditions. Performance numbers come from a simulated device and network; your visitors' experience depends on their devices, connections and locations. Real-user data, where present, is the better guide.
- One page, from outside. We see what any visitor sees. Other pages, logged-in areas, server files and databases are out of scope.
- Not a security audit. A passive scan finds configuration problems, not application vulnerabilities. A good score is a sound starting point, not a certificate.
- No guarantee. Checks can be wrong, sources can be down, and a site can be compromised in ways no outside scan can see. Use the report to decide what to look at, not as a verdict.
Questions
Why is my score different from PageSpeed Insights?
PageSpeed Insights shows Lighthouse's performance score. Our Performance section uses the same Lighthouse run but scores the individual metrics, real-user vitals, page weight, compression and HTTP version by severity; the Lighthouse score itself is one check among them. The two usually move together but are not the same number.
Why did my score change between scans?
Performance varies run to run, especially on slow or busy servers. Real-user data updates over a rolling window. A data source that was down ("could not test") is left out of the score, so the same site can score differently when it comes back. The report shows signed-in users what changed since their previous scan.
What does "could not test" mean?
The check couldn't run: a source was unavailable, the site answered with a bot challenge, or the response wasn't a web page. Such checks don't count towards any score.
Does a good Security score mean the site has no vulnerabilities?
No. It means the settings visible from outside are in good shape. Vulnerabilities in the application, the server or its plugins need testing that only the site's owner can authorise.
Checks reference
All 193 checks, grouped by section. Each row names the check, its severity (which sets its weight) and why it matters. Malware signs are listed by level only.
Performance (36)
| Check | Severity | Why it matters |
|---|---|---|
| Lighthouse performance score | High | A lab score (0–100) summarizing how fast the page loads and becomes usable on a simulated device. |
| Largest Contentful Paint (LCP) | High | Time until the largest image or text block is visible. Good is 2.5 s or less. |
| Cumulative Layout Shift (CLS) | High | How much visible content jumps around while loading. Good is 0.1 or less. |
| Total Blocking Time (TBT) | Medium | Time the main thread was blocked by long tasks, delaying input. Good is 200 ms or less. |
| First Contentful Paint (FCP) | Medium | Time until the first text or image appears. Good is 1.8 s or less. |
| Speed Index | Low | How quickly the visible content is populated during load. Good is 3.4 s or less. |
| Server response time (TTFB) | Medium | How long the server took to start sending the HTML document. Good is 800 ms or less. |
| Real-user LCP (Chrome UX Report) | Medium | LCP measured on real Chrome visits over the last 28 days, when Google has enough data. |
| Real-user INP (Chrome UX Report) | Medium | Interaction to Next Paint: how quickly the page responds to real taps and clicks. Good is 200 ms or less. |
| Real-user CLS (Chrome UX Report) | Medium | Layout shift measured on real Chrome visits over the last 28 days. |
| Real-user FCP (Chrome UX Report) | Information | How long real Chrome visitors waited for the first text or image over the last 28 days. Good is 1.8 s or less. |
| Real-user TTFB (Chrome UX Report) | Information | How long real visitors waited for the server to start answering, including redirects and connection setup. Good is 0.8 s or less. |
| Whole-site real-user experience | Information | Google’s verdict on Core Web Vitals across all pages of the site, from real Chrome visits over 28 days. This is the site-level signal Search Console reports. |
| Top improvement opportunities | Low | The Lighthouse suggestions with the largest estimated savings for this page. |
| No render-blocking resources | Information | CSS and JavaScript loaded in the <head> without async/defer stop the browser from showing anything until they arrive. |
| Efficient image delivery | Information | Images that are larger than displayed, poorly compressed or not in WebP/AVIF waste bandwidth and slow down LCP. |
| Long cache lifetimes for static files | Information | Files cached only briefly are downloaded again on every visit, making repeat visits slower than they need to be. |
| Text visible while fonts load | Information | Without font-display, browsers hide text until the web font arrives, so visitors stare at a blank space. |
| LCP image found early | Information | The largest image should be in the initial HTML, not lazy-loaded, and requested with high priority, or LCP waits for it. |
| Fast HTML response | Information | The page itself must arrive quickly: compressed, without redirects and with a fast server response. |
| Little unused JavaScript | Information | JavaScript the page downloads but never runs costs bandwidth and parsing time, especially on phones. |
| Little unused CSS | Information | Large stylesheets with rules the page never uses delay rendering, because CSS blocks the first paint. |
| No legacy JavaScript for modern browsers | Information | Polyfills and transpiled code for old browsers are sent to modern ones that don’t need them. |
| No duplicated JavaScript | Information | The same library shipped in several bundles is downloaded and parsed more than once. |
| Short JavaScript execution time | Information | Time spent parsing and running scripts blocks the main thread, delaying interaction (TBT, INP). |
| Light main-thread work | Information | All work the browser does on the main thread (scripts, style, layout, painting). Too much makes the page feel sluggish. |
| Images have width and height | Information | Images without dimensions push content down when they load, causing layout shift (CLS). |
| No forced reflows | Information | Scripts that read layout (offsetHeight, getBoundingClientRect) right after changing styles force the browser to recalculate layout synchronously. |
| Minified CSS and JavaScript | Information | Unminified files carry whitespace and comments that add bytes for no benefit. |
| Reasonable page size (DOM elements) | Information | Pages with thousands of elements take longer to style and lay out, and every interaction costs more. |
| Third-party code | Information | Scripts from other companies (analytics, chat, ads, embeds) and how much main-thread time and data each adds. |
| Desktop results | Low | The same Lighthouse audit run with a desktop profile. |
| Text compression | Medium | Compressing HTML with Brotli or gzip usually cuts its transfer size by 70% or more, so pages start rendering sooner. |
| HTTP/2 or HTTP/3 | Low | HTTP/2 and HTTP/3 load many files over one connection; HTTP/1.1 queues them, which slows pages with many assets. |
| Total page weight | Medium | Everything the page downloads, from HTML to images and scripts. Heavy pages are slow on mobile networks and cost users data. |
| Estimated CO₂ per page view | Information | An estimate of the emissions of one page view from the data it transfers (Sustainable Web Design model, average grid). |
Security (52)
| Check | Severity | Why it matters |
|---|---|---|
| Served over HTTPS | Critical | HTTPS encrypts traffic so visitors’ data cannot be read or altered in transit. |
| HTTP redirects to HTTPS | High | Visitors who type the bare domain should land on the secure version automatically. |
| No redirect from HTTPS to HTTP | High | Every redirect on the way to the page should stay on HTTPS. A hop down to plain HTTP leaves the rest of the visit unencrypted, and browsers warn. |
| Certificate is trusted | Critical | Browsers block or warn on certificates that do not chain to a trusted authority. |
| Certificate expiry | High | An expired certificate takes the site offline for most visitors. |
| Certificate matches the hostname | Critical | The certificate must cover the exact hostname visitors use. |
| Modern TLS version | High | TLS 1.2 and 1.3 are current; older versions have known weaknesses. |
| HTTP Strict Transport Security | High | HSTS tells browsers to always use HTTPS, preventing downgrade attacks. max-age should be at least 180 days. |
| HSTS covers subdomains | Low | includeSubDomains extends HTTPS enforcement to every subdomain. |
| HSTS preload | Low | The preload directive allows browsers to ship your HSTS policy built in. |
| Content Security Policy | High | A CSP limits which scripts can run, the strongest defense against cross-site scripting. |
| CSP avoids 'unsafe-inline' scripts | Medium | 'unsafe-inline' lets injected inline scripts run, defeating most of the CSP. |
| CSP avoids 'unsafe-eval' | Medium | 'unsafe-eval' allows eval() and similar, a common injection sink. |
| CSP has no wildcard script sources | Medium | A * source allows scripts from any host, so the policy no longer restricts scripts. |
| CSP sets object-src and base-uri | Low | Without these, plugins and an injected <base> tag can bypass an otherwise strict policy. |
| Clickjacking protection | Medium | Prevents other sites from framing your pages to trick users into clicks. |
| X-Content-Type-Options | Medium | nosniff stops browsers from guessing content types, which can turn uploads into scripts. |
| Referrer-Policy | Low | Controls how much of your URLs leak to other sites through the Referer header. |
| Permissions-Policy | Low | Restricts powerful browser features (camera, geolocation, …) your pages and embeds can use. |
| No software version disclosure | Low | Version numbers in headers or markup help attackers pick known exploits. |
| No mixed content | High | Loading http:// resources on an https:// page breaks its security; browsers block active ones. |
| No known-vulnerable JavaScript libraries | High | Script URLs reveal library versions with published vulnerabilities (Retire.js data). |
| security.txt | Low | A /.well-known/security.txt file tells researchers how to report vulnerabilities. |
| SPF record | Medium | SPF lists the servers allowed to send email for your domain, reducing spoofing. |
| DMARC policy | Medium | DMARC tells receivers what to do with mail that fails SPF/DKIM, stopping domain spoofing. |
| CAA record | Low | CAA limits which certificate authorities may issue certificates for your domain. |
| No plain-text email addresses | Low | Addresses written in plain text or mailto: links are collected by spam bots within days of being published. |
| Subresource Integrity on CDN files | Low | Scripts and styles loaded from public CDNs can be swapped if the CDN is compromised. An integrity hash makes the browser refuse a changed file. |
| Safe CORS headers | Medium | Access-Control-Allow-Origin decides which other sites may read your responses. "*" together with credentials, or "null", is a misconfiguration attackers look for. |
| No secret keys in the page | Critical | API keys, tokens or private keys in the HTML or inline scripts can be copied by anyone who opens the page. |
| Payments in live mode | Medium | A Stripe test-mode key on the live site means checkout accepts only test cards: real customers cannot pay. |
| No error messages or debug output | High | Stack traces, SQL errors and debug headers reveal file paths, code and the database, which makes attacks much easier. |
| No default server page or directory listing | Medium | A web server’s welcome page or an "Index of /" file listing shows the site isn’t configured, or exposes files that were never meant to be browsed. |
| Forms send data encrypted | High | A password field on an HTTP page, or a form that posts to an http:// address, sends what visitors type in plain text. |
| Cross-Origin-Opener-Policy | Low | COOP keeps other windows from keeping a handle on your page, which blocks a class of cross-site leaks and popup attacks. |
| No internal details in HTML comments | Low | Developer comments left in the page can reveal internal IP addresses, server names or credentials. |
| DNSSEC enabled | Low | DNSSEC signs your DNS records, so resolvers can detect forged answers that would send visitors to an attacker’s server. |
| MTA-STS for incoming mail | Low | MTA-STS tells other mail servers to deliver to you only over verified TLS, so mail can’t be downgraded to plain text in transit. |
| TLS reporting for mail (TLS-RPT) | Low | TLS-RPT asks other mail servers to send you daily reports of failed encrypted deliveries, so problems don’t go unnoticed. |
| BIMI brand logo for email | Low | BIMI shows your logo next to your emails in Gmail, Apple Mail and Yahoo, once DMARC is enforced. Optional, but it builds trust. |
| Mail servers (MX) set up | Medium | MX records tell other servers where to deliver mail for the domain; ones that point at names that don’t resolve lose mail. |
| DKIM signing key published | Medium | DKIM signs outgoing mail so receivers can verify it really came from you and wasn’t changed. We look for keys at the selectors common mail services use. |
| SPF within 10 DNS lookups | Medium | Receivers stop evaluating SPF after 10 DNS lookups and treat the record as broken, so legitimate mail can fail. |
| DMARC reports enabled | Low | Without a rua= address nobody sees who sends mail in your name, or whether your own mail fails authentication. |
| Web server not on blocklists | Medium | Public spam and abuse blocklists list server IP addresses that sent spam or attacks. A listed web server often means a compromised server or a noisy neighbour on shared hosting. |
| Mail servers not on blocklists | High | A mail server on a blocklist has its mail rejected or sent to spam by receivers that use the list. |
| Mail servers have reverse DNS | Low | Large mailbox providers distrust mail from IP addresses without a reverse DNS (PTR) name. |
| Strong certificate key | High | The certificate’s key must be at least RSA 2048 bits or an EC key of 256 bits; weaker keys can be broken or are refused by browsers. |
| Cookies marked Secure | High | Cookies without the Secure flag can be sent over plain HTTP, where anyone on the network can read them. |
| Cookies marked HttpOnly | Medium | Cookies scripts don’t need should be HttpOnly, so an injected script can’t steal them (session cookies above all). |
| Cookies have a SameSite policy | Low | SameSite stops browsers from sending the cookie with requests started by other sites, a defence against CSRF. |
| Tracking waits for consent | Medium | Analytics and advertising tags or cookies arrive with the page. In the EU and Türkiye (GDPR, KVKK) non-essential tracking needs the visitor’s consent first, and a consent banner must offer “Reject” as clearly as “Accept”. We can see whether a consent tool is on the page, not how its banner looks or behaves: check that yourself. |
SEO (63)
| Check | Severity | Why it matters |
|---|---|---|
| Page returns HTTP 200 | Critical | Search engines only index pages that load successfully. |
| Short redirect chain | Medium | Each redirect adds latency and can dilute ranking signals. Two hops or fewer is fine. |
| Title tag | High | The title is the headline in search results. Aim for 10–60 characters. |
| Meta description | Medium | Often used as the snippet under the title in search results. Aim for 50–160 characters. |
| Exactly one H1 heading | Medium | A single main heading makes the page topic clear to readers and search engines. |
| Canonical URL | Medium | Tells search engines which URL is the preferred version of this page. |
| Page is indexable | High | A noindex directive (meta robots or X-Robots-Tag) keeps the page out of search results. |
| Language declared | Low | The lang attribute helps search engines and screen readers handle the content correctly. |
| Mobile viewport | Medium | Without a viewport meta tag, mobile browsers render a zoomed-out desktop page. |
| Open Graph tags | Low | og:title, og:description and og:image control how links look when shared on social media. |
| Structured data (JSON-LD) | Low | Valid JSON-LD can make the page eligible for rich results. |
| Image alt text | Low | Alt text describes images to search engines and screen-reader users. |
| robots.txt reachable | Medium | robots.txt tells crawlers what they may fetch and where your sitemap is. |
| XML sitemap found | Low | A sitemap helps search engines discover all your pages. |
| www and non-www are consolidated | Low | Serving the same content on both www and the bare domain splits ranking signals. |
| Favicon | Low | Google shows your favicon next to your pages in mobile results, and browsers use it in tabs and bookmarks. |
| HTML5 doctype | Low | Without <!doctype html> as the first line, browsers render the page in quirks mode, which changes layout in subtle ways. |
| Character encoding | Low | Declaring UTF-8 makes sure accented letters and symbols display correctly and that search engines read your text as written. |
| No legacy plugins | Medium | <object>, <embed> and <applet> content (Flash, Java, plugins) no longer runs in browsers, so visitors see an empty box. |
| Readable link URLs | Low | Short, lower-case URLs with hyphens are easier to read and share, and less likely to create duplicate pages. |
| URL length | Low | Short addresses are easier to read, share and remember, and search results show them in full. Very long ones get cut off. |
| Heading structure | Low | How the page is divided into H1–H6 headings. Levels should go in order (an H3 sits under an H2), so readers, screen readers and search engines can follow the outline. |
| Readability | Information | How easy the page text is to read, as a Flesch Reading Ease score (English only): shorter sentences and words score higher. Clear text keeps visitors reading and is easier for AI answers to quote. |
| Keyword density | Information | The words and phrases the page uses most, and their share of all its words. They show what the page is about to a reader; one term repeated far more than natural writing would can look like keyword stuffing. |
| RSS or Atom feed | Information | A feed lists your newest posts in a standard format, so feed readers, podcast apps, newsletters and aggregators can follow the site. Pages announce it with a <link rel="alternate"> tag. |
| Search engine webmaster tools | Information | Whether the site is verified with Google Search Console, Bing Webmaster Tools, Yandex, Baidu or Naver, found from verification tags and DNS records. These consoles show indexing problems, search queries and manual actions, and let you submit a sitemap. |
| Embedded frames (iframes) | Low | Content from other pages shown inside this one, such as videos, maps or widgets. Search engines may credit that content to its own address rather than to this page, and each frame adds loading work. |
| Social profiles linked | Low | Links from the page to the organization's social media profiles. They help visitors find you, and listed in structured data (sameAs) they help search engines and AI assistants connect your brand to its accounts. |
| Real 404 for missing pages | Medium | A missing page should answer 404 or 410. Answering 200 (a "soft 404") lets search engines index error pages and wastes crawl budget. |
| Accessibility (Lighthouse) | Medium | Lighthouse checks contrast, labels, alt text, headings and other basics that make a page usable with assistive technology. |
| Lighthouse SEO score | Medium | Google’s own lab audit of search basics (title, description, status code, crawlable links, hreflang, canonical), scored 0–100. |
| Lighthouse Best Practices score | Medium | Lighthouse’s check of modern web hygiene: HTTPS, console errors, deprecated browser features, image sizing and permission prompts. |
| Descriptive link text | Low | Links that say only "click here" or "read more" tell search engines and screen-reader users nothing about the page they lead to. |
| Crawlable links | Medium | Search engines only follow <a> elements with a real href. Links built with JavaScript click handlers or "javascript:" URLs are invisible to them. |
| No browser console errors | Low | Errors logged while the page loads usually mean a broken script, a missing file or a blocked request, often a feature that silently doesn’t work. |
| No deprecated browser features | Low | Browser features that are being removed keep working only until browsers drop them; pages that rely on them break without warning. |
| No third-party cookies | Low | Cookies set by other sites are blocked by Safari and Firefox and restricted in Chrome, so features that rely on them fail for many visitors. |
| No issues in Chrome DevTools | Low | Chrome flagged problems such as blocked mixed content, cookie or CORS errors, or content security warnings while loading the page. |
| Images keep their proportions | Low | Images displayed with a different aspect ratio than the file look stretched or squashed. |
| Sharp images on high-density screens | Low | Images smaller than their display size on modern phones (2–3× pixel density) look blurry. |
| No intrusive prompts or blocked pasting | Low | Asking for location or notification permission on page load, or blocking paste into fields (often passwords), drives visitors away. |
| Source code not published (source maps) | Low | Source maps let anyone read your original, unminified code, with comments, internal routes and sometimes keys left in it. |
| Rich result markup complete | Medium | Structured data for products, articles, FAQs, breadcrumbs, businesses and events only earns rich results in Google when the required properties are there. |
| hreflang language links valid | Medium | Multi-language sites tell search engines which version suits which language with hreflang. Invalid codes or a missing self-reference make Google ignore them. |
| robots.txt rules are safe | Medium | robots.txt can accidentally block the whole site, or the CSS and JavaScript Google needs to render it, and unreadable lines are silently ignored. |
| Sitemap is up to date and on this site | Low | A useful sitemap lists only this site’s HTTPS URLs, stays under 50,000 URLs per file and shows recent <lastmod> dates. |
| Microdata or RDFa structured data | Low | Structured data written as Microdata or RDFa attributes (common in older themes and plugins). Google reads it like JSON-LD. |
| Canonical points to this page | Medium | The canonical tag tells search engines which URL to index. Naming another URL asks them to index that one instead of this page. |
| Permanent redirects | Low | Moves that are permanent should use a 301 or 308 redirect. With a temporary redirect (302, 303, 307) search engines may keep the old address in results. |
| HTML size under 2 MB | Medium | Googlebot reads only the first 2 MB of a page’s HTML; text, links and schema after that are ignored for indexing. |
| One title tag | Low | A page should have one <title>. With several, only one is used for the browser tab and search results, and which one is unpredictable. |
| One meta description | Low | A page should have one meta description; with several, search engines pick one themselves. |
| No meta refresh | Medium | A <meta http-equiv="refresh"> reloads or redirects the page from the browser. It is slow, confusing for visitors and screen readers, and a weaker redirect signal than a server redirect. |
| Links on the page are followed | Medium | A page-wide nofollow (meta robots or X-Robots-Tag) makes search engines ignore every link on the page and pass nothing to the linked pages. |
| X (Twitter) card | Low | X (Twitter) builds link previews from twitter:card tags, falling back to Open Graph. Without either, a shared link shows as plain text. |
| Open Graph URL matches the canonical | Low | og:url should name the same address as the canonical tag, so shares and likes count for the canonical URL. |
| Internal links use HTTPS | Medium | Links between your own pages should use HTTPS. An http:// link costs an extra redirect on every click, or lands on an unencrypted page. |
| No nofollow on internal links | Low | Search engines don’t follow rel="nofollow" links, so nofollow on links to your own pages keeps them from discovering and ranking those pages. |
| Page links to other pages | Low | Links lead visitors and crawlers on to the rest of the site; a page without any is a dead end. |
| No double slashes in URLs | Low | A "//" inside a URL path is usually a template bug, and search engines can treat such addresses as separate, duplicate URLs. |
| Canonical uses HTTPS | Medium | On an HTTPS page the canonical URL should use HTTPS too; an http:// canonical asks search engines to index the insecure version. |
| Page listed in the sitemap | Low | Pages listed in the XML sitemap are found by search engines directly, not only through links. |
| Valid language code | Low | The <html lang> value should be a valid language code that matches the page’s own hreflang entry. Screen readers and some search engines read it. |
AI Readiness (14)
| Check | Severity | Why it matters |
|---|---|---|
| Search and AI search crawlers allowed | High | AI answers cite pages their search crawlers can reach: Googlebot and Bingbot (which AI Overviews and Copilot rely on), OAI-SearchBot, Claude-SearchBot and PerplexityBot. |
| Assistants can open your pages | Low | When someone asks ChatGPT, Claude or Perplexity about a page, their user agents (ChatGPT-User, Claude-User, Perplexity-User) fetch it on that person’s behalf. |
| AI training crawlers | Low | Crawlers such as GPTBot, ClaudeBot, Google-Extended and CCBot collect pages to train models. Allowing or blocking them is your choice; it doesn’t affect AI search. |
| Content in the HTML | High | Most AI crawlers don’t run JavaScript. If the main text only appears after scripts run, they see an empty page. |
| Schema for who and what | Medium | Schema.org markup tells machines who is behind the site (Organization, WebSite) and what the page is (Article, Product, FAQPage…). |
| Author and date | Low | A named author and a published or updated date help readers and AI systems judge whether content is credible and current. |
| Quotable structure | Low | Clear sub-headings, lists and tables make it easy to lift a precise answer from a page, which is how AI answers quote sources. |
| llms.txt | Low | llms.txt is a proposed file that summarizes a site for language models. The major AI engines are not known to use it yet. |
| In Common Crawl | Information | Common Crawl is a free, open archive of the web and one of the main sources AI models are trained on. Whether your domain is in the newest crawl shows how visible it is to them. |
| Consistent AI training policy | Low | AI training crawlers should be treated the same way: all allowed or all blocked. A mix usually means robots.txt was written for one company’s bot and not updated for the others. |
| Product schema on product pages | Medium | Product structured data gives shopping results and AI shopping answers the name, price, availability and ratings of a product page. |
| Article schema on articles | Low | Article, BlogPosting or NewsArticle schema states an article’s headline, author and dates in a machine-readable form. |
| FAQPage schema on FAQ pages | Low | FAQPage structured data presents each question and answer of an FAQ page in the form assistants quote. |
| Organization schema with profiles | Low | Organization schema on the home page, with sameAs links to the official profiles, connects the domain to the brand in search and AI answers. |
Site Profile (14)
| Check | Severity | Why it matters |
|---|---|---|
| At least two name servers | Medium | With a single name server the whole domain (site and mail) disappears whenever that server is down. |
| Name servers on separate networks | Low | Name servers that all sit in one network fail together; spreading them over networks keeps DNS answering. |
| DNS provider | Information | Which company answers DNS for the domain, from its name servers. |
| SOA record timers | Low | The SOA record sets how secondary servers refresh the zone and how long missing names are cached; broken values cause stale or flapping DNS. |
| Served through a CDN | Low | A content delivery network serves the site from locations near visitors and absorbs traffic spikes and attacks. |
| Server location and network | Information | The country and network (ASN) the site’s server answers from. |
| Green hosting | Low | Whether The Green Web Foundation lists the site’s host as running on, or offsetting with, renewable energy. |
| Subdomains in certificate logs | Information | Every publicly trusted certificate is logged in Certificate Transparency, so the hostnames on your certificates are public. Forgotten staging, test or admin hosts show up there too. |
| Unsupported software | High | Software whose release line no longer gets security fixes, judged from the versions the site reveals (CMS, server, language, libraries). |
| Software updates available | Medium | Detected versions that are behind their latest release, including CMS plugins. Updates often contain security fixes. |
| Domain registration expiry | High | When the domain registration runs out, according to the registry. An expired domain takes the site and its email offline. |
| Known vulnerabilities in visible versions | Critical | Software versions the site shows publicly, compared with the known vulnerabilities we track (including those CISA lists as actively exploited). A match means the visible version is in an affected range; Linux distribution builds may already carry the fix. |
| AI app builder and hosted backend | Information | Apps made with AI builders (Lovable, Bolt, v0, Replit) often talk to Supabase or Firebase straight from the browser. Then the database access rules alone decide what anyone can read or change, and they can only be tested from inside your project: check that Row Level Security is on for every table, storage buckets are private, Firebase rules are not open, and service keys stay on the server. |
| IPv6 support | Low | Whether the site has an IPv6 address (AAAA record), so visitors on IPv6-only networks reach it directly. |
Malware Signs (14)
| Check | Level |
|---|---|
| Page and its scripts not on Google’s malware lists | Blocklist listing |
| No scripts from known compromised hosts | Blocklist listing |
| Domain not blocked by Quad9 | Blocklist listing |
| No fake "verify you are human" paste instructions | Strong sign |
| No blockchain calls on a non-crypto site | Strong sign |
| No code before <html> or after </html> | Strong sign |
| Sitemap free of spam pages | Strong sign |
| Scripts come from established domains | Weak sign |
| No packed or obfuscated inline scripts | Weak sign |
| No live connections to unknown servers | Weak sign |
| robots.txt declares only your own sitemaps | Weak sign |
| Script inventory | Information |
Changelog
- v1.0 · 2026-11-01
- First published methodology: grade bands, section weights, severity-weighted section scores, the Malware Signs ceilings and the blocklist cap on the overall score, as scored since launch.
Reports record the methodology version they were scored with; a report made before this page existed carries none.
Disagree with a result?
If a check looks wrong, write to us with the report link and we'll look at it; corrections go into the scanner for everyone. If you don't want your site scanned at all, the bot page explains the robots.txt rule that makes us refuse it.