# SaferPage Benchmark-Abnahme

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.

## Kennzahlen
- benchmark_count: 14
- accepted_public_evidence_count: 12
- accepted_with_operator_followup_count: 1
- waiting_for_external_go_live_count: 1
- public_evidence_url_count: 17
- runbook_link_count: 39
- source_detail_count: 24
- readiness_smoke_count: 7
- readiness_smoke_ok_count: 7
- readiness_smoke_failed_check_count: 0
- readiness_smoke_blocked_expected_count: 5
- readiness_smoke_target_count: 163

## No-Secret-Smokes
- **DACH Crawler Readiness Smoke**: ok, failed_checks=0, expected_blockers=0, Nachweis: https://saferpage.de/evidence/crawler-readiness-smoke.json
- **Trust-Readiness Smoke**: ok, failed_checks=0, expected_blockers=1, Nachweis: https://saferpage.de/evidence/trust-readiness-smoke.json
- **Competitive Source Availability Smoke**: ok, failed_checks=0, expected_blockers=0, Nachweis: https://saferpage.de/evidence/competitive-source-availability-smoke.json
- **Competitive Evidence Health Smoke**: ok, failed_checks=0, expected_blockers=0, Nachweis: https://saferpage.de/evidence/competitive-evidence-health-smoke.json
- **Alert-Delivery Readiness Smoke**: ok, failed_checks=0, expected_blockers=1, Nachweis: https://saferpage.de/evidence/alert-delivery-readiness-smoke.json
- **Security-Feed Readiness Smoke**: ok, failed_checks=0, expected_blockers=2, Nachweis: https://saferpage.de/evidence/security-feed-readiness-smoke.json
- **API-Key Readiness Smoke**: ok, failed_checks=0, expected_blockers=1, Nachweis: https://saferpage.de/evidence/api-key-readiness-smoke.json

## Abnahmepunkte
### Schneller DACH-All-in-one-Report
- Entscheidung: accepted_public_evidence
- Status: covered
- Wettbewerber-Signal: Deutsche Scanner bündeln Recht, Datenschutz, Cookies, Technik, BFSG, E-Commerce, Sicherheit, SEO/KI-Sichtbarkeit, Performance, Score und Fixes in einem verständlichen Einstieg.
- Claim-Grenze: 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.
- Nächster Schritt: Website-Check als zentrale Endnutzer-/Betreiberansicht nutzen und Coverage, Screenshot, Performance/UX, SEO/KI-Sichtbarkeit und Fix-Pfade im JSON beobachten.
- Evidence: https://saferpage.de/website-check/anrufer.info/json
- Runbook: Primärnachweis - https://saferpage.de/website-check/anrufer.info/json

### Cookie-/Tracker-Report mit Screenshot-Kontext
- Entscheidung: accepted_public_evidence
- Status: covered
- Wettbewerber-Signal: Cookie-Reports zeigen Thumbnail, Tracker, Kategorien, prior-consent-Probleme, Storage- und Drittanbieter-Signale.
- Claim-Grenze: Produktive CMP-Schreibpfade bleiben Betreiberfreigabe; öffentliche Reports dürfen keine Besucherlogs exportieren.
- Nächster Schritt: 160x150-Seitenvorschauen, Cookie-Details und Top-Fixes konsequent in Kurzreport, A-Z und Crawler-Listen verlinkt halten.
- Evidence: https://saferpage.de/anrufer.info/share-card-json
- Runbook: Primärnachweis - https://saferpage.de/anrufer.info/share-card-json

### Öffentlicher Testindex mit Preview-Coverage
- Entscheidung: accepted_public_evidence
- Status: covered
- Wettbewerber-Signal: Reife Scanner machen zuletzt geprüfte Domains, Thumbnail-/Preview-Kontext, vollständige Report-Verlinkung, wiederkehrende Scans und maschinenlesbare Nachweise nachvollziehbar.
- Claim-Grenze: Abdeckung bleibt ein laufender Betriebsindikator: fehlende 160x150-Previews müssen sofort als Backfill-Arbeit sichtbar werden.
- Nächster Schritt: A-Z-Testindex, Sitemap-Shards, JSON/CSV/Markdown-Exports und Crawler-Ops weiter als öffentliche Discovery- und QA-Schicht nutzen.
- Evidence: https://saferpage.de/tests-json
- Runbook: Primärnachweis - https://saferpage.de/tests-json
- Runbook: Crawler-Timer - https://saferpage.de/crawler/timer-runner-json

