Oft gestellte Fragen – nachvollziehbar beantwortet.

Treelogy beobachtet öffentlich erreichbare Websites technisch und passiv: Quelltext, DOM, Browsernetzwerk, Cookies, Storage, Consent, Formulare, Sicherheitsheader, Rechtstexte und technische Signale. Daraus entstehen strukturierte Befunde mit Quellen und Prioritäten.

Zusätzlich werden Weiterleitungen, externe Dienste, Rechtstextpfade, erkannte Systeme und Sonderbereiche wie Bewerbungs- oder Karriereportale getrennt betrachtet. So bleibt sichtbar, was tatsächlich beobachtet wurde, was nur aus dem Quelltext stammt und wo eine manuelle Prüfung erforderlich ist.

Nein. Der Standardlauf ist eine passive Browser- und Quelltextanalyse. Er ersetzt weder einen vollständigen Penetrationstest noch eine serverseitige Sicherheitsprüfung oder Rechtsberatung.

Erfasst wird der normale, freigegebene Seitenablauf mit Chromium. Ein aktiver Sicherheits- oder Belastungstest braucht einen eigenen Auftrag, ein abgestimmtes Ziel, klare Grenzen und eine dokumentierte Freigabe durch die verantwortliche Stelle.

Nicht beauftragt und nicht Bestandteil des Standardlaufs sind Fuzzing, Portscans, Brute Force, unberechtigte Zugriffe, Formularübermittlungen und offensive Tests. Aktive Tests werden nur ausdrücklich beauftragt und vorher abgegrenzt.

Auch das Umgehen von Zugangsschutz, das Ausprobieren fremder Zugangsdaten oder das Verändern von Daten gehört nicht zur passiven Prüfung. Nicht erreichbare Bereiche werden als Abdeckungslücke dokumentiert und nicht durch riskante Aktionen ersetzt.

Für Website-Betreiber, Datenschutzbeauftragte, Kanzleien, Agenturen, IT-Teams und Unternehmen, die eine technische und nachvollziehbare Ausgangslage für weitere Entscheidungen benötigen.

Die Ergebnisse können als gemeinsamer Ausgangspunkt für Datenschutz, Technik, Redaktion und Management dienen. Je nach Bedarf lässt sich die Prüfung lokal, als Server-Version oder als White-Label-Lösung in vorhandene Agentur- und Kundenprozesse einbinden.

Passwörter, Tokens und andere Secrets werden im Report redigiert. Es werden höchstens die ersten drei Zeichen und danach *** angezeigt. Der vollständige Wert wird nicht in den Bericht übernommen.

Zusätzlich werden Fundstelle, Secret-Kategorie und technischer Kontext beschrieben, ohne das Geheimnis offenzulegen. Ein möglicher Treffer ist immer durch den Betreiber zu verifizieren; betroffene Zugangsdaten sollten kontrolliert und gegebenenfalls nach einem abgestimmten Verfahren rotiert werden.

Nein, nicht vollständig. Dokumentiert werden Secret-Typ, Fundstelle, technischer Kontext und ein redigierter Wert. Betreiber sollten betroffene Zugangsdaten unabhängig davon serverseitig prüfen und gegebenenfalls rotieren.

Auch URL-Parameter, Inline-Konfigurationen, localStorage und JavaScript-Bundles werden unter diesem Gesichtspunkt betrachtet. Die technische Dokumentation soll eine sichere Nachprüfung ermöglichen, aber keine missbrauchsfähige Kopie eines Schlüssels oder Tokens erzeugen.

Verglichen werden beobachtbare Zustände vor und nach Consent, Requests, Cookies, Storage, Skripte, Anbieter und Interaktionen, soweit der Browserlauf sie verifizieren kann. Nicht bestätigte Aktionen werden als solche ausgewiesen.

Der Abgleich unterscheidet beispielsweise notwendige Speicherungen, Statistik, Marketing und externe Medien, sofern diese Signale technisch erkennbar sind. Ob eine konkrete Einwilligung wirksam ist, hängt zusätzlich von Konfiguration, Information, Zweck und rechtlicher Bewertung ab.

Nein. Cookie-Freiheit beantwortet weder die Rechtsgrundlage noch Informations- oder Einwilligungsfragen. Der Report weist beobachtete technische Signale aus; die rechtliche Bewertung bleibt eine Einzelfallprüfung.

Auch Fingerprinting, URL-Kennungen, Session-IDs, Pixel oder serverseitige Messungen können für die Einordnung relevant sein. Deshalb wird nicht nur nach Cookie-Namen gesucht, sondern der beobachtete Datenfluss im jeweiligen Prüfzustand betrachtet.

Nein. Der Report ist eine technische Arbeitsgrundlage. DSB, Kanzlei oder verantwortliche Fachpersonen bewerten Rechtsgrundlage, Erforderlichkeit, Interessenabwägung und weitere rechtliche Fragen.

Er trennt deshalb Beobachtung, technische Bewertung und rechtliche Einordnung. Hinweise wie „nicht ermittelt“, „nicht verifiziert“ oder „manuell prüfen“ markieren Grenzen der automatischen Abdeckung und sind keine pauschale rechtliche Schlussfolgerung.

KI kann begrenzt bei Klassifizierung und lokalem Data Enrichment unterstützen, etwa bei Varianten, Begriffen und technischen Mustern. Primärbelege, Quellenabgleich und menschliche Einordnung bleiben maßgeblich. Eine KI entscheidet nicht selbst, ob ein Rechtsverstoß vorliegt.

Die Beweiskette wird nicht durch eine unprüfbare Modellentscheidung ersetzt: Quelle, Browserbeobachtung, Evidence und Report müssen unabhängig nachvollziehbar bleiben. KI-Vorschläge werden daher als Unterstützung behandelt und vor der Freigabe gegen technische Daten und Regeln geprüft.

Je nach Profil können redigierte HAR-Daten, Screenshots, Evidence-IDs, ein SHA-256-Manifest, Version, Zeitstempelstatus und eine technische Zusammenfassung enthalten sein. Die Belege werden dem Prüfzeitpunkt und konkreten Befunden zugeordnet.

Ein Verschlüsselungshinweis, die verwendete Chromium-Version, Exportstatus und Dateiintegrität können ergänzend dokumentiert werden. Geheimnisse und unnötige personenbezogene Inhalte werden vor der Ausgabe reduziert oder redigiert.

Es gibt eine kostenlose Vorschau sowie Kompakt- und Vollberichte mit unterschiedlicher Detailtiefe. Der Vollbericht kann zusätzlich ein strukturiertes ZIP-Beweispaket enthalten.

