109 automated checks on every scan

Encrypted transport, protection headers, secrets forgotten in the code and exposed backends: where quickly-built (especially AI-built) sites really get hurt.

• Automatic HTTPS redirect. The http:// version must immediately lead to https://, or traffic can travel in the clear.
• TLS certificate validity. Expired or invalid certificate = “not secure” browser warning and visitors running away.
• Mixed HTTP content on HTTPS pages. Scripts or images loaded in the clear inside an encrypted page open the door to tampering.
• HSTS (Strict-Transport-Security). Tells the browser to always use HTTPS, even on the first visit.
• TLS certificate expiry. We warn you if the certificate expires within 30 days: on expiry the site suddenly blocks for everyone.
• SPF record (email anti-spoofing). Without SPF anyone can send email in your domain’s name, and yours lands in spam.
• Domain DMARC policy. Tells mail servers what to do with forged email: missing or monitor-only, spoofing gets through.
• JS libraries with known CVEs. jQuery, Bootstrap, Lodash and others in versions with publicly documented vulnerabilities (with CVE ids).
• End-of-life (EOL) JS libraries. Unsupported libraries (AngularJS, Vue 2): new flaws will never receive a patch.
• Content-Security-Policy. The main defense against injected scripts (XSS): without it, a hostile script can do anything.
• Clickjacking protection (X-Frame-Options). Prevents your site from being framed inside scam pages to steal clicks.
• MIME sniffing (X-Content-Type-Options). Stops the browser from “guessing” file types and executing content it should not.
• Referrer-Policy. Controls how much navigation information you leak to third-party sites.
• Permissions-Policy. Restricts access to camera, microphone and sensors by third-party scripts.
• Server software version disclosure. Advertising your server or framework version hands attackers the list of exploits to try.
• .env file publicly reachable. The file with passwords and API keys downloadable by anyone: one of the worst (and most common) mistakes.
• .git folder publicly reachable. An exposed .git folder lets anyone download your entire source code, secrets included.
• Source maps exposed in production. Debug maps reveal the original code, often with comments and secrets.
• AWS keys in public code. An AWS access key in the JavaScript bundle = someone else running up your cloud bill.
• Stripe secret keys in public code. An exposed Stripe secret key allows refunds, charges and access to payment data.
• Exposed Google API keys. Unrestricted Google keys can generate costs and abuse on your services.
• Supabase service-role key exposed. The service-role key bypasses every database security rule: in the frontend it is a disaster.
• Supabase Row Level Security. Tables readable without login: we verify RLS rules actually protect your data (the fact only, never the data).
• Firebase database access rules. Realtime Database with open rules = every user’s data public. We check without downloading anything.
• Content-Security-Policy strength. A CSP with ’unsafe-inline’ or open sources looks like protection but stops nothing: false safety is worse than none.
• Window isolation (Cross-Origin-Opener-Policy). Stops a page opened from your site from keeping control of your tab.
• Cookie security flags (Secure, HttpOnly, SameSite). Without these flags a session cookie is readable by JavaScript and attached to other sites’ requests: account theft and CSRF.
• Third-party script integrity (SRI). If the CDN hosting a library is compromised (it happened to polyfill.io, 100k+ sites), without integrity the browser runs the swapped code.
• Form submission over encrypted connection. A form posting to http:// from an https:// page sends data in the clear, and the browser warns the user on submit.
• Protected external links (rel="noopener"). Without noopener the page you open can change your tab’s address while the user is looking elsewhere.
• DKIM email signing. Without DKIM your mail authenticates worse and lands in spam more often; with it, recipients can verify the message is really yours.
• DMARC reporting (rua). A DMARC policy with no reporting address is blind: you cannot see who writes in your name, and you can never tighten it.
• Enforced encryption between mail servers (MTA-STS). TLS between mail servers is optional: without MTA-STS an attacker can force plaintext delivery and read mail in transit.
• DNSSEC. Signs the domain's DNS answers: without it, visitors can be redirected to a server that is not yours.
• CAA record. Declares which authorities may issue certificates for your domain. Without it, any CA in the world can issue one in your name.

