KI-Sichtbarkeit in der Praxis: Fallstudie Flowlane
von Peter
Immer mehr Menschen fragen eine KI, bevor sie eine Suchmaschine öffnen. Ob eine Website in diesen Antworten vorkommt, entscheidet sich nicht erst nach dem Launch, sondern schon in der Entwicklung.
In dieser Fallstudie zeigen wir, wie wir das bei flowlane gelöst haben, einem webbasierten Roadmap-Tool für IT-Portfoliomanager: 7 Maßnahmen, die wir von Anfang an eingebaut haben, was sie bewirken sollen, wie sie bei uns im Code aussehen und welche Fehler dabei häufig passieren.
Kurzfassung
- KI-Systeme zitieren nur Websites, die sie crawlen dürfen, technisch lesen können und inhaltlich eindeutig verstehen.
- Die robots.txt sollte KI-Crawler bewusst zulassen oder sperren und dabei zwischen Trainings- und Such-Crawlern unterscheiden.
- Eine llms.txt fasst das Angebot sachlich zusammen, inklusive dessen, was es nicht leistet.
- Strukturierte Daten beschreiben Organisation, Website, Produkt und Artikel als verknüpften Graph, aber nur mit Angaben, die dauerhaft stimmen.
- Inhalte beantworten echte Fragen der Zielgruppe, mit der Kernaussage zuerst, und bilden ein zusammenhängendes Themen-Cluster.
KI-Sichtbarkeit ist eine Architekturfrage
KI-Systeme wie ChatGPT, Perplexity, Claude oder Googles KI-Übersichten beantworten Fragen, statt nur Links zu liefern. Sie greifen dabei auf Seiten zu, die sie crawlen dürfen, technisch lesen können und inhaltlich eindeutig verstehen. Fehlt eine dieser Voraussetzungen, taucht eine Website in der Antwort nicht auf, egal wie gut das Produkt ist.
Die meisten dieser Voraussetzungen sind keine Marketing-Aufgabe, sondern Architektur: Was steht in der robots.txt? Welche Daten liegen maschinenlesbar vor? Beantworten die Inhalte echte Fragen? Wer das früh festlegt, spart später aufwändige Nacharbeit.
Die folgenden sieben Maßnahmen stammen aus einem echten Projekt, dem Launch von flowlane, einem webbasierten Roadmap-Tool für IT-Portfoliomanager. Sie lassen sich auf die meisten Websites übertragen, vom Software-Produkt bis zur Unternehmensseite.
Die konkreten Maßnahmen für eine verbesserte KI-Sichtbarkeit
KI-Crawler in der robots.txt bewusst zulassen
Was: Die robots.txt nennt die relevanten KI-Crawler ausdrücklich und erlaubt ihnen den Zugriff auf alle öffentlichen Inhalte. Die Anwendung selbst und PHP-Endpunkte bleiben gesperrt.
Warum: Viele Websites sperren KI-Crawler, ohne es zu wissen, etwa über Voreinstellungen im CMS, Sicherheits-Plugins oder das CDN. Wer nicht gecrawlt wird, kann nicht zitiert werden.
User-agent: GPTBotUser-agent: OAI-SearchBotUser-agent: ClaudeBotUser-agent: Claude-SearchBotUser-agent: PerplexityBotUser-agent: Google-ExtendedAllow: /Disallow: /app/Disallow: /*.php$
Häufiger Fehler: Trainings-Crawler und Such-Crawler werden in einen Topf geworfen. GPTBot sammelt Trainingsdaten, OAI-SearchBot liefert Quellen für Live-Antworten in ChatGPT. Wer nur GPTBot sperrt, kann trotzdem zitiert werden, und umgekehrt. Diese Entscheidung sollte man bewusst treffen.
Eine llms.txt mit ehrlichen Grenzen
Was: Unter /llms.txt liegt eine kompakte Zusammenfassung des Produkts in Markdown: Funktionen, Tarife, Datenhaltung, Integrationen und eine Liste der wichtigsten Ratgeber-Artikel.
Warum: Eine llms.txt gibt Sprachmodellen eine saubere, offizielle Kurzfassung ohne Navigation, Cookie-Banner und Layout. Die llms.txt verbreitet sich schnell, wird aber aktuell noch kaum gelesen. Innerhalb eines Jahres stieg aber die Zahl der Websites mit einer solchen Datei auf das 8,8-Fache im Mai 2026 (Quelle: PPC Land). Der Standard ist jung und wird noch nicht von allen Systemen ausgewertet. Der Aufwand ist aber gering, und die Datei zwingt dazu, das eigene Produkt in klaren Sätzen zu beschreiben.
Der wichtigste Abschnitt ist „Grenzen“:
GrenzenKein direkter Import aus Excel, Jira oder MS Project, nur das eigene JSON-Format.flowlane ersetzt kein Ticket- oder Aufgabensystem wie Jira, sondern ergänzt es auf Portfolio-Ebene.
Häufiger Fehler: Die llms.txt wird als Werbetext geschrieben. KI-Systeme vergleichen Produkte. Wer offen sagt, was sein Tool nicht kann, wird korrekt eingeordnet und landet bei den passenden Fragen statt bei den falschen.
Strukturierte Daten als zusammenhängender Graph
Was: Die Startseite beschreibt flowlane per JSON-LD als Organization, WebSite und SoftwareApplication, verknüpft über feste @id-Werte. Jeder Ratgeber-Artikel ist als Article mit Autor (Person) ausgezeichnet und gehört zu einem Blog. Die Ratgeber-Übersicht ist eine CollectionPage mit ItemList.
{ "@type": "SoftwareApplication", "@id": "https://flowlaneapp.de/#software", "name": "flowlane", "applicationCategory": "BusinessApplication", "applicationSubCategory": "Roadmap- und Projektportfoliomanagement", "operatingSystem": "Web", "featureList": ["Portfolio-Timeline über alle Projekte und Teams", "..."], "publisher": { "@id": "https://flowlaneapp.de/#organization" }}
Warum: Strukturierte Daten sagen Maschinen eindeutig, was etwas ist: ein Softwareprodukt, eine Organisation, ein Artikel von einer bestimmten Person. Die @id-Verknüpfung macht daraus ein zusammenhängendes Bild statt einzelner Schnipsel.
Häufiger Fehler: Schema-Blöcke werden per Plugin erzeugt und widersprechen dem sichtbaren Inhalt, etwa veraltete Preise oder Bewertungen ohne Grundlage. Strukturierte Daten müssen exakt zur Seite passen.
Fragen so beantworten, wie Menschen sie stellen
Was: Die Startseite enthält sieben häufige Fragen mit Antworten, sichtbar auf der Seite und zusätzlich als FAQPage ausgezeichnet. Beispiel: „Für wen ist flowlane gedacht, und was unterscheidet es von Jira oder Excel?“
Warum: KI-Antworten entstehen aus Textstellen, die eine Frage direkt und vollständig beantworten. Eine gute Antwort beginnt mit der Kernaussage und steht auch ohne den Rest der Seite für sich.
Häufiger Fehler: FAQs mit Fragen, die niemand stellt („Warum ist unser Produkt so gut?“), oder Antworten, die erst nach drei Sätzen Einleitung zur Sache kommen.
Eine Discovery-Datei für KI-Agenten unter /.well-known/
Was: Unter dem festen Pfad /.well-known/mcp.json liegt eine maschinenlesbare Beschreibung der Schnittstelle: Name, Endpunkt, Übertragungsart, Authentifizierung, Link zur Dokumentation und die verfügbaren Werkzeuge, jeweils mit Kennzeichnung, ob sie nur lesen oder auch ändern. Die llms.txt verweist auf diese Datei.
{
"name": "de.flowlaneapp/flowlane",
"websiteUrl": "https://flowlaneapp.de/",
"documentation": "https://flowlaneapp.de/ratgeber/flowlane-mcp-verbindung.html",
"remotes": [
{ "type": "streamable-http", "url": "https://flowlaneapp.de/app/mcp.php" }
],
"authentication": { "type": "bearer" },
"tools": [
{ "name": "get_roadmaps", "description": "Listet alle Roadmaps ...", "readOnly": true }
]
}
Warum: Der Ordner /.well-known/ ist ein standardisierter Ort für maschinenlesbare Metadaten einer Domain, bekannt etwa von security.txt. KI-Agenten und Verzeichnisse müssen so nicht raten, ob eine Website eine Schnittstelle hat und wie man sie anspricht. Für MCP ist diese Konvention noch nicht abschließend festgelegt. Die Datei kostet aber wenig und lässt sich anpassen, sobald sich ein Format durchsetzt.
Häufiger Fehler: Die Datei liegt zwar bereit, ist aber nirgends verlinkt, oder die Authentifizierung ist nur vage beschrieben. Wichtig ist auch die Trennung von lesenden und ändernden Werkzeugen: Ein Agent sollte vorher erkennen, was ein Aufruf bewirkt.
Aktualität und Indexierung konsistent steuern
Was: Jeder Ratgeber-Artikel trägt datePublished und dateModified im Schema. Das lastmod in der sitemap.xml folgt einer festen Regel: bei Artikeln genau das dateModified aus dem Schema. Jede Seite hat ein Canonical-Tag, Entwürfe und Prototypen stehen auf noindex, der Anwendungsbereich ist per robots.txt gesperrt.
<!-- lastmod: Artikel = dateModified aus dem JSON-LD, übrige Seiten = letzte inhaltliche Änderung -->
<url>
<loc>https://flowlaneapp.de/ratgeber/flowlane-mcp-verbindung.html</loc>
<lastmod>2026-10-15</lastmod>
</url>
Warum: KI-Suchsysteme bevorzugen aktuelle Quellen. Widersprüchliche Datumsangaben zwischen Seite, Schema und Sitemap machen eine Quelle weniger vertrauenswürdig. Und Entwürfe sollen nicht als offizielle Aussage zitiert werden.
Häufiger Fehler: Das lastmod wird bei jedem Deployment automatisch auf das aktuelle Datum gesetzt. Suchmaschinen merken das und ignorieren die Angabe dann ganz.
Checkliste: KI-Sichtbarkeit für die eigene Website
- robots.txt prüfen: Sind GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot und Google-Extended bewusst erlaubt oder gesperrt?
- CDN und Sicherheits-Plugins prüfen: Blockieren sie KI-Crawler, ohne dass es in der robots.txt steht?
- llms.txt anlegen: Was das Produkt ist, für wen, was es kostet und was es nicht kann.
- Strukturierte Daten ergänzen: Organisation, Website und Produkt mit festen @id-Werten verknüpfen, Artikel mit Autor auszeichnen.
- Nur auszeichnen, was dauerhaft stimmt und sichtbar auf der Seite steht.
- Echte Fragen der Zielgruppe beantworten, Kernaussage zuerst.
- Ein Themen-Cluster aufbauen, inklusive fairer Vergleiche und Abgrenzungen.
- Gibt es eine Schnittstelle: Discovery-Datei unter /.well-known/ bereitstellen, dokumentieren und verlinken.
- Datumsangaben in Schema und Sitemap nach einer festen Regel pflegen, Entwürfe auf noindex setzen.