Astro es el mejor reemplazo para WordPress en sitios con mucho contenido en 2026 -- blog, docs, páginas de marketing -- porque envía cero JavaScript por defecto y supera a WordPress en Core Web Vitals por 60-80 puntos. He migrado una docena de sitios WordPress a Astro en los últimos dos años, desde blogs personales de 50 posts hasta portales de documentación de 3,000 páginas, y los resultados son consistentemente dramáticos: tiempos de carga subsegundos, puntuaciones de Lighthouse por encima de 95, y facturas de hosting que caen de $99/mes a literalmente cero.

Esta no es una guía de "solo exporta XML y reza". Voy a guiarte a través del proceso exacto que utilizo, incluyendo los errores que te atraparán si no los planificas -- URLs rotas, imágenes faltantes, shortcodes huérfanos, y la pregunta del sistema de comentarios que confunde a todos.

Tabla de Contenidos

Por qué Astro en lugar de WordPress

WordPress está sobredimensionado para la mayoría de los sitios de contenido. Estás ejecutando PHP, MySQL, un servidor web, una capa de caché, y probablemente una docena de plugins solo para servir lo que es fundamentalmente contenido estático. Cada carga de página golpea una base de datos. Cada plugin es un agujero de seguridad potencial. Cada actualización es una oración para que nada se rompa.

Astro invierte este modelo. Pre-renderiza tus páginas a HTML estático en tiempo de compilación. Sin base de datos. Sin runtime del lado del servidor. Sin PHP. El resultado es HTML plano, CSS, y -- solo cuando optas explícitamente -- JavaScript.

Aquí está lo que consistentemente veo en las migraciones:

Métrica WordPress (Administrado) Astro (Estático) Mejora
Rendimiento de Lighthouse 34-55 95-100 +60-80 pts
First Contentful Paint 2.8-4.2s 0.4-0.8s ~80% más rápido
Total Blocking Time 200-800ms 0-10ms ~98% reducción
Tamaño de Página (post típico) 1.5-3.5 MB 80-250 KB ~90% más pequeño
Time to Interactive 4-8s 0.5-1.0s ~85% más rápido
Solicitudes HTTP 60-130 8-15 ~85% menos

Estos no son seleccionados. Son promedios de migraciones reales. Los sitios WordPress con plugins de caché y CDNs aún no pueden tocar una compilación estática de Astro porque fundamentalmente hacen más trabajo por solicitud.

El Ángulo de Seguridad

WordPress es el CMS más atacado en internet. No porque sea malo, sino porque está en todas partes y tiene una enorme superficie de ataque -- ejecución de PHP, acceso a base de datos, cargas de archivos, XML-RPC, endpoints de REST API, páginas de login de admin. Cada mes trae nuevas vulnerabilidades de plugins.

Los sitios Astro implementados en un CDN tienen esencialmente cero superficie de ataque. No hay servidor para explotar, sin panel de admin para fuerza bruta, sin base de datos para inyectar. Tu sitio es una carpeta de archivos HTML sentada en una red de borde global.

La Experiencia del Desarrollador

Si alguna vez has intentado personalizar un tema de WordPress, conoces el dolor: etiquetas de plantilla PHP mezcladas con HTML, la jerarquía de plantillas que requiere memorización, archivos functions.php que crecen en monstruos inmantenibles, conflictos constantes de plugins.

Astro usa una arquitectura basada en componentes con un formato de archivo que se parece a HTML con superpoderes. Puedes usar componentes de React, Vue, Svelte, o Solid dentro de páginas Astro -- pero solo cuando realmente necesitas interactividad. Para un blog o sitio de marketing, probablemente no.

---
// src/pages/blog/[...slug].astro
import { getCollection } from 'astro:content';
import BlogLayout from '../../layouts/BlogLayout.astro';

export async function getStaticPaths() {
  const posts = await getCollection('blog');
  return posts.map(post => ({
    params: { slug: post.slug },
    props: { post },
  }));
}

const { post } = Astro.props;
const { Content } = await post.render();
---

