--- title: "Eine WordPress-Website „Agent-Ready“ machen: Ein praktisches Tutorial" date: 2026-07-10 author: "Warren Laine-Naida" featured_image: "https://warrenlainenaida.de/wp-content/uploads/2026/07/warren-laine-naida-agentic-seo.webp" categories: - name: "KI" url: "/category/ki.md" - name: "SEO Lernen" url: "/category/seo-lernen.md" --- # Eine WordPress-Website „Agent-Ready“ machen: Ein praktisches Tutorial Was hat mich dazu inspiriert, meine Websites besser auf Agentic Browsing vorzubereiten? Ich hatte einen seiner Artikel gelesen, mir gefiel das Design seiner Website, und ich habe weitergelesen. Drei Quellen, die ich am hilfreichsten fand, stammen von derselben Person – Joost de Valk, bekannt durch Yoast. - – ein hervorragender Artikel - – ein WordPress-Plugin - (auch [pagespeed.web.dev](https://pagespeed.web.dev) prüft deine Website inzwischen darauf) – prüft deine Website auf Agentenzugriff Ich habe claude.ai genutzt, um mich bei den Anpassungen zu unterstützen. KI ist sehr nützlich, wenn man sie sinnvoll einsetzt. Tools wie isitagentready.com prüfen Websites anhand einer sich entwickelnden Checkliste von Standards für die Auffindbarkeit durch KI-Agenten – Link-Header, Content Signals in robots.txt, API-Kataloge, OAuth-Metadaten, Zahlungsprotokolle und mehr. Die meisten dieser Checklisten sind mit einer generischen Website im Hinterkopf geschrieben, daher trifft nicht jeder Punkt auf jede Website zu. Dieses Tutorial zeigt, wie man herausfindet, was tatsächlich relevant ist, und wie man die relevanten Teile umsetzt – am Beispiel einer echten WordPress-Content-/Unternehmenswebsite. ## Neu in diesem Thema? Eine kurze Einführung Wenn Begriffe wie „Header“, „.htaccess“ oder „curl“ für dich neu sind, beginne hier, bevor du zu Schritt 1 gehst. **Was ist ein „Header“?** Jedes Mal, wenn dein Browser eine Webseite lädt, sendet dein Server nicht nur den eigentlichen Seiteninhalt zurück, sondern auch ein kleines Paket zusätzlicher Informationen, das nie direkt auf der Seite sichtbar ist – zum Beispiel „das ist HTML“, „so wurde diese Seite zuletzt geändert“ oder, in unserem Fall, „hier ist ein Link zu weiteren Infos für KI-Agenten“. Dieses zusätzliche Paket nennt man HTTP-Header. Es ist unsichtbar, es sei denn, man sucht gezielt danach mit einem speziellen Tool. **Was ist `.htaccess`?** Es ist eine kleine Konfigurationsdatei, die im Root-Verzeichnis deiner Website liegt und direkte Anweisungen an deinen Webserver gibt (statt an WordPress). Sie ist sehr mächtig, das heißt aber auch: Fehler darin können deine Website lahmlegen – erstelle immer eine Sicherungskopie, bevor du sie bearbeitest. **Was ist `curl`?** Ein Kommandozeilen-Tool, mit dem man Webanfragen stellt und genau sieht, was ein Server zurücksendet – einschließlich der Header, die ein normaler Browser-Tab vor dir verbirgt. Du musst nichts Besonderes installieren; es ist standardmäßig in Mac- und Linux-Terminals enthalten und auch in Windows PowerShell verfügbar. ### Was du vor dem Start brauchst: - **Zugriff auf die Dateien deiner Website.** Meist bedeutet das ein FTP-Programm (z. B. FileZilla) oder den in deinem Hosting-Kontrollpanel eingebauten „Dateimanager“ (cPanel, Plesk usw.). Wenn du dich nur jemals unter `deinewebsite.de/wp-admin` einloggst, hast du Dashboard-Zugriff, aber keinen Dateizugriff – frage deinen Hoster nach FTP- oder Dateimanager-Zugangsdaten. - **Eine Möglichkeit, Rohdaten-Header zu prüfen.** Entweder ein Terminal (bei Mac/Linux bereits eingebaut; bei Windows PowerShell) oder ein reines Text-Tool im Web wie reqbin.com/curl. - **Eine Sicherung jeder Datei, bevor du sie bearbeitest.** Besonders bei `.htaccess` und `robots.txt` – lade dir jedes Mal zuerst eine Kopie herunter. **Woran erkennst du, ob ein Schritt funktioniert hat?** Wenn in diesem Tutorial „mit `curl` prüfen“ steht, bedeutet das: Öffne ein Terminal, gib `curl -sI https://deinewebsite.de/` ein, drücke Enter, und lies den Textblock, der ausgegeben wird. Du suchst nach der Zeile, die du gerade hinzugefügt hast – sie sollte genau so erscheinen, wie du sie geschrieben hast. Mit dieser Grundlage geht es nun an die eigentliche Checkliste. ## Schritt 1: Wisse, welche Art von Website du betreibst Bevor du irgendetwas am Code änderst, beantworte zwei Fragen: 1. Hast du Datei-/Serverzugriff (FTP, SFTP, SSH, Hosting-Dateimanager) oder nur Zugang zum WordPress-Dashboard? 2. Verfügt deine Website über APIs, kostenpflichtige Inhalte oder einen E-Commerce-Checkout, bei dem sich ein KI-Agent authentifizieren oder bezahlen müsste? Diese beiden Antworten schließen den Großteil der Checkliste sofort aus: Wenn deine Website …überspringe diese Punktenur über das Dashboard zugänglich ist (kein Dateizugriff)alles, was `.htaccess` oder `/.well-known/`-Dateien erfordert — nutze stattdessen Pluginseine Content-/Unternehmenswebsite ohne APIs istOAuth/OIDC-Discovery, OAuth Protected Resource Metadata, `auth.md`, API-Katalog, MCP Server Card, WebMCPnichts programmatisch verkauftx402, MPP, UCP, ACP (Zahlungsprotokolle für Agenten)Für eine typische Website eines kleinen Unternehmens oder eine persönliche WordPress-Website bleiben in der Regel nur **zwei** Punkte der Checkliste übrig, die sich lohnen: - Content Signals in `robots.txt` - Link-Response-Header (RFC 8288) Alles Weitere (DNS-AID, Zahlungsprotokolle, MCP Server Cards) ist entweder noch zu früh im Entwicklungsstadium, erfordert Infrastruktur, die du nicht hast, oder betrifft schlicht keine Website, die keinen eigenen KI-Agenten oder keine eigene API betreibt. ## Schritt 2: Content Signals zu robots.txt hinzufügen WordPress erzeugt standardmäßig eine *virtuelle* robots.txt. Um eigene Direktiven hinzuzufügen, lade eine **physische Datei** in dein Website-Root-Verzeichnis hoch (im selben Ordner wie `wp-config.php`): ``` User-agent: * Allow: / Content-Signal: ai-train=no, search=yes, ai-input=no Sitemap: https://deinewebsite.de/sitemap.xml ``` Passe `ai-train` / `search` / `ai-input` an deine tatsächlichen Präferenzen an. Prüfe außerdem, ob deine `Sitemap:`-Zeile mit der URL übereinstimmt, die dein SEO-Plugin tatsächlich erzeugt – das ist nicht immer `/sitemap.xml`. **Achte auf Konflikte:** Wenn dein SEO-Plugin (Yoast, RankMath usw.) einen eigenen robots.txt-Editor aktiviert hat, deaktiviere ihn – eine physische Datei und eine plugin-verwaltete Version können sich sonst gegenseitig überschreiben. ## Schritt 3: Einen Link-Response-Header hinzufügen Hier findet der Großteil der eigentlichen Fehlersuche statt. Ein paar wichtige Erkenntnisse aus diesem Prozess: ### Verwende einen echten, registrierten Relation-Type Erfinde keinen eigenen `rel`-Wert (z. B. `rel="ai-usage"`). Checker für Agenten-Discovery suchen nach **registrierten IANA-Link-Relationen** – etwa `service-doc`, `help`, `privacy-policy`, `terms-of-service`. Wenn deine Website keine API hat, verlinke stattdessen auf wirklich nützliche Seiten mit echten Relation-Types: apache ``` Header set Link '; rel="privacy-policy", ; rel="help"' ``` ### Bevorzuge .htaccess gegenüber einem mu-Plugin, wenn du Caching nutzt Das Hinzufügen des Headers über WordPress (`add_action('send_headers', ...)` in einem mu-Plugin) ist theme-unabhängig und funktioniert normalerweise gut – aber wenn dein Hoster oder ein Caching-Plugin fertige HTML-Snapshots ausliefert, läuft der PHP-Code von WordPress bei einem Cache-Treffer möglicherweise gar nicht, wodurch der Header stillschweigend verschwindet. Das Setzen des Headers auf **Webserver-Ebene** vermeidet dieses Problem vollständig: apache ``` # Diesen Block ganz oben in der .htaccess einfügen, # vor der Zeile "# BEGIN WordPress" Header set Link '; rel="privacy-policy", ; rel="help"' ``` Sichere die `.htaccess` immer, bevor du sie bearbeitest. ### Mit Rohdaten prüfen, nicht mit einem browserbasierten Checker Manche Online-Tools zum Prüfen von Headern rendern die Ergebnisse über HTML, wodurch stillschweigend Teile des Header-Werts verloren gehen können – insbesondere alles, was wie ein HTML-Tag aussieht, etwa ``. Wenn ein Checker einen Header abgeschnitten oder fehlend anzeigt, obwohl du bereits bestätigt hast, dass er gesetzt ist, prüfe stattdessen mit einem Rohdaten-Tool: bash ``` curl -sI https://deinewebsite.de/ ``` oder einem reinen Text-Tool wie reqbin.com/curl. Genau dieses Problem trat hier auf – der Header war die ganze Zeit korrekt, aber das Rendering des Prüftools hat ihn optisch entfernt. ### Ein allgemeiner Scanner-Fehler bedeutet nicht immer ein Problem auf deiner Seite Wenn ein automatisierter Checker eine Meldung wie „Could not check Link headers: the operation was aborted“ ausgibt, liegt das oft an einer fehlgeschlagenen Anfrage des Scanners selbst (Firewall-Blockade, Rate-Limiting, Timeout) – nicht daran, dass dein Header tatsächlich fehlt. Bestätige das unabhängig mit `curl`, bevor du einem Phantomproblem nachjagst. ## Schritt 4: llms.txt in Betracht ziehen (optional, aber gut geeignet für Content-Websites) Unabhängig von der oben genannten formalen Checkliste ist `llms.txt` eine community-getriebene (nicht-IETF-)Konvention: eine einfache Markdown-Datei im Root-Verzeichnis deiner Website (`/llms.txt`), die KI-Systemen eine knappe Zusammenfassung deiner Website liefert und auf wichtige Seiten verlinkt – ähnlich im Geiste wie `robots.txt` oder `sitemap.xml`, jedoch für Sprachmodelle statt für Crawler oder Suchmaschinen geschrieben. Im Gegensatz zu den meisten oben genannten Checklisten-Punkten ist dieser hier: - wirklich für Content-/Marketing-Websites gedacht, nicht für APIs - eine einzelne statische Datei – keine Serverkonfiguration oder Plugins zwingend erforderlich - zunehmend anerkannt, etwa durch die Agentic-Browsing-Audits von Chrome Lighthouse Wenn deine Website bereits Markdown-Versionen von Seiten erzeugt (achte auf `` im Quelltext deiner Seiten – manche SEO-/KI-Plugins fügen das automatisch hinzu), hast du wahrscheinlich schon die Grundlage, um schnell einen `llms.txt`-Index hinzuzufügen. ## Zusammenfassende Checkliste für eine typische WordPress-Content-Website - Content Signals in `robots.txt` (physische Datei im Root-Verzeichnis) - Link-Response-Header mit **registrierten** `rel`-Types, gesetzt über `.htaccess` - `llms.txt` (optional, hoher Nutzen für content-fokussierte Websites) - Alles andere auf typischen „Agent-Readiness“-Checklisten: **überspringen** – es sei denn, du fügst später APIs, einen MCP-Server oder agentenbasierte Zahlungen hinzu ## Die wichtigsten Erkenntnisse 1. **Lies die Checkliste kritisch** – sie ist für eine generische Website geschrieben, und die meisten Punkte richten sich an API- oder Commerce-getriebene Anwendungsfälle. 2. **Passe die Umsetzungsmethode an deinen Zugriffslevel an** – `.htaccess`/Datei-Uploads, wenn du FTP/SSH hast, Plugins/mu-Plugins, wenn du nur Dashboard-Zugriff hast. 3. **Caching ist die häufigste stille Fehlerquelle** bei serverseitig gesetzten Headern – teste sowohl mit aktiviertem als auch mit deaktiviertem Caching. 4. **Prüfe mit Rohdaten-Tools** (`curl -I`), nicht mit browserbasierten Checkern, da HTML-Rendering Teile von Header-Werten verstecken kann. 5. **Ein Scanner-Fehler bedeutet nicht immer, dass deine Website kaputt ist** – prüfe gegen, bevor du Zeit investierst, etwas zu „reparieren“, das bereits funktioniert. ## Weiterführende Informationen Suchmaschinenoptimierung – Finde dich selbst! Künstliche Intelligenz und Online-Marketing