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. Die schwere Arbeit macht der Agent. Du legst zwei Schalter um, gibst ihm seine Anweisungen und gibst seine Arbeit frei. Alles landet als Entwurf, und nichts geht online, bevor du es selbst veröffentlichst.

Dein Teil und der Teil des Agenten

Lies das zuerst, denn es ist die ganze Anleitung in einer Liste. Dein Teil der Migration sind sechs Handgriffe:

1. Agenten-Zugriff einschalten (ein Schalter im Admin-Panel)
2. Anmelden im Admin-Panel, in dem Browser, den dein Agent nutzt
3. Dem Agenten seine Anweisungen geben (ein fertiger Prompt zum Einfügen steht am Ende dieser Anleitung)
4. Die Freigabedialoge beantworten, oder den Autopiloten aktivieren und einen Stapel durchlaufen lassen
5. Die Entwürfe durchsehen und veröffentlichen, der eine Schritt, den nur du tun kannst
6. Den Agenten-Zugriff wieder ausschalten, wenn du fertig bist

Alles andere (die alte Website lesen, Inhalte neu schreiben, Bilder hochladen, Featured- und Social-Bilder anhängen, Layouts nachbauen, Menüs verdrahten) ist der Teil des Agenten. Der Abschnitt mit den Etappen weiter unten beschreibt diese Arbeit, damit du weißt, was dich erwartet und was du prüfen solltest, nicht damit du sie von Hand erledigst.

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. Das Markup der alten Website, ihre Inline-Styles, kaputten Shortcodes und angesammelten Fehler bleiben zurück, weil keine einzige Zeile ihres Codes kopiert wird.

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.
• Jeder Schreibvorgang wird von dir freigegeben. Einzelne Aktionen zeigen einen Bestätigungsdialog, Massenaktionen einen einzigen Dialog für den ganzen Stapel.
• Jede Aktion wird protokolliert. Agentengesteuerte Änderungen erscheinen im Audit-Log wie jede andere Admin-Aktion, deinem Benutzer zugeordnet.

Vorbereitung: was du tust, bevor der Agent loslegt

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.
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 setzt dort das Häkchen 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.

Ein KI-Provider-Key ist nicht nötig. Alles, was die Migration nutzt, funktioniert out of the box: Der Agent bringt sein eigenes Modell mit. Hast du für den eingebauten KI-Assistenten einen Provider eingerichtet, kommen obendrauf vier Bonus-ai_*-Tools dazu (Generierung, Übersetzung, Seitenblöcke, SEO), die über die eigene Engine des CMS laufen. Ohne Provider werden sie schlicht nicht angeboten. Jedes Tool, das der Agent sieht, ist ein Tool, das funktioniert. Schön zu haben, nie erforderlich.

Freigaben: was du tatsächlich anklickst

Eine Migration bedeutet Dutzende oder Hunderte Schreibvorgänge, deshalb skalieren die Freigaben, statt sich zu vervielfachen. Das wirst du wirklich zu sehen bekommen:

• Ein Dialog pro Stapel, nicht pro Eintrag. Legt der Agent viele Beiträge oder Seiten auf einmal an oder lädt er ein Set von Bildern hoch, listet ein einziger Dialog jeden Eintrag mit Checkbox auf. Alle auswählen oder eine handverlesene Teilmenge freigeben. Übersprungene Einträge werden dem Agenten zurückgemeldet.
• Autopilot für lange Läufe. Jeder Freigabedialog hat eine Checkbox, um Agenten-Aktionen für 15 oder 60 Minuten automatisch freizugeben, nur in diesem Browser-Tab. Ein sichtbares Badge zählt herunter. Ein Klick widerruft es. Nur du kannst das einschalten (als Agenten-Tool existiert es nicht), und auch mit Autopilot bleibt Veröffentlichen unmöglich.

Die Migration, Etappe für Etappe

Diese Etappen sind der Arbeitsplan des Agenten. Für jede: was der Agent tut und wo du ins Spiel kommst.

Etappe 1: Bestandsaufnahme

Der Agent geht die alte Website durch und erstellt eine Liste der Seiten und Beiträge: URL, Titel, Sprache und ob die Seite Bilder oder ein gestaltetes Layout enthält.

Du prüfst die Liste und entscheidest, was mitkommt und was nicht. Eine Migration ohne Exportdatei ist eine Migration ohne Dachboden: Veraltete Seiten bleiben einfach zurück. Das ist die wertvollste redaktionelle Entscheidung des ganzen Prozesses, und sie gehört dir.