<BlogLayout title={post.data.title} description={post.data.excerpt}>
  <article>
    <h1>{post.data.title}</h1>
    <time datetime={post.data.date.toISOString()}>
      {post.data.date.toLocaleDateString()}
    </time>
    <Content />
  </article>
</BlogLayout>

Esa es una página de post de blog dinámica completa. Intenta hacer eso en WordPress con la misma claridad.

Astro vs Next.js vs Gatsby para Migración WordPress

Astro

Astro fue construido específicamente para sitios de contenido. Su "arquitectura de islas" significa que envías cero JS a menos que un componente específico lo necesite. Las colecciones de contenido te dan manejo de markdown type-safe con validación de esquema incorporada. Los tiempos de compilación son rápidos, el modelo mental es simple, y no necesitas entender React para usarlo. Para blogs, docs, y sitios de marketing, es la opción obvia en 2026. Si estás explorando esta ruta, nuestro equipo de desarrollo Astro ha manejado migraciones en cada escala.

Next.js

Next.js es un framework de aplicación completo. Maneja autenticación, renderizado del lado del servidor, rutas API, middleware, y cien otras cosas que no necesitas para un blog. Enviarás el runtime de React a cada visitante ya sea que necesite interactividad o no (los server components del App Router ayudan, pero el paquete base sigue siendo más pesado). Next.js tiene sentido cuando estás construyendo un producto SaaS o un sitio con funcionalidad dinámica pesada -- dashboards de usuario, e-commerce, características en tiempo real. ¿Para una migración de contenido desde WordPress? Es overkill. Dicho esto, si tu sitio realmente necesita esas características, nuestro equipo de Next.js puede ayudarte a descubrir la arquitectura correcta.

Gatsby

Gatsby está efectivamente en modo de mantenimiento. Netlify lo adquirió en 2023, y el desarrollo se ha ralentizado a un ritmo de tortuga. La capa de datos GraphQL que una vez pareció ingeniosa ahora se siente como una complejidad innecesaria. Los tiempos de compilación para sitios grandes son dolorosos. El ecosistema de plugins es obsoleto. Recomendaría fuertemente en contra de iniciar un nuevo proyecto de Gatsby en 2026. Si actualmente estás en Gatsby, migrar a Astro es realmente más fácil que migrar desde WordPress porque tu contenido probablemente ya esté en markdown.

Característica Astro Next.js Gatsby
JS por defecto enviado 0 KB ~85-100 KB ~70-90 KB
Colecciones de contenido Incorporadas, type-safe Configuración manual Capa GraphQL
Tiempo de compilación (1000 posts) ~30-45s ~60-90s ~120-300s
Curva de aprendizaje Baja Media-Alta Media
Mejor para Sitios de contenido Aplicaciones web Proyectos heredados
Desarrollo activo Muy activo Muy activo Mínimo
Soporte SSR Opcional Por defecto Limitado

Playbook de Migración en 7 Pasos

Aquí está el proceso exacto que sigo. Sin evasiones.

Paso 1: Auditar tu Sitio WordPress

Antes de que toques cualquier código, necesitas saber con qué estás trabajando. Inicia sesión en tu admin de WordPress y haz un inventario.

# Si tienes WP-CLI instalado (deberías)
wp post list --post_type=post --format=csv --fields=ID,post_title,post_name,post_date > posts.csv
wp post list --post_type=page --format=csv --fields=ID,post_title,post_name,post_date > pages.csv
wp plugin list --format=table
wp theme list --format=table

Documenta cada plugin y qué hace. Necesitarás encontrar equivalentes de Astro o dejarlos caer. Los comunes:

  • Yoast SEO → Gestión incorporada de <head> de Astro + @astrojs/sitemap
  • Contact Form 7 → Formspree, Formspark, o una función serverless
  • WP Super Cache / W3 Total Cache → No necesario (tu sitio ya es estático)
  • Wordfence / Sucuri → No necesario (sin servidor que proteger)
  • Plugin de Google Analytics → Etiqueta de script directo o integración de Partytown
  • WooCommerce → Snipcart, Shopify Buy Button, o una plataforma de e-commerce dedicada

