Skip to content
TAA

Artikel

Jasmine Lise Beauty: GEO, JSON-LD und was KMU-Websites 2026 brauchen

Diese Woche: eine Beauty-Salon-Website für KI-Suchen fit gemacht — JSON-LD-Graph, GEO-Dateien, Entity-Disambiguation. Plus ein gehärtetes Kamera-Backup-System.

8. Juni 2026 · Marcel R. G. Berger · 5 min

  • app entwickeln lassen
  • jasminelise-beauty
  • astro
  • seo
  • geo
  • build-in-public
Teilen

Donnerstagnachmittag saß ich über der Website von Jasmine Lise Beauty und hatte gerade zum dritten Mal die Schemastruktur aufgerollt. Nicht weil etwas kaputt war — sondern weil Google Search Console mir zeigte, dass die bestehenden JSON-LD-Blöcke zwar valide, aber isoliert waren. Einzelne Entitäten ohne Beziehungen. Für klassische Suche: ausreichend. Für KI-gestützte Suche und Answer Engines: nicht mehr genug. Das war der Anlass für einen kompletten SEO- und GEO-Sprint, der sich über zwei Tage zog und am Ende deutlich mehr Substanz hatte als ich ursprünglich geplant hatte.

Jasmine Lise Beauty: wenn eine Website für KI-Suche sichtbar sein muss

Ein JSON-LD-Graph statt loser Einzelentitäten

Das war die wichtigste technische Entscheidung dieser Woche. Bisher hatte die Seite mehrere separate JSON-LD-Blöcke — einen für Person, einen für LocalBusiness, einen für VideoObject. Jeder für sich korrekt, aber ohne explizite Verbindungen zueinander. Suchmaschinen und KI-Systeme müssen dann selbst raten, ob die Person im Person-Block dieselbe ist wie der Inhaber des LocalBusiness. Meistens klappt das. Manchmal nicht.

Ich habe alle Entitäten in einen einzigen @graph-Block zusammengeführt. Jetzt verweisen LocalBusiness und ProfilePage explizit per @id auf die Person-Entität, und die VideoObject-Einträge haben einen publisher-Link zurück zur LocalBusiness. Das ist kein Hexenwerk, aber der Unterschied ist messbar: ein zusammenhängender Graph sagt Crawlern klar, wer hier wer ist — und welche Entität welche andere beschreibt. Ich habe dabei auch die Person-Entität angereichert: givenName, familyName, hasOccupation, geschätzte Interaktionsstatistiken und die YouTube-Channel-ID als sameAs-Eintrag. Details, die für klassisches Ranking kaum zählen — für Entity-Erkennung in Knowledge Graphs aber erheblich sind.

GEO — die Datei, von der die meisten KMU-Websites noch nichts wissen

GEO steht für Generative Engine Optimization: das, was SEO für KI-Antworten ist. ChatGPT, Perplexity, Google AI Overviews — sie alle lesen Websites anders als klassische Crawler. Sie suchen nach klar strukturiertem, maschinenlesbarem Text, der direkt beantwortet: Wer ist das? Was macht diese Person? Warum ist sie relevant?

Dafür gibt es eine Konvention, die sich gerade durchsetzt: llms.txt und llms-full.txt im Root-Verzeichnis — Klartextdateien, die genau diese Fragen in einem Format beantworten, das LLMs direkt verarbeiten können. Ich habe für Jasmine Lise beide Dateien geschrieben: llms.txt als kompakten Identitäts-Block mit Answer-first-Struktur (“Jasmine Lise ist eine Friseurin und Beauty-Content-Creatorin aus…”), llms-full.txt mit Namens-Varianten, Positionierung, einer FAQ auf Deutsch und Englisch und einem kurzen deutschen Zusammenfassungstext.

Das ist ehrlich gesagt noch Neuland. Niemand kann heute mit Sicherheit sagen, welche KI-Systeme diese Dateien aktiv crawlen. Aber der Aufwand ist gering, und der Schaden wenn man es nicht tut ist potenziell groß: wer in drei Jahren noch keine strukturierte GEO-Grundlage hat, kämpft gegen gut gepflegte Wettbewerber mit deutlichem Handicap. Ich baue das lieber jetzt ein, solange es noch kein Standard ist.

