AI to WordPress Migration: What Must Survive the Move

Before anything else: freeze a reference

Every migration should start by capturing what currently exists, because the original becomes unavailable the moment the platform subscription lapses. Record a full crawl of live URLs with their status codes, a copy of every page's rendered HTML, a full-page screenshot at three viewport widths, and an inventory of media files with dimensions and alt text. This reference set is what you test against later; without it, "does the new site match" becomes a matter of opinion.

Capture analytics and search data too. The twenty pages that carry most of the traffic deserve pixel-level attention; the long tail rarely does. This triage is what keeps a migration finite. The website conversion overview describes the same preparation phase from the tooling side, and the list of common migration mistakes is worth reading before you start rather than after.

Preserving layouts

Layout loss is the most visible failure and the most avoidable. Generated sites express layout in one of three ways: utility classes compiled at build time, a class-based stylesheet, or inline styles produced by a visual canvas. Each requires a different approach.

Utility-class output should generally be compiled once and shipped as a single theme stylesheet, rather than reproduced by hand. Class-based stylesheets, such as those Webflow exports, can often be carried across almost unchanged and simply enqueued by the theme. Inline canvas styles are the difficult case: absolute positioning that looks correct at the design width collapses at other sizes and has to be re-expressed as flexible layout before it becomes a template.

Work from the outside in. Establish the page container, the grid and the vertical rhythm first, then place sections, then components. Rebuilding a page component by component without first fixing the spacing system produces a site that is subtly wrong everywhere. When something does break, the guide to fixing broken layouts catalogues the usual causes. Framework-specific structure is covered in our React to WordPress guide and, for static output, the HTML to WordPress conversion reference.

Preserving images

Images fail quietly. A migration that moves files but drops alt text, loses the original resolution, or changes filenames without redirects will pass a visual review and still damage accessibility and image search traffic.

• Move originals, not the resized versions the old platform served.
• Preserve alt text verbatim; it is content, not configuration.
• Keep filenames and paths where possible, and redirect them where not.
• Re-declare intrinsic width and height so layout shift stays near zero.
• Generate modern formats such as WebP or AVIF at build or upload time, with a fallback.
• Lazy-load everything except the hero image, which should load eagerly.

The operational detail — sizes attributes, srcset generation, compression targets — is documented in the WordPress image optimisation guide, and the wider performance envelope in the speed optimisation documentation.

Preserving SEO

Search visibility is an accumulated asset, and a replatform is the single most common way to destroy it. Three mechanisms do almost all the damage: URLs that change without redirects, metadata that is not carried across, and structured data that is quietly dropped.

Build a redirect map before you build the site. Every URL in the old crawl gets a row: it either survives unchanged or has a named destination. Redirect chains should be collapsed to a single hop, and blanket redirects to the homepage should be treated as a bug, because search engines interpret them as soft 404s. Then verify titles, meta descriptions, canonical tags, robots directives, Open Graph tags, XML sitemap coverage and internal anchor text page by page for the priority set.

Our editorial treatment is in preserving SEO during website migration. For the operational checklist, use the post-migration SEO checklist, the ranking preservation guide and the SEO migration checklist for AI-built sites.

Preserving navigation

Navigation encodes an information architecture that was probably argued over for weeks. In a generated site it may be hard-coded in a component; in WordPress it becomes a managed menu. Reproduce the hierarchy exactly — order, nesting depth, labels, active states and any mega-menu grouping — before anyone is tempted to "improve" it. Improvements are a separate project with their own measurement.

Do not forget the navigation that is not in the header: footer link groups, breadcrumb trails, in-content cross-links, related-content blocks and pagination. These carry both usability and internal link equity. Breadcrumbs in particular should be re-created with structured data, as described in the WordPress structured data guide.

Preserving responsive design

Test every breakpoint the original supported, not just the two you remember. Generated sites frequently include intermediate rules that only appear between 900 and 1100 pixels, or orientation-specific behaviour on tablets. A conversion that only checks phone and desktop will ship a broken middle.

Pay specific attention to navigation collapse thresholds, image art direction, typographic scale, table overflow behaviour and any element positioned absolutely. Touch targets and focus order should be verified with the keyboard as well as the mouse — see the WCAG accessibility guide and the responsive design documentation.

Preserving assets

Assets are everything that is not a page: fonts, icon sets, downloadable PDFs, video files, favicons, manifest files, verification files and any legacy documents linked from old posts. These are the items most often left behind, because they are not visible in a page-by-page review.

Enumerate them from the crawl rather than from memory, and keep their addresses stable. For a research or publishing site, a PDF URL is frequently cited in other people's work, which makes it a permanent identifier whether or not you intended it to be. Self-hosting fonts, rather than relying on the previous platform's CDN, also removes a dependency and usually improves performance. Storage and delivery choices are covered in the hosting guide, and integrity checks on downloaded exports in the export security notes.

Preserving metadata

Metadata is the machine-readable half of a website and the half nobody screenshots. It includes per-page titles and descriptions, canonical URLs, language and hreflang declarations, Open Graph and Twitter Card tags, schema.org structured data, publication and modification dates, author attribution and taxonomy assignments.

In a generated site much of this is absent or hard-coded, so migration is the moment to establish it properly: a title pattern per template, a description field that editors actually fill in, structured data emitted from real content rather than pasted, and dates preserved from the original publication rather than reset to the import date. Resetting dates is a small mistake with a real cost — it tells search engines an eight-year archive was all published yesterday. The content-to-CMS migration guide covers field mapping, and the custom post types documentation covers where those fields should live.

Platform-specific starting points

The seven concerns above are universal, but the first steps differ by source technology. Our internal companions are the React path, the Next.js rendering discussion, the Framer export and Webflow conversion piece, the Lovable migration and code-quality analysis, and the static HTML article. A full index sits in the learning resources library, with platform reviews in the AI builders comparison.

On the technical documentation side, start from the AI to WordPress migration documentation and branch to the relevant converter: React, Next.js, Framer, Lovable, Webflow or static HTML. Teams weighing an automated versus hand-built approach should read the manual versus automated conversion analysis.

A verification routine worth keeping

Before launch: crawl the staging site and compare the URL inventory against the reference crawl; diff titles and descriptions; confirm every redirect returns a single 301; validate structured data; run a performance measurement on the five highest-traffic templates; and review each of those templates at four viewport widths with the keyboard only.

After launch: watch server logs for 404s daily for two weeks, monitor index coverage, re-submit the sitemap, and keep the old platform available in read-only form for at least a month. Nothing exposes a missed asset faster than a real 404 log. Ongoing measurement is covered in the performance monitoring guide, and staging practice in the staging environment documentation.