Arquitectura de información en Webflow: lo que pasa antes de abrir el Designer

Existe un patrón que se repite en la mayoría de los proyectos Webflow que llegan a Literal con problemas: el activo se ve razonablemente bien, el diseño es decente, pero algo no funciona. Las URLs son inconsistentes. El CMS tiene campos que nadie sabe para qué sirven. La navegación no refleja cómo piensa el usuario. El blog y el portfolio comparten lógica pero están construidos de formas distintas. Y añadir una nueva sección requiere decisions que deberían haberse tomado al principio.

El diagnóstico casi siempre es el mismo: el proyecto empezó en el Designer sin haber definido antes la arquitectura de información. Se diseñó la interfaz antes de entender la estructura. Y ese orden invertido es la causa raíz de la mayoría de los problemas de escalabilidad, mantenimiento y visibilidad que aparecen después.

Qué es la arquitectura de información y por qué determina todo

La arquitectura de información (AI) es el mapa que define qué contenido existe en el activo, cómo se organiza, cómo se relaciona entre sí y cómo lo encuentra el usuario. No es el diseño visual ni la estructura del código: es la capa lógica que existe entre el negocio y la interfaz, y que determina las decisiones de ambas.

En el contexto de un proyecto Webflow, la AI define cuántas páginas existen y cuál es su jerarquía, qué colecciones del CMS son necesarias y qué campos componen cada una, cómo se relacionan entre sí los distintos tipos de contenido, qué URLs va a tener el activo y cómo reflejan la estructura de la información, y cómo va a navegar el usuario desde la home hasta cualquier punto de conversión.

Cada una de estas decisiones tiene consecuencias directas en el SEO, en el GEO y en el coste de mantenimiento del activo. Y todas ellas son mucho más costosas de cambiar después de que el proyecto está construido que antes de empezar.

El sitemap como documento de ingeniería

En Literal, el primer entregable de cualquier proyecto no es un wireframe ni un diseño. Es un sitemap — pero no el tipo de sitemap que es una lista de páginas en un archivo XML. Es un documento de arquitectura que mapea la estructura completa del activo con sus relaciones, su jerarquía y sus implicaciones para el CMS.

Un sitemap de ingeniería responde preguntas que un sitemap convencional ignora. No solo dice que existe una página de servicios: dice si esa página es una página estática con el contenido hardcodeado o si es un template dinámico que renderiza items de una colección. No solo dice que hay un blog: dice qué campos componen cada artículo, qué taxonomías existen, cómo se filtran los artículos y si hay relaciones con otros tipos de contenido. No solo lista las URLs: define la convención de nomenclatura que se va a usar en todo el activo y cómo va a escalar cuando se añadan nuevas secciones.

Este nivel de detalle en la fase previa al diseño tiene un beneficio inmediato: cuando se abre el Designer por primera vez, todas las decisiones estructurales ya están tomadas. El equipo de diseño trabaja sobre una estructura definida, no sobre suposiciones que habrá que validar más tarde.

El CMS como base de datos, no como colección de páginas

Uno de los errores más frecuentes en proyectos Webflow es tratar el CMS como un repositorio de páginas en lugar de como una base de datos de entidades con relaciones. La diferencia no es semántica: tiene consecuencias directas en cómo escala el activo y en cómo lo procesan los motores de búsqueda y los modelos de lenguaje.

En la fase de arquitectura de información, definimos el esquema del CMS antes de crear ninguna colección en Webflow. Qué tipos de entidad existen, qué campos tipados los componen, qué relaciones hay entre colecciones — un artículo del blog que referencia a una categoría, un caso de éxito que referencia tecnologías y servicios, un miembro del equipo que referencia proyectos en los que ha participado. Estas relaciones son las que convierten el CMS de un gestor de contenido plano en un grafo de entidades que los modelos de lenguaje pueden recorrer y verificar.

La especificidad del esquema también determina la calidad de los datos estructurados JSON-LD que se pueden generar automáticamente. Un CMS bien diseñado permite inyectar Schema precisos en cada tipo de página sin trabajo manual: cada artículo sabe que es un TechnicalArticle con su autor, su fecha y su categoría; cada caso de éxito sabe que es un workExample del servicio correspondiente. Un CMS mal diseñado hace que esos datos estructurados sean imposibles de mantener a escala.

La taxonomía de URLs como decisión de posicionamiento

La estructura de URLs de un activo no es un detalle técnico. Es una señal de relevancia que Google y los modelos de lenguaje leen para entender la jerarquía del contenido y la especialización del dominio.

En la fase de arquitectura de información, definimos la convención de URLs antes de crear ninguna página. Para Webflow, esto implica decidir si las colecciones del CMS van a tener prefijos de ruta — /blog/nombre-articulo vs /nombre-articulo — cómo se van a nombrar los slugs para que sean descriptivos y consistentes, y qué jerarquía refleja mejor la estructura temática del activo para el posicionamiento.

Una convención de URLs inconsistente — donde algunos artículos están en /blog/, otros en /recursos/ y otros en la raíz — fragmenta la autoridad temática del dominio. Google y los LLMs interpretan la consistencia de las URLs como una señal de organización y rigor. Y una vez que las URLs están publicadas, cambiarlas tiene un coste de redirecciones y pérdida temporal de posicionamiento que es mucho más alto que haberlas definido bien desde el principio.

Cómo afecta la AI al GEO

La arquitectura de información tiene un impacto directo en la citabilidad del activo por los modelos de lenguaje. Los LLMs no indexan páginas aisladas: construyen una comprensión del activo como conjunto. Un activo con una estructura de información clara — donde cada sección tiene un propósito definido, donde las relaciones entre tipos de contenido están declaradas, donde las URLs reflejan la jerarquía temática — es un activo que los modelos de lenguaje pueden modelar con precisión.

Por el contrario, un activo con una estructura de información ambigua — páginas cuyo propósito no está claro, contenido duplicado en secciones distintas, relaciones entre entidades no declaradas — es un activo que los LLMs procesan con baja confianza. Y cuando la confianza es baja, la citabilidad cae.

En Literal, la fase de arquitectura de información no es solo una preparación para el diseño. Es la base del GEO: la decisión que determina si el activo va a ser comprensible y citable para los sistemas que están redefiniendo cómo se descubre una marca.

Conclusión: el orden importa

La tentación de empezar a diseñar antes de tener la arquitectura definida es comprensible — es más visible, es más tangible, produce resultados rápidos que se pueden mostrar. Pero cada decisión de diseño tomada antes de tener la estructura definida es una decisión que puede necesitar rehacerse cuando la estructura emerja más tarde.

En Literal, la arquitectura de información no es un paso previo al trabajo real. Es el trabajo más importante del proyecto, porque determina la calidad de todo lo que viene después: el CMS, el SEO, el GEO, el mantenimiento y la escalabilidad del activo a largo plazo.

Antes de abrir el Designer, hay que saber exactamente qué se va a construir y por qué. Ese es el estándar con el que trabajamos.