iO VERIFY: FAQ

Trackingfrei bedeutet für uns: Keine Datenweitergabe an Dritte ohne aktive, bewusste Handlung des Nutzers. Das schließt den Einsatz von Third-Party-Cookies, versteckten Tracking-Pixeln, externen Analyse-Tools (wie Google Analytics) und extern geladenen Skripten konsequent aus. Wer das Siegel trägt, respektiert die digitale Privatsphäre seiner Besucher kompromisslos.

Eingebettete iframes von Drittanbietern laden fast immer automatisch Hintergrundskripte und Cookies. Selbst sogenannte "Privacy-Modi" (wie bei YouTube-nocookie) bauen oft noch Verbindungen zu den Servern der Anbieter auf und übertragen IP-Adressen der Nutzer, sobald die Seite geladen wird. Das widerspricht unseren Kriterien für das iO VERIFY Siegel.

Die Lösung ist der sogenannte "Fake-Player" oder "Cover-Link". Anstatt einen fremden iframe zu laden, baust du die visuelle Illusion eines Players selbst nach. Lade das Coverbild auf deinen Server hoch, baue es in dein Layout ein (z. B. 16:9 oder 1:1) und lege optional einen Play-Button darüber. Verlinke dieses Konstrukt dann direkt auf die externe Plattform mit dem Attribut target="_blank". Der Effekt: Die Seite bleibt ultraschnell, es fließen null Daten an Dritte beim Laden, und der Nutzer kommt mit einem Klick genau dorthin, wo die Medien spielen.

Nein. Die Einbindung von Webfonts (wie Google Fonts) über externe Server oder das Laden von Frameworks über CDNs überträgt beim Seitenaufruf automatisch die IP-Adresse des Besuchers an diese Drittanbieter. Um das Siegel zu erhalten, müssen alle Assets (Schriftarten, Bilder, Skripte, Stylesheets) lokal auf deinem eigenen Server gehostet werden.

Du musst nicht komplett "blind" fliegen, aber das Tracking muss datenschutzfreundlich und lokal erfolgen. Erlaubt sind die reine Auswertung von Server-Logfiles (bei denen die IP-Adressen anonymisiert gespeichert werden) sowie lokal gehostete Analytics-Lösungen (wie cookiefreie Matomo-Instanzen oder Plausible), die ausschließlich auf deinem Server laufen und keine Daten an Dritte senden.

Nein. Like-Buttons, Share-Widgets oder Feed-Boxen, die direkt von Meta, X oder anderen sozialen Netzwerken geladen werden, sind untersagt. Auch hier gilt das Prinzip des "statischen Links": Nutze eigene, lokal gehostete Icons, die den Nutzer als simplen HTML-Link zur jeweiligen Plattform führen.

Die kurze Antwort: Nein! Da du keine zustimmungspflichtigen Third-Party-Cookies (wie Meta-Pixel oder Werbetracker) einsetzt, entfällt die rechtliche Notwendigkeit für Cookie-Banner oder Consent-Management-Plattformen. Deine Seite ist sofort nutzbar. Rein funktionale Cookies, z. B. für einen Warenkorb oder Login, benötigen keinen Banner.

Wir prüfen die Seite unter realen Bedingungen. Dazu gehört ein Check des Quellcodes und die Überwachung des Network-Tabs in den Entwicklertools des Browsers beim Aufrufen deiner Seite. Sobald beim initialen Laden der Seite eine Verbindung zu einem nicht autorisierten Drittanbieter-Server aufgebaut wird, schlägt die Verifizierung fehl.

Nein. Für die Verifizierung ist der verwendete Tech-Stack zweitrangig. Uns interessiert ausschließlich der Network-Traffic beim Endnutzer. Wenn der Browser des Besuchers beim Aufruf der Seite keine ungefragten Verbindungen zu Drittanbietern aufbaut und keine Third-Party-Cookies setzt, qualifiziert sich die Seite.

Das ist theoretisch möglich, in der Praxis aber oft die größte Herausforderung. Viele kommerzielle SaaS-Baukästen laden standardmäßig eigene Analyse-Skripte, externe Schriftarten oder setzen Session-Cookies. Wer einen solchen Baukasten nutzt, muss prüfen, ob die Plattform einen strikten "Privacy Mode" ohne externe Anfragen anbietet. Gelingt das nicht, schlägt die Verifizierung fehl.

Bei selbstgehosteten CMS hast du deutlich bessere Karten, da du die Kontrolle über deinen eigenen Server hast. Die Gefahr liegt hier bei installierten Themes oder Plugins, die ungefragt Google Fonts laden oder Tracking-Pixel integrieren. Wer ein CMS nutzt, muss alle Erweiterungen streng auditieren.

