Guides Create account 🇬🇧 🇩🇪
  • Guides
  • Create account
  • Sign in
  • 🇬🇧 🇩🇪

    • Methodology

    What the scanner checks and how the score comes about

    This page is generated from the same code that scores every scan. The categories, weights and checks below are the ones in use right now.

     Scan a website

    01 Scope

    What is checked

    17 of 20 categories are active with 221 individual checks. Active groups: Data protection, Legal obligations, Security, Accessibility, Quality & technology, Trust & transparency. The remaining categories are built but dormant: they are not checked and do not count towards any score.

    Scoring version 54. Every change to the categories, weights or checks raises this number, and stored scans are scored again under it the next time they are opened.

    Data protection

    Group weight 25 25.0 % of the overall score

    Privacy policy & external fonts

    Weight 35 in the group 35.0 % of the group score 18 checks
    • Fonts loaded from elsewhere
      Tests whether fonts are fetched from an external provider while the page loads. That passes the visitor address to the provider before anybody was asked; hosting the font files yourself avoids it.
    • Services named in the privacy policy
      Compares the external services the page actually loads with the wording of the privacy policy. Every recipient of visitor data belongs in that text, and a service that cannot be found there is the prompt to look; a different wording or a processor name is not recognised.
    • Controller named
      Tests whether the privacy policy names who is responsible for the data processing. Visitors need that name and its contact details to be able to address a request about their data to anybody at all.
    • Legal basis named
      Tests whether the privacy policy names a legal basis for the processing it describes. Every processing rests on one, and the privacy policy is the place where it is stated.
    • Storage duration described
      Tests whether the privacy policy says how long data is kept, or which criteria decide that. Without it neither the visitor nor the operator can tell when something has to disappear again.
    • Visitor rights described
      Tests whether the privacy policy describes the rights of the visitor, such as access, rectification, erasure or objection. They only work if the text says they exist and how to use them.
    • Right to complain named
      Tests whether the privacy policy mentions the supervisory authority and the right to lodge a complaint there. It is the way out for a visitor who gets nowhere with the operator.
    • Safeguard for transfers outside the EU
      Runs where a transfer outside the EU is visible, either from the wording of the privacy policy or from the services detected. It tests whether the text names a safeguard for it, for example standard contractual clauses or an adequacy decision.
    • IP shortening for analytics
      Runs where the page loads an analytics service. It tests whether the privacy policy says that visitor IP addresses are shortened before evaluation, because the full address is what turns a visit count into personal data.
    • Privacy policy is dated
      Tests whether the privacy policy carries a recognisable date. Without one nobody can tell whether the text still matches the services the page uses today.
    • Privacy policy linked on every page
      Opens a few subpages of the site and tests whether each of them links to the privacy policy. Visitors often land on a subpage directly, and the information has to be reachable from wherever data is collected, not only from the start page.
    • Privacy policy in the language of the page
      Compares the language the start page declares with the one its privacy policy declares. Visitors have to be informed in the language the page speaks to them in; where one of the two pages declares no language, the check stays uncertain.
    • Purposes of the processing named
      Tests whether the privacy policy says what the data is actually used for, as concrete purposes such as operating the site, answering an enquiry or measuring reach. The assurance that everything happens lawfully is not a purpose and does not count.
    • Recipients of the data named
      Tests whether the privacy policy says who receives the data besides the operator, either by name or as categories such as hosting provider, payment provider or analytics provider. Without that a visitor cannot tell where their data ends up.
    • Withdrawal of a consent described
      Tests whether the privacy policy says that a consent once given can be withdrawn at any time with effect for the future. Wherever a banner asks for consent, the text has to say how to take it back.
    • Right to object named
      Tests whether the privacy policy names the right to object to a processing. It is the right a visitor uses against everything that rests on a legitimate interest, which is why it is asked for separately and not only inside the list of the other rights.
    • Legitimate interest stated
      Runs where the privacy policy rests a processing on a legitimate interest. It tests whether the text also says what that interest consists of, because the legal basis alone gives a visitor nothing they could weigh against their own interests.
    • Form data described
      Runs where the scan found a form on the page that visitors enter their own data into. It tests whether the privacy policy describes what happens to that data, because a form collects it directly from the visitor and that is where the duty to inform is strongest.

    Consent & Tracking

    Weight 35 in the group 35.0 % of the group score 11 checks
    • Cookies before consent
      Tests whether the page sets cookies that are not technically necessary before the visitor has agreed. Anything that only serves analysis or advertising has to wait for the click on accept.
    • Browser storage before consent
      Tests whether the page writes into the browser storage before consent. Local storage is judged the same way as a cookie, so moving a marker there changes nothing about the duty to ask.
    • Tracking services before consent
      Tests whether analysis or advertising services are already loaded before consent. Loading the script alone passes the visitor address on, so it has to be held back until the visitor has agreed.
    • Consent banner present
      Tests whether the page shows a consent banner at all. It is needed as soon as anything beyond the technically necessary is loaded, and it should name what it is asking for.
    • Rejection offered
      Tests whether the banner offers a rejection at all. A banner with an accept button only leaves no choice, so consent given that way does not count as freely given; the rejection should also be as easy to reach as the acceptance.
    • Rejection actually blocks
      The scanner uses the rejection in the banner, reloads the page and only then measures again. It tests whether cookies that are not technically necessary are still set afterwards, because a rejection that changes nothing is the most common real breach.
    • Consent can be withdrawn
      After the rejection has been used, this tests whether the page still offers a permanently reachable way back into the consent settings. Withdrawal has to be as easy as giving consent, which needs an entry point that stays there once the banner is gone.
    • No year-long identifier of your own before consent
      Tests whether the page sets cookies on its own domain before consent that carry an identifier-shaped value and stay valid for longer than twelve months. A marker of that length recognises the same browser across a whole year and beyond, which is why it has to wait for consent and should not outlive one year even then.
    • Rejection is remembered
      The scanner uses the rejection in the banner, reloads the page and looks whether the banner asks again with its rejection option. A rejection that is not stored makes the visitor answer on every page view, which wears the decision down instead of respecting it.
    • Consent Mode starts with denied
      Runs where the page uses Google Consent Mode. It reads the default state that applies to visitors from Germany and tests whether the storage parameters start as denied. A default of granted lets tags store and send data before the banner has asked anybody.
    • No consent before the decision
      Runs where the page uses a consent platform after the IAB TCF standard or Google Consent Mode. In a fresh browser, before any click, it asks these interfaces whether they already report a consent. Anything they report at that point was not given by the visitor.

    Third-Party Risk

    Weight 15 in the group 15.0 % of the group score 16 checks
    • Number of external services
      Counts how many other providers the page pulls in, for example fonts, maps, videos or analysis tools. Every one of them receives the visitor address, has to appear in the privacy policy and slows the page down.
    • External services assigned to a provider
      Tests whether every external host the page loads could be assigned to a named provider. A host without an assignment is not harmless, it is a recipient of visitor data whose operator and country we could not determine, and it belongs in the privacy policy just the same.
    • No tracking disguised under your own domain
      Resolves the DNS alias of the subdomains the page loads from and tests whether one of them points at a tracking vendor. Such a subdomain looks like the site itself to the browser, so cookies set there escape every block on third-party cookies.
    • Transfer outside the EU
      Tests whether embedded services transfer data to countries outside the EU. That is permitted, but it needs a legal basis and a passage of its own in the privacy policy; a European alternative avoids the question.
    • Purpose of the external services
      Assigns every recognised provider its purpose, such as analysis, advertising, CDN, payment, maps, video, fonts, consent or support, and tests whether one of them goes beyond what the page technically needs. Such a service needs consent, and consent is measured by a separate check that is not active yet.
    • Cookies from external hosts
      Tests whether external hosts set cookies while the page loads, through their own response or from their script through document.cookie. A long-lived cookie with an identifier lets the provider recognise the browser on other sites too.
    • Browser storage written by external scripts
      Tests whether scripts from external hosts write into localStorage, sessionStorage or IndexedDB of the page. Browser storage is judged like a cookie, an identifier kept there is just as recognisable.
    • Page address kept from external hosts
      Tests which external hosts receive the full address of the page with path and parameters in the Referer header, measured against the Referrer-Policy the page sets. The path alone can reveal what a visitor was reading.
    • Page parameters not passed on
      Tests whether values from the parameters of the page address reappear in requests to external hosts. Search terms, campaign codes or an e-mail address in the address then end up with that provider.
    • Form input stays with the site
      Tests whether a form that collects personal data sends its input to an external service instead of the server of the site.
    • No canvas fingerprinting
      Tests whether an external script draws hidden text into a canvas and reads the image back, judged by the Blacklight criteria. The result identifies a device without any cookie, and the visitor cannot delete it.
    • No session recording
      Tests whether the page loads a known session recording service such as Hotjar, Microsoft Clarity or FullStory. Such a service can replay mouse movements, clicks and form input of a visit.
    • No third-party keyboard listeners
      Tests whether external scripts listen to keyboard input on form fields, or on the whole page as part of a known session recording service. It shows who is listening, not whether input leaves the page; nothing is typed and no form is submitted.
    • No tracking pixels or beacons
      Tests whether the page sends counting requests to external hosts, as invisible one-pixel images or as beacons. They carry no content and report the visit to the provider.
    • Embedded videos, maps and posts in data-saving form
      Tests whether YouTube, Vimeo, Google Maps or embedded posts, players and booking widgets of social networks, Spotify, SoundCloud or Calendly load in a frame together with the page instead of the data-saving variant or a click to load. The frame passes the visitor address to the provider as soon as it appears.
    • No early connections to external hosts
      Tests whether the head of the page asks the browser to resolve or connect to external hosts in advance with dns-prefetch or preconnect. A preconnect already passes the visitor address on, even if nothing is loaded from that host afterwards.

    Form consent & privacy notice

    Weight 15 in the group 15.0 % of the group score 3 checks
    • Consent boxes not pre-ticked
      Tests whether a checkbox in a form is already ticked when the page loads. A pre-ticked box is not an active decision by the visitor, so consent collected that way generally does not count as freely given.
    • Privacy notice next to the form
      Tests whether a data-protection notice or a link to the privacy policy sits inside the form or directly next to it. Without it, visitors enter their data without being told at that moment what happens to it.
    • Form input stays on the page until it is sent
      Types a synthetic test address into the e-mail fields of the page, leaves the field and watches whether it reaches another provider, also in hashed form. The form is never submitted. Input that leaves the page before the click on send was never given to that provider.

    Legal obligations

    Group weight 20 20.0 % of the overall score

    Legal / DACH Compliance

    Weight 50 in the group 100.0 % of the group score 4 checks
    • Imprint reachable
      Tests whether a link to the imprint can be found on the page and whether that page answers. In the German-speaking market the imprint has to be reachable from every page with a small number of clicks.
    • Privacy policy reachable
      Tests whether a link to the privacy policy can be found on the page and whether that page answers. Visitors have to be able to read at any time which data is processed and by whom.
    • Reference to the current law
      Tests whether the page, the imprint or the privacy policy still cites the Telemediengesetz, which was replaced by the Digitale-Dienste-Gesetz in 2024. The duty itself is unchanged, so replacing the reference with section 5 DDG is enough.
    • No outdated ODR link
      Tests whether the page still links to the European online dispute resolution platform. That platform has been shut down, so the link now leads nowhere and should be removed.

    Security

    Group weight 20 20.0 % of the overall score

    Transport security

    Weight 30 in the group 30.0 % of the group score 17 checks
    • Strict-Transport-Security header
      Tests whether the site tells browsers to use HTTPS for every later request, so a connection cannot fall back to an unencrypted channel.
    • Site reachable over HTTPS
      Tests whether the site opens over an encrypted connection at all, so that what visitors send and receive cannot be read on the way.
    • Redirect from HTTP to HTTPS
      Tests whether a request over unencrypted HTTP is moved onto an encrypted connection.
    • Mixed content
      Tests whether an encrypted page loads any of its own resources over an unencrypted connection.
    • Form submission over HTTPS
      Tests whether the forms on the pages checked send their data to an encrypted address instead of to plain HTTP.
    • Negotiated TLS version
      Tests which TLS version the browser actually agreed with the server while loading this page.
    • Effect of the transport security policy
      Tests whether the transport security policy reaches the browser at all: it only takes effect on the encrypted final page, not on an unencrypted response or on the redirect alone.
    • HSTS preload state
      Tests whether the domain is on the browser preload list and whether the header agrees with that state.
    • Lifetime of the HSTS policy
      Tests whether the declared lifetime of the transport security policy is long enough to have an effect.
    • Certificate validity
      Tests whether the certificate is valid right now and not about to expire.
    • Certificate host name
      Tests whether the certificate is actually issued for the host name that was scanned.
    • Certificate trust chain
      Tests whether the certificate can be verified against the public trust store.
    • Certificate key strength
      Tests whether the key in the certificate is long enough to still count as safe.
    • Certificate signature algorithm
      Tests whether the certificate is signed with an algorithm that still counts as safe.
    • Outdated TLS versions
      Tests whether the server still accepts TLS 1.0 or TLS 1.1, versions that count as broken.
    • Current TLS version
      Tests whether the server offers TLS 1.3, the current version of the protocol.
    • Cipher strength
      Tests whether the server accepts a connection that uses ciphers which count as weak.

    Protective headers

    Weight 30 in the group 30.0 % of the group score 23 checks
    • Content-Security-Policy
      Tests whether a content security policy limits which scripts, styles and frames the page is allowed to load.
    • X-Content-Type-Options header
      Tests whether the response pins the content types it declares, so a browser does not guess a different one.
    • Referrer-Policy header
      Tests whether the site limits which address information is passed on when a visitor follows a link to another site.
    • Permissions-Policy header
      Tests whether access to powerful browser features such as camera, microphone and location is explicitly restricted.
    • X-Frame-Options header
      Tests whether other sites are kept from embedding the page in a frame, a common clickjacking indicator.
    • Cross-Origin-Opener-Policy header
      Tests whether the page separates its browsing context from windows it opens and from windows that open it.
    • Cross-Origin-Resource-Policy header
      Tests whether the site states which other origins may embed its resources.
    • Cross-Origin-Embedder-Policy header
      Tests whether the page requires embedded resources to opt in before they are loaded.
    • Reporting-Endpoints header
      Tests whether the site names an endpoint that browsers can report policy violations to.
    • Subresource integrity
      Tests whether scripts loaded from other sites carry an integrity hash, so an altered file is not executed.
    • Security headers beyond the start page
      Tests whether a second page of the same site answers with the same security headers as the start page.
    • Strength of the content security policy
      Tests whether the policy really constrains scripts, instead of letting everything through a broad directive.
    • Content security policy enforced
      Tests whether the policy is enforced or only reported, because a report-only policy blocks nothing.
    • Delivery of the content security policy
      Tests whether the policy arrives as an HTTP header, which covers more cases than a policy placed in the page markup.
    • Strength of the referrer policy
      Tests whether the chosen referrer policy really withholds the address instead of passing the full URL on.
    • Value of the X-Frame-Options header
      Tests whether the framing rule uses a value that current browsers still honour.
    • Coverage of the Permissions-Policy
      Tests whether the policy actually names the sensitive browser features instead of staying empty.
    • Value of the X-Content-Type-Options header
      Tests whether the header carries nosniff, the only value that has any effect.
    • Value of the Cross-Origin-Opener-Policy
      Tests whether the value actually separates the browsing context instead of naming the browser default under a header name.
    • Value of the Cross-Origin-Resource-Policy
      Tests whether the value restricts who may embed the response instead of allowing every origin.
    • Enforcement of the Cross-Origin-Embedder-Policy
      Tests whether the embedder policy is in force or only reports what it would have blocked.
    • X-XSS-Protection header
      Tests whether the site still sends the retired XSS filter header, which current browsers ignore and which used to cause problems of its own.
    • CORS configuration
      Tests whether the site opens its responses to any origin, in particular together with credentials.

    Cookie attributes

    Weight 10 in the group 10.0 % of the group score 4 checks
    • Secure attribute on cookies
      Tests whether cookies are marked so that they are only ever sent over an encrypted connection.
    • HttpOnly attribute on cookies
      Tests whether cookies are withheld from scripts in the page, which limits what injected script code can read.
    • SameSite attribute on cookies
      Tests whether cookies state whether they may travel on requests that start on another site.
    • SameSite=None without Secure
      Tests whether a cookie that allows cross-site use is at least limited to encrypted connections.

    Domain & mail security

    Weight 20 in the group 20.0 % of the group score 14 checks
    • SPF record
      Tests whether the domain names in DNS which servers are allowed to send mail on its behalf.
    • DMARC record
      Tests whether the domain states in DNS how a receiving mail server should treat messages that fail authentication.
    • DNSSEC
      Tests whether the DNS answers for the domain are cryptographically signed.
    • CAA record
      Tests whether the domain limits in DNS which certificate authorities may issue certificates for it.
    • MTA-STS policy
      Tests whether the domain publishes a policy that requires encrypted transport for incoming mail.
    • TLS-RPT record
      Tests whether the domain names a place that receives reports about failed mail transport encryption.
    • DKIM key
      Tests whether a DKIM key can be found under one of the common selector names, so outgoing mail can be signed and a forged sender is recognisable, and whether an RSA key there has at least 2048 bits. Only when no name exists under _domainkey at all is the key reported as missing; if something is published there under a selector of your own, the check stays unresolved.
    • Website over IPv6
      Tests whether the scanned host publishes an AAAA record and can therefore be reached directly by visitors on an IPv6-only network.
    • Mail servers over IPv6
      Tests whether at least one mail server of the domain publishes an AAAA record. Without a mail server in DNS the question does not arise and stays unmeasured.
    • Nameserver redundancy
      Tests whether the zone is served by more than one nameserver, so a single failing server does not take the website, the mail and every subdomain down at once.
    • DANE/TLSA record
      Tests whether the mail servers of the domain publish a TLSA record, which lets a sending server verify the certificate through DNSSEC. It applies only where the zone of the mail server is signed with DNSSEC; without the signature a TLSA record would prove nothing, and a mail server in an unsigned provider zone is out of reach for the site owner.
    • Reputation of the domain
      Tests whether Google Safe Browsing lists the domain as dangerous, which makes browsers warn visitors before the site opens.
    • Names pointing at an unused hosting account
      Tests whether the scanned address or its www counterpart is directed by CNAME at a hosting platform whose target is free to be claimed, because it resolves nowhere or the platform answers with the page it shows for an unclaimed name. A CNAME onto such a platform is normal by itself and is not reported; only these two observations are.
    • Remaining registration period
      Tests how long the registration of the domain still runs, because an expired domain takes the website, the mail and every subdomain down at once. The date is only readable where the registry serves it over RDAP, which the generic domains do and the country code domains of this market do not; without it the check stays unmeasured and is never counted as a defect.

    Information exposure

    Weight 10 in the group 10.0 % of the group score 8 checks
    • Server version disclosed
      Tests whether the response names the exact version of the software that serves the site.
    • Technology disclosed in headers
      Tests whether the response names the software, framework or platform behind the site.
    • security.txt
      Tests whether the site publishes a contact point for security reports at the agreed address.
    • Directory contents visible
      Tests whether a directory the page loads its own files from answers with a list of its contents instead of a page. Only directories derived from the resources of the page are asked, no addresses are guessed.
    • Internal information in the markup
      Tests whether the delivered markup contains error output, a directory of the server, an internal network address in a comment or a string with the shape of an access key. The check reads the markup that every visitor receives anyway and reports the kind of the find, never its wording.
    • Age of the software in use
      Tests whether the products the page names about itself, such as the content management system, the web server or a JavaScript library, are behind their current release. The check reads only what the page discloses of its own accord and reports nothing when no version is visible or the release reference is too old to judge against. A version built by a Linux distribution stays open, because the distribution brings security fixes into it without changing the number.
    • Maintenance of the server platform
      Tests whether the server banner points to an operating system release or an OpenSSL line whose maintenance has ended. Only a banner that pins the release down is judged; where it names neither, the check reports nothing.
    • Unusual content on the page
      Tests whether the delivered page contains elements that injected code typically leaves behind: an invisible frame that loads from another site, a script that decodes its own content before running it, or an automatic redirect to another site. Each of these has legitimate uses, so the check reports a pointer to look at rather than a verdict.

    Accessibility

    Group weight 13 13.0 % of the overall score

    Accessibility (automated checks)

    Weight 100 in the group 100.0 % of the group score 19 checks
    • Accessibility statement present
      Tests whether the site links to an accessibility statement. Public bodies and, since the accessibility act, many businesses have to publish one; if it is missing, add a page that names the state of conformity and a contact option for barrier reports.
    • Automatically detectable barriers
      Tests how many of the automated rules the page breaks, for example missing text alternatives, unlabelled controls or too little contrast. Each violation is a concrete place in the markup that can be repaired.
    • Automatically detectable barriers on a narrow screen
      Runs the automated rules a second time at a width of 320 pixels, where many sites switch to their mobile layout, and reports only what the desktop run did not already find. Collapsed menus and mobile controls often break the same WCAG rules as the desktop view, for example 4.1.2 (name, role, value).
    • Automatically detectable barriers on contact, cart and checkout
      Runs the automated rules on the contact page and, where linked, on the cart and the checkout, because the accessibility act is about exactly these steps. A contact form without labelled fields breaks WCAG 3.3.2 (labels or instructions), wherever the start page stands.
    • Readable on a narrow screen
      Tests whether the content reflows into a narrow window instead of forcing the visitor to scroll sideways. People who enlarge the page or use a small screen otherwise lose part of the text on every line.
    • Keyboard focus visible
      Moves through the start page with the Tab key and compares each element with and without focus. If nothing changes, keyboard users cannot see where they are (WCAG 2.4.7 focus visible); give every link and control a clear focus style.
    • No keyboard trap
      Tests whether the Tab key always moves the focus on. An element that keeps the focus locks keyboard users out of the rest of the page (WCAG 2.1.2 no keyboard trap).
    • Focused element not hidden
      Tests whether an element that receives keyboard focus can be seen, or whether it lies outside the visible area, for example in a closed menu, or sits completely under a fixed header or banner (WCAG 2.4.11 focus not obscured).
    • Moving content can be paused
      Tests whether videos and animations that start on their own and run longer than five seconds can be paused or stopped. Constant motion makes it hard for many people to read the rest of the page (WCAG 2.2.2 pause, stop, hide).
    • Reduced motion respected
      Tells the page that the visitor prefers reduced motion and tests whether its animations stop. People who react to motion with dizziness set this preference in their system (WCAG 2.3.3 animation from interactions).
    • No accessibility overlay
      Tests whether the page loads an overlay widget that promises accessibility as an add-on. An overlay does not repair the markup, does not satisfy the accessibility act and can get in the way of the assistive technology visitors already use.
    • Linked PDFs are tagged
      Opens the PDF documents linked from the start page and tests whether they carry a tag structure. Without tags a screen reader cannot tell headings, lists and tables apart (WCAG 1.3.1 info and relationships).
    • Linked PDFs declare their language
      Tests whether the linked PDF documents declare their language, so that a screen reader pronounces them correctly (WCAG 3.1.1 language of page).
    • Linked PDFs show a title
      Tests whether the linked PDF documents have a title and tell the viewer to show it instead of the file name (WCAG 2.4.2 page titled).
    • Feedback option in the statement
      Tests whether the accessibility statement names a way of reporting a barrier, for example a mail address, a form or a telephone number. This is a text search, so a differently worded option can be missed; name a contact person plainly in the statement.
    • State of conformity in the statement
      Tests whether the accessibility statement says how far the site meets the requirements, that is fully, partially or not at all, and against which standard. Without that sentence the statement does not say what visitors can expect.
    • Known barriers listed in the statement
      Tests whether the accessibility statement names the parts that are not accessible yet. Listing them honestly, together with the reason and an alternative, is part of a complete statement.
    • Date of the last review
      Tests whether the accessibility statement carries the date on which it was drawn up or last reviewed. Without a date nobody can tell whether it still describes the current site; review it regularly and record the date.
    • Enforcement procedure in the statement
      Tests whether the accessibility statement names the supervisory or arbitration body a visitor can turn to when a barrier report gets no answer. Name the body that is responsible for you, with its contact details.

    Quality & technology

    Group weight 14 14.0 % of the overall score

    SEO

    Weight 32 in the group 32.0 % of the group score 35 checks
    • Page title
      Tests whether the page carries a title of a sensible length, does not repeat it on other pages and, on the start page, says more than "Home". The title is the headline of the search result, so it should name this one page.
    • Meta description
      Tests whether the page carries a short summary for the search result and whether it is long enough to be useful without being cut off. Without one the search engine picks an arbitrary passage from the page.
    • Main heading
      Tests whether the page has exactly one main heading. It tells visitors and search engines what this page is about; several main headings leave that open.
    • Order of the headings
      Tests whether the heading levels follow one another without a gap. Headings are the table of contents of the page, and people who navigate by screen reader use exactly that structure.
    • Canonical address
      Tests whether the page names its own preferred address. Where the same content is reachable under several addresses, this is what stops the search engine from splitting the ranking between them.
    • Page may be indexed
      Tests whether the page bars search engines from recording it or from following its links. Such an instruction is right for a staging site and a mistake on a live page, because it keeps the page out of the search results entirely.
    • Preview for social networks
      Tests whether the page supplies a title, a description and an image for the preview shown when the link is shared. Without them the preview stays blank and the link gets clicked less.
    • Preview card for X
      Tests whether the page supplies the additional details that X uses for its link preview. This is a small addition to the social preview above.
    • Structured data
      Tests whether the page describes itself in machine-readable form, for example as a business, an article or a product, and whether that description is valid. It is what search engines build extended results from.
    • Language references
      Tests whether a multilingual site names its language versions consistently and refers to itself as well. Inconsistent references send visitors to the wrong language version.
    • robots.txt
      Tests whether the site carries a robots.txt, whether it is reachable and whether it blocks search engines more than intended. A rule left over from a relaunch can take the whole site out of the search results.
    • Sitemap
      Tests whether the site offers a sitemap, whether it is reachable, whether it really is XML and whether the robots.txt names it. It is the list of pages search engines walk through, which matters most where pages are poorly linked.
    • Handling of unknown addresses
      Tests what an address that does not exist returns. It should be an error page of your own with the status 404; a page that answers with 200 leads search engines to record thousands of empty pages.
    • Status of the page
      Tests whether the server reports success for the page. Search engines go by that status and do not index a page that reports an error, even if it displays normally.
    • Meaningful link texts
      Tests whether links name their target instead of reading "click here" or "more". Search engines use the link text to understand the page behind it.
    • Links search engines can follow
      Tests whether every link carries a real address. Links that only work through a script lead search engines nowhere, so the pages behind them are not discovered.
    • Readable robots.txt
      Tests whether every line of the robots.txt follows the format. Crawlers skip lines they cannot read, so a rule in such a line does not apply.
    • Set up for phones
      Tests whether the page tells phones to show it at the width of the screen. Without that instruction it appears as a scaled-down desktop page, and Google rates pages by their mobile version.
    • Document type declared
      Tests whether the document starts with the HTML doctype. Without it browsers switch to a compatibility mode in which the layout can differ from what was designed.
    • Character encoding declared
      Tests whether the page declares its character encoding at the very start. Otherwise umlauts and special characters can turn into wrong characters.
    • No permission request on opening
      Tests whether the page asks for the location or for notifications while it loads. Visitors decline requests they cannot place, and browsers then suppress them for good.
    • Pasting into input fields allowed
      Tests whether input fields accept pasted text. Blocking it locks out password managers and leads to typing errors and abandoned forms.
    • Enough text on the page
      Counts the words of the visible text. A page with very little text gives search engines little to tell what it is about.
    • Links to own pages
      Tests whether the page links to other pages of the site and whether those links may be followed. Search engines discover the rest of the site through them.
    • Readable addresses
      Tests the addresses of the page and of the own pages it links for session identifiers, underscores, spaces, double slashes, many parameters and a length of more than 200 characters.
    • Only one meta description
      Tests whether the page carries exactly one meta description. With several, search engines pick one of them, and not necessarily the one you wrote.
    • No meta refresh
      Tests whether the page reloads itself or forwards visitors through a meta refresh instruction. Search engines treat such a forwarding as a weak redirect, a redirect of the server is the reliable way.
    • Fallback language named (x-default)
      Tests whether a multilingual page names the version for visitors whose language it does not serve. Pages without language references are not judged here.
    • Preview address matches the canonical
      Tests whether the address in og:url is the same as the canonical address. Otherwise shares and search results collect under two addresses. Pages that lack one of the two are not judged here.
    • Canonical address reachable
      Tests whether the canonical address answers directly, without a redirect or an error, and uses https on an https site. Only addresses of your own site are asked.
    • Page files open to search engines
      Tests whether the robots.txt locks Googlebot out of stylesheets, scripts or images the page loads from its own host. Without them a search engine sees the page unstyled.
    • No placeholder text
      Tests whether the visible text still contains placeholder text such as "Lorem ipsum".
    • Links with a target
      Tests whether links on the page lead somewhere instead of carrying only "#" as their address.
    • Favicon
      Tests whether the site delivers an icon for browser tabs, bookmarks and the search result on phones.
    • Readable font size on phones
      Tests whether the text is large enough to be read on a phone without zooming.

    Performance

    Weight 32 in the group 32.0 % of the group score 23 checks
    • Overall loading rating
      Tests how fast the page loads and sums the single measurements up into one figure. The run uses a simulated mobile connection with a slowed-down processor, so visitors on a fast device usually see better numbers than the report shows.
    • Time until the first content appears
      Measures how long it takes until the first text or image is visible. Until then a visitor looks at an empty page and cannot tell whether anything is happening.
    • Speed at which the visible area fills
      Measures how quickly the visible area of the page fills with content while loading. A page that builds up evenly feels faster than one that stays empty for a long time and then appears at once.
    • Time until the main content appears
      Measures how long it takes until the largest element of the page, usually the headline image or the main text block, is visible. This is the moment at which a visitor feels the page is there.
    • Stability of the layout
      Measures how much the content still jumps around while loading. Images without a stated size or a banner inserted afterwards are the usual cause, and the result is a visitor clicking the wrong thing.
    • Time the page cannot be operated
      Measures how long scripts keep the browser so busy that taps and clicks are not answered. The page already looks finished then, which makes the delay especially irritating.
    • Response time of the server
      Measures how long the server takes to send the first part of the page. Everything else can only start after that, so a slow response delays the whole page. Caching or a stronger hosting plan is the usual remedy.
    • Files that hold up the display
      Tests whether stylesheets or scripts have to be loaded in full before anything appears. Loading them later or in the background lets the page show its content sooner.
    • Compressed delivery of the page
      Tests whether the server sends the page and its stylesheets and scripts compressed, that is with gzip or brotli. Without compression the browser waits for far more data before it can start drawing; it is a single switch on the web server.
    • Caching instructions of the page
      Tests whether the server tells the browser how long it may keep the delivered files. Without that instruction, returning visitors load everything again on every visit.
    • Embedded players and chats load on demand
      Tests whether embedded elements of other providers, such as video players or chats, are loaded only when a visitor uses them. Loaded right away they slow down the page for everyone.
    • Minified stylesheets and scripts
      Tests whether stylesheets and scripts are delivered without comments and superfluous characters. Removing them changes nothing about the function and shortens the download.
    • No unused code
      Tests whether the page loads stylesheets and scripts of which it uses only a small part. Code that is never run still has to be downloaded and processed.
    • Cache lifetime of images, styles and scripts
      Tests whether the browser may keep static files for a long time. Returning visitors then load the page almost entirely from their own device.
    • Current transfer protocol
      Tests whether the files are delivered over HTTP/2 or HTTP/3. Both send many files side by side over one connection, where the older HTTP/1.1 makes them wait in line.
    • Page reachable without detours
      Tests whether the page is reached directly or only through redirects. Every redirect costs a full round trip to the server before anything is shown.
    • Scripts without duplicate or outdated code
      Tests whether scripts contain the same library more than once or compatibility code for browsers that are no longer in use. Both enlarge the download without benefit.
    • Number of page elements
      Tests how many HTML elements the page consists of. A very large number slows down every calculation of the browser, while loading as well as while scrolling.
    • Text visible while fonts load
      Tests whether text is shown in a fallback font until the web font has arrived. Without that instruction the text stays invisible for that time.
    • Instant return with the back button
      Tests whether the browser can keep the page in memory, so that it appears at once when a visitor returns to it with the back button.
    • Smooth animations
      Tests whether animations change only properties the browser can handle without recalculating the page. Other animations stutter on weaker devices.
    • Main image loaded with priority
      Tests whether the largest image of the visible area is loaded right away and with priority. It decides when the page feels loaded.
    • No outdated browser functions
      Tests whether scripts use functions that browsers have marked as outdated. Outdated functions are removed by browsers after a notice period.

    Images

    Weight 18 in the group 18.0 % of the group score 9 checks
    • Images load
      Tests whether every image on the page can actually be fetched. A broken image usually points to a file that was renamed or deleted after a relaunch.
    • Stated image size
      Tests whether images state their width and height. Without them the browser does not know how much space to keep free, so the text jumps as soon as the image arrives.
    • Images not delivered oversized
      Tests whether images are transferred much larger than they are shown. Scaling them down to the size actually displayed is usually the biggest single saving in loading time on a page.
    • Modern image format
      Tests whether images are delivered as WebP or AVIF instead of JPEG or PNG. At the same visible quality these formats need markedly less data, and every current browser understands them.
    • Images further down load on demand
      Tests whether images outside the visible area are loaded only when a visitor scrolls to them. Loaded right away they delay the visible area.
    • Images sufficiently compressed
      Tests whether images would be considerably smaller at the same visible quality if they were compressed more strongly.
    • Animations not as large GIF files
      Tests whether animations are delivered as large GIF files. A video needs a fraction of the data for the same animation.
    • Images shown undistorted
      Tests whether images are shown in the ratio of width to height that the file has. Otherwise they appear stretched or squashed.
    • Images sharp on high-resolution displays
      Tests whether images have enough pixels for the area they are shown in. Too coarse a file looks blurred on current phones and laptops.

    Sustainability

    Weight 8 in the group 8.0 % of the group score 3 checks
    • Transferred data volume
      Measures how many bytes a single visit transfers. Large images and videos dominate this figure; reducing them saves loading time, mobile data allowance and energy at the same time.
    • Hosting on renewable energy
      Tests whether the Green Web Foundation lists the hosting provider of this site as running on renewable energy. The directory is not complete, so an unknown result is not a defect; ask your provider about it.
    • Number of requests
      Counts how many separate files a single visit loads. Every request costs a round trip and energy; very high numbers usually come from tracking, advertising and embedded services.

    AI Visibility

    Weight 10 in the group 10.0 % of the group score 7 checks
    • AI crawlers admitted
      Tests whether the robots.txt admits the crawlers of the AI assistants. Shutting them out is a legitimate decision; it does mean the site cannot be quoted in their answers.
    • No accidental exclusion
      Tests whether the robots.txt shuts AI crawlers out although the rest of the file is open to search engines. That combination usually comes from a copied example rather than a decision.
    • llms.txt present
      Tests whether the site offers an llms.txt, a short summary of what is where for AI assistants. It is a young convention and no duty, but a cheap way of being understood correctly.
    • Instructions against AI use
      Tests whether the page declares that its content is not to be used for AI training. That is a legitimate position and no defect; it is listed so that whoever maintains the page next sees the decision.
    • Content readable without JavaScript
      Tests whether the text of the page is already in the delivered document. Many assistants do not execute scripts, so content that is assembled in the browser is invisible to them.
    • Quotable description of the page
      Tests whether the page describes itself in machine-readable form, for example as an article, a business or a product. Without it an assistant has to guess from the running text what this page is and who publishes it.
    • WebMCP tools described completely
      Tests, for pages that offer tools to AI agents through WebMCP, whether every tool carries a name, a description and named parameters. Pages without WebMCP are not affected.

    Trust & transparency

    Group weight 8 8.0 % of the overall score

    Trust & Transparency (heuristic checks)

    Weight 70 in the group 100.0 % of the group score 7 checks
    • Contact option findable
      Tests whether the page names a way of getting in touch, for example a contact page, a mail address or a telephone number. Visitors look for it before they buy or enquire.
    • Page about the provider
      Tests whether the site says who is behind it, beyond the imprint. A short page about the company or the team is one of the most frequently visited pages of a small site.
    • No pressure-building design
      Tests whether the page uses artificial scarcity or countdowns to hurry visitors along. Such elements damage trust and, where the scarcity is not real, are also an unfair commercial practice.
    • Trust seal can be looked up
      Tests whether a displayed trust seal links to its own certificate or profile page at the provider that issued it. Only that page lets a visitor tell a current certificate from a graphic that was copied or has long expired.
    • Countdown really runs
      Tests whether a countdown in the shop keeps running and does not start over when the page is loaded again. A deadline that restarts with every visit pretends a time pressure that does not exist, which the law lists as an unfair commercial practice in every case.
    • No purchase notifications of other visitors
      Tests whether the page announces purchases by other visitors, such as "Anna from Berlin has just purchased". Visitors cannot check such messages, and invented ones mislead about the demand for a product.
    • Responsible practitioner named
      Tests, for practices of the healing professions only, whether the site names who treats there and with which qualification. Search engines rate health pages without a recognisable responsible person low, and patients look for exactly that before they book.

    02 Scoring

    How the score is calculated

    Category score

    Each check of a category ends as passed, violated, uncertain or not checked. The category score is the share of its check budget that holds up, from 0 to 100. A check that could not run takes no part, so an unmeasured area neither helps nor hurts.

    Group score

    The group score is the weighted mean of its measured category scores, using the weights listed above. A category without a score drops out of both the sum and the weights.

    Malus for severe findings

    A weighted mean alone would dilute a serious defect. Every critical finding therefore subtracts 6 points and every high-severity finding 3 points from the score of its group. The malus of a group is capped at 30 points, and no score falls below 0.

    Overall score

    The overall score is the weighted mean of the group scores, using the group weights. Only groups with a score take part, which is why the shares above add up to 100 % across the active groups.

    Cap for severe defects

    A mean lets three good groups hide one at the floor. After the mean, the overall score is therefore capped, and the lowest cap wins: one critical finding caps it at 79, two or more at 64, a group below 50 at 79 and a group below 25 at 49. A page without such defects keeps its mean. The report then names both numbers and the reason.

    Unreachable pages

    If the page itself cannot be opened, the scan shows no overall score. The DNS and mail findings measured without the page remain visible on their own.

    03 Scale

    Bands and ranks

    Scores from 80 upwards are shown in green, from 50 to 79 in amber and below 50 in red.

    100 Legendary 90-99 Excellent 80-89 Strong 65-79 Solid 50-64 Needs work 25-49 Weak 0-24 Critical

    Trophy ladder

    Badge, leaderboard and monitor mail show a trophy. Each rung presumes the one below it, so a site holds the highest trophy up to which every rung is met.

    Bronze
    • overall score from 50
    • every group from 25
     Silver
    • overall score from 65
    • every group from 50
    • no critical finding
     Gold
    • overall score from 80
    • every group from 65
    • at most 2 high findings
     Platinum
    • overall score from 90
    • every group from 80
    • no high finding
     Diamond
    • overall score from 97
    • every group from 90
    • no finding above low

    04 Not checked

    Categories that are currently not checked

    These categories exist in the code but are dormant. They are not checked, produce no findings and do not count towards any score, so a report says nothing about them.

    E-Commerce Compliance not checked Advertising Claims Risk not checked Local & Hospitality Readiness not checked

    05 Limits

    What the scanner cannot tell you

    Deliberately not checked

    The scanner gives no legal advice and does not judge whether a site is compliant as a whole. It does not review the content of texts beyond the signals listed above, does not test business processes such as ordering or contract flows, and does not assess internal systems, servers or data handling that are not visible from outside.

    Why results can differ between two scans

    • Network: timeouts, packet loss or a slow response can stop a check from running, and it then counts as not checked.
    • CDN and edge servers: a content delivery network can answer from a different server with different headers, cookies or certificates on each request.
    • Time: sites change, consent banners and third-party scripts load conditionally, and certificates or domains approach their expiry.
    • AI assessment: some checks, such as reading a privacy policy, are judged by a language model. Its answer can vary slightly between two runs on the same text.

    Limits of the scanner

    • Only publicly visible signals: the scanner sees what any browser receives from the page and its DNS records, nothing more.
    • No penetration test: it does not try to exploit vulnerabilities, guess passwords or send attack traffic.
    • No authentication: pages behind a login, a paywall or a customer account are not scanned.

    See the methodology applied to your website

    The scan takes about a minute and shows every check with its result.

    Scan a website
    Recent scans Guides Local leagues Pricing Methodology For hosters API Data protection Imprint Accessibility Terms Cancel contracts here © 2026 Erseni