Paso 2: Exportar Contenido de WordPress

Tienes dos opciones: exportación XML o REST API. Recomiendo la exportación XML para la mayoría de sitios porque captura todo en un solo shot.

En admin de WordPress: Tools → Export → All Content → Download Export File

Esto te da un archivo .xml que contiene cada post, página, comentario, campo personalizado, categoría, etiqueta, y referencia de media.

Para sitios más grandes (1000+ posts), el enfoque de REST API es más confiable:

// scripts/export-wp.mjs
import fs from 'fs/promises';
import path from 'path';

const WP_URL = 'https://your-wordpress-site.com/wp-json/wp/v2';
const PER_PAGE = 100;

async function fetchAllPosts() {
  let page = 1;
  let allPosts = [];
  
  while (true) {
    const res = await fetch(
      `${WP_URL}/posts?per_page=${PER_PAGE}&page=${page}&_embed`
    );
    
    if (!res.ok) break;
    
    const posts = await res.json();
    if (posts.length === 0) break;
    
    allPosts = allPosts.concat(posts);
    console.log(`Fetched page ${page} (${allPosts.length} posts total)`);
    page++;
  }
  
  return allPosts;
}

const posts = await fetchAllPosts();
await fs.writeFile('wp-posts.json', JSON.stringify(posts, null, 2));
console.log(`Exported ${posts.length} posts`);

Paso 3: Genera tu Proyecto Astro

npm create astro@latest my-new-site
cd my-new-site

# Añade las integraciones que necesitarás
npx astro add mdx
npx astro add sitemap
npx astro add tailwind

# Instala dependencias adicionales
npm install sharp @astrojs/rss

Recomiendo empezar con una configuración mínima en lugar de un tema. Los temas añaden complejidad que no necesitas durante la migración. Haz que el contenido funcione primero, luego estilízalo.

Paso 4: Convierte Contenido a Markdown

Aquí es donde comienza el trabajo real. Necesitas convertir contenido HTML de WordPress a markdown limpio con frontmatter apropiado.

Uso un script personalizado de Node.js con turndown para conversión HTML-a-markdown:

npm install turndown @wordpress/block-serialization-default-parser

// scripts/convert-posts.mjs
import TurndownService from 'turndown';
import fs from 'fs/promises';
import path from 'path';

const turndown = new TurndownService({
  headingStyle: 'atx',
  codeBlockStyle: 'fenced',
});

// Maneja HTML específico de WordPress
turndown.addRule('wpCaption', {
  filter: (node) => {
    return node.nodeName === 'DIV' && 
           node.className.includes('wp-caption');
  },
  replacement: (content, node) => {
    const img = node.querySelector('img');
    const caption = node.querySelector('.wp-caption-text');
    return `![${caption?.textContent || ''}](${img?.src || ''})\n`;
  },
});

const posts = JSON.parse(await fs.readFile('wp-posts.json', 'utf-8'));

for (const post of posts) {
  const slug = post.slug;
  const markdown = turndown.turndown(post.content.rendered);
  
  const frontmatter = `---
title: "${post.title.rendered.replace(/"/g, '\\"')}"
date: ${post.date}
excerpt: "${(post.excerpt.rendered || '').replace(/<[^>]*>/g, '').trim().replace(/"/g, '\\"')}"
categories: [${(post._embedded?.['wp:term']?.[0] || []).map(c => `"${c.name}"`).join(', ')}]
tags: [${(post._embedded?.['wp:term']?.[1] || []).map(t => `"${t.name}"`).join(', ')}]
featuredImage: "${post._embedded?.['wp:featuredmedia']?.[0]?.source_url || ''}"
draft: false
---`;

  const content = `${frontmatter}\n\n${markdown}\n`;
  
  await fs.mkdir('src/content/blog', { recursive: true });
  await fs.writeFile(`src/content/blog/${slug}.md`, content);
  console.log(`Converted: ${slug}`);
}

