WordPress to Astro migration with preserved SEO

Do you recognize any of these symptoms?

Most of those who migrate do not arrive out of love for technology, but because of a concrete pain that keeps recurring. If any of these sound familiar, the problem is probably not your site specifically, but the platform it is built on.

"My site loads slowly and I can't fix it." It is the most common symptom and it has a basis in the data: in field measurements, WordPress sites pass the load threshold (LCP) only around 54% of the time, and the full set of Core Web Vitals on mobile around 46%. Every plugin you installed to solve something added JavaScript that today competes to make your site slower. On a modern static site that problem disappears at the root, it is not "optimized": it is eliminated.

"I got hacked, or I live in fear it will happen." It is not bad luck or carelessness on your part. WordPress sites receive on the order of 90,000 attacks per minute globally, and around 97% of vulnerabilities are not in the WordPress core but in the third-party plugins and themes that make it functional. A static site has no database to inject or public admin panel to attack: the attack surface is radically smaller.

"I pay maintenance every month and it never ends." Updates, patches, plugin conflicts, things that break on their own: WordPress maintenance is a recurring cost that does not stop. You can size yours with our total cost calculator. A well-built static site brings that cost down to a fraction, because there is much less to maintain.

"I feel WordPress has fallen behind." It is not a mere perception. WordPress strung together six consecutive months of market-share decline in the first half of 2026, while modern frameworks like Astro doubled their downloads in a quarter. In January 2026, Cloudflare —a large-scale internet infrastructure company— acquired the company behind Astro, which gives the stack long-term backing. The professional industry is moving, and the migration is how you get on that change without losing what you already built.

If you identified with one or several, the rest of this page explains how the migration is done well, with what guarantees and at what price. And if you are not sure migrating is right for your case, we also have an honest section on when NOT to migrate, because it does not suit everyone.

Why a well-done migration is serious work

Migrating a site from WordPress to static Astro is not exporting content to another panel. It is a technical process that has to simultaneously preserve five things: the complete URL structure (every old link must keep working or redirect correctly), the ranking earned on Google (each page must maintain or improve its position), the structured data (schema.org replicated or improved), the complete editorial content (each article, page and media), and the visitor experience (no visible downtime, no broken links, no loss of functionality).

When any of these five fails, the migration destroys years of SEO work in weeks. It is the scenario that terrifies companies with significant organic traffic and the reason many postpone migration indefinitely. The wrong conclusion is "better not to migrate"; the right conclusion is "migrate only with a methodology that guarantees preservation". Well-done migrations not only preserve SEO but typically improve it because the Core Web Vitals gains are a real algorithmic factor, and an Astro site that loads in 1 second ranks better than the same content in WordPress loading in 4 seconds.

What distinguishes a professional migration from an improvised one is the documentation before the cutover. Complete URL-to-URL mapping in a spreadsheet, exhaustive list of validated 301 redirects, inventory of replicated schema markup, baseline of Google positions captured for post-migration comparison, documented rollback plan in case something fails. Without that prior documentation, the migration is a gamble; with it, it is a predictable process with a guaranteeable result.

The six layers our migration covers

Each migration covers six technical and operational layers that work in parallel. If any is omitted, the migration is incomplete and problems appear weeks later at the most inconvenient moment.

Layer one: URL mapping and preservation. Complete inventory of every URL of the current WordPress site with its status (200 OK, 301, 404), analysis of which must remain intact and which require redirection, old-URL-to-new-URL mapping documented in a spreadsheet, generation of the redirects file for the static hosting, post-cutover validation of each redirect with Screaming Frog to confirm expected behavior.

Layer two: editorial content migration. Complete export of pages, posts, custom post types, taxonomies, images, attachments from WordPress. Conversion to Markdown with structured frontmatter or JSON according to client preference. Content integrity verification: each imported article must have the same text, the same images, the same semantic structure it had in WordPress. Import of custom meta tags (title tag, meta description) when they differ from the native title and excerpt.

Layer three: schema replication and improvement. Inventory of existing schema markup on the WordPress site (what Yoast, RankMath or similar plugins generate). Replication of each type in native Astro JSON-LD, with the opportunity to improve what was implemented sub-optimally. Validation of each schema with the Schema Markup Validator and Rich Results Test. For sites with LocalBusiness, FAQPage, Service or Article, this layer usually results in more complete and coherent schema than the original.

