WordPress to Astro: 4,000 Posts, 0 Plugins

Cloudflare's cache-hit ratio had fallen from 65.7% (Sep 2025) to 4.2% (Aug 2026). Every one of the top 151 pages I checked came back cf-cache-status: DYNAMIC, with no Cache-Control header at all. A bot flood in August 2026 (19,000 threats, 6x normal request volume) landed straight on PHP with nothing in front of it.

Our gaming content, mostly Roblox codes and the biggest slice of the site's traffic, scored mobile performance 25 to 66, LCP up to 7.3s, CLS up to 0.32, and TBT up to 4,520ms. Accessibility was pinned at 83 on every article: one bug in the shared layout, repeated 4,000 times.

Median HTML was 220KB with 11 external scripts per page, on a site that is mostly a code list and a paragraph of text. Bing's crawler recorded the top article at 219KB. Traffic reflected all of it: pageviews fell from 107,000/month (Sep 2025) to 41,000/month (Aug 2026).

Every part of a WordPress install is something to patch: core, the theme, and each of the 32 plugins ships its own vulnerability stream and its own update. Skip one and you own the risk. Someone still has to keep the server online, the PHP version current, and the database backed up, forever. Static removes the whole category instead of managing it.

This is the only chance to get "before" numbers. Do it all on the same day.

• GA4 export: monthly pageviews, sessions, users, ad revenue for 12 months. By country, device, channel for 3 months. Engagement rate, bounce rate, pages/session.
• GSC export: monthly clicks/impressions/CTR/position for 16 months. Per-page clicks (all pages, not just top N). Per-query (top 200 + branded split). By country, device.
• GSC manual exports (no API): Page Indexing report, Core Web Vitals report, Links report, Enhancements (FAQ/HowTo/Breadcrumb counts), manual actions.
• AdSense: monthly earnings and RPM per domain.
• Bing Webmaster: monthly stats, crawl stats, pages in index.
• Lighthouse: mobile + desktop on one URL per page type, 3 runs each, take the median.
• Full URL inventory from all sitemaps.
• Per-page SEO snapshot: status code, title, description, canonical, robots, H1, schema types, word count, image count, internal links, script count, HTML bytes, TTFB, cache headers.
• robots.txt and ads.txt content.
• Cloudflare/CDN: cache-hit ratio, analytics, zone config.
• Plugin list with what each one does.
• Redirect table (Rank Math or whatever manages your redirects).
• Comments export (REST returned 403 for me; export from the DB or admin instead).
• Media library size (du -sh on uploads).
• Hosting cost per month.
• Screenshots of each page type, mobile and desktop.

Every URL gets one of: keep (same path), 301 (to what), 410 (gone), noindex (exists, not for search).

• Collect URLs from: sitemaps, GSC (any page with impressions in 16 months), Bing index, the existing redirect table, an internal-links crawl, hot-linked /wp-content/uploads/ images, feeds, pagination, tag/author/date archives, ?replytocom, ?s=, attachment pages, AMP.
• Write a url-map.csv with one row per URL and its decision.
• Decide the zero-click posts now. Pruning after the move confounds measurement.
• Carry all existing redirects as-is. 44 of my top 150 pages were redirects already, almost all pointing at one how-to page.

• WP REST API: posts, pages, media, categories, tags, users, with _embed.
• Store raw JSON first, transform second. You will re-run the transform.
• Keep: slug, real date (not the bumped sitemap lastmod), modified, status, categories, tags, author, excerpt, featured image, SEO plugin meta (title, description, canonical, robots, focus keyword).
• Parse block content for FAQ/HowTo. Rank Math stores FAQ and HowTo as block JSON, not rendered HTML. Parse the blocks, not content.rendered. This cost me days.
• Convert HTML to Markdown/MDX. Keep headings, tables, code, and lists as close to the original as possible. Normalize the wp-block-* wrappers away.
• Download original images, upload to your CDN, record width and height, rewrite URLs.
• Verify: post count in the export = REST total minus decided exclusions. Randomly sample 20 posts and diff them visually against live.

For every page type, reproduce from frontmatter:

