# Betreiber-Fix-Guides fuer kuendigung.ebnermedia.de

kuendigung.ebnermedia.de: 11 priorisierte Betreiber-Guide(s) aus 34 Befund(en).

> Automatisch aus SaferPage-Scan-Evidenz und Betreiber-Guides abgeleitet. Betreiber müssen Umsetzung, Rechtsgrundlagen, interne Systeme und Re-Scan-Nachweise fachlich freigeben.

## Phasen
- **Triage** (0-48 Stunden): Hoch priorisierte Befunde reproduzieren, Owner bestätigen, Exportpaket sichern.
- **Fix umsetzen** (0-14 Tage): Consent-, Anbieter-, Notice-, Cookie-, Formular- oder Header-Änderungen umsetzen und versionieren.
- **Nutzertexte synchronisieren** (parallel): Datenschutzhinweis, Cookie-Erklärung, Anbieterregister und TrustHub an reale Technik anpassen.
- **Re-Scan und Freigabe** (nach Deployment): Erstaufruf, Ablehnen, Akzeptieren, GPC, Mobilansicht und priorisierte Unterseiten erneut prüfen.

## Guide-Streams
### Referrer- und URL-Leaks vermeiden
- Priorität: hoch / Owner: Webentwicklung/IT / Phase: 0-7 Tage
- Guide: https://saferpage.de/guides/referrer-und-url-leaks-vermeiden
- Befund: Drittanbieter können vollen Referrer-Kontext erhalten - Referrer-Policy prüfen und für Anbieter wie Google Static mindestens strict-origin-when-cross-origin oder strenger setzen.
- [ ] Befund reproduzieren: SaferPage-Report, betroffene URL, Consent-Zustand und Request-/Cookie-/Header-Evidence sichern.
- [ ] Ursache beheben: Konfiguration, Tag, Inhalt, Anbieter, Header oder Formular gemäß Guide ändern und Änderung versionieren.
- [ ] Nutzertext aktualisieren: Datenschutzhinweis, Cookie-Liste, Anbieterregister oder Trust-Dokumentation an die reale Technik anpassen.
- [ ] Re-Test und Abschluss: Referrer-Header und Query-Parameter in Request-Samples kontrollieren.

### Google-Dienste datenschutzfreundlich einbinden
- Priorität: hoch / Owner: Marketing/IT / Phase: 0-7 Tage
- Guide: https://saferpage.de/guides/google-dienste-datenschutzfreundlich-einbinden
- Befund: Google Consent Mode Default nicht erkannt - Vor dem ersten Google-Tag Consent-Defaults setzen, typischerweise ad_storage, analytics_storage, ad_user_data und ad_personalization auf denied.
- Befund: Google-Dienste & Drittanbieter - Google-Dienste einzeln prüfen, Consent Mode sauber setzen und Fonts möglichst lokal ausliefern.
- Befund: Google-Dienste - Befund mit Betreiber-Guide beheben und danach erneut scannen.
- Befund: Remote-Schriften von Google erkannt - Prüfen, ob Google Fonts lokal gehostet oder in der Datenschutzerklärung und Consent-Logik sauber erklärt werden.
- [ ] Befund reproduzieren: SaferPage-Report, betroffene URL, Consent-Zustand und Request-/Cookie-/Header-Evidence sichern.
- [ ] Ursache beheben: Konfiguration, Tag, Inhalt, Anbieter, Header oder Formular gemäß Guide ändern und Änderung versionieren.
- [ ] Nutzertext aktualisieren: Datenschutzhinweis, Cookie-Liste, Anbieterregister oder Trust-Dokumentation an die reale Technik anpassen.
- [ ] Re-Test und Abschluss: Google-Requests vor und nach Consent vergleichen.

