Free website scan
A passive scan checks security headers, TLS, consent, technical SEO, Core Web Vitals and how visible you are to AI systems. You get a report with a rating, technical evidence, priorities and concrete next steps.
One free scan per domain within 24 hours.
No account needed · Passive scan · No changes to your website
No plugin, no agent, no installation. The scan behaves like a crawler: read-only requests to up to 8 pages, plus DNS records and the TLS certificate. It identifies itself as WebSecureAudit in the user agent, runs no attacks and guesses no credentials. 17 areas checked, results within minutes as a PDF by email.
The report shows not only what stands out, but how relevant a finding is, why it matters, how to fix it, what to tackle first and roughly what the fix will cost you.
An overall score from 0 to 100 with a release verdict: cleared, review needed or blocked. Every finding carries a severity from blocker to info and a level of evidence – technically observed, self-declared or document on file.
Every finding lands in exactly one implementation phase, from immediate action to long-term work. You work the list top to bottom instead of guessing what comes first.
Every finding comes with technical evidence – the header line, the HTTP status, the URL – plus a recommendation, an effort range and the standard it refers to: GDPR Art. 32, OWASP Top 10, § 25 TDDDG, the German Accessibility Act, the AI Act.
The example report shows the full structure of a scan – rating, findings, evidence, priorities and actions. The subject was a deliberately misconfigured demo shop, so that every kind of finding appears.
16 out of 100 · Grade E Release blocked · 15 blockers · 34 high findings · Excerpt from the example report
Blocker
Production secrets or source code are publicly retrievable; credentials must be rotated.
/.env → HTTP 200 (49 bytes)17 areas, grouped by what they tell you. Every finding comes with the evidence it rests on.
HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer and Permissions Policy. Cookie flags Secure, HttpOnly and SameSite, CORS wildcards, mixed content, forms without a CSRF token or served over HTTP. Plus TLS protocols, certificate chain and remaining validity.
What sits on the server but is nobody's business: .env, .git, phpinfo.php, debug logs, backup archives, forgotten wp-config copies, open directory listings. The most common blocker in the report.
Which consent tool is in use, tracking before consent, pre-ticked boxes, a missing reject or withdraw path, unclassified cookies. Plus legal notice, privacy policy, terms and right of withdrawal checked for completeness – as technical indicators for the GDPR and § 25 TDDDG.
Title and meta description by length and duplication, H1, canonical, robots.txt and XML sitemap, unintended noindex, redirect chains, soft 404s, broken internal and external links, image alt text, www/non-www duplicates, Open Graph, Twitter Card, hreflang and html lang.
Whether llms.txt exists and whether GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot, Google-Extended and Applebot-Extended get through or are blocked in robots.txt. Plus structured data as Schema.org JSON-LD, whether your content is readable without JavaScript, and how citable the page is for generative search.
LCP, INP and CLS from the Chrome UX Report – field data from real visitors, the numbers Google actually ranks on – alongside the Lighthouse lab value. Plus TTFB, render-blocking resources, missing compression, cache headers, third-party scripts, image formats, image dimensions and lazy loading.
SPF, DKIM and DMARC in DNS, plus the MX records. If one of them is missing or weak, order confirmations and newsletters land in spam – or someone sends mail in your name.
Heading order, form labels, landmarks, skip link, tabindex and the accessibility statement required by the German Accessibility Act. Mobile: viewport, blocked zoom, text too small, fixed widths, the wrong keyboard type on form fields.
The detected platform and libraries with their versions, server banners, authentication and session handling. What sits behind the login is only visible to the backend audit.
Every finding states what it rests on. Technically observed means the scan measured it itself and attaches the evidence. Other points can only be proven organisationally – a deletion policy, a record of processing activities, a data processing agreement; there the report states which document is missing instead of judging it. Legal classifications are technical indicators and are no substitute for legal advice.
Load time is not estimated but measured at Google – through the same interface PageSpeed Insights draws its numbers from. The report keeps the two apart: the lab value, produced under standardised conditions and therefore comparable, and the field data from real visitors over the past 28 days – the number Google actually ranks on. Where the two disagree, the field wins.
You enter your website and your email address.
The crawler reads up to 8 pages, headers, certificate and DNS. Usually under a minute.
As a PDF by email: score, release verdict, individual findings with evidence, phase plan and cost indication.
Scan again after deploying. The report shows which finding is gone – and which one is new.
One scan is enough? Then you need no account. Enter domain and email address, the report arrives as a PDF. We store nothing about you beyond the address it goes to.
Good for a one-off stocktake – before a relaunch, after a handover, or when you want to know where a website currently stands.
Start auditA single scan is a snapshot. Deployments, plugin updates, a new tracking script, an expired certificate – any change can bring back a finding you fixed long ago. With a free account you see that, instead of learning it at the next random scan.
Many technical findings translate directly into structured tasks for Claude. Next to the report sits a claude-fixes/ folder with project information, ready-made prompts, file hints and a run.sh – the basis for the work, not the work itself. A missing security header or an exposed .env becomes a task of minutes instead of a research job.
Claude prepares the technical groundwork. Review, sign-off and legal judgement stay with a human. The 94 % in the example is the share of findings for which a task package is generated – not the share that fixes itself.
Whether it worked is what a new scan tells you: it checks specifically whether the finding is gone.
The standard scan is a front-end audit. It sees what gets delivered: rendered markup, response headers, the TLS certificate, embedded scripts and third-party requests – exactly what a crawler or a visitor sees. Server-side code, user accounts and plugin versions stay shut. For those there is the backend audit. For it you store read access in the portal – a WordPress application password, a Shopify admin API token, basic auth or a session cookie, depending on the system. Only after proving the domain by TXT record or file, so that nobody has someone else's system scanned. You need an account for this; you start the scan yourself.
Access adapts to the system: an account with read rights, an API token, basic auth or a session cookie. Read rights are enough – nothing is changed, installed or deleted.
Going further: the system audit on request. For everything beyond the backend audit – manual review, code analysis, custom web applications – write to info@websecureaudit.de with the domain and the system in use. You get a proposal covering scope and price; access is set up only afterwards. This is a separate, paid arrangement, not a self-service button. Request a system audit
Not every finding matters equally. An exposed .env is a different problem from a missing alt text – but both sit in the same list if nobody sorts them. The report orders actions by urgency and sensible sequence; every finding lands in exactly one phase with a time window, a number of actions and a cost indication. The windows and goals come from the tool itself, the numbers from the example report.
immediately
Everything blocking release: close blockers, settle open scope and evidence questions.
11 actions in the example report
0–2 weeks
Close acute risks before they are exploited. Imminent danger.
2 actions in the example report
2–6 weeks
Bring the technical base to a maintainable state, reduce the attack surface for good.
28 actions in the example report
6–14 weeks
Become findable in classic search and in AI systems, improve load times and conversion.
23 actions in the example report
3–6 months
Polish, accessibility, monitoring and a process that holds the standard.
1 action in the example report
One scan per domain per 24 hours is free – full feature set, no account, no payment details. If you need more in the same window, during a relaunch for instance, 5 further scans cost 4,90 € – one-off, no subscription, no sign-up.
The allowance belongs to the domain, not to the account – a paid scan therefore counts with or without an account.
Why a limit at all: every scan puts load on someone else's site and costs us compute, and scanning the same domain five times a day yields almost the same result five times.