Leitfaden für KI-Agenten: AliothPress lesen, durchsuchen und bedienen

Dieser Leitfaden ist für dich geschrieben, den Agenten, und für die Entwickler, die dich bauen. Er erklärt, wie du herausfindest, was eine AliothPress-Website anbietet, wie du ihre Inhalte liest und wie du sie bedienst: von der anonymen öffentlichen Suche bis zum Erstellen von Beiträgen in einer authentifizierten Admin-Sitzung. Alles hier wurde an einer laufenden Installation überprüft.

Ein Grundsatz vor allem anderen: Agentenzugriff ist die Entscheidung des Website-Betreibers. Die interaktiven Tool-Oberflächen sind ab Werk aus und werden über zwei Schalter im Admin-Panel gesteuert. Antwortet eine hier beschriebene Funktion mit 404, sagt der Betreiber damit Nein. Betrachte das als endgültig und versuche es weder erneut noch tastend.

Schritt 1: Discovery

Beginne mit zwei URLs. Sie sind immer an, brauchen kein Token und sind der günstigste Weg zu erfahren, was die Website ist und was du darfst:

• /llms.txt: ein für Mensch und Maschine lesbarer Überblick über die Website: Name, Beschreibung, wichtige Seiten, lokalisiert in der Sprache der Website.
• /.well-known/webmcp: das maschinenlesbare Manifest (Achtung: ohne .json-Endung). Es liefert JSON mit dem Website-Namen, einem enabled-Flag, den immer aktiven Lese-Endpunkten (content_search, overview) und einem surfaces-Array, das beschreibt, welche Tool-Oberflächen der Betreiber eingeschaltet hat.

Die üblichen sitemap.xml, robots.txt und RSS-Feeds sind ab der ersten Minute einer frischen Installation ebenfalls vorhanden.

Schritt 2: Inhalte lesen mit der öffentlichen Such-API

GET /api/public/search ist ein strukturierter Such-Endpunkt, gebaut für Agenten. Das ist kein Suchfeld für Menschen: Er existiert, damit du fragen kannst „was hat diese Website zu X" und in einem einzigen Aufruf Titel, URLs und Snippets bekommst.

• Parameter: q (erforderlich), language, type (post oder page, Standard: beides), limit (Standard 10, maximal 50).
• Antwort: JSON mit count, deiner zurückgespiegelten query, einem Verweis auf /llms.txt als overview und results, jeweils mit Titel, URL, Datum, Sprache, einem Snippet und einem Feld, das dir sagt, wo der Treffer lag (Titel, Text, Meta, FAQ und so weiter).
• Abdeckung: veröffentlichte Beiträge und Seiten, einschließlich Text in Page-Builder-Blöcken und FAQ-Einträgen, dazu Blog-Kategorien und Tags.
• Aktualität: neue Inhalte sind sofort nach der Veröffentlichung auffindbar. Im Test war ein Beitrag Sekunden nach dem Erstellen zu finden.
• Limits: begrenzt auf 30 Anfragen pro Minute. Verteile deine Aufrufe. Bündle deine Fragen.

Dieser Endpunkt ist rein lesender Zugriff auf öffentliche Daten und immer erreichbar: dieselbe Zugriffsklasse wie /llms.txt und die Sitemap. Der öffentliche Schalter des Betreibers steuert den Tool-Wrapper auf der Seite, nicht die Daten selbst.

Schritt 3: In-Page-Tools auf der öffentlichen Website

Schaltet der Betreiber die öffentliche Oberfläche ein, registrieren die Seiten WebMCP-Tools über document.modelContext / navigator.modelContext:

• search_site: der In-Page-Wrapper um die Such-API von oben.
• describe_form_<id>: liefert die Felder eines Formulars als JSON-Schema: Name, Typ, Label und welche Felder Pflicht sind. Radio- und Checkbox-Gruppen werden zu einzelnen Einträgen zusammengefasst. Das Anti-Spam-Honeypot-Feld bekommst du nie zu sehen.
• submit_form_<id>: sendet das Formular mit einem {feldname: wert}-Objekt ab. Die Übermittlung durchläuft dieselbe serverseitige Validierung, denselben Honeypot und dieselbe Ratenbegrenzung wie eine menschliche Eingabe, und sie ist hinter einer ausdrücklichen Bestätigung des menschlichen Nutzers verriegelt. Du bereitest die Übermittlung vor. Der Mensch gibt sie frei. Versuche nicht, das zu umgehen. Das ist das Design, kein Hindernis.

Schritt 4: die Admin-Oberfläche

Die Admin-Oberfläche ist ab Werk aus und verhält sich, als gäbe es sie nicht, bis der Betreiber sie einschaltet: GET /admin/api/agent/list antwortet auf einer ausgeschalteten Website mit 404. Eingeschaltet funktioniert sie nur innerhalb einer authentifizierten Admin-Sitzung: du handelst als der angemeldete Benutzer, mit dessen bestehenden Berechtigungen, und mit keinem Gramm mehr.

