Website Migration With AI: Keep Your Search Traffic

A website migration keeps its search traffic when three things are true: every old URL is accounted for, every one that changes redirects permanently to the page that replaces it, and someone watches Search Console afterwards and fixes what missed. An AI agent makes the inventory cheaper to build and the redirect map faster to write. It reads the old site, lists every URL, fetches the content and images, drafts the new pages and produces the redirect rows. It does not make the decisions. You decide what stays, where each page goes, and when to publish.

This guide is the method end to end, with a post for each step. It is written for someone moving a WordPress, Wix or Squarespace site to a hosted builder, and most of it applies to any move where URLs change. Where it describes the destination, it uses Beste, because that is the builder we know from the inside; the method works on any platform that lets you control paths and redirects.

If you are here because of PHP2Shell

Updated 22 October 2026.

On 21 October 2026 the PHP project shipped emergency releases for two critical flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619, that allow unauthenticated remote code execution on servers running unpatched PHP. WordPress sites are exposed because WordPress runs on PHP, and the WordPress.org announcement is clear that no WordPress update fixes it: the PHP on the server has to change.

A migration is not the response to this week. Patching takes hours; a careful move takes weeks, and the old site stays live and exposed for all of those weeks unless it is patched too. Ask your host to confirm the patched PHP is installed, and check the version yourself. What the incident does show is who maintains the layer under your site, and whether a theme or plugin keeps you on a PHP version that no longer gets fixes. If it does, you are choosing between an upgrade project and a migration project anyway. The details, with every source, are in Migrating From WordPress After PHP2Shell.

Why this is worth doing differently now

Migrations used to be expensive in a specific way: the inventory, the extraction and the rebuild were days of careful, boring work, so the inventory was the step that got skipped. People rebuilt from the navigation menu instead. The pages the menu did not show, the old articles, the PDFs other sites linked to, the posts that ranked for years without anyone touching them, were left behind without a redirect. Those are often the pages that earned the search traffic.

An agent that can fetch pages, parse an export file, write Markdown and call a website builder's tools removes the boring part. Listing every URL and pulling out every page becomes hours of the agent's time instead of days of yours. What that buys is not speed for its own sake; it buys the ability to do the migration properly, with a complete list and a complete redirect map, at a cost that a small site can afford.

The rules about search have not changed. Google's documentation on site moves with URL changes still asks for a URL mapping, permanent server-side redirects from each old URL to its new one, a new sitemap, and monitoring in Search Console while the move settles. What has changed is who does the mechanical work.

The method in one list

Decide whether to move at all.
Build a content inventory: one row per old URL, with traffic, and a decision for each.
Decide what the new site can keep at the same path, and reproduce those paths.
Export what the old platform allows, import what the new one can, and have the agent read the live site for the rest.
Rebuild the site as a draft, with site-wide noindex on, from the inventory.
Write the redirect map as a CSV from the inventory's old and new URL columns.
Test the targets, import the redirects, point the domain, turn noindex off, publish.
Submit the sitemap, test the top old URLs, and watch the Page indexing report for a month.

The sections below follow the same order, and each ends with the post that covers it in detail.

Whether to migrate at all

Oil painting of an old tree with deep roots standing firm while the sky behind it turns from navy through mauve to peach and coral — Some sites should stay where they are. That decision comes before the build.

The agent makes the build cheap. It does not make the move cheap. A site should stay where it is when it is really an app with user accounts, a members area or a custom database; when the store is large and integrated; when the old URLs carry most of the business and the new platform cannot reproduce them; when one plugin does the thing the business depends on; or when the complaint is maintenance and a smaller change solves it. A business that will rebrand or change domain in six months should wait and make one move with one redirect map.

Staying is a decision, and the inventory is worth building either way. It shows what the site has, and if the answer changes later, the hard part is done.

Read When Not to Migrate.

The content inventory

Oil painting of an old wooden card-catalogue drawer pulled half open, its index cards glowing peach against a deep navy to coral dawn background — Every old URL gets a row, and every row gets a decision.

The inventory is a spreadsheet with a row per URL on the old site and the columns needed to decide its fate: title, type, word count, last updated, clicks over 12 months, inbound links, decision, new URL. The agent fills the first columns from several sources, because no single one is complete. The sitemap lists what the old platform thinks matters. Search Console lists what earns traffic. A crawl of the site finds the tag pages, archives and old files. The CMS export finds drafts and private pages.

You fill the decision column: keep, merge, rewrite or drop. The agent can propose decisions from the numbers, and the proposal is a useful sort order, but a page with two clicks a year may be the one a client reads before every renewal. Decide against the list, not from memory.

