Por qué migramos de WordPress a Astro (y por qué el blog no vive dentro del portfolio en Vue)

Este blog llevaba once años en WordPress.com, plan gratuito, sin tocarse apenas. Lo que quería no era solo poner orden puntual — categorías, tags, fusionar un par de series de posts fragmentadas — sino tener un lugar donde documentar las cosas de manera rápida y eficiente, con un solo git push, apoyándome en IA para automatizar buena parte de ese trabajo. Al intentarlo me encontré con una pared, no con una tarea de tarde.

Por qué WordPress se quedó corto

No fue una decisión estética ni una moda por Astro. Fue una sensación acumulada de que WordPress se me quedaba pequeño: no lo gestionaba al completo. Había una capa entera del sitio — infraestructura, despliegue, incluso el propio contenido en bruto — que no estaba bajo mi control, sino bajo el de la plataforma. Eso fue lo que me llevó a buscar alternativas, no un bloqueo puntual que se pudiera arreglar con un plan de pago.

Los bloqueos concretos que fui encontrando al intentar reorganizar el contenido viejo no eran la causa, eran el síntoma de esa falta de control:

• Redirects 301 reales, de pago. Fusionar tres posts de Raspberry Pi en uno solo implica que las otras dos URLs tienen que redirigir a la superviviente. En WordPress.com eso es Jetpack Redirects, función de pago — o un plugin, que tampoco se puede instalar sin plan Business.
• API de contenidos bloqueada. posts.update, categories.create — la base sobre la que quería construir un flujo con IA para automatizar la reorganización de categorías y tags estaba detrás del mismo muro.
• Cero plugins, de ningún tipo. Ni para redirects, ni para nada.

El detonante real fue justo intentar montar ese flujo con IA: no reorganizar categorías y tags a mano, sino apoyarme en herramientas de IA que hicieran ese trabajo por mí a partir de la API de contenidos. Ahí fue cuando choqué con el muro real.

Cada uno de estos puntos, por separado, tiene solución: pagar el plan que corresponda. Pero pagar no resolvía lo que de verdad me molestaba, que era no gestionar el sitio al completo — seguía siendo la infraestructura de otro, con las reglas de otro.

Buscando alternativas, dos ideas fueron las que de verdad me convencieron: quería escribir los artículos en Markdown, sin editor propietario de por medio, y me di cuenta de que no necesitaba un panel de gestión — con integración continua, el propio despliegue podía ser el “publicar”. Sin backend, sin base de datos, sin admin panel esperando a que le suba de plan.

Por qué Astro

No fue la única opción sobre la mesa, pero fue la que encajaba con lo que había decidido que quería: escribir en Markdown y no depender de un panel de gestión.

• Markdown como formato nativo, no como plugin. Cada artículo es un fichero de texto plano con frontmatter. Se edita con cualquier editor, se versiona con Git, se revisa con un diff normal. Nada de editor de bloques propietario ni de contenido atrapado en una base de datos que solo la propia plataforma sabe leer.
• El despliegue es el panel de gestión. No necesito una interfaz de administración esperando detrás de un login: publicar es hacer git push y dejar que la integración continua construya y despliegue el sitio estático. Editar un post, moverlo de categoría o borrarlo es exactamente el mismo flujo que cualquier otro cambio en el repositorio — sin una capa de gestión aparte que mantener.
• Redirects nativos. Un objeto en astro.config.mjs. Sin plan de pago, sin plugin, sin Jetpack.
• Content Collections + schema Zod. La taxonomía de categorías ahora es un enum validado en build time — si intento publicar un post con una categoría que no existe, astro build falla. WordPress nunca me dio esa garantía; podía escribir cualquier cosa en el campo categoría y se guardaba tal cual.
• Todo el historial vive en Git. Cada cambio de categoría, cada corrección de un post viejo, queda registrado con su propio commit. En WordPress esos cambios no dejaban rastro salvo que llevaras la cuenta tú mismo a mano.

Por qué no vive dentro del portfolio en Vue

Esta es la pregunta que más me hicieron cuando comenté que estaba montando el blog en Astro: si ya tengo mrubiodev.com en Vue, ¿por qué no meter el blog ahí dentro, como una sección más?

Por tres motivos, y ninguno es “porque sí”:

1. mrubiodev.com es una SPA renderizada en cliente, y no es solo el simulador. Bajo la interfaz de MS-DOS/Windows 3.11 hay un portfolio completo — CV, experiencia, formación, skills, proyectos, contacto, incluso una sección de beta testing — con algunas partes restringidas. El simulador retro es la interfaz con la que se navega todo esto, no el contenido en sí.

Eso agrava el problema de fondo, no lo cambia: es una SPA montada con createApp().mount('#app'), sin SSR ni SSG. El HTML que sirve el servidor está prácticamente vacío hasta que el JavaScript se ejecuta — y encima, parte del contenido real solo aparece tras superar una capa de acceso. Para un portfolio así, tiene sentido: quien entra ya sabe a quién busca, y cierto contenido puede ser deliberadamente restringido. Para un blog, ese mismo patrón es un problema doble: un rastreador que no ejecute JavaScript ve una página en blanco donde debería ver un artículo técnico completo, y si el contenido encima estuviera restringido, directamente no lo vería nunca. Astro, en cambio, genera HTML estático en build time: cada post es una página real, pública, desde el primer byte.

2. Son dos experiencias con lógicas internas incompatibles, y mezclarlas empeora ambas. No es solo “simulador interactivo vs. lectura rápida” — es un sistema con gestión de sesión, control de acceso por sección y persistencia en cliente, todo construido alrededor de la lógica de un escritorio virtual (bootManager, sistema de ficheros simulado, logros). Meter un blog técnico ahí dentro no es solo un choque estético: obligaría a decidir si los artículos también pasan por el control de acceso (sin sentido para contenido que quieres que se indexe y se comparta) o si conviven como una isla sin esa capa dentro de una app pensada en gran parte para tenerla. Ninguna opción es limpia. Mejor mantener cada cosa fiel a lo que es.

3. Necesitan pipelines de despliegue distintos. Corregir una tilde en un post no debería obligar a reconstruir y redesplegar todo el simulador interactivo, con su propio estado, su propio bootManager.js, su propio sistema de logros. Con el blog como proyecto Astro separado (blog.mrubiodev.com), cada uno se despliega de forma independiente, a su propio ritmo.

La solución no es “todo en un sitio” ni “todo separado sin relación” — es dos proyectos con propósitos distintos, enlazados entre sí. El blog enlaza a mrubiodev.com desde su cabecera; el portfolio, cuando llegue el momento de tocarlo, enlazará al blog. Cada uno hace una cosa y la hace bien, en vez de los dos haciendo un poco de todo a medias.

Lo que queda pendiente

Esta migración no cierra el tema del todo. La identidad visual del blog se pensó heredando la paleta moderna (violeta/índigo) de mrubiodev.com precisamente para que, aunque vivan en dominios separados, no se sientan como dos productos sin relación — un guiño retro puntual en el panel de metadatos de cada post es el único punto donde el ADN del simulador se cuela en el blog. Separados en infraestructura, pero no en identidad.

Por ahora, el blog se queda sin comentarios. Ya le estoy dando vueltas a cómo integrarlos en el futuro, con la misma filosofía que el resto del blog: sin desplegar un backend propio ni una base de datos que mantener.