DACH-Crawler, Timer-Gates, User-Agent, Seedquelle, Batchgrenzen, Recent-Reportlinks und Preview-Coverage ohne Crawl-Start pruefen.
No-Secret: ja · erwartete Blocker: 0 Smoke-Evidence öffnenKonkurrenzanalyse / Abnahme
Benchmark-Abnahme mit Evidence und Go-live-Gates
Benchmark-Abnahme der SaferPage-Wettbewerbsanalyse: jede Konkurrenzanforderung wird mit öffentlicher Evidence, Primärquellen, Claim-Grenze, nächstem Schritt und Runbook-Links prüfbar gemacht.
Die Abnahme prüft öffentliche Produkt-Evidence gegen Wettbewerbsanforderungen. Sie ist keine Rechtsberatung, kein Zertifikat und ersetzt keine produktiven Betreiberfreigaben, Secrets, Zielsysteme, NDA-Flows oder privaten Dokumentzugriffe.
14Benchmarks
12akzeptiert
1mit Follow-up
1Go-live-Gate
17Evidence-URLs
39Runbooks
5/5No-Secret-Smokes
No-Secret-Smokes
Abnahmebelege für Produktiv-Gates
Trust-Readiness, Gated-Trust-Dossier, Viewer-Datenschutz und Questionnaire-Review ohne private Dokumente, Magic Links oder echte Uploads pruefen.
No-Secret: ja · erwartete Blocker: 1 Smoke-Evidence öffnenAlert-Zielsysteme, Dispatch-Runner, Runtime-Kontrollen und Dry-run ohne echte Zustellung pruefen.
No-Secret: ja · erwartete Blocker: 1 Smoke-Evidence öffnenURLhaus/Safe-Browsing/Feed-Connectoren, Storage-Gates und Feed-Runner ohne Feed-Secrets pruefen.
No-Secret: ja · erwartete Blocker: 2 Smoke-Evidence öffnenAPI-Key-Store, Runtime-Gates, Migration-Preflight und Deny-Fixtures ohne Key-Ausgabe pruefen.
No-Secret: ja · erwartete Blocker: 1 Smoke-Evidence öffnenAbnahmepunkte
Jede Konkurrenzanforderung mit Beweis und Grenze
Schneller DACH-All-in-one-Report
accepted_public_evidence · covered
Deutsche Scanner bündeln Recht, Datenschutz, Cookies, Technik, BFSG, E-Commerce, Sicherheit, SEO/KI-Sichtbarkeit, Performance, Score und Fixes in einem verständlichen Einstieg.
Produktive Secrets und Freigaben bleiben im Parity-Board separat sichtbar; der öffentliche DACH-All-in-one-Einstieg selbst ist als 10-Modul-Website-Check mit Coverage-Metriken belegt. Website-Check als zentrale Endnutzer-/Betreiberansicht nutzen und Coverage, Screenshot, Performance/UX, SEO/KI-Sichtbarkeit und Fix-Pfade im JSON beobachten.- Quellen
- Compliso (2026-06-09), WebPrüfer (2026-06-09)
- Evidence
- 1 URLs
Cookie-/Tracker-Report mit Screenshot-Kontext
accepted_public_evidence · covered
Cookie-Reports zeigen Thumbnail, Tracker, Kategorien, prior-consent-Probleme, Storage- und Drittanbieter-Signale.
Produktive CMP-Schreibpfade bleiben Betreiberfreigabe; öffentliche Reports dürfen keine Besucherlogs exportieren. 160x150-Seitenvorschauen, Cookie-Details und Top-Fixes konsequent in Kurzreport, A-Z und Crawler-Listen verlinkt halten.- Quellen
- Cookiebot (2026-06-09), Compliso (2026-06-09)
- Evidence
- 1 URLs
Öffentlicher Testindex mit Preview-Coverage
accepted_public_evidence · covered
Reife Scanner machen zuletzt geprüfte Domains, Thumbnail-/Preview-Kontext, vollständige Report-Verlinkung, wiederkehrende Scans und maschinenlesbare Nachweise nachvollziehbar.
Abdeckung bleibt ein laufender Betriebsindikator: fehlende 160x150-Previews müssen sofort als Backfill-Arbeit sichtbar werden. A-Z-Testindex, Sitemap-Shards, JSON/CSV/Markdown-Exports und Crawler-Ops weiter als öffentliche Discovery- und QA-Schicht nutzen.- Quellen
- Cookiebot (2026-06-09), siteboard (2026-06-09), SIWECOS (2026-06-09)
- Evidence
- 1 URLs
Geplante Security-Scans mit Alerting
waiting_for_external_go_live · blocked
Security-Scanner erwarten tägliche Prüfungen, automatische Nachrichten, Gesamtscore, Siegel und vollständige Sicherheitsberichte.
Security-Evidence-Index, Launch-Board, Badge, Alerts, Feed-Evidence und Dry-Run-Gates sind öffentlich belegbar; Feed-Credentials, Feed-Storage-Freigabe und produktive externe Alert-Ziele sind noch nicht aktiv. Security-Evidence-Index und Launch-Board als öffentliche Nachweisschicht nutzen; URLhaus/Safe-Browsing-Credentials, Storage-Approval und Delivery-Approval über No-Secret-Preflights freigeben.- Quellen
- SIWECOS (2026-06-09)
- Evidence
- 2 URLs
Kontinuierliches Privacy- und Policy-Monitoring
accepted_public_evidence · covered
Privacy-Tools überwachen Domains und Privacy Policies wiederkehrend, historisieren Ergebnisse und berücksichtigen regionale Zugriffssituationen.
Regionale Browser-Simulation und produktive Betreiber-Digests bleiben ausbaufähig, sind aber als Module und Delivery-Gates angelegt. Portfolio-Digest, Policy-Diff und Consent-Region-Regeln im Betreiberfluss enger verbinden.- Quellen
- Osano (2026-06-09)
- Evidence
- 1 URLs
Agentur-/Developer-DeepScan-Report
accepted_public_evidence · covered
Agenturtools liefern umfassende Website-Crawls, DeepScans bis etwa 100 Unterseiten, Unterseitenpriorisierung, Monitoring, PDF-Reports und Entwicklerberichte fuer Accessibility, Performance, SEO, Security und technische Qualitaet.
SaferPage hat Unterseiteninventar, Crawl-Abdeckung, 100-Unterseiten-Zielplan, Backoff-/Timeout-Guardrails, Performance/UX, Accessibility, Security, Fix-Guides und PDF-Pack; echte zusätzliche Unterseiten entstehen kontrolliert durch laufende Crawls statt durch ungebremste Last. Agentur-/Developer-DeepScan als zentrale Arbeitsansicht fuer 100er-Zielplan, Seiteninventar, Fix-Guides, Performance-/Accessibility-Evidence, PDF, Backoff-Grenzen und Re-Scan-Links nutzen.- Quellen
- siteboard (2026-06-09)
- Evidence
- 1 URLs
Performanter DACH-Crawler mit Backoff
accepted_public_evidence · covered
Crawl- und Monitoring-Werkzeuge muessen grosse Domainlisten kontrolliert verarbeiten: Queue, Durchsatz, Fehlerklassen, Retry, Backoff, ETA, User-Agent und direkte Reportlinks.
Vollstaendige Webabdeckung bleibt ein fortlaufender Seed-/Queue-Prozess; SaferPage begrenzt Last bewusst statt unkontrolliert zu crawlen. Durchsatz, Backlog-ETA, Error-Klassen und Retry-Backoff in Crawler-Operations beobachten und Batchgroesse nur schrittweise skalieren.- Quellen
- siteboard (2026-06-09), Osano (2026-06-09)
- Evidence
- 1 URLs
CMS-/Shop-spezifische Reparaturanleitungen
accepted_public_evidence · covered
DACH-Scanner werben mit CMS-Fix-Anleitungen, damit Betreiber nicht nur Befunde, sondern konkrete Plattformschritte fuer WordPress, TYPO3, Shopify, Wix, Webflow oder moderne Frontends bekommen.
CMS-Erkennung bleibt passiv und darf nicht mehr behaupten als sichtbare Header, HTML-, Asset- und Browserkontakte belegen; bei unsicherer Plattform zeigt SaferPage ein allgemeines Deployment-Playbook. CMS-/Deployment-Playbooks in Technik-Center, Markdown-Export, Fix-Guides und Re-Scan-Flow als Betreiberstandard halten.- Quellen
- Hugo Check (2026-06-09)
- Evidence
- 1 URLs
Evidence-basierter Browser-/Netzwerk-Audit
accepted_public_evidence · covered
Evidence-first Scanner erfassen reale Browser-Requests, Pre-Consent-Tracking, Drittanbieter-Datenflüsse und strukturierte Nachweise statt nur Checklisten.
Roh-HARs und personenbezogene Requestdaten werden nicht öffentlich exportiert; SaferPage veröffentlicht sanitisierte Request-/Cookie-/Consent-Evidence und Hash-Manifeste. Audit Evidence Pack, Drittanbieter-Matrix, Consent-Zustände, Screenshot und Integritätsmanifest als zentrale Nachweise im Report-Pack halten.- Quellen
- Auditzo (2026-06-09)
- Evidence
- 1 URLs
NIS2-, E-Mail- und Domain-Schutz-Signale
accepted_public_evidence · covered
DACH-Scanner kombinieren DSGVO-/Security-Prüfung mit E-Mail-/Domain-Schutz, NIS2-Selbstcheck, Unterseitenkontingenten, Monitoring und White-Label-Berichten.
NIS2-Betroffenheit kann aus öffentlichen Website-Signalen nicht verbindlich behauptet werden; Betreiber müssen Branche, Größe, Sonderfälle und Lieferkettenbezug bestätigen. NIS2-Self-Check, MX/SPF/DMARC, TLS/HSTS, Domainhistorie, Monitoring und Betreiberfragen weiterhin im DACH-All-in-one-Report verlinken.- Quellen
- Hugo Check (2026-06-09)
- Evidence
- 1 URLs
Eigenes E-Mail-/Domain-Schutz-Center
accepted_public_evidence · covered
DACH-Scanner zeigen E-Mail- und Domain-Schutz als eigenen Arbeitsbereich statt nur als Security-Nebenbefund.
DKIM wird bewusst nicht aus der Website behauptet; echte DKIM-Bestaetigung braucht Selectors oder ausgehende Mail-Header als Betreiber-Evidence. E-Mail-Schutz-Center aus Website-Check, Sitemap, NIS2, Security und Betreiber-Fix-Guides als Standardpfad verlinkt halten.- Quellen
- Hugo Check (2026-06-09), SIWECOS (2026-06-09)
- Evidence
- 1 URLs
Öffentliches Prüfbadge mit Verifizierungsseite
accepted_public_evidence · covered
DACH-Scanner und Cookie-/Security-Tools bieten sichtbare Siegel oder Verification-Badges, die auf öffentliche Statusseiten mit Score, Prüfdatum, geprüften Bereichen, Embed-Code und klarer Einordnung für Besucher führen.
Das Badge ist bewusst kein Zertifikat, kein Anwalts- oder BFSG-Siegel und keine Rechtsfreigabe; öffentliche Verifizierung darf nur passiv geprüfte Signale, Datum, Methodik, Score und Claim-Grenzen zeigen. Badge-Verifizierung in Reports, Badge-Index, Embed Center, Sitemap und Betreiber-Trustseiten als Standardziel halten; HTML/JSON/Markdown-Embeds müssen immer auf die Verifizierungsseite linken und Re-Scan nach wesentlichen Website-Änderungen empfehlen.- Quellen
- Website-Check.de (2026-06-09), CookieInspector (2026-06-09), SIWECOS (2026-06-09)
- Evidence
- 2 URLs
Gated Trust Center und Questionnaire-Automation
accepted_with_operator_followup · partial
Trust-Plattformen steuern NDA, Ablauf, Access Requests, Viewer-Privacy, Quellenbindung, Fragebogen-Upload und AI-gestützte Antworten.
Öffentliche Trust-/Questionnaire-Coverage ist im Gated-Readiness-Dossier belegbar; produktive Auth, NDA, private Dokumente, API-Key-Store und echte Questionnaire-Verarbeitung fehlen weiter als Live-Integration. Trust-Readiness-Index, Coverage-Metriken, Quellenbindung, Review-Gates und Claim-Grenzen beobachten; Trust-Access, Viewer-Privacy, API-Key-Store und Questionnaire-Review erst nach Auth-/Storage-/NDA-Freigaben produktiv schalten.- Quellen
- Vanta (2026-06-09), Conveyor (2026-06-09)
- Evidence
- 2 URLs
Gated-Trust-Go-live-Dossier mit Blockertransparenz
accepted_public_evidence · covered
Reife Trust-Plattformen machen vor privaten Freigaben transparent, welche Gates für Auth, NDA, private Dokumente, Viewer Privacy, Questionnaire Intake, Portalzugang, API-Keys und Delivery erfüllt sein müssen.
Das Dossier aktiviert bewusst keine produktiven Secrets, Einladungen, NDA-Signaturen oder privaten Dokumente; es macht die externen Freigaben prüfbar. Gated Readiness als Go-live-Checkliste vor jeder produktiven Trust-Freigabe verwenden und erst nach gruenen Runtime-/Delivery-/Auth-Gates private Zugriffe schalten.- Quellen
- Vanta (2026-06-09), Conveyor (2026-06-09)
- Evidence
- 1 URLs