DEV Community

Eduardo Villão
Eduardo Villão

Posted on

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

#wordpress #ai #webdev #astro

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.

Why Cloudflare Pages

A few reasons it won over Vercel, Netlify, and GitHub Pages for this project:

  • Global edge network with zero cold starts
  • Free tier is genuinely generous — unlimited requests, unlimited bandwidth
  • Cloudflare Workers for any dynamic logic that survives the migration
  • D1 for lightweight database needs if they come up later
  • Everything in one ecosystem

If you're already on Cloudflare for DNS (most people are), the migration path is shorter than it looks.

The stack after migration

  • Static site generator: Astro — outputs pure HTML, partial hydration for any interactive component, excellent build performance
  • Hosting: Cloudflare Pages
  • Forms: FormRoute — more on this later
  • AI used: Claude for content transformation, component generation.

Step 1 — Export and inventory the WordPress content

First step: understand what you actually have.

# Export everything from WordPress
# Admin → Tools → Export → All content
# Downloads an XML file
Enter fullscreen mode Exit fullscreen mode

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:

  1. List every post and page with title, slug, date, and category
  2. Identify which content was actively trafficked vs stale
  3. Flag any posts with embedded shortcodes that would need manual attention

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.
Enter fullscreen mode Exit fullscreen mode

Step 2 — Convert content to 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.
Enter fullscreen mode Exit fullscreen mode

For 80% of posts, the output was clean and ready to use. The remaining 20% had:

  • Contact form shortcodes ([contact-form-7]) — needed replacement
  • Gallery shortcodes ([gallery ids="..."]) — needed manual rebuild
  • Plugin-specific shortcodes — varied by plugin

The shortcode problem is where most WordPress migrations get stuck. More on the form replacement below.

Step 3 — Set up Astro on Cloudflare Pages 

npm create astro@latest my-site
cd my-site
npx astro add cloudflare
Enter fullscreen mode Exit fullscreen mode

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(),
})
Enter fullscreen mode Exit fullscreen mode

For a pure static site, output: 'static' is what you want. No server-side rendering, no cold starts, pure HTML at the edge.

Step 4 — Migrate content and assets

I asked Claude to generate a migration script that:

  1. Read the WordPress XML export
  2. Created individual .md files for each post with proper frontmatter
  3. Renamed media files to a clean slug-based convention
  4. Updated internal image references in the content 
// 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)
  )
}
Enter fullscreen mode Exit fullscreen mode

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.

Step 5 — The forms problem

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"]
Enter fullscreen mode Exit fullscreen mode

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>
Enter fullscreen mode Exit fullscreen mode

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.

Step 6 — Redirects

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

You'll need to map each ID to its slug manually or via a script — Claude can generate that script from the XML export.

What broke (honest list)

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 result

  • Build time: under 10 seconds
  • Time to first byte: under 50ms globally (Cloudflare edge)
  • Lighthouse score: 98–100 across the board
  • Hosting cost: $0 (Cloudflare Pages free tier)
  • Maintenance: zero PHP, zero plugin updates, zero server patches

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.

Summary — what AI helped with

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.

Resources

Top comments (0)