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. Cuando por fin me puse a reorganizar el contenido viejo — categorías, tags, fusionar un par de series de posts fragmentadas — 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 — todo lo que habría permitido 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.

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. Es un simulador interactivo de PC 386 — MARIO-DOS, ventanas de Windows 3.11 — montado con createApp().mount('#app'). No hay SSR ni SSG: el HTML que sirve el servidor está prácticamente vacío hasta que el JavaScript se ejecuta en el navegador. Para un portfolio interactivo, es una decisión razonable: quien entra ya sabe a quién busca. Para un blog, es un problema real de SEO — un rastreador que no ejecute JavaScript (o lo haga con retraso) ve una página en blanco donde debería ver un artículo técnico completo. Astro, en cambio, genera HTML estático en build time: cada post es una página real desde el primer byte.

2. Son dos experiencias distintas y mezclarlas empeora ambas. El simulador retro es para explorarlo, con tiempo, jugando con las ventanas y los easter eggs. Un blog técnico es para leerlo rápido, buscar un comando concreto, copiar un bloque de código. Meter uno dentro del otro obliga a elegir: o el blog hereda el chrome de ventana de MS-DOS (y la lectura larga se vuelve incómoda), o el simulador se llena de rutas de contenido que no tienen nada que ver con su lógica de sistema de ficheros virtual. 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.