Layer four: performance optimization from build. Correct configuration of Astro to generate pure static HTML, automatic image optimization (WebP/AVIF formats with fallback, native lazy loading, declared dimensions), minimal JavaScript only in specific interactive components (islands architecture), critical inline CSS, strategic font preloading. The typical result is LCP under 1.5 seconds on 90% of pages, versus the typical 3-5 seconds of equivalent WordPress.

Layer five: static hosting and domain configuration. Setup of Cloudflare Pages, Netlify or Vercel as appropriate (most Panamanian projects fit in the Cloudflare Pages free tier). Custom domain configuration with DNS pointing to the static hosting, automatic SSL certificate, WWW vs non-WWW configuration, environment variables setup if applicable. A global CDN is already included with no additional configuration, which improves latency from any country that visits the site.

Layer six: post-cutover validation and monitoring. Complete crawl of the new site with Screaming Frog to detect broken links or incorrect redirects. Submission of the new sitemap to Google Search Console and Bing Webmaster Tools. Intensive monitoring of Search Console for 30 days post-launch to detect drops in impressions, clicks or positions. Weekly report during the first 4 weeks comparing pre and post migration metrics. Specific adjustments if anything moves outside the expected range.

Methodology in four phases

Each migration follows exactly the same ordered process. The phases are fixed; the scope within each varies according to the chosen plan and the complexity of the specific site.

Phase 1 — Discovery and planning (week 1). Kickoff call to understand the current site, its critical dependencies, its real editorial workflow, its existing integrations. We receive access to WordPress admin, Search Console, Analytics and current hosting. Technical inventory of the site: exact number of URLs, active plugins, custom post types, taxonomies, current schema, baseline performance metrics. At the end of this phase we deliver a documented migration plan with exact timelines, a redirects plan and a rollback plan. Discovery is free and does not oblige you to continue with the migration.

Phase 2 — Parallel construction (weeks 2 to 8 by plan). Development of the Astro site in a staging environment you can review progressively. Import of editorial content, replication of templates and design, implementation of schema markup, optimization of images and performance. Your WordPress site keeps working in production normally with no impact. Review iterations with feedback until staging approval.

Phase 3 — Cutover and launch (1 scheduled night). Cutover executed in low-traffic hours (typically Sunday between 2-5 AM Panama time). DNS change so the domain points to the new Astro hosting. Activation of all the mapped 301 redirects. Immediate verification of uptime and functionality. Sitemap submission to Search Console. The effective real downtime is 5 to 30 minutes during DNS propagation.

Phase 4 — Post-launch monitoring (following weeks by plan). Intensive monitoring for 30 to 90 days by plan. Weekly crawl of the site looking for regressions or broken links. Review of Search Console looking for drops in impressions, new 404 errors, indexing problems. Weekly report during the first month and monthly during the following ones. Specific adjustments at no additional cost within the guarantee period.

Plans and public pricing

Three plans with fixed prices and explicit deliverables. As across the rest of the site, the prices are public with no "it depends, let's talk". If your case falls outside the described ranges, we document it before starting with an explicit personalized quote.

Sites with more than 500 URLs, e-commerce with an active catalog of 1,000+ products, or cases with exceptional complexity receive a personalized quote above USD 9,000. The difference is due to additional real hours documented in discovery, not to inflating the rate.

How it compares with the rest of the market

It is worth situating the prices in real perspective. In the United States and the United Kingdom, agencies specialized in WordPress-to-Astro migration like Lucky Media or Gautam Khorana charge between USD 5,000 and USD 25,000 for equivalent work, with separate discovery between USD 1,500 and USD 5,000. In Spain, a complete web migration sits between EUR 2,000 and EUR 8,000 according to Solumize 2026. In Argentina, well-scoped technical projects start at USD 2,500 and can reach USD 20,000+ on critical migrations, according to SciData.

For Panama specifically, the few agencies that offer this service do so with no public pricing and almost always with chargeable discovery that adds USD 500-1,500 before any commitment. Our approach is the opposite: discovery always free, firm price from the first contact, written contractual guarantee, no later surprises. The difference goes beyond price: it is one of purpose. We sell migration as a defined product, not as an invitation to a continuous sale.

