{"slug": "how-i-migrated-a-wordpress-site-to-cloudflare-pages-using-ai-and-what-broke", "title": "How I migrated a WordPress site to Cloudflare Pages using AI (and what broke)", "summary": "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.", "body_md": "WordPress does everything. That's both the problem and the solution.\n\nI'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.\n\nBut 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.\n\nFor those cases, I've started migrating everything. Destination: Cloudflare Pages. The process: largely AI-assisted.\n\nHere's how it went.\n\nA few reasons it won over Vercel, Netlify, and GitHub Pages for this project:\n\nIf you're already on Cloudflare for DNS (most people are), the migration path is shorter than it looks.\n\nFirst step: understand what you actually have.\n\n```\n# Export everything from WordPress\n# Admin → Tools → Export → All content\n# Downloads an XML file\n```\n\nThe XML export gives you posts, pages, categories, tags, authors, and media references. It doesn't give you the actual media files — those come separately.\n\nI fed the XML export to Claude and asked it to:\n\nThe output was a clean inventory in about 30 seconds. On a large site this alone saves hours.\n\n**Prompt I used:**\n\n```\nHere's a WordPress XML export. Give me:\n1. A table of all posts: title, slug, publish date, category, word count\n2. A list of all shortcodes used across the content\n3. Any embedded iframes or third-party scripts you can identify\nFormat as markdown.\n```\n\nWordPress stores content as HTML with shortcodes mixed in. Astro wants Markdown with frontmatter. Claude handled most of this conversion automatically.\n\n**Prompt for content conversion:**\n\n```\nConvert this WordPress post HTML to Markdown with Astro frontmatter.\nPreserve all headings, links, images, and formatting.\nOutput the frontmatter with: title, description, pubDate, slug, tags.\nFlag any shortcodes you can't convert with a [MANUAL REVIEW NEEDED] comment.\n```\n\nFor 80% of posts, the output was clean and ready to use. The remaining 20% had:\n\n`[contact-form-7]`\n\n) — needed replacement`[gallery ids=\"...\"]`\n\n) — needed manual rebuildThe shortcode problem is where most WordPress migrations get stuck. More on the form replacement below.\n\n```\nnpm create astro@latest my-site\ncd my-site\nnpx astro add cloudflare\n```\n\nThe Cloudflare adapter handles the build output format for Pages. After that, connect your GitHub repo to Cloudflare Pages and it deploys on every push.\n\nBasic `astro.config.mjs`\n\n:\n\n``` python\nimport { defineConfig } from 'astro/config'\nimport cloudflare from '@astrojs/cloudflare'\n\nexport default defineConfig({\n  output: 'static',\n  adapter: cloudflare(),\n})\n```\n\nFor a pure static site, `output: 'static'`\n\nis what you want. No server-side rendering, no cold starts, pure HTML at the edge.\n\nI asked Claude to generate a migration script that:\n\n`.md`\n\nfiles for each post with proper frontmatter\n\n``` js\n// Claude-generated migration script (simplified)\nimport { parseStringPromise } from 'xml2js'\nimport { writeFileSync, mkdirSync } from 'fs'\nimport { slugify } from './utils'\n\nconst xml = readFileSync('export.xml', 'utf-8')\nconst data = await parseStringPromise(xml)\nconst posts = data.rss.channel[0].item\n\nfor (const post of posts) {\n  const title = post.title[0]\n  const content = post['content:encoded'][0]\n  const date = post.pubDate[0]\n  const slug = post['wp:post_name'][0]\n\n  const frontmatter = `---\ntitle: \"${title}\"\npubDate: ${new Date(date).toISOString()}\nslug: \"${slug}\"\n---\\n\\n`\n\n  writeFileSync(\n    `src/content/blog/${slug}.md`,\n    frontmatter + convertToMarkdown(content)\n  )\n}\n```\n\nFor 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.\n\nThis is where every WordPress-to-static migration hits the same wall.\n\nContact 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.\n\nThe options I evaluated:\n\n**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.\n\n**Use a form backend service** — drop one endpoint into the form, the service handles everything. No server, no maintenance.\n\nI went with [FormRoute](https://formroute.dev). The migration from Contact Form 7 was straightforward:\n\n**Before (Contact Form 7 shortcode):**\n\n```\n[contact-form-7 id=\"123\" title=\"Contact form\"]\n```\n\n**After (Astro component):**\n\n```\n---\n// src/components/ContactForm.astro\n---\n\n<form action=\"https://api.formroute.dev/f/YOUR_KEY\" method=\"POST\">\n  <input type=\"text\" name=\"name\" placeholder=\"Your name\" required />\n  <input type=\"email\" name=\"email\" placeholder=\"Your email\" required />\n  <textarea name=\"message\" placeholder=\"Your message\" required></textarea>\n\n  <div class=\"cf-turnstile\" data-sitekey=\"YOUR_TURNSTILE_KEY\"></div>\n\n  <input type=\"text\" name=\"_honeypot\" style=\"display:none\" tabindex=\"-1\" />\n\n  <button type=\"submit\">Send</button>\n</form>\n\n<script src=\"https://challenges.cloudflare.com/turnstile/v0/api.js\" async></script>\n```\n\nSpam 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.\n\nWordPress 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.\n\nCloudflare Pages handles redirects via a `_redirects`\n\nfile in the public folder:\n\n```\n/old-post-url/ /new-post-url/ 301\n/category/news/ /blog/ 301\n/?p=123 /post-slug/ 301\n```\n\nI 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.\n\nFor WordPress sites with `?p=123`\n\nstyle URLs, the pattern is:\n\n```\n/?p=:id /blog/:slug 301\n```\n\nYou'll need to map each ID to its slug manually or via a script — Claude can generate that script from the XML export.\n\n**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.\n\n**Search** — WordPress search is server-side. Static sites need client-side search. Pagefind works well with Astro and takes 10 minutes to set up.\n\n**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.\n\n**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.\n\n**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.\n\nThe 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.\n\n| Task | Time without AI | Time with AI |\n|---|---|---|\n| Content inventory | 2–3 hours | 10 minutes |\n| HTML to Markdown conversion | 1 day | 10 minutes |\n| Migration scripts | 4–6 hours | 10 minutes |\n| Redirects file | 2 hours | 5 minutes |\n| Component generation | 3 hours | 20 minutes |\n\nThe 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.", "url": "https://wpnews.pro/news/how-i-migrated-a-wordpress-site-to-cloudflare-pages-using-ai-and-what-broke", "canonical_source": "https://dev.to/edu_villao/how-i-migrated-a-wordpress-site-to-cloudflare-pages-using-ai-and-what-broke-eji", "published_at": "2026-06-26 14:54:40+00:00", "updated_at": "2026-06-26 15:04:15.124125+00:00", "lang": "en", "topics": ["developer-tools", "artificial-intelligence", "large-language-models"], "entities": ["WordPress", "Cloudflare Pages", "Claude", "Astro", "Vercel", "Netlify", "GitHub Pages", "R2"], "alternates": {"html": "https://wpnews.pro/news/how-i-migrated-a-wordpress-site-to-cloudflare-pages-using-ai-and-what-broke", "markdown": "https://wpnews.pro/news/how-i-migrated-a-wordpress-site-to-cloudflare-pages-using-ai-and-what-broke.md", "text": "https://wpnews.pro/news/how-i-migrated-a-wordpress-site-to-cloudflare-pages-using-ai-and-what-broke.txt", "jsonld": "https://wpnews.pro/news/how-i-migrated-a-wordpress-site-to-cloudflare-pages-using-ai-and-what-broke.jsonld"}}