Warum ich aufhörte, Websites zu optimieren, und anfing, ein Protokoll zu spezifizieren

SOVP habe ich nicht am Reißbrett entworfen. Es ist aus zwölf Jahren Technical SEO entstanden, aus der Beobachtung, dass ein Beruf sein Fundament verliert, und aus der Entscheidung, das Fundament neu zu bauen statt weiter an der Oberfläche zu arbeiten.

Diese Seite erzählt, wie das passiert ist: von der ersten Beobachtung sinkender Klickraten bis zum aktiven IETF Draft. Die Spezifikation liegt bei Litzki Systems LLC, das Produkt bei CERTavia. Hier steht die Geschichte dazwischen.

Die Beobachtung: 2024 bis September 2025

Die ersten Anzeichen kamen aus der eigenen Arbeit. Klickraten in Kundenprojekten fielen, bei gleichbleibendem Ranking. Auf der eigenen Domain zeigte sich dasselbe Bild. Etwas hatte sich verschoben, ohne dass ein Algorithmus-Update es erklärte.

Was folgte, war kein Bauchgefühl mehr, sondern drei Zahlen, die ich bewusst nicht vermische:

Die Mehrheit der Besucher auf vielen Domains war zu diesem Zeitpunkt bereits Maschine, nicht Mensch. Für Maschinen gab es keine verlässliche Antwort auf eine einfache Frage: Wem gehört diese Domain, und stimmt, was sie behauptet? Kein Zertifikat, kein Protokoll, keine Instanz beantwortete das deterministisch. Diese Lücke wurde zum Ausgangspunkt.

Der Werkzeugbau: November bis Dezember 2025

Bevor ein Protokoll entstand, entstanden Werkzeuge. Ein eigenes Keyword- und Backlink-Tool. Eine Alternative zu Frase und NeuronWriter für Content-Briefings. Eigene Dashboards für Projektreporting.

Der Grund war schlicht: allein zu arbeiten bedeutet, monatliche Kosten im dreistelligen Bereich pro Tool selbst zu tragen, für Software, die selten genau das lieferte, was ein Projekt brauchte. Eigenbau kostete Zeit, sparte Geld und lieferte am Ende exakt die Daten, die gebraucht wurden. Kein Marketing-Layer dazwischen.

Wer seine Werkzeuge selbst baut, sieht irgendwann etwas, das kein fertiges Tool zeigt: die Lücke unter allen Werkzeugen. Jedes SEO-Tool misst Rankings, Backlinks, Content-Scores. Keines beantwortete, ob die Domain, die es analysierte, überhaupt vertrauenswürdig war, für eine Maschine, die selbst entscheidet.

Das Manifest: Januar 2026

Im Januar 2026 entstand das Revenue Architecture Protocol, RAP v1.8: ein Beratungs-Framework in Marketing-Sprache, für Entscheider, mit zehn Säulen. Ich nenne es hier offen ein Manifest, nicht eine Spezifikation. Das ist es gewesen.

Fünf Ideen aus RAP trugen weiter, unverändert bis heute:

• Architektur vor Content
• Maschinenlesbarkeit als Designziel, nicht als Nachgedanke
• Deterministische statt stochastischer Logik
• Extern verankertes Vertrauen statt Selbstauskunft
• Unveränderlichkeit des Kerns

Was fehlte, war handfester: Formalisierung, Offenheit, kryptographische Prüfbarkeit. RAP forderte das Richtige und besaß noch kein Verfahren, es zu beweisen.

Ein frühes Blackbox-Konzept aus dieser Phase entstand in einer Zusammenarbeit, die früh endete. Was danach folgte, entstand von Grund auf neu: eigene deterministische Architektur, eigene Anmeldung.

Die Scoring-Logik: Zwölf Jahre in einem Prüfkatalog

Lange vor dem Manifest existierte ein gewichteter SEO-Audit-Katalog: 28 Prüfpunkte in sechs Bereichen, Technik, Performance, Mobile, Content, Struktur und Offpage. Jeder Punkt erhielt eine Auswirkungsstufe und einen Erfüllungsgrad.

Die Formel dahinter: Σ(P × V) / Σ V_max × 100. Kein Protokoll, ein Beratungswerkzeug, gewachsen aus zwölf Jahren operativer SEO-Arbeit, in denen ich Hunderte von Domains exakt so bewertet habe. Subjektiv, überprüfbar nur durch die Person, die den Audit durchführte, signiert von niemandem.

Die Struktur dieses Katalogs lebt im heutigen CES-Score weiter: gewichtete Parameter, gruppiert in Cluster, aggregiert zu einem Gesamtwert, bewertet gegen eine definierte Schwelle. Die Architektur bleibt dieselbe. Drei Schichten kamen hinzu:

• Reproduzierbarkeit: Derselbe Scan ergibt heute auf jeder Maschine dasselbe Ergebnis.
• Kryptographische Signierung: Das Ergebnis ist fälschungssicher dokumentiert.
• Binäre Konsequenz: CERTIFIED oder FAILED. Der alte Katalog erlaubte Graustufen. SOVP erlaubt sie bewusst nicht.

Der Protokoll-Parameterraum umfasst über 265 Signale. CERTavia implementiert daraus 80+ Parameter in sechs Clustern, zugeschnitten auf den EU AI Act. Beide Zahlen stimmen. Sie beschreiben verschiedene Schichten desselben Systems.

Zwischen dem alten Prüfkatalog und dem heutigen Protokoll lag eine Phase, in der ich prüfte, ob mathematische Modelle aus der Wellenphysik beweisen können, dass architektonische Integrität messbare algorithmische Sichtbarkeit erzeugt. Die Mathematik war valide, die Fragestellung führte in die falsche Richtung. Der Kurswechsel von der physikalischen Analogie zur kryptographischen Verifikation war die entscheidende Wende.

Die Formalisierung: März bis Juni 2026

Der vollständige Benchmark, DACH Enterprise Readiness Report 2026, zeigt, wie selten CERTIFIED bislang erreicht wird. Die Audit-Dimensionen im Detail stehen auf der Expertise-Seite.

Was SOVP beansprucht, und was nicht

SOVP ist eine Verifikationsschicht unterhalb bestehender Trust-Frameworks. Es ergänzt sie, es ersetzt sie nicht. SOVP prüft nicht, ob ein Inhalt wahr, vollständig oder regelkonform ist. Es prüft, ob die Herkunft eines maschinenlesbaren Dokuments kryptographisch belegt ist, bevor eine Instanz es überhaupt verarbeitet.

Wo das Protokoll heute lebt

Drei Stellen, an denen SOVP heute tatsächlich existiert, nicht nur beschrieben wird:

• Die Spezifikation bei Litzki Systems LLC →
• draft-litzki-sovp auf dem IETF Datatracker →
• Die eigene Domain scannen lassen, CERTavia →

Der Weg von der ersten sinkenden Klickrate bis zum aktiven Draft war nicht geplant. Er war die logische Folge einer einzigen Frage, die kein bestehendes System beantworten konnte.