Wir haben unsere Website gebaut. 30 Tage später haben wir einen Fehler gefunden, den wir nicht erwartet hatten.
Jeder achte Besucher konnte unsere Seite nicht lesen. Das haben wir nicht vermutet. Wir haben es gemessen. Und genau an dieser Stelle beginnt die Geschichte, die den Unterschied macht zwischen Software ausliefern und Software liefern, die wirkt.
Was passiert ist
Wir haben unsere neue Website live geschaltet. Zweisprachig, Deutsch und Englisch. Auf der Startseite eine automatische Sprachweiche: Sie erkennt, woher der Nutzer kommt, und leitet ihn auf die passende Sprachversion. Industrie-Standard. Sauberes Setup. Die meisten Teams hätten an dieser Stelle abgehakt.
Wir nicht. Stattdessen haben wir 30 Tage lang systematisch ausgewertet, woher die Nutzer kommen, was sie tun und wo sie abspringen. KI-gestützte Analyse, DSGVO-konform, keine personenbezogenen Daten. Das Ergebnis hat uns überrascht.
AI-Suchmaschinen verändern die Spielregeln
Zuerst die gute Nachricht: AI-Suchmaschinen wie ChatGPT, Perplexity und Co. haben in den ersten 30 Tagen über 3.000 Crawler-Visits auf unsere Seite geschickt. Zum Vergleich: 710 echte menschliche Besucher im selben Zeitraum. Die KI-Systeme indexieren, referenzieren und verlinken aktiv auf Unterseiten. Das ist kein Experiment mehr, das ist Realität.
Gartner prognostizierte bereits 2024 einen Rückgang des traditionellen Suchvolumens um 25 % bis 2026, getrieben durch AI-Chatbots und virtuelle Agenten. Diese Verschiebung passiert gerade. Und sie bringt ein Problem mit, das die wenigsten auf dem Schirm haben.
Denn AI-Suchmaschinen verhalten sich anders als Google. Sie verlinken direkt auf Unterseiten. Und sie bevorzugen englische Versionen, weil ihre Trainingsdaten überwiegend englisch sind.
Der Twist: Unsere Sprachweiche griff nicht
Die Sprachweiche funktionierte auf der Startseite. Perfekt. Aber AI-Suchmaschinen schicken Nutzer nicht auf die Startseite. Sie schicken sie auf eine spezifische Unterseite. Die englische Version.
Ein konkretes Szenario: Ein deutscher Nutzer fragt ChatGPT nach einem Thema, das wir abdecken. ChatGPT liefert eine Antwort mit Link. Der Link führt auf unsere englische Unterseite. Der Nutzer klickt, landet auf Englisch, versteht die Seite möglicherweise nicht vollständig. Was passiert? Er klickt weg.
Das ist kein hypothetisches Problem. Wir haben es in den Daten gesehen.
Was die Zahlen sagen
Hier wird es konkret:
| Metrik | Wert |
|---|---|
| Absprungrate: englischsprachige Nutzer auf EN-Seiten | 58 % |
| Absprungrate: deutschsprachige Nutzer auf EN-Seiten | 86 % |
| Differenz | +28 Prozentpunkte |
| Seiten pro Session: englischsprachige Nutzer | 4,0 |
| Seiten pro Session: „gestrandete" deutsche Nutzer | 1,2 |
28 Prozentpunkte. Das ist keine Nuance, das ist ein Abgrund.
Und die 1,2 Seiten pro Session bei den gestrandeten deutschen Nutzern erzählen eine eigene Geschichte. Diese Menschen haben nicht sofort weggeklickt. Sie haben es versucht. Eine Seite angeschaut, vielleicht eine zweite angefangen. Dann aufgegeben. Das Spiegelbild existierte auch in die andere Richtung: Englischsprachige Nutzer, die auf deutschen Unterseiten landeten, zeigten dasselbe Muster.
Wer nur auf Pageviews schaut, hätte den Erfolg gefeiert. Die Gesamtzahlen sahen gut aus. Erst der Drilldown zeigte, dass jeder achte EN-Visitor die Seite nicht verstand.
Warum das ein Build-Measure-Learn-Problem ist
Steve Blank und Eric Ries haben den Build-Measure-Learn-Loop als Kern der Lean-Startup-Methodik beschrieben. Die Idee ist einfach: Du baust etwas, misst die Wirkung und lernst aus der Differenz zwischen Erwartung und Realität. Dann baust du weiter.
Einfach in der Theorie. Selten in der Praxis.
Die meisten Software-Teams behandeln den Launch als Ziellinie. Feature fertig, Deployment durch, Ticket geschlossen. Was danach passiert? Das liegt beim Kunden. Beim Marketing. Bei irgendwem anderem.
Das ist die halbe Arbeit. Die andere Hälfte beginnt nach dem Go-Live: Stimmt unsere Annahme? Nutzen echte Menschen das Produkt so, wie wir es gedacht haben? Wo brechen sie ab? Warum?
Unser Website-Beispiel zeigt das in Reinform. Wir hatten eine vernünftige Annahme: Sprachweiche auf der Startseite reicht, weil Nutzer dort einsteigen. Diese Annahme war richtig für Google-Traffic. Für AI-Search-Traffic war sie falsch. Ohne Messung hätten wir das nie erfahren.
Was wir jetzt ändern
Die Lösung ist chirurgisch, nicht radikal. Die Sprachweiche wird auf jede Unterseite erweitert, aber mit einer klaren Bedingung: Sie greift nur bei externen Einstiegen. Wer über ChatGPT, Google oder Perplexity auf eine Unterseite kommt, wird auf die sprachlich passende Version geleitet.
Wer einmal aktiv eine Sprache gewählt hat, bleibt dort. Wer intern navigiert, wird nicht umgeleitet. Niemand wird bevormundet.
Unsere Hypothese: Die Absprungrate bei sprachlich fehlgeleiteten Besuchern halbiert sich mindestens.
Der Loop schließt sich. Und öffnet sich wieder.
Hier kommt der Teil, den die meisten Teams weglassen. Wir messen das in 30 Tagen erneut. Wenn die Hypothese stimmt, haben wir ein konkretes Problem gelöst. Wenn sie nicht stimmt, lernen wir etwas Neues. Beide Ergebnisse bringen uns weiter.
Das klingt selbstverständlich. Ist es aber nicht. Die Realität in den meisten Software-Projekten sieht anders aus: Feature gebaut, als erledigt markiert, weiter zum nächsten Ticket. Ob das Feature die gewünschte Wirkung hat? Wird selten überprüft. Noch seltener korrigiert.
Build-Measure-Learn ist kein Buzzword. Es ist Handwerk. Und Handwerk zeigt sich daran, dass man es auch dann praktiziert, wenn niemand zuschaut.
Was das für Software-Projekte generell bedeutet
Zwei Erkenntnisse aus dieser Erfahrung, die über unsere Website hinausgehen:
AI-Search verändert, wie Nutzer auf Websites ankommen. Wer seine Seite nur für Google-Traffic optimiert, baut für ein Verkehrsmuster, das gerade an Bedeutung verliert. AI-Suchmaschinen verlinken tiefer, spezifischer und mit eigener Sprachlogik. Darauf muss die Architektur einer Website vorbereitet sein.
Messen nach dem Launch ist keine Kür. Es ist der Teil der Arbeit, der den Unterschied macht zwischen „wir haben es gebaut" und „es funktioniert". Wir haben diesen Fehler gefunden, weil wir systematisch hingeschaut haben. Eine Standardanalyse hätte ihn verdeckt. Erst die Segmentierung nach Sprache und Herkunft hat das Problem sichtbar gemacht.
Software bauen ist die einfachere Hälfte. Nachweisen, dass sie wirkt, ist die schwierigere. Und die wertvollere.
So arbeiten wir
Diese Disziplin bringen wir auch in Kundenprojekte mit. Ob Web-Plattformen, E-Commerce-Systeme oder individuelle Anwendungen: Wir antizipieren vor dem Build, was Nutzer brauchen. Wir messen danach, ob es eingetreten ist. Wir lernen aus den Abweichungen. Und wir korrigieren mit klaren, messbaren Hypothesen.
Falls ihr ähnliche Disziplin für eure Software braucht, wisst ihr jetzt, wofür wir bei Golle IT stehen.