WordPress to Astro Migration Checklist — Every Step Before You Go Live

Why WordPress → Astro Is Worth It (And Where It Goes Wrong)

Astro ships zero JavaScript by default, so a content site that was a sluggish stack of WordPress plugins becomes a static bundle that scores 100 on Lighthouse. The trade-off: WordPress did a lot of invisible work — permalinks, redirects, sitemaps, meta tags via Yoast/Rank Math, image resizing, forms, comments. In Astro, you rebuild each of those deliberately. The migration fails when one of them is forgotten and only surfaces after DNS has already moved. The fix is a disciplined checklist plus a real-domain test before cutover.

The WordPress to Astro Migration Checklist

1. Audit & export the old site

• Crawl the live WordPress site and export the full URL list (every post, page, category, tag, attachment).
• Record current titles, meta descriptions, canonical tags, and OG images per URL — this is your SEO parity baseline.
• Export content via the REST API or to Markdown/MDX (e.g. wordpress-export-to-markdown); decide whether to keep WordPress headless or go fully static.
• Inventory dynamic features: forms, search, comments, members, WooCommerce — each needs an Astro replacement.

2. Rebuild content & routing in Astro

• Model posts/pages with content collections (src/content/) and map each to the same URL path as WordPress where possible.
• Decide trailingSlash ('always', 'never', 'ignore') to match the old permalink structure — mismatches cause 301-chains or 404s.
• Set site in astro.config.mjs to your real domain so canonical, sitemap, and RSS URLs are correct.
• Reconcile shortcodes and page-builder (Elementor/Divi) HTML by hand — they don't export cleanly.

3. Map redirects (the make-or-break step)

• For every legacy URL that changes, add a 301 — via Astro's redirects config, a host _redirects (Netlify/Cloudflare) or vercel.json.
• Don't forget query-style permalinks (/?p=123), /category/ and /tag/ bases, paginated archives, and old feed URLs (/feed/).
• Preserve /sitemap.xml and /robots.txt; submit the new sitemap in Search Console after go-live.

4. Migrate media, forms & SEO tags

• Move wp-content/uploads assets; use astro:assets / <Image> and confirm output paths resolve under the production path.
• Replace form plugins with Netlify Forms, Formspree, a serverless function, or an Astro SSR endpoint.
• Recreate per-page meta, OG/Twitter tags, and JSON-LD structured data in a shared layout; add @astrojs/sitemap and @astrojs/rss.

5. Deploy & test on your real domain — before DNS

• Deploy to Vercel, Netlify, or Cloudflare Pages and add your custom domain in the dashboard (it'll wait on DNS).
• Use TestURL.live with your domain + the platform hostname to preview the Astro build on your real domain.
• Run the visual diff, redirect-chain trace, SEO snapshot, Lighthouse, and security-header audit. Fix, re-test, then cut over.

The Pre-Cutover Verification Layer

Steps 1–4 are build work. Step 5 is where TestURL.live earns its place — it turns "looks fine in the deploy preview" into "verified on the production domain."

WordPress vs Astro — What Changes

Concern	WordPress	Astro
Rendering	PHP per request	Static HTML (or SSR adapter)
SEO tags	Yoast / Rank Math	Layout component + @astrojs/sitemap
Redirects	Plugin / .htaccess	redirects config / _redirects / vercel.json
Forms	CF7 / Gravity Forms	Netlify Forms / Formspree / SSR endpoint
Images	Media library resizing	astro:assets / <Image>
Hosting target	IP / cPanel	Vercel / Netlify / Cloudflare hostname

Related Guides & Tools