Migrar de WordPress a Astro: el caso de seonidas.com

Publicado el 18 de septiembre de 2026 · Por Jesús Iturbide, en colaboración con el equipo de Marketing España · Lectura: 20 min

De dónde venía seonidas.com

seonidas.com es la web de consultoría de SEO técnico de la cooperativa, y hasta el 3 de septiembre de 2026 era un WordPress con tema propio: 26 plantillas PHP, cuatro plugins y un motor de SEO a medida que emitía título, descripción, canónica, robots y datos estructurados de cada pieza. Tenía 50 artículos entre publicados y programados, 23 páginas y cuatro herramientas interactivas. Sobre el papel, una web hecha.

Sobre el papel. A finales de agosto, quien la dirige la puntuó con un uno sobre diez, y tenía razón en lo visible: la portada medía 15.116 píxeles de alto porque una plantilla volcaba un documento entero que ya existía en otra página. Se recortó a 10.705 píxeles en una tarde. Lo grave no se veía.

Lo grave era que Google no podía mirarla. El 2 de septiembre, una medición sobre el HTML servido encontró que ninguna de sus páginas era indexable —portada, servicios y contacto incluidos— y que 36 de sus 50 artículos llevaban su propia etiqueta de noindex: de los 24 publicados, solo 13 estaban abiertos al buscador. No era una decisión. Era estado heredado de la construcción, un candado por pieza que nadie había abierto porque nadie lo había medido. Search Console lo confirmó después con la cifra más honesta de todo este artículo: 2 impresiones y 0 clics en 180 días, con una sola consulta, la de su propia marca.

Ese es el punto de partida real. No una web lenta que había que acelerar, sino una web invisible que había que abrir. Y, después de abrirla, decidir sobre qué tecnología se sostenía.

La medición que desmontó la premisa

La pregunta que llegó fue «¿la pasamos a Astro para que vaya más rápida?». Antes de contestar medimos, y la medición dijo que la premisa estaba mal. Desde el propio servidor, sin intermediarios, WordPress servía la portada en 9,5 milisegundos. Desde fuera, el tiempo hasta el primer byte rondaba los 384 milisegundos: seis tomas y la mediana, no una toma suelta. Entre medias había una sola pieza, el CDN del alojamiento, que en su propia cabecera de respuesta declaraba haber esperado al origen casi medio segundo.

Para comparar teníamos otra web del grupo, ya en Astro, en el mismo alojamiento y sin pasar por el CDN: 208 milisegundos. La ventaja coincidía exactamente con quién pasaba por el CDN, no con la tecnología. Migrar por rendimiento no iba a dar lo que se buscaba.

Se migró igualmente, y conviene decir por qué, porque no fue por velocidad. Fue por control: un sitio estático entrega exactamente el HTML que se ha construido, sin plugins que inyecten código ni caché que sirva versiones viejas, y el escaparate de un servicio de SEO técnico tiene que poder enseñarse línea a línea. Y fue por el calendario: con 38 artículos programados hasta noviembre hacía falta un motor de estados (publicado, borrador, programado) que ya existía en la otra web del grupo y se podía replicar. Decisión tomada con el dato delante, no a pesar de él.

Hay una rectificación que también forma parte del caso. Aquella medición del 2 de septiembre nos llevó a recomendar desactivar el CDN. Dos días después, al repetirla, el servidor estaba con una carga de 57 y hasta la web sin CDN tardaba 2,6 segundos: no se podía concluir nada, y la primera toma tampoco separaba el CDN de la carga del nodo. La recomendación se retiró. Un CDN delante de un sitio estático es su mejor caso de uso, y el CDN se quedó.

Qué se llevó a Astro y qué hubo que reconstruir