Die Profile unterscheiden sich vor allem bei Umfang, Befundtiefe, Belegen und Dokumentation. Die Vorschau dient der Orientierung; ein Vollbericht führt technische Zusammenhänge, Prioritäten, Abgleiche und nächste Schritte ausführlicher zusammen.

Der Prüfauftrag und die Vorschau können kostenlos sein. Freigabepflichtige Profile werden über den im Auftrag angebotenen Zahlungsweg, zum Beispiel PayPal, bezahlt. Der Umfang wird vor der Freigabe angezeigt.

Die Zahlungsabwicklung und die technische Prüfung werden getrennt betrachtet. Nach einer erfolgreichen Freigabe wird der vereinbarte Reportumfang bereitgestellt; Zahlungsdaten werden nicht als Bestandteil der Website-Evidence ausgewertet.

Kosten entstehen nur für ein ausdrücklich gewähltes kostenpflichtiges Reportprofil. Preis, Profil und Leistungsumfang werden vor der Zahlung verständlich angezeigt.

Die kostenlose Vorschau soll eine Entscheidung über die weitere Prüfung ermöglichen. Individuelle aktive Tests, zusätzliche Pfade oder besondere Auswertungen werden nur nach vorheriger Abstimmung und mit transparentem Umfang berücksichtigt.

Ja. Die Anwendung kann lokal, serverseitig oder als abgestimmte Kombination betrieben werden. Für Agenturen ist eine White-Label-Lösung mit eigenen Abläufen und Kundenauftritten möglich.

Eine lokale Installation kann sensible Arbeitsdaten und interne Prüfprozesse in der eigenen Umgebung halten. Eine optionale Synchronisation wird bewusst konfiguriert und setzt eine definierte Freigabe, Authentisierung und Datenzuordnung voraus.

Prüfzugriff, API, Datenbank und Evidence-Ablage werden logisch getrennt. Reports und Belege werden geschützt gespeichert. Geheimnisse werden redigiert und lokale KI wird nicht ungeprüft mit Daten versorgt.

Zusätzlich werden Berechtigungen, Freigabestatus, Versionen und Belegbeziehungen getrennt behandelt. Die konkrete Absicherung hängt von Installation, Serverbetrieb, Schlüsselverwaltung und den jeweils vereinbarten organisatorischen Maßnahmen ab.

Ja. Bitte bei einer Anfrage die Fallreferenz und, sofern vorhanden, die betroffene URL angeben. Senden Sie keine unnötigen personenbezogenen oder geheimen Inhalte mit.

Bei Rückfragen hilft die Fallreferenz, den richtigen Auftrag, Status und Freigabekontext zuzuordnen. Lösch- und Auskunftsanfragen werden getrennt von fachlichen Korrekturen behandelt, damit die Evidence-Historie nicht unbeabsichtigt verändert wird.

Geschützte Marken, Logos und Kennzeichen können als technische Dokumentation des beobachteten Zustands erscheinen. Daraus entsteht keine Markenlizenz und keine Zustimmung zu einer Nutzung außerhalb des Prüfkontexts.

Abbildungen, Screenshots und Seitentitel werden nur im Zusammenhang mit dem geprüften technischen Zustand verwendet. Der Report beansprucht weder eine geschäftliche Verbindung noch Rechte an den dargestellten Inhalten Dritter.

Erkennungshinweise können unter anderem Drupal, TYPO3, Magento, Salesforce, Odoo, Sitecore, Optimizely, Liferay, Magnolia und Pimcore betreffen. Eine Erkennung bleibt ein technisches Signal und wird mit Confidence und Quellen ausgewiesen.

Zusätzlich können Frontend-Bibliotheken, Shop- und Portalstrukturen, Analytics- oder Consent-Plattformen sowie typische Pfade und Header berücksichtigt werden. Wenn mehrere Signale widersprüchlich sind, bleibt die Klassifikation entsprechend vorsichtig und wird nicht als sichere Herstellerangabe ausgegeben.

Karriere-, Bewerbungs- und externe Portalseiten können als eigener Prüfgegenstand dokumentiert werden. Verantwortliche, Portalbetreiber, Weiterleitungen und eingebettete Inhalte werden getrennt betrachtet.

Auch eingebundene Recruiting-Dienste, Tracking, Formulare, Datenschutzlinks und ein abweichendes Impressum können eigene Befunde erzeugen. Ein Bewerberportal wird nicht automatisch der Hauptdomain zugerechnet, wenn die technische Verantwortung oder der Datenfluss erkennbar abweicht.

Angeforderte URL, Weiterleitungskette und Zielseite werden getrennt dokumentiert. Eine Weiterleitung ersetzt nicht automatisch das ursprüngliche Prüfziel.

So bleibt nachvollziehbar, ob beispielsweise eine Länder-, Karriere-, Shop- oder Portaladresse auf ein anderes System führt. Bei Fehlern, WAF-Challenges oder nicht erreichbaren Zielen wird die tatsächlich beobachtete Abdeckung ausdrücklich vom nicht geprüften Ziel unterschieden.

Öffentliche Kontaktdaten werden aus Rechtstexten und belastbaren Behördenquellen extrahiert. Namen, Rollen, Anschriften und Zuständigkeiten werden quellengebunden abgeglichen. Unsichere Zuordnungen werden als manuell zu prüfen markiert.

Für Behörden können Ort, PLZ, Bundesland, Leitung, Anschrift, E-Mail, offizielle Website und ein Beschwerdeweg getrennt erfasst werden. Die Zuordnung bleibt eine Orientierung und hängt zusätzlich von verantwortlicher Stelle, Tätigkeitsbereich und aktueller offizieller Quelle ab.

Ja, technische SEO- und Accessibility-Signale können ergänzend geprüft werden. Das ist keine vollständige SEO-Beratung und kein rechtliches WCAG-Konformitätszertifikat.

Betrachtet werden können beispielsweise Titel, Description, Canonical, strukturierte Daten, Überschriften, Alt-Texte, Tastaturzugänglichkeit, Kontraste und mobile Auffälligkeiten. Automatisch erkannte Hinweise sollten anschließend mit realen Nutzungsszenarien und Fachprüfung validiert werden.

Der Status beschreibt, ob ein qualifizierter Zeitstempel technisch angehängt und verifiziert wurde. NOT_ATTACHED bedeutet „Nicht angehängt“ und ist keine eIDAS-Bestätigung.

Auch Scanzeit, Rechtstexte-Abgleich, Manifest und verwendete Version können getrennt ausgewiesen werden. Ein technischer Zeitpunkt dokumentiert den Abruf und Export, bestätigt aber nicht automatisch die rechtliche Aktualität eines Dokuments.