### Geplante Security-Scans mit Alerting
- Entscheidung: waiting_for_external_go_live
- Status: blocked
- Wettbewerber-Signal: Security-Scanner erwarten tägliche Prüfungen, automatische Nachrichten, Gesamtscore, Siegel und vollständige Sicherheitsberichte.
- Claim-Grenze: Security-Evidence-Index, Launch-Board, Badge, Alerts, rollenbasierte Notification-Digests, Subscription-Policy, Feed-Evidence und Dry-Run-Gates sind öffentlich belegbar; Feed-Credentials, Feed-Storage-Freigabe und produktive externe Alert-Ziele sind noch nicht aktiv.
- Nächster Schritt: Security-Evidence-Index und Launch-Board als öffentliche Nachweisschicht nutzen; URLhaus/Safe-Browsing-Credentials, Storage-Approval und Delivery-Approval über No-Secret-Preflights freigeben.
- Evidence: https://saferpage.de/sicherheit/feed-launch-board-json
- Evidence: https://saferpage.de/security-evidence-json
- Runbook: Primärnachweis - https://saferpage.de/sicherheit/feed-launch-board-json
- Runbook: Zweiter Nachweis - https://saferpage.de/security-evidence-json
- Runbook: Feed-Credentials prüfen - https://saferpage.de/sicherheit/feed-credential-preflight-json
- Runbook: Storage-Freigabe prüfen - https://saferpage.de/sicherheit/feed-storage-readiness-json
- Runbook: Alert-Zustellung prüfen - https://saferpage.de/integrationen/delivery-credential-preflight-json
- Runbook: Go-live-Gates - https://saferpage.de/betreiber/go-live-json

### Kontinuierliches Privacy- und Policy-Monitoring
- Entscheidung: accepted_public_evidence
- Status: covered
- Wettbewerber-Signal: Privacy-Tools überwachen Domains und Privacy Policies wiederkehrend, historisieren Ergebnisse und berücksichtigen regionale Zugriffssituationen.
- Claim-Grenze: Regionale Browser-Simulation und produktive externe Zustellung bleiben ausbaufähig; Monitoring-Digest, Portfolio-Digest, Policy-Diff und Owner-Warteschlangen sind als öffentlicher Betreiberfluss verbunden.
- Nächster Schritt: Monitoring-Digest als zentrale Betreiberansicht fuer Regressionen, Owner-Warteschlangen, Policy-Diff, Portfolio-Digest und Re-Scan-/Fix-Links nutzen.
- Evidence: https://saferpage.de/monitoring/digest-json
- Runbook: Primärnachweis - https://saferpage.de/monitoring/digest-json
- Runbook: Portfolio-Digest - https://saferpage.de/portfolio/digest
- Runbook: Policy-Lifecycle - https://saferpage.de/policies/anrufer.info/export

### Agentur-/Developer-DeepScan-Report
- Entscheidung: accepted_public_evidence
- Status: covered
- Wettbewerber-Signal: Agenturtools liefern umfassende Website-Crawls, DeepScans bis etwa 100 Unterseiten, Unterseitenpriorisierung, Monitoring, PDF-Reports und Entwicklerberichte fuer Accessibility, Performance, SEO, Security und technische Qualitaet.
- Claim-Grenze: 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.
- Nächster Schritt: Agentur-/Developer-DeepScan als zentrale Arbeitsansicht fuer 100er-Zielplan, Seiteninventar, Fix-Guides, Performance-/Accessibility-Evidence, PDF, Backoff-Grenzen und Re-Scan-Links nutzen.
- Evidence: https://saferpage.de/agentur/anrufer.info/deepscan-json
- Runbook: Primärnachweis - https://saferpage.de/agentur/anrufer.info/deepscan-json
- Runbook: Report-Pack PDF - https://saferpage.de/report-pack/anrufer.info/pdf
- Runbook: Fix-Guides - https://saferpage.de/fix-guides/anrufer.info/export

