Zum Inhalt springen
← Startseite

Changelog

Alle Updates, neue Features und Verbesserungen an Webalyzr.

Bugfix

Apex-Domain ohne www.: bei kaputten Setups (z.B. isas.de) automatisch auf www.${domain} ausweichen

  • •Symptom: isas.de zeigt im Compliance-Check „Impressum nicht gefunden" und „Datenschutz nicht gefunden", obwohl beide Seiten existieren. Cookie-Scanner liefert `net::ERR_CERT_COMMON_NAME_INVALID at https://isas.de`. SEO-Modul findet kein Title, keine Headings, keine Legal-Pages
  • •Root Cause: Der Apex `isas.de:443` liefert nur einen 14-Byte-Placeholder (`<h3>test</h3>`) aus dem nginx-Default-vhost mit einem Cert für `analytics.isas.de`. Die echte Site läuft ausschließlich unter `www.isas.de`. webalyzr hat bisher stur `https://${domain}` als Base-URL verwendet — bei isas.de landeten wir damit auf dem leeren Placeholder
  • •Fix: Neuer shared Helper `resolvePreferredBaseUrl()` in `utils/preferred-host.ts`. Ein leichtgewichtiger HEAD-/GET-Probe vergleicht Apex vs `www.`-Variante: wenn Apex netzwerkmäßig fehlschlägt ODER unter 500 Bytes liefert ODER keine `<a href>`-Tags hat UND die www-Variante substantielleren Content liefert, wird automatisch auf www gewechselt. Ergebnis wird 5 Minuten pro Domain gecached, kostet also höchstens 2 Probes pro Scan
  • •Eingesetzt in: compliance-check, SEO-Modul, cookie-scanner, performance-Modul, security-Modul, accessibility-Modul, sitemap-validator, robots-analyzer, duplicate-meta-finder, sustainability-check, exposed-files, http-protocol-check, external-services. Insgesamt 13 Tools/Module — der Apex-vs-www-Fallback wirkt jetzt überall, wo es auf den richtigen Web-vhost ankommt
  • •Zusätzlich: Chromium-Browser-Pool bekommt jetzt `--ignore-certificate-errors`. Wir scannen GEZIELT Sites mit kaputten/abgelaufenen Certs — vorher brach Chromium hart mit `ERR_CERT_COMMON_NAME_INVALID` ab und lieferte den Cookie-/Accessibility-/Compliance-Tools gar kein DOM. Die Cert-Qualität selbst wird vom ssl-checker separat bewertet, also keine Sicherheits-Regression
  • •Verifikation: isas.de Compliance-Score von 0 (alles "Startseite nicht erreichbar") auf 90/100, impressum/datenschutz/cookie-consent alle „pass". SEO-Modul findet 3 Legal-Pages und den echten Title „Leibniz-Institut für Analytische Wissenschaften". Cookie-Scanner erkennt 4 Matomo-Cookies
Bugfix

