La arquitectura de información web define cómo se inventaría, agrupa, nombra, jerarquiza y conecta el contenido para que personas y buscadores puedan encontrarlo. Incluye taxonomía, navegación, URLs, búsqueda interna y relaciones contextuales. No es dibujar un sitemap al final: comienza con necesidades y evidencia, se prueba antes del diseño visual y se mantiene cuando cambian productos y contenidos.
Un menú corto puede ocultar una arquitectura confusa y un menú grande puede ser claro si sus categorías responden a tareas. La calidad no se mide por cantidad de niveles, sino por la capacidad de predecir dónde está la información y completar un recorrido.
Qué es arquitectura de información
Es la práctica de convertir un inventario heterogéneo en un sistema comprensible. Define unidades de contenido, relaciones, etiquetas y reglas de crecimiento. En un ecommerce organiza categorías, atributos, filtros y productos; en un sitio B2B conecta problemas, servicios, sectores, recursos y contacto.
La arquitectura no es solo jerarquía. Un contenido puede pertenecer a una categoría principal y ser accesible desde búsqueda, enlaces relacionados, filtros y recorridos por tarea. Esos caminos deben conservar una URL canónica clara.
Componentes de una arquitectura web
Inventario. Qué páginas, archivos, datos y funciones existen.
Taxonomía. Qué categorías, atributos y relaciones los describen.
Jerarquía. Qué depende de qué y qué nivel de detalle ocupa.
Etiquetado. Cómo se nombran categorías, enlaces y acciones.
Navegación. Menús globales, locales, breadcrumbs y enlaces contextuales.
Búsqueda. Índice, sinónimos, filtros y respuesta a cero resultados.
URL y metadatos. Identidad estable, canonical, idioma y datos estructurados.
Investigar antes de estructurar
Reúne objetivos, consultas de búsqueda, entrevistas, tickets, navegación, búsqueda interna y lenguaje comercial. No copies el organigrama: el usuario no tiene por qué saber qué área administra cada servicio.
Crea tareas representativas: “comparar planes”, “encontrar requisitos”, “devolver un pedido”. Segmenta por rol, mercado y conocimiento. La misma etiqueta puede funcionar para expertos y fallar para nuevos usuarios.
Audita competidores para reconocer convenciones, no para replicar. Una estructura frecuente puede ser familiar o una mala práctica compartida.
Inventario y auditoría de contenido
Registra URL, título, tipo, idioma, propietario, tráfico, enlaces, conversión, actualización, indexación y acción propuesta. Las acciones típicas son mantener, mejorar, fusionar, redirigir, archivar o eliminar.
Detecta duplicados por intención, no solo por texto. Dos páginas distintas pueden competir por la misma necesidad; una sola puede mezclar intenciones incompatibles.
Asigna responsable y ciclo de vida. Una taxonomía sin gobernanza acumula categorías vacías, etiquetas duplicadas y páginas huérfanas.
Diseñar taxonomías y jerarquías
Las categorías deben ser mutuamente comprensibles y suficientemente completas para el alcance, sin forzar cada elemento a una única dimensión. Separa categoría editorial de atributo filtrable.
Usa etiquetas concretas y lenguaje de usuario. “Soluciones” y “recursos” pueden ser demasiado vagos sin contexto. Evita mezclar objetos —“Zapatos”— con audiencias —“Para empresas”— en el mismo nivel salvo que el modelo lo justifique.
Limitar niveles reduce complejidad, pero aplanar todo crea listas inmanejables. Diseña profundidad según relaciones y prueba la encontrabilidad.
Card sorting: generar opciones
En un card sorting, participantes agrupan contenidos y pueden proponer nombres. El abierto explora modelos; el cerrado evalúa categorías dadas; el híbrido combina. Selecciona tarjetas representativas y evita duplicados obvios.
Nielsen Norman Group advierte que el card sorting no produce automáticamente la arquitectura final. Los participantes pueden crear una categoría “otros” útil para completar el ejercicio pero inútil como menú.
Analiza acuerdos, desacuerdos y razones. El resultado alimenta alternativas junto a restricciones legales, SEO y operación.
Tree testing: evaluar la jerarquía
El tree test presenta la estructura textual, sin diseño visual, y pide encontrar destinos mediante tareas. Mide éxito, ruta directa, tiempo y retrocesos. Permite corregir etiquetas y categorías antes de construir pantallas.
Card sorting es principalmente generativo; tree testing es evaluativo. Una secuencia común audita el sitio, explora agrupaciones, crea árboles y prueba tareas críticas.
No redactes la tarea usando la misma palabra del menú: regalaría la respuesta. Prueba con participantes relevantes y analiza rutas erróneas, no solo porcentaje final.
Navegación, enlaces y breadcrumbs
El menú global muestra áreas estables; la navegación local desarrolla la sección; breadcrumbs expresan jerarquía; enlaces contextuales conectan decisiones. No obligues al menú principal a contener todo.
Los enlaces importantes deben ser elementos rastreables con destinos reales. Google recomienda enlaces <a> con href resoluble. Un componente que navega solo mediante JavaScript puede limitar descubrimiento.
El texto del enlace anticipa destino. “Ver requisitos de envío” informa más que “ver más”. Conserva foco, teclado y estados accesibles.
Estructura URL y SEO
Una URL legible puede reflejar contenido sin copiar cada nivel del menú. Evita cambiarla por ajustes menores de categoría. Define reglas para slugs, parámetros, paginación, filtros, idiomas y canonicals.
La profundidad de clic importa más que contar barras. Páginas estratégicas necesitan enlaces internos desde contextos relevantes. Un sitemap XML ayuda al descubrimiento, pero no sustituye arquitectura ni enlaces rastreables.
Arquitectura y conversión
La arquitectura reduce carga de decisión cuando agrupa opciones comparables y presenta el siguiente paso. Una persona debe entender qué servicio corresponde, qué incluye y dónde actuar.
No escondas información crítica para forzar contacto. Precio, alcance, políticas o compatibilidad pueden ser necesarios antes del CTA. Mide búsqueda interna, retrocesos, cero resultados, ruta y finalización.
Búsqueda interna, filtros y sinónimos
La búsqueda es una ruta complementaria, no una excusa para abandonar navegación. Indexa contenido útil, reconoce errores frecuentes y ofrece resultados con títulos, tipos y contexto. Un cero resultados debe sugerir alternativas y registrar la consulta.
Los filtros expresan atributos estables: talla, ubicación, industria o fecha. Define combinaciones indexables según demanda y valor; el resto puede permanecer funcional sin crear miles de URLs rastreables. Evita filtros duplicados con nombres distintos.
Construye un diccionario de sinónimos con lenguaje de usuarios, negocio y especialidad. “Celular”, “móvil” y “smartphone” pueden referir al mismo concepto en mercados diferentes. Revisa consultas internas para descubrir términos que la navegación no contempla.
Modelos de contenido y componentes
Un modelo define campos y relaciones de cada tipo: servicio, autor, producto, destino o evento. Separar nombre, resumen, requisitos, precio y relación permite presentar el mismo contenido en página, buscador y componente sin copiarlo manualmente.
Las relaciones deben tener significado. “Contenido relacionado” calculado solo por fecha rara vez ayuda. Define si la conexión es requisito, alternativa, siguiente paso, ubicación o categoría. Esto también mejora enlaces internos y datos estructurados.
El modelo necesita validaciones: campos obligatorios, vocabularios, unicidad, idioma y estado. Una arquitectura visual perfecta se degrada si el CMS permite categorías escritas de cinco formas.
Accesibilidad y arquitectura móvil
La arquitectura debe funcionar con teclado, lector de pantalla, zoom y distintos dispositivos. Un menú oculto tras gestos sin alternativa vuelve invisible la estructura. Encabezados jerárquicos, landmarks, foco y nombres accesibles ayudan a navegar.
En móvil hay menos espacio, no menos necesidades. Prioriza tareas, permite volver, conserva contexto y evita menús con capas que se cierran accidentalmente. No elimines información crítica solo porque la pantalla es pequeña.
Prueba con contenido real y textos largos. Traducciones, nombres de producto y preferencias de tamaño pueden romper etiquetas que funcionaban en un prototipo corto.
Cómo medir la arquitectura después de publicar
Observa éxito y directitud en tareas, uso de navegación, búsqueda interna, cero resultados, retrocesos, páginas huérfanas y rutas a acciones. Un aumento de búsqueda puede indicar preferencia o falla del menú; necesita contexto.
Search Console ayuda a evaluar consultas y páginas orgánicas, pero no explica el recorrido interno completo. Analítica muestra rutas observables con límites de consentimiento. Soporte aporta lenguaje y problemas que nunca llegan a una página.
Crea una línea base antes de migrar y segmenta por dispositivo y tarea. Si cambia contenido, diseño y URLs al mismo tiempo, declara que el efecto no puede atribuirse solo a la arquitectura.
Ejemplo hipotético
Ejemplo hipotético. Una consultora organiza el menú por departamentos internos: Estrategia, Operaciones y Transformación. Los usuarios buscan “implementar CRM” y alternan entre tres áreas.
El inventario revela páginas duplicadas. Entrevistas y card sorting proponen categorías por problema. Un tree test muestra que “Automatización comercial” funciona mejor que “Transformación”. Se crea una página canónica de CRM y enlaces desde sectores.
La mejora se valida con éxito en tareas, menor uso de búsqueda interna y formularios cualificados. No se atribuye todo cambio a navegación porque también se fusionó contenido.
Migrar una arquitectura sin perder rutas
- Congela inventario de URLs y señales.
- Mapea cada URL vieja a una nueva equivalente.
- Evita cadenas y redirecciones a destinos genéricos.
- Actualiza enlaces, canonical, hreflang y sitemap.
- Prueba 301, 200 final y ausencia de bucles.
- Publica con rollback y monitoreo.
- Conserva redirecciones mientras sigan siendo útiles.
Google recomienda preparar el mapeo y monitorear una migración con cambios de URL. Un 301 no vuelve equivalente un destino irrelevante.
Gobernanza y mantenimiento
Define quién crea categorías, criterios mínimos, convención de nombres, revisión y retiro. Toda página necesita propósito, propietario y lugar.
Revisa trimestralmente búsquedas sin resultado, páginas huérfanas, categorías vacías y crecimiento de parámetros. Una auditoría SEO puede identificar fallas técnicas; la investigación comprueba si la estructura tiene sentido.
Antes de crear una sección, exige propósito, audiencia, diferencia frente a categorías existentes, volumen inicial, responsable y criterio de retiro. Publicar una categoría vacía para “llenarla después” crea rutas débiles y deuda editorial.
Documenta excepciones. Un mismo elemento puede necesitar dos caminos visibles por modelos mentales distintos, sin duplicar la página. La gobernanza decide cuándo esa polijerarquía ayuda y cuándo multiplica mantenimiento.
Mantén un registro de decisiones con evidencia, alternativa descartada y fecha de revisión. Cuando cambien portafolio o lenguaje, el equipo podrá actualizar la estructura sin repetir debates ni conservar categorías cuya razón original desapareció.
Errores frecuentes
- Copiar el organigrama.
- Diseñar el menú antes del inventario.
- Usar etiquetas internas o vagas.
- Tomar card sorting como resultado final.
- No hacer tree testing.
- Crear una URL por cada filtro.
- Cambiar slugs sin mapeo.
- Olvidar gobierno y ciclo de vida.
Fuentes consultadas
Consulta documental: 10 de septiembre de 2026.
- Nielsen Norman Group: tree testing.
- GOV.UK: hacer un servicio simple.
- Google Search Central: enlaces rastreables.
- Google Search Central: migraciones con cambios de URL.
Preguntas frecuentes sobre arquitectura de información
¿Qué es arquitectura de información web?
Es organizar, nombrar y conectar contenido para que personas y buscadores puedan encontrarlo y comprenderlo.
¿Es lo mismo que un sitemap?
No. Un sitemap representa parte de la estructura; la arquitectura incluye taxonomía, navegación, búsqueda, etiquetas y gobierno.
¿Qué diferencia hay entre card sorting y tree testing?
Card sorting genera opciones de agrupación; tree testing evalúa si una jerarquía propuesta permite encontrar destinos.
¿Cuántos niveles debe tener un sitio?
No existe cifra universal. Usa los niveles necesarios para relaciones claras y valida tareas, sin listas planas ni profundidad innecesaria.
¿La URL debe copiar toda la jerarquía?
No siempre. Debe ser estable y comprensible; la jerarquía también se comunica con navegación, enlaces y breadcrumbs.
¿Cómo revisar la arquitectura de mi sitio?
Prepara inventario, objetivos y tareas críticas. Puedes contactar a SEOMOS para revisar UX, contenido y SEO.