Paso 5: Descarga y Organiza Media

WordPress almacena media en directorios wp-content/uploads/YYYY/MM/. Necesitas descargar todo y actualizar referencias.

# Rápido y sucio: espejo wget de tu directorio de uploads
wget -r -np -nH --cut-dirs=2 -P public/uploads \
  https://your-wordpress-site.com/wp-content/uploads/

# Luego encuentra y reemplaza URLs antiguas en tus archivos markdown
find src/content/blog -name '*.md' -exec sed -i '' \
  's|https://your-wordpress-site.com/wp-content/uploads/|/uploads/|g' {} +

Para migraciones de producción, utilizo la optimización de imágenes de Astro con la librería sharp para convertir todo a WebP y generar tamaños responsivos en tiempo de compilación. Esto solo puede cortar la carga de imágenes por 40-60%.

Paso 6: Construye Layouts y Componentes

Crea tus layouts de Astro para coincidir (o mejorar) la estructura de tema de WordPress. Como mínimo necesitarás:

  • src/layouts/BaseLayout.astro -- shell HTML, <head>, nav, footer
  • src/layouts/BlogLayout.astro -- plantilla de post único
  • src/pages/blog/index.astro -- listado de blog con paginación
  • src/pages/blog/[...slug].astro -- páginas de posts dinámicos
  • src/pages/index.astro -- página de inicio

Paso 7: Prueba, Redirecciona, Despliega

Construye localmente y verifica todo:

npm run build
npm run preview

# Verifica enlaces rotos
npx linkinator http://localhost:4321 --recurse

Configura redirecciones (cubierto en detalle abajo), configura tu DNS, y despliega. Cubriré opciones de hosting en la sección de comparación de costos.

Exportar Datos de WordPress a Colecciones de Contenido de Astro

Las colecciones de contenido de Astro son una de sus mejores características. Te dan acceso type-safe a tu contenido markdown con validación de esquema. Aquí está cómo configurarlas apropiadamente para contenido migrado de WordPress.

Define tu Schema

// src/content.config.ts
import { defineCollection, z } from 'astro:content';
import { glob } from 'astro/loaders';

const blog = defineCollection({
  loader: glob({ pattern: '**/*.{md,mdx}', base: './src/content/blog' }),
  schema: z.object({
    title: z.string(),
    date: z.coerce.date(),
    excerpt: z.string().optional(),
    categories: z.array(z.string()).default([]),
    tags: z.array(z.string()).default([]),
    featuredImage: z.string().optional(),
    draft: z.boolean().default(false),
  }),
});

export const collections = { blog };

La belleza de esto: si alguno de tus posts migrados tiene frontmatter faltante o malformado, Astro te lo dirá en tiempo de compilación con un mensaje de error claro. Sin más fallos silenciosos.

Manejo de Shortcodes de WordPress

Este es el error que la mayoría de guías de migración saltan. Si tus posts de WordPress usan shortcodes como [gallery], [caption], [embed], o cualquier shortcode personalizado de plugins, aparecerán como texto sin procesar en tu markdown.

Tienes tres opciones:

  1. Pre-procesamiento durante conversión -- Escribe reglas regex en tu script de conversión para transformar shortcodes en equivalentes markdown o HTML
  2. Usa MDX -- Convierte posts afectados a .mdx y crea componentes Astro que reemplacen shortcodes
  3. Encuentra y reemplaza manualmente -- Para sitios pequeños, a veces es el enfoque más rápido
// Ejemplo: convertir shortcode de galería de WordPress durante conversión
function convertShortcodes(content) {
  // [gallery ids="1,2,3"]
  content = content.replace(
    /\[gallery ids="([^"]+)"\]/g,
    (match, ids) => {
      const imageIds = ids.split(',');
      return imageIds.map(id => `![](/uploads/gallery/${id.trim()}.jpg)`).join('\n');
    }
  );
  
  // [youtube url="..."]
  content = content.replace(
    /\[youtube[^\]]*url="([^"]+)"[^\]]*\]/g,
    (match, url) => `<iframe src="${url}" width="560" height="315" frameborder="0"></iframe>`
  );
  
  return content;
}