### Drittanbieter im Datenschutz erklären
- Priorität: hoch / Owner: Legal/Vendor Owner / Phase: 0-7 Tage
- Guide: https://saferpage.de/guides/drittanbieter-datenschutz-erklaeren
- Befund: Erkannte Anbieter fehlen in der Datenschutzerklärung - Technisch erkannte Dienste in der Datenschutzerklärung konkret mit Anbieter, Zweck, Rechtsgrundlage, Empfänger und Transferhinweis benennen.
- Befund: Anbieterakten, AVV/DPA und Transfers priorisiert schließen - Top-Anbieter mit Zweck, Rolle, AVV/DPA, TOMs, Subprozessoren und Transfergrundlage dokumentieren.
- Befund: Browser-Nachweis - Unnötige Drittanbieter reduzieren und die verbleibenden Kontakte in Datenschutz und Consent abbilden.
- [ ] Befund reproduzieren: SaferPage-Report, betroffene URL, Consent-Zustand und Request-/Cookie-/Header-Evidence sichern.
- [ ] Ursache beheben: Konfiguration, Tag, Inhalt, Anbieter, Header oder Formular gemäß Guide ändern und Änderung versionieren.
- [ ] Nutzertext aktualisieren: Datenschutzhinweis, Cookie-Liste, Anbieterregister oder Trust-Dokumentation an die reale Technik anpassen.
- [ ] Re-Test und Abschluss: Drittanbieter-Liste gegen neue Requests und Cookies abgleichen.

### Datenschutzerklärung verbessern
- Priorität: hoch / Owner: Datenschutz/Content / Phase: 0-7 Tage
- Guide: https://saferpage.de/guides/datenschutzerklaerung-verbessern
- Befund: Datenschutzhinweis wirkt sehr dünn - Datenschutzerklärung sollte Verarbeitung, Rechtsgrundlagen, Cookies/Drittanbieter und Betroffenenrechte nachvollziehbar erklären.
- [ ] Befund reproduzieren: SaferPage-Report, betroffene URL, Consent-Zustand und Request-/Cookie-/Header-Evidence sichern.
- [ ] Ursache beheben: Konfiguration, Tag, Inhalt, Anbieter, Header oder Formular gemäß Guide ändern und Änderung versionieren.
- [ ] Nutzertext aktualisieren: Datenschutzhinweis, Cookie-Liste, Anbieterregister oder Trust-Dokumentation an die reale Technik anpassen.
- [ ] Re-Test und Abschluss: Datenschutzhinweis gegen Cookies, Anbieter, Formulare und Zwecke abgleichen.

### Barrierefreiheit bei Bannern und Formularen prüfen
- Priorität: hoch / Owner: UX/Content/IT / Phase: 0-7 Tage
- Guide: https://saferpage.de/guides/barrierefreiheit-cookie-banner-formulare
- Befund: Formularfelder ohne klare Beschriftung - Für jedes Eingabefeld ein sichtbares label, aria-label oder aria-labelledby setzen.
- Befund: Barrierefreiheit & Usability - Alt-Texte, Formularlabels, Button-Namen, lang-Attribut und Überschriftenstruktur für Nutzer und Screenreader prüfen.
- Befund: Cookie-Banner, Formulare und mobile Nutzung barriereärmer machen - Befund mit Betreiber-Guide beheben und danach erneut scannen.
- Befund: Bilder ohne Alternativtext - Inhaltliche Bilder mit alt-Text versehen; dekorative Bilder mit leerem alt oder aria-hidden kennzeichnen.
- [ ] Befund reproduzieren: SaferPage-Report, betroffene URL, Consent-Zustand und Request-/Cookie-/Header-Evidence sichern.
- [ ] Ursache beheben: Konfiguration, Tag, Inhalt, Anbieter, Header oder Formular gemäß Guide ändern und Änderung versionieren.
- [ ] Nutzertext aktualisieren: Datenschutzhinweis, Cookie-Liste, Anbieterregister oder Trust-Dokumentation an die reale Technik anpassen.
- [ ] Re-Test und Abschluss: Tastatur, Screenreader, Kontrast und Mobilansicht manuell prüfen.

