De WordPress a un sitio estático asistido por IA: reconstruir sin perder el pasado

Mi antiguo sitio web de WordPress había hecho su trabajo. Había acumulado artículos, imágenes y fragmentos de historia profesional a lo largo de muchos años. Pero mantener un sistema de gestión de contenido basado en bases de datos para un sitio personal había empezado a parecer como mantener un motor en marcha solo para iluminar una lámpara de escritorio.

Quería algo más rápido, fácil de operar y mucho más personal. También quería saber hasta qué punto un socio de programación de IA podría ayudarme a llevar a cabo la migración, no pulsando el mítico botón de «convertir sitio web», sino analizando conmigo las verdaderas decisiones de ingeniería.

El resultado es el sitio que está leyendo ahora: un portafolio hecho a mano y nativo de la nube que se sirve como archivos estáticos a través de Amazon S3 y CloudFront. La escritura antigua sigue disponible, mientras que la nueva página añade fotografías, certificaciones, datos de entrenamiento, juegos pequeños y un relato más completo de mi trabajo.

La parte exitosa no fue reemplazar WordPress por la IA. Era separar el contenido que valía la pena conservar de la maquinaria que ya no se ganaba su lugar.

Primero, defina qué significa realmente «basado en la IA»

El sitio web de producción no necesita un modelo lingüístico para publicar una página. Eso añadiría latencia, complejidad y dependencia sin beneficio para los visitantes comunes. Es un sitio estático y esa es una función.

La IA formó parte del proceso de ingeniería. Ayudó a inspeccionar el material antiguo, a proponer una arquitectura de la información, a redactar y revisar la copia, a generar y refactorizar el código, a descubrir incoherencias, a mejorar el comportamiento de respuesta y a convertir el trabajo manual repetido en guiones. Seguí siendo el propietario del producto: seleccioné el material, corregí las suposiciones, juzgué el resultado visual y aprobé los cambios de producción.

Por lo tanto, «asistido por IA» es la descripción correcta. La información se utilizó durante la creación y el mantenimiento del sitio; el sistema suministrado sigue siendo sencillo.

1. Inventario antes del rediseño

Una migración debe empezar con las pruebas, no con una nueva paleta de colores. Antes de cambiar la presentación, recopilé las entradas, las páginas, las categorías y las referencias multimedia de WordPress. El contenido original se exportó a JSON estructurado y los archivos asociados se copiaron a un archivo local.

Esto creó dos importantes redes de seguridad:

• un archivo de contenido legible por máquina que podría transformarse sin tener que raspar el sitio en vivo repetidamente;
• una mediateca preservada que contiene las imágenes, los documentos y los certificados originales.

También revisé las URL, los títulos, las fechas de publicación, los enlaces internos y el contenido que nunca debería publicarse accidentalmente. Una copia de seguridad completa no es lo mismo que un sitio web público: las exportaciones pueden contener borradores, archivos obsoletos, información personal y credenciales. La conservación y la publicación deben seguir siendo decisiones distintas.

2. Separar el contenido de WordPress

El activo más valioso de WordPress no era el tema, los complementos o el esquema de la base de datos. Era el contenido. Una vez que las publicaciones se representaron como JSON y los medios pasaron a un árbol de archivos normal, la capa de presentación pasó a ser reemplazable.

En la página principal, JavaScript lee los datos del artículo seleccionado y crea las tarjetas Field Notes. Cada artículo también tiene su propia página HTML estática. Esto da a la interfaz la flexibilidad del contenido estructurado y, al mismo tiempo, conserva las URL normales y rastreables para los motores de búsqueda y los lectores que llegan a través de un enlace directo.

Este enfoque de «preservar primero, curar en segundo lugar» evitó un error común de migración: descartar el historial porque el nuevo diseño no tiene ningún lugar obvio donde ponerlo. El archivo sobrevivió primero; las decisiones editoriales llegaron después.

3. Diseñe el nuevo sitio en torno a la persona, no al CMS

WordPress, naturalmente, fomenta que un sitio parezca una secuencia de publicaciones. Mi nueva página necesitaba un centro de gravedad diferente: una presentación, un trabajo profesional, un recorrido por mi carrera, certificaciones, fotografías, progreso de la formación, notas técnicas y un poco de diversión.