Aktive Tests finden ausschließlich auf ausdrücklichen Auftrag mit abgestimmtem Ziel, Datenraum, Umfang und Freigabe statt. Sie sind kein Teil des passiven Standardlaufs und werden individuell dokumentiert.

Je nach Bedarf können CMS, Frontend, Backend, SAP, APIs oder definierte blinde Vektoren im Prüfplan berücksichtigt werden. Voraussetzung sind eine klare Autorisierung, ein verantwortlicher Kontakt und ein Verfahren, das Betrieb und Beweiskette schützt.

Ausgangspunkt ist die beauftragte URL mit ihren erreichbaren Weiterleitungen und technisch sichtbaren Unterseiten. Rechtstexte, Impressum, Datenschutz, Kontakt, Login-, Karriere- oder Portalpfade können als relevante Sonderbereiche ergänzt werden.

Eine vollständige Website-Inventur ist damit nicht automatisch verbunden. Der Report weist aus, welche URLs tatsächlich aufgerufen, welche Links gefunden und welche Bereiche nicht erreichbar oder nicht Bestandteil des Prüfplans waren.

Je nach erreichbarer Antwort werden unter anderem Content-Security-Policy, HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy und Permissions-Policy erfasst. Die Werte werden als technische Konfiguration und nicht als pauschales Sicherheitsurteil dokumentiert.

Fehlende Header können Härtungsbedarf anzeigen, sind aber nicht automatisch ein DSGVO-Verstoß. Entscheidend sind Schutzbedarf, Bedrohungsmodell, tatsächliche Verarbeitung und die Gesamtheit der technischen und organisatorischen Maßnahmen.

Eine WAF- oder Bot-Challenge kann verhindern, dass der normale Seiteninhalt, Banner oder Rechtstext vollständig geladen wird. Der Report kennzeichnet dann die technische Abdeckung und trennt sie von Aussagen über Inhalte, die nicht beobachtet werden konnten.

Eine Challenge wird nicht umgangen. Stattdessen können Status, sichtbare Antwort, Weiterleitungen, Header und erreichbare Evidence dokumentiert werden. Für eine belastbare Ergänzung ist gegebenenfalls ein freigegebener Prüfpfad oder ein anderer Testzeitpunkt erforderlich.

Der Browserlauf kann einen frischen Zustand, die sichtbare CMP-Oberfläche und definierte Interaktionen dokumentieren. Vorher- und Nachher-Zustände werden anhand von Requests, Cookies, Storage und Skripten verglichen, soweit diese Signale zugänglich sind.

Wenn Schaltflächen nicht reagieren, nur in bestimmten Regionen erscheinen oder ein Banner fehlt, wird das als Beobachtung mit Einschränkung erfasst. Ein einzelner Lauf ist kein Beweis für alle Endgeräte, Regionen oder späteren Konfigurationen.

Ein US- oder Drittlandsignal kann sich aus einem Anbieter, Hostnamen, Dienst oder einer gepflegten Anbieter-Registry ergeben. Es beschreibt zunächst eine technische Jurisdiktions- oder Anbieterindikation und bestätigt allein noch keinen konkreten Empfänger, Inhalt oder Transfer.

Der Report unterscheidet deshalb zwischen beobachtetem Request, Anbieterhinweis, tatsächlichem Empfängerland, Payload und dokumentiertem Transfermechanismus. Die rechtliche Bewertung und die Prüfung geeigneter Garantien bleiben bei den Verantwortlichen und ihren Fachpartnern.

Erkannte Datenschutzlinks werden aufgelöst und, soweit technisch möglich, als HTML- oder PDF-Dokument extrahiert. Sichtbarer DOM-Inhalt und Quelltext können getrennt erfasst werden, damit dynamische Rechtstexte nicht mit einer leeren Quelltextansicht verwechselt werden.

Der Abgleich kann genannte Anbieter, Zwecke, Rechtsgrundlagen, DSB-Kontakte, Drittlandhinweise und Aktualisierungsangaben mit Browserbeobachtungen vergleichen. „Nicht extrahierbar“ bedeutet eine technische Abdeckungslücke und nicht automatisch, dass ein Rechtstext fehlt.

Das Impressum wird auf erkennbare Verantwortliche, Anschrift, Kontakt, Register- und Vertretungsangaben sowie verlinkte Sonderseiten geprüft. Die Angaben können mit Zielhost, Weiterleitungen und Datenschutzkontakten technisch abgeglichen werden.

Ein abweichender Portalbetreiber, eine veraltete Adresse oder ein externer Bewerbungsdienst wird als Abweichung dokumentiert. Ob die Anbieterkennzeichnung rechtlich ausreichend ist, muss eine zuständige Fachperson bewerten.

Gefundene Datenschutzbeauftragte oder Datenschutzstellen werden mit Name, Organisation, Anschrift, Telefon, E-Mail und Quelle erfasst, wenn diese Angaben im zugänglichen Rechtstext belastbar vorhanden sind. Bekannte Kontakte können zusätzlich gegen gepflegte Referenzdaten geprüft werden.

Eine nicht erkannte Person ist nicht automatisch nicht vorhanden. Dynamische Inhalte, PDFs, Bilder, abweichende Schreibweisen und externe Datenschutzseiten können die Extraktion begrenzen; solche Fälle werden für die manuelle Nachprüfung kenntlich gemacht.

Screenshots zeigen sichtbare Zustände wie Banner, Formulare, Weiterleitungen und Rechtstextbereiche. HAR-Daten können Requests, Statuscodes, Header und Zeitbezüge dokumentieren, sofern sie im jeweiligen Lauf aufgezeichnet wurden.

Beide Artefakttypen werden mit Evidence-IDs und dem Prüfkontext verknüpft. HAR-Inhalte werden vor Ausgabe redigiert; ein Beleg zeigt den beobachteten Zeitpunkt und Ausschnitt, nicht automatisch jede serverseitige Verarbeitung.

Prioritäten berücksichtigen technische Signalstärke, mögliche Auswirkung, Betroffenheit, Wiederholbarkeit, Abdeckung und Belegqualität. Abwesenheiten und nicht assessierbare Punkte werden nicht künstlich als Risikopunkte behandelt.

Die Priorität ist eine strukturierte Arbeitsreihenfolge und kein rechtsverbindliches Urteil. Reportkopf, Befundkarten, Zählwerte, Score und Status werden vor dem Export auf Konsistenz geprüft.

„Teilweise“ weist darauf hin, dass nur ein Teil des Prüfpfads, der Interaktionen oder der technischen Signale verifiziert werden konnte. Ursachen können Challenge-Seiten, fehlende Antworten, dynamische Komponenten oder ausdrücklich begrenzte Abdeckung sein.