### Performanter DACH-Crawler mit Backoff
- Entscheidung: accepted_public_evidence
- Status: covered
- Wettbewerber-Signal: Crawl- und Monitoring-Werkzeuge muessen grosse Domainlisten kontrolliert verarbeiten: Queue, Durchsatz, Fehlerklassen, Retry, Backoff, ETA, User-Agent und direkte Reportlinks.
- Claim-Grenze: Vollstaendige Webabdeckung bleibt ein fortlaufender Seed-/Queue-Prozess; SaferPage begrenzt Last bewusst statt unkontrolliert zu crawlen.
- Nächster Schritt: Durchsatz, Backlog-ETA, Error-Klassen und Retry-Backoff in Crawler-Operations beobachten und Batchgroesse nur schrittweise skalieren.
- Evidence: https://saferpage.de/crawler/ops-json
- Runbook: Primärnachweis - https://saferpage.de/crawler/ops-json
- Runbook: Crawler-Timer - https://saferpage.de/crawler/timer-runner-json
- Runbook: A-Z-Testindex - https://saferpage.de/tests-json

### CMS-/Shop-spezifische Reparaturanleitungen
- Entscheidung: accepted_public_evidence
- Status: covered
- Wettbewerber-Signal: 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.
- Claim-Grenze: 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.
- Nächster Schritt: CMS-/Deployment-Playbooks in Technik-Center, Markdown-Export, Fix-Guides und Re-Scan-Flow als Betreiberstandard halten.
- Evidence: https://saferpage.de/technik/anrufer.info/export
- Runbook: Primärnachweis - https://saferpage.de/technik/anrufer.info/export

### Evidence-basierter Browser-/Netzwerk-Audit
- Entscheidung: accepted_public_evidence
- Status: covered
- Wettbewerber-Signal: Evidence-first Scanner erfassen reale Browser-Requests, Pre-Consent-Tracking, Drittanbieter-Datenflüsse und strukturierte Nachweise statt nur Checklisten.
- Claim-Grenze: Roh-HARs und personenbezogene Requestdaten werden nicht öffentlich exportiert; SaferPage veröffentlicht sanitisierte Request-/Cookie-/Consent-Evidence und Hash-Manifeste.
- Nächster Schritt: Audit Evidence Pack, Drittanbieter-Matrix, Consent-Zustände, Screenshot und Integritätsmanifest als zentrale Nachweise im Report-Pack halten.
- Evidence: https://saferpage.de/anrufer.info#audit-evidence
- Runbook: Primärnachweis - https://saferpage.de/anrufer.info#audit-evidence

### NIS2-, E-Mail- und Domain-Schutz-Signale
- Entscheidung: accepted_public_evidence
- Status: covered
- Wettbewerber-Signal: DACH-Scanner kombinieren DSGVO-/Security-Prüfung mit E-Mail-/Domain-Schutz, NIS2-Selbstcheck, Unterseitenkontingenten, Monitoring und White-Label-Berichten.
- Claim-Grenze: NIS2-Betroffenheit kann aus öffentlichen Website-Signalen nicht verbindlich behauptet werden; Betreiber müssen Branche, Größe, Sonderfälle und Lieferkettenbezug bestätigen.
- Nächster Schritt: NIS2-Self-Check, MX/SPF/DMARC, TLS/HSTS, Domainhistorie, Monitoring und Betreiberfragen weiterhin im DACH-All-in-one-Report verlinken.
- Evidence: https://saferpage.de/nis2/anrufer.info/export
- Runbook: Primärnachweis - https://saferpage.de/nis2/anrufer.info/export

### Eigenes E-Mail-/Domain-Schutz-Center
- Entscheidung: accepted_public_evidence
- Status: covered
- Wettbewerber-Signal: DACH-Scanner zeigen E-Mail- und Domain-Schutz als eigenen Arbeitsbereich statt nur als Security-Nebenbefund.
- Claim-Grenze: DKIM wird bewusst nicht aus der Website behauptet; echte DKIM-Bestaetigung braucht Selectors oder ausgehende Mail-Header als Betreiber-Evidence.
- Nächster Schritt: E-Mail-Schutz-Center aus Website-Check, Sitemap, NIS2, Security und Betreiber-Fix-Guides als Standardpfad verlinkt halten.
- Evidence: https://saferpage.de/email-schutz/anrufer.info/json
- Runbook: Primärnachweis - https://saferpage.de/email-schutz/anrufer.info/json