### Datenschutz-Webseiten-Prüfkatalog umsetzen
- Priorität: hoch / Owner: Programm-Owner/Datenschutz / Phase: 0-7 Tage
- Guide: https://saferpage.de/guides/datenschutz-webseiten-pruefkatalog
- Befund: Wichtige Betreiberseiten nicht vollständig in der Linkstruktur gefunden - Datenschutz und Impressum sollten von der Startseite aus klar erreichbar sein.
- Befund: Seitenabdeckung & Crawl - Datenschutz, Impressum, Kontakt, Cookie-Hinweise und kritische Formularseiten klar verlinken und regelmäßig mitprüfen.
- Befund: Wichtige Unterseiten, Datenschutz und Formulare crawlbar verlinken - Befund mit Betreiber-Guide beheben und danach erneut scannen.
- Befund: Wenig interne Seiten auf der Startseite gefunden - Wichtige Seiten wie Datenschutz, Impressum, Kontakt und Cookie-Hinweise klar intern verlinken.
- [ ] Befund reproduzieren: SaferPage-Report, betroffene URL, Consent-Zustand und Request-/Cookie-/Header-Evidence sichern.
- [ ] Ursache beheben: Konfiguration, Tag, Inhalt, Anbieter, Header oder Formular gemäß Guide ändern und Änderung versionieren.
- [ ] Nutzertext aktualisieren: Datenschutzhinweis, Cookie-Liste, Anbieterregister oder Trust-Dokumentation an die reale Technik anpassen.
- [ ] Re-Test und Abschluss: Gesamten Scan nach Umsetzung der priorisierten Guides wiederholen.

### Security-Header setzen
- Priorität: hoch / Owner: IT/Security / Phase: 0-7 Tage
- Guide: https://saferpage.de/guides/security-header-setzen
- Befund: Content-Security-Policy fehlt - Header `content-security-policy` setzen und nach Deployment erneut prüfen.
- Befund: X-Frame-Options fehlt - Header `x-frame-options` setzen und nach Deployment erneut prüfen.
- Befund: X-Content-Type-Options fehlt - Header `x-content-type-options` setzen und nach Deployment erneut prüfen.
- Befund: Sicherheit, TLS & Header - HTTPS, Zertifikat, HSTS, CSP, zentrale Security-Header und externe Skriptquellen sauber konfigurieren.
- Befund: Security-Header, Referrer-Policy und Browser-Schutz setzen - Befund mit Betreiber-Guide beheben und danach erneut scannen.
- Befund: Cross-Origin-Embedder-Policy fehlt - Header `cross-origin-embedder-policy` setzen und nach Deployment erneut prüfen.
- Befund: Cross-Origin-Opener-Policy fehlt - Header `cross-origin-opener-policy` setzen und nach Deployment erneut prüfen.
- Befund: Cross-Origin-Resource-Policy fehlt - Header `cross-origin-resource-policy` setzen und nach Deployment erneut prüfen.
- Befund: Referrer-Policy fehlt - Header `referrer-policy` setzen und nach Deployment erneut prüfen.
- Befund: Permissions-Policy fehlt - Header `permissions-policy` setzen und nach Deployment erneut prüfen.
- [ ] Befund reproduzieren: SaferPage-Report, betroffene URL, Consent-Zustand und Request-/Cookie-/Header-Evidence sichern.
- [ ] Ursache beheben: Konfiguration, Tag, Inhalt, Anbieter, Header oder Formular gemäß Guide ändern und Änderung versionieren.
- [ ] Nutzertext aktualisieren: Datenschutzhinweis, Cookie-Liste, Anbieterregister oder Trust-Dokumentation an die reale Technik anpassen.
- [ ] Re-Test und Abschluss: Header, TLS, CSP und Referrer-Policy nach Deployment erneut scannen.

### Drittlandtransfer und Anbieter prüfen
- Priorität: hoch / Owner: Legal/Datenschutz / Phase: 0-7 Tage
- Guide: https://saferpage.de/guides/drittlandtransfer-und-anbieter-pruefen
- Befund: Drittland-/US-Anbieter im Browseraufruf prüfen - Für Anbieter wie Google Static, google.com, Google Fonts Transfergrundlage, AVV, DPF/SCC/TIA und Datenschutzhinweise prüfen.
- Befund: Anbieter-Jurisdiktion nicht klar ableitbar - Unklare Drittanbieter in Anbieterinventar, AVV-Prozess und Datenschutzerklärung nachrecherchieren.
- [ ] Befund reproduzieren: SaferPage-Report, betroffene URL, Consent-Zustand und Request-/Cookie-/Header-Evidence sichern.
- [ ] Ursache beheben: Konfiguration, Tag, Inhalt, Anbieter, Header oder Formular gemäß Guide ändern und Änderung versionieren.
- [ ] Nutzertext aktualisieren: Datenschutzhinweis, Cookie-Liste, Anbieterregister oder Trust-Dokumentation an die reale Technik anpassen.
- [ ] Re-Test und Abschluss: US-/Drittlandhosts, Anbieterrolle und Transfergrundlage erneut prüfen.