Entity-Disambiguation: der unschöne Teil der Arbeit

Jasmine Lise ist kein seltener Name. Das ist das Problem. Wenn eine Suchmaschine “Jasmine Lise” sieht, muss sie entscheiden: welche Jasmine Lise? Die Friseurin aus [Ort], die Content-Creatorin auf YouTube, oder eine der anderen Trägerinnen dieses Namens?

Entity-Disambiguation bedeutet: ich mache es der Maschine so leicht wie möglich, die richtige Person zu identifizieren. Das passiert auf mehreren Ebenen gleichzeitig. Im JSON-LD-Graph über sameAs-Links zu verifizierbaren Profilen. In den Bild-Alt-Texten, die ich überarbeitet habe — weg von “Friseurin bei der Arbeit”, hin zu “Jasmine Lise, Friseurin und Hair-Content-Creatorin, zeigt Heatless-Curl-Technik”. Im <head> über rel=me-Links zu YouTube, Instagram und E-Mail, die Google als Identitätsverifikation wertet. Und im Hero-Teaser selbst: “Heatless curls” war zu nischig, “Fabulous hair” deckt breiteren Hair-Intent ab — eine kleine Änderung mit messbarem SEO-Effekt.

Ob das alles zusammen so funktioniert wie ich es mir vorstelle, weiß ich in vier bis acht Wochen. So ist das mit SEO-Arbeit.

Was mich dabei gestört hat

Ich war mit der Schreibarbeit an llms-full.txt länger beschäftigt als geplant. Nicht wegen technischer Komplikation, sondern wegen Qualitätsanspruch: ein schlechter GEO-Text schadet womöglich mehr als gar keiner, weil er falsche oder verwirrende Informationen in KI-Trainingsdaten einspeist. Ich habe den Entwurf zweimal verworfen, bevor ich mit dem Ergebnis zufrieden war. Das klingt übervorsichtig — aber wenn dieser Text der Ausgangspunkt für hundert zukünftige KI-Antworten über Jasmine Lise wird, sollte er präzise sein. Das war mehr Schreibarbeit als Entwicklungsarbeit, und das war für mich diese Woche die größte Umstellung im Kopf.

Was sonst noch lief

camera-s3-stream hat drei Commits bekommen, die sich klein lesen, aber wichtig sind. Mein Home-Server-Sicherheitssystem — IP-Kameras streamen über RTSP auf S3 — hatte ein stilles Problem: bei vollem tmpfs oder fehlgeschlagenen mv-Operationen hat der Upload-Loop einfach stillschweigend weitergemacht, als wäre nichts gewesen. Dateien gingen verloren, ohne dass irgendein Log-Eintrag das angezeigt hätte. Ich habe die Upload-Schleife jetzt gehärtet: transiente I/O-Fehler werden gefangen, geloggt, und der Loop erholt sich graceful. Zusätzlich habe ich den Kamera-Discovery-Cache so gebaut, dass ein erzwungener Re-Scan den Disk-Cache tatsächlich invalidiert — vorher hat ein Force-Flag den alten Cache-Stand genommen und damit die Neuerkennung sabotiert. Kleiner Fehler, blöde Konsequenz.

CivoCloudManager 2.1.1 ist draußen — ein kleines Maintenance-Release mit aktualisierten rechtlichen Dokumenten und einem neuen Support-Tab in der App. Nichts Dramatisches, aber diese Art von Release ist wichtig: eine App ohne aktuelle Datenschutzerklärung und erreichbaren Support-Kanal hat im App Store ein Problem.


Wenn du eine Website oder App für dein Unternehmen planst und dir nicht sicher bist, ob sie 2026 noch gefunden wird — nicht nur von Google, sondern auch von den KI-Systemen, die immer mehr Suchanfragen beantworten — ist das genau die Art von Arbeit, die ich für Kunden mache. Schau dir an, was ich anbiete: /services/.

Den öffentlichen Code zu CivoCloudManager findest du auf GitHub — und die App selbst auf der Projektseite.

Teilen