The compliance basics that regulators (and your users) expect from any European site.

• Cookie consent banner. If you use non-technical cookies you need a consent banner: its absence is the most visible violation.
• Reachable privacy policy. A linked, readable privacy policy is mandatory if you process any personal data.
• Trackers active before consent. Analytics and pixels firing before the “Accept” click violate GDPR: we detect them.
• Cookie policy as a separate document. EU guidance requires a standalone cookie notice with the list, lifetimes and third parties: a paragraph inside the privacy policy is not enough.
• Reachable terms and conditions. Mandatory if you sell; for everyone else they are the only document defining what you promise and what you do not.
• Company details in the footer (VAT number, legal name). EU and Italian law require them online too, and it is the first thing anyone checks before trusting you.
• Fonts loaded without sending data to Google. Google Fonts from the CDN sends every visitor’s IP to the US without consent: the violation behind thousands of EU demand letters.
• Privacy consent in data collection forms. A form asking for email or phone with no checkbox and no notice collects data with no provable legal basis.

What a visitor (or customer) actually runs into: broken links, errors, dead ends.

• Broken links. Links leading to pages that do not exist: trust down, SEO penalized.
• JavaScript console errors. Console errors often mean broken features nobody noticed.
• Visible stack traces or technical errors. Raw error messages on the page scare users and reveal internals.
• HTTP 404 status on non-existent pages. Answering 200 on an address that does not exist (soft 404) makes Google index empty, made-up pages.
• Custom 404 page. The bare server 404 is a dead end: no message, no link back into the site.
• Reachable contact channel. Email, form or contact page: without one, the site loses credibility (and customers).
• Favicon present. The icon in the browser tab and in search results: missing, the site looks unfinished.
• Server response time. Slow responses frustrate users before the page even loads.
• User journeys without dead ends. We simulate the main navigation: buttons leading nowhere, broken flows.
• The domain receives the email addresses published on the site. @yourdomain addresses on the site but no MX record: those messages bounce and customer requests are lost.
• IPv6 reachability. Several mobile networks are now IPv6-only: with no AAAA record they reach you through translators, adding latency and failures.
• Name server redundancy. A single name server is one point of failure for site and email together. The standard asks for at least two.
• Domain expiry. An expired domain takes down site and mail, and after the grace period anyone can register it instead of you.
• Images that actually load. Images answering with an error leave empty boxes: on a product page it is the most immediate abandonment signal.
• HTTP/2 or newer protocol. On HTTP/1.1 the browser queues requests one at a time: on a page with dozens of files that is a delay on every visit.

The fundamentals to be found on Google and look good when your link gets shared.

• Page <title> tag. The title is the first thing Google shows: missing or empty, you are invisible.
• Meta description. The description under the title in search results: without it, Google decides for you.
• H1 heading structure. One clear H1 per page: zero or too many confuse search engines.
• Heading hierarchy (h1 → h2 → h3). Headings must not skip levels: the correct hierarchy is the map Google and screen readers use to understand the page.
• Canonical URL. Prevents the same page from appearing as duplicated, diluting your ranking.
• robots.txt file. Tells search engines what they may crawl: its absence signals neglect.
• robots.txt does not block search engines. A "Disallow: /" left over from staging erases the site from Google, and you cannot see it from the page.
• Sitemap declared in robots.txt. The Sitemap: directive is how a crawler that does not know you finds every page right away.
• XML sitemap. The site map helps Google find and index all your pages.
• JSON-LD structured data (schema.org). Tells Google and AI assistants what you are: without it, no rich results in the SERP.
• JSON-LD structured data format. A JSON-LD block with a syntax error or no @context/@type is silently discarded: useless markup.
• Social preview (Open Graph). Without Open Graph, a shared link looks bare on social and chat: no image, no title.
• Declared page language. The lang attribute helps search engines and screen readers understand the content.
• Mobile viewport. Without the viewport meta the site looks tiny on phones: instant mobile penalty.
• Search engine indexability. A forgotten noindex (common on generated sites) erases you from Google.
• AI crawler access (ChatGPT, Claude, Perplexity). If robots.txt blocks them — often a CDN default — your site cannot be cited in assistant answers.
• Business identity in structured data. The Organization or LocalBusiness node tells engines (and AIs) who you are: without it they summarise you without citing you.
• Title length in search results. Past 65 characters Google truncates, below 25 it rewrites: either way the title you chose is not the one users read.
• Meta description length. Too short and Google replaces it, too long and it gets cut mid-sentence: it is your only free ad space.
• Social preview completeness (image, text, URL). Partial Open Graph = crippled preview: without og:image the shared link renders as a text-only box.
• X/Twitter preview (Twitter Card). Without twitter:card the link on X goes out bare instead of with the large preview.
• Alternate language declaration (hreflang). On a multilingual site, a wrong hreflang makes versions compete and lands users in the wrong language.

