Frequently Asked Questions on AI Builders, Migration and WordPress

It is a tool that generates a working website from a description rather than from manual layout work. Some produce real source code, others produce a site inside their own hosted environment, and that difference determines how easily you can move later. See the AI website builders overview.

Choose by what you will need on the way out: a code generator if the site must be maintained independently, a hosted visual platform if design speed matters more than portability, and an application platform only for internal tools. See the choosing a builder.

Practically all of them. The output is HTML, CSS and JavaScript in some form, and that can always be expressed as a theme. What varies is how much of the editing model and dynamic behaviour has to be rebuilt. See the converting an AI website.

A small marketing site is typically one to three days including quality assurance. Sites with content collections, several languages or bespoke application logic take longer because the data model must be designed rather than copied. See the conversion approaches.

Not if URLs stay stable, changed addresses get single-hop 301 redirects, and titles, descriptions, canonical tags and structured data are carried across unchanged. See the ranking preservation.

Redirecting unmatched old URLs to the homepage. Search engines treat that as a soft 404 and the accumulated value of each page is lost. See the mistakes to avoid.

Yes wherever possible. A URL is a public identifier that other people have cited; changing it is a cost, not a refresh opportunity. See the post-migration checklist.

Move the originals rather than the resized versions the old platform served, preserve alt text and filenames, re-declare dimensions, and generate modern formats at upload time. See the image optimisation.

Everything below the fold, yes. The hero image should load eagerly and ideally be preloaded, because it is usually the Largest Contentful Paint element. See the speed optimisation.

Usually because absolute positioning from a design canvas was copied literally, or because a compiled utility stylesheet was reproduced by hand instead of being carried across. See the fixing broken layouts.

They must be inventoried from the original stylesheet, not assumed. Generated sites often include intermediate rules that only appear on tablet widths. See the responsive design.

Paid plans allow a full static export of HTML, CSS, JavaScript and assets, plus CSV exports of CMS collections. Forms, search and collection filtering stop working outside Webflow hosting. See the Webflow export.

Framer publishes to its own hosting and supports static export of the rendered result. Animations and the editing environment do not transfer and are rebuilt. See the Framer export.

Connect the project to a Git repository and clone it. You receive the complete React source tree, including components, styles and assets. See the Lovable export guide.

Both give you a downloadable project or Git sync. Build the project locally first to confirm dependencies resolve outside the hosted environment. See the Bolt.new export.

Yes, and easily, because the output is ordinary source code. Difficulty depends on the framework used rather than the assistant. See the Claude migration.

Yes. Static markup is what you see; a React application is a program whose output you see. Recovering the content model from components is the extra work. See the React migration guide.

Rendering mode matters. Statically generated routes reveal their URLs in the build output, while server-rendered and revalidated routes need an explicit decision about where freshness comes from. See the Next.js migration guide.

Only when the interface is genuinely application-like. For content sites, template rendering is cheaper to maintain and usually faster. See the REST API documentation.

Classify first — page, collection entry or shared chrome — then reproduce the paths exactly. Static conversions are predictable precisely because nothing is hidden. See the HTML to WordPress.

For content that keeps changing and must outlive its suppliers, yes: open source, self-hostable, exportable, API-accessible and supported by a large labour market. See the how themes work.

As few as you can defend. Every plugin is a dependency with an update cycle and a security surface. See the essential plugins.

Use a child theme, or a purpose-built theme you own. Editing a parent theme directly makes updates impossible. See the child theme guide.

Per-page titles and descriptions, canonical tags, sitemaps, hreflang and structured data. Migration is the moment to add them properly. See the SEO for AI-built sites.

Considerably. Importing an archive with today's date tells search engines a decade of material appeared at once, which flattens topical history. See the content migration guide.

Generated from real content fields rather than pasted into templates, so it stays accurate as pages change, and validated as part of deployment. See the structured data guide.

A well-built template site normally outperforms a client-rendered original on first load, because there is no hydration and far less JavaScript. See the performance monitoring.

Decide the URL strategy first — subdirectory, subdomain or domain — then keep hreflang relationships intact across the move. See the multilingual guide.

Automation is excellent for structure, assets and redirects, and weak at editorial judgement. Most successful projects use both. See the manual versus automated.

Connect version control on day one, keep content out of components, avoid platform-specific primitives, and confirm the export builds locally before the project matters. See the preventing lock-in.