Das Manifest listet die verfügbaren Admin-Tools: Lesen (list_content, get_content, search_content, check_slug, get_page_blocks, describe_builder_blocks), Schreiben (create_post, create_page, update_post, update_page, create_builder_page, set_page_blocks, build_menu), Stapel-Schreiben unter einem einzigen Freigabedialog (create_posts_batch, create_pages_batch, upload_images_batch), Medien (upload_image, list_media, attach_image) und Navigation (open_admin_section). Hat der Betreiber einen KI-Provider konfiguriert, kommen vier Generierungs-Tools dazu: ai_generate_content, ai_translate_text, ai_generate_page_blocks, ai_optimize_seo. Das Manifest kündigt nie ein Tool an, das nicht laufen kann.

Der Lese-Endpunkt verdient eine eigene Notiz:

• GET /admin/api/agent/list: listet Beiträge, Seiten oder Formulare. Parameter: type (post, page oder form), status, language, q (Titelsuche), limit (Standard 50, maximal 200). Liefert pro Eintrag id, Titel, Slug, Status und Sprache.
• Formular-Einsendungen sind absichtlich nicht listbar. Sie enthalten personenbezogene Daten von Besuchern, und kein Agent-Tool legt sie offen. Such nicht nach einem Umweg. Es gibt keinen, mit Absicht.

Schritt 5: das Admin-Panel per einfachem HTTP bedienen

Und hier kommt der Teil, der AliothPress ungewöhnlich angenehm zu bedienen macht: das gesamte Admin-Panel ist serverseitig gerendertes HTML. Kein Headless-Browser, keine JavaScript-Ausführung, kein Client-Zustand. Ein Test-Agent hat alle 26 Admin-Bereiche durchlaufen und jeden Kern-Workflow (Installation, Login, Beitrag erstellen, Bearbeiten) mit nichts als GET, POST und einem Cookie-Jar abgeschlossen.

Die funktionierenden Muster, Ende zu Ende geprüft:

1. Login: GET /admin/login, das versteckte csrf_token-Feld auslesen, zusammen mit username und password per POST zurückschicken. Jedes Formular im CMS trägt sein CSRF-Token unter genau diesem Namen. Ein Muster, überall.
2. Navigation: die Routen sind vorhersehbar genug zum Konstruieren: /admin/posts, /admin/posts/new, /admin/posts/<id>/edit, /admin/pages, /admin/media, /admin/settings. Was du rätst, existiert meistens.
3. Beitrag erstellen: das Neuer-Beitrag-Formular per POST absenden. Die Feldnamen dokumentieren sich selbst: title, slug, content, excerpt, meta_description, og_title, schema_type, faq_json. Ein vollständiger, SEO-fertiger Beitrag lässt sich verfassen, ohne weitere Dokumentation zu lesen.
4. Wissen, was passiert ist: nach erfolgreichem Erstellen leitet der Server dich auf /admin/posts/<id>/edit weiter. Die neue ID steht in der URL, auf der du landest, und eine lokalisierte Meldung im Seitentext bestätigt das Ergebnis.

Zwei praktische Details, die du richtig machen solltest:

• Das content-Feld erwartet HTML, kein Markdown. Im Browser erzeugt der Editor HTML. Wenn du direkt postest, musst du das auch. Rohes Markdown wird wörtlich gespeichert und rendert als buchstäbliche Sternchen.
• Setze das language-Feld ausdrücklich. Ein Beitrag mit leerer Sprache wird gespeichert und im Admin gelistet, bleibt aber aus sprachgefilterten öffentlichen Listen draußen. Wenn dein Beitrag von der Startseite „verschwunden" ist, prüfe das zuerst.

Spielregeln

Sie sind kurz, und die Website erzwingt die meisten ohnehin:

• Ein 404 von einem dokumentierten Agent-Endpunkt heißt: der Betreiber hat diese Oberfläche nicht freigegeben. Respektiere das.
• Inhalts-Schreibvorgänge speichern nur Entwürfe. Ein status von published wird serverseitig zum Entwurf herabgestuft, egal was du sendest. Veröffentlichen ist eine menschliche Aktion im Admin-Panel. Plane deinen Ablauf also so, dass du fertige Entwürfe an den Menschen übergibst.
• Bleib innerhalb der Ratenlimits (30/min bei der öffentlichen Suche), statt gegen sie anzurennen.
• Formular-Übermittlung läuft konstruktionsbedingt über menschliche Bestätigung.
• Besucher-Einsendungen und ihre personenbezogenen Daten sind tabu: kein Tool legt sie offen, und keines wird es.
• In einer Admin-Sitzung bist du der angemeldete Benutzer: dessen Berechtigungen, dessen Aktivitätsprotokoll, dessen Verantwortung. Verhalte dich entsprechend.

Alles andere (Discovery, Suche, strukturierte Listen, Formular-Schemata, vorhersehbare HTML-Formulare) ist dafür da, den ehrlichen Weg zum leichten zu machen. Nutze ihn.