Migration to AliothPress with an AI Agent

This guide walks through migrating a site from another CMS to AliothPress using an AI agent and the built-in WebMCP tools: no export files, no import plugins, no dependence on whatever your old page builder is willing to give you. The agent reads the old site in one browser tab, rewrites each piece of content cleanly, and files everything into AliothPress as drafts that you review and publish. The old site's markup, inline styles, broken shortcodes, and accumulated mistakes stay behind, because not a single line of its code is copied.

How this works

A WebMCP-capable agent running in your browser can see two things at once: the old site (as any visitor would) and your AliothPress admin panel (as you, inside your signed-in session). Instead of parsing a database dump, the agent reads each old page the way a careful editor would, rewrites it as clean semantic HTML, and saves it through the same admin routes a human uses, with your confirmation on every write.

Three properties make this safe for a production site:

• Everything lands as a draft. Agents can never publish. Publish requests are demoted to drafts server-side, independently of anything the agent or its tools claim. Nothing appears on the public site until you publish it yourself.
• Every write is approved by you. Single actions show a confirmation dialog, and bulk actions show one dialog for the whole batch (details below).
• Every action is logged. Agent-driven changes appear in the audit log like any other admin action, attributed to your user.

Before you start

1. Enable the admin surface. Open the AI Assistant page in the admin panel and turn on Admin panel under AI agent access (WebMCP). You can turn it off again the moment the migration is done. Access is revoked instantly.
2. Make sure your browser's agent can see the tools. Either your browser supports WebMCP natively (paste your origin trial token in the field on the same AI Assistant page), or enable the compatibility polyfill checkbox there.
3. Sign in to the admin panel in the browser profile the agent uses. The agent works inside your session and inherits exactly your permissions, nothing more.
4. Have the old site reachable in the same browser: publicly, or signed in if the content is behind a login.
5. Optional but recommended: configure an AI provider on the AI Assistant page. The agent then also gets generation, translation, and SEO tools that run through your own API key.

The approval model during a migration

Migrations involve dozens or hundreds of writes, so approvals are designed to scale instead of multiplying:

• Batch approval. When the agent uses create_posts_batch or create_pages_batch, you get one dialog listing every title with a checkbox: select all, or approve a hand-picked subset. Skipped items are reported back to the agent so it knows exactly what happened.
• Autopilot. Any approval dialog offers time-boxed auto-approval: tick the checkbox, pick 15 or 60 minutes, and subsequent agent actions in that browser tab are approved automatically. A visible badge counts down and revokes with one click. Only a human can enable autopilot (it does not exist as an agent tool), and even under autopilot, publishing remains impossible.

Step by step

1. Inventory the old site

Ask the agent to walk the old site and produce a list of pages and posts worth migrating: URL, title, language, and whether the page carries images or a designed layout. This is also the moment to decide what doesn't move. A migration without an export file is a migration without an attic: outdated pages simply stay behind.

2. Recreate posts and pages as drafts

The agent reads each old page and recreates it with create_posts_batch or create_pages_batch. Each batch item supports title, content, excerpt, language, slug, tags, category, SEO fields, and image fields. Two instructions are worth giving the agent explicitly:

• Rewrite, don't copy. The content should be clean semantic HTML (headings, paragraphs, lists, blockquotes) written from the old page's meaning, not a paste of its markup. This is the entire point of migrating this way.
• Pass the old slug. Each item accepts a slug, so URLs like /about-us keep working after the switch. Slugs are sanitized and de-duplicated automatically. check_slug verifies availability up front.

For multilingual sites, migrate one language first, then create the other languages with translation_of pointing at the source item's id (from list_content). The server links them into a translation group, so hreflang and the language switcher work exactly as if you had translated by hand.

3. Bring the images

The agent uploads each image with upload_image (the file travels as base64, with a filename and mandatory alt text, the same accessibility rule the human upload form enforces). Every upload runs through the standard media pipeline: resizing, EXIF stripping, WebP/AVIF variants, SVG sanitizing. Migrated images come out cleaner than the originals. Already-uploaded images are discoverable with list_media, so nothing gets uploaded twice.

4. Attach featured and social images

With the image URLs in hand, attach_image sets a featured image, an Open Graph image, a Twitter card image, or all three in one step: only the image fields change, everything else on the post or page is preserved. For finer edits (an excerpt here, a meta description there), update_post and update_page change exactly the fields you name and leave the rest untouched.

5. Rebuild designed pages in the Page Builder

Landing pages and other designed layouts from the old site's page builder don't need to be copied, and shouldn't be. The agent reads describe_builder_blocks, a machine-readable reference of every block type AliothPress ships (sections, columns, slideshows, galleries, accordions, tables, tickers, forms, and the rest), then recreates the layout natively with create_builder_page. Existing layouts are read with get_page_blocks and updated with set_page_blocks. One rule to remember: on a builder page, the layout is changed through the blocks tools, not through the content field. The tools will tell the agent the same thing if it tries.

6. Wire up the menus

Once the pages exist, build_menu sets the header and footer menus from a list of page and post ids, including nesting. Like every write, it asks you first.

7. Review and publish

At this point the whole migrated site sits in your admin panel as drafts. Read through them, fix what needs fixing (yourself or via the agent), and publish from the admin UI, the one step that is yours alone. When you're done, you can switch the admin surface off again on the AI Assistant page.

Keeping your URLs

• Same domain: pass the old paths as slugs during creation (step 2) and the URLs simply continue to resolve.
• Changed your mind about a slug later? Editing a slug on an existing post or page makes AliothPress create a redirect from the old slug automatically.
• New domain: redirects from the old domain are a job for the old server's configuration (or your DNS/hosting panel), not the CMS.

A prompt to hand your agent

Migrate content from https://old-site.example to this AliothPress admin.

1. List all pages and posts on the old site. Show me the list before doing anything.
2. For each approved item: rewrite the content as clean semantic HTML from
   scratch. Do not copy the old markup. Keep the original slug. Carry over
   title, excerpt, tags, category, and meta description where they exist.
3. Create everything with create_posts_batch / create_pages_batch (drafts).
4. Upload each item's images with upload_image (write descriptive alt text),
   then attach featured + OG + Twitter images with attach_image (slot: all).
5. Rebuild designed pages with the Page Builder tools. Check
   describe_builder_blocks first.
6. Recreate the header and footer menus with build_menu.
7. Report anything you skipped or couldn't map, so I can handle it manually.

Guardrails, recapped

• Agents create and edit drafts only: publishing is blocked in the tool layer and server-side
• Every write is confirmed by you, singly, in batches, or under a time-boxed autopilot that only you can enable and can revoke with one click
• Form submissions (visitor personal data) are excluded from agent endpoints entirely
• Everything the agent does lands in the audit log
• One switch on the AI Assistant page revokes all agent access instantly