### Tracking und Consent reparieren
- Priorität: hoch / Owner: Marketing/IT/Datenschutz / Phase: 0-7 Tage
- Guide: https://saferpage.de/guides/tracking-und-consent-reparieren
- Befund: Datenschutz, Cookies & Consent - Tracking, Werbung und nicht notwendige Cookies vor Zustimmung blockieren und verständlich erklären.
- Befund: Tracking, Cookies oder Drittanbieter vor Einwilligung reparieren - Befund mit Betreiber-Guide beheben und danach erneut scannen.
- [ ] Befund reproduzieren: SaferPage-Report, betroffene URL, Consent-Zustand und Request-/Cookie-/Header-Evidence sichern.
- [ ] Ursache beheben: Konfiguration, Tag, Inhalt, Anbieter, Header oder Formular gemäß Guide ändern und Änderung versionieren.
- [ ] Nutzertext aktualisieren: Datenschutzhinweis, Cookie-Liste, Anbieterregister oder Trust-Dokumentation an die reale Technik anpassen.
- [ ] Re-Test und Abschluss: Erstaufruf, Ablehnen, Akzeptieren und GPC getrennt scannen.

### Servicekarte und Anbieterinventar aufbauen
- Priorität: mittel / Owner: Datenschutz/Marketing/IT / Phase: 7-30 Tage
- Guide: https://saferpage.de/guides/servicekarte-und-anbieterinventar-aufbauen
- Befund: Drittanbieter aus Browserkontakten einem Dienst zuordnen - Servicekarte je Anbieter anlegen und Datenschutzhinweis, CMP und Anbieterregister synchronisieren.
- [ ] Befund reproduzieren: SaferPage-Report, betroffene URL, Consent-Zustand und Request-/Cookie-/Header-Evidence sichern.
- [ ] Ursache beheben: Konfiguration, Tag, Inhalt, Anbieter, Header oder Formular gemäß Guide ändern und Änderung versionieren.
- [ ] Nutzertext aktualisieren: Datenschutzhinweis, Cookie-Liste, Anbieterregister oder Trust-Dokumentation an die reale Technik anpassen.
- [ ] Re-Test und Abschluss: Anbieter-Radar, Cookie-Inventar und Browserkontakte gegen die Servicekarten abgleichen.

### Externe Skripte und SRI absichern
- Priorität: niedrig / Owner: IT/Webentwicklung / Phase: quartalsweise
- Guide: https://saferpage.de/guides/externe-skripte-und-sri-absichern
- Befund: Externe Skripte ohne Subresource Integrity - Für statische CDN-Skripte `integrity` und passend `crossorigin` setzen oder Skripte kontrolliert lokal ausliefern.
- Befund: Meta-Description fehlt - Eine kurze Beschreibung setzen, die den Zweck der Seite erklärt.
- [ ] Befund reproduzieren: SaferPage-Report, betroffene URL, Consent-Zustand und Request-/Cookie-/Header-Evidence sichern.
- [ ] Ursache beheben: Konfiguration, Tag, Inhalt, Anbieter, Header oder Formular gemäß Guide ändern und Änderung versionieren.
- [ ] Nutzertext aktualisieren: Datenschutzhinweis, Cookie-Liste, Anbieterregister oder Trust-Dokumentation an die reale Technik anpassen.
- [ ] Re-Test und Abschluss: Externe Skripte, SRI, CSP und Consent-Auslösung erneut prüfen.

