Migrate WordPress to Astro.js: The SEO-Safe Way (2026)

The Migration That Either Doubles Your Traffic or Kills It

WordPress-to-Astro migrations follow a bimodal outcome pattern. Sites that do it carefully — with full URL mapping, redirect implementation, and a pre-launch SEO audit — typically see organic traffic increase within 60–90 days as Google registers the performance improvements. Sites that rush it, skip the redirect work, or change URL structures without planning lose 30–70% of their organic visibility overnight.

The technical difference between the two outcomes isn’t complicated. But it requires discipline that most agencies and developers skip because it’s unglamorous work: spreadsheets, redirect lists, and systematic validation rather than design and code.

This guide covers everything that actually needs to happen — in order.

Why Businesses Migrate Away from WordPress

Before the technical process, it’s worth being clear about what’s motivating the move. The most common reasons we see:

Performance debt that plugins can’t fix. A WordPress site that started with 5 plugins now has 40. Each plugin adds JavaScript, database queries, and potential conflicts. The caching setup that worked two years ago is now fighting with the new analytics plugin, the accessibility plugin, and the form plugin all simultaneously. Performance scores have drifted from 60 to 30, and no individual fix solves it.

Security incidents or constant vulnerability patches. According to Patchstack’s WordPress Vulnerability Report 2024, 97% of WordPress vulnerabilities originate in plugins. A clinic website handling patient inquiries cannot afford to run outdated plugins, but maintaining update discipline across 30+ plugins is a real operational burden.

Hosting and maintenance costs that keep climbing. Managed WordPress hosting with adequate performance runs Rp 500,000–2,000,000/month in Indonesia. Astro + Cloudflare Pages runs at zero variable cost for most clinic-scale traffic volumes.

The maintenance loop. WordPress requires constant attention: core updates, plugin updates, backup verification, security scans, database optimization. The technical overhead accumulates — and the business is paying someone to manage it, whether that cost is visible or not.

What a Migration Actually Involves

A WordPress-to-Astro migration has five distinct phases. Each one has specific deliverables. Skipping any phase moves risk to the next.

Phase 1: Content Audit and Inventory

Before writing a single line of Astro code, you need a complete map of everything currently on the WordPress site that Google knows about.

Run a full crawl using Screaming Frog or Ahrefs to export:

• Every indexed URL (not just pages — posts, taxonomy pages, author archives)
• Each URL’s current title, meta description, H1, word count, and inbound link count
• The canonical URL for each page
• Any hreflang declarations if the site is multilingual

Sort this list by organic traffic and backlink count. Pages with significant traffic or external backlinks are your highest-priority migration assets. Pages with zero traffic, no backlinks, and duplicate content are candidates for consolidation or removal — but that decision happens explicitly, not by accident.

Separately, export the WordPress sitemap and cross-reference it with Google Search Console’s performance data. The intersection of “indexed by Google” and “receives organic clicks” is your non-negotiable preservation list.

Phase 2: URL Structure Decision

This decision has the highest stakes in the entire migration. There are two options:

Option A: Preserve the existing URL structure exactly. Every URL in Astro matches the WordPress URL. No redirects needed. Zero SEO risk from URL changes. This is almost always the right choice for pages with existing traffic and backlinks.

Option B: Change some URLs as part of the migration. This can make sense when the WordPress URL structure is genuinely problematic — for example, /2014/03/12/dentist-jakarta/ instead of /blog/dentist-jakarta/. Date-based URLs rarely serve the content well for evergreen pages. If you’re going to make URL changes, this is the time — but every change requires a 301 redirect.

Our recommendation: preserve URLs for anything ranking. Clean up URL structure only for pages that have zero traction.

Phase 3: Building the Astro Project

With the audit complete and URL structure decided, building the Astro site can begin. For a clinic landing page migration, the typical Astro project structure:

src/
├── pages/
│   ├── index.astro          ← Homepage (preserves /)
│   ├── blog/
│   │   └── [slug].astro     ← Dynamic blog routes (preserves /blog/[slug]/)
│   ├── privacy-policy.astro
│   └── terms-of-service.astro
├── content/
│   └── blog/                ← Markdown files for each WordPress post
├── components/
│   ├── Header.astro
│   ├── Footer.astro
│   └── SEO.astro            ← Centralized meta/canonical/hreflang
└── assets/
    └── images/              ← Optimized WebP versions of WordPress media

Each WordPress post becomes a Markdown file in src/content/blog/ with a frontmatter block containing the title, date, excerpt, and canonical URL. Astro’s content collection system handles the rest.

WordPress images need to be re-optimized. Export the original uploads, convert to WebP/AVIF using Sharp or a build-time processing script, and import into Astro’s asset system. Do not hotlink to the WordPress media library — once WordPress is decommissioned, those URLs break.

Phase 4: Redirect Implementation

Every URL that changes — or any WordPress URL that you’re retiring — needs a 301 redirect to its Astro equivalent.

For sites hosted on Cloudflare Pages (our standard), redirects are implemented in the _redirects file:

