Warum Rechtstexte nicht im CMS verstreut liegen sollten
Verteilte Rechtstexte in CMS-Seiten, Word-Dokumenten und kopierten Snippets erschweren Versionierung und Live-Abgleich. Der Beitrag zeigt typische Risiken.
Guides
Praxisorientierte Beiträge zu Versionierung, Freigabe, HTML/JSON/PDF-Auslieferung und Live-Abgleich veröffentlichter Rechtstexte.
Was ist Legal Content Operations?
Verteilte Rechtstexte in CMS-Seiten, Word-Dokumenten und kopierten Snippets erschweren Versionierung und Live-Abgleich. Der Beitrag zeigt typische Risiken.
Wie strukturierte Verwaltung, klare Reviews und kontrollierte Veröffentlichung das Management rechtlich relevanter Website-Inhalte vereinfachen.
Multi-Site- und Multi-Locale-Setups stellen besondere Anforderungen an Variantenpflege und Veröffentlichungskontrolle.
Drei Artefaktformen der Public Delivery API im Vergleich — wann HTML, wann JSON, wann PDF passt.
Wie Transaktions-Delivery für Rechtstexte funktioniert: HTML im E-Mail-Footer, JSON im eigenen Template oder PDF als Anhang in Bestell-, Vertrags- und Registrierungsbestätigungen.
Wie Workspaces, Brands und Site-Profile getrennte Mandanten und Marken sauber abbilden.
Legal Content Drift entsteht, wenn die live sichtbare Fassung eines Rechtstextes nicht mehr der freigegebenen Version entspricht — auf Websites, in Apps, in Sprachen oder in transaktionalen E-Mails.
Ein Rechtstext kann prüfungsbedürftig werden, ohne dass jemand ihn angefasst hat: weil sich der rechtliche Rahmen ändert, weil sich Website und Angebot ändern oder weil live eine andere Fassung steht als freigegeben. Der Überblick über die drei Anlässe und den Prüfprozess dahinter.
Nicht jede Rechtsänderung betrifft jedes Dokument. Wie sich von einer Änderung zu den tatsächlich betroffenen Marken, Märkten und Dokumenttypen eingrenzen lässt — statt aus jedem Newsletter-Alarm eine Komplettdurchsicht zu machen.
Neues Tool, neue Funktion, neuer Dienstleister: Die Website verändert sich laufend, der Rechtstext nicht automatisch mit. Welche Website-Änderungen typischerweise einen Prüfanlass erzeugen, wie sich das belegen lässt — und warum es darauf keine pauschale Ja/Nein-Antwort gibt.
Beide Male stimmt etwas nicht zwischen Website und Rechtstext — die Ursache ist aber gegensätzlich: Entweder hat sich die Realität verändert, oder es steht schlicht die falsche Fassung live. Ein Entscheidungsbaum und was jeweils zu tun ist.
Signal, Relevanzprüfung, Prüfhinweis, Review, optionaler Änderungsvorschlag, Entwurf, Freigabe, Veröffentlichung: die Kette, die aus einer Veränderung eine nachvollziehbare Entscheidung macht — inklusive der Entscheidung, nichts zu ändern.
Sequentielle Reviews, Schwellenwert-Freigaben und das Verbot von Self-Review als Bausteine nachvollziehbarer Prozesse.
Immutable Snapshots, Wiederherstellung als neuer Entwurf und nachvollziehbare Versionsverläufe.
Welche rechtlich relevanten Dokumente SaaS-Produkte typischerweise pflegen und wo Fehler entstehen.
Basisdokument, gezielte Overrides und das Vermeiden duplizierter Volltexte für saubere Variantenpflege.
Wie sich die freigegebene AGB-Fassung als PDF-Artefakt aus der Public Delivery API an transaktionale Bestellbestätigungen anhängen lässt — versioniert und nachvollziehbar.
HTML im E-Mail-Footer oder PDF im Anhang: wie die freigegebene Widerrufsbelehrung versioniert in transaktionale Bestätigungen gelangt.
Version Pinning, effective_at-Auslieferung und Audit Trail: wie sich der Bezug zwischen einer Transaktion und der gültigen veröffentlichten Fassung technisch herstellen lässt.
Drift entsteht beim Veröffentlichen, nicht erst beim Suchen: eine Quelle statt kopierter Volltexte, Risikomomente wie Relaunch und Caching, plus kontinuierlicher Live-Abgleich.
Zentrale Basisversion plus gezielte Varianten für mehrere Marken, Märkte und Sprachen — ohne Volltexte zu duplizieren, mit Freigabe und Veröffentlichung je Marke und Kontext.
TermShelf als zentrale Quelle und Delivery-Layer für Shop-Systeme: HTML, JSON und PDF über die Public Delivery API statt verstreuter Pflege im Shop-Backend.
Wie Shopware-Storefronts und Bestellbestätigungs-Mails AGB, Widerrufsbelehrung und Datenschutzinformationen als versioniertes HTML-, JSON- oder PDF-Artefakt aus TermShelf beziehen — statt Volltexte in Sales Channels und Twig-Mail-Templates zu pflegen.
Wie transaktionale Shopify-E-Mails AGB- und Widerruf-Artefakte aus einer externen Delivery-Quelle beziehen: PDF im Anhang, HTML-Fragment im Template oder JSON in der eigenen Middleware — versioniert und zum Bestellzeitpunkt nachvollziehbar.
Wie WooCommerce-Bestellmails die freigegebene AGB- oder Widerruf-Fassung als PDF-Anhang, HTML-Fragment oder JSON aus TermShelf beziehen — statt Rechtstexte im Theme- oder Mail-Template zu pflegen, das beim nächsten Update überschrieben wird.