## Tracker- und Service-Mapping
- gstatic.com (vendor): Zweck, Rolle, AVV/DPA, Region, Transfer und Consent-Kategorie bestätigen.
- google.com (vendor): Zweck, Rolle, AVV/DPA, Region, Transfer und Consent-Kategorie bestätigen.
- fonts.gstatic.com (vendor): Zweck, Rolle, AVV/DPA, Region, Transfer und Consent-Kategorie bestätigen.
- code.jquery.com (vendor): Zweck, Rolle, AVV/DPA, Region, Transfer und Consent-Kategorie bestätigen.
- XSRF-TOKEN (cookie_storage): Zweck, Laufzeit, Anbieter und Consent-Erfordernis in Cookie-Erklärung und CMP pflegen.
- laravel_session (cookie_storage): Zweck, Laufzeit, Anbieter und Consent-Erfordernis in Cookie-Erklärung und CMP pflegen.
- gstatic.com (browser_request): Request einem Dienst, Zweck und Consent-Zustand zuordnen oder blockieren.
- google.com (browser_request): Request einem Dienst, Zweck und Consent-Zustand zuordnen oder blockieren.
- fonts.gstatic.com (browser_request): Request einem Dienst, Zweck und Consent-Zustand zuordnen oder blockieren.
- code.jquery.com (browser_request): Request einem Dienst, Zweck und Consent-Zustand zuordnen oder blockieren.

## CMS-/Shop- und Deployment-Playbooks
### Allgemeines Website-Deployment
Wenn kein eindeutiges CMS sichtbar ist, Release, Consent, Drittanbieter, Security-Header und Nachweise wie bei einem CMS-Update behandeln.
- Owner: Webbetrieb/IT/Datenschutz / Technik-Nachweis: https://saferpage.de/technik/kuendigung.ebnermedia.de/export / Re-Scan: https://saferpage.de/?url=kuendigung.ebnermedia.de
- [ ] Deployment-Quelle, Hosting/CDN, externe Skripte, Consent-Tool und wichtige Templates inventarisieren.
- [ ] Alle nicht notwendigen Drittanbieter vor Einwilligung blockieren und Anbieterzwecke dokumentieren.
- [ ] Security-Header, HTTPS/HSTS, Referrer-Policy, CSP und Cookie-Attribute prüfen.
- [ ] Nach Änderungen Re-Scan, Screenshot, JSON/CSV und Fix-Guides ablegen.
- Abnahme: Release-Änderung ist nachvollziehbar.
- Abnahme: Drittanbieter-/Cookie-Abgleich ist aktualisiert.
- Abnahme: Re-Scan und Nachweise sind verlinkt.
> Grenze: Passiv abgeleitet: SaferPage behauptet nur sichtbare CMS-/Shop-/Deployment-Signale. Betreiber müssen Plattform, Versionen, Plugins, Apps und interne Deployments bestätigen.

## Fehlalarm- und Grenzen-Review
Betreiber-Review-Playbook gegen typische Fehlalarme: Consent-/Paywall-Grenzen, Google-Consent-Anwendbarkeit, Formular-Coverage, Cookie-Kontext und Score-Wording.
### Consent-Wall, Paywall oder Overlay einordnen
- Frage: Hat der automatische Lauf ein Overlay, eine PUR-/Abo-Wall, Geoblocking oder eine Login-Grenze gesehen?
- Betreiberaktion: Wenn Overlay, Login, PUR-/Abo-Wall oder Geoblocking Inhalte verdeckt, Befunde zu Impressum, Formularen, Cookies und verstecktem Text manuell prüfen.
- Abnahme: Manuelle Prüfung ist mit Screenshot, Pfad, Entscheidung und Re-Scan-Vermerk dokumentiert.
- Nachweis: https://saferpage.de/kuendigung.ebnermedia.de / Guide: https://saferpage.de/methodik
> Grenze: Ein verdeckter Footer oder Paywall-Text ist kein automatischer Nachweis für fehlende Betreibertransparenz.