Se migraron los 50 artículos y 26 páginas a ficheros Markdown, con los metadatos propios de cada pieza (título SEO, descripción, robots, canónica, tipo de schema, frase objetivo, nota editorial y el rastro de dónde venía cada texto) copiados uno a uno al frontmatter. El esquema de la colección los declara obligatorios: si uno desaparece del origen, la construcción falla en vez de perderlo en silencio. Ese es el primer cambio de mentalidad que trae un sitio estático. El error salta antes de publicar, no después.

El cuerpo de los artículos no se convirtió a Markdown. Ya era HTML limpio, y convertirlo habría perdido las anclas de los encabezados que el índice lateral necesita y la estructura de las tablas. Se llevó tal cual. El primer build generó 14 páginas en 10,45 segundos y una portada de 16 kilobytes que sirve las imágenes por ruta; incrustadas, la misma portada pesaba un megabyte.

Lo que WordPress hacía por su cuenta hubo que reponerlo a mano. Esta lista es la que conviene tener delante antes de migrar cualquier web a estático:

Las URL vivían donde nadie miraba

Cada artículo guardaba un metadato que decía que su ruta era «/blog/» seguido del slug, y la primera auditoría de la migración se fió de él: «los artículos ya vivían en /blog/». Era falso. El WordPress vivo servía los 50 artículos en la raíz, y así los tenía Google en su sitemap; la ruta con «/blog/» hacía una redirección hacia la raíz, no al revés. Los «156 enlaces rotos» que esa auditoría había contado apuntaban a la dirección real. Sin darnos cuenta a tiempo, la conmutación habría mandado a un error 404 todo lo indexado.

La salida fue mantener «/blog/» como ruta nueva (ya estaba en las 156 referencias reescritas y en el sitemap) y escribir 50 redirecciones permanentes de la raíz a «/blog/» en cada construcción, con una comprobación que no deja subir el sitio si faltan. Hoy siguen vivas: puedes pedir cualquier slug antiguo y ver el 301.

El día del cambio: lo que falló

Se conmutó el 3 de septiembre a las 22:12 UTC. El guion preveía comprimir WordPress antes de retirarlo, y falló dos veces. El servidor compartido estaba con una carga de entre 50 y 70, y a esa carga mata los procesos largos: la compresión murió a los 64 megabytes de 229, y la exportación de la base de datos estuvo diez minutos sin escribir un byte, porque para hacerla arranca WordPress entero.

Lo que funcionó fue lo contrario de lo previsto: mover en vez de comprimir. Mover 229 megabytes dentro del mismo disco es instantáneo y los conserva íntegros, así que WordPress sigue ahí, fuera de la raíz pública, con un fichero que explica cómo volver atrás. La base de datos no se tocó, porque un sitio estático no la usa; su volcado, hecho después de retirar WordPress, tardó 25 segundos y ocupa 21 tablas.

Y entonces la portada no cambió. Todas las rutas servían ya el sitio nuevo salvo la primera, que el CDN siguió entregando desde su caché durante horas. La causa no era el CDN en sí: era la caducidad que WordPress le había dado a esa respuesta. El objeto guardado decía siete días —cortesía del plugin de caché de WordPress—, mientras el sitio nuevo declara 600 segundos. Se resolvió solo cuando esa entrada caducó, y ya no puede repetirse: la entrada nueva se guarda con los diez minutos de Astro.

La lección de esa noche cabe en una frase: las cabeceras que llegan a través de un CDN describen al objeto que el CDN guardó, no al servidor que responde ahora. Para saber qué hace el origen hay que preguntarle al origen, resolviendo el dominio contra su dirección IP y saltándose al intermediario. Probamos antes todas las formas de purgar esa entrada desde fuera, y ninguna funcionó; la única purga real vive en el panel del alojamiento.

Lo que la auditoría encontró al día siguiente

El 4 de septiembre se auditaron las 41 páginas construidas, 31 de ellas indexables, sobre la web viva y no sobre la copia local. Lo técnico estaba bien: tiempo hasta el primer byte entre 52 y 191 milisegundos, LCP entre 564 y 1.828 milisegundos, desplazamiento de diseño por debajo de 0,002, un solo H1 y un solo grafo de datos estructurados por página, cero títulos duplicados, cero imágenes sin texto alternativo y las 50 redirecciones vivas.