DANE/TLSA-Validierung: SPKI-Selector wurde fälschlich über das ganze Zertifikat gehasht — fast jeder DANE-Mailserver wurde als "mismatch" gemeldet

  • •TLSA-Records mit Selector 1 (SubjectPublicKeyInfo) sind die in freier Wildbahn häufigste Form — posteo.de, mailbox.org, mxroute.com und die meisten korrekt konfigurierten DANE-Provider nutzen Selector 1. Das dane-check-Tool hat den Hash für Selector 1 aber über das KOMPLETTE Zertifikat berechnet (mit dem Kommentar „we use the full cert as approximation"), nicht über das SPKI-Feld — Ergebnis: bei jedem korrekt eingerichteten DANE-MX kam „Certificate does not match TLSA record" zurück, plus die Empfehlung „DANE reparieren"
  • •Fix: X509Certificate.publicKey.export({ type: "spki", format: "der" }) liefert die korrekt DER-codierte SPKI, gehasht mit SHA-256/SHA-512 je nach matchingType. Unbekannte Selector- und MatchingType-Werte (z.B. zukünftige RFC-Erweiterungen) geben jetzt explizit „Unsupported" zurück statt eine falsche Validierungsaussage zu liefern
  • •Anlass: Audit am 13.05.2026 — alle DANE-aktivierten Mailserver in unseren Test-Scans waren betroffen
Bugfix

Content-Quality bei SPAs: jede React-/Next.js-Site bekam "Thin Content" als High-Prio-Empfehlung

  • •Bug: Anders als image-optimizer, structured-data, broken-link-checker hatte content-quality keinen SPA-Render-Fallback. Bei React/Next/Vue-Sites enthält das rohe HTML oft nur ein <div id="root"></div> + Skeleton — die Wortzahl lag dann bei 5-20, und die Empfehlung „Sehr geringe Wortzahl, ziele auf 800-1500 Wörter" tauchte trotz einer real 2000+-Wörter-Seite auf
  • •Fix: dasselbe spa-render-Pattern, das die anderen 5 Tools schon nutzen — isLikelySpa()-Heuristik (sparse Links ODER kleines rohes HTML) ODER weniger als 100 Body-Wörter triggert einen Headless-Chromium-Render-Pass, dann wird das gerenderte DOM gemessen. Schneller Static-Pfad bleibt der Default für klassische Server-rendered-Sites
Bugfix

Accessibility-Check: Skip-Link-Custom-Rule produzierte False-Positives bei ~90% aller Sites

  • •Bug: Custom-Check „WCAG 2.4.1 Bypass Blocks" feuerte als Moderate-Violation, sobald der ALLERERSTE <a href> der Seite kein Skip-Link war. Realität: bei den allermeisten Sites ist der erste Link das Logo (Home-Link) oder ein Cookie-Banner-Link. Skip-Links sind WCAG-empfohlen, aber „Bypass Blocks" verlangt nicht „muss erster Link sein" — alternative Techniken (Landmarks via <main>, <nav>, <header>) erfüllen das Kriterium ebenfalls
  • •Fix: Check feuert jetzt NUR noch, wenn weder ein <main>-Landmark NOCH irgendein Skip-Link irgendwo auf der Seite vorhanden ist. Wenn nur das <main> fehlt, aber ein <nav>-Landmark da ist, wird die Severity auf "minor" runtergestuft. Patterns für Skip-Link-Detection erweitert (skipnav, skip-to-content, skip-to-main)
  • •Folge: typische Sites mit ordentlicher HTML5-Landmark-Struktur (<main>, <nav>, <header>, <footer>) bekommen keine künstlichen WCAG-2.4.1-Abzüge mehr — der A11y-Score wird um ~3 Punkte realistischer
Bugfix

Tech-Stack: React-Detection nur via DevTools-Marker — fast keine Produktions-Site wurde als React erkannt

  • •Bug: React-Detection-Heuristik war [data-reactroot] (existiert seit React 18 / Concurrent Mode nicht mehr) ODER html.includes(„__REACT_DEVTOOLS") — der zweite Marker existiert nur, wenn der Endnutzer React DevTools im Browser installiert hat. In Produktion praktisch nie sichtbar. Folge: Tech-Stack-Report meldete bei den meisten React-/Next.js-Sites „kein Framework erkannt"
  • •Fix: Detection greift jetzt auf moderne, in Produktion stabile Marker zurück — data-react-helmet (sehr verbreitet bei SEO-Setups), react-dom/jsx-runtime-Bundle-Pfade, _reactRootContainer, __reactProps$, __reactFiber$, React.createElement-Aufrufe in JS-Bundles. Confidence bleibt bei „medium", weil React selten als alleinige Framework-Aussage ausreicht
  • •Zusätzlich: WooCommerce-Detection toleriert jetzt auch CamelCase-Markup (manche Custom-Themes schreiben „WooCommerce" statt „woocommerce" im HTML)
Bugfix

Blacklist-Check: SORBS DNSBL wurde 2024 abgeschaltet — meldete seither jede IP als "gelistet"

  • •Proofpoint (Eigentümer seit der GFI-Übernahme) hat dnsbl.sorbs.net Ende 2024 stillgelegt. Die Zone liefert seither NXDOMAIN-Wildcards bzw. zeitweise 127.0.0.2 für jede Anfrage. Folge: webalyzr meldete bei jeder zweiten Domain „Auf SORBS gelistet" — auch saubere IPs großer Mail-Provider. Endnutzer haben sich zurecht beschwert
  • •Fix: SORBS aus der DNSBL-Liste entfernt. Plus Kommentar im Code, der dokumentiert WARUM (damit nicht der nächste Audit „mehr DNSBLs hinzufügen" zurück packt). Liste der aktiv geprüften DNSBLs ist damit von 25 auf 24 reduziert
  • •Hinweis: Wildcard-Detection als generelles Safeguard (Sentinel-Query mit bekannt-sauberer IP gegen jede Zone) ist noch nicht implementiert — wenn künftig weitere DNSBLs sterben, müssen sie ebenfalls manuell aus der Liste
Bugfix

Cookie-Scanner: Klaro / Usercentrics / CookieYes wurden erkannt, aber Consent-Cookies nie gesetzt — Tracking-Scripts luden nie

  • •Bug: die CMP-Erkennung (detectedCmp-Variable) listete „klaro", „usercentrics", „cookieyes" korrekt, aber die nachfolgende if/else-Kette zum Setzen der Standard-Consent-Cookies endete bei „complianz" — die drei fielen in den Unknown-CMP-Fallback (Klick auf den Banner-Button), der bei vielen Klaro/UC/CY-Installationen scheitert (Custom-CSS, Shadow-DOM, JS-injizierte Buttons). Folge: Tracking-Scripts luden nie, der Cookie-Report meldete „0 Analytics/Marketing-Cookies" trotz aktivem Google Analytics. Falscher „alles sauber"-Eindruck
  • •Fix: explizite Consent-Cookies pro CMP — `klaro` als URL-encoded JSON mit allen Standard-Services (google-analytics, gtm, matomo, fb-pixel, youtube, vimeo, gmaps), `uc_settings` + `uc_user_interaction` für Usercentrics v3, `cookieyes-consent` als URL-encoded String für CookieYes. accept-all und reject-all werden je separat unterstützt
  • •Plus Deep-Scan-Timing-Refactor: vorher 8 Subpages × bis zu 17s = bis 136s pro Site, was bei MAX_PAGES=4 den ganzen Throughput totgeschlagen hat. Jetzt 3 priorisierte Subpages (shop/checkout/kontakt), waitUntil: "domcontentloaded" statt "networkidle2" (Idle wird auf Sites mit dauer-firenden Tracking-Pixeln nie erreicht), Timeouts 15s → 10s, Settle 2s. Deep-Scan dauert jetzt typischerweise <30s statt bis zu 130s
Bugfix

SPF: Lookup-Counter zählte nicht rekursiv — Sites mit gängigen include:-Chains kamen fälschlich als "valid" durch

  • •Bug: RFC 7208 §4.6.4 verlangt, dass jeder DNS-Lookup beim Auswerten eines SPF-Records gezählt wird, REKURSIV durch alle include:- und redirect=-Targets. webalyzrs Counter zählte aber nur die Mechanismen im ÄUSSEREN Record. Sites mit `include:_spf.google.com include:spf.mandrillapp.com include:servers.mcsv.net` sahen „5/10", real waren es 14+ (jeder include triggert intern weitere Lookups) — Empfangs-Mailserver liefern dann „permerror" und können die Mail komplett ablehnen, ohne dass webalyzr es gemerkt hätte
  • •Fix: rekursiver SPF-Resolver mit Lookup-Counter und Visited-Set. Loop-Detection (`include:foo.com` → `include:bar.com` → `include:foo.com`) explizit als Fehler mit Hinweis „Mailserver liefern permerror und blockieren alle Mails". Hartes Tiefen-Limit bei 10 Verschachtelungsebenen als Schutz vor pathologischen Records
  • •Zusätzlich: DKIM-Validator prüft jetzt die echte Keystärke. Vorher nur „p-Tag-Länge > 100 Zeichen" — das hat 1024-Bit-RSA-Keys (216 Zeichen Base64) als OK durchgelassen, obwohl Gmail/Microsoft 1024-Bit seit 2024 als schwach markieren. Jetzt: Public Key wird Base64-decodiert, als SPKI geparst, RSA-Modulus-Bit-Länge ermittelt. < 1024 = kritisch, < 2048 = warn. t=y (Test-Mode) wird separat erkannt und gemeldet — Empfänger ignorieren Test-Mode-DKIM komplett
Bugfix

SMTP-Open-Relay-Test: False-Positives durch eigene Domain als Sender, False-Negatives durch Greylisting

  • •Bug 1 (False-Positives): MAIL FROM nutzte die getestete Domain als Absender (`test@${domain}`). Viele Mailserver akzeptieren automatisch ihre eigene Domain als MAIL FROM und filtern erst auf Empfänger-Ebene — das hat echte Open-Relays maskiert und gleichzeitig Sites fälschlich als „Open Relay" gemeldet, deren Anti-Spoofing nur foreign-sender-basiert greift
  • •Bug 2 (False-Negatives): 4xx-Responses (Greylisting, Rate-Limit) wurden wie 5xx als „Relay korrekt abgelehnt" interpretiert. Server, die uns beim ersten unbekannten Sender temporär ablehnen (gängige Anti-Spam-Praxis bei Postscreen/Postgrey), bekamen so ein ungerechtfertigtes „pass" — würde der Test 5 Minuten später wiederholt, käme vielleicht ein echtes Problem zum Vorschein
  • •Fix: MAIL FROM nutzt jetzt `probe@webalyzr-scan.invalid` (fremde Domain mit RFC-6761-TLD, garantiert nicht-existent). 4xx wird als „inconclusive" (info) gerendert statt als „pass" — mit dem Hinweis „Greylisting/Rate-Limit, Test bei späterem Scan wiederholen". 5xx auf MAIL FROM gilt als korrekte Ablehnung (Anti-Spoof greift schon dort)
Bugfix

Traceroute: SSRF-Lücke durch TOCTOU + IPv6 wurde gar nicht geprüft

  • •Security-Bug: Der SSRF-Check hat per dns.resolve4 die A-Records aufgelöst, gegen private-IP-Ranges geprüft — und dann tracert mit dem ursprünglichen HOSTNAMEN gestartet. Tracert macht sein eigenes DNS-Lookup (Windows-Resolver, ggf. anderer Cache, andere TTL). Bei kurzer TTL + DNS-Rebinding konnte zwischen Check und Spawn eine private IP zurückkommen — klassischer TOCTOU-Bug, internes Netz von außen scannbar wenn ein Angreifer den DNS-Resolver der getesteten Domain kontrolliert
  • •Bug 2: AAAA-Records wurden gar nicht geprüft. IPv6-Domains, die auf fc00::/7 (Unique-Local) oder ::1 (Loopback) zeigen, kamen ungehindert durch
  • •Fix: A UND AAAA werden parallel aufgelöst, ALLE Adressen gegen isPrivateIp (kennt IPv4-Privat, IPv6-Loopback, IPv6-Link-Local, IPv6-ULA) geprüft. Die zuvor verifizierte IPv4 wird direkt als Argument an tracert übergeben — tracert macht damit kein eigenes Lookup mehr. IPv6-only Hosts werden mit klarer Fehlermeldung abgelehnt (Windows tracert spricht v6 nur mit Extra-Flag, das supporten wir bewusst nicht)
Bugfix

Weitere Detection-Verbesserungen: meta-tag-analyzer, broken-link-checker, image-optimizer, exposed-files, external-services

  • •meta-tag-analyzer auf cheerio umgestellt. Vorher: Regex direkt am HTML-String. Bei React-SSR-Payloads mit __NEXT_DATA__-JSON, das Strings wie `"<title>Old</title>"` im State enthält, zog der erste Regex-Match aus dem JSON-Wert statt aus dem echten <head><title>. Cheerio parst baum-strukturiert und ignoriert Inline-Scripts korrekt
  • •broken-link-checker: isExternal-Check über URL.origin statt startsWith. Vorher: `https://example.com.evil.com/...` wurde mit baseOrigin `https://example.com` als „intern" klassifiziert (startsWith-Match). Jetzt: strikter Origin-Vergleich. Phishing-Domains werden korrekt als extern eingestuft
  • •image-optimizer: totalImages zeigt jetzt die ECHTE Anzahl Bilder auf der Seite, plus ein separates imagesChecked-Feld für die 30er-Stichprobe. Vorher meldete ein Shop mit 80 Produktbildern „totalImages: 30" — der Endnutzer dachte, es gäbe 30 Bilder. Schwelle für „oversized" von 200 KB auf 400 KB hochgesetzt (Hero-Bilder sind heute typischerweise 200-500 KB selbst bei guter WebP-Kompression)
  • •exposed-files (.htaccess): Validator hat akzeptiert, sobald irgendwo „Allow"/„Header"/„Rewrite" im Body stand — manche Theme-Texts (Cookie-Banner „Allow all"), Custom-404-HTMLs ohne <html>-Tag oder JS-Strings haben das fälschlich getriggert. Jetzt: muss mit Apache-Direktive (RewriteEngine/IfModule/Options/AuthType/…) starten ODER mindestens 2 klare Apache-Syntax-Muster enthalten. Genauso für debug.log/error.log — Zeitstempel-Muster (ISO, Apache common log, PHP-Fehler) sind jetzt verpflichtend
  • •external-services Privacy-Mentions: Wortgrenzen-Regex statt substring. Vorher matchte „Hotjar" auch in „wir nutzen kein Hotjar"; jetzt Negations-Kontext-Check (wenn „nicht"/„kein"/„ohne" im 30-Zeichen-Fenster davor steht, zählt es nicht als Erwähnung). Außerdem: zu kurze Mentions (<4 Zeichen wie „GA", „X") werden ignoriert, weil sie zu viele Substring-Treffer produzieren
Verbesserung

SSL-Checker prüft jetzt CAA-Records gegen den tatsächlichen Cert-Issuer

  • •Vorher: CAA-Records wurden vom ssl-checker komplett ignoriert. Eine Site ohne CAA-Record bekam ein perfektes A+, obwohl ein essentielles Security-Control fehlt (CAA verhindert seit 2017, dass nicht autorisierte CAs Zertifikate ausstellen). War ein CAA-Record da, hat ihn niemand gegen den Cert-Issuer der gefundenen Cert-Kette verglichen — Inkonsistenz: dns-lookup zeigte CAA, ssl-checker nicht
  • •Jetzt: drei Status-Kategorien — `ok-none` (kein CAA, beliebige CA erlaubt; Empfehlung: CAA setzen), `ok-allowed` (CAA listet die ausstellende CA korrekt), `mismatch` (CAA listet die ausstellende CA NICHT — kritisches Compliance-Issue). CA-Mapping deckt die häufigsten Public CAs ab: Let's Encrypt, Sectigo/Comodo, DigiCert, GlobalSign, GoDaddy/Starfield, Amazon, Google Trust Services, Cloudflare, ZeroSSL, Buypass, Entrust
Verbesserung

DNS-Tools: konsistente blocked-Status-Klassifizierung, subdomain-finder verlangsamt, port-scanner konsolidiert

  • •dns-propagation: REFUSED/SERVFAIL werden jetzt als „blocked" klassifiziert (Resolver-Policy, keine Propagation-Aussage) statt als generischer „error". ENOTFOUND/ENODATA als „nodata" (Domain kennt, aber kein Record dieses Typs). Propagation-Prozent wird nur über tatsächlich antwortende Resolver berechnet — „blocked" und „error" zählen nicht mehr in den Nenner. Neustar 64.6.64.6 raus (seit 2023 von UltraDNS stillgelegt)
  • •subdomain-finder: BATCH_SIZE von 50 auf 10 reduziert. Viele Auth-NS — besonders kleinere (IONOS-Plesk, Strato, Hetzner) — drosseln ab ~30 QPS pro Source-IP und antworten dann mit REFUSED, was existierende Subdomains als „nicht gefunden" durchrutschen ließ. AXFR läuft jetzt zuerst und alleine; wenn ein Auth-NS einen Zonen-Transfer erlaubt (≥50 Subdomains), wird Brute-Force ganz übersprungen — wir haben die authoritative Liste. Wildcard-Detection einmal pro Run (vorher 2× mit möglicherweise unterschiedlichen IPs durch Round-Robin)
  • •port-scanner: zwei separate Listen — eine im Standalone-Tool (21 Ports), eine im Security-Modul (38 Ports) — durch eine geteilte utils/common-ports.ts ersetzt. Custom-Sophos-Ports (4444, 9443 mit hardcoded Service-Namen „Sophos Admin"/„Sophos User") entfernt — alter Customer-Workaround. Plus Kategorien (expected/admin/critical/legacy) als Basis für faireres Scoring (offener :443 ist erwartet, offener :3306/:6379/:27017 ist kritisch)
Verbesserung

Browser-Tools: networkidle2-Antipattern in performance/seo/cookie-scanner durch domcontentloaded ersetzt

  • •Bug: drei Browser-Tools (performance.service.ts, seo.service.ts, cookie-scanner.service.ts) nutzten `waitUntil: "networkidle2"` mit 15-20s Timeout. Auf Sites mit dauer-firenden Analytics-Pixeln (Hotjar-Recording, Clarity, GA-Realtime) wird Network-Idle NIE erreicht — Folge: kompletter Timeout-Verlust statt graceful degradation, kein LCP/CLS-Wert, kein gerendertes Meta, kein Cookie-Snapshot
  • •Fix: alle drei migriert auf `domcontentloaded` + explizit kontrolliertes Settle-Fenster (2.5-6s je nach Use-Case). Performance bekommt 5s Settle für späte LCP-Updates, SEO 2.5s für JS-injizierte Meta, Cookie-Scanner 6s nach Consent-Reload für GTM → GA → 3rd-party-Cookies. Accessibility-Check war als einziges schon umgestellt — jetzt ist das Pattern überall konsistent
  • •Zusätzlich: accessibility-modul Score-Diskrepanz fixed. Das Tool berechnet 100 - critical*15 - serious*8 - moderate*3 - minor*1 (ungecappt), das Modul packt das in 5 Buckets mit Cap (30/30/20/10/10). Bei 3 critical violations zeigte UI „Accessibility 55" und Breakdown 46 — zwei verschiedene Zahlen. Jetzt: Score = Summe der sichtbaren Findings-Punkte. Single Source of Truth
Bugfix

Sitemap: zwei Guide-URLs mit Umlauten waren 404, plus stale lastModified — jetzt dynamisch aus dem Filesystem

  • •Bug: `/guides/security-headers-erklärt` und `/guides/website-sicherheit-prüfen` standen mit echten Umlauten in sitemap.xml, die Next.js-Routen hießen aber tatsächlich `security-headers-erklaert` und `website-sicherheit-pruefen` (ASCII). Beide Sitemap-URLs lieferten 404 — Google konnte die zwei Guides faktisch nicht indexieren. Verifiziert: die Umlaut-Variante gibt heute noch 404, die ASCII-Variante gibt 200
  • •Root Cause: Sitemap-Datei pflegte die 49 Tool-Slugs und 3 Guide-Slugs als hardcoded String-Array — bei jeder neuen Seite oder Slug-Umbenennung droht Drift zwischen Filesystem und Sitemap
  • •Fix: `app/sitemap.ts` scannt jetzt zur Build-Zeit via `fs.readdirSync` die Verzeichnisse `app/tools/` und `app/guides/` und nimmt alle Unterordner mit einer `page.tsx` auf. Damit fällt der Umlaut-Bug konstruktionsbedingt weg (die Slugs kommen direkt vom Filesystem), und neue Tool-/Guide-Seiten landen automatisch in der Sitemap
  • •Zusätzlich: `lastModified` kommt jetzt aus dem mtime der jeweiligen page.tsx (statt durchgängig 2026-03-18, was selbst nach Code-Änderungen stehen blieb) — gekappt auf das aktuelle Datum, damit kein in-die-Zukunft-Datum entstehen kann. `changeFrequency` und `priority` ergänzt: Homepage `weekly` / 1.0, Core-Pages `monthly` / 0.8, Tools 0.7, Guides 0.6
  • •Output validiert: 63 URLs (11 Core + 49 Tools inkl. Methodik + 3 Guides), alle Slugs entsprechen den tatsächlichen Routen, lastModified spiegelt echte Edit-Zeiten der page.tsx-Dateien
Verbesserung

Backend-Performance: Browser-Pool entbottlenecked und Pro-Modul-Timeouts statt pauschaler 60 Sekunden

  • •Headless-Chromium-Pool war auf max. 2 parallele Pages konfiguriert, der Worker läuft aber mit concurrency=2 × Module-Batch=3 — bis zu 6 Module fragen gleichzeitig eine Page an. Sechs Caller (accessibility, compliance-check, cookie-scanner, performance, seo, spa-render) konkurrierten um zwei Slots, was Scans mit JS-rendering-Tools künstlich serialisiert hat
  • •Default jetzt MAX_PAGES=4, zusätzlich via Env-Variable `BROWSER_POOL_MAX_PAGES` ohne Redeploy hochziehbar — bei mehr RAM auf dem VPS lässt sich der Wert (Page-Context ~150-250 MB) jederzeit anpassen. Idle-Shutdown und Crash-Recovery-Logik bleiben unverändert
  • •Modul-Timeouts: vorher pauschal 60 s für alle 10 Module. DNS und WHOIS sind in 1-2 s fertig — der globale 60-s-Wert war für die zu lang (hängende Scan-Steps bei stillen Resolver-Problemen). Performance und Accessibility brauchen mit Chromium-Render real bis zu 40 s — bei langsamen Sites war 60 s zu knapp
  • •Neue Werte: dns/whois 20 s, blacklist 25 s, mail/http/ssl 30 s, security 45 s, seo 60 s, performance/accessibility 90 s. Fail-fast für die schnellen Module + mehr Luft für die schweren — Gesamt-Scan-Dauer fühlbar gleichmäßiger
Bugfix

PDF-Report-Korrekturen: widersprüchliche Labels, abgeschnittene Erklärungen, ausführlicher Tech-Stack

  • •Widerspruch zwischen UI und PDF behoben: bei DNSSEC und CDN stand im PDF „DNSSEC aktiviert" bzw. „CDN erkannt" mit ROTEM X — was nicht passt. Die `drawCheckRow`-Hilfsfunktion bekommt jetzt optional ein negatives Label, und 32 Aufrufer wurden mit klaren Pass/Fail-Paaren versorgt: „DNSSEC aktiviert" + „DNSSEC nicht aktiviert", „CDN erkannt" + „Kein CDN erkannt", „SPF-Record vorhanden" + „Kein SPF-Record gefunden" usw. Im PDF erscheint jetzt entweder die positive Aussage mit ✓ ODER die negative Aussage mit ✗ — nicht mehr beide kombiniert
  • •Compliance-PDF: BFSG-Hinweis zur Barrierefreiheitserklärung wurde auf 120 Zeichen gekappt und endete nach „… verpflichtet das Barr…". Truncate-Grenze auf 2000 Zeichen erhöht — PDFKit wickelt den Text automatisch um, also kein Layout-Risiko. Vollständiger Hinweis inkl. „wer ist betroffen / wer ausgenommen / Bußgelder bis 100.000 €" steht jetzt drin
  • •Tech-Stack-PDF deutlich ausgebaut: vorher nur dünner Server-Header + flache Liste. Jetzt: getrennte Tabellen pro Kategorie (CMS, Library, JS Framework, …) mit Erkennungs-Sicherheit (sicher/wahrscheinlich/möglich). Korrigiertes Schema-Mapping in der Versions-Prüfung — vorher waren die Property-Namen falsch (`v.name` statt `v.technology`), Tabelle blieb leer. Jetzt mit Diff-Spalte „X Major-Versionen hinterher". Neu: CMS-Probe-Findings als eigene Sektion mit Severity-Badges (KRITISCH/WARNUNG/INFO) — z.B. „wp-login.php öffentlich erreichbar", „/composer.json leakt Version", „User-Enumeration via REST API möglich"
  • •Content-Quality im Haupt-Scan-Report: die ContentQualityDetail-Komponente im Scan-Result-Flow rendert jetzt die Verbesserungs-Vorschläge UND die Einleitung — vorher waren die nur im Standalone-/tools/content-quality-Endpoint sichtbar, nicht im Haupt-Scan. Plus: „Woerter/Saetze/Absaetze/Oslash" durch echte Umlaute „Wörter/Sätze/Absätze/Ø" ersetzt
Verbesserung

Sitemap, robots.txt, Mixed-Content, Meta-Tags: konkrete Empfehlungen statt knapper Empty-States

  • •Sitemap-Validator: bei „keine Sitemap gefunden" gibt es jetzt eine Erklärung was XML-Sitemaps bringen (Crawl-Geschwindigkeit, vor allem bei neuen Sites und tieferen Strukturen) und konkrete Anleitungen pro CMS (WordPress mit Yoast/Rank Math, Next.js mit app/sitemap.ts, statische Sites, Online-Generator xml-sitemaps.com). Plus Hinweis Sitemap-in-robots.txt + Submit in Search Console
  • •Robots-Analyzer: bei „keine robots.txt" wird erklärt was robots.txt ist und ob du eine brauchst (technisch optional, praktisch empfohlen wegen Sitemap-Hinweis und AI-Crawler-Kontrolle), eine fertige Vorlage zum Copy-Paste mit Standard-Direktiven und optionalen GPTBot/ClaudeBot/PerplexityBot-Ausschlüssen, plus Tipps zur korrekten Platzierung im Webroot
  • •Mixed-Content: bei „alles sauber" wird jetzt erklärt was Mixed Content überhaupt ist (HTTPS-Site lädt HTTP-Ressourcen → Browser blockiert oder warnt) und warum 0 Treffer ein positives Signal sind. Bei HTTP-Sites gibt es Schritt-für-Schritt-Anweisungen zum HTTPS-Umzug (Let's Encrypt, .htaccess-Redirect, HSTS-Header). Bei gefundenem Mixed Content kommt die Standard-Lösung mit Content-Security-Policy + upgrade-insecure-requests
  • •Meta-Tags-Analyzer: statt nur „missing title" gibt es jetzt priorisierte Empfehlungen pro Tag — wichtige (Title/H1/viewport/Description), empfohlene (Canonical/Open-Graph) und optionale (Twitter-Card/Favicon/lang). Jede Empfehlung mit konkretem Code-Beispiel und Soll-Werten (Title 30–60 Zeichen, Description 120–160 Zeichen, og:image 1200×630px). Plus Einleitung was Meta-Tags überhaupt steuern
Verbesserung

Structured-Data, Content-Quality und Compliance-Check liefern jetzt konkrete Handlungsempfehlungen statt nur „nichts gefunden"

  • •Structured Data: bei leerem Ergebnis erklärt das Tool jetzt, was Schema.org-Markup bringt (Rich Snippets, AI-Search-Citations, Knowledge-Graph) — plus eine Heuristik aus dem HTML, welche Schema-Typen für genau diese Site sinnvoll wären. Erkennt LocalBusiness an Adresse+Telefon, Article an /blog/-Pfaden + Autor-Byline, Product an Preis+Warenkorb-Buttons, FAQPage an Frage-Headlines, BreadcrumbList an sichtbarer Navigation. Jeder Vorschlag kommt mit Priorität, Begründung, Nutzen-Beschreibung und JSON-LD-Vorlage zum Copy-Paste
  • •Content Quality: statt nur „Probleme: Niedrige Wortzahl" gibt es jetzt priorisierte Verbesserungsvorschläge mit konkreten Soll-Werten (z.B. „Aktuell 326 Wörter → Ziel: 800-1500"), Begründung aus den Quality-Rater-Guidelines und Handlungstipps. Bereiche: Inhalt (Wortzahl), Lesbarkeit (Flesch), Struktur (H1/H2, Text-HTML-Ratio), Keywords (Density-Warnung), interne/externe Verlinkung, E-E-A-T-Signale. Plus Einleitung was die Metriken überhaupt bedeuten und woher die Schwellwerte kommen
  • •Compliance-Check / Barrierefreiheitserklärung: jetzt mit explizitem Hinweis, wer ab 28.06.2025 unter das BFSG fällt (B2C-Online-Shops, Banken, Telekommunikation, Personenbeförderung, E-Book-Anbieter) und wer ausgenommen ist (Kleinstunternehmen unter 10 MA + ≤2 Mio € Umsatz; B2B; reine Info-Sites). Damit kleine Sites nicht in Panik geraten und große Anbieter wissen was reinmuss (Konformitäts-Stand, Feedback-Mechanismus, Schlichtungsstelle). Bußgelder bis 100.000 € werden klar genannt
  • •Umlaute überall: 23 Frontend-Dateien hatten noch „pruefen / qualitaet / verhaeltnis / Groesse / fuer / ueber / erklaerung" als ASCII-Workarounds. Diese sind jetzt durchgängig auf echte ä/ö/ü/ß umgestellt — sowohl in den Tool-Labels (Cookie-Scanner-Beschreibung, Compliance-Beschreibung etc.) als auch in Page-Titles und Meta-Descriptions
Bugfix

Tech-Stack: keine falschen „WordPress v2"-Anzeigen mehr durch zu lockere Versions-Regex

  • •Symptom: Tech-Stack-Tool zeigte bei manchen WordPress-Sites „WordPress v2 → v6.9.4, Veraltet – 4 Major-Versionen". WordPress 2 gab es zuletzt 2007 — solche Installationen sind in freier Wildbahn praktisch nicht mehr existent. Es war immer ein Detection-Bug
  • •Ursache: Drei kaskadierende lockere Regex-Patterns. (1) Der Generator-Meta-Detect-Regex `WordPress\s+([\d.]+)` matchte auch nur eine einzelne Ziffer wenn der Generator-Content etwas wie „… WordPress 2 Theme" enthielt. (2) Die /readme.html-Probe nutzte `Version\s*([\d.]+)` und matchte beim ersten Treffer — der WordPress-Readme-Changelog enthält aber dutzende „Version 2.0 introduced…"-Phrasen, die ALLE Sites fälschlich als „WordPress 2.0" markiert hätten. (3) Der Version-Check schickte selbst diese single-digit-Versionen durch den Outdated-Vergleich, statt sie als offensichtlich kaputt zu verwerfen
  • •Fix in drei Schichten: alle CMS-Detect-Regexes (WordPress/Joomla/Drupal/TYPO3) erfordern jetzt mindestens X.Y-Format (`\d+\.\d+(?:\.\d+)?`). Die readme.html-Probe schaut nur noch im Header VOR dem ersten `<h2>` (= vor dem Changelog-Abschnitt), wo nur die aktuelle Version steht. Im Version-Check selbst werden detected versions mit weniger als 2 numeric Components stillschweigend übersprungen, statt sie als „4 Major-Versionen veraltet" auszuweisen
  • •Konsequenz: WordPress wird auf Sites, die ihre Version verschleiern, jetzt korrekt als „erkannt, Version unbekannt" geführt — kein Outdated-Score-Abzug mehr durch erfundene Version „2". Echte Outdated-Detections (z.B. jQuery 3.3.1 statt 4.0.0) bleiben unverändert
Verbesserung

Pre-Flight-IP-Block-Check jetzt auch in allen 22 Standalone-/tools-Endpoints

  • •Bisher griff der TCP-Reachability-Check nur am Anfang des Haupt-Scans (/api/scan). Wer ein einzelnes Tool über /tools/&lt;name&gt; aufgerufen hat (Tech-Stack, Mixed-Content, Sustainability, Compliance-Check, …), bekam bei einer geblockten Site einfach ein leeres Ergebnis zurück — irreführend, weil es so aussah als hätten wir die Site analysiert und nichts gefunden
  • •Jetzt: Vor jedem HTTP-basierten Standalone-Tool läuft derselbe TCP-Connect-Probe-Check wie beim Haupt-Scan. Bei Block wird HTTP 422 mit klarer Meldung „Site blockiert unsere Scanner-IP – Lösung: Whitelisting" zurückgegeben. Konkret aktiviert für: redirect-checker, meta-tags, robots-analyzer, sitemap-validator, http-protocol-check, social-media-preview, accessibility-check (+pdf), cookie-scanner, mixed-content, tech-stack, geo-readiness, broken-link-checker, structured-data, page-performance, duplicate-meta, image-optimizer, content-quality, serp-simulator, external-services, exposed-files, compliance-check, sustainability-check
  • •DNS-/SMTP-/WHOIS-/TLS-direct-Tools (dns-lookup, smtp-diagnostics, dkim-validator, blacklist-check, dane-check, tls-cipher-analyzer, port-scanner, subdomain-finder, ssl-checker, bimi-lookup, dns-propagation, ping) bleiben unberührt — die operieren nicht auf Web-Port-Ebene und brauchen den HTTP-Check nicht
  • •Wichtig zur Identifikation gegenüber der Site: der Pre-Flight macht ausschließlich einen passiven TCP-SYN auf Port 443 (und ggf. 80) — kein HTTP-Request, kein User-Agent, kein X-Webalyzr-Header. Die Site sieht nur ein normales SYN-Paket wie von jedem Browser, kann uns also nicht aktiv loggen oder identifizieren. Konkret beobachtet bei buse.de (hinter Sucuri-WAF) und itwerksaar.de (vermutlich fail2ban) — beide blocken Datacenter-IPs flächendeckend
Bugfix

DNS-Modul: Resolver-Failover bei Rate-Limit — keine fälschlich leeren DNS-Reports mehr

  • •Symptom war: ein Scan zeigt nur den A-Record, alle anderen Record-Typen (NS, MX, SOA, TXT, CAA) als „nicht gefunden", obwohl die Domain sauber konfiguriert ist. Score sackt von typischen 80–90 Punkten auf 45 ab, ohne dass sich an der Domain etwas geändert hat
  • •Root Cause: node:dns rotiert die konfigurierte Server-Liste (8.8.8.8 → 1.1.1.1 → 4.2.2.1 → 9.9.9.9) automatisch nur bei TRANSPORT-Fehlern (echter Timeout, Network unreachable). REFUSED- und SERVFAIL-Antworten werden NICHT auf den nächsten Resolver gefailovered — der Fehler wird sofort geworfen und unser safeResolve-Wrapper liefert leeren Default. Wenn der erste Resolver unsere Scanner-IP rate-limited (Google 8.8.8.8 macht das gerne bei häufigen Anfragen aus IONOS-Datacenter-Ranges), schlagen ALLE Record-Lookups in einem Scan still fehl
  • •Fix: jeder DNS-Lookup probiert jetzt explizit alle vier Public-Resolver der Reihe nach in eigenen Resolver-Instanzen. Reihenfolge umgestellt auf Cloudflare → Google → Level3 → Quad9 (Cloudflare gibt seltener REFUSED an Datacenter-IPs). Failover wird ausgelöst bei SERVFAIL, REFUSED, TIMEOUT, CONNREFUSED, BADRESP, CANCELLED und transientem EAI_AGAIN. NXDOMAIN und NODATA bleiben final — das sind echte authoritative Antworten, die alle Resolver gleich geben würden
  • •Konkret beobachtet bei thuer-it.com: Score sprang von 45 auf 80, weil unsere Anfragen kurzzeitig bei Google rate-limited waren. Diese Klasse Bug betraf potenziell viele Scans über den Tag verteilt, wann immer 8.8.8.8 unsere IP gedrosselt hat
Feature

Sechs Tools nutzen jetzt Headless-Chromium für authentische Ergebnisse statt nur HTML-Parsing

  • •Mixed-Content: misst jetzt echte Network-Requests via Chromium, nicht nur explizite http://-URLs im HTML. Wesentlich für JS-injizierte Mixed-Content-Fälle (CDN-Loader, dynamische Tracker), die ein Browser tatsächlich blockt — der bisherige Static-Check hat diese Klasse komplett übersehen
  • •External-Services: Browser-Pass auf der Homepage sammelt alle 3rd-Party-Requests via Network-Hook. Google Tag Manager lädt z.B. typischerweise 5–15 weitere Tracker (GA, Pixel, Hotjar, Clarity, …) erst zur Laufzeit nach — vorher haben wir nur den GTM-Bootstrap gesehen. Tracker-Liste verdoppelt sich oft
  • •Sustainability-Check: Page-Weight wird jetzt als Summe aller tatsächlichen Network-Response-Bytes gemessen (Top-Level + CSS + JS + Fonts + Bilder + XHR), nicht mehr nur der HTML-Bytes. Die CO2-Berechnung war bisher systematisch um Faktor 5–20 zu niedrig. Methode wird im Resultat als browser/static ausgewiesen, transparent welche Messung greift
  • •Image-Optimizer: bei SPA-Verdacht oder &lt;3 Bildern im rohen HTML Render-Pass — Next.js-Image-Komponente, lazy-load und galerien injizieren Bilder oft erst clientseitig. Bisher zählte der Check dann „0 Bilder", obwohl die Seite 20+ hatte
  • •Broken-Link-Checker: bei SPA-Heuristik (&lt;10 Links oder &lt;8KB rohes HTML) Render-Pass — React-Router/Next.js-Link-Wrapper erzeugen die a-Tags erst nach Hydration
  • •Structured-Data: wenn rohes HTML 0 ld+json-Blöcke enthält oder SPA-Verdacht besteht, Render-Pass. GTM/Yoast/RankMath/SEO-Press injizieren Schema-Markup oft per JS — vorher unsichtbar für unseren Scanner
  • •Alle sechs Pfade laufen über das schon etablierte browser-pool-Pattern aus dem Compliance-Tool (max. 2 parallele Pages, 60 s Idle-Shutdown, hartes Timeout pro Render, stiller Static-Fallback wenn Chromium nicht verfügbar). Die Static-Pfade bleiben als schneller Default für klassische Server-rendered-Sites bestehen — Browser-Pass schaltet sich nur ein wenn nötig
  • •Routing: die Upgrades wirken sowohl in den /tools/&lt;name&gt;-Standalone-Endpoints als auch in den Bonus-Tools im Haupt-Scan, weil beide Pfade dieselben Service-Funktionen aufrufen
Verbesserung

DNSSEC-Resolver-Anzeige: ehrlichere Konsens-Logik und Klartext-Erklärungen statt nur EDE-Codes

  • •Bisheriges Problem: wenn ein Resolver wie Cloudflare die DNS-Antwort durch eine Policy/ACL geblockt hat (EDE 15–18 „blocked/censored/filtered/prohibited"), wurde das als „unsigned" gezählt — der Resolver hatte aber tatsächlich gar keine DNSSEC-Aussage gemacht, die „noad"-Klassifikation war ein Nebeneffekt der verweigerten Auflösung. Der angezeigte Konsens „DNSSEC unsigned" war dann irreführend, weil er sich faktisch nur auf einen einzigen Resolver stützte
  • •Neuer Per-Resolver-Status „blocked" für EDE 15–18 — eigener Badge in der UI („gesperrt"), eigene Erklärung als Tooltip und im sichtbaren Karten-Text. Diese Antworten zählen NICHT mehr als „unsigned"-Stimme im Konsens
  • •Wenn nach Aussortieren der blocked/error-Antworten weniger als 2 verlässliche Stimmen übrig bleiben, wechselt das Gesamt-Ergebnis auf den neuen Status „inconclusive" — sichtbar als „DNSSEC-Status nicht eindeutig bestimmbar", statt einer falschen Aussage. Score bleibt neutral (5 von 10 Punkten)
  • •Pro Resolver gibt es jetzt eine Klartext-Erklärung auf Deutsch — z.B. „Resolver hat die Antwort verweigert: Resolver durfte nicht antworten (Policy/ACL). Diese Antwort ist keine Aussage über DNSSEC" oder „Resolver hat DNSSEC-Signatur kryptografisch validiert (AD-Flag gesetzt)". Mapping-Tabelle für alle 28 EDE-Codes nach RFC 8914, im Backend lokalisiert
Feature

Contao-Version-Detection verbessert und in den Outdated-Check integriert

  • •Contao-Sites entfernen häufig das Versions-Generator-Meta auf der Homepage als Hardening — vorher konnten wir „Contao erkannt" ausgeben, aber keinen Versions-Abgleich machen. Jetzt versucht der Tech-Stack-Scanner auch /contao/login (Backend-Login-Seite, das Versions-Meta bleibt dort meist) und als Notfall /composer.json (öffentlich erreichbar bei Misskonfigurationen)
  • •Wird eine Version gefunden, läuft sie durch den bestehenden Outdated-Check gegen endoflife.date — markiert die Site als „X Major-Versionen / Y Minor-Versionen / Z Patches hinterher" und „End-of-Life" falls die Cycle abgelaufen ist. Das gleiche Mechanismus, der schon für WordPress, TYPO3, Drupal & Shopware existiert
  • •Reihenfolge in der Tool-Pipeline geändert: CMS-Deep-Probes laufen jetzt VOR dem Versions-Check, damit die per Probe nachgefundenen Versionen (Contao/TYPO3/WP via Backend-Login) im selben Scan ausgewertet werden — vorher musste der Versions-Check einen zweiten Scan abwarten
  • •Regex-Verschärfung: Versions-Patterns matchen jetzt nur noch X.Y- oder X.Y.Z-Formate, damit Linktexte wie „Contao 4 Kurzanleitung" nicht mehr fälschlich als Version „4" interpretiert werden (false-positive aus dem ersten Live-Test gegen thuer-it.com)
Verbesserung

Scanner bricht jetzt sauber ab, wenn die Ziel-Site unsere IP blockiert — statt halbem Report

  • •Neuer TCP-Reachability-Pre-Check vor dem eigentlichen Scan: Versucht zweimal eine TCP-Verbindung zu Port 443 (4 s Timeout) und fällt notfalls auf Port 80 zurück. Antwortet keiner der Ports auf das SYN-Paket, wird der Scan gar nicht erst gestartet
  • •Bisher: Wenn ein Hoster die Scanner-IP per Firewall droppt (klassisch nach fail2ban-Block oder WordPress-Security-Plugin), liefen trotzdem 20+ Tools 5–10 Minuten lang in einzelne Timeouts und produzierten einen irreführenden Report mit ~30 Punkten Score und Dutzenden "timeout"-Findings, obwohl die Seite eigentlich gesund ist
  • •Jetzt: Innerhalb von max. 18 Sekunden klare Fehlermeldung im Frontend mit konkretem Hinweis — „Wahrscheinlichste Ursache: Hoster blockiert Scanner-IP (87.106.131.207). Lösung: Beim Hoster um Whitelisting bitten, oder warten bis fail2ban automatisch entsperrt." Score und Report werden nicht erzeugt
  • •Differenziert vier Fehler-Klassen: tcp_timeout (SYN gedroppt — IP-Block), tcp_refused (RST — Webserver down), dns (Hostname nicht auflösbar) und unknown. Jede Klasse bekommt einen passenden Erklärtext, damit man nicht raten muss
  • •TLS-Handshake-Fehler und HTTP-4xx/5xx werden bewusst NICHT vorab abgefangen — die sind wertvoller Scan-Input und werden weiterhin von den einzelnen Modulen (Performance, Security, SEO) als Befund gemeldet
Feature

DNS-Modul: echte DNSSEC-Signaturvalidierung statt nur "ja/nein"-Check

  • •DNSSEC-Test fragt jetzt drei DoH-Resolver parallel ab (Cloudflare, Google, Quad9) und bildet Konsens über das AD-Flag (Authenticated Data) sowie Status-Codes
  • •Vier-Stufen-Klassifizierung statt zwei: valid (alle Resolver bestätigen), unsigned (Domain ohne DNSSEC – legitim), bogus (mind. ein Resolver liefert SERVFAIL + EDE 6-10), partial (gemischte Antworten)
  • •BOGUS-Status wird im Report als kritischer Finding ausgewiesen mit dem konkreten EDE-Code (z.B. "EDE 6: DNSSEC Bogus") – der bisherige AD-only-Check hat eine Bogus-Domain fälschlich als "DNSSEC nicht aktiviert" markiert, was die eigentliche Schwere verschleiert hat (Bogus-Domains sind unter validierender DNS unerreichbar)
  • •UI zeigt zusätzlich pro Resolver eine kleine Karte mit dessen Antwort (AD ✓ / unsigned / SERVFAIL / error) sowie EDE-Code – transparent, welcher Resolver was sagt
  • •Anlass: DENIC ZSK-Rollover-Zwischenfall heute morgen führte zeitweise zu DNSSEC-Bogus für .de-Domains (validierende Resolver gaben SERVFAIL+EDE 6, ohne Validation funktionierte alles). Tool hätte das mit dem neuen Check klar als BOGUS gemeldet statt nur "DNSSEC nicht aktiviert"
Bugfix

SEO-Indexability-Fixes: Soft 404 und Duplicate-Canonical-Probleme beseitigt

  • •/report aus der Sitemap entfernt — die generische /report-URL ohne Domain-Parameter wurde von Google als Soft 404 gewertet, weil sie nur einen kurzen "nicht gefunden"-Hinweis ausgegeben hat. Nur dynamische /report/<domain>-Reports sollen indexiert werden
  • •Empty-States für /report (ohne Domain) und /scan (ohne ID) auf vollwertigen Inhalt erweitert: H1, Erklärtext, was geprüft wird, CTA zur Startseite. Verhindert Soft-404-Klassifizierung durch Google auch wenn jemand direkt auf die generische URL geht
  • •/privacy-Verzeichnis komplett gelöscht: hatte einen Canonical-Tag auf /datenschutz, aber inhaltlich abweichenden Text — Google ignorierte das deklarierte Canonical und meldete "Duplikat – vom Nutzer nicht als kanonisch festgelegt". Plus: Seite war noindex und wurde dafür separat als "durch noindex ausgeschlossen" gemeldet. Footer-/AGB-Verweis zeigt jetzt direkt auf /datenschutz
  • •Hintergrund: Search Console zeigte 6 Coverage-Probleme (3× Soft 404, 1× noindex-Ausschluss, 1× Duplikat ohne Canonical, 1× gecrawlt aber nicht indexiert) — alle dürften nach diesem Deploy auf "behoben" wechseln
Bugfix

Scanner akzeptiert jetzt Domains, die nur über lokales/Provider-DNS auflösen

  • •Pre-Scan-Check "Domain existiert" hat bisher ausschließlich Google Public DNS (8.8.8.8) und Cloudflare (1.1.1.1) angefragt. Manche Domains mit Nameservern wie *.dns-parking.com geben dort SERVFAIL zurück, obwohl die Domain technisch live ist (z.B. seosignals.de) — Scanner hat sie fälschlich als "Domain not found" abgelehnt
  • •Fix in zwei Stufen: (1) Public-Resolver-Liste um Level3 (4.2.2.1) und Quad9 (9.9.9.9) erweitert — node:dns probiert bei Transport-Fehlern automatisch den nächsten Server. (2) Falls alle Public-Resolver SERVFAIL geben, fällt der Pre-Check zusätzlich auf den System-DNS zurück (auf dem VPS systemd-resolved → Provider-DNS) — fängt auch Edge-Cases ab, bei denen wirklich kein Public-Resolver antwortet
  • •Score-Module bleiben unverändert beim Public-DNS-only Pfad — Methodik "wir testen die externe Sicht" bleibt konsistent. Nur der Existenz-Check ist bewusst toleranter, weil eine ablehnende Fehlermeldung gegenüber einer live erreichbaren Domain das größere Übel ist
Bugfix

/scan und /report: Hydration-Mismatch behoben — Scans starten jetzt zuverlässig

  • •Beim direkten Aufruf einer Scan-URL wie /scan?id=337&token=… blieb gelegentlich der Empty-State stehen, statt in den Loading-Spinner und schließlich die Live-Ergebnisse zu wechseln. Ursache war ein useMemo([]) das beim Server-Render mit window===undefined null cachte und beim Client-Hydration zu einem DOM-Mismatch führte
  • •Fix: Params werden jetzt erst nach Hydration via useEffect aus window.location ausgelesen. Initial-State (SSR und erster Client-Render) sind identisch → kein Mismatch → React kann sauber re-rendern, sobald die echten Params verfügbar sind. Gleicher Fix in /report/<domain>
Feature

Compliance-Check: SPA-Erkennung mit Headless-Chromium-Render-Pfad

  • •Bei JS-gerenderten Single-Page-Apps (Next.js/React/Vue-Sites mit dünnem rohem HTML) startet der Compliance-Check jetzt automatisch einen zweiten Pass mit Headless-Chromium und analysiert das voll gerenderte DOM — vorher hat der Cheerio-Static-Parser dort keine Links und Inhalte gefunden und alle Compliance-Items als "warn" markiert
  • •SPA-Heuristik: Homepage hat weniger als 10 sichtbare Links **oder** das rohe HTML ist kleiner als 8 KB → SPA-Verdacht → Browser-Pass. Normale Sites bleiben im schnellen Static-Pfad (~0,5 s)
  • •Auch der Impressum-Inhalts-Check (Adresse, Kontakt, TMG/DDG-Verweis) versucht bei SPA-Verdacht und unklarem Static-Resultat einen Browser-Render-Fallback der /impressum-Seite — damit greift die TMG/DDG-Detection auch bei JS-only-Impressums
  • •Hartes 10-Sekunden-Timeout pro Render-Pass plus stilles Failback auf das Static-Ergebnis, wenn Chromium nicht verfügbar ist oder das Rendering scheitert
  • •UI zeigt einen Hinweis-Banner an, wenn die Startseite per Headless-Chromium ausgewertet wurde — transparent über die Methodik
  • •Impressum-Check warnt zusätzlich, wenn die geprüfte Seite noch auf das TMG (Telemediengesetz) verweist statt auf das DDG (Digitale-Dienste-Gesetz) — TMG wurde am 14.05.2024 durch das DDG abgelöst, Verweise auf das alte Gesetz sind potenzieller Abmahn-Anlass
  • •TMG-Erkennung greift jetzt in beiden Discovery-Pfaden: sowohl wenn der Impressum-Link direkt von der Startseite verlinkt ist als auch wenn er nur über die Standard-URL (/impressum) gefunden wird
  • •UI: "Seite oeffnen"-Buttons im Compliance-Tool nutzen jetzt korrektes ö statt der ASCII-Schreibweise
Verbesserung

Compliance-Check: bessere Detection für Impressum/Datenschutz/AGB + ehrliches Mail-Scoring

  • •Impressum/Datenschutz/Barrierefreiheits-Detection deutlich robuster: vorher wurde nur exakter Linktext gegen /^impressum$/ etc. gematcht — Varianten wie "» Impressum", "Impressum / AGB", icon-only Links mit aria-label, oder Footer-Links mit Zusatztext fielen durch das Raster
  • •Neuer findLink-Helper sucht zusätzlich in aria-label, title-Attribut und URL-Pfad — und nutzt Wort-Grenzen statt strict-anchors. Pattern für Datenschutz erweitert um "Datenschutzhinweise", "Datenschutzbestimmungen", "DSGVO", "Privacy Notice/Statement"; für Impressum um "Pflichtangaben", "Anbieterkennzeichnung", "Legal Information"
  • •AGB / Nutzungsbedingungen werden jetzt als 5. Compliance-Item geprüft — informativ, fließt nicht in den Score ein (nur bei Online-Vertragsschluss zwingend). Erkennt "AGB", "Allgemeine Geschäftsbedingungen", "Terms of Service", "User Agreement" etc.
  • •Cookie-Consent-Detection erweitert: Didomi, Iubenda, TrustArc, Sourcepoint, Quantcast Choice, Osano, Termly, Cookie Information, Civic Cookie Control, IAB TCF v2 werden jetzt erkannt — plus self-hosted Patterns (/consent.js mit data-consent-open Triggern, "Cookie-Einstellungen"-Linktext)
  • •Mail-Scoring: nicht-anwendbare Items (DKIM/STARTTLS/MTA-STS/TLS-RPT/BIMI ohne MX-Record) bekommen jetzt 0/0 Punkte und fallen damit aus dem Nenner — vorher gab es volle Punkte als "info", was zu einem irreführenden 82/100 für Domains ohne Mail-Infrastruktur führte. SPF und DMARC bleiben weiterhin durchgängig bewertbar (Anti-Spoofing-Schutz greift auch ohne Mail-Server)
Verbesserung

Sitemap-Discovery folgt jetzt der sitemaps.org-Spec (robots.txt zuerst, /sitemap.xml als Fallback)

  • •Sitemap-Validator-Tool prüft bei Eingabe einer Domain zuerst die robots.txt auf eine Sitemap:-Direktive (kanonische Discovery-Methode laut sitemaps.org, die auch Google und Bing nutzen) — vorher wurde direkt /sitemap.xml angefragt und bei abweichendem Pfad ein 404 als "keine Sitemap" gewertet
  • •Fallback-Pfade wurden um die gängigen Varianten erweitert: /sitemap_index.xml (Yoast), /sitemap-index.xml (Astro-Default), /wp-sitemap.xml (WordPress-Core seit 5.5), /sitemap-0.xml (Astro Multi-File-Output) — Spec erlaubt das ausdrücklich
  • •Result enthält jetzt ein "discovery"-Feld ("robots" / "fallback" / "direct"), das transparent macht, wie die Sitemap gefunden wurde
  • •Gleiche Discovery-Logik wird auch im Duplicate-Meta-Finder und External-Services-Crawler verwendet — vorher haben beide Tools an Sites mit nicht-Standard-Sitemap-Pfaden vorbeigecrawlt und dann nur die Homepage analysiert
  • •Methodology-Text im Tool angepasst: erklärt jetzt explizit die zweistufige Discovery-Reihenfolge
Bugfix

Rechtshinweise auf aktuelle Gesetze umgestellt (DDG/MStV/TDDDG)

  • •Impressum-Seite: § 5 TMG → § 5 DDG, § 7 Abs. 1 TMG → § 7 Abs. 1 DDG, §§ 8 bis 10 TMG → §§ 8 bis 10 DDG (TMG wurde am 14.05.2024 durch das Digitale-Dienste-Gesetz ersetzt)
  • •Impressum-Seite: § 10 Abs. 3 MDStV → § 18 Abs. 2 MStV (MDStV ist bereits 2003 ausgelaufen, RStV wiederum 2020 in den Medienstaatsvertrag aufgegangen)
  • •Compliance-Check-Tool: User-Texte und Tool-Beschreibung auf DDG bzw. TDDDG (statt TTDSG) aktualisiert — sowohl deutsche als auch englische Variante
  • •PDF-Report-Generator und i18n-Tipps: Verweise auf "§ 5 TMG" in Empfehlungstexten und Hilfe-Tooltips ebenfalls auf "§ 5 DDG" umgestellt
  • •Inhaltlich keine Änderung der Pflichtangaben — die Umbenennungen sind redaktionell, aber Verweise auf nicht mehr existierende Gesetze sind potenzieller Abmahn-Anlass
Verbesserung

SMTP-Diagnose: Peer-Reject-Erkennung (4xx/5xx statt Timeout)

  • •Wenn ein Empfänger-MX die Scanner-IP auf Protokollebene ablehnt (typisch 554 Bad DNS PTR bei GMX/web.de/T-Online gegen Cloud-IPs), liest der Handshake-Code den SMTP-Response-Code jetzt explizit aus und meldet ihn als peerRejectCode + peerRejectMessage — statt in den 6s-Timeout zu laufen
  • •Neue Felder tlsStarttls.peerRejectCode und tlsStarttls.peerRejectMessage im Result
  • •Recommendation-Engine: Peer-Rejects werden als INFO-Finding "MX lehnt Scanner-IP ab" ausgewiesen — ausdrücklich mit dem Hinweis, dass das keine Fehl-Konfiguration der gescannten Domain ist, sondern eine IP-Reputations-Policy des Empfängers
  • •Frontend-TLS-Panel zeigt bei Peer-Reject eine eigene Amber-Box mit Code + Text statt der generischen "Handshake fehlgeschlagen"-Meldung
  • •Banner und STARTTLS-Probe sowie Submission-Port-587-Probe nutzen jetzt alle einen gemeinsamen readSmtpResponse-Helper, der SMTP-Response-Codes strukturiert parst
Verbesserung

SMTP-Diagnose: Scanner-Reputations-Awareness (dreistufige Outbound-Erkennung)

  • •Neues Feld outboundConnectivity mit den drei Stufen full / partial / none ersetzt das binäre portsBlocked-Flag
  • •Scanner probed sich selbst gegen 6 Referenz-MXe (Gmail, Outlook, Hotmail, GMX, T-Online, freenet) statt wie bisher nur drei
  • •Frontend zeigt farbcodierte Banner: rot (komplett blockiert, z.B. IONOS vor Freischaltung), amber (eingeschränkte Mail-Reputation, z.B. Cloud-IP mit generischem PTR), kein Banner (alles grün)
  • •Recommendation-Engine unterdrückt TLS-Handshake-Timeouts als Findings, wenn der Scanner sich in partial-Connectivity befindet — dadurch keine falschen "STARTTLS fehlgeschlagen"-Meldungen bei Domains mit Google-/GMX-MXen
  • •Methodology-Text an neue Realität angepasst: nicht mehr "Hoster blockt Port 25", sondern "manche MXe filtern Scanner-IP-Ranges nach Reputation/PTR"
Feature

Blacklist-Check: Seriositäts-Einstufung + UCEPROTECT-Aufklärung

  • •DNSBL-Liste von 20 auf 25+ Einträge erweitert (Truncate, Hostkarma, Invaluement, Manitu NiX Spam, Spamhaus Sublisten einzeln)
  • •Jede Liste bekommt jetzt Metadaten: Betreiber, Seriositäts-Tier (Industrie-Standard / Verbreitet / Nische / Umstritten), Delisting-URL, Fokus-Beschreibung, Pay-to-Delist-Flag
  • •Return-Codes werden übersetzt: z.B. "127.0.0.2 → SBL (bekannter Spam-Versender)" bei Spamhaus ZEN
  • •Prominente Warnbox wenn auf kontroverser Liste gelistet (UCEPROTECT L1/L2/L3) mit Link zum Knowledgebase-Artikel
  • •Zusammenfassung trennt nach Industrie-Standard-Hits vs. Umstrittene-Liste-Hits – nicht alle Listings sind gleich relevant
  • •Expandable Table-Rows zeigen Focus/Warning/Delisting-Link pro Liste inline
  • •Knowledgebase-Artikel "IP-Blacklisting: Ursachen & Lösungen" erweitert: klare Trennung seriöse vs. umstrittene Listen, Sektion zur Sippenhaft-Mechanik von UCEPROTECT L2/L3, RFC 6471-Zitat zum Pay-to-Delist-Modell, explizite Empfehlung nicht die Express-Gebühr zu zahlen
Feature

SMTP-Diagnose: TLS-Handshake, DANE, AUTH-Audit, Mail-DNS-Stack + Recommendations

  • •STARTTLS-Handshake auf Port 25 mit echtem TLS-Upgrade: Protokoll, Cipher, Forward-Secrecy, Zertifikat (Subject/Issuer/SAN/Wildcard/Ablauf/SPKI-Hash), SAN-vs-MX-Hostname-Matching
  • •Implicit-TLS-Probe auf Port 465 (SMTPS) mit Cert-Parse
  • •Submission-Port 587: EHLO + STARTTLS-Handshake + AUTH-Mechanism-Audit (PLAIN/LOGIN-vor-TLS-Warnung)
  • •DANE/TLSA-Lookup + Verifikation gegen SHA-256-Hash des Live-Certs (usage=3, matching=1)
  • •VRFY/EXPN-User-Enumeration-Test
  • •All-MX-Enumeration: IPv4 + IPv6 + PTR + Port-25-Reachability pro Prio-Stufe
  • •Kompletter Mail-DNS-Stack: SPF (mit Qualifier/Include-Parse), DMARC (p/sp/rua/ruf/adkim/aspf), DKIM-Probe über 13 gängige Selektoren, MTA-STS (DNS + .well-known-Policy-Fetch + Mismatch-Check), TLS-RPT, CAA, BIMI, Nameserver
  • •MX-Blacklist-Check gegen Spamhaus ZEN, Spamcop, SORBS, Barracuda, CBL
  • •Regelbasierte Recommendation-Engine (kritisch/hoch/info) mit fertigen DNS-Snippets
  • •Scanner-Self-Test: erkennt blockierten Port 25 outbound (Hoster-Default) und zeigt entsprechendes Info-Banner im Frontend, damit TLS-Live-Daten nicht als "broken" missverstanden werden
Feature

Exchange-Check: volle Intelligence-Suite + Recommendation Engine

  • •TLS-Intelligenz pro Host (domain, mail., autodiscover.): Zertifikat (Subject, Issuer, SAN, Wildcard-Erkennung, Ablauf-Tage) + TLS-Version-Matrix 1.0/1.1/1.2/1.3
  • •SMTP EHLO-Collector: kompletter Handshake mit Feature-Parse, STARTTLS-Verhandlung, Protokoll/Cipher-Erkennung, Exchange-native vs. Exim/Postfix-Gateway-Fingerprint
  • •Port-Exposure: TCP-Probes auf 25, 443, 465, 587, 993, 995 gegen mail.-Host
  • •Mail-DNS-Stack: SPF mit Qualifier- und Include-Parse, DMARC mit p/sp/rua/ruf/adkim/aspf-Breakdown, DKIM-Selector-Probe (13 gängige Namen), MTA-STS (DNS + .well-known-Policy-Fetch), TLS-RPT, CAA, BIMI, Nameserver
  • •MX-Blacklist-Check: Spamhaus ZEN, Spamcop, SORBS, Barracuda, CBL
  • •Recommendation Engine: priorisierte Handlungsempfehlungen (kritisch/hoch/info) mit fertigen DNS-Snippets zum Kopieren
  • •False-Positive-Fix: Issues werden nur noch bei echten Exchange-Endpunkten gefeuert (vorher hat Apache-Catch-all auf Main-Domain "OWA publicly accessible" etc. ausgelöst)
  • •Erweiterte Endpoint-Probes: EWS, MAPI, RPC, ActiveSync, OAB, PowerShell, API jetzt auch auf mail.-Subdomain, Best-Pick bevorzugt Exchange-confirmed
Feature

Drupal + Shopware Deep-Probes + Report-Pages SEO-optimiert

  • •Shopware-Detection präzisiert: Meta-Generator + /themes/Frontend/ + /bundles/storefront/ statt nur Name-Match
  • •Drupal Deep-Probe: CHANGELOG.txt-Check (verrät Version), /user/login, /sites/default/settings.php (CRITICAL wenn offen), Module-Extraktion aus sites/all/modules
  • •Shopware Deep-Probe: /recovery/install/index.php CRITICAL-Alarm, Admin-Backend-Check, API-Version-Leak /api/_info/version, /files/documents/ Directory-Listing, SW5-Plugins + SW6-Bundles
  • •Report-Pages (/report/domain.com): dynamische Canonical, Open-Graph + Twitter-Cards, erweitertes TechArticle-Schema mit about-Entity, BreadcrumbList-Schema
  • •robots.txt referenziert jetzt zwei Sitemaps: Next.js-Static (Core-Pages) + Backend-Dynamic (alle Report-URLs) — damit Google alle gescannten Domains als Long-Tail-Content indexieren kann
Verbesserung

Accessibility + HSTS-Preload-Ready

  • •Score-Badge-Farben überarbeitet: Kontrast gegen /15-Hintergründe von 1.4 auf WCAG-AA-kompatibel angehoben (lime-400 → lime-700, yellow-500 → yellow-700)
  • •Nested-Interactive-Elements behoben: Recent-Scans-Cards auf der Homepage nutzen jetzt stretched Link + relative Delete-Button statt role="button" mit verschachteltem Button
  • •H1-Duplikat auf Homepage entfernt: SEO-Content-Block ist jetzt H2 (nur Hero-Heading bleibt H1)
  • •Language-Toggle-Button: min. 32x32px Klickfläche (WCAG 2.5.8)
  • •HSTS: doppelte Security-Header entfernt (Apache + Nginx) — nur noch Nginx setzt Header
  • •HTTP-Scoring: Server-Header und X-Powered-By als warn mit Teilpunkten statt fail (Security-through-Obscurity ist umstritten)
  • •HTTP-Scoring: Custom-404 als warn statt fail (UX-Empfehlung, nicht Pflicht)
  • •Webalyzr.de selbst ist nach den Fixes laut hstspreload.org-API preload-eligible (errors: [], warnings: [])
Bugfix

Scoring fairer: Mail/DNS/SEO bestrafen nicht mehr fehlende Optional-Features

  • •Mail-Modul: Domains ohne MX-Records werden nicht mehr mit 85 Punkten bestraft (DKIM, STARTTLS, MTA-STS, TLS-RPT, BIMI sind ohne Mail-Versand nicht anwendbar)
  • •Mail-Modul: SPF und DMARC bleiben auch ohne MX relevant — als Anti-Spoofing-Schutz mit reduziertem Gewicht (warn statt fail)
  • •Mail-Modul: BIMI-Record nicht mehr als Fehler — BIMI hat <1% Adoption und benötigt ein Verified Mark Certificate
  • •DNS-Modul: CAA-Records und IPv6 (AAAA) als "warn" statt "fail" — optional, nicht verpflichtend
  • •DNS-Modul: MX ohne Records ist jetzt neutrale Info (Domain kann bewusst nur Web-Domain sein)
  • •SEO-Modul: Hreflang-Tags bei Single-Language-Sites (nur <html lang="xx">) als "info" 2/2 statt "fail" 0/2
  • •Security-Header-Check: Accept-Encoding: identity erzwingen, um Plesk/Nginx-Brotli-Quirks zu umgehen
  • •Empirische Score-Änderungen: vercel.app Mail von ~0 auf 82/100, webalyzr.de SEO auf 100/100, Security auf 87/100
Neues Tool

Neues Tool: AI-Search-Readiness (GEO-Check)

  • •Prüft die Sichtbarkeit in ChatGPT, Perplexity, Google AI Overviews und Bing Copilot
  • •AI-Crawler-Check für GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, Google-Extended u.a. in robots.txt
  • •llms.txt-Validierung (Title/Description/Sections/Links)
  • •Schema-Analyse mit Fokus auf FAQPage, HowTo, Organization, BreadcrumbList
  • •Passage-Citability: fragebasierte Headings + Block-Länge (optimal 134-167 Wörter laut Ahrefs-Studie)
  • •SSR-Check (AI-Crawler führen kein JavaScript aus)
  • •Freshness-Check und Entity-Linking via sameAs
  • •Gewichteter Gesamtscore 0-100 mit konkreten Handlungsempfehlungen pro Finding
Verbesserung

Homepage: FAQPage- und HowTo-Schema für AI-Extraktion ergänzt

  • •FAQPage-Schema mit den 4 Homepage-FAQs (Kosten, Score-Berechnung, Datenschutz, Unterschied zu SSL Labs/MXToolbox)
  • •HowTo-Schema für die 3-Schritt-Anleitung zur Website-Analyse
  • •AI-Assistenten wie ChatGPT und Perplexity können Antworten direkt aus diesen Blöcken zitieren
  • •Eigener GEO-Score durch die Änderungen von 84 auf 90 gestiegen
Feature

Tech-Stack: CMS-Deep-Probes für WordPress, TYPO3 und Contao

  • •WordPress: exakte Version aus /readme.html und /wp-json/, Checks für User-Enumeration (REST API + ?author-Redirect), xmlrpc.php und wp-login.php
  • •TYPO3: Backend-Login-Check /typo3/, CRITICAL-Alarm wenn LocalConfiguration.php öffentlich, typo3temp-Directory-Listing, Extension-Erkennung aus typo3conf/ext-Pfaden
  • •Contao: exakte Version aus Generator-Meta, Backend-Login-Check, CRITICAL-Alarm wenn contao-manager.phar.php erreichbar, /files/-Directory-Listing, Modul-Erkennung aus Asset-Pfaden
  • •Contao-Detection präzisiert: statt fragilem html.includes("contao") jetzt harte Signale (Generator-Meta, /assets/contao/, data-contao)
  • •Alle Probes laufen parallel und fail-safe mit 6s-Timeout pro Request
Bugfix

Scoring-Korrekturen: Port-Scanner, DANE, Broken-Link-Checker

  • •Port-Scanner: Bug behoben, bei dem offene riskante Ports keine Punktabzuege gaben (Score stand faelschlicherweise immer auf 100)
  • •DANE-Check: Neue bedingte Bewertung. Ohne MX-Records wird DANE jetzt als "nicht anwendbar" markiert statt mit 50/100 abgestraft
  • •DANE-Check: Fehlerhafte DANE-Records (20), DANE ohne DNSSEC (60), korrekt konfiguriert (100)
  • •Broken-Link-Checker: 429 (Rate-Limit) und 403 (Blocked) werden nicht mehr als "broken" gewertet, sondern als eigene Statuskategorien ausgewiesen
  • •Broken-Link-Checker: Sanftere Prüfung - sequenziell pro Host mit 400ms Delay, honoriert Retry-After, nutzt Browser-User-Agent
  • •Broken-Link-Checker: Fallback von HEAD auf GET bei 403/405/415/429/501
Verbesserung

Broken-Link-Checker: URLs jetzt klickbar

  • •Alle gefundenen Links sind jetzt direkt anklickbar und öffnen sich in einem neuen Tab
  • •Ermöglicht schnelle manuelle Überprüfung von als "broken" gemeldeten URLs
  • •Gilt sowohl für das Bonus-Tool als auch für die Ergebnisse im Hauptscan
Verbesserung

Hosting- und DNS-Provider-Erkennung via Nameserver

  • •Nameserver-basierte Provider-Erkennung mit 80+ Patterns (IONOS, Strato, Hetzner, All-Inkl, GoDaddy, Cloudflare u.v.m.)
  • •DNS NS-Lookup als Fallback wenn WHOIS-Text keine Nameserver liefert (betrifft .de, .energy und viele weitere TLDs)
  • •Neues Feld "DNS-Provider" im Hosting-Check und Whois-Modul
  • •Hetzner-Nameserver (your-server.de, second-ns.de) korrekt erkannt
Verbesserung

Cookie-Klassifizierung: Hardcoded-Daten in Datenbank migriert

  • •Alle 700+ Cookie-Definitionen (Provider, Kategorien, Beschreibungen) von hardcoded Arrays in die Datenbank verschoben
  • •Crawler überschreibt manuelle Korrekturen nicht mehr (source: manual vs cookie.is)
  • •Neue DB-Felder: Subcategory, Privacy-URL, Match-Patterns (Regex), Source-Priorität
  • •Admin-Endpoint zum Seeden und Aktualisieren der Klassifizierungsdaten
  • •Wix-Cookies (svSession, ssr-caching) korrekt als "necessary" klassifiziert
Feature

Cookie-Datenbank mit 1.300+ Einträgen

  • •Umfangreiche Cookie-Datenbank mit Klassifizierung nach Kategorie, Provider und Zweck
  • •259 manuell kuratierte Einträge mit Provider-Zuordnung, Regex-Patterns und Datenschutz-URLs
  • •Saubere Kategorie-Verteilung: Necessary, Analytics, Marketing, Preferences
Neues Tool

Cookie-Scanner (DSGVO Cookie-Analyse)

  • •Browser-basierter Scan mit Puppeteer + Fetch-Fallback
  • •Erkennung von 50+ Consent-Management-Plattformen
  • •Klassifizierung von Cookies in 4 Kategorien mit Provider-Zuordnung
  • •Deep-Scan-Modus: analysiert mehrere Unterseiten
  • •DSGVO-Score mit konkreten Handlungsempfehlungen
  • •Erkennung von 40+ Tracking-Skripten (Google Analytics, Meta Pixel, HubSpot etc.)
Feature

Webalyzr Launch - Kostenlose Website-Analyse

  • •Hauptscan mit 10 Modulen: DNS, Mail (SPF/DKIM/DMARC), HTTP-Headers, SSL/TLS, Blacklist, SEO, Performance, Security, WHOIS und Accessibility
  • •130+ automatisierte Checks mit Scoring-System (0-100 Punkte)
  • •PDF-Report-Export mit detaillierten Ergebnissen und Handlungsempfehlungen
  • •Scan-Verlauf mit Vergleichsfunktion zum Tracken von Verbesserungen
  • •30+ Bonus-Tools: SPF/DMARC/DKIM-Generator, SSL-Checker, DNS-Lookup, Redirect-Checker, Port-Scanner, Whois-Lookup, Meta-Tag-Generator, Robots-Generator, CSP-Generator, htaccess-Generator u.v.m.
  • •Erweiterte Tools: Subdomain-Finder, TLS-Cipher-Analyse, Broken-Link-Checker, Sitemap-Validator, Structured-Data-Validator, Compliance-Check, Tech-Stack-Erkennung
  • •Knowledgebase mit Fachartikeln zu DNS, SSL, E-Mail-Sicherheit und Webstandards
  • •Zweisprachig (Deutsch/Englisch) mit automatischer Spracherkennung
  • •Datenschutzfreundlich: keine Benutzerkonten, keine Cookies, rein passive Analyse
  • •Backend: Fastify + TypeScript mit Redis/BullMQ Queue-System
  • •Frontend: Next.js 14 mit statischem Export und Tailwind CSS