The agent also extracts every page to a folder of Markdown files, one per URL, with the old URL recorded at the top of each. That folder is both the raw material for the rebuild and the source of the redirect map.

Read Content Inventory With an AI Agent.

Getting the content out of WordPress

Oil painting of an old wooden travel chest with its lid half open, a few shapes lifting out toward peach dawn light while others stay in the navy shadow inside — From WordPress, the content travels. Most of what the plugins did stays behind.

WordPress has two ways out. The export file, from Tools, then Export, is a WXR file that per the Tools Export documentation contains posts, pages, custom post types, comments, custom fields, categories, tags, custom taxonomies, users and navigation menus, but not the image files, the theme or the plugins. And the REST API, which a builder can read directly.

On Beste, the blog takes the second route: posts are imported from the Posts panel in Studio with their content, excerpt, date, author, categories, tags and images, the images copied into the media library and the slugs kept. They arrive as drafts, and running the import again updates posts with the same slug instead of duplicating them, so you can import early and sync once more just before launch. Pages are the agent's job, because written pages travel well and page builder layouts have to be rebuilt from what the live site renders. WooCommerce is a separate migration.

Read Migrating From WordPress After PHP2Shell.

Getting the content out of Wix or Squarespace

Oil painting of an ornate birdcage with its door open and a small bird stepping out toward a peach and coral dawn, the cage itself set against deep navy — On Wix and Squarespace, the live site is the export. Read it while it is still up.

On these two platforms, the live site is the export. Per Wix's support page on exporting your site elsewhere, a Wix site cannot be moved to another host, and per its feature request page, blog posts cannot be exported to other platforms at the time of checking. CMS collections and store products export to CSV from their own panels.

Squarespace's export article describes an XML file built for importing into WordPress. It includes layout pages, one blog and text and image blocks, and excludes album, cover, index, portfolio, calendar and store pages, page headers and footers, audio, video and product blocks, drafts and styles. The same article warns that image links which still point at Squarespace stop working once the Squarespace site is cancelled.

So the method on both platforms is: the agent reads the published pages, downloads every image at full size while the subscription is active, records each page's meta title and description, and the exports fill in structured content such as products. Keep the old plan running until the images are safe and the redirects resolve from the new host.

Read Migrating From Wix or Squarespace.

The rebuild

The rebuild is the step most people think of as the migration, and with an agent it is the shortest. Two approaches, and they combine:

From a prompt. Describe the business, who the site is for and how it should feel, and get an editable draft with pages, navigation and copy about the business. Then the agent replaces the generated copy with the extracted text page by page, so the site has the old content in the new structure.
Page by page. The agent creates each page or post from the inventory with the slug set to the old path, picks sections for the content, and fills them with the text as written. Slower, and closer to the original.

Three rules for the rebuild regardless of approach. Build with site-wide noindex on, so an unfinished site is not indexed. Do not rewrite content during the migration; mark pages to rewrite and do it after launch, because Google's site move guide advises planning changes one after the other rather than all at once. And read every page before publish, because an agent reproduces what it reads, typos included. How to set those rules up for the agent is in Writing Rules for Your Website Agent, and the broader way of running a site through an agent is in the MCP guide. For a worked example of an agent doing this kind of structured, page-by-page work on a real site, with every decision kept on our side, see how we built beste.co in three languages over MCP.

The redirect map

Oil painting of a slender arched footbridge spanning from a dark navy bank on the left to a warm peach and coral dawn on the right — Each redirect is one hop from the old address to the page that replaces it.

The redirect map is the inventory's last two columns, filtered to the rows where the URL changes: old path, new path. Each row becomes a permanent redirect. Google's redirects documentation treats a permanent (301 or 308) server-side redirect as a signal that the target should become the canonical URL, recommends one whenever possible, and keeps JavaScript redirects as a last resort, because Google may never see one if rendering fails.

The rules that matter: one hop from old URL to final page, no catch-all to the home page, merged pages may share a target, dropped pages return 404 rather than redirecting anywhere, and the redirects stay in place for at least a year, ideally for as long as the site exists. The cheapest row is the one you do not need: every old path the new site reproduces exactly needs no redirect and carries no risk.

If the domain changes, the map has the same shape with targets on the new domain, and you also submit a Change of Address in Search Console after the redirects are live. Per the Change of Address help page, the tool is for domain and subdomain changes only, its effect lasts 180 days, and redirects should stay at least that long.

Read Redirect Mapping From a CSV.

Launch and the week after

Oil painting of a small lighthouse on a shoreline at the end of night, its lamp still faintly lit as the sky turns from navy through mauve to peach and coral — The month after launch is for watching and fixing rows, not for new changes.

