Wie wir jede Behauptung auf unserer Website geprueft haben (und was wir gefunden haben)

Der Ausgangspunkt

OmniWatchGuard ist innerhalb weniger Monate schnell gewachsen — neue Funktionen, neue Seiten, neue Texte bei jedem Sprint. Irgendwann wurde mir klar, dass ich nicht mehr sicher wusste, ohne den Code zu pruefen, welche Behauptungen auf der Website wahr waren und welche noch aus der Planungsphase stammten.

Es war keine bewusste Entscheidung zu luegen. Es ist die Art von Diskrepanz, die bei einem Solo-Founder-Produkt ganz natuerlich entsteht: Man schreibt Texte fuer eine Funktion, bevor man sie baut, setzt sie auf die Roadmap, und dann bleibt der Text in der Eile, andere Dinge zu launchen, monatelang unveraendert.

Der Prozess: wie wir die Diskrepanzen gefunden haben

Wir sind nicht von einer Liste von Verdachtsmomenten ausgegangen. Wir sind von einer einfachen Frage ausgegangen: Entspricht jede Datei, die oeffentlichen Inhalt erzeugt — Seiten, FAQ-Komponenten, JSON-LD-Schema, der Preisrechner — dem, was tatsaechlich im Code existiert?

1. Wir haben alle Dateien aufgelistet, die fuer Nutzer oder Suchmaschinen sichtbaren Text erzeugen: FAQ.astro, FAQSchema.astro, FAQEnterprise.astro, PricingSchema.astro, Comparison.astro, Calculator.astro, SoftwareAppSchema.astro, AggregateRatingSchema.astro, privacy.astro
2. Fuer jede Funktionsbehauptung ("unterstuetzt X", "ueberwacht Y") haben wir die tatsaechliche Implementierung im Backend/Crawler gesucht
3. Wir haben jede Behauptung in drei Kategorien eingeteilt: wahr (implementiert und getestet), teilweise wahr (implementiert, aber mit nicht erwaehnten Einschraenkungen), falsch (nur auf der Roadmap oder nie gebaut)
4. Fuer jede falsche oder teilweise Behauptung haben wir eine von zwei Massnahmen gewaehlt: entweder den Text korrigieren, um der Realitaet zu entsprechen, oder die Funktion tatsaechlich bauen, damit sie wahr wird

Was wir gefunden haben

Fest codierte Bewertungen und Testimonials

AggregateRatingSchema.astro und Testimonials.astro hatten eine feste Bewertung von 4,9, eine feste Zahl von "200+ Bewertungen" und "500+ Unternehmen" sowie Namen und Zitate von Testimonials, die direkt im Code geschrieben waren — diese Kunden existierten nicht. Wir haben alles durch echte Daten ersetzt, berechnet aus der reviews-Tabelle der Datenbank: durchschnittliche Bewertung und echte Anzahl der Bewertungen, der Testimonials-Bereich blendet sich selbst aus, wenn noch keine echte Bewertung existiert. Der "Bewertung hinterlassen"-CTA bleibt dauerhaft sichtbar.

Roadmap-Funktionen, die als live dargestellt wurden

Die Ueberwachung von Login-Seiten, RBAC (Rollen und Berechtigungen) und SSO erschienen in der FAQ und der Vergleichstabelle als verfuegbare Funktionen. Das waren sie nicht. Wir haben alle sechs betroffenen Dateien (FAQ, FAQSchema, PricingSchema, Comparison, Calculator, SoftwareAppSchema) korrigiert, um klar "Roadmap 2026" fuer RBAC/SSO anzuzeigen, und haben die Behauptung ueber iOS-/Android-Apps, die nicht existierten und nicht geplant waren, vollstaendig entfernt.

Anzeigefehler, der ein echtes Problem verdeckte

Die Comparison.astro-Komponente auf der Startseite hatte einen Rendering-Fehler, der ein gruenes Haekchen (✓) fuer jede Funktion anzeigte, unabhaengig von den tatsaechlichen dahinterliegenden Daten — auch fuer Funktionen, die die Konkurrenz hatte und wir nicht. Die Vergleichstabelle log praktisch wegen eines technischen Fehlers, nicht nur wegen veralteten Textes.

Warum wir uns entschieden haben, die Funktion zu bauen, statt nur den Text zu korrigieren

Fuer das Login-Seiten-Monitoring hatten wir die Wahl: den Text korrigieren (schnell, eine Stunde Arbeit) oder die Funktion tatsaechlich bauen (mehr Aufwand, loest das Problem aber an der Wurzel). Wir haben die zweite Option gewaehlt. Wir haben eine verschluesselte Spalte (AES-GCM) fuer Authentifizierungs-Cookie/Header an der Monitor-Tabelle hinzugefuegt, der Crawler entschluesselt und injiziert den Header auf beiden Abruf-Wegen (einfach und Puppeteer) und erkennt Sitzungsablauf ueber einen 401-/403-Statuscode oder eine Weiterleitung auf eine Login-Seite. Wir haben es End-to-End auf dem eigenen OmniWatchGuard-Dashboard getestet (das Authorization: Bearer statt Cookie verwendet), bevor wir den Text als wahr erneut veroeffentlicht haben.

Was unveraendert geblieben ist

Nicht alles, was wir unvollstaendig fanden, wurde durch Bauen korrigiert. RBAC und SSO bleiben auf einer echten Roadmap fuer 2026 — sie sind eindeutig als solche markiert, und wir versprechen kein genaues Datum, bevor wir nicht tatsaechlich mit der Arbeit daran begonnen haben.

Haeufig gestellte Fragen

Warum veroeffentlichen Sie das, statt es still zu korrigieren?

Weil der Prozess selbst fuer andere Solo-Founder nuetzlich ist, die auf dieselbe natuerliche Diskrepanz zwischen Roadmap und Marketingtext stossen, und weil Transparenz darueber, was heute wahr ist, mehr Vertrauen aufbaut als jedes Testimonial.

Wie verhindern Sie, dass sich dasselbe Problem wiederholt?

Es gibt noch keinen automatisierten Prozess, der die Diskrepanz vollstaendig verhindert — das ist ein strukturelles Risiko bei jedem Produkt mit schneller Iteration. Was sich konkret geaendert hat: Bewertungen und Testimonials koennen nicht mehr fest codiert werden (sie kommen ausschliesslich aus der Datenbank), und jede neue Funktion, die im Text erwaehnt wird, durchlaeuft vor der Veroeffentlichung eine manuelle Pruefung gegen den Code.

Umfasste die Pruefung auch die englischen Seiten?

Ja, alle Korrekturen wurden symmetrisch auf die RO- und EN-Versionen jeder betroffenen Datei angewendet, einschliesslich des von Suchmaschinen genutzten JSON-LD-Schemas.