## WordPress to Astro redirects
/old-url/    /new-url/    301
/tag/*       /blog/       301  # Collapse tag archives
/?p=*        /blog/       301  # WordPress URL legacy format

Build the redirect map as a spreadsheet first:

Old URL (WordPress)	New URL (Astro)	Redirect Type	Notes
/services/	/layanan/	301	URL cleanup
/dr-sarah/	/tim-dokter/#dr-sarah	301	Consolidated
/contact-form/	/#kontak	301	Removed standalone page

Test every redirect before launch using a tool like Redirect Checker or cURL. A broken 301 is as damaging to SEO as a missing page.

Phase 5: Pre-Launch SEO Validation

The pre-launch validation checklist should be completed on a staging URL — ideally blocked from Google with robots.txt Disallow: / or X-Robots-Tag: noindex until the review is complete.

Validate before launch:

• Every high-traffic URL renders correctly and returns 200
• Every redirect in the list returns 301 (not 302)
• Canonical tags are self-referencing on all pages
• Hreflang declarations are correct for multilingual sites
• XML sitemap is accurate and includes only canonical URLs
• Robots.txt is correct (no accidental Disallow)
• Title tags and meta descriptions match WordPress originals (or intentional improvements)
• H1 tags are present and correct on every page
• Internal linking preserved from WordPress structure
• Google Analytics and Tag Manager firing correctly
• Schema markup validating in Google Rich Results Test
• PageSpeed Insights scoring 90+ on both mobile and desktop

This list takes half a day. Skipping it has cost sites months of recovery.

Common Mistakes That Destroy Rankings Post-Migration

These are the actual failure patterns we see in migrations that went wrong:

Launching without redirect maps. The single most common cause of post-migration traffic collapse. Old WordPress URLs still indexed by Google return 404 after launch. Google sees the 404, marks the URL as invalid, removes it from the index, and transfers zero equity to the new URL.

Changing URLs without redirects “to clean up the structure.” Removing date prefixes, adding category paths, or changing slug formats sounds reasonable — and SEO-neutral if you set up redirects. But in practice, redirects are often partial or incorrect, and the result is lost rankings.

Not submitting the new sitemap immediately post-launch. After launch, submit the sitemap URL directly in Google Search Console and request indexing of the highest-priority pages. This accelerates the time Google takes to discover and verify the migration.

Carrying over noindex tags accidentally. WordPress development environments often have a “Discourage search engines from indexing this site” checkbox that was checked during development and never unchecked. Verify that no noindex meta tags are appearing on canonical pages post-launch.

Losing internal link anchor text. WordPress block editor content often contains internal links with specific anchor text that has accumulated SEO value. When converting to Markdown, verify that every internal link in the content is preserved in its new format.

What Improves After a Successful Migration

Sites that migrate carefully see consistent improvements across several dimensions within 3–6 months:

Core Web Vitals pass rate. Moving from a WordPress Elementor build to Astro typically improves LCP by 70–80%, CLS by 90%, and Total Blocking Time from 1,000ms+ to under 50ms. Google’s Search Console Core Web Vitals report will reflect these improvements within 28 days (the assessment window).

Crawl efficiency. Static Astro pages are significantly faster for Googlebot to crawl than WordPress pages that require PHP execution. Sites with large content libraries may see crawl frequency increase as a result — which can accelerate indexing of new content.

Hosting cost reduction. Cloudflare Pages hosting for static Astro sites is free for most clinic-scale traffic. Compared to managed WordPress hosting, this represents Rp 500,000–2,000,000/month in direct savings.

Security posture. With no PHP, no WordPress admin, no plugins, and no database, the attack surface effectively disappears. There’s no wp-admin to brute force, no xmlrpc.php to exploit, no plugin CVEs to patch.

Should You Migrate or Rebuild?

One distinction worth making: a migration preserves existing URLs and content. A rebuild starts fresh — new URL structure, new content strategy, new information architecture.

If your WordPress site has significant organic traffic — more than 2,000 monthly visits — migration is almost always the right choice. You have SEO equity to preserve, and a rebuild risks losing it.

If your WordPress site has minimal organic traffic, receives most visitors from paid ads, and you’re planning to redesign the content strategy anyway — a clean rebuild on Astro may be more efficient than a careful migration of underperforming content.

Most clinic sites fall somewhere in between. The right approach is to migrate the pages that have accumulated rankings, and rebuild the architecture and content strategy around them.

The Migration vs. Maintaining WordPress

There’s a real cost to staying on WordPress that compounds over time. Every month of maintenance work, every plugin update, every security incident, every hosting invoice is a cost. Over 3 years, for a typical clinic site:

Cost Category	WordPress (3-year estimate)	Astro + Cloudflare (3-year estimate)
Hosting	Rp 18,000,000–72,000,000	Rp 0 (Cloudflare Pages free tier)
Developer maintenance	Rp 36,000,000–84,000,000	Rp 3,000,000–12,000,000
Plugin licenses	Rp 3,000,000–18,000,000	Rp 0
Security incidents	Rp 5,000,000+ (unpredictable)	Rp 0 (no attack surface)
Total	Rp 62M–174M	Rp 3M–12M

These are real cost differences, not hypothetical. The migration investment pays for itself within months.

For clinics interested in seeing the performance difference concretely, our portfolio of 14 clinic and SMB implementations includes performance benchmarks for each. For the technical architecture details, see our full stack comparison.

References

1. Patchstack: State of WordPress Security 2024 — 2024
2. Google Search Central: 301 Redirects and SEO — 2024
3. Google Search Console: Core Web Vitals Report — 2024
4. Astro Documentation: Content Collections — 2024
5. Google Search Central: Site Migrations — 2024
6. Cloudflare: Pages Redirects Documentation — 2024
7. HTTPArchive Web Almanac: CMS Performance 2024 — 2024