Der Status soll die Aussagekraft korrekt begrenzen und nicht durch eine scheinbar vollständige Klassifikation ersetzen. Nach einem erneuten Lauf mit besserer Erreichbarkeit kann sich der Status ändern.

Ja, erkennbare Shop-, Portal- und Frontend-Signale können ergänzend zur CMS-Klassifikation erfasst werden. Dazu zählen beispielsweise Magento, Salesforce Commerce Cloud, Odoo, Bewerbungsplattformen, Analytics- und Consent-Systeme.

Die Erkennung basiert auf mehreren technischen Indizien wie Skripten, Pfaden, Headern, Markup und bekannten Plattformmerkmalen. Einzelne Bibliotheken reichen nicht immer für eine sichere Aussage; widersprüchliche Signale werden entsprechend vorsichtig bewertet.

Ein Accessibility-Hinweis kann fehlende Alternativtexte, Kontrastprobleme, unklare Fokusführung, problematische Formulare, unpassende Überschriften oder mobile Überläufe betreffen. Er beschreibt ein technisches Prüfsignal, nicht automatisch eine vollständige WCAG-Verletzung.

Die Ergebnisse sollten mit Tastatur, Screenreader, verschiedenen Viewports und realen Nutzungsszenarien nachgeprüft werden. So lassen sich automatisch sichtbare Hinweise priorisieren und mit konkreten Verbesserungsmaßnahmen verbinden.

Technische SEO-Signale können Titel, Description, Canonical, Robots-Anweisungen, strukturierte Daten, Überschriften, Indexierbarkeit, interne Links, Sprachangaben und Vorschau-Metadaten umfassen. Sie werden auf der erreichbaren Zielseite und im beobachteten DOM erfasst.

Der Report ersetzt keine Inhaltsstrategie oder Suchmaschinenberatung. Er macht technische Auffälligkeiten sichtbar, damit Redaktion, Entwicklung und SEO-Verantwortliche die Ursachen gemeinsam bewerten können.

Externe Links, neue Fenster, Zielhosts und erkennbare Rel-Attribute können als technische Hinweise erfasst werden. Dazu gehören auch fehlende Schutzattribute wie noopener oder unklare Weiterleitungen, sofern sie im geprüften Markup sichtbar sind.

Ein solcher Hinweis ist zunächst eine Härtungs- oder Qualitätsbeobachtung. Kontext, Browserverhalten, Vertrauensbeziehung und Zielseite entscheiden darüber, welche Maßnahme tatsächlich sinnvoll ist.

Ja, Cookies, localStorage, sessionStorage und sichtbare Formularzustände können im Browserlauf erfasst werden. Besondere Aufmerksamkeit gilt dauerhaft gespeicherten Zugangsdaten, Tokens, Nutzerkennungen oder personenbezogenen Werten.

Der Standardlauf füllt keine fremden Formulare mit echten Daten aus und führt keine Anmeldung ohne Freigabe durch. Sichtbare Feldtypen, Autocomplete-Einstellungen und clientseitige Speicherung können dennoch als technische Signale dokumentiert werden.

Öffentlich ausgelieferte Skripte und Inline-Konfigurationen können auf Secret-Muster, URLs, E-Mail-Adressen, interne Hosts, Debug-Ausgaben und riskante HTML-Ausgaben geprüft werden. Dabei werden nur erreichbare Dateien und Inhalte des freigegebenen Prüfpfads betrachtet.

Treffer werden kontextbezogen bewertet, weil Platzhalter, Testwerte, öffentliche IDs und echte Geheimnisse unterschiedlich zu behandeln sind. Die Ausgabe redigiert sensible Werte und empfiehlt eine manuelle Verifikation beziehungsweise Rotation.

Erkannte Bibliotheken und Versionen werden aus HTML, Skript-URLs, Kommentaren oder charakteristischen Signalen abgeleitet. Veraltete jQuery-, Handlebars-, Video- oder Plugin-Versionen können als Wartungs- und Sicherheitsrisiko markiert werden.

Die konkrete Ausnutzbarkeit hängt von Nutzung, Konfiguration, Exposition und bekannten Schwachstellen ab. Der Report nennt deshalb Version und Kontext und trennt den technischen Updatebedarf von einer Behauptung über eine tatsächlich ausgenutzte Lücke.

Ja, Hauptdomain, Portalbetreiber, Dienstleister, Agentur und genannte Verantwortliche können getrennt erfasst werden, wenn die Quellen diese Unterscheidung tragen. Weiterleitungen und externe Bewerbungs-, Shop- oder Formularsysteme werden nicht automatisch zu einer einzigen Organisation verschmolzen.

Abweichende Anschriften, Marken, E-Mail-Domains und Rechtstexte können eine Klärung auslösen. Die endgültige Verantwortlichkeits- und Rollenbewertung bleibt eine organisatorische und rechtliche Aufgabe.

Die Suche ordnet Ort oder PLZ einer öffentlich gepflegten Datenschutzaufsicht zu und zeigt, sofern vorhanden, Website, Anschrift, Leitung, E-Mail und Beschwerdeweg. Die Datenbank wird mit einem ausgewiesenen Datenstand und Aktualisierungszeitpunkt versehen.

Die Suche ist eine Orientierung und keine automatische Einzelfallentscheidung. Zuständigkeit kann zusätzlich von Verantwortlicher, Branche, öffentlicher Stelle und Tätigkeitsbereich abhängen; bei Unsicherheit sollte die offizielle Behörde direkt kontaktiert werden.

Ein Rechtstexte-Abgleich findet im Prüf-Lauf für die erreichbaren Dokumente und Links statt. Zusätzlich können Referenzdaten und Behördeninformationen regelmäßig aktualisiert werden, wobei Datenstand und technischer Abrufzeitpunkt getrennt ausgewiesen werden.

Eine automatische Aktualisierung bestätigt nicht, dass ein Text rechtlich aktuell oder vollständig ist. Für laufende Überwachung, Änderungen und Freigaben können abgestimmte wiederkehrende Prüfungen eingerichtet werden.

Ja, Agenturen können eine angepasste lokale oder serverseitige Lösung in bestehende Kundenprozesse integrieren. Branding, Rollen, Reportprofile, Freigaben, Datenhaltung und Schnittstellen werden nach dem vereinbarten Einsatzmodell abgestimmt.

Die technische Basis bleibt dabei nachvollziehbar: Prüfpfad, Evidence, Version, Status und Verantwortlichkeiten müssen auch im eigenen Auftritt sichtbar und reproduzierbar bleiben. Ein White Label verändert nicht die Anforderungen an Schutz und Dokumentation.