Creamos esa estructura directamente en HTML, CSS y JavaScript semánticos. No hay ningún tema de uso general que intente satisfacer a miles de sitios posibles. La navegación, la tipografía, el menú móvil, el marco de las imágenes y los detalles interactivos existen para esta cartera.

El rediseño fue iterativo. Podría ver una vista previa local, decir que un terminal me cubría el brazo, que un retrato parecía recortado o que un encabezado se rompía ante una palabra incómoda, y la implementación podría ajustarse de inmediato. En ese breve ciclo de retroalimentación es donde la colaboración con la IA fue especialmente útil: el juicio visual siguió siendo humano, mientras que traducirlo a CSS funcional se hizo mucho más rápido.

4. Trate las URL antiguas y la visibilidad de las búsquedas como datos de producción

Un rediseño no tiene éxito si la nueva página de inicio tiene un aspecto excelente, pero desaparecen años de material con capacidad de búsqueda. Cada nota seleccionada recibió una URL independiente, un título descriptivo, una metadescripción y una dirección canónica. Las páginas también incluyen metadatos de Open Graph y Twitter para compartir, además de datos estructurados de Schema.org que identifican el contenido como un artículo técnico y lo conectan conmigo como su autor.

El mapa del sitio muestra las páginas principales y las notas archivadas. El sitio me identifica siempre como «Bernd Kuhlen» e incluye «Bernhard Kuhlen» como nombre alternativo. Los robots reciben instrucciones de rastreo explícitas, mientras que las personas y los motores de búsqueda pueden seguir los enlaces normales sin ejecutar la página de inicio interactiva.

Si un enlace permanente antiguo tiene backlinks o historial de búsquedas, debería seguir siendo válido o redirigir permanentemente a su sustituto. El mapeo de URL pertenece al plan de migración, no a la lista de limpieza tras el lanzamiento.

5. Haga que la infraestructura sea aburrida, en el buen sentido

Los archivos finales se almacenan en un depósito S3 privado, cifrado y versionado. CloudFront es el punto de entrada público y accede al depósito a través del control de acceso de Origin, por lo que el almacenamiento en sí no queda expuesto como un sitio web público. Se aplica HTTPS, se requiere un TLS moderno y una política de encabezados de respuesta proporciona los principales encabezados de seguridad del navegador.

La infraestructura se describe en CloudFormation y no se monta únicamente haciendo clic en la consola de AWS. El script de despliegue actualiza la pila, sincroniza una lista explícita de archivos públicos permitidos e invalida la caché de CloudFront. Esto hace que una versión sea repetible y da a los cambios futuros una implementación revisable.

El alojamiento estático elimina la base de datos de WordPress, el tiempo de ejecución de PHP, las actualizaciones de temas y los parches de complementos de la ruta de solicitud. No elimina la responsabilidad operativa, sino que la convierte en un problema más pequeño y observable.

6. Previsualice primero, corte sobre segundo

Durante toda la obra, el sitio funcionó localmente en un contenedor detrás de Nginx. Ese entorno de previsualización permitía probar diseños de escritorio y teléfono, abrir documentos archivados, jugar a los juegos integrados e inspeccionar las listas de entrenamiento antes de que algo llegara a producción.

Un plan de transición segura debe incluir:

1. una congelación del contenido o una exportación final claramente definida;
2. una base de datos completa y una copia de seguridad multimedia;
3. validación local y provisional de URL importantes;
4. registros y certificados de DNS preparados antes del cambio;
5. una ruta de retroceso al origen anterior;
6. comprobaciones posteriores al lanzamiento desde fuera de la máquina de desarrollo.

El control de versiones y la infraestructura de S3 como código ayudan a la recuperación, pero no sustituyen a un procedimiento de reversión deliberado.

7. Añadir observabilidad tras eliminar el servidor de aplicaciones

Un sitio web estático aún puede fallar, atraer bots o generar tráfico inesperado. Registros de acceso de CloudFront, solicitudes de registro, códigos de estado, agentes de usuario y ubicaciones periféricas. Esos registros alimentan un panel de CloudWatch que muestra las familias de volúmenes de acceso y estados HTTP, con un período de retención definido en lugar de una acumulación ilimitada.

Las vistas geográficas ayudan a revelar dónde parece originarse el tráfico, aunque una ubicación límite, un país o una ciudad derivados de la IP nunca deben confundirse con una persona verificada. Los datos operativos responden a las preguntas sobre las solicitudes; rara vez prueban la identidad.