Etappe 2: Inhalte, neu angelegt als Entwürfe

Der Agent liest jede freigegebene Seite und erstellt sie mit create_posts_batch / create_pages_batch neu: Er schreibt den Inhalt als sauberes semantisches HTML aus der Bedeutung der alten Seite, statt ihr Markup einzufügen, und übernimmt Titel, Auszüge, Tags, Kategorien, SEO-Felder, Social-Card-, FAQ- und Schema.org-Metadaten und die Original-Slugs (damit URLs wie /about-us weiter funktionieren). Bei mehrsprachigen Websites migriert er zuerst eine Sprache und legt die anderen dann verknüpft über translation_of an, sodass hreflang und der Sprachumschalter funktionieren, als hättest du von Hand übersetzt.

Du gibst den Stapeldialog frei, alle Einträge oder eine Teilmenge.

Etappe 3: Bilder

Der Agent lädt die Bilder mit upload_images_batch hoch, ein ganzes Set unter einem einzigen Freigabedialog (einzelne Dateien gehen über upload_image), und schreibt für jedes Bild beschreibende Alt-Texte (verpflichtend, dieselbe 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. Vorher prüft er list_media, sodass nichts doppelt hochgeladen wird.

Du gibst das Set in einem Dialog frei, alle Bilder oder eine handverlesene Teilmenge (für sehr lange Läufe bleibt der Autopilot praktisch).

Etappe 4: Featured- und Social-Bilder

Der Agent hängt Bilder mit attach_image an: Featured, Open Graph, Twitter Card oder alle drei in einem Schritt. Nur die Bildfelder ändern sich, alles andere am Beitrag oder an der Seite bleibt erhalten. Feinere Korrekturen (hier ein Auszug, dort eine Meta-Description) laufen über update_post / update_page, die exakt die benannten Felder ändern.

Du gibst frei. Vorzubereiten gibt es nichts.

Etappe 5: Gestaltete Seiten, nativ nachgebaut

Der Agent kopiert nicht die Ausgabe des alten Page Builders. Er liest describe_builder_blocks (eine maschinenlesbare Referenz aller AliothPress-Blocktypen: Abschnitte, Spalten, Slideshows, Galerien, Akkordeons, Tabellen, Ticker, Formulare und der Rest) und baut jedes Layout nativ nach: viele Seiten auf einmal, indem er ihre Blöcke an create_pages_batch übergibt, einzelne Seiten mit create_builder_page, spätere Änderungen mit set_page_blocks. Sprachversionen gestalteter Seiten funktionieren genauso: translation_of plus die übersetzten Blöcke.

Du gibst frei und schaust dir das Ergebnis im Page Builder an: Layout-Geschmack ist ein menschlicher Sport. Falls du später nachjustierst: Das Layout steckt in den Blöcken, nicht im Content-Feld. Die Tools sagen dem Agenten dasselbe, falls er es versucht.

Etappe 6: Menüs

Der Agent setzt Header- und Footer-Menü mit build_menu aus den neuen Seiten- und Beitrags-IDs, Verschachtelung eingeschlossen.

Du gibst frei, und das ist ein guter Moment, mit der Navigation der alten Website zu vergleichen.

Etappe 7: Durchsehen und veröffentlichen

Der Agent meldet, was er migriert hat und was er übersprungen hat oder nicht zuordnen konnte.

Du liest die Entwürfe durch, korrigierst, was Korrektur braucht (selbst oder über den Agenten), veröffentlichst aus dem Admin-Panel heraus (der eine Schritt, der dir allein gehört) und schaltest die Admin-Oberfläche auf der KI-Assistent-Seite wieder aus.

Deine URLs behalten

• Gleiche Domain: Die alten Pfade wurden in Etappe 2 als Slugs mitgegeben, die URLs funktionieren also 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.

Der Prompt für deinen Agenten

Das ist Schritt 3 deiner sechs. Füge ihn beim Agenten ein, passe die URL an, und die Etappen oben entfalten sich von hier aus:

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,
   Meta-Description sowie Social- und Schema.org-Metadaten, wo sie existieren.
3. Lege alles mit create_posts_batch / create_pages_batch an (Entwürfe).
4. Lade die Bilder mit upload_images_batch hoch (schreibe für jedes Bild
   beschreibende Alt-Texte) und hänge Featured-, OG- und Twitter-Bilder
   mit attach_image an (slot: all).
5. Baue gestaltete Seiten nativ nach: übergib ihre Blöcke an
   create_pages_batch, oder nutze create_builder_page für einzelne Seiten.
   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