Definitiv. Wer seine Seite selbst schreibt (HTML/CSS/JS/PHP) oder moderne Static Site Generatoren nutzt, hat die absolute Kontrolle über jeden einzelnen Request. Es gibt keine versteckten Core-Skripte, die dazwischenfunken.

Das Siegel ist kein Freifahrtschein für die Ewigkeit. Wir führen in regelmäßigen Abständen Stichproben durch. Wenn ein Anbieter durch ein Update anfängt, externe Skripte zu laden, verliert die Seite die Kriterien für unsere Verifizierung.

Normale Video-Embeds sind tabu (auch im erweiterten Datenschutzmodus). Nutze entweder die "Fake-Player"-Methode und verlinke ein Vorschaubild direkt zum Video, oder lade das Video als .mp4-Datei auf deinen eigenen Webspace hoch und binde es über den nativen HTML5-Video-Tag lokal ein.

Ja, solange es saubere, statische HTML-Links sind. Das Tracking passiert erst, wenn der Nutzer den Link klickt und deine Seite verlässt. Verboten sind jedoch dynamische Werbenetzwerke oder JavaScript-Snippets von Affiliate-Netzwerken, die Banner automatisiert ausspielen.

Kopiere niemals blind den bereitgestellten JavaScript-Embed-Code deines Newsletter-Tools. Nutze stattdessen reine HTML-Formulare. Du baust das Form-Element selbst und trägst als Aktion lediglich die Ziel-URL des Anbieters ein. So werden die Daten erst beim aktiven Klick auf "Abonnieren" übergeben.

Ja, aber mit Disziplin. Externe JavaScript-Einbindungen auf der Checkout-Seite zur Betrugsprävention (wie bei On-Page-Zahlungsfenstern) verstoßen gegen die Regeln. Die Lösung ist ein Hosted Checkout: Der gesamte Shop läuft lokal auf deinem Server, für den eigentlichen Bezahlvorgang leitest du den Kunden per klassischem Redirect auf die externe, sichere Zahlungsseite des Anbieters weiter.

Problem: Schriftarten werden oft im Hintergrund von externen Servern geladen und übertragen dabei die IP des Nutzers.

Lösung: Lokales Hosting. Lade die benötigten Schriften herunter, lege sie auf deinem Server ab und binde sie über CSS ein. In CMS wie WordPress helfen Plugins, externe Anfragen zu blockieren.

Problem: Unsichtbare Tools wie reCAPTCHA analysieren dauerhaft das Nutzerverhalten und setzen Cookies – ein sofortiges K.O. für das Siegel.

Lösung: Nutze unsichtbare Honeypot-Felder, die nur von Spam-Bots ausgefüllt werden, oder einfache, lokal generierte Rechenaufgaben als Schutz.

Problem: WordPress sendet standardmäßig Daten an Automattic für Gravatare und lädt Emojis von externen Servern nach.

Lösung: Deaktiviere Gravatare in den Einstellungen und nutze lokale Standard-Bilder. Externe Emojis lassen sich mit wenigen Code-Zeilen oder Plugins komplett abschalten.

Problem: Interaktive Karten laden im Hintergrund massenhaft Skripte und Bildkacheln. Auch wenn OpenStreetMap (OSM) datenschutzfreundlicher als Google ist, wird beim automatischen Laden der Karte die IP-Adresse des Besuchers ungefragt an den jeweiligen Drittserver übertragen. Für das Siegel ist das beim initialen Seitenaufruf nicht erlaubt.

Lösung 1 (Der Fake-Player): Mache einen hochwertigen Screenshot deines Kartenausschnitts, binde dieses Bild lokal auf deiner Webseite ein und verlinke es mit einem target="_blank" auf den externen Kartendienst.

Lösung 2 (Die Profi-Variante / Self-Hosting): Stell dir eine digitale Karte wie ein riesiges Puzzle vor. Anstatt das Skript zur Bedienung der Karte und die einzelnen Puzzleteile (die Kartenkacheln oder "Tiles") live von externen Servern laden zu lassen, baust du dir deinen eigenen, kleinen Kartenserver auf. Das bedeutet:

• Du hostest das Kartenskript (z. B. Leaflet.js) direkt in deinem Projektordner.
• Du lädst die benötigten Karten-Bilder (Tiles) für deinen Bereich vorab auf deinen eigenen Webspace herunter.
• Du verknüpfst das lokale Skript mit deinen lokalen Bildern.

