Methodik – So funktionieren die Webalyzr-Analysen
Transparenz ist ein Grundprinzip von Webalyzr. Auf dieser Seite wird für jedes Analyse-Tool detailliert erklärt, welche Pruefungen durchgefuehrt werden, welche Protokolle und Methoden zum Einsatz kommen und welche Einschraenkungen bestehen. Alle Checks nutzen ausschliesslich oeffentlich zugaengliche Informationen: DNS-Abfragen, HTTP-Requests, TLS-Handshakes und WHOIS-Lookups. Es werden keine invasiven Scans durchgefuehrt und keine Daten auf dem Zielserver veraendert.
Methodik & FAQ
Hier erfahren Sie, wie jedes unserer Analyse-Tools technisch funktioniert: welche Protokolle und Methoden verwendet werden, was genau geprüft wird und welche Einschränkungen es gibt.
Netzwerk & Server15
Was wird geprüft?
Prüft die Erreichbarkeit eines Hosts und misst die Antwortzeit (Latenz).
Wie funktioniert es?
Es werden 5 TCP-Verbindungen zum Zielhost aufgebaut (Port 443). Gemessen werden Minimum, Durchschnitt und Maximum der Antwortzeiten sowie Paketverlust.
Beispiel-Ergebnis
google.com → Min: 12ms, Avg: 14ms, Max: 18ms, Paketverlust: 0%
Hinweise
Kein ICMP-Ping, sondern TCP-Connect. Einige Firewalls blockieren TCP-Verbindungen auf Port 443.
Was wird geprüft?
Zeigt den Netzwerkpfad (alle Zwischenstationen) zwischen unserem Server und dem Zielhost.
Wie funktioniert es?
UDP-Pakete werden mit schrittweise erhöhtem TTL-Wert (Time-to-Live) gesendet. Die Ergebnisse werden per SSE-Stream in Echtzeit übertragen.
Beispiel-Ergebnis
Hop 1: 10.0.0.1 (1ms) → Hop 2: 192.168.1.1 (5ms) → ... → Hop 9: 142.250.185.14 (14ms)
Hinweise
Maximal 30 Hops. Einige Router antworten nicht (erscheinen als *).
Was wird geprüft?
Prüft, welche Netzwerk-Ports auf einem Host geöffnet sind.
Wie funktioniert es?
TCP-Connect-Scan auf 21 gängige Service-Ports: 21 (FTP), 22 (SSH), 25 (SMTP), 53 (DNS), 80 (HTTP), 110 (POP3), 143 (IMAP), 443 (HTTPS), 465 (SMTPS), 587 (Submission), 993 (IMAPS), 995 (POP3S), 1234 (Misc), 3306 (MySQL), 3389 (RDP), 4444 (Misc/Metasploit), 5432 (PostgreSQL), 5900 (VNC), 8080 (HTTP-Alt), 8443 (HTTPS-Alt), 9443 (HTTPS-Alt). Für jeden Port wird versucht, eine TCP-Verbindung aufzubauen (Timeout: 3 Sekunden). Antwortet der Port, gilt er als offen.
Beispiel-Ergebnis
example.com → Port 80 (HTTP): offen, Port 443 (HTTPS): offen, Port 22 (SSH): geschlossen, ...
Hinweise
Nur TCP, kein UDP-Scan. Ports werden in 6er-Batches geprüft, um den Zielhost nicht zu überlasten.
Was wird geprüft?
Umfassende DNS-Analyse: Fragt alle Record-Typen (A, AAAA, MX, TXT, CNAME, NS, SOA, CAA, SRV) ab und entdeckt Subdomains automatisch über mehrere Methoden.
Wie funktioniert es?
1) Zone Transfer (AXFR) wird versucht – liefert bei Erfolg sämtliche DNS-Records der Zone. 2) Certificate Transparency Logs (crt.sh) werden abgefragt, um Subdomains mit SSL-Zertifikaten zu entdecken. 3) Bekannte Subdomain-Muster werden geprobt: gängige Hostnames (www, mail, ftp, autodiscover, etc.), DKIM-Selektoren verschiedener Provider (Microsoft 365, Google, IONOS, Mailchimp, Proton Mail u.a.), Mail-Konfiguration (_dmarc, _mta-sts, _acme-challenge) und SRV-Records (Autodiscover, SIP, XMPP, IMAP). Wildcard-DNS wird erkannt und herausgefiltert, ebenso wie CNAME-aufgelöste A/AAAA-Records, die keine echten Einträge sind. Alle Abfragen laufen parallel über Google/Cloudflare DNS.
Beispiel-Ergebnis
example.com → @ A: 93.184.216.34, @ MX: mail.example.com (Prio 10), ftp A: 93.184.216.34, _dmarc TXT: v=DMARC1; p=reject, selector1._domainkey CNAME: ...
Hinweise
Da DNS kein "Alle Records auflisten"-Kommando hat, können nur Records gefunden werden, deren Hostnamen bekannt sind oder durch AXFR/CT-Logs entdeckt werden. Provider-spezifische Records mit zufälligen Namen (z.B. IONOS-interne DKIM-Hashes) sind von außen nicht auffindbar.
Was wird geprüft?
Zeigt Registrierungsinformationen einer Domain: Registrar, Erstellungsdatum, Ablaufdatum und Nameserver.
Wie funktioniert es?
Primär wird das RDAP-Protokoll (Registration Data Access Protocol) verwendet. Bei Domains ohne RDAP-Unterstützung erfolgt ein Fallback auf den zuständigen Whois-Server per TCP.
Beispiel-Ergebnis
example.de → Registrar: DENIC eG, Erstellt: 2005-01-01, Ablauf: 2026-01-01, Status: connect
Hinweise
Aufgrund der DSGVO/GDPR werden bei europäischen Domains (z.B. .de, .at, .eu) kaum noch personenbezogene Daten wie Inhabername oder Adresse angezeigt. Die meisten Registrare reduzieren die Whois-Ausgabe auf technische Daten (Nameserver, Ablaufdatum, Registrar).
Was wird geprüft?
Ermittelt Geolocation, Netzwerkzugehörigkeit (ASN) und Reverse-DNS einer IP-Adresse.
Wie funktioniert es?
Abfrage bei RIPE/ARIN über das RDAP-Protokoll für Netzwerkdaten. Reverse-DNS wird per PTR-Record-Abfrage ermittelt.
Beispiel-Ergebnis
8.8.8.8 → Google LLC, AS15169, Mountain View, US, Reverse-DNS: dns.google
Was wird geprüft?
Prüft das SSL/TLS-Zertifikat einer Domain auf Gültigkeit, Ablaufdatum und Zertifikatskette.
Wie funktioniert es?
Ein TLS-Handshake wird durchgeführt und das Zertifikat samt Kette ausgelesen. Geprüft werden: Common Name, SANs, Aussteller, Gültigkeitszeitraum und Ketten-Vollständigkeit.
Beispiel-Ergebnis
example.com → Aussteller: Let's Encrypt, Gültig bis: 2026-05-15, Kette: 3 Zertifikate, TLS 1.3
Was wird geprüft?
Verfolgt die komplette Weiterleitungskette einer URL und zeigt jeden HTTP-Statuscode.
Wie funktioniert es?
HTTP-Requests werden mit manueller Redirect-Behandlung (redirect: manual) durchgeführt. Jeder Hop wird mit Statuscode, Location-Header und Antwortzeit protokolliert.
Beispiel-Ergebnis
http://example.com → 301 → https://example.com → 301 → https://www.example.com → 200 OK
Hinweise
Maximal 10 Hops, um Endlosschleifen zu vermeiden.
Was wird geprüft?
Prüft, ob ein Server HTTP/2 und HTTP/3 unterstützt.
Wie funktioniert es?
HTTP/2-Erkennung über ALPN-Negotiation beim TLS-Handshake. HTTP/3-Erkennung über den Alt-Svc-Header in der HTTP-Antwort.
Beispiel-Ergebnis
example.com → HTTP/1.1: ja, HTTP/2: ja, HTTP/3: nein
Was wird geprüft?
Prüft, ob eine IP-Adresse auf gängigen Spam-Sperrlisten (RBLs) gelistet ist.
Wie funktioniert es?
Die IP-Adresse wird in reversed Form gegen ca. 30 bekannte DNS-basierte Blacklists (RBLs) abgefragt. Eine DNS-Antwort bedeutet, dass die IP gelistet ist.
Beispiel-Ergebnis
203.0.113.5 → Gelistet auf: Spamhaus ZEN, SORBS – Nicht gelistet auf: 28 weiteren RBLs
Hinweise
Nur IPv4-Adressen. Ergebnisse können je nach RBL-Aktualisierung leicht verzögert sein.
Was wird geprüft?
Prüft, ob DNS-Änderungen bei wichtigen öffentlichen Nameservern bereits angekommen sind.
Wie funktioniert es?
Der angegebene DNS-Record wird bei 10 großen öffentlichen DNS-Servern abgefragt: Google (8.8.8.8, 8.8.4.4), Cloudflare (1.1.1.1, 1.0.0.1), Quad9 (9.9.9.9), OpenDNS (208.67.222.222, 208.67.220.220), Level3 (4.2.2.1), Comodo (8.26.56.26) und Neustar (64.6.64.6). Die Ergebnisse werden verglichen und der Propagation-Status in Prozent angezeigt.
Beispiel-Ergebnis
example.com (A-Record) → Google: 93.184.216.34, Cloudflare: 93.184.216.34, ... → Propagation: 100%
Hinweise
Es werden keine autoritativen Nameserver der Domain abgefragt, sondern öffentliche Resolver. Das Ergebnis zeigt, ob die Änderung bei den meistgenutzten DNS-Diensten angekommen ist.
Was wird geprüft?
Findet unsichere HTTP-Ressourcen auf HTTPS-Seiten, die Browser-Warnungen auslösen.
Wie funktioniert es?
Der HTML-Quellcode der Seite wird geladen und alle src- und href-Attribute analysiert. Ressourcen, die über http:// statt https:// geladen werden, werden als Mixed Content gemeldet.
Beispiel-Ergebnis
https://example.com → 2 Probleme: http://cdn.example.com/style.css (Stylesheet), http://example.com/logo.png (Bild)
Was wird geprüft?
Entdeckt Subdomains einer Domain über öffentliche Quellen.
Wie funktioniert es?
Abfrage der Certificate Transparency Logs über crt.sh. Zusätzlich DNS-Bruteforce-Prüfung gängiger Subdomain-Namen.
Beispiel-Ergebnis
example.com → www.example.com, mail.example.com, shop.example.com, api.example.com (4 gefunden)
Hinweise
Es werden nur öffentlich bekannte Subdomains gefunden. Interne oder nicht in CT-Logs veröffentlichte Subdomains werden nicht erkannt.
Was wird geprüft?
Analysiert die unterstützten TLS-Protokollversionen und Verschlüsselungs-Suiten eines Servers.
Wie funktioniert es?
Für jede TLS-Version (1.0, 1.1, 1.2, 1.3) wird ein separater Handshake-Versuch durchgeführt. Die ausgehandelten Cipher-Suiten werden nach Sicherheitsstufe bewertet.
Beispiel-Ergebnis
example.com → TLS 1.3: TLS_AES_256_GCM_SHA384 (stark), TLS 1.2: ECDHE-RSA-AES128-GCM-SHA256 (stark), TLS 1.1: nicht unterstützt
Hinweise
TLS 1.0 und 1.1 gelten als veraltet. Ein gutes Ergebnis zeigt nur TLS 1.2+ mit starken Ciphern.
Was wird geprüft?
Ermittelt den Hosting-Provider und ein eventuell vorgeschaltetes CDN einer Website.
Wie funktioniert es?
Die Domain wird per DNS aufgelöst, dann werden ASN-Lookup (Team Cymru), Reverse-DNS und ein HTTP-HEAD-Request parallel durchgeführt. Aus ASN-Organisation, Reverse-DNS-Hostname und HTTP-Headern (z.B. cf-ray, x-served-by) werden Hosting-Provider und CDN abgeleitet.
Beispiel-Ergebnis
example.com → IP: 104.21.5.123, CDN: Cloudflare, ASN: AS13335 (Cloudflare Inc.), Server: cloudflare
Hinweise
Hinter einem CDN wie Cloudflare ist der tatsächliche Origin-Hoster nicht ermittelbar, da alle Anfragen über das CDN geroutet werden.
E-Mail & DNS6
Was wird geprüft?
Umfassende Mail-Infrastruktur-Analyse: MX-Topologie (alle Prio-Stufen mit IPv4/IPv6/PTR/Reachability), echter STARTTLS-Handshake auf Port 25 mit Zertifikat-Parsing und Hostname-Matching, Implicit-TLS-Probe auf Port 465, Submission-Port 587 mit AUTH-Mechanism-Audit, DANE/TLSA-Lookup + Verification, VRFY/EXPN-User-Enumeration-Test, Open-Relay-Check, kompletter Mail-DNS-Stack (SPF/DMARC/DKIM/MTA-STS/TLS-RPT/CAA/BIMI), MX-Blacklist-Check und priorisierte Handlungsempfehlungen.
Wie funktioniert es?
Zuerst MX-Auflösung + Reverse-DNS, dann parallel: (1) klassische SMTP-Session für Banner/EHLO/Open-Relay/Transaction-Time. (2) Ausgehende STARTTLS-Verhandlung mit TLS-Upgrade und Zertifikat-Extraktion (Subject/Issuer/SAN/Wildcard/Ablauf/SPKI-Hash). (3) Implicit-TLS auf Port 465. (4) EHLO+STARTTLS auf Port 587 mit AUTH-Mechanism-Parse. (5) DANE-TLSA-Lookup und Vergleich gegen SHA-256-Hash des Live-Certs (usage=3, matching=1). (6) VRFY/EXPN-Test für User-Enumeration. (7) DNS-Stack über 13 häufige DKIM-Selektoren, SPF-Qualifier-Parse, DMARC-Breakdown, MTA-STS DNS + .well-known-Policy-Fetch, MTA-STS-vs-actual-MX-Match. (8) Blacklist-Check gegen Spamhaus ZEN, Spamcop, SORBS, Barracuda, CBL. (9) Regelbasierte Recommendation-Engine.
Beispiel-Ergebnis
example.com → 3 MX-Hosts · STARTTLS TLS 1.3 ECDHE-RSA-AES256-GCM · Cert *.example.com 84 Tage · SAN matcht ✓ · Submission 587 mit STARTTLS+AUTH PLAIN LOGIN · DANE verified · SPF -all · DMARC p=reject rua= ✓ · MTA-STS enforce · Blacklists clean · 4 Empfehlungen
Hinweise
Die Live-Handshake-Checks (TLS, STARTTLS, DANE, 465, 587) setzen eine ausgehende Verbindung auf Port 25/465/587 vom Scanner-Host voraus. Einige große Mailbox-Provider (u.a. Google/Gmail, GMX, T-Online, freenet, web.de) filtern eingehende Verbindungen von Cloud-/VPS-IP-Ranges besonders streng — insbesondere wenn der PTR-Record generisch ist. In solchen Fällen können TLS-Probes scheitern, obwohl die gescannte Domain technisch einwandfrei ist. Der Scanner meldet seine eigene Outbound-Erreichbarkeit (full/partial/none), damit echte Domain-Probleme von Scanner-seitigen Reputations-Limits unterschieden werden können. Die DNS-basierten Checks (SPF, DMARC, DKIM, MTA-STS, TLS-RPT, CAA, DANE-Lookup, Blacklists) funktionieren unabhängig davon zuverlässig. Das Tool sendet nie echte Mail; AUTH-Credentials werden nie übermittelt.
Was wird geprüft?
Analysiert den Zustellweg einer E-Mail, Verzögerungen und Authentifizierungsergebnisse (SPF, DKIM, DMARC).
Wie funktioniert es?
Die eingefügten E-Mail-Header werden geparst. Received-Header werden in chronologischer Reihenfolge dargestellt, Verzögerungen zwischen Hops berechnet und Authentication-Results ausgewertet.
Beispiel-Ergebnis
Hop 1 → Hop 2 (0.3s) → Hop 3 (1.2s, Verzögerung!), SPF: pass, DKIM: pass, DMARC: pass
Was wird geprüft?
Prüft, ob DKIM-Signaturen für eine Domain korrekt im DNS hinterlegt sind.
Wie funktioniert es?
DNS-TXT-Abfrage auf den _domainkey-Selektoren der Domain. Die gefundenen DKIM-Schlüssel werden auf Format, Schlüssellänge und Gültigkeit geprüft.
Beispiel-Ergebnis
example.com → Selektor "google": gefunden, RSA 2048-Bit, gültig. Selektor "default": nicht gefunden.
Hinweise
Ohne Kenntnis des genauen Selektors werden gängige Selektornamen durchprobiert (default, google, selector1, selector2, k1 etc.).
Was wird geprüft?
Prüft, ob eine Domain ein BIMI-Logo für die Anzeige in E-Mail-Clients konfiguriert hat.
Wie funktioniert es?
DNS-TXT-Abfrage auf default._bimi.[domain]. Wenn vorhanden, wird das referenzierte SVG-Logo abgerufen und auf Gültigkeit (SVG Tiny 1.2 Profil) geprüft.
Beispiel-Ergebnis
example.com → BIMI-Record: v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/cert.pem – Logo: gültig
Was wird geprüft?
Umfassende Exchange-Intelligence: erkennt Microsoft Exchange Server samt Version, Patch-Stand, bekannten CVEs und End-of-Life-Status und liefert zusätzlich Host-/TLS-Analyse, Port-Exposure, SMTP-Gateway-Fingerprint, den kompletten Mail-DNS-Stack sowie priorisierte Handlungsempfehlungen.
Wie funktioniert es?
Mehrstufige Analyse: (1) HTTP-Probes aller Exchange-Endpoints (Autodiscover, OWA, ECP, ActiveSync, EWS, OAB, MAPI/HTTP, RPC/HTTP, PowerShell, REST API) auf Haupt- und mail./autodiscover.-Subdomains mit Versionserkennung aus Response-Headern. (2) Autodiscover-POST mit echtem XML-Request. (3) TLS pro Host: Zertifikat (Subject, Issuer, SAN, Wildcard-Status, Ablauf) plus Versions-Matrix TLS 1.0/1.1/1.2/1.3. (4) Port-Exposure auf 25, 443, 465, 587, 993, 995. (5) SMTP-Handshake mit EHLO-Feature-Parse und STARTTLS-Verhandlung (Cipher/Protokoll). (6) Mail-DNS-Stack: SPF, DMARC-Breakdown (p/sp/rua/ruf/adkim/aspf), DKIM-Selector-Probe, MTA-STS (DNS + .well-known-Policy), TLS-RPT, CAA, BIMI, Nameserver. (7) MX-Blacklist-Check gegen Spamhaus ZEN, Spamcop, SORBS, Barracuda, CBL. (8) Abgleich gegen CVE-Datenbank (Static + NVD-Feed) und endoflife.date. (9) Regelbasierte Recommendation-Engine priorisiert alle Findings nach kritisch/hoch/info.
Beispiel-Ergebnis
example.com → Exchange SE 15.2.2562.17 erkannt, 5 SUs hinten, 16 NVD-CVEs, Wildcard-Cert 165 Tage, TLS 1.3 fehlt, DMARC ohne rua, MTA-STS fehlt, 9 priorisierte Empfehlungen
Hinweise
Port 25 wird bei manchen Scans vom Hoster blockiert, sodass der SMTP-EHLO-Block leer bleibt - alle anderen Intelligence-Daten werden trotzdem sauber geliefert. Das Tool arbeitet passiv, sendet nie echte Mail und meldet sich nur unauthentifiziert an Exchange-Endpoints.
Was wird geprüft?
Prüft, ob eine Domain DANE (DNS-Based Authentication of Named Entities) für die Absicherung von E-Mail-Transport einsetzt.
Wie funktioniert es?
Abfrage der TLSA-DNS-Records und Prüfung auf DNSSEC-Signierung. DANE erfordert DNSSEC, da die TLSA-Records sonst nicht vertrauenswürdig sind.
Beispiel-Ergebnis
example.com → TLSA-Record: 3 1 1 abc123..., DNSSEC: aktiv, DANE-Status: gültig
SEO & Website19
Was wird geprüft?
Analysiert die SEO-relevanten Meta-Tags einer Webseite: Title, Description, Open Graph und Twitter Cards.
Wie funktioniert es?
Der HTML-Quellcode wird geladen und die Meta-Tags per HTML-Parsing extrahiert. Geprüft werden Länge, Vorhandensein und Qualität der wichtigsten Tags.
Beispiel-Ergebnis
example.com → Title: "Beispiel GmbH" (12 Zeichen – zu kurz), Description: vorhanden (148 Zeichen – optimal), OG:Image: fehlt
Was wird geprüft?
Analysiert die robots.txt-Datei einer Website und zeigt die Crawler-Regeln übersichtlich an.
Wie funktioniert es?
Die robots.txt wird abgerufen und die Direktiven (Allow, Disallow, Sitemap, Crawl-delay) pro User-Agent geparst und ausgewertet.
Beispiel-Ergebnis
example.com/robots.txt → User-Agent: * – Disallow: /admin/, /tmp/ – Sitemap: https://example.com/sitemap.xml
Was wird geprüft?
Prüft die XML-Sitemap einer Website auf Gültigkeit und Vollständigkeit.
Wie funktioniert es?
Discovery folgt der sitemaps.org-Spec: zuerst wird die robots.txt nach einer Sitemap:-Direktive durchsucht (kanonische Methode, die auch Google und Bing nutzen). Erst wenn dort nichts steht, werden gängige Pfade als Fallback geprüft (/sitemap.xml, /sitemap_index.xml für Yoast, /sitemap-index.xml für Astro, /wp-sitemap.xml für WordPress-Core, /sitemap-0.xml). Anschließend wird das XML geparst und auf Pflichtfelder (loc, lastmod) geprüft. Sitemap-Indizes werden ebenfalls unterstützt.
Beispiel-Ergebnis
example.com → robots.txt verweist auf /sitemap-index.xml → 42 URLs gefunden, 3 ohne lastmod, 1 URL mit HTTP-Fehler 404
Hinweise
Sehr große Sitemaps (>50.000 URLs) werden nur teilweise analysiert. Wenn weder die robots.txt eine Sitemap deklariert noch einer der Standard-Pfade antwortet, gilt die Sitemap als nicht gefunden.
Was wird geprüft?
Zeigt eine Vorschau, wie eine URL auf Social-Media-Plattformen dargestellt wird.
Wie funktioniert es?
Open-Graph- und Twitter-Card-Tags werden ausgelesen und als Vorschau für Facebook, Twitter/X und LinkedIn simuliert.
Beispiel-Ergebnis
example.com → Facebook: Titel + Bild + Beschreibung, Twitter: Summary Card mit Bild, LinkedIn: Titel + Beschreibung
Was wird geprüft?
Prüft eine Webseite auf WCAG 2.1 Barrierefreiheits-Probleme (automatisierte Prüfung).
Wie funktioniert es?
Die Seite wird in einer jsdom-Umgebung geladen und mit der axe-core Engine analysiert. Gefundene Probleme werden nach Schweregrad (kritisch, schwerwiegend, moderat, gering) kategorisiert.
Beispiel-Ergebnis
3 kritisch: Bilder ohne Alt-Text, 5 schwerwiegend: fehlende Formular-Labels, 2 moderat: unzureichender Farbkontrast
Hinweise
Automatisierte Tests decken ca. 30-40% der WCAG-Kriterien ab. Eine vollständige Barrierefreiheits-Prüfung erfordert zusätzlich manuelle Tests.
Was wird geprüft?
Erkennt alle Cookies und Tracking-Technologien, die eine Website setzt.
Wie funktioniert es?
Die Seite wird in einem headless Puppeteer-Browser geladen. Über das Chrome DevTools Protocol (CDP) werden alle Cookies, Local-/SessionStorage-Einträge und Netzwerk-Requests analysiert. Optional wird ein Cookie-Consent simuliert (Deep Scan).
Beispiel-Ergebnis
8 Cookies gefunden: 2 notwendig (Session-ID, CSRF-Token), 4 Analytics (Google Analytics, Hotjar), 2 Marketing (Facebook Pixel)
Hinweise
Es können nicht alle Cookies erfasst werden – insbesondere Cookies, die erst nach Login gesetzt werden.
Was wird geprüft?
Erkennt die eingesetzten Technologien einer Website (CMS, Frameworks, Server, Analytics).
Wie funktioniert es?
HTTP-Response-Header (X-Powered-By, Server etc.) und HTML-Quellcode werden auf bekannte Muster geprüft. Pattern-Matching gegen eine Datenbank gängiger Technologie-Signaturen.
Beispiel-Ergebnis
example.com → Server: nginx, CMS: WordPress 6.4, PHP: 8.2, jQuery: 3.7, Google Analytics: GA4
Was wird geprüft?
Findet defekte Links (404, Timeout, etc.) auf einer Webseite.
Wie funktioniert es?
Alle Links im HTML-Quellcode werden extrahiert und per HTTP HEAD-Request auf Erreichbarkeit geprüft. Fehlerhafte Antworten (4xx, 5xx, Timeout) werden gemeldet.
Beispiel-Ergebnis
47 Links geprüft → 2 defekt: /alte-seite (404), https://extern.example.com/api (Timeout)
Hinweise
Es werden nur Links auf der angegebenen Seite geprüft, kein Crawling der gesamten Website.
Was wird geprüft?
Prüft Schema.org Structured Data (JSON-LD) einer Seite auf Vorhandensein und Korrektheit.
Wie funktioniert es?
JSON-LD-Blöcke im HTML werden extrahiert und geparst. Pflichtfelder je Schema-Typ werden validiert und fehlende Eigenschaften gemeldet.
Beispiel-Ergebnis
example.com → 1 Schema gefunden: Organization (name: ja, url: ja, logo: fehlt, contactPoint: fehlt)
Was wird geprüft?
Analysiert die Ladezeit und Performance-Kennzahlen einer Webseite.
Wie funktioniert es?
Gemessen werden Time-to-First-Byte (TTFB), Gesamtladezeit, Anzahl und Größe der Ressourcen (CSS, JS, Bilder) sowie Optimierungspotenziale.
Beispiel-Ergebnis
example.com → TTFB: 180ms, Ladezeit: 1.8s, 23 Requests, 1.2 MB Gesamt, 4 Bilder ohne Kompression
Was wird geprüft?
Findet doppelte oder widersprüchliche Meta-Tags über mehrere Seiten einer Website hinweg.
Wie funktioniert es?
Die Sitemap wird gecrawlt und die Meta-Tags (Title, Description) jeder Seite extrahiert und verglichen. Duplikate und zu ähnliche Einträge werden markiert.
Beispiel-Ergebnis
35 Seiten geprüft → 3 doppelte Titles ("/about" und "/über-uns"), 5 Seiten ohne Description
Hinweise
Maximal 100 Seiten aus der Sitemap werden geprüft.
Was wird geprüft?
Analysiert Bilder einer Webseite auf Optimierungspotenzial: Format, Größe, Alt-Texte und Lazy Loading.
Wie funktioniert es?
Alle Bild-Tags im HTML werden extrahiert. Geprüft werden: Dateiformat (WebP/AVIF-Empfehlung), Dateigröße, Vorhandensein von Alt-Texten und Lazy-Loading-Attributen.
Beispiel-Ergebnis
12 Bilder gefunden → 3 ohne Alt-Text, 5 als PNG statt WebP (Einsparung: ~60%), 2 ohne Lazy Loading
Was wird geprüft?
Bewertet die Inhaltsqualität einer Webseite: Lesbarkeit, Wortanzahl und Keyword-Dichte.
Wie funktioniert es?
Der Textinhalt wird extrahiert und analysiert. Berechnet werden Flesch-Reading-Ease (angepasst für Deutsch), Wortanzahl, Satzlänge und Keyword-Verteilung.
Beispiel-Ergebnis
example.com → 820 Wörter, Lesbarkeit: 58 (mittelschwer), Durchschn. Satzlänge: 16 Wörter, Top-Keywords: "service" (2.1%), "beratung" (1.8%)
Was wird geprüft?
Zeigt eine Vorschau, wie eine Seite in den Google-Suchergebnissen dargestellt wird.
Wie funktioniert es?
Title und Meta-Description werden mit Pixel-genauer Berechnung dargestellt. Zu lange Texte werden an der gleichen Stelle abgeschnitten wie bei Google.
Beispiel-Ergebnis
Title: "Beispiel GmbH – Ihr Partner für..." (56 Zeichen, 480px – passt), Description: "Wir bieten..." (142 Zeichen, 890px – wird abgeschnitten bei 920px)
Was wird geprüft?
Prüft ob sensible Dateien (.env, .git, wp-config.php, SQL-Dumps, docker-compose.yml etc.) öffentlich erreichbar sind.
Wie funktioniert es?
Ca. 30 bekannte sensible Pfade werden per HTTP GET abgefragt. Bei Status 200 wird der Inhalt mit dateitypspezifischen Validatoren geprüft (z.B. ".env" muss "=" enthalten, ".git/HEAD" muss "ref:" enthalten), um Custom-404-Seiten auszuschließen. Die Prüfung läuft in Batches von 10 parallelen Requests mit je 5 Sekunden Timeout.
Beispiel-Ergebnis
example.com → .env: exponiert (kritisch), .git/HEAD: nicht erreichbar, wp-config.php: nicht erreichbar, .well-known/security.txt: vorhanden (info)
Hinweise
security.txt (.well-known/security.txt) wird als positive Sicherheitspraxis gemeldet, nicht als Schwachstelle. Inhalt wird nur teilweise gelesen (max. 4 KB) und sensible Werte werden im Snippet maskiert.
Was wird geprüft?
Prüft ob die vier wichtigsten rechtlichen Pflichtseiten vorhanden und verlinkt sind: Impressum, Datenschutzerklärung, Cookie-Consent und Barrierefreiheitserklärung.
Wie funktioniert es?
Die Startseite wird geladen und das HTML nach Links mit relevanten Texten durchsucht (z.B. "Impressum", "Datenschutz", "Privacy"). Bei Treffern wird die Zielseite geladen und auf Inhalts-Muster geprüft (z.B. PLZ+Ort für Impressum). Fallback-Prüfung gängiger Standard-URLs (/impressum, /datenschutz etc.). Cookie-Consent wird über bekannte CMP-Signaturen im HTML erkannt (Cookiebot, OneTrust, Usercentrics, Borlabs, Klaro u.a.).
Beispiel-Ergebnis
example.com → Impressum: gefunden (pass), Datenschutz: gefunden (pass), Cookie-Consent: Cookiebot erkannt (pass), Barrierefreiheit: nicht gefunden (warn) → Score: 85/100
Hinweise
Die Prüfung ist eine Heuristik und ersetzt keine juristische Bewertung. Inhalte von Impressum und Datenschutzerklärung werden nur auf Muster geprüft, nicht inhaltlich validiert.
Was wird geprüft?
Durchsucht Schwachstellen-Datenbanken (NVD und OSV) nach bekannten CVEs für Software, Bibliotheken und Produkte.
Wie funktioniert es?
Der Suchbegriff (Software-Name, Bibliothek, Produkt oder CVE-ID) wird parallel bei der NVD (National Vulnerability Database, NIST) und OSV (Open Source Vulnerabilities, Google) abgefragt. Ergebnisse werden nach CVSS-Score bewertet, dedupliziert und nach Schweregrad sortiert.
Beispiel-Ergebnis
Suche "WordPress" → CVE-2024-31210 (kritisch, CVSS 9.8): Remote Code Execution, CVE-2024-28890 (hoch, CVSS 7.5): SQL Injection, ...
Hinweise
Maximal 30 Ergebnisse werden angezeigt. Die NVD-API hat Rate-Limits, daher können bei vielen Anfragen Verzögerungen auftreten. OSV deckt hauptsächlich Open-Source-Software ab.
Was wird geprüft?
Analysiert den CO2-Fußabdruck einer Webseite, Green Hosting, HTTP-Kompression, Bildformate und Font-Loading.
Wie funktioniert es?
Die Startseite wird geladen und die Transfer-Größe gemessen. CO2 wird nach dem Sustainable Web Design Model berechnet (0.81 kWh/GB × 442g CO2/kWh). Green Hosting wird über die Green Web Foundation API geprüft. Zusätzlich werden Content-Encoding (Kompression), Bildformate (Legacy vs. WebP/AVIF), Font-Dateien (@font-face, font-display, externe Fonts) und die Gesamtzahl externer Ressourcen analysiert.
Beispiel-Ergebnis
example.com → 0.12g CO2 (Exzellent), Green Hosting: ja (Hetzner), Brotli-Kompression: aktiv, 3 Legacy-Bilder, 4 Font-Dateien → Score: 78/100
Hinweise
Die CO2-Berechnung basiert auf der HTML-Transfergröße der Startseite. Nachgeladene Ressourcen (JS, CSS, Bilder) werden gezählt aber nicht separat gewogen. Durchschnitt liegt bei ca. 0.5g CO2 pro Pageview.
Was wird geprüft?
Erkennt alle externen Dienste und Drittanbieter, die eine Website lädt, und prüft die DSGVO-Konformität.
Wie funktioniert es?
Bis zu 30 Seiten werden per Sitemap oder Homepage-Crawl gesammelt. Für jede Seite werden alle extern geladenen Ressourcen (Scripts, Stylesheets, Fonts, iFrames, Bilder) extrahiert und gegen eine Datenbank von über 80 bekannten Diensten abgeglichen. Zusätzlich werden Inline-Script-Patterns (z.B. GTM-Container, Facebook Pixel) erkannt. Die Datenschutzerklärung wird per Link-Text-Suche oder Standard-URL-Fallback gefunden und textbasiert auf Erwähnung der erkannten Dienste geprüft.
Beispiel-Ergebnis
example.com → 12 externe Dienste: Google Analytics (Consent: ja, in DSE: ja), Google Fonts (Consent: ja, in DSE: nein – Warnung!), Cloudflare CDN (Consent: nein), DSGVO-Score: 67/100
Hinweise
Nur im HTML deklarierte Ressourcen werden erkannt. Dienste, die erst nach JavaScript-Ausführung oder nach Consent dynamisch geladen werden, können nur über Inline-Script-Pattern-Matching teilweise erkannt werden. Der Datenschutz-Abgleich ist eine Heuristik und ersetzt keine juristische Prüfung.
Generatoren7
Was wird geprüft?
Erstellt einen korrekten SPF-Record (Sender Policy Framework) für Ihre Domain.
Wie funktioniert es?
Über ein Konfigurationsformular wählen Sie erlaubte Mailserver, IP-Adressen und Include-Einträge. Daraus wird die korrekte TXT-Record-Syntax generiert.
Beispiel-Ergebnis
Eingabe: Google Workspace + eigener Server 203.0.113.5 → Ergebnis: v=spf1 include:_spf.google.com ip4:203.0.113.5 ~all
Hinweise
Ein SPF-Record darf maximal 10 DNS-Lookups auslösen. Der Generator warnt bei Überschreitung.
Was wird geprüft?
Erstellt einen DMARC-Record (Domain-based Message Authentication) für Ihre Domain.
Wie funktioniert es?
Sie wählen die DMARC-Policy (none, quarantine, reject), Berichts-Adressen und Prozentsatz. Daraus wird der TXT-Record für _dmarc.[domain] generiert.
Beispiel-Ergebnis
Policy: reject, Report: admin@example.com → Ergebnis: v=DMARC1; p=reject; rua=mailto:admin@example.com; pct=100
Was wird geprüft?
Erstellt eine robots.txt-Datei mit Crawler-Regeln für Ihre Website.
Wie funktioniert es?
Über einen Regel-Builder definieren Sie Allow/Disallow-Direktiven pro User-Agent und fügen Sitemap-Verweise hinzu. Das Ergebnis wird im robots.txt-Format ausgegeben.
Beispiel-Ergebnis
Ergebnis: User-agent: * Disallow: /admin/ Disallow: /private/ Sitemap: https://example.com/sitemap.xml
Was wird geprüft?
Erstellt einen Content Security Policy (CSP) Header für Ihre Website.
Wie funktioniert es?
Über einen Direktiven-Builder konfigurieren Sie erlaubte Quellen für Scripts, Styles, Bilder und weitere Ressourcentypen. Daraus wird die CSP-Header-Syntax generiert.
Beispiel-Ergebnis
Ergebnis: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src *
Was wird geprüft?
Erstellt HTML-Meta-Tags für SEO, Open Graph und Twitter Cards.
Wie funktioniert es?
Über ein Formular geben Sie Title, Description, Keywords und Social-Media-Informationen ein. Daraus werden die entsprechenden HTML-Meta-Tag-Snippets generiert.
Beispiel-Ergebnis
Eingabe: Title "Meine Seite", Desc "Beschreibung" → <title>Meine Seite</title>, <meta name="description" content="Beschreibung">, <meta property="og:title" ...>
Was wird geprüft?
Erstellt Apache .htaccess-Konfigurationen für gängige Anwendungsfälle.
Wie funktioniert es?
Sie wählen aus Modulen wie Redirects, Caching, Kompression, Sicherheitsheader und URL-Rewriting. Daraus werden die entsprechenden Apache-Direktiven generiert.
Beispiel-Ergebnis
HTTPS-Redirect + Caching → RewriteEngine On, RewriteCond %{HTTPS} off, RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L] + ExpiresByType ...
Was wird geprüft?
Generiert ein DKIM-Schlüsselpaar (RSA) für die E-Mail-Authentifizierung einer Domain.
Wie funktioniert es?
Im Browser wird über die Web Crypto API ein RSA-Schlüsselpaar erzeugt. Der öffentliche Schlüssel wird als DNS-TXT-Record im DKIM-Format ausgegeben, der private Schlüssel im PEM-Format zum Download angeboten.
Beispiel-Ergebnis
Domain: example.com, Selektor: default → DNS: default._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIIBIjAN..." + Private Key als .pem Download
Hinweise
Die Schlüssel werden ausschließlich im Browser generiert – es werden keine Daten an den Server übertragen.