The speed your users actually perceive, measured with Google PageSpeed.

• Mobile loading performance. Core Web Vitals via PageSpeed (mobile strategy, the measure Google uses for ranking): a slow site loses visitors and positions.
• Desktop loading performance. Same measure with the desktop strategy: on a big screen, speed expectations are even higher.
• Modern image formats (WebP/AVIF). Images in JPEG/PNG where modern formats would weigh far less at the same quality.
• Image weight and sizing. Images poorly compressed or served larger than displayed: useless weight on every visit.
• Unused JavaScript. Code downloaded and processed that the page never uses: slows down precisely the slowest devices.
• Render-blocking resources. Synchronous CSS and scripts keeping the page blank while content is already there.
• Text compression (gzip/brotli). Without compression HTML, CSS and JS weigh double: the fix is one server configuration line.
• Static asset caching. Assets re-downloaded on every visit instead of read from cache: punishes returning visitors.
• Total page weight. Beyond 3MB, loading is felt on any non-perfect connection.
• Real-user Core Web Vitals. CrUX data from the site's real Chrome users: the measure Google actually uses in ranking.
• CDN delivery. With no CDN every visitor downloads everything from the origin server, and a traffic spike has no buffer.
• Text visible while fonts load. Without font-display the browser keeps text invisible for up to three seconds: a laid-out but wordless page.
• Deferred image loading. Without loading="lazy" the browser also fetches bottom-of-page images right away, stealing bandwidth from what is on screen.
• Declared image dimensions. With no width and height the content jumps as images arrive: the leading cause of the layout instability Google penalises.
• JavaScript and CSS minification. Code shipped with indentation and comments is dead weight on every visit: one build step fixes it.

The European Accessibility Act has applied since 28 June 2025: accessibility is a legal obligation whose deadline has already passed. These checks read the page markup and find the most common barriers.

• Alternative text on images. With no alt, whoever cannot see the image loses the information: it is the first criterion checked in any conformance review.
• Labels on form fields. An unlabelled field is announced as "text box" and nothing more: on a payment form that is a full barrier.
• Accessible name on icon-only buttons and links. Hamburger, close X, cart: without aria-label they are read out as "button" and nothing else.
• Descriptive title on iframes. Maps and embedded videos with no title are announced as "frame", without saying what is inside.
• Headers in data tables. Without <th> a price list becomes a sequence of unlabelled numbers for anyone listening to it.
• Zoom allowed on mobile. user-scalable=no stops users from enlarging the page: people with low vision cannot read it on a phone.
• Page structure (main, nav, header). Landmarks are the map that lets people jump to the content instead of crossing the whole menu.
• "Skip to content" link. Without it, keyboard users cross the header and the menu on every page change.
• Consistent tab order. A positive tabindex builds a sequence of its own that does not match what is on screen.
• Controllable autoplaying audio and video. Audio that starts by itself talks over the screen reader's voice and cannot be stopped.
• Captions on videos. Without captions, speech is only available to those who can hear it — and to the majority watching with the sound off.
• Correct use of ARIA attributes. Invented roles or aria-hidden on still-focusable elements make things worse rather than better.
• Link text that makes sense out of context. A list of "click here" tells apart nothing, neither for a screen reader nor for Google.
• Accessibility statement. The document declaring how far conformance has got and how to report a barrier. For many organisations it is mandatory.