### Google Consent Mode nur bei Google-Evidenz fordern
- Frage: Wurden Google-Tag, Google-Domain oder Google-Tracking-ID wirklich gesehen?
- Betreiberaktion: Google-Tags, Zwecke, Consent Defaults und Tag-Gating anhand der konkreten Request-/Script-Evidence prüfen.
- Abnahme: Google-Dienst ist inventarisiert, Consent Default ist belegt und Re-Scan bestätigt das Gating.
- Nachweis: https://saferpage.de/kuendigung.ebnermedia.de/top-fixes-json / Guide: https://saferpage.de/guides/google-dienste-datenschutzfreundlich-einbinden
> Grenze: Diese Bewertung gilt nur für die gespeicherte Scan-Evidence; spätere Tag-Manager-Änderungen brauchen Re-Scan.

### Formular-Coverage gegen Startseiten-Sample abgleichen
- Frage: Gibt es Formulare auf Startseite oder direkt gecrawlten Unterseiten?
- Betreiberaktion: Alle 1 Formular(e) mit Zweck, Pflichtfeldern, Datenschutzlink, Tracking und Referrer-Kontext prüfen.
- Abnahme: Formularzweck, Pflichtfelder, Datenschutzhinweis und Consent-/Tracking-Kontext sind pro Formularseite nachvollziehbar.
- Nachweis: https://saferpage.de/abdeckung/kuendigung.ebnermedia.de/export / Guide: https://saferpage.de/guides/formulare-datenschutzkonform-absichern
> Grenze: SaferPage sendet keine Formulare ab und kennt keine internen Rechtsgrundlagen oder nachgelagerte Verarbeitung.

### Cookies nach Zweck statt pauschal bewerten
- Frage: Sind Cookies vor Einwilligung technisch notwendig oder Tracking/Marketing?
- Betreiberaktion: Cookie-Liste mit Zweck, Anbieter, Laufzeit, Consent-Kategorie und Auslösezeitpunkt pflegen; Funktionscookies von Tracking-Cookies trennen.
- Abnahme: Cookie-Erklärung und CMP zeigen dieselben Kategorien; Re-Scan belegt keine ungeklärten Trackingkontakte vor Einwilligung.
- Nachweis: https://saferpage.de/cookies/kuendigung.ebnermedia.de / Guide: https://saferpage.de/guides/cookie-laufzeiten-und-zwecke-pruefen
> Grenze: Load-Balancing, Sicherheit und Consent-Speicherung können notwendig sein; die Einordnung braucht Betreiberkontext.

### Score und Warntexte als Priorisierung formulieren
- Frage: Wird aus dem automatischen Score ein pauschales Seriositäts- oder Rechtsurteil?
- Betreiberaktion: Report-Quality-Smoke, Kurzreport und Management-Text prüfen: harte Aussagen wie zertifiziert, rechtssicher oder grundsätzlich gefährlich vermeiden.
- Abnahme: Bericht trennt Beobachtung, Betreibermaßnahme, Grenze und Re-Scan; keine nicht belegten Zertifikats- oder Rechtsclaims.
- Nachweis: https://saferpage.de/evidence/report-quality-smoke.json / Guide: https://saferpage.de/methodik
> Grenze: Score ist eine technische Priorisierung und kein abschließendes Urteil über Rechtmäßigkeit, Seriosität oder Sicherheit.

### Aussage-Ampel und Claim-Grenzen übernehmen
- Frage: Trennt der Report klar zwischen automatisch belegter Evidence, manueller Betreiberprüfung und Aussagen, die nicht behauptet werden dürfen?
- Betreiberaktion: Aussage-Ampel im Report prüfen und in internen Tickets übernehmen: automatisch belegt, manuell prüfen und nicht behaupten getrennt dokumentieren.
- Abnahme: Fix-Tickets, Betreiberfreigabe und Re-Scan-Notiz enthalten keine DSGVO-Freigabe, kein pauschales Seriositätsurteil und keine nicht belegten Sicherheitsclaims.
- Nachweis: https://saferpage.de/kuendigung.ebnermedia.de / Guide: https://saferpage.de/methodik
> Grenze: Die Aussage-Ampel ist eine Kommunikations- und Abnahmehilfe; sie ersetzt keine Rechtsberatung, keine Betreiberfreigabe und keine vollständige Prüfung hinter Login, Paywall oder Geoblocking.