Launch is: targets tested, redirects imported, domain pointed, noindex off, publish, sitemap submitted. The week after is: test the top 50 old URLs by hand and with the URL Inspection tool, submit a Change of Address if the domain changed, and read the Page indexing report every morning.

Old URLs should move to "Page with redirect". The 404 list should match the rows you chose to drop, and nothing else. "Redirect error" should be empty. The report's help page says a 404 is correct for a page removed without replacement and a 301 is the fix for a page that moved, which is exactly the comparison to run against the map. Fix missing rows, collapse chains, validate the fix, and change nothing else. Google's site move guide says a medium-sized site can take a few weeks or more to settle and that ranking swings in that period are expected.

Read The Week After a Migration.

How the work is spread out

Every site is different, and the inventory decides the real schedule. What does not change is the order, and where the time goes:

Phase	What happens	Who does it
Inventory	Exports from Search Console and the old platform merged into one list	Agent, from your files
Decisions	Keep, merge, rewrite or drop on every row; new URLs chosen	You
Posts	WordPress posts imported as drafts, with their images	Importer, then your read-through
Pages	Rebuilt as a draft with noindex on; meta titles carried over	Agent, then your read-through
Redirects	CSV built from the inventory and tested against the draft	Agent, checked by you
Launch	Posts synced once more, redirects imported, domain pointed, noindex off, publish, sitemap submitted	You
First month	Page indexing report every morning; missing rows added	You, with the agent comparing lists
Month three	Clicks by page compared with the old site; old platform cancelled if nothing points back	You

The agent's rows are the ones that used to take the longest. The rows that stay with you are decisions and watching, and the watching is the part people skip.

For studios doing this for clients

A migration is a project with a clear end, and with an agent doing the mechanical work it fits inside a fixed price. The inventory is the document that sets the scope: a client can see the row count and the decisions before the build starts. After launch, the client edits content and the studio keeps the redirects and the Search Console watch. An incident like PHP2Shell is also a reason to know, for every client site, who updates the server software and how fast. Who pays for the agent after launch depends on whether it runs inside the builder or on a plan someone already has; MCP Server vs Built-In AI Chat sets out the difference.

How this works in Beste

Beste is the destination in this method; the agent does the reading. Here is each step mapped to what Beste provides, and where it stops.

WordPress posts. Imported from the Posts panel in Studio through the WordPress REST API, with content, excerpt, date, author, categories, tags, the featured image and the images in the content, which are copied into the media library. Slugs are kept. Posts arrive as drafts, and a second run updates posts with the same slug rather than creating duplicates. The built-in blog then gives each post its fields and BlogPosting structured data.
Everything else. Over the MCP server, an agent in Claude, ChatGPT, Claude Code, Codex or Cursor creates pages with paths that match the old site, picks sections from the library and fills them with the extracted text. Posts from other platforms are recreated the same way. Every change lands in the draft, in batches that can mostly be undone, and nothing goes live until you ask for a publish in your own words. Reads never count toward a limit, so the agent can check the draft against the inventory as often as it needs to. A build from a prompt gives a first draft in minutes that the agent then fills with the old content.
Paths. Nested pages reproduce most old paths exactly, so most rows never become redirects.
Redirects. The rest go into a two-column CSV imported as bulk 301 redirects, with a preview of matched, duplicate and unmatched rows before anything is saved; rows without a matching page can be imported as external redirects. Single rows are added later in the editor or with add_redirect. Redirects are served by the hosting layer.
Staging. Site-wide noindex keeps the unfinished site out of search while you build, and the menu warns while it is on. On Pro, password protection lets you stage on the real domain and open the site once the redirects are in place.
Launch. The domain connects from any registrar on every plan by copying two records, with no transfer, and the certificate is issued and renewed for you, per the custom domain page. The sitemap, meta tags, OG images, structured data, hreflang for linked language versions and an /llms.txt file regenerate on every publish.
After. Hosting, HTTPS and platform updates are Beste's job, so there is no server software on your side to patch. Search Console stays on Google's side: you verify the domain there and submit the sitemap.

What it costs, plainly. A build can start on Free, which has no time limit, includes the custom domain, and allows 150 agent edits a month. A migration of more than a few dozen pages will use more than that, and redirects, password protection and analytics are Pro. Per the pricing page, Pro is $15 a month billed annually or $20 monthly, and if a Pro plan is cancelled the site stays live but redirects stop working. Keep Pro for as long as old links matter, which for a migrated site is most of its life.

What Beste does not do, so you can plan around it: there is no importer for Wix or Squarespace, only for WordPress posts; form responses cannot be exported yet; post scheduling is not available yet; and Beste builds websites, not apps with user accounts or a database. The controls for everything above are on the technical SEO page.