White Label / Audit-Log
Früher oder später stellt jemand eine Frage, die niemand aus dem Gedächtnis beantworten kann. Wer hat diesem Kunden seine eigene Domain gegeben? Wer hat dieses Teammitglied entfernt? Wer hat die Website freigegeben, die mit den falschen Preisen online ging? Ein Audit-Log ist das Protokoll, das diese Fragen beantwortet. Diese Seite zeigt genau, was unseres protokolliert, was nicht und wie Sie es nutzen, ohne zu viel daraus abzuleiten.
Demo buchen · Die Preise richten sich nach deinem Volumen und Setup, und deinen genauen Preis erfährst du im Gespräch. 0% Transaktionsgebühr.
Aktualisiert: 25. Oktober 2026

*Zwei echte Einträge aus der Bearbeitung eines Demo-Kunden: Einer änderte Notizen und Tags, der andere das Website-Limit. Jede Zeile zeigt Datum, Benutzer, Aktion, Ressource und Details.*
Jeder Eintrag im Audit-Log besteht aus fünf Teilen:
| Spalte | Was sie enthält | Beispiel aus dem Screenshot |
|---|---|---|
| Datum | Wann die Aktion stattfand | "gerade eben" |
| Benutzer | Wer sie ausgeführt hat | Derzeit als Konto-ID der Person angezeigt, nicht als Name |
| Aktion | Was getan wurde, in Worten | "Kundendaten aktualisiert" |
| Ressource | Welche Art von Objekt betroffen war, und welches | Kunde, mit seiner ID |
| Details | Die Einzelheiten, sofern die Aktion welche hat | Welche Felder sich geändert haben: Notizen und Tags; oder das Website-Limit |
Inhaber und Admins können das Protokoll nach Aktion filtern (Menü "Alle Aktionen") und durchblättern. Andere Teamrollen und Website-Inhaber können es nicht öffnen.
Ein ehrlicher Vorbehalt zum Screenshot: Die Benutzerspalte zeigt heute eine Konto-ID statt eines Namens. Sie können die ID anhand Ihrer Teamliste einer Person zuordnen, sollten diesen Schritt aber kennen, bevor Sie sich in Eile auf das Protokoll verlassen.
Dies sind die Aktionen auf Kontoebene, die ins Protokoll geschrieben werden, gruppiert nach der Frage, die sie jeweils beantworten:
| Frage, die man Ihnen stellt | Protokollierte Aktionen |
|---|---|
| Wer hat diesen Kunden hinzugefügt oder entfernt? | Kunde eingeladen; Kunde entfernt |
| Wer hat geändert, was dieser Kunde tun darf? | Kundendaten aktualisiert, einschließlich Website-Limit, Tarif, Notizen, Tags und Schaltern je Kunde |
| Wer hat die Regeln für alle geändert? | Kundenstandards aktualisiert (die markenweiten Schalter und der Freigabe-Standard) |
| Wer hat die Marke geändert? | Branding aktualisiert |
| Wer hat unser Team geändert? | Teammitglied eingeladen; Rolle geändert; Mitglied hinzugefügt oder entfernt |
| Wer hat die Veröffentlichung dieser Website freigegeben? | Veröffentlichungsanfrage freigegeben oder abgelehnt |
| Wer hat geändert, was Kunden zahlen? | Tarif erstellt, aktualisiert oder gelöscht; Zahlungsanbindung gestartet |
| Wer hat eine Domain entfernt? | Domain entfernt |
| Wer hat die Website eines Kunden aus der Konsole geöffnet? | Kunden-Website geöffnet |
Klarheit darüber ist wichtiger als die obige Liste, denn ein Audit-Log ist nur nützlich, wenn man seine Grenzen kennt.
Beginnen Sie bei der Ressource, nicht beim Datum. Hat ein Kunde plötzlich eine eigene Domain, filtern Sie nach Kundenänderungen und lesen Sie die Einträge zur ID dieses Kunden. Das Detailfeld zeigt, welche Felder sich in jedem Eintrag geändert haben, sodass Sie eine Notizänderung von einer Berechtigungsänderung unterscheiden können, ohne zu raten.
Wählen Sie einen festen Tag. Ein Inhaber oder Admin liest die Einträge des letzten Monats und stellt vier Fragen:
Halten Sie das Datum der Prüfung und alle Nachverfolgungen in Ihren eigenen Unterlagen fest. Ein Protokoll, das nie gelesen wird, beweist sehr wenig.
Wenn ein Teammitglied geht, entfernen Sie es noch am selben Tag und prüfen Sie im Protokoll seine letzten Aktionen. In diesem Moment entdecken Teams am häufigsten eine Berechtigungsänderung, über die nie gesprochen wurde.
Viele öffentliche Stellen müssen Verwaltungsentscheidungen dokumentieren und können Anfragen nach Informationsfreiheitsrecht erhalten. Das Audit-Log kann helfen nachzuvollziehen, wer wann Website-Einstellungen geändert hat, ist aber kein Aktenverwaltungssystem, und wir behaupten nicht, dass es eine bestimmte Aufbewahrungsfrist oder ein bestimmtes Gesetz erfüllt. Behandeln Sie es als Quelle, aus der Sie in Ihr eigenes Aktensystem übernehmen, nach Ihren eigenen Aufbewahrungsregeln. Unsere Seite für Behörden behandelt die Eignung für den öffentlichen Sektor ausführlicher.
Nutzen Sie diese, ob Sie sich für uns entscheiden oder nicht. Unsere Antworten stehen in der rechten Spalte.
| Frage | Warum sie wichtig ist | We.Inc heute |
|---|---|---|
| Welche Aktionen werden protokolliert? Fragen Sie nach der Liste. | "Alles" stimmt selten | Die Aktionen auf Kontoebene aus der obigen Tabelle |
| Werden Inhaltsbearbeitungen innerhalb von Websites protokolliert? | Einstellungsprotokolle und Inhaltshistorie sind verschiedene Dinge | Nein; nutzen Sie die GitHub-Synchronisierung für die Inhaltshistorie |
| Wer kann das Protokoll lesen? | Zu breit, und es sickert durch; zu eng, und niemand liest es | Inhaber und Admins |
| Zeigt ein Eintrag, was sich geändert hat, oder nur, dass sich etwas geändert hat? | Sie brauchen das Feld, nicht nur das Ereignis | Ein Detailfeld listet geänderte Felder auf, sofern die Aktion welche hat |
| Wie lange werden Einträge aufbewahrt? Können sie bearbeitet oder gelöscht werden? | Aufbewahrung und Integrität sind der Sinn eines Protokolls | Keine Angabe zu Aufbewahrung oder Unveränderlichkeit; fragen Sie in der Demo |
| Lässt sich das Protokoll exportieren? | Sie brauchen es eventuell in Ihrem eigenen Aktensystem | Fragen Sie in der Demo nach den aktuellen Exportoptionen |
| Wird der Benutzer mit Namen angezeigt? | Geschwindigkeit während eines Vorfalls | Heute die Konto-ID |
Eine umfassendere Liste von Fragen an Anbieter finden Sie in unserer Beschaffungs-Checkliste.
Das Audit-Log ist das dritte Teil eines Sets. Kundenberechtigungen legen fest, was jeder Website-Inhaber tun darf. Veröffentlichungsfreigaben setzen eine Prüfung vor das Online-Gehen einer Website. Das Audit-Log hält fest, wer eines von beiden geändert und wer was freigegeben hat. Jedes Teil ist allein schwächer: Berechtigungen ohne Protokoll laden zu stillen Ausnahmen ein, und ein Protokoll ohne Berechtigungen dokumentiert nur das Durcheinander.
Der NIST-Leitfaden zum Log-Management (SP 800-92, 2006) ist noch immer die Standardreferenz, wenn Sie eine interne Protokollierungsrichtlinie schreiben; er ist für Sicherheitsprotokolle in einer ganzen Organisation geschrieben, also breiter angelegt als das Kontoprotokoll einer Website-Plattform, aber seine Ratschläge dazu, was protokolliert und wer es prüft, gelten auch hier.
Demo buchen, und wir ändern im Gespräch die Einstellungen eines Kunden und zeigen Ihnen die Einträge, die dabei entstehen.
Zuletzt geprüft am 2026-10-25.
Buche eine 30-minütige Demo. Wir zeigen dir den Baukasten unter deiner Marke, sehen uns an, wie viele Kunden-Websites du betreiben willst, und nennen dir deinen genauen Preis.
Lieber erst die ganze Tour? Den White-Label-Website-Baukasten ansehen
Nein. Es protokolliert Aktionen im Markenkonto, etwa Änderungen an Kunden, Berechtigungen, Marke, Team, Tarifen, Domains und Freigaben. Für eine Historie der Inhaltsänderungen synchronisieren Sie den Code einer Website mit GitHub.
Inhaber und Admins des Markenkontos. Andere Teamrollen und Website-Inhaber können es nicht öffnen.
Wir nennen keine Aufbewahrungsfrist und behaupten nicht, dass das Protokoll manipulationssicher ist. Wenn Sie eine feste Aufbewahrungsfrist brauchen, übernehmen Sie Einträge regelmäßig in Ihr eigenes Aktensystem und fragen Sie uns in der Demo, was verfügbar ist.
Heute zeigt die Benutzerspalte die Konto-ID, die Sie anhand Ihrer Teamliste einer Person zuordnen können.