Report, Exportpipeline, Prüfschema, Evidence-IDs und technische Laufdaten werden einer Version beziehungsweise Fallreferenz zugeordnet. Dadurch kann nachvollzogen werden, mit welcher Regel- und Softwarebasis ein Ergebnis entstanden ist.

Nachträgliche Korrekturen sollten als neue Fassung oder klar dokumentierte Anpassung erkennbar bleiben. So werden aktuelle Darstellung, ursprüngliche Beobachtung und fachliche Einordnung nicht unbemerkt vermischt.

Zuerst betroffene Zugänge und Systeme kontrollieren, weitere Abflüsse begrenzen und Beweise wie Zeitpunkte, Logs, Screenshots und Nachrichten unverändert sichern. Danach sollten verantwortliche Stelle, IT-Sicherheit und Datenschutzbeauftragte einbezogen werden.

Zu prüfen sind insbesondere Risiko, Datenarten, betroffene Personen, Empfänger und die Melde- beziehungsweise Informationspflichten nach Art. 33 und 34 DSGVO. Eine Zahlung, Löschung oder Änderung von Systemen sollte nicht unkoordiniert erfolgen.

Für einen Standardlauf genügen die freigegebene Ziel-URL und die gewünschten Kontaktdaten. Bei Sonderpfaden, Portalen, lokalen Installationen oder aktiven Zusatzmodulen sollten Ziel, Umfang, Ansprechpartner und gewünschte Ausgaben vorab beschrieben werden.

Bei Rückfragen zu einem bestehenden Auftrag helfen Fallreferenz und betroffene URL. Bitte senden Sie keine unnötigen Passwörter, Tokens oder anderen geheimen Inhalte; technische Nachweise werden kontrolliert und redigiert behandelt.

Der Quelltext zeigt die vom Server gelieferte Ausgangsbasis. Der DOM zeigt den Zustand, den der Browser nach Skriptausführung und dynamischen Änderungen tatsächlich aufgebaut hat.

Beide Sichten können voneinander abweichen. Treelogy dokumentiert deshalb, ob ein Signal nur im HTML, im sichtbaren DOM oder in beiden Ebenen erkannt wurde.

Eine dynamische Website kann Rechtstexte, Banner, Skripte oder Formulare erst nach dem Laden erzeugen. Eine reine HTML-Suche würde solche Inhalte übersehen oder einen leeren Ausgangszustand falsch interpretieren.

Der getrennte Vergleich macht sichtbar, ob ein Befund aus dem ausgelieferten Quelltext stammt oder erst durch Browserlogik entsteht. Das verbessert die Nachvollziehbarkeit und die Auswahl der passenden Evidence.

Prüfdeckung beschreibt, welche URL, Interaktionen, Zustände, Dokumente und technischen Signale im konkreten Lauf tatsächlich erreichbar und beobachtbar waren. Sie ist ein wichtiger Teil der Aussagegrenze.

Eine hohe Prüfdeckung bedeutet nicht automatisch, dass jede serverseitige Verarbeitung bekannt ist. Nicht erreichbare oder nicht freigegebene Bereiche werden getrennt ausgewiesen, statt sie stillschweigend zu ergänzen.

Die Scanzeit bezeichnet den technischen Browser- und Exportlauf. Der Datenstand beschreibt, wann eine Referenzquelle, Behördenliste oder Kataloginformation zuletzt aktualisiert wurde.

Beide Zeitpunkte können auseinanderliegen und werden deshalb getrennt angezeigt. Ein Datenstand ersetzt nicht den Nachweis, dass eine Website zum Scanzeitpunkt unverändert oder rechtlich aktuell war.

Canonical-, hreflang- und alternative Sprachlinks können aus HTML und DOM erfasst werden. Dabei wird geprüft, auf welche Zieladresse sie zeigen und ob sie zur geprüften URL passen.

Abweichungen können SEO- oder Wartungshinweise sein, sind aber nicht automatisch ein Datenschutzproblem. Weiterleitungen, Sprachvarianten und Shop-Storeviews werden im technischen Kontext getrennt betrachtet.

Ja, sichtbare Bilder und informative Grafiken können auf vorhandene, leere oder fehlende Alternativtexte geprüft werden. Das betrifft auch Vorschaukarten, Logos und verlinkte Bilder.

Die automatische Prüfung kann die Bedeutung eines Bildes nicht vollständig beurteilen. Deshalb sollte die Redaktion ergänzend prüfen, ob der Alternativtext den Zweck des Bildes verständlich beschreibt.

Mobile Viewports können auf horizontale Überläufe, abgeschnittene Inhalte, zu breite Buttons, überlappende Icons und unpassende Abstände geprüft werden. Screenshots und DOM-Messungen unterstützen die Zuordnung.

Ein einzelner Viewport ist nur eine Stichprobe. Für eine belastbare Korrektur sollten unterschiedliche Gerätebreiten, Zoomstufen, Schriftgrößen und Eingabemethoden zusätzlich getestet werden.

Geprüft werden können Fokusreihenfolge, sichtbarer Fokus, erreichbare Menüs, Dialoge, Akkordeons und Formulare. Auch problematische Klickziele oder ausschließlich mausabhängige Interaktionen können auffallen.

Die Prüfung ersetzt keinen vollständigen assistiven Nutzungstest. Sie zeigt technische Ansatzpunkte, die anschließend mit Tastatur und gegebenenfalls Screenreader reproduziert werden sollten.

Kontrastwerte, sehr helle Texte, farbabhängige Statusanzeigen und schlecht erkennbare Fokuszustände können als Accessibility-Signale erfasst werden. Dabei werden sichtbare Zustände und CSS-Merkmale berücksichtigt.

Automatische Kontrastwerte können durch Schriftgröße, Gewicht, Hintergrundbilder und Zustandswechsel begrenzt sein. Eine manuelle Prüfung mit realen Komponenten bleibt deshalb sinnvoll.

Formulare können auf Methode, Ziel, sichtbare Labels, Eingabetypen, Autocomplete, Pflichtfelder, externe Ziele und erkennbare Schutzmechanismen geprüft werden. Der Standardlauf sendet keine echten personenbezogenen Inhalte.

Ein fehlendes CSRF-Signal ist bei einer reinen Suchfunktion anders zu bewerten als bei einer schreibenden Aktion. Der Bericht ordnet Formularbefunde deshalb nach Kontext und beobachteter Funktion ein.

