// leitfaden
Wie macht man GEO auf der eigenen Website in der Praxis?
Aktualisiert: 2026-08-03
// kurze antwort
Technisches GEO ist Hygiene, keine Magie. Auf get-geo.ai hat ein halber Arbeitstag jedes Signal auf einen einzigen Host ausgerichtet, KI-Fetchern den Inhalt mit der ersten Anfrage gegeben, die Search Console auf eine Domain-Property umgestellt und den kompletten Leitfaden-Korpus in llms-full-Dateien pro Locale gelegt, die sich aus demselben Register aktualisieren wie die Seiten. Der Inhalt entscheidet, ob Sie zitiert werden; die Technik entscheidet, ob jemand weit genug liest, um Sie zu zitieren.
Ausgangspunkt: eine Website, die richtig aussieht
Wir verkaufen GEO — also muss unsere eigene Website die Referenzimplementierung sein. Dieser Leitfaden ist keine Theorie, sondern das Protokoll eines echten Arbeitstags: was wir gefunden, wie wir es behoben und was wir überprüft haben. Jedes Beispiel stammt von genau dieser Website.
get-geo.ai wurde vom ersten Tag an „nach Lehrbuch“ gebaut: serverseitiges Rendering, 9 Sprachen mit hreflang, Schema.org-JSON-LD, Answer-First-Struktur, llms.txt. Was sollte es da noch zu reparieren geben? Das Audit fand ein Problem, das man mit bloßem Auge nicht sieht.
Befund Nr. 1: der Konflikt zwischen Apex und www
Physisch lebte die Website auf www.get-geo.ai, während jedes Signal — canonical, sitemap, hreflang, JSON-LD, llms.txt — auf get-geo.ai zeigte (den Apex, die Domain ohne Subdomain). Der Apex wiederum antwortete mit einer 308-Weiterleitung zurück auf www.
Das Ergebnis war eine Schleife: „Die kanonische Version ist der Apex“ → der Apex leitet auf www weiter → www sagt „die kanonische Version ist der Apex“. Ein klassischer Google-Crawler überlebt das, verbrennt dabei aber Crawl-Budget. KI-Fetcher oft nicht: Viele haben ein Budget von ein oder zwei Anfragen pro Seite, und manche erreichen den Inhalt durch eine Weiterleitung schlicht nie. Für GEO ist das kritisch: Eine Datei, die der Fetcher nicht sieht, ist eine Datei, die nicht existiert.
Die Lösung: Der Apex wurde beim Host (Vercel) zur primären Domain gemacht, www leitet per 308 auf den Apex weiter. Ein einziger Schalter — und alle Signale wurden konsistent: tatsächliche Adresse, canonical, interne Links, sitemap und llms.txt zeigen jetzt alle auf denselben Ort.
Die Lehre: Die Wahl zwischen Apex und www spielt keine Rolle. Entscheidend ist, dass die Website auf genau einem von beiden lebt und der andere hart weiterleitet. Jede Lücke zwischen „wo die Website lebt“ und „wohin die Signale zeigen“ ist eine Steuer auf jeden Crawler-Besuch.
Befund Nr. 2: ein veralteter Tipp von einem KI-Agenten
Die Diagnose führte ein KI-Agent durch, und auf seiner Checkliste stand: „prüfen, dass der A-Record des Apex auf 76.76.21.21 zeigt“. Ein Blick in das tatsächliche DNS zeigte etwas anderes: Die Domain löst auf 216.198.79.1 auf — Vercels neuere Infrastruktur, auf die der Host nach dem Trainingsstichtag des Modells migriert ist.
Der Rat war nicht schädlich — nur veraltet. Das Modell zitierte selbstbewusst die Vergangenheit.
Die Lehre: Ein KI-Agent ohne Verifikationswerkzeuge ist Gedächtnis, kein Wissen. Prüfen Sie jede technische Empfehlung eines Modells gegen den Live-Zustand des Systems: Eine DNS-Abfrage dauert eine Sekunde und entscheidet die Frage. Das ist übrigens das Kernprinzip von GEO selbst: Modelle antworten aus dem, was sie lesen konnten — und genau deshalb machen wir Inhalte lesbar.
Schritt 3: Google Search Console — die Domain-Property
Nach dem Wechsel des primären Hosts wurde die alte GSC-Property (ein URL-Präfix auf https://www.get-geo.ai/) nutzlos: Sie deckt nur www ab, während die Seiten auf den Apex umzogen.
Die richtige Konfiguration ist eine Domain-Property (get-geo.ai, ohne Protokoll, ohne Subdomain): Sie deckt Apex, www, http, https und alle Subdomains auf einmal ab. Verifizieren lässt sie sich nur über einen DNS-TXT-Record — mit einem angenehmen Detail: Das google-site-verification-Token hängt am Konto, nicht an der Verifizierungsmethode, sodass ein früher ins DNS eingetragener Record die Prüfung sofort bestand. Danach: das Einreichen der Sitemap unter der Apex-Adresse — https://get-geo.ai/sitemap.xml.
Die Lehre: Eine frisch eingereichte Sitemap steht in der GSC oft mit dem roten Status „Konnte nicht abgerufen werden“ und null Seiten da. Das ist kein Fehler, sondern ein Platzhalter bis zum ersten Verarbeitungslauf — der ist asynchron und kann bis zu ein paar Tage dauern. Bevor Sie in Panik geraten, prüfen Sie drei Dinge: Die Datei öffnet sich unter ihrer direkten URL, jedes <loc> darin zeigt auf den richtigen Host, und robots.txt enthält eine Sitemap:-Zeile. Wenn alle drei stimmen — einfach warten.
Schritt 4: die Sitemap als GEO-Instrument, nicht als Formalität
Unsere Sitemap enthält mehr als Seiten. Sie listet llms.txt, llms-full.txt und jede Sprachversion von llms-full/{locale} — mit lastmod-Daten und Prioritäten.
Warum: KI-Crawler (GPTBot, ClaudeBot, PerplexityBot) wurden dabei beobachtet, wie sie Sitemaps lesen, und das explizite Auflisten der LLM-Dateien gibt ihnen einen direkten Weg zur maschinenlesbaren Version der Website — ohne darauf zu bauen, dass der Fetcher die /llms.txt-Konvention kennt.
Die Lehre: Behandeln Sie die Sitemap als Speisekarte für Maschinen, nicht als Pflichtkästchen. Alles, was KI-Systeme sehen sollen, gehört dort hinein — mit ehrlichen lastmod-Daten.
Schritt 5: llms-full — vollständiger Inhalt statt Inhaltsverzeichnis
Die Konvention unterscheidet zwei Dateien: llms.txt ist ein Inhaltsverzeichnis mit Links; llms-full.txt ist der vollständige Inhalt für Systeme, die Links nicht folgen. Unsere Full-Version enthielt anfangs nur die Startseite: Die Leitfäden — unser zitierfähigster Bestand — waren nur Seite für Seite erreichbar.
Was wir geändert haben:
- Dateien pro Locale. Die vollständigen Leitfaden-Texte zogen nach llms-full/{locale} um, jede Datei komplett in ihrer eigenen Sprache. 9 Sprachen in eine Datei zu kippen heißt, die nützliche Dichte für jede konkrete Anfrage um das Neunfache zu verdünnen.
- Eine URL unter jeder Überschrift. In der Datei beginnt jeder Leitfaden mit seinem Titel und der kanonischen URL direkt darunter — damit ein Modell, das den Text übernimmt, die Seite zitieren kann und nicht die txt-Datei selbst.
- Automatische Generierung aus einem einzigen Register. Die Dateien werden aus derselben Quelle gebaut wie die Leitfaden-Seiten. Ein neuer Leitfaden erreicht Website, Sitemap und llms-full in einem Schritt. Manuelle Synchronisation stirbt binnen eines Monats — wir haben sie gar nicht erst angefangen.
- Ein Limit mit ehrlicher Degradation. Die Datei hat eine Größenobergrenze; läuft sie über, hängt sie statt stillem Abschneiden eine Liste der Leitfäden an, die nicht mehr hineinpassten — mit Links.
- Eine Lektion aus unerwarteter Richtung: Das erste 100-KB-Limit wäre fast an einem Schriftsystem zerbrochen. Devanagari (Hindi) belegt in UTF-8 3 Bytes pro Zeichen gegenüber 1 für lateinische Schrift — die Hindi-Datei erreichte 85 KB, während die englische halb so groß war. Wir haben das Limit auf 300 KB angehoben. Wenn Ihre Website mehrsprachig ist, budgetieren Sie mit Blick auf die Schrift: CJK- und indische Schriftsysteme wiegen um ein Mehrfaches mehr.
Das Ergebnis des Tages
Ein halber Arbeitstag, keine einzige neue Inhaltsseite — und trotzdem:
- jedes Signal der Website zeigt auf einen Host, ohne Schleifen oder überflüssige Weiterleitungen;
- ein KI-Fetcher mit einem Budget von einer Anfrage bekommt den Inhalt beim ersten Versuch;
- die GSC sammelt Daten für die gesamte Domain, nicht für eine Subdomain;
- der komplette Korpus der Leitfäden in 9 Sprachen steht Maschinen als eine Datei pro Locale zur Verfügung;
- die Veröffentlichung eines neuen Leitfadens aktualisiert Website, Sitemap und llms-full automatisch.
Hygiene, keine Magie
Das ist die technische Seite von GEO: keine Magie, sondern Hygiene. Der Inhalt entscheidet, ob Sie zitiert werden. Die Technik entscheidet, ob jemand weit genug liest, um Sie zu zitieren.
Verwandte Fragen
Spielt Apex vs. www für GEO eine Rolle?
Die Wahl selbst nicht. Entscheidend ist, dass die Website auf genau einem Host lebt und jedes Signal — canonical, sitemap, hreflang, JSON-LD, llms.txt — dorthin zeigt, während der andere Hostname hart weiterleitet. Eine Schleife zwischen Apex und www verbrennt Crawl-Budget und stoppt oft KI-Fetcher, die nur ein oder zwei Anfragen stellen.
Sollte ich in der Google Search Console eine Domain-Property verwenden?
Ja, wenn Ihnen sowohl Apex als auch www (oder http und https) wichtig sind. Eine Domain-Property deckt alle auf einmal ab und wird per DNS-TXT verifiziert. Eine URL-Präfix-Property allein auf www wird blind, sobald der primäre Host auf den Apex wechselt.
Warum llms.txt in der Sitemap auflisten?
KI-Crawler wurden dabei beobachtet, wie sie Sitemaps lesen. llms.txt und die llms-full-Dateien pro Locale aufzulisten gibt ihnen einen direkten Weg zum maschinenlesbaren Korpus — ohne darauf zu bauen, dass jeder Fetcher die /llms.txt-Konvention kennt.
Warum llms-full-Dateien pro Locale statt eines mehrsprachigen Dumps?
Eine einzige Datei mit neun Sprachen verdünnt die nützliche Dichte für jede konkrete Anfrage um das Neunfache. Eine Datei pro Locale hält den Korpus dicht, setzt unter jede Leitfaden-Überschrift eine kanonische URL und lässt sich aus demselben Register generieren wie die HTML-Seiten.
Verwandte Leitfäden
Quellen
// teilen