The SEO preservation guarantee written into the contract

The contractual clause is the concrete mechanism that backs the preservation promise. It is worth being explicit about what it guarantees exactly and what it does not.

What the guarantee does cover. Complete URL mapping documented and validated before the cutover; all 301 redirects working correctly from the moment of launch; schema markup replicated or improved relative to the original WordPress site; meta tags (title tag, meta description, Open Graph) preserved or intentionally improved; validation in Search Console during the guarantee period (60, 90 or 120 days by plan); free correction of any page that loses demonstrable ranking attributable to the migration during the guarantee period.

What the guarantee does not cover. Google algorithm changes that affect all sites in the sector (these cannot be anticipated and are not our responsibility); market or general search behavior changes (drop in sector demand, seasonality); new content published post-migration that does not rank well (that requires ongoing SEO, not migration); losses attributable to client decisions after the cutover (deleting pages, changing content massively, undoing implemented schema); losses in a period beyond the guarantee.

The guarantee is a real commitment with documented consequences, not empty marketing. In no real case since our start have we had to execute the clause because the methodology works; the fact that it is written is what obliges us to apply the methodology with no shortcuts.

What the migration does NOT include: honest limits

For the offer to be honest, it is worth being explicit about what is not in the migration. Three typical things some clients expect that are not in the scope.

It does not include significant visual redesign. The migration preserves your current visual identity with minor technical adjustments. If you want to redesign the site (new palette, new fonts, new visual structure of templates), it is a separate project quoted apart. Some clients combine migration + redesign in a single project; we do it but with an explicit unified quote, not as a hidden add-on in the migration.

It does not include new editorial content creation. We migrate exactly the content you currently have. If the migration reveals that certain pages need rewriting or that important pages are missing for SEO/AEO, we document it in the post-launch report and discuss it as a separate project or monthly retainer.

It does not include ongoing post-migration SEO. The migration ends with the preservation guarantee. If you want continuous SEO optimization, ranking of new keywords, optimized content production, the correct format is a monthly retainer of SEO, AEO/GEO or local SEO as appropriate. For clients who continue with a retainer, we discount the cost equivalent to one month of discovery from the first month of the retainer.

When NOT to migrate from WordPress to Astro

Three scenarios where honesty leads us not to recommend the migration even though we could sell it. They are the cases where WordPress remains the correct option for the business.

If you depend on critical plugins with no equivalent. Some businesses built their operation on very specific WordPress plugins: custom corporate membership systems, integrations with exotic CRMs, regulated sector plugins, very specific e-commerce with complex plugins. If removing that plugin breaks critical business operation and there is no reasonable equivalent in the Astro stack, the migration would cost more than it would save. We say so explicitly in discovery; if your case is this, we do not sign a contract.

If the editorial team is large and resistant to change with no hybrid option. If you have 10+ editors working WordPress for years, the transition costs can exceed the 3-year saving: retraining, temporary operational friction, possible loss of productivity for months. The hybrid architecture (headless WordPress + Astro frontend) mitigates this case by keeping the familiar WordPress panel for the editorial team, but if your organization has no budget for that more expensive option, pure WordPress can be pragmatic.

If the current site's horizon is less than 2 years. If the company is in the process of a merger, acquisition, complete brand reinvention, or a major change that will mean rebuilding the site soon, optimizing TCO over 3-5 years loses meaning. In those cases the right thing is to minimize the initial investment knowing the site will be replaced regardless.

The case of our own site

As across the rest of the ecosystem, it is worth being explicit about our own case so that internal consistency is proof of the recommendations. This site you are reading is built in static Astro, deploys as pure HTML on the Cloudflare Pages free tier, has no database or server code in production, and loads consistently under 1 second of LCP on any page. Any tool like PageSpeed Insights or our own speed test lets you verify it.

The previous site was on typical WordPress. The migration was executed with exactly the methodology we offer as a service: URL-to-URL mapping documented, complete 301 redirects, schema replicated and improved, cutover in low-traffic hours. The result was 100% SEO preservation in our specific case (no page lost demonstrable position during the monitoring period) plus significant improvements in Core Web Vitals that probably contributed to the positions gained afterward. It is the real case that backs what we offer as a product.