// leitfaden
Wie wenden Sie GEO auf Ihrer eigenen Website in der Praxis an?
Autor: Dmitry Filippov, Founder, GET-GEO.AI
Veröffentlicht: 2026-08-03 · Aktualisiert: 2026-09-22
// kurze antwort
Bei einer halbtägigen Prüfung von get-geo.ai fanden wir widersprüchliche Einstellungen für Apex und www, einen veralteten Vorschlag eines KI-Agenten und unvollständige Textexporte. Wir haben Canonical-URLs, Sitemap und llms.txt auf einen Host ausgerichtet. Prüfen Sie, bevor Sie weitere Inhalte veröffentlichen, ob Crawler die richtige Version der vorhandenen Inhalte erreichen.
- GEO auf unserer eigenen Website brauchte einen halben Tag und keine neuen Seiten: einen primären Host, eine Domain-Property in der Search Console und neu erzeugte llms-full-Exporte.
- Jedes Signal zeigte auf den Apex, während der Apex mit einer 308-Weiterleitung auf www antwortete: eine Schleife, aus der KI-Crawler mit nur einer Anfrage pro Seite nie herauskommen.
- Die Checkliste eines KI-Agenten verlangte für den A-Eintrag des Apex 76.76.21.21; das aktuelle DNS zeigte 216.198.79.1, die neuere Infrastruktur von Vercel. Prüfen Sie Ratschläge eines Modells deshalb am laufenden System.
- Eine frisch eingereichte Sitemap kann ein paar Tage lang „Konnte nicht abgerufen werden“ anzeigen; prüfen Sie drei Dinge: Die Datei öffnet sich, jeder loc-Eintrag nennt den richtigen Host, robots.txt führt sie auf.
- llms-full liefert jetzt eine Datei für jede der neun Sprachen; Devanagari belegt 3 Bytes pro Zeichen, sodass die Hindi-Datei im August 2026 85 KB erreichte. Das Limit wurde seither mehrfach angehoben, heute auf 2 MB.
Ausgangspunkt: eine Website, die richtig aussieht
Wir wenden unsere GEO-Methoden auf unsere eigene Website an. Dieser Leitfaden hält einen Arbeitstag fest: die Probleme, die wir gefunden haben, die Änderungen, die wir vorgenommen haben, und die Prüfungen danach. Jedes Beispiel stammt von get-geo.ai.
get-geo.ai wurde vom ersten Tag an „nach Lehrbuch“ gebaut: serverseitiges Rendering, neun Sprachen mit hreflang, Schema.org-JSON-LD, ein Aufbau, der die Antwort an den Anfang stellt, llms.txt. Was sollte es da noch zu beheben geben? Die Prüfung fand ein Problem, das sich mit bloßem Auge nicht erkennen lässt.
Befund Nr. 1: der Konflikt zwischen Apex und www
Die Website lag tatsächlich unter www.get-geo.ai, während alle Signale – Canonical-URL, Sitemap, hreflang, JSON-LD, llms.txt – auf get-geo.ai zeigten (den Apex, also 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 übersteht das, verbraucht dabei aber Crawl-Budget. KI-Crawler oft nicht: Viele haben nur ein oder zwei Anfragen pro Seite zur Verfügung, und manche erreichen den Inhalt über eine Weiterleitung gar nicht. Für GEO ist das entscheidend: Eine Datei, die der Crawler nicht sieht, existiert für ihn nicht.
Die Lösung: Der Apex wurde beim Host (Vercel) zur primären Domain, www leitet per 308 auf den Apex weiter. Mit diesem einen Schalter wurden alle Signale stimmig: die tatsächliche Adresse, die Canonical-URL, die internen Links, die Sitemap und llms.txt zeigen jetzt auf denselben Ort.
Die Hauptadresse darf die Domain mit oder ohne www sein. Wählen Sie eine, leiten Sie die andere dorthin weiter und sorgen Sie dafür, dass Canonical-URLs, Links und Sitemap übereinstimmen, denn davon hängt der Zugang der Crawler ab.
Befund Nr. 2: ein veralteter Tipp eines KI-Agenten
Die Diagnose führte ein KI-Agent durch. Auf seiner Checkliste stand: „Prüfen, ob der A-Eintrag des Apex auf 76.76.21.21 zeigt.“ Das aktuelle DNS zeigte etwas anderes: Die Domain wird zu 216.198.79.1 aufgelöst, der neueren Infrastruktur von Vercel, auf die der Host nach dem Trainingsstichtag des Modells umgezogen ist.
Der Rat war nicht schädlich, nur veraltet. Das Modell zitierte selbstsicher die Vergangenheit.
Technische Hinweise eines KI-Modells sollten Sie am laufenden System prüfen. Hier genügte eine DNS-Abfrage, um die vorgeschlagene Adresse als veraltet zu erkennen. Ohne Prüfung kann eine plausible Antwort auch eine alte Konfiguration beschreiben.
Schritt 3: Google Search Console – die Domain-Property
Nach dem Wechsel des primären Hosts wurde die alte Property der Search Console (ein URL-Präfix auf https://www.get-geo.ai/) nutzlos: Sie deckt nur www ab, während die Seiten auf den Apex umzogen.
Richtig ist eine Domain-Property (get-geo.ai, ohne Protokoll und ohne Subdomain): Sie deckt Apex, www, http, https und alle Subdomains auf einmal ab. Verifizieren lässt sie sich nur über einen DNS-TXT-Eintrag, mit einem erfreulichen Detail: Das Token google-site-verification gehört zum Konto und nicht zur Verifizierungsmethode, deshalb bestand ein früher im DNS eingetragener Eintrag die Prüfung sofort. Danach haben wir die Sitemap unter der Apex-Adresse eingereicht: https://get-geo.ai/sitemap.xml.
Die Lehre: Eine frisch eingereichte Sitemap steht in der Search Console oft mit dem roten Status „Konnte nicht abgerufen werden“ und null Seiten da. Das ist kein Fehler, sondern ein Platzhalter bis zur ersten Verarbeitung; sie läuft asynchron und kann bis zu ein paar Tage dauern. Prüfen Sie, bevor Sie in Panik geraten, drei Dinge: Die Datei öffnet sich unter ihrer direkten URL, jedes <loc> darin zeigt auf den richtigen Host, und robots.txt enthält eine Zeile Sitemap:. Stimmt alles, warten Sie einfach.
Schritt 4: die maschinenlesbaren Dateien in die Sitemap aufnehmen
Unsere Sitemap enthält mehr als Seiten. Sie führt llms.txt, llms-full.txt und jede Sprachversion von llms-full/{locale} auf, mit lastmod-Daten und Prioritäten.
Der Grund: Beobachtungen zufolge lesen KI-Crawler (GPTBot, ClaudeBot, PerplexityBot) Sitemaps. Wer die LLM-Dateien ausdrücklich auflistet, gibt ihnen einen direkten Weg zur maschinenlesbaren Version der Website, ohne dass der Crawler die /llms.txt-Konvention kennen muss.
Listen Sie die Inhalte auf, die Crawler finden sollen, und geben Sie lastmod-Daten an, die tatsächliche Änderungen widerspiegeln.
Schritt 5: llms-full – der vollständige Inhalt statt eines Inhaltsverzeichnisses
Die Konvention unterscheidet zwei Dateien: llms.txt ist ein Inhaltsverzeichnis mit Links, llms-full.txt der vollständige Inhalt für Systeme, die Links nicht folgen. Unsere Full-Version enthielt anfangs nur die Startseite: Die Leitfäden, unsere am besten zitierbaren Inhalte, waren nur Seite für Seite erreichbar.
Was wir geändert haben:
- Eine Datei pro Sprache. Die vollständigen Leitfadentexte liegen unter llms-full/{locale}, jede Datei durchgehend in ihrer eigenen Sprache. Wer neun Sprachen in eine Datei packt, verdünnt die nützliche Dichte für jede konkrete Frage auf ein Neuntel.
- Eine URL unter jeder Überschrift. Jeder Leitfaden beginnt in der Datei 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.
- Exporte aus demselben Register wie die Leitfaden-Seiten. Wird ein Leitfaden veröffentlicht, aktualisieren sich Website, Sitemap und llms-full-Dateien gemeinsam, ohne manuellen Abgleich.
- Die Größenobergrenze sichtbar machen. Passt ein Leitfaden nicht mehr unter die Obergrenze, hängen wir seinen Titel und Link an, statt den Text stillschweigend abzuschneiden.
- Eine Lehre von unerwarteter Seite: Das erste Limit von 100 KB wäre fast an einem Schriftsystem gescheitert. Devanagari (Hindi) belegt in UTF-8 3 Bytes pro Zeichen, lateinische Schrift 1; die Hindi-Datei erreichte 85 KB, die englische war halb so groß. Damals haben wir das Limit auf 300 KB angehoben und seither, als weitere Leitfäden hinzukamen, auf 2 MB. Planen Sie bei einer mehrsprachigen Website das Budget mit Blick auf die Schrift: CJK-Schriften und indische Schriften belegen ein Mehrfaches an Platz.
Das Ergebnis des Tages
Ein halber Arbeitstag, keine einzige neue Inhaltsseite – und trotzdem:
- jedes Signal der Website zeigt auf einen Host, ohne Schleifen und zusätzliche Weiterleitungen;
- ein KI-Crawler mit nur einer Anfrage pro Seite bekommt den Inhalt beim ersten Versuch;
- die Search Console sammelt Daten für die gesamte Domain, nicht für eine Subdomain;
- alle Leitfäden in neun Sprachen liegen für Maschinen vollständig vor, als eine Datei pro Sprache;
- die Veröffentlichung eines neuen Leitfadens aktualisiert die Website, die Sitemap und llms-full automatisch.
Technische Prüfungen vor weiteren Inhalten
Diese Korrekturen machen Inhalte zugänglich und über die ganze Website einheitlich. Sie belegen nicht, dass eine Seite zitiert wird, beseitigen aber Probleme, die einen Crawler am Lesen hindern können.
Verwandte Fragen
Spielt Apex oder www für GEO eine Rolle?
Die Wahl selbst nicht. Entscheidend ist, dass die Website auf genau einem Host läuft und jedes Signal – Canonical-URL, Sitemap, hreflang, JSON-LD, llms.txt – dorthin zeigt, während der andere Hostname dauerhaft weiterleitet. Eine Schleife zwischen Apex und www verbraucht Crawl-Budget und stoppt oft KI-Crawler, 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-Eintrag verifiziert. Eine URL-Präfix-Property allein für www erfasst nichts mehr, sobald der primäre Host auf den Apex wechselt.
Warum llms.txt in der Sitemap auflisten?
Beobachtungen zufolge lesen KI-Crawler Sitemaps. llms.txt und die llms-full-Dateien je Sprache aufzulisten gibt ihnen einen direkten Weg zum maschinenlesbaren Bestand, ohne dass jeder Crawler die /llms.txt-Konvention kennen muss.
Warum eine llms-full-Datei pro Sprache statt einer mehrsprachigen Gesamtdatei?
Eine einzelne Datei mit neun Sprachen verdünnt die nützliche Dichte für jede konkrete Frage auf ein Neuntel. Eine Datei pro Sprache hält den Bestand dicht, stellt unter jede Überschrift eines Leitfadens die kanonische URL und lässt sich aus demselben Register erzeugen wie die HTML-Seiten.
Verwandte Leitfäden
Quellen
// teilen
So zitieren Sie diese Seite
Zitieren und Weiterverwenden ausdrücklich erwünscht — mit Quellenangabe und Link auf diese Seite.
“Wie wenden Sie GEO auf Ihrer eigenen Website in der Praxis an?” — GET-GEO.AI, 2026-09-22. https://get-geo.ai/de/guides/how-we-do-geo-ourselves