Lo editorial, no. La página «Sobre» no recibía ni un enlace interno: publicada e inalcanzable. Nueve de los diez servicios no enlazaban a ningún análisis del blog. Los servicios tenían 417 palabras de media frente a las 1.481 de los artículos, o sea que lo que vende era lo más flaco. Veintiuna páginas de las 31 no citaban una sola fuente externa. Y 65 piezas llevaban dentro la nota «revisión humana y autoría pendientes», doce de ellas publicadas, mientras la política editorial de la propia web decía que nada generado se publica sin esa revisión. Una web que se contradecía a sí misma.

Hubo algo peor, y lo contamos porque es el tipo de fallo que solo se caza mirando. La portada de la previa traía nueve cifras de resultados que venían del boceto de diseño («1.247 palabras posicionadas», «562 dominios de referencia», un gráfico de la posición 50 a la 1) y se estaban sirviendo como propias. Ninguna medida. En una web que se vende como consultoría de SEO técnico. La guía de diseño del proyecto lo prohibía por escrito, y la nota interna de la sesión anterior afirmaba que no se habían publicado. Se retiraron antes de conmutar y se sustituyeron por datos que la propia web cuenta al construirse: los análisis publicados, los enlaces comprados (cero) y las cookies antes del consentimiento (cero).

Todo lo demás se corrigió en la misma jornada, con el resultado medido antes y después por el mismo instrumento:

La nota interna del auditor pasó de 43,4 a 100 sobre 100, y conviene decir qué mide esa nota: el estado técnico y editorial de cada página, con una fórmula escrita por dimensión. No mide posiciones, tráfico ni autoridad. Un 100 ahí significa «no queda nada roto», no «ya posiciona». Sobre el FAQPage, un matiz que también hay que decir: Google dejó de mostrar el desplegable de preguntas en sus resultados el 7 de mayo de 2026, así que se mantiene por el valor semántico y para los sistemas de IA, sin prometer que se vea en la página de resultados.

Siete cosas que aprendimos

Ninguna de estas siete es nueva para quien haya migrado una web. Todas se nos olvidaron al menos una vez en este caso, y por eso van escritas.

1. Mide el origen antes de culpar al gestor. Si el servidor sirve en milisegundos, el problema está aguas abajo: CDN, DNS, red. Cambiar de tecnología no arregla lo que no está en la tecnología.
2. Un metadato no es una medición. El campo decía «/blog/» y la web servía en la raíz. Antes de afirmar dónde vive una URL se le pide al sitio vivo, y ahora lo hace el propio guion de conmutación como última comprobación.
3. Las cabeceras detrás de un CDN hablan del objeto guardado. Veíamos «acierto de caché» y «siete días» y parecían del origen: venían dentro de la respuesta que el CDN guardó cuando el sitio todavía era WordPress.
4. Una afirmación sobre el entregable no es una comprobación del entregable. «Las cifras del boceto no se han publicado» estaba escrito en una nota, y estaban en la previa. Se comprueba sobre el HTML construido con una búsqueda de esas cifras que no debe devolver nada, y esa búsqueda quedó en el guion.
5. Una comprobación que nunca ha fallado no es una comprobación. Cada despliegue pasa más de diez puertas (cabecera, enlaces, consentimiento, redirecciones, formulario, accesibilidad, herramientas, grafo de datos, calendario, vigilancia y móvil), y cada una se probó inyectándole el defecto que debía cazar. Varias nacieron débiles: una aprobaba las herramientas con la lógica vacía y otra acusaba a un control accesible. Se arreglaron antes de fiarse de ellas.
6. Una pieza no puede haberse modificado antes de existir. La migración escribió la fecha del día en las 50 piezas, y 39 se publican después de esa fecha. Solo dos eran visibles; las otras 37 habrían salido con la incoherencia dentro, una a una, hasta noviembre. Mientras nadie toque una pieza, su fecha de modificación es la de publicación, y una puerta del grafo lo comprueba.
7. Con carga 70, un alojamiento compartido no va lento: mata procesos. Se mira la carga antes de cualquier operación larga, y si pasa de 20 se replantea para que no haga falta un proceso largo. Mover, no comprimir.

