Migration zu AliothPress mit KI-Agent

Diese Anleitung führt durch den Umzug einer Website von einem anderen CMS zu AliothPress, mit einem KI-Agenten und den eingebauten WebMCP-Tools: ohne Exportdateien, ohne Import-Plugins und ohne Abhängigkeit davon, was der Page Builder der alten Website herauszugeben bereit ist. Der Agent liest die alte Website in einem Browser-Tab, schreibt jeden Inhalt sauber neu und legt alles als Entwürfe in AliothPress ab, die du prüfst und veröffentlichst. Das Markup der alten Website, ihre Inline-Styles, kaputten Shortcodes und angesammelten Fehler bleiben zurück, weil keine einzige Zeile ihres Codes kopiert wird.

So funktioniert es

Ein WebMCP-fähiger Agent in deinem Browser sieht zwei Dinge gleichzeitig: die alte Website (wie jeder Besucher) und dein AliothPress-Admin-Panel (als du, innerhalb deiner angemeldeten Session). Statt einen Datenbank-Dump zu parsen, liest der Agent jede alte Seite wie ein sorgfältiger Redakteur, schreibt sie als sauberes semantisches HTML neu und speichert sie über dieselben Admin-Routen, die ein Mensch nutzt, mit deiner Bestätigung bei jedem Schreibvorgang.

Drei Eigenschaften machen das für eine Produktiv-Website sicher:

• Alles landet als Entwurf. Agenten können nie veröffentlichen. Veröffentlichungsanfragen werden serverseitig zu Entwürfen herabgestuft, unabhängig davon, was der Agent oder seine Tools behaupten. Nichts erscheint auf der öffentlichen Website, bevor du es selbst veröffentlichst.
• Jeder Schreibvorgang wird von dir freigegeben. Einzelne Aktionen zeigen einen Bestätigungsdialog, Massenaktionen einen einzigen Dialog für den ganzen Stapel (Details unten).
• Jede Aktion wird protokolliert. Agentengesteuerte Änderungen erscheinen im Audit-Log wie jede andere Admin-Aktion, deinem Benutzer zugeordnet.

Bevor du startest

1. Gib die Admin-Oberfläche frei. Öffne die Seite KI-Assistent im Admin-Panel und schalte unter dem KI-Agenten-Zugriff (WebMCP) den Admin-Bereich ein. Nach der Migration kannst du ihn sofort wieder ausschalten. Der Zugriff erlischt augenblicklich.
2. Stelle sicher, dass der Agent deines Browsers die Tools sieht. Entweder unterstützt dein Browser WebMCP nativ (füge deinen Origin-Trial-Token in das Feld auf derselben KI-Assistent-Seite ein), oder du aktivierst dort die Checkbox für das Kompatibilitäts-Polyfill.
3. Melde dich im Admin-Panel an, und zwar in dem Browser-Profil, das der Agent nutzt. Der Agent arbeitet innerhalb deiner Session und erbt exakt deine Berechtigungen, kein Gramm mehr.
4. Halte die alte Website erreichbar, im selben Browser: öffentlich oder angemeldet, falls die Inhalte hinter einem Login liegen.
5. Optional, aber empfohlen: Konfiguriere auf der KI-Assistent-Seite einen KI-Provider. Der Agent bekommt dann zusätzlich Tools für Generierung, Übersetzung und SEO, die über deinen eigenen API-Key laufen.

Das Freigabemodell während einer Migration

Eine Migration bedeutet Dutzende oder Hunderte Schreibvorgänge, deshalb skalieren die Freigaben, statt sich zu vervielfachen:

• Batch-Freigabe. Nutzt der Agent create_posts_batch oder create_pages_batch, bekommst du einen Dialog, der jeden Titel mit Checkbox auflistet: alle auswählen oder eine handverlesene Teilmenge freigeben. Übersprungene Einträge werden dem Agenten zurückgemeldet, sodass er genau weiß, was passiert ist.
• Autopilot. Jeder Freigabedialog bietet eine zeitlich begrenzte Auto-Freigabe an: Häkchen setzen, 15 oder 60 Minuten wählen, und die folgenden Agenten-Aktionen in diesem Browser-Tab werden automatisch freigegeben. Ein sichtbares Badge zählt herunter und lässt sich mit einem Klick widerrufen. Nur ein Mensch kann den Autopiloten einschalten (als Agenten-Tool existiert er nicht), und auch mit Autopilot bleibt Veröffentlichen unmöglich.

Schritt für Schritt

1. Bestandsaufnahme der alten Website

Bitte den Agenten, die alte Website durchzugehen und eine Liste der Seiten und Beiträge zu erstellen, die den Umzug wert sind: URL, Titel, Sprache und ob die Seite Bilder oder ein gestaltetes Layout enthält. Das ist auch der Moment zu entscheiden, was nicht mitkommt. Eine Migration ohne Exportdatei ist eine Migration ohne Dachboden: Veraltete Seiten bleiben einfach zurück.

2. Beiträge und Seiten als Entwürfe neu anlegen

Der Agent liest jede alte Seite und erstellt sie mit create_posts_batch oder create_pages_batch neu. Jeder Eintrag im Stapel unterstützt Titel, Inhalt, Auszug, Sprache, Slug, Tags, Kategorie, SEO-Felder und Bildfelder. Zwei Anweisungen lohnt es sich, dem Agenten ausdrücklich mitzugeben:

• Neu schreiben, nicht kopieren. Der Inhalt soll sauberes semantisches HTML sein (Überschriften, Absätze, Listen, Zitate), geschrieben aus der Bedeutung der alten Seite, nicht als Kopie ihres Markups. Genau darum geht es bei dieser Art von Migration.
• Den alten Slug mitgeben. Jeder Eintrag akzeptiert einen slug, sodass URLs wie /about-us nach dem Umzug weiter funktionieren. Slugs werden automatisch bereinigt und dedupliziert. check_slug prüft die Verfügbarkeit vorab.