Consent-Manager können über sichtbare Banner, Skripte, lokale Speicher, globale Variablen, Netzwerkaufrufe und typische Anbietermerkmale erkannt werden. Dazu zählen beispielsweise Usercentrics, Cookiebot oder andere CMPs.

Die Erkennung des Anbieters sagt noch nicht, ob die Konfiguration korrekt ist. Entscheidend sind sichtbare Optionen, Default-Zustand, tatsächliche Requests und die Verbindung zur Datenschutzerklärung.

Diese Formulierung bedeutet, dass im konkreten Lauf kein entsprechender Request vor dem beobachteten Einwilligungszeitpunkt festgestellt wurde. Sie ist eine Aussage über diesen Lauf und dessen Abdeckung.

Sie bestätigt nicht automatisch eine vollständige rechtliche Compliance. Andere Pfade, Geräte, Regionen, serverseitige Prozesse oder spätere Interaktionen können separat bewertet werden müssen.

Technisch notwendige Cookies können etwa Session, Warenkorb, Sprache, Sicherheit oder Consent-Zustand unterstützen. Ihre konkrete Einordnung hängt von Funktion, Lebensdauer, Anbieter und Verarbeitung ab.

Ein Cookie-Name allein reicht nicht für eine rechtliche Bewertung. Treelogy dokumentiert beobachtete Namen, Attribute, Zeitpunkt und Kontext und trennt technische Beschreibung von der rechtlichen Einordnung.

Mehrere Requests desselben Anbieters oder Dienstes können für die Übersicht zusammengeführt werden, damit der Bericht nicht durch wiederholte Einträge unleserlich wird. Die Einzel-Evidence bleibt dabei referenzierbar.

Zusammenfassungen zeigen Anzahl und Muster, ersetzen aber nicht die genaue Request-Evidenz. Unterschiedliche Zwecke, Hosts oder Einwilligungszustände werden getrennt dargestellt, wenn sie relevant sind.

Öffentliche Kontaktadressen, Testadressen und möglicherweise interne Adressen können in Skripten, Kommentaren oder Konfigurationen vorkommen. Sie werden nach Fundstelle, Kontext und möglicher Sensibilität unterschieden.

Eine E-Mail-Adresse ist nicht automatisch ein Geheimnis. Der Report sollte jedoch interne Testkontakte, personenbezogene Daten und klar erkennbare Zugangskonfigurationen nicht unnötig vollständig wiedergeben.

Interne Hostnamen, Entwicklungsumgebungen, SAP-Systeme, private IPs oder technische Pfade können in JavaScript, Quelltext, Headern oder Fehlermeldungen sichtbar werden. Sie geben Hinweise auf die Infrastruktur und sollten kontextbezogen bewertet werden.

Ein sichtbarer Hostname beweist keinen externen Zugriff. Er kann aber Information Disclosure oder unnötige Produktionsreste anzeigen und sollte geprüft werden.

Eine fehlende oder sehr permissive Content-Security-Policy begrenzt die Browserhärtung gegen bestimmte Script-, Objekt- oder Verbindungsrisiken. Report-Only ist nicht dasselbe wie eine durchsetzende Policy.

Die konkrete Wirksamkeit hängt von Code, Drittanbietern, Nonces, Hashes und Deployment ab. Ein CSP-Hinweis ist ein technischer Härtungspunkt und nicht automatisch ein Nachweis für einen erfolgreichen Angriff.

HSTS weist Browser an, eine Domain für einen Zeitraum nur über HTTPS aufzurufen. Das kann Downgrade- und unbeabsichtigte HTTP-Verbindungen reduzieren, wenn Domain und Subdomains korrekt konfiguriert sind.

HSTS allein schützt nicht vor allen Webangriffen und ersetzt weder sichere Cookies noch eine passende CSP oder Serverkonfiguration.

CORS steuert, welche Browserursprünge Antworten lesen dürfen. Wildcards, reflektierte Origins oder unpassende Credentials-Konfigurationen können bei sensiblen APIs ein Härtungssignal sein.

Ein CORS-Header auf einer öffentlichen Ressource ist nicht automatisch gefährlich. Entscheidend sind Authentisierung, Antwortinhalt, Methoden, Credentials und die Frage, ob ein fremder Ursprung sensible Daten lesen kann.

Externe Skriptquellen, Versionen, Integritätsattribute, Anbieter und Ladebedingungen können erfasst werden. Dazu gehören auch doppelte Bibliotheken, unklare Versionen und dynamische Nachladungen.

Fehlende Subresource Integrity ist ein Härtungshinweis, sofern externe Skripte eingesetzt werden. Eine sinnvolle Maßnahme kann ein eigener, gepflegter Build oder eine versionierte und mit SRI abgesicherte Quelle sein.

Shop-Signale können unter anderem Magento, Salesforce Commerce Cloud, Shopify, WooCommerce, Shopware und Odoo umfassen, sofern sichtbare Merkmale vorhanden sind. Auch Zahlungs-, Warenkorb-, Produkt- und Storeview-Strukturen können Hinweise liefern.

Die Erkennung bleibt abhängig von Theme, Proxy, Cache, WAF und Anpassungen. Ein System kann verborgen, falsch klassifiziert oder nur als wahrscheinliche Plattform ausgewiesen werden.

Bei individuellen oder headless Systemen werden API-Pfade, Frameworks, JSON-Strukturen, Build-Artefakte, Header, Komponenten und typische Routen als Indizien betrachtet. Eine eindeutige Herstellerangabe ist bei Eigenentwicklungen oft nicht möglich.

Der Bericht kann dann eine technische Kategorie wie „individuelle Plattform“ oder „nicht eindeutig erkannt“ ausweisen. Das ist genauer als eine überzogene Klassifikation aus nur einem Bibliotheksnamen.

Job- und Bewerbungsformulare können personenbezogene Daten, Uploads, Tracking und externe Portalverarbeitung verbinden. Erfasst werden sichtbare Ziele, Weiterleitungen, Rechtstexte, Anbieter und technische Formmerkmale ohne Einreichung echter Bewerberdaten.

Ein Bewerberportal sollte hinsichtlich Verantwortlicher, Auftragsverarbeitung, Speicherdauer und Kontaktwegen gesondert bewertet werden. Die Hauptwebsite und das Bewerbersystem dürfen nicht unbesehen als identischer Prüfgegenstand behandelt werden.

iFrames können als eigener technischer Kontext mit Quelle, Zielhost, Größe, Sandbox-Attributen und sichtbarem Inhalt dokumentiert werden. Besonders relevant sind externe Formulare, Videos, Karriereportale und Zahlungs- oder Buchungsstrecken.