Das Ergebnis: Wenn der Nutzer auf der Karte zoomt oder wischt, kommuniziert sein Browser ausschließlich mit deinem eigenen Server. Die Karte ist voll interaktiv, aber es fließen absolut keine Daten an Dritte ab – 100 % iO VERIFY-konform. (Hinweis: Da dies technisch anspruchsvoll ist, raten wir hier zu Individualentwicklungen).

Problem: Selbst ein "leerer" Tag Manager ist ein externes Skript. Tools wie Meta Pixel sind ohnehin tabu.

Lösung: Entferne alle Tag Manager restlos. Nutze ausschließlich lokal gehostete Analytics-Lösungen (ohne Cookies und mit IP-Anonymisierung) oder werte direkt deine Server-Logfiles aus.

Problem: Das Einbinden von Bibliotheken über externe Content Delivery Networks (CDNs) generiert Requests an Dritte.

Lösung: Lade die entsprechenden Script- oder CSS-Dateien herunter, packe sie in dein Projekt und lade sie ausschließlich lokal von deiner eigenen Domain.

Lösung: Öffne deine .htaccess-Datei und füge diesen Block ein. Er erlaubt nur Inhalte von deiner eigenen Domain und gibt unser Siegel als vertrauenswürdige Bildquelle frei:

<IfModule mod_headers.c>
    Header set Content-Security-Policy "default-src 'self'; img-src 'self' https://verify.intuitionorbit.de; style-src 'self' 'unsafe-inline';"
</IfModule>

Lösung: Ergänze deine .htaccess um diese Zeile, um zu verhindern, dass dein Server Informationen über die Herkunft deiner Besucher an Dritte weitergibt:

Header always set Referrer-Policy "no-referrer"

Lösung: Um Verbindungen sicher zu machen und Umleitungs-Angriffe zu verhindern, nutze diesen Header (nur bei aktivem SSL-Zertifikat!):

Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

Lösung: Wenn du eine strikte Content Security Policy verwendest, musst du unsere Domain explizit erlauben. Stelle sicher, dass die Zeile in deinem CSP-Header wie folgt aussieht:

img-src 'self' https://verify.intuitionorbit.de;

So stellst du sicher, dass das iO VERIFY Siegel trotz hoher Sicherheitsstandards korrekt angezeigt wird.

Der Zertifizierungsprozess ist in drei klare Phasen unterteilt:

• Phase 1: Die Selbstdiagnose (Kostenlos). Bevor du dich bei uns meldest, scanne deine Architektur durch einen unabhängigen, auf Privatsphäre fokussierten Scanner wie Webbkoll. So deckst du offensichtliche Lecks (wie Third-Party-Requests) sofort selbst auf.
• Phase 2: Die Bereinigung. Schließe alle vom Scanner erfassten Lücken. Erst wenn deine Architektur sauber ist, solltest du das offizielle Audit anfordern.
• Phase 3: Das offizielle Audit (Kostenpflichtig). Hier übernimmt unsere Instanz. Wir prüfen deine Seite tiefgehend auf Faktoren, die automatisierte Scanner übersehen. Sind alle Protokolle erfüllt, wird das iO VERIFY Siegel erteilt.

Unser Siegel steht für hohe Qualität und Vertrauen. Deshalb prüfen wir jedes eingereichte Projekt manuell und sorgfältig anhand unserer strikten Kriterien. Aufgrund der aktuell hohen Nachfrage nimmt dieser gründliche Prozess etwas mehr Zeit in Anspruch als gewöhnlich. Wir bearbeiten alle Anträge fair in der Reihenfolge ihres Eingangs und arbeiten mit Hochdruck daran, dein Projekt schnellstmöglich zu bewerten.

Wir vergeben keine automatisierten Freifahrtscheine. Jedes Projekt wird manuell und intensiv von unserer operativen Instanz auf Herz und Nieren geprüft – vom Quellcode bis hin zu Netzwerk-Traffic und Server-Side-Tracking-Indizien. Die einmalige Gebühr deckt diese dedizierte Lebenszeit und unsere technische Expertise ab. Nur so behält das Siegel seinen kompromisslosen Wert für echte Datensouveränität.

Keine Sorge, deine Investition ist nicht verloren! Wenn wir beim Audit noch Tracking-Reste oder unsaubere Datenströme finden, erhältst du von uns einen präzisen Fehlerbericht. Wir lassen dich nicht im Regen stehen, sondern zeigen dir exakt, wo es im Code klemmt.

Unsere Fairness-Garantie: Du hast anschließend Zeit, die identifizierten Lücken in Ruhe zu schließen. Sobald du das System abgedichtet hast, führen wir eine kostenlose Nachprüfung durch.