Lo que puedes comprobar tú mismo

Todo lo anterior son afirmaciones nuestras sobre nuestra propia web, así que aquí va la forma de comprobarlas sin fiarte de nosotros: qué decimos, cómo se verifica y lo que vimos el 6 de septiembre de 2026. Si algún día dejan de cumplirse, este artículo estará desactualizado y habrá que decirlo aquí.

Hay una página más que vale la pena abrir, «El grupo», porque explica lo que este artículo da por sabido: la cooperativa mantiene varias webs con marcas distintas y esa página dice qué resuelve cada una y a cuál escribir. Está escrita y enlazada desde el pie, no escondida. Es la forma honesta de tener cinco escaparates.

¿Astro o WordPress? Cuándo compensa cada uno

Ninguna de las dos es mejor en abstracto. Lo decide quién va a publicar, con qué frecuencia y cuánto control necesita sobre lo que sale. Después de esta migración, y de mantener los dos tipos de web en el grupo, así lo repartimos:

Y lo que no cambia con la tecnología: redirecciones, sitemap, caché y enlazado interno se rompen igual en las dos si nadie los mide. Este caso lo demuestra, porque lo que más costó no fue Astro. Si vas a rediseñar sobre WordPress, el protocolo es el mismo y lo tenemos escrito en rediseñar la web sin hundir el posicionamiento. Si lo que necesitas es decidir tecnología para un proyecto nuevo, es una conversación de desarrollo web antes que de SEO. Y si la web ya existe y no aparece, empieza por saber si Google puede verla, que es lo primero que miramos en posicionamiento SEO.

Preguntas frecuentes

¿Astro o WordPress para mi web?

Lo decide quién publica y qué hace la web, no cuál está de moda. Si una o dos personas técnicas publican con calendario y quieres control total del HTML, un sitio estático con Astro es más simple de mantener y de auditar. Si publican varias personas sin perfil técnico, o hay tienda, usuarios o áreas privadas, WordPress sigue siendo la opción razonable. En el grupo mantenemos las dos por esa razón.

¿Migrar de WordPress a Astro hace perder posicionamiento?

No por la tecnología; sí por lo que la migración arrastra si no se mide. Lo que hunde posiciones es cambiar las URL sin redirigirlas, dejar el sitemap sin reponer o servir versiones viejas desde la caché. En este caso las tres cosas aparecieron, y las tres se cazaron antes de que Google las viera porque se comprobó sobre la web viva, no sobre lo que decían los metadatos.

¿Un sitio estático puede tener formulario de contacto y herramientas?

Sí, pero hay que construirlos aparte. Aquí el formulario es un PHP plano que guarda cada consulta antes de intentar enviar el correo, de modo que un fallo de correo no pierde el contacto, y las cuatro herramientas se reescribieron en JavaScript de cliente y se prueban en un navegador real en cada despliegue. Lo que en WordPress viene con un plugin, en estático se programa una vez y se verifica siempre.

¿Cuánto tarda Google en notar el cambio?

No lo sabemos todavía para esta web, y por eso no lo prometemos. La portada tardó unas horas en cambiar por la caché del CDN; el rastreo de las redirecciones y la indexación de las páginas nuevas van por tandas. La línea base está tomada (2 impresiones en 180 días) y el efecto se medirá contra ella a las ocho o doce semanas, que es el plazo mínimo antes de sacar conclusiones.

Sigue por aquí

• Rediseñar la web sin hundir el posicionamiento
• Web lenta: qué la frena de verdad y qué no vas a arreglar
• WordPress para empresas: cuándo conviene y cuándo no