Ein iFrame ist nicht automatisch unsicher oder datenschutzwidrig. Maßgeblich sind Anbieter, Datenfluss, Einwilligungszustand, Berechtigungen, eingebettete Rechtstexte und die tatsächliche Interaktion.

Verlinkte PDFs können als Dokumentquelle erfasst und, wenn technisch möglich, textlich extrahiert werden. URL, Titel, Dateityp, Abrufzeitpunkt und erkannte Textabschnitte können dem Rechtstexte-Abgleich dienen.

Scan, OCR, verschlüsselte PDFs, alte Layouts oder fehlerhafte Fonts können die Extraktion begrenzen. In solchen Fällen wird die technische Lücke ausgewiesen und keine Vollständigkeit behauptet.

Widersprüche zwischen sichtbarer Seite, Datenschutz, Impressum, Cookie-Hinweisen und beobachteten Diensten können als Konsistenzhinweis markiert werden. Beispiele sind ein genannter Anbieter ohne beobachteten Einsatz oder ein beobachteter Dienst ohne erkennbare Information.

Die automatische Prüfung ersetzt keine juristische Auslegung. Sie macht die konkrete Stelle, Quelle und Abweichung auffindbar, damit Verantwortliche und Fachpartner den Text gezielt prüfen und korrigieren können.

Ort und PLZ sind Suchhilfen, aber nicht allein entscheidend. Verantwortliche Stelle, Tätigkeitsbereich, öffentliche oder private Organisation und besondere Zuständigkeitsregeln können die Zuordnung verändern.

Bei einer auffälligen Zuordnung sollte die offizielle Behördenquelle geprüft und die konkrete Stelle direkt kontaktiert werden. Korrekturen an der Referenzdatenbank sollten mit Quelle und Datenstand nachvollziehbar dokumentiert werden.

Wenn die offizielle Behörde einen Online-Beschwerde- oder Kontaktweg ausweist, kann dieser als direkter Link in der Behördenübersicht erscheinen. Der Link wird aus der gepflegten Quelle übernommen und nicht frei aus Suchergebnissen ergänzt.

Vor einer Übermittlung sollten Zuständigkeit, erforderliche Angaben, sichere Übertragung und die eigenen Nachweise geprüft werden. Treelogy bietet Orientierung und reicht keine Beschwerde an eine Behörde ein.

Evidence-IDs verbinden eine technische Beobachtung mit einem Artefakt wie Screenshot, Request, DOM-Ausschnitt, Header oder Dokument. Die genaue ID-Struktur hängt vom Prüf- und Exportmodell ab.

Wichtig ist die stabile Zuordnung: Ein Befund soll auf die passende Quelle zeigen, ohne dass der Report sensible Rohdaten unnötig vervielfältigt. Änderungen am Export müssen diese Verknüpfung erhalten.

Ein SHA-256-Manifest enthält Prüfsummen der Dateien im Beweispaket. Damit kann später festgestellt werden, ob eine Datei seit dem Export verändert wurde.

Die Prüfsumme beweist nicht allein die Wahrheit des Inhalts oder den Ursprung einer Website. Sie ergänzt Evidence, Exportzeitpunkt, Version, Zugriffsschutz und gegebenenfalls einen qualifizierten Zeitstempel.

„Nicht angehängt“ bedeutet, dass im konkreten Export kein qualifizierter Zeitstempel als Anlage vorlag oder verifiziert werden konnte. Daraus darf keine eIDAS-Bestätigung abgeleitet werden.

Scanzeit, Manifest und Exportstatus können trotzdem technisch dokumentiert sein. Für einen qualifizierten Nachweis ist ein dafür eingerichteter und überprüfter Zeitstempelprozess erforderlich.

Kopf, Verteilung, Score, To-do-Liste und Detailkarten greifen auf dieselbe Befundbasis zurück. Wenn sich Zählwerte unterscheiden, kann der Bericht Prioritäten oder Status falsch vermitteln.

Die Exportpipeline sollte deshalb vor der PDF-Erstellung auf Konsistenz prüfen. Nicht assessierbare Abwesenheiten dürfen keine Risikopunkte tragen, und neue Befunde müssen in Verteilung und relevanten Zählungen erscheinen.

Verglichen werden können Rohbefunde, Klassifikation, Priorität, Status, Seitenzahl, Kapitel, Links, Evidence-Referenzen und PDF-Layout. Der Abgleich prüft, ob eine Codeänderung alte Sonderfälle unbeabsichtigt verschlechtert.

Quelltext, Laufresultat und Report werden als Kette betrachtet. Bei Abweichungen wird zuerst die Ursache eingegrenzt, anschließend die Regel oder Darstellung angepasst und der Fall erneut reproduziert.

PDF-Exporte sollten auf Seitengröße, Schrift, Abstände, Überschneidungen, Farbhintergrund, Abschlussseite, Wasserzeichen, QR-Code, Tabellen und Seitenzahlen geprüft werden. Referenzberichte helfen, unbeabsichtigte Designregressionen zu erkennen.

Inhaltliche Korrekturen dürfen nicht automatisch Schriftgrößen oder Seitenaufbau zerstören. Deshalb gehören visuelle Prüfung und maschinelle Text-/Seitenkonsistenz gemeinsam in den Exporttest.

Die Abschlussseite bündelt Fallreferenz, Ziel, Status, Scanzeit, Rechtstexte-Abgleich, technische Grenzen, Kontakt und nächste Schritte. Sie rundet den Bericht ab und trennt technische Beobachtung von Rechtsberatung.

QR-Code, Logo, Hinweistext und Kontaktangaben werden so angeordnet, dass sie nicht mit dem letzten Inhalt, Rand oder Seitenfuß kollidieren. Die konkrete Seitenzahl wird erst nach dem finalen Export festgelegt.

Die lokale App führt definierte Prüfungen in der eigenen Umgebung aus und kann Chromium, Analysepipeline, Datenbank und Evidence-Ablage kontrolliert verbinden. Sie eignet sich für interne Qualitätssicherung und sensible Arbeitsprozesse.

Welche Daten synchronisiert werden, wird ausdrücklich festgelegt. Lokaler Betrieb bedeutet nicht automatisch vollständige Isolation; Netzwerk, Updates, Zugriffsrechte und Backups müssen passend zur Umgebung abgesichert werden.

Eine optionale Synchronisation kann freigegebene Status-, Report- oder Katalogdaten zwischen lokaler App und Server-Version übertragen. Sie sollte auf definierte Felder, Rollen, Richtung und Zeitpunkte begrenzt werden.

Es werden keine Daten stillschweigend synchronisiert. Authentisierung, Transportverschlüsselung, Konfliktauflösung, Protokollierung und Löschkonzept müssen vor dem produktiven Einsatz festgelegt werden.