Consulta de Contenido

Una vez que tu contenido está en colecciones, consultarlo es sencillo:

---
// src/pages/blog/index.astro
import { getCollection } from 'astro:content';
import BlogLayout from '../../layouts/BlogLayout.astro';

const posts = (await getCollection('blog'))
  .filter(post => !post.data.draft)
  .sort((a, b) => b.data.date.valueOf() - a.data.date.valueOf());
---

<BlogLayout title="Blog">
  <ul>
    {posts.map(post => (
      <li>
        <a href={`/blog/${post.slug}/`}>
          <h2>{post.data.title}</h2>
          <time>{post.data.date.toLocaleDateString()}</time>
          <p>{post.data.excerpt}</p>
        </a>
      </li>
    ))}
  </ul>
</BlogLayout>

Preservar SEO: Redirecciones 301, Sitemap y Schema

Esta sección es crítica. Una migración fallida puede destruir años de equidad SEO de la noche a la mañana. No saltes nada de esto.

Estructura de URL y Redirecciones 301

WordPress por defecto usa URLs como /2024/03/my-post-title/ o /?p=123. Necesitas mapear cada URL antigua a su equivalente nueva en Astro.

Primero, genera una lista completa de URLs antiguas:

# Usando WP-CLI
wp post list --post_type=post,page --field=url > old-urls.txt

# O rastrea el sitemap
curl -s https://your-site.com/sitemap.xml | grep -oP '<loc>\K[^<]+'

Para Vercel, crea un vercel.json en la raíz de tu proyecto:

{
  "redirects": [
    { "source": "/2024/03/my-old-post/", "destination": "/blog/my-old-post/", "permanent": true },
    { "source": "/:year(\\d{4})/:month(\\d{2})/:slug/", "destination": "/blog/:slug/", "permanent": true },
    { "source": "/category/:slug/", "destination": "/blog/category/:slug/", "permanent": true },
    { "source": "/feed/", "destination": "/rss.xml", "permanent": true }
  ]
}

Para Netlify, usa _redirects en tu carpeta public/:

