Blog · Praxisbericht aus dem eigenen Betrieb ·
Praxisbericht: Wie wir die obhut-Landingpage veröffentlicht und geprüft haben
Beim Veröffentlichen dreier Praxisleitfäden reichte uns eine erreichbare Startseite nicht als Nachweis. Wir verglichen die ausgelieferten Dateien mit dem signierten Paket und prüften auch die Markdown-Fassungen. Dabei wurden fehlende Quellen korrigiert und eine verbleibende Header-Abweichung dokumentiert. Dieser Bericht beschreibt den eigenen obhut-Website-Release vom 28. September 2026, kein Kundenprojekt.
Ausgangslage: drei Leitfäden und mehrere Auslieferungsformen
Veröffentlicht wurden ein lokal ausführbarer RLS-Leitfaden, eine Software-Übergabe mit Checkliste und ein Leitfaden für interne CRM-Zugriffe. Neben den HTML-Seiten gehörten Markdown-Fassungen, Downloads, Blogübersicht, Feed und Sitemap zur Änderung. Eine richtige HTML-Ansicht konnte deshalb einen Fehler in einer anderen Darstellung verdecken.
Die Website wurde als statischer Inhalt hinter dem bestehenden Gateway ausgeliefert. Der betrachtete Vorgang tauschte das freigegebene Website-Paket aus. Er aktualisierte weder Anwendungscode noch Datenbankschema der Produktplattform. Auch die später vorbereiteten Leitfäden zu API-Limits, Secrets und Wiederherstellung waren nicht Bestandteil dieses historischen Releases.
Die entscheidende Frage lautete: Entspricht die öffentliche Ausgabe genau dem freigegebenen Stand, und bleiben die vorgesehenen Inhalte in jeder Darstellung erhalten? Besucherzahlen und Suchpositionen beantworten diese Frage nicht. Sie wurden für den hier beschriebenen technischen Vergleich nicht als Erfolgsmaß herangezogen.
Ein signiertes Paket legt den zu prüfenden Stand fest
Das Veröffentlichungspaket enthielt die zugelassenen öffentlichen Dateien mit Prüfsummen. Planung und interne Forschungsunterlagen gehörten nicht in dieses Paket. Eine Signatur band Manifest, Archiv und Veröffentlichungsskript an einen konkreten freigegebenen Stand. Vor der Anwendung wurden diese Bezüge geprüft.
Der veröffentlichte korrigierte Stand stammt aus Commit
719e7c30ad52b8d5d54e58ca811b0cd1964e87a7. Die Release-ID lautet
20260928004224-719e7c30ad52. Der Veröffentlichungsbeleg meldet den
erfolgreichen Abschluss am 28. September 2026 um 00:45:31 UTC, also 02:45:31 Uhr
in Berlin. Diese Kennungen beschreiben den damaligen Vorgang, nicht automatisch
den heute neuesten Stand der Website.
Eine Signatur bestätigt die Zuordnung zum unterzeichnenden Schlüssel. Sie beweist für sich genommen weder korrekten Inhalt noch richtige Serverkonfiguration. Dafür folgten die inhaltlichen und öffentlichen Prüfungen. Die veröffentlichte Belegzusammenfassung nennt ausgewählte Ergebnisse und die Prüfsummen der zugrunde liegenden internen Berichte. Sie ist eine redaktionell erstellte Zusammenfassung, kein unabhängiges Audit und kein vollständiges signiertes Release-Archiv.
Website-Inhalte aktualisieren, den laufenden Gateway erhalten
Für den Vorgang wurde eine Veröffentlichungssperre gehalten und der vorherige Dateistand als Rückweg aufbewahrt. Die neuen Assets wurden vor den HTML-Dateien übertragen. So lagen die zugehörigen Dateien bereit, bevor neue Seiten auf sie verwiesen. Das Verfahren aktualisierte den bestehenden Website-Pfad; der bind-gemountete Wurzelpfad blieb erhalten.
Das ist keine Behauptung eines atomaren Austauschs aller Antworten weltweit. Einzelne Dateien wurden nacheinander ersetzt, und bereits laufende Anfragen oder vorhandene Caches sind davon getrennt zu betrachten. Der Rückweg bestand im aufbewahrten vorherigen Website-Stand. Eine echte Rückschaltung wurde in diesem Veröffentlichungsvorgang nicht ausgeführt und wird hier nicht als erprobt behauptet.
Der Beleg verzeichnet 14 erhaltene Container und keinen neu erstellten Gateway. Das begrenzt den beobachteten Eingriff, ersetzt aber keine lückenlose Verfügbarkeitsmessung. Aus diesen Momentaufnahmen lässt sich keine zugesicherte Ausfallzeit von null Sekunden ableiten.
Der konkrete Fehler: Quellen fehlten in Markdown
Die Quellenlisten waren im HTML vorhanden, wurden aber zunächst nicht in die Markdown-Fassungen übernommen. Ihr HTML-Container war als Navigation markiert. Der vorhandene Konverter ließ Navigation bewusst weg, damit Menüelemente nicht in jedem Dokument wiederholt werden. Für eine Bibliografie war dieses Element deshalb die falsche Bedeutung.
Die Korrektur machte die Quellenlisten zu Inhaltsabschnitten und erhielt ihre Darstellung. Anschließend wurden die Markdown-Dateien neu erzeugt, geprüft und als neuer signierter Stand veröffentlicht. Im korrigierten Paket blieben alle 20 Quelleneinträge der drei Leitfäden in Markdown erhalten. Die Zahl bezeichnet die Quelleneinträge dieses überprüften Artikelsets, keine unabhängige Bewertung ihrer Inhalte.
Die erste Veröffentlichung war um 00:28:10 UTC protokolliert, die korrigierte um 00:45:31 UTC. Diese Zeitpunkte dokumentieren die zwei Eingriffe. Die Differenz ist keine gemessene Reparaturdauer: Beginn der Fehlersuche, aktive Arbeitszeit und andere Zwischenschritte wurden hier nicht vollständig als Zeitmessung erfasst.
Die übertragbare Lehre ist konkret: Wichtige Quellen, Downloads und fachliche Einschränkungen gehören in den Inhaltsbereich einer Seite. Prüfen Sie ihre Anwesenheit auch in den tatsächlich angebotenen Exporten. Eine erfolgreiche Konvertierung ohne Fehlermeldung beantwortet diese Inhaltsfrage nicht.
Was die öffentliche Prüfung tatsächlich ergab
| Prüfung | Ergebnis | Aussagegrenze |
|---|---|---|
| Öffentliche Datei-Hashes | 202 von 202 entsprachen dem signierten Paket. | Bestätigt die abgefragten Bytes, nicht automatisch alle Header oder zukünftige Antworten. |
| Markdown-Auslieferung | 67 Seiten entsprachen den erwarteten Fassungen; alle 20 Quellen der drei neuen Leitfäden blieben erhalten. | Bezieht sich auf den damaligen Seitenbestand. |
| Gesamter Prüfbericht | 347 von 349 Prüfungen bestanden; zwei Content-Type-Befunde blieben offen. | Der unveränderte Bericht hat den Status „failed“. |
| Laufende Umgebung | 14 Container erhalten, Gateway nicht neu erstellt. | Kein Nachweis ununterbrochener Verfügbarkeit zwischen allen Beobachtungen. |
| IndexNow | Sechs geänderte URLs mit HTTP 200 angenommen. | Keine Bestätigung von Indexierung, Rankings oder KI-Zitierungen. |
Die öffentliche Prüfung fragte auch die drei neuen HTML-/Markdown-Paare, Sitemap, Weiterleitungen und ausdrücklich nicht veröffentlichte interne Pfade ab. Lokale Qualitätsprüfungen waren davor erfolgreich durchlaufen worden. Lokale Tests und öffentliche Antworten sind verschiedene Belege; der Bericht behauptet keinen remote ausgeführten CI-Lauf.
Warum 202 passende Hashes trotzdem kein grüner Gesamtbericht sind
Für den herunterladbaren Python-Runner fehlte bei GET und HEAD der erwartete Content-Type. Die Datei selbst war vollständig und entsprach ihrer Prüfsumme. Der kombinierte Dateizähler des Prüfers stand deshalb auf 201 von 202, obwohl alle 202 Byte-Vergleiche stimmten. Wer nur eine dieser Zahlen nennt, lässt einen Teil des Ergebnisses weg.
Ein späterer Browser-Download wurde zusätzlich geprüft: 12.779 Bytes, passend zum SHA-256-Wert des signierten Artefakts. Dieser Schritt zeigte, dass der Download in diesem Browser gelang; die Datei wurde dafür nicht ausgeführt. Er beseitigte den Header-Befund nicht. Der Content-Type blieb eine eigenständige offene Aufgabe.
Das Beispiel zeigt, warum Prüfergebnisse nach Art des Nachweises gelesen werden müssen. Dateiintegrität, Darstellungsinhalt, Metadaten und Nutzbarkeit hängen zusammen, sind aber nicht derselbe Test. Ein ergänzender erfolgreicher Versuch sollte einen ursprünglichen Fehlerbericht nicht nachträglich in einen angeblich vollständig grünen Bericht verwandeln.
Was Agenturen für einen Kundenrelease übernehmen können
- Den Umfang festlegen: Welche Dateien, Dienste, Daten und Exportformate gehören zum konkreten Release? Was bleibt außerhalb?
- Den freigegebenen Stand benennen: Revision und Paket müssen später mit den ausgelieferten Ergebnissen vergleichbar sein.
- Einen Rückweg vorbereiten: Vorherigen Inhalt aufbewahren und bei Anwendungen zusätzlich Schema, Daten und externe Nebenwirkungen berücksichtigen.
- Öffentlich prüfen: Relevante Nutzerwege, Inhalte, Downloads und Header nach der Veröffentlichung beobachten; interne Testergebnisse dafür nicht umdeuten.
- Abweichungen übergeben: Für offene Punkte Verantwortliche und nächste Schritte festhalten. Messungen und Annahmen getrennt benennen.
Bei einer dynamischen Kundenanwendung kommen Anmeldung, Mandantenrechte, Datenmigrationen, Hintergrundjobs und Wiederherstellung hinzu. Dieser Website-Release beweist deren Sicherheit nicht. Der Anwendungsleitfaden und der CRM-Restore-Versuch behandeln diese zusätzlichen Fragen.
Auch einen geschäftlichen Effekt leiten wir aus dem Vorgang nicht ab. Eine angenommene Suchmaschinenmeldung und passende Dateien belegen weder zusätzliche Anfragen noch bessere Sichtbarkeit. Dafür braucht es die getrennte Beobachtung nach der Veröffentlichung. Dieser Praxisbericht dokumentiert einen eng umrissenen technischen Vorgang aus dem eigenen Betrieb.
Das Kundenprojekt mit obhut besprechen
obhut entwickelt eine Betriebsplattform für Agenturen mit Websites, Kundenportalen, SaaS und internen Anwendungen. Statisches Hosting, DNS sowie HTTP/HTTPS-Proxy und Tunnel sind implementiert.
Identitätsbasierter Access, WAF für Kundentraffic und Serverlaufzeiten sind geplant. Ein Hosting- oder Proxy-Baustein übernimmt nicht automatisch die Anwendungspflege, Mailmigration oder Wiederherstellung von Kundendaten. Ein laufender Wartungsvertrag und dessen Leistungen müssten gesondert vereinbart werden.
Im Projektgespräch für Agenturen klären wir Ihre Anwendung, den geplanten Wechsel und die heutigen Zuständigkeiten. Bringen Sie eine kurze Systemübersicht und die offenen Betriebsfragen mit; Zugangsdaten gehören nicht in das Kontaktformular.
Quellen und Prüfstand
Interne Release-Belege am 28. September 2026 ausgewertet. Eigener Website-Betrieb; keine externe Prüfung, keine Agentur-Kundenreferenz.
