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

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.

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

:

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

// 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. 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.

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.