Lessons from real AI to WordPress migrations: what I wish clients knew
Practical lessons from an IT consultant who has moved many AI-built websites to WordPress: planning, surprises and what really matters.
Convert2WP – convert your AI website to WordPressClick here
Why I started writing these notes
The first time a client asked me to move a site built with an AI tool to WordPress, I assumed it would be like any other redesign. It was not. The site looked finished, the client was proud of it, and yet nobody on their team could change a single sentence without opening a chat window and asking a model to regenerate a file. That moment taught me that the real problem was never the design. It was ownership.
Since then I have done enough of these projects to notice patterns. The same questions come up, the same small surprises appear in week two, and the same decisions decide whether a project feels calm or chaotic. These notes are the conversation I now have with every client before we start.
Lesson one: the site you see is not the whole site
Clients tend to judge a site by its homepage. In practice the homepage is the easiest part. The difficult parts hide in places nobody looks at daily: a thank-you page after a form, a privacy page generated months ago, a pricing table that pulls numbers from a small database, an old blog post that still receives traffic from search engines.
My first step is always a full crawl of the live site. I export every URL, its title, its description and its status code into a spreadsheet. It is boring work and it takes an hour, but it is the single most valuable hour of the project. Without that list, something will be forgotten, and it is usually the page that brings in the most leads.
Lesson two: design converts quickly, logic does not
When I run a page through a converter such as Convert2WP, the visible result is often surprisingly close to the original within minutes. Headings, images, colours and sections arrive in WordPress as editable blocks. Clients see that and assume the project is nearly done.
Then we reach the contact form that sent data to a cloud function, the login area, or the small calculator that called an external service. None of that is converted, and it should not be. Those parts are application logic. I rebuild them with well-maintained plugins or a small custom plugin, and I estimate them separately. Being honest about this early prevents disappointment later.
Lesson three: small glitches are normal
After every conversion there are details to polish: a button that wraps differently on a narrow phone, an icon that is slightly larger, spacing that feels a bit tighter. I tell clients upfront that this is normal. Most of these issues take minutes to fix in the block editor, and some disappear by installing a single plugin.
What matters is that the structure is right: clean headings, real text in the HTML, sensible URLs and a theme that editors can work with. Pixel-perfect is a goal for the final week, not a requirement for day one.
Lesson four: SEO is decided by the server, not the browser
Many AI-built sites render their content with JavaScript. In a browser everything looks fine. But when you view the raw source, the page is almost empty, the canonical is wrong or missing, and every language version shows the same English head. Search engines read that raw response first, and some never get further.
WordPress sends complete HTML from the server. That alone often improves indexing. I still check each important page with view-source and a command-line request, because that is what a crawler actually receives. If the canonical, title and language attribute are correct there, the foundation is solid.
Lesson five: keep the URL structure boring
Every changed URL is a risk. Where possible I keep the exact same paths. Where a change is unavoidable, I add one permanent redirect from the old address to the new one and test it. I avoid chains of redirects and I never point everything to the homepage, because search engines treat that as a soft error.
For pages that truly no longer exist, I redirect to the closest relevant page. A clear redirect map, maintained for a few months after launch, catches the leftovers that appear in Search Console.
Lesson six: plan the first eight weeks after launch
Launch day is not the finish line. In the first weeks rankings often move up and down while search engines re-evaluate the site. That is normal behaviour and not a reason to panic or undo the migration. I check Search Console weekly, fix new 404s, watch Core Web Vitals and confirm that the sitemap is read without errors.
Clients who know this in advance stay calm. Clients who do not tend to change titles and structure every few days, which resets the evaluation and makes things worse.
Lesson seven: train the people, not just the site
The real benefit of WordPress appears when the team uses it. I always plan a short session where editors create a page, change an image, add a post and update a menu. I give them a one-page cheat sheet and show them where backups live. After that, the site is genuinely theirs.
If I could give only one piece of advice, it would be this: treat the migration as a move to independence. The AI tool gave you a great first version. WordPress gives you a site you can run yourself for years.