• <title>, meta description, canonical (self, absolute, include www), robots meta.
• OpenGraph + Twitter card, og:image at the same aspect ratio.
• JSON-LD schemas: Organization + WebSite + BreadcrumbList on every page, Article + FAQPage on content pages.
• Sitemap with real lastmod dates (not the bumped WordPress ones).
• robots.txt identical plus the new sitemap URL.
• RSS at the same path (/feed/).
• Redirect file from url-map.csv. 301 for moves, 410 for gone.
• Trailing-slash policy identical to WordPress.
• www canonical host, apex redirects to www, HTTP to HTTPS.
• Every <img> has width, height, and alt. Fonts self-hosted, preloaded, font-display: swap.
• Ad slots reserved with a fixed min-height (prevents CLS).
• Analytics: same GA4 property, same AdSense publisher ID, ads.txt byte-identical.

• Redirect test: request every URL in url-map.csv on preview, assert status and final URL. Zero failures.
• Parity diff: run the Step 0 snapshot script on preview. Diff per URL: title, description, canonical, robots, H1, schema types, word count (within 10%), image count. Every difference explained or fixed.
• Crawl: zero 4xx internal links, zero redirect chains, zero pages without a canonical.
• Schema: Rich Results Test on one URL per page type.
• Lighthouse: same URLs as baseline, mobile + desktop.
• Sitemaps: URL count = keep-count from url-map.csv.
• Ads render on preview with test mode. GA4 debug view receives page_view.
• Feed validates. 404 returns a real 404 status.

• Lower DNS TTL 24 hours before.
• Deploy the final build. Switch DNS.
• Keep WordPress alive on a different hostname, noindex, basic auth, 30 days.
• Same day: submit the sitemap in GSC and Bing, request indexing on the top 20 pages.
• Same day: create a search-console annotation marking the cutover, naming the commit that shipped it.
• Turn off WP cron, mail, and scheduled publishing (prevents redirect loops).

Daily for 14 days, weekly after:

• GSC Page Indexing: watch "Not found (404)", "Redirect error", "Duplicate, Google chose different canonical".
• GSC Performance: clicks and impressions vs the same weekday in the previous 4 weeks. A dip under 10% in week 1 is normal. Over 20% on a top-50 page: investigate that page's redirect and canonical the same day.
• Bing: crawl errors, pages in index.
• Server logs/analytics: top 404 paths. Add redirects for any path with real hits.
• CWV field data: the GSC CWV report should flip from poor to good over 28 days.
• AdSense: impressions per pageview and RPM. Watch for policy flags on new page layouts.
• GA4: engagement rate and pages per session. A drop means broken internal links or slow ads.

• After 30 clean days: snapshot the WP database + uploads to cold storage.
• Destroy the VPS (or repurpose it).
• Remove old DNS records and old Cloudflare rules.
• Keep the old GSC property for historical data.

2,999 of the 3,000 WordPress posts carried a 2026 lastmod. Some plugin was bumping the modified date on every post. Search engines learn to ignore that. The new build emits real dates, but I did not catch this until after I had trusted lastmod as a "recently updated" signal. Verify your dates against the actual post edit history before migrating.

Rank Math stores FAQ and HowTo schema as WordPress block JSON embedded in post_content. It is not in content.rendered, and it is not in a separate meta field in the REST API. Parse the rendered HTML and you lose all structured data. I had to go back and re-parse the raw block content for every post that used those blocks.

The WordPress REST API returned 403 on the comments endpoint. Not documented, not obvious. I exported the 55 comments through the database instead. Check the endpoint on day one, not the day you need it.

44 of my top 150 GSC landing pages 301'd to a single how-to page (the old torrent-proxy posts). Google kept ranking the old URLs for months after the redirect was set. Every one of those redirects had to be carried into the new site exactly, because missing even one means a sudden 404 on a page Google is still sending traffic to.

"Under Attack" era firewall rules were still active long after the bot flood. Audit and drop them as part of the move. They add latency and break legitimate clients.

Astro's render() reads from the filesystem. You cannot pass it a modified body. Any content transformation (stripping sections, rewriting markup) has to happen either in the CMS or after render. I tried to strip FAQ sections from article bodies at build time to render them as accordions instead. It silently produced empty output. The fix is to store the body in the shape you actually want.