Esta observabilidad también crea una base de referencia útil. En lugar de esperar a que alguien denuncie un enlace roto, puedo ver las tendencias de error e inspeccionar las rutas que se solicitan.

8. Utilice la migración para crear cosas que WordPress nunca alentó

Cuando el sitio dejó de diseñarse según un tema de blog tradicional, fue más fácil añadir funciones que reflejaran mis intereses reales. Las exportaciones de Apple Health se transformaron en vistas agregadas de los entrenamientos diarios, semanales y mensuales. Los certificados se convirtieron en un archivo dedicado y navegable. Las fotografías personales recibieron subtítulos. Dos juegos pequeños, Snake y Galaga, encontraron un lugar en la sección Diversión.

Se siguen entregando como activos estáticos y como código del lado del cliente. El cambio importante no era añadir una plataforma más pesada, sino crear una estructura en la que pudieran coexistir funciones pequeñas y específicas.

Qué hizo bien la IA y dónde necesitó supervisión

La IA era particularmente eficaz en las inspecciones repetitivas, proponiendo transformaciones, produciendo las primeras implementaciones, comprobando el lenguaje y aplicando comentarios detallados en varios archivos. Podría hacer un seguimiento de la relación entre un registro de contenido, la página del artículo, el mapa del sitio y el paquete de despliegue.

Aún requiere verificación. Un enlace plausible puede estar mal. Un diseño técnicamente válido puede resultar incómodo en un teléfono de verdad. La copia generada puede parecer genérica o afirmar más de lo que realmente hace el sistema. Los comandos de infraestructura pueden tener consecuencias que van mucho más allá de un error tipográfico en un párrafo.

El flujo de trabajo más productivo era conversacional, pero disciplinado: inspeccionar el sistema real, hacer un cambio limitado, previsualizarlo, probarlo y solo después publicarlo. La IA aceleró ese ciclo, no lo eliminó.

Una lista de verificación de migración repetible

1. Haga una copia de seguridad de la base de datos, las cargas y la configuración de WordPress.
2. Exportar publicaciones, páginas, taxonomías, fechas, autores y referencias a los medios.
3. Clasifique el contenido como público, privado, obsoleto o incierto.
4. Cree un inventario de URL y un mapa de redireccionamientos.
5. Elija la arquitectura de destino más sencilla que cumpla con los requisitos reales.
6. Cree un sistema de diseño pequeño y plantillas de contenido reutilizables.
7. Genere páginas semánticas independientes para el material que debería poder buscarse.
8. Añada metadatos, URL canónicas, datos estructurados, reglas de robots y un mapa del sitio.
9. Pruebe la accesibilidad, los diseños adaptables, los enlaces, los documentos y las páginas de error.
10. Describa la infraestructura y el despliegue en código.
11. Pase con copias de seguridad, monitorización y una ruta de reversión probada.
12. Guarde el archivo hasta que el nuevo sitio haya demostrado su eficacia.

La compensación

Un sitio estático no es automáticamente el sustituto correcto para todas las instalaciones de WordPress. Una redacción con muchos editores no técnicos, flujos de trabajo complejos, comentarios o datos del lado del servidor que cambian con frecuencia puede seguir beneficiándose de un CMS maduro o de un CMS independiente con una interfaz estática.

Para una cartera personal mantenida mediante código, el saldo es diferente. Cambié la comodidad de editar las publicaciones en un navegador por una superficie de ataque más pequeña, una entrega predecible, cambios de versión y un control total de la experiencia. La IA redujo la fricción de ese flujo de trabajo basado en códigos lo suficiente como para hacer que la operación fuera atractiva.

Última comida para llevar

El antiguo sitio de WordPress no lo tiraron a la basura. Se desmanteló con cuidado: se conservó el contenido, se promocionaron las partes útiles, se reconstruyó la presentación y se simplificó la infraestructura.

Esa es la lección de migración, repetiría. No empiece por preguntar qué producto de IA debe reemplazar a WordPress. Empiece por preguntarse qué debe sobrevivir, qué es lo que realmente tiene que hacer el sitio y qué complejidad se puede eliminar. Luego, utilice la IA como un socio de ingeniería capaz: curioso, rápido y útil, pero siempre trabajando en función de archivos reales, pruebas reales y el juicio humano.