When it makes sense to migrate from WordPress to Astro

01 / Decision

When Astro can be a better fit

02 / Inventory

Before redesigning anything: inventory the real WordPress site

A safe migration starts with a list of everything that exists and everything that receives traffic. Copying the navigation is not enough. Inventory public URLs, content, media, forms, taxonomies, redirects, canonicals, structured data, users and every feature that depends on plugins.

• Separate editorial pages, commercial entries, categories, archives, attachments and endpoints; do not assume every legacy URL deserves an equivalent page.
• Mark URLs with external links, impressions or traffic before deciding whether to preserve, redirect or return a real 404.
• Identify actual dynamic features: accounts, comments, forms, payments, search, memberships, automation and integrations.
• Keep an old → new URL map and test it against the candidate build before switching the domain.
• Do not automatically copy scripts, commercial schemas, shortcodes or plugin data when the feature they represented no longer exists.

03 / URLs and SEO

SEO is protected by URL equivalence, not by the framework

Replacing WordPress with Astro does not require changing URLs. If a URL keeps the same content and intent, preserving it avoids an unnecessary SEO migration. When a URL must change, Google recommends preparing a mapping and using permanent server-side redirects to the final destination while avoiding chains. Canonicals, sitemaps, internal links and real 404 responses should also be verified on the new site.

04 / Real case

Real case: Mi Casa Autosuficiente

For Mi Casa Autosuficiente, migration was treated as an architecture and scope decision rather than a mechanical WordPress copy. The public surface was inventoried, editorial content was separated from commercial functions that should no longer appear active, and the primary domain was only considered migrated after the candidate build and Hostinger HTTPS delivery were verified.

• The primary domain now serves Astro with an editorial architecture focused on energy, urban gardening and water.
• Practical tools that do not require a server run directly in the browser.
• The migration distinguished between preserving a useful URL, redirecting it and retiring it; legacy content was not republished by default.
• Publishing is validated through build, navigation/SEO checks and a smoke test against the real HTTPS deployment, not only a local compilation.
• The public portfolio page shows the current result; migration operations live in technical documentation such as this guide.

05 / Checklist

Checklist before cutover

1. 01

   Inventory every public URL and feature before building the replacement.

2. 02

   Decide what stays, redirects or retires, with an explicit reason for each case.

3. 03

   Compare titles, canonicals, metadata, sitemap, robots and internal links in the candidate.

4. 04

   Test mobile, forms, tools, 404s and assets on a real staging host.

5. 05

   Switch production only when you can verify the exact deployed revision, then monitor Search Console after cutover.