Te piden un rediseño. Colores, tipografías, maquetación. Aceptas, abres el sitio y descubres que el problema no está en la superficie. Eso me pasó con la web de Libelium, fabricante de hardware IoT de extremo a extremo, cuya plataforma de software como servicio es iris360. Terminé reconstruyendo la arquitectura entera, y este es el relato de por qué y de qué aprendí.
Una nota de método. Cada cifra sale de un fichero del proyecto. Cuando no existe, lo digo.
Pintar la fachada de un edificio con cimientos torcidos
Si te encargan pintar la fachada y al subir al andamio ves grietas en la estructura, puedes pintar igualmente y cobrar. O puedes avisar de que la pintura se caerá en un año. Yo avisé y amplié el alcance.
El encargo que escondía otro
Debajo del diseño había un único tipo de contenido que mezclaba 129 casos de éxito, 99 noticias, 53 artículos y 25 informes. Las fichas técnicas vivían dentro del editor visual y cada producto repetía sus datos. El mapa del sitio para asistentes de IA listaba 5 casos de éxito de más de 130 publicados. Los widgets dependían de plugins de terceros con vulnerabilidades conocidas y sin parchear, sobre un servidor con versiones sin soporte y sin caché de objetos.
El briefing del equipo de marketing iba más lejos que el encargo inicial. El tráfico orgánico tradicional cae y crecen las respuestas mediadas por IA, así que la web debía funcionar para buscadores clásicos, para asistentes que recuperan contenido y para modelos generativos que citan fuentes. Esas tres capas son SEO, AIO y GEOGlosarioAIO y GEODos capas de optimización que se suman al SEO clásico. AIO (AI Optimization) busca que el contenido sea comprensible para asistentes de IA mediante estructura clara, entidades definidas y datos legibles por máquina. GEO (Generative Engine Optimization) busca que una marca aparezca y se cite en las respuestas de los motores generativos. Las dos dependen de los mismos cimientos técnicos que el SEO, como el marcado estructurado y un archivo llms.txt.Ver término completo →. El documento no cuantificaba la caída de tráfico ni fijaba línea base alguna, y dos reglas suyas condicionaron cada decisión posterior. Ninguna URL con valor se elimina sin destino equivalente y redirección validada. Ningún KPI se promete sin línea base, fuente y responsable.
El 19 de agosto levanté un stack Docker vacío y esa tarde importé la base de datos de producción, de 1,04 GB. Siete semanas después, el 7 de octubre, se ejecutó el corte.
Separar la página del dato
La decisión de más peso fue separar el contenido público de los datos que lo alimentan. La página de un producto tiene su URL y su posicionamiento. Su ficha técnica no tiene URL y vive aparte. Las sondas, las tecnologías de conexión y las certificaciones son tipos propios que varios productos comparten. Quien edita un dispositivo marca una sola vez qué sensores admite, y esa relación sirve a la página, a la búsqueda interna y a cualquier asistente conversacional.
Las verticales cruzan lo demás. Una misma etiqueta de sector une soluciones, productos, casos de éxito y recursos sin enlazarlos a mano, de modo que un lector puede entrar por cualquier rama y llegar a la solución que busca.
El detalle del modelo está en separar la página del dato técnico en WordPress.
Un sitio que también habla con máquinas
Con los datos ordenados, el motor propio puede decir a buscadores y asistentes qué es cada página. Una solución sale como producto con su problema resuelto. Un caso de éxito sale como artículo. El sitio antiguo servía el mismo esquema genérico en todas partes. Además, el mapa en texto plano para asistentes pasó de 31 páginas a 158 en el entorno de pruebas, con un coste que no escondo. Pesaba quince veces más y tuve que recortarlo. El recorrido completo está en llms.txt, JSON-LD y GEO en WordPress, y el fundamento en navegación agéntica y SEO para IA.
Mis widgets en lugar de plugins ajenos
Construí una biblioteca propia de widgets de Elementor. Hoy suma 59 y ningún texto, lista ni icono de negocio va fijo en el código. El 3 de octubre migré 126 widgets de tres plugins de terceros repartidos en 355 entradas. Un código propio se puede auditar y no depende de que otro siga manteniendo su plugin. A cambio, la responsabilidad pasa a quien mantiene el stack, y eso es un coste continuo.
Dos marcas, un monorepo
El repositorio de iris360 nació el 16 de septiembre como clon del de Libelium. Dos copias del mismo tema empiezan a divergir desde el primer día, así que extraje los widgets a un paquete común y acabé en un monorepoGlosarioMonorepoRepositorio de control de versiones que aloja varios proyectos, paquetes o sitios en un único árbol de código. Aplicado a WordPress con varias marcas, un monorepo guarda una sola copia del tema, del motor y de los widgets compartidos, y una carpeta por sitio con lo que es propio de cada uno. Evita las copias divergentes de los repositorios clonados y los commits de actualización de puntero de los submódulos de Git.Ver término completo → con una sola copia de tema, motor y widgets y una carpeta por sitio. La marca activa es una opción de WordPress y todo lo que cambia entre marcas cuelga de ella. Yo había propuesto primero un Multisite, y expliqué por qué lo descarté en WordPress en monorepo en vez de multisite.
Hubo un camino que retiré. Cada landing era una clase PHP sincronizada con su post de Elementor, 29 en total, con dos fuentes de verdad que producían conflictos. Ahora el contenido se edita solo en Elementor y se protege con copias automáticas cada dos horas. Lo cuento en retirar el generador de landings.
El rendimiento escondía otro fallo de arquitectura
Al rastrear 146 rutas con Lighthouse, las páginas de verticales puntuaban entre 0,09 y 0,33 en rendimiento. El tema no tenía plantilla de archivo para taxonomías, WordPress caía en la genérica y Elementor devolvía la página completa de cada entrada, hasta diez diseños apilados en un listado. Una plantilla con tarjetas resumidas llevó una ruta de 0,09 a 0,31, redujo el HTML de 528 KB a 121 KB y bajó el desplazamiento de maquetación de 0,801 a 0. Esas cifras miden una ruta en local sobre la web nueva y no comparan con el sitio antiguo. El análisis está en el archivo de taxonomías que apilaba páginas.
Migrar 746 rutas sin perder señales
Un script leyó los sitemaps antiguos, probó cada ruta contra la web nueva y las clasificó. Auditamos 726 rutas de Libelium y 20 de iris360. Lo que más importa es qué pasó entre la víspera del corte y el día del corte.
| Libelium, 726 rutas | 6 de octubre | 7 de octubre |
|---|---|---|
| 301 correcto en un salto | 38 | 324 |
| Cadenas de 2 a 4 saltos | 257 | resueltas |
| Error 404 | 35 | 6 |
Otras 396 respondían 200 directamente. Dos reglas con comodín cubren 254 URLs del antiguo tipo de contenido, y los seis 404 restantes son tres entradas, cada una en español e inglés, sin decisión tomada. Los barridos se hicieron contra los dominios de pruebas. El proceso entero está en migrar 746 rutas sin perder señales.
Una regla de verdad para los datos de producto
Reconstruí cinco fichas de producto y encontré dimensiones sin respaldo, 22 sondas genéricas con códigos inventados y 17 enlaces de datasheet que daban 404. Fijé una regla simple. Si el datasheet vigente y la web antigua coinciden, ese es el valor. Si el datasheet trae medidas nuevas, manda el datasheet. Lo que solo existe en la web nueva se elimina. Quedaron 134 sondas reales. La regla está en una regla de verdad para los datos de producto.
Con un agente de IA como pareja
Todo esto lo hice con un agente de IA que editaba código y escribía en producción. Se equivocó, y por eso las reglas viven en el repositorio y cada escritura sigue un patrón de simulación, copia y una sola aplicación. Los errores ocurrieron igualmente, pero costaron poco. Los cuento en programar con un agente de IA.
Lo que aún no sé
El corte llegó cinco días después de la ventana prevista, que iba del 28 de septiembre al 2 de octubre. No existe un barrido registrado contra los dominios definitivos y no hay medición posterior de velocidad, tráfico, posicionamiento ni conversión. La ficha de KPI que exige el briefing todavía no existe. Cuando haya datos, actualizaré este caso.
Me llevo una idea para cualquier rediseño. Antes de aceptar el alcance, mira qué hay debajo de la superficie, porque el rediseño visual se volvió el síntoma de un problema de modelo de datos. Y decide qué quieres poder demostrar, porque yo gané mucho por escribir las reglas antes de tocar nada, y lo que no medí, no lo afirmo.