/2024/03/my-old-post/  /blog/my-old-post/  301
/category/*            /blog/category/:splat  301
/feed/                 /rss.xml  301

Para Cloudflare Pages, usa _redirects (mismo formato que Netlify) o Bulk Redirects en el dashboard.

Generación de Sitemap

La integración @astrojs/sitemap maneja esto automáticamente:

// astro.config.mjs
import { defineConfig } from 'astro/config';
import sitemap from '@astrojs/sitemap';

export default defineConfig({
  site: 'https://your-new-site.com',
  integrations: [sitemap()],
});

Después de desplegar, envía tu sitemap nuevo en Google Search Console inmediatamente. También envía una solicitud de eliminación para cualquier URL que ya no exista y no esté redirigida.

Marcado de Datos Estructurados / Schema

Si Yoast estaba manejando tu marcado de schema, necesitas replicarlo. Crea un componente reutilizable:

---
// src/components/ArticleSchema.astro
const { title, date, excerpt, image, author = 'Your Name' } = Astro.props;

const schema = {
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": title,
  "datePublished": date,
  "description": excerpt,
  "image": image,
  "author": {
    "@type": "Person",
    "name": author
  }
};
---

<script type="application/ld+json" set:html={JSON.stringify(schema)} />

Feed RSS

No olvides tus suscriptores de RSS:

// src/pages/rss.xml.js
import rss from '@astrojs/rss';
import { getCollection } from 'astro:content';

export async function GET(context) {
  const posts = await getCollection('blog');
  return rss({
    title: 'Your Site',
    description: 'Your description',
    site: context.site,
    items: posts.map(post => ({
      title: post.data.title,
      pubDate: post.data.date,
      description: post.data.excerpt,
      link: `/blog/${post.slug}/`,
    })),
  });
}

Comparación de Costos de Hosting

Aquí es donde el caso comercial para la migración se vuelve imposible de ignorar.

Escenario de Hosting Costo Mensual Costo Anual Notas
WP Engine (WordPress Administrado) $30-60 $360-720 Planes Startup-Growth
Kinsta (WordPress Administrado) $35-70 $420-840 Planes Starter-Business
Flywheel (WordPress Administrado) $15-30 $180-360 Planes Tiny-Personal
Auto-hospedado (DigitalOcean + mantenimiento) $12-24 $144-288 Más tu tiempo para actualizaciones
Astro en Vercel (Hobby) $0 $0 100GB ancho de banda/mes
Astro en Netlify (Gratis) $0 $0 100GB ancho de banda/mes
Astro en Cloudflare Pages (Gratis) $0 $0 Ancho de banda ilimitado
Astro en Vercel (Pro) $20 $240 1TB ancho de banda, características de equipo

Para la gran mayoría de sitios de contenido -- blogs, portfolios, sitios de documentación, sitios de marketing -- los niveles gratuitos en Vercel, Netlify, o Cloudflare Pages son más que suficientes. Estás sirviendo archivos estáticos desde un CDN global. Un sitio recibiendo 100,000 páginas vistas por mes apenas arañará los límites de nivel gratuito.

Déjame deletrear las matemáticas. Si estás pagando $50/mes por hosting de WordPress administrado, eso es $600/año. Durante tres años, eso es $1,800. Añade licencias de plugins premium (Yoast Premium a $99/año, Elementor Pro a $59/año, WP Rocket a $59/año), y estás viendo $800-$1,000 anualmente para un sitio de contenido que podría ser alojado gratis.

La migración en sí es un costo único. Si lo manejas tú mismo, es tu tiempo. Si contratas un equipo como el nuestro a través de nuestros servicios de desarrollo de CMS headless, el ROI típicamente se recupera dentro de 6-12 meses solo con ahorros de hosting -- sin contar las mejoras de rendimiento y SEO. Revisa nuestra página de precios para especifics.

Pero ¿Qué Hay de las Características Dinámicas?

La objeción más común: "Mi sitio de WordPress tiene formularios de contacto, búsqueda, comentarios, y e-commerce."

  • Formularios de contacto: Formspree (nivel gratuito: 50 envíos/mes), Formspark, o una función serverless simple
  • Búsqueda: Pagefind (gratis, se ejecuta completamente en el lado del cliente, construido para sitios estáticos) -- es increíble
  • Comentarios: Giscus (gratis, respaldado por GitHub), o Disqus si debes
  • E-commerce: Snipcart, Shopify Lite, o Stripe Checkout
  • Suscripciones de newsletter: Llamadas directas de API a ConvertKit, Mailchimp, o Buttondown

Ninguno de estos requiere un servidor. Ninguno de ellos añade costo significativo.

FAQ

¿Cuánto tiempo lleva la migración de WordPress a Astro?

Para un blog típico con 50-200 posts, espera 1-2 semanas de trabajo a tiempo parcial si lo estás haciendo tú mismo. La conversión de contenido generalmente es un día de trabajo con un buen script. Construir los layouts y componentes de Astro toma 2-4 días dependiendo de la complejidad del diseño. Las pruebas, configuración de redirecciones, y despliegue toman otros 1-2 días. Para sitios más grandes (500+ posts) o sitios con tipos de post personalizados complejos y dependencias de plugins, presupuesta 3-6 semanas. Si prefieres dejarlo en manos, contacta a nuestro equipo -- típicamente completamos migraciones en 2-4 semanas.

¿Puede Astro manejar un blog de WordPress con 1000+ posts?

Absolutamente. He migrado sitios con más de 3,000 posts y los tiempos de compilación se mantuvieron por debajo de 2 minutos. Las colecciones de contenido están optimizadas para conjuntos de datos grandes, y como todo se compila a HTML estático, no hay penalización de rendimiento en tiempo de ejecución sin importar el volumen de contenido. El paso de compilación es el único lugar donde la escala importa, y el rendimiento de compilación de Astro es excelente -- significativamente más rápido que Gatsby o Next.js para contenido estático a escala.

¿Soporta Astro comentarios de WordPress?

No nativamente, y honestamente eso es una característica, no un error. Los comentarios de WordPress son un imán de spam que requiere moderación constante. Para sitios Astro, las mejores opciones son: Giscus (usa GitHub Discussions -- gratis, sin rastreo, excelente para audiencias de desarrolladores), Disqus (el viejo estándar, tiene anuncios en nivel gratuito), Commento (enfocado en privacidad, $5/mes), o una solución personalizada usando una base de datos como Turso o Supabase con una ruta API de Astro. Si quieres preservar comentarios de WordPress existentes, expórtalos y muéstralos como contenido estático, luego usa uno de estos servicios para comentarios nuevos en adelante.

¿Es Astro más rápido que WordPress?

Ni siquiera está cerca. Un sitio estático de Astro superará incluso la configuración de WordPress más optimizada porque elimina el cuello de botella fundamental: procesamiento del lado del servidor. WordPress tiene que ejecutar PHP, consultar una base de datos, ensamblar la página, y enviarla -- para cada solicitud (a menos que esté en caché). Astro pre-construye todo. Tus visitantes reciben HTML pre-renderizado directamente desde un nodo de borde de CDN cerca de ellos. Las mejoras típicas son tiempos de carga 80-90% más rápidos y mejoras de puntuación de Lighthouse de 60-80 puntos.

¿Qué sucede con mi admin de WordPress y editor WYSIWYG?

Pierdes el panel de admin de WordPress. Para la mayoría de desarrolladores, eso es un alivio. Editarás archivos markdown directamente, lo que es más rápido y más portable. Si tienes editores de contenido no técnicos que necesitan una interfaz visual, considera el enfoque headless: mantén WordPress ejecutándose como un backend de contenido y usa Astro como frontend. O empareja Astro con un CMS headless como Sanity, Contentful, Storyblok, o Keystatic (que tiene un editor basado en GitHub que es genuinamente agradable). Nuestros servicios de desarrollo de CMS headless pueden ayudarte a elegir el backend de contenido correcto para tu equipo.

¿Bajarán mis rankings en Google después de migrar?

No deberían, y en la mayoría de casos mejoran -- pero solo si manejas correctamente las redirecciones. Cada URL antigua debe seguir funcionando o 301-redirigir a su equivalente nueva. Envía tu sitemap nuevo a Google Search Console el mismo día que lanzas. Monitorea el reporte de Index Coverage durante los primeros 30 días. He visto sitios ganar 15-30% más tráfico orgánico dentro de 2-3 meses de migración puramente a partir de mejoras en Core Web Vitals, ya que Google usa señales de experiencia de página como factor de ranking.

¿Puedo mantener WordPress como CMS headless y usar Astro para el frontend?

Sí, y este es un gran enfoque de término medio. Mantienes el admin y experiencia de editor de WordPress pero descartas el frontend de PHP completamente. Astro obtiene contenido de la REST API de WordPress (o WPGraphQL) en tiempo de compilación y genera páginas estáticas. Aún necesitas alojar WordPress en algún lugar, así que no ahorrarás en costos de hosting, pero obtienes todos los beneficios de rendimiento del frontend. Para equipos que están fuertemente invertidos en el flujo de trabajo de edición de WordPress, esta a menudo es la opción pragmática.

¿Necesito saber React o algún framework de JavaScript para usar Astro?

No. Los componentes de Astro usan un formato de archivo .astro que se parece a HTML con un bloque de script frontmatter. Si puedes escribir HTML y CSS, puedes construir un sitio Astro. Los frameworks de JavaScript (React, Vue, Svelte) son opcionales -- solo los traerías si necesitas componentes interactivos del lado del cliente como un widget de búsqueda, un formulario con validación, o un carrusel de imágenes. Para un blog o sitio de marketing, puedes construir todo sin tocar React.