Bei mehrsprachigen Websites migrierst du zuerst eine Sprache und erstellst die anderen dann mit translation_of, das auf die ID des Quelleintrags zeigt (aus list_content). Der Server verknüpft sie zu einer Translation Group, sodass hreflang und der Sprachumschalter genau so funktionieren, als hättest du von Hand übersetzt.

3. Die Bilder mitnehmen

Der Agent lädt jedes Bild mit upload_image hoch (die Datei reist als Base64, mit Dateinamen und verpflichtendem Alt-Text, derselben Barrierefreiheitsregel, die auch das menschliche Upload-Formular durchsetzt). Jeder Upload durchläuft die Standard-Medien-Pipeline: Größenanpassung, EXIF-Entfernung, WebP- und AVIF-Varianten, SVG-Bereinigung. Migrierte Bilder kommen sauberer heraus als die Originale. Bereits hochgeladene Bilder findet list_media, sodass nichts doppelt hochgeladen wird.

4. Featured- und Social-Bilder anhängen

Mit den Bild-URLs in der Hand setzt attach_image ein Featured-Bild, ein Open-Graph-Bild, ein Twitter-Card-Bild oder alle drei in einem Schritt: Nur die Bildfelder ändern sich, alles andere am Beitrag oder an der Seite bleibt erhalten. Für feinere Korrekturen (hier ein Auszug, dort eine Meta-Description) ändern update_post und update_page exakt die Felder, die du benennst, und lassen den Rest unangetastet.

5. Gestaltete Seiten im Page Builder nachbauen

Landingpages und andere gestaltete Layouts aus dem Page Builder der alten Website müssen nicht kopiert werden, und sie sollten es auch nicht. Der Agent liest describe_builder_blocks, eine maschinenlesbare Referenz aller Blocktypen, die AliothPress mitbringt (Abschnitte, Spalten, Slideshows, Galerien, Akkordeons, Tabellen, Ticker, Formulare und der Rest), und baut das Layout dann nativ mit create_builder_page nach. Bestehende Layouts liest get_page_blocks, aktualisiert werden sie mit set_page_blocks. Eine Regel zum Merken: Auf einer Builder-Seite wird das Layout über die Block-Tools geändert, nicht über das content-Feld. Die Tools sagen dem Agenten dasselbe, falls er es versucht.

6. Die Menüs verdrahten

Sobald die Seiten existieren, setzt build_menu die Header- und Footer-Menüs aus einer Liste von Seiten- und Beitrags-IDs, Verschachtelung eingeschlossen. Wie jeder Schreibvorgang fragt es dich zuerst.

7. Durchsehen und veröffentlichen

Jetzt liegt die ganze migrierte Website als Entwürfe in deinem Admin-Panel. Lies sie durch, korrigiere, was Korrektur braucht (selbst oder über den Agenten), und veröffentliche aus dem Admin-Panel heraus, den einen Schritt, der dir allein gehört. Danach kannst du die Admin-Oberfläche auf der KI-Assistent-Seite wieder ausschalten.

Deine URLs behalten

• Gleiche Domain: Gib die alten Pfade bei der Erstellung als Slugs mit (Schritt 2), und die URLs funktionieren einfach weiter.
• Später anders überlegt? Wird der Slug eines bestehenden Beitrags oder einer Seite geändert, legt AliothPress automatisch eine Weiterleitung vom alten Slug an.
• Neue Domain: Weiterleitungen von der alten Domain sind Aufgabe der alten Server-Konfiguration (oder deines DNS- oder Hosting-Panels), nicht des CMS.

Ein Prompt für deinen Agenten

Migriere Inhalte von https://alte-website.example in dieses AliothPress-Admin.

1. Liste alle Seiten und Beiträge der alten Website auf. Zeig mir die Liste,
   bevor du irgendetwas tust.
2. Für jeden freigegebenen Eintrag: Schreib den Inhalt als sauberes
   semantisches HTML von Grund auf neu. Kopiere nicht das alte Markup.
   Behalte den Original-Slug. Übernimm Titel, Auszug, Tags, Kategorie und
   Meta-Description, wo sie existieren.
3. Lege alles mit create_posts_batch / create_pages_batch an (Entwürfe).
4. Lade die Bilder jedes Eintrags mit upload_image hoch (schreibe
   beschreibende Alt-Texte) und hänge Featured-, OG- und Twitter-Bilder
   mit attach_image an (slot: all).
5. Baue gestaltete Seiten mit den Page-Builder-Tools nach. Lies zuerst
   describe_builder_blocks.
6. Erstelle Header- und Footer-Menü mit build_menu neu.
7. Melde alles, was du übersprungen hast oder nicht zuordnen konntest,
   damit ich es manuell erledigen kann.

Die Leitplanken, noch einmal

• Agenten erstellen und bearbeiten nur Entwürfe: Veröffentlichen ist in der Tool-Schicht und serverseitig blockiert
• Jeder Schreibvorgang wird von dir bestätigt: einzeln, im Stapel oder unter einem zeitlich begrenzten Autopiloten, den nur du einschalten und mit einem Klick widerrufen kannst
• Formular-Übermittlungen (persönliche Daten der Besucher) sind von den Agenten-Endpunkten vollständig ausgenommen
• Alles, was der Agent tut, landet im Audit-Log
• Ein Schalter auf der KI-Assistent-Seite entzieht den gesamten Agenten-Zugriff sofort