### Öffentliches Prüfbadge mit Verifizierungsseite
- Entscheidung: accepted_public_evidence
- Status: covered
- Wettbewerber-Signal: 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.
- Claim-Grenze: 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.
- Nächster Schritt: 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.
- Evidence: https://saferpage.de/badge/anrufer.info/verifizierung-json
- Evidence: https://saferpage.de/badges-json
- Runbook: Primärnachweis - https://saferpage.de/badge/anrufer.info/verifizierung-json
- Runbook: Zweiter Nachweis - https://saferpage.de/badges-json
- Runbook: Embed Center - https://saferpage.de/badge/anrufer.info/embed-json

### Gated Trust Center und Questionnaire-Automation
- Entscheidung: accepted_with_operator_followup
- Status: partial
- Wettbewerber-Signal: Trust-Plattformen steuern NDA, Ablauf, Access Requests, Viewer-Privacy, Quellenbindung, Fragebogen-Upload und AI-gestützte Antworten.
- Claim-Grenze: Öffentliche Trust-/Questionnaire-Coverage, Quellenbindung, Review-Gates, Delegationsvorschläge und Notification-Digest sind belegbar; produktive Auth, NDA, private Dokumente, API-Key-Store, echter Versand und echte Questionnaire-Verarbeitung fehlen weiter als Live-Integration.
- Nächster Schritt: Trust-Readiness-Index, Coverage-Metriken, Quellenbindung, Delegation, Notification-Digest und Claim-Grenzen beobachten; Trust-Access, Viewer-Privacy, API-Key-Store und Questionnaire-Review erst nach Auth-/Storage-/NDA-/Delivery-Freigaben produktiv schalten.
- Evidence: https://saferpage.de/trust/anrufer.info/gated-readiness-json
- Evidence: https://saferpage.de/trust-readiness-json
- Runbook: Primärnachweis - https://saferpage.de/trust/anrufer.info/gated-readiness-json
- Runbook: Zweiter Nachweis - https://saferpage.de/trust-readiness-json
- Runbook: Trust-Go-live - https://saferpage.de/trust/anrufer.info/go-live-json
- Runbook: Access Requests - https://saferpage.de/datenraum/anrufer.info/zugriffe-json
- Runbook: Viewer Privacy - https://saferpage.de/trust/anrufer.info/viewer-datenschutz-json
- Runbook: Questionnaire Review - https://saferpage.de/trust/anrufer.info/fragebogen-review-json
- Runbook: API-Key-Gates - https://saferpage.de/api-zugriff/key-readiness-json

### Gated-Trust-Go-live-Dossier mit Blockertransparenz
- Entscheidung: accepted_public_evidence
- Status: covered
- Wettbewerber-Signal: 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.
- Claim-Grenze: Das Dossier aktiviert bewusst keine produktiven Secrets, Einladungen, NDA-Signaturen oder privaten Dokumente; es macht die externen Freigaben prüfbar.
- Nächster Schritt: Gated Readiness als Go-live-Checkliste vor jeder produktiven Trust-Freigabe verwenden und erst nach gruenen Runtime-/Delivery-/Auth-Gates private Zugriffe schalten.
- Evidence: https://saferpage.de/trust/anrufer.info/gated-readiness-json
- Runbook: Primärnachweis - https://saferpage.de/trust/anrufer.info/gated-readiness-json
- Runbook: Trust-Go-live - https://saferpage.de/trust/anrufer.info/go-live-json
- Runbook: Access Requests - https://saferpage.de/datenraum/anrufer.info/zugriffe-json
- Runbook: Viewer Privacy - https://saferpage.de/trust/anrufer.info/viewer-datenschutz-json
- Runbook: Questionnaire Review - https://saferpage.de/trust/anrufer.info/fragebogen-review-json
- Runbook: API-Key-Gates - https://saferpage.de/api-zugriff/key-readiness-json