Chromium bildet den normalen Browserablauf ab und macht sichtbare Inhalte, DOM, Cookies, Storage, Netzwerk und Interaktionen beobachtbar. Version und Laufparameter können für die Reproduzierbarkeit dokumentiert werden.

Ein Browserlauf kennt trotzdem nicht automatisch alle Backend-Prozesse, Nutzerrollen oder serverseitigen Datenbanken. Diese Grenze wird im Bericht ausdrücklich benannt und kann nur durch zusätzliche freigegebene Prüfungen erweitert werden.

Die API vermittelt kontrollierte Funktionen zwischen Oberfläche, Prüfprozess und Datenhaltung. Die Datenbank sollte nicht direkt aus dem Browser erreichbar sein; Berechtigungen und Felder werden serverseitig geprüft.

Evidence-Dateien, Reports, Zahlungsstatus und technische Rohdaten können zusätzlich getrennt gespeichert werden. Die konkrete Architektur und Absicherung muss zur lokalen oder serverseitigen Betriebsform passen.

Die Frage nach Verschlüsselung muss für Transport, Datenbank, Dateisystem, Backups und Schlüsselverwaltung getrennt beantwortet werden. Ein einzelner Verschlüsselungshinweis im Report ersetzt keine Infrastrukturprüfung.

Im Prüfmodell sollten Schutzstatus, Zugriff, Aufbewahrung und Redaction dokumentiert werden. Betreiber müssen die konkrete Server- und Backup-Konfiguration mit ihren Verantwortlichen überprüfen.

Eine White-Label-Freigabe erlaubt einer Agentur, Oberfläche, Reportdarstellung und Prozesse an den eigenen Kundenauftritt anzupassen. Rollen, Marken, Domains und Freigabemodelle werden dabei vertraglich und technisch definiert.

Die Herkunft und Integrität der Evidence darf nicht durch das Branding unklar werden. Version, Prüfzeitpunkt, technische Grenzen und Verantwortlichkeiten müssen auch in einer White-Label-Ausgabe nachvollziehbar bleiben.

Treelogy liefert technische Beobachtungen, Quellen, Prioritäten und Evidence. DSB und Kanzlei bewerten Zweck, Rechtsgrundlage, Informationspflichten, Verträge und Risiken; IT und Fachabteilungen setzen Maßnahmen um.

Die gemeinsame Arbeitsgrundlage verhindert, dass technische Vermutungen als fertige Rechtsmeinung oder rechtliche Anforderungen ohne technische Evidenz behandelt werden. Zuständigkeiten und offene Fragen können im Report dokumentiert werden.

Ja, auf Wunsch können technische Verbesserungen und deren Verifikation begleitet werden. Dazu gehören etwa Consent-Konfiguration, Rechtstext-Verlinkung, Header, Accessibility, SEO, CMS-Integration und Report-Regressionen.

Die Umsetzung wird vom Prüfbericht getrennt dokumentiert, damit klar bleibt, was ursprünglich beobachtet, was verändert und was anschließend erneut verifiziert wurde.

Eine lokal betriebene KI kann Varianten, Begriffe, Kategorien und bekannte technische Muster ergänzen, ohne Rohdaten ungeprüft an einen externen Dienst zu senden. Sie kann beispielsweise bei der Vorbereitung einer Klassifikation unterstützen.

Die KI darf jedoch keine Belege erfinden oder die Primärquelle ersetzen. Ergebnis, Quelle, Regel, Modellversion und menschliche Prüfung müssen voneinander getrennt nachvollziehbar bleiben.

Modellinput, interne Verarbeitung und Output sind ohne geeignete Kontrollkette nicht vollständig plausibel und reproduzierbar. Eine freie KI-Bewertung könnte daher nicht zuverlässig zeigen, welche konkrete Quelle zu einer Aussage geführt hat.

Bei Treelogy bleiben Browserbeobachtung, Quelltext, Dokument, Screenshot, Request und Regel die maßgeblichen Primärbelege. KI darf begrenzt unterstützen, aber nicht die Beweiskette oder menschliche Einordnung ersetzen.

Neue Begriffe können aus geprüften Quelltexten, Reports, Katalogen und manuell bestätigten Sonderfällen abgeleitet werden. Sie werden zunächst als Kandidaten gesammelt und einer Regel, Kategorie oder Referenzquelle zugeordnet.

Eine Erweiterung wird erst nach Regressionstests übernommen. So kann ein neuer Begriff die Erkennung verbessern, ohne bestehende Klassifikationen, Städtezuordnungen oder Befundregeln unkontrolliert zu verschieben.

Sonderfälle wie Städte- und Kommunaldomains, Versicherer, Wohnungsgesellschaften, Karriereportale, Shops, Weiterleitungen und hybride Systeme werden über mehrere Signale bewertet. Domainname allein reicht nicht als Klassifikation.

Bekannte Korrekturen und bestätigte Beispiele werden als Testfälle geführt. Bei widersprüchlicher Evidenz bleibt die Ausgabe vorsichtig und zeigt, welche zusätzliche Quelle oder manuelle Prüfung erforderlich ist.

DNS-Fehler, TLS-Probleme, Timeouts, HTTP-Fehler und WAF-Challenges werden als technische Ergebnisse dokumentiert. Ein nicht verfügbarer Report wird nicht mit erfundenen Befunden oder einer falschen Klassifikation aufgefüllt.

Nach einer späteren Erreichbarkeit kann ein neuer Lauf gestartet werden. Die ursprüngliche Fehlersituation bleibt als eigener Status nachvollziehbar und wird nicht stillschweigend überschrieben.

Eine erneute Prüfung ist besonders nach Consent-, CMS-, Tracking-, Rechtstext-, Sicherheits- oder größeren Frontend-Änderungen sinnvoll. Wiederkehrende Läufe können außerdem Regressionen und neue Drittanbieter sichtbar machen.

Intervall und Umfang sollten zum Änderungsrhythmus, Risiko und Schutzbedarf passen. Der technische Datenstand muss bei jedem Lauf separat festgehalten werden.

Ein guter Report zeigt nicht nur eine Liste von Problemen, sondern verbindet Quelle, Beobachtung, Auswirkung, Priorität, Abdeckung und nächste Maßnahme. Dadurch können Betreiber und Fachpartner gezielt entscheiden.

Besonders wertvoll ist die klare Grenze zwischen verifiziertem Signal, technischer Vermutung, nicht assessierbarem Bereich und rechtlicher Bewertung. So wird aus dem Prüfbericht eine belastbare Arbeitsgrundlage statt einer unprüfbaren Behauptung.