How I migrated a WordPress site to Cloudflare Pages using AI (and what broke)

A developer migrated a WordPress site to Cloudflare Pages using AI assistance, with Claude converting XML exports to Markdown and generating migration scripts. The process revealed that 80% of posts converted cleanly, while 20% required manual fixes for shortcodes like contact forms and galleries.

WordPress does everything. That's both the problem and the solution. I've spent years in the WordPress ecosystem: plugins, themes, WooCommerce, Gutenberg, the whole thing. It's a mature, powerful platform that handles complex cases really well. I'm not here to say it's bad. But with AI there's a category of site where it became overkill: landing pages, product sites, company pages, portfolios. Pages that are essentially static content with a contact form. You're running a full PHP stack, managing plugin updates, paying for server hosting, all for a page that could be pure HTML served from the edge. For those cases, I've started migrating everything. Destination: Cloudflare Pages. The process: largely AI-assisted. Here's how it went. A few reasons it won over Vercel, Netlify, and GitHub Pages for this project: If you're already on Cloudflare for DNS most people are , the migration path is shorter than it looks. First step: understand what you actually have. Export everything from WordPress Admin → Tools → Export → All content Downloads an XML file The XML export gives you posts, pages, categories, tags, authors, and media references. It doesn't give you the actual media files — those come separately. I fed the XML export to Claude and asked it to: The output was a clean inventory in about 30 seconds. On a large site this alone saves hours. Prompt I used: Here's a WordPress XML export. Give me: 1. A table of all posts: title, slug, publish date, category, word count 2. A list of all shortcodes used across the content 3. Any embedded iframes or third-party scripts you can identify Format as markdown. WordPress stores content as HTML with shortcodes mixed in. Astro wants Markdown with frontmatter. Claude handled most of this conversion automatically. Prompt for content conversion: Convert this WordPress post HTML to Markdown with Astro frontmatter. Preserve all headings, links, images, and formatting. Output the frontmatter with: title, description, pubDate, slug, tags. Flag any shortcodes you can't convert with a MANUAL REVIEW NEEDED comment. For 80% of posts, the output was clean and ready to use. The remaining 20% had: contact-form-7 — needed replacement gallery ids="..." — needed manual rebuildThe shortcode problem is where most WordPress migrations get stuck. More on the form replacement below. npm create astro@latest my-site cd my-site npx astro add cloudflare The Cloudflare adapter handles the build output format for Pages. After that, connect your GitHub repo to Cloudflare Pages and it deploys on every push. Basic astro.config.mjs : python import { defineConfig } from 'astro/config' import cloudflare from '@astrojs/cloudflare' export default defineConfig { output: 'static', adapter: cloudflare , } For a pure static site, output: 'static' is what you want. No server-side rendering, no cold starts, pure HTML at the edge. I asked Claude to generate a migration script that: .md files for each post with proper frontmatter js // Claude-generated migration script simplified import { parseStringPromise } from 'xml2js' import { writeFileSync, mkdirSync } from 'fs' import { slugify } from './utils' const xml = readFileSync 'export.xml', 'utf-8' const data = await parseStringPromise xml const posts = data.rss.channel 0 .item for const post of posts { const title = post.title 0 const content = post 'content:encoded' 0 const date = post.pubDate 0 const slug = post 'wp:post name' 0 const frontmatter = --- title: "${title}" pubDate: ${new Date date .toISOString } slug: "${slug}" ---\n\n writeFileSync src/content/blog/${slug}.md , frontmatter + convertToMarkdown content } For media, I kept the files in the Cloudflare Pages public folder and updated the references in the Markdown files. For larger sites with heavy media, R2 is worth looking at, but for most company pages and landing pages, serving assets directly from Pages is enough. Claude generated the find-and-replace script for URL rewriting. This is where every WordPress-to-static migration hits the same wall. Contact Form 7, Gravity Forms, WPForms — they all depend on PHP running on the server. Move to static and they stop working entirely. There's no server to process the submission. The options I evaluated: Write a Cloudflare Worker — possible, but you're now maintaining a backend for what is essentially a contact form. Wiring up email delivery, validation, spam protection. More moving parts than I wanted. Use a form backend service — drop one endpoint into the form, the service handles everything. No server, no maintenance. I went with FormRoute https://formroute.dev . The migration from Contact Form 7 was straightforward: Before Contact Form 7 shortcode : contact-form-7 id="123" title="Contact form" After Astro component : --- // src/components/ContactForm.astro --- <form action="https://api.formroute.dev/f/YOUR KEY" method="POST" <input type="text" name="name" placeholder="Your name" required / <input type="email" name="email" placeholder="Your email" required / <textarea name="message" placeholder="Your message" required </textarea <div class="cf-turnstile" data-sitekey="YOUR TURNSTILE KEY" </div <input type="text" name=" honeypot" style="display:none" tabindex="-1" / <button type="submit" Send</button </form <script src="https://challenges.cloudflare.com/turnstile/v0/api.js" async </script Spam protection runs via Cloudflare Turnstile, invisible to real users. Submissions go to the FormRoute dashboard and trigger an email notification. Free tier covers 1,000 submissions a month. WordPress URLs don't always match what you want for a static site. You need to redirect old URLs to new ones so you don't lose SEO or break existing links. Cloudflare Pages handles redirects via a redirects file in the public folder: /old-post-url/ /new-post-url/ 301 /category/news/ /blog/ 301 /?p=123 /post-slug/ 301 I fed Claude the old URL list and the new slug list and asked it to generate the redirects file. It handled the mapping in one pass. For WordPress sites with ?p=123 style URLs, the pattern is: /?p=:id /blog/:slug 301 You'll need to map each ID to its slug manually or via a script — Claude can generate that script from the XML export. Comments — WordPress comments don't have a static equivalent. I replaced them with nothing. If comments matter for your site, look at Giscus GitHub Discussions-based or just remove them. Search — WordPress search is server-side. Static sites need client-side search. Pagefind works well with Astro and takes 10 minutes to set up. WooCommerce — if your WordPress site has ecommerce, this migration path doesn't apply. WooCommerce requires a server. Static + Shopify Buy Button or a headless approach is the alternative. Some SEO plugins — Yoast SEO data lives in WordPress meta. The XML export includes it but you need to map it manually to your Astro frontmatter. Claude can generate the mapping script but it takes some cleanup. Plugin-specific shortcodes — anything from a plugin that isn't content countdown timers, booking widgets, interactive maps needs a replacement. There's no universal answer here — depends on what the plugin did. The AI-assisted migration took about a day of actual work for a mid-size site 80 posts, 20 pages . Without AI the same work would have taken a week — content conversion and script generation were the biggest time savings. | Task | Time without AI | Time with AI | |---|---|---| | Content inventory | 2–3 hours | 10 minutes | | HTML to Markdown conversion | 1 day | 10 minutes | | Migration scripts | 4–6 hours | 10 minutes | | Redirects file | 2 hours | 5 minutes | | Component generation | 3 hours | 20 minutes | The parts AI couldn't help with: judgment calls on what to keep, what to cut, and how to handle plugin-specific functionality. That's still on you.