Qué es arquitectura de información y por qué define el éxito
Arquitectura de información (IA, no confundir con inteligencia artificial) es la disciplina de organizar, etiquetar y estructurar el contenido de un sitio web para que los usuarios encuentren rápidamente lo que buscan, sin pensar. Es invisible cuando está bien hecha y dolorosa cuando está mal.
La diferencia entre dos sitios con el mismo contenido y la misma estética puede ser brutal: uno tiene tasa de conversión del 3.8% y otro del 0.7% solo por arquitectura de información. El primero ordena el contenido como el usuario espera; el segundo lo ordena como la empresa internamente lo piensa.
Para Google, una buena arquitectura es factor SEO directo: facilita el crawl, distribuye autoridad por internal linking, y crea estructuras claras que el algoritmo entiende como “este sitio cubre el tema de forma organizada”. Sitios con IA caótica son penalizados implícitamente: Google los considera menos autoritativos en sus temas.
Card sorting: cómo entender el modelo mental del usuario
Card sorting es la técnica de UX research más cost-effective para diseñar arquitectura de información. Consiste en pedir a usuarios reales que agrupen tarjetas con nombres de contenido en categorías que ellos definan. Revela cómo piensa el usuario, no cómo asume la empresa.
Card sorting abierto
El usuario crea sus propias categorías y nombra cada grupo. Útil para sitios nuevos donde no hay estructura previa. Revela vocabulario natural del usuario.
Card sorting cerrado
El usuario asigna tarjetas a categorías predefinidas. Útil para validar una propuesta de arquitectura. Revela si las categorías propuestas son comprensibles.
Card sorting híbrido
Categorías iniciales propuestas pero el usuario puede crear nuevas o renombrar. Equilibrio práctico para iteración rápida.
Herramientas para hacer card sorting
OptimalSort y UserZoom son las herramientas profesionales. Para presupuesto bajo, Trello, Miro o Google Forms con texto libre funcionan. Mínimo 8-12 participantes representativos del público objetivo para tener señal estadística.
Sitemaps lógicos vs sitemaps técnicos
Hay dos tipos de sitemaps que conviven en arquitectura web. Confundirlos es error común.
Sitemap lógico (UX/IA)
Diagrama jerárquico que muestra cómo se organiza el contenido visualmente para el usuario. Refleja menús, breadcrumbs, secciones. Es el output del proceso de IA. Se hace antes de programar nada.
Sitemap técnico (XML para SEO)
Archivo sitemap.xml que lista todas las URLs indexables del sitio para que Google las descubra. SEOPress Pro y Yoast lo generan automáticamente. Es input para SEO técnico, no para diseño UX.
Diferencia práctica
El sitemap lógico puede tener 30 nodos visibles para usuario (menú principal, footer). El sitemap técnico tendrá 500 URLs (todos los posts, productos, taxonomías). Ambos son necesarios y diferentes.
Taxonomía: categorías, etiquetas, tipos de contenido
WordPress permite organizar contenido con tres mecanismos. Usarlos bien marca la diferencia entre sitio prolijo y caos.
Custom Post Types (tipos de contenido)
Para tipos diferentes de contenido (no son posts ni páginas). Ejemplos: productos, casos de éxito, eventos, cursos, FAQs. Cada tipo tiene su propia estructura de campos y permalinks.
Categorías (taxonomía jerárquica)
Para clasificación principal y mutuamente excluyente del contenido. Ejemplo: un post pertenece a la categoría “SEO” o “Diseño Web”, no a ambas. Genera estructura jerárquica con padres e hijos.
Etiquetas (taxonomía no jerárquica)
Para descriptores transversales no excluyentes. Un post puede tener etiquetas “WordPress”, “BerqWP”, “LiteSpeed” simultáneamente. NO crear etiquetas porque sí: solo etiquetas que tendrán al menos 5+ posts asociados, sino se diluye autoridad.
Custom Taxonomies
Para clasificaciones específicas que no encajan en categorías ni etiquetas. Ejemplo: en un sitio de inmobiliaria, “Tipo de propiedad” (casa, apartamento, lote) y “Estado” (venta, arriendo) son taxonomías separadas que se cruzan.
Navegación primaria, secundaria y contextual
Tres niveles de navegación coexisten en sitios bien diseñados. Cada uno tiene función específica.
Navegación primaria
El menú principal en el header. Contiene 5-8 links a las secciones más importantes. NO debe tener todo: solo lo crítico. La regla del “ascensor”: si tiene que explicar qué es cada sección, sobra.
Navegación secundaria
Menú de footer, sidebar, o mega menus expandidos. Contiene navegación de soporte: políticas legales, FAQ, contacto, redes sociales, información secundaria. NO debe duplicar el primario.
Navegación contextual
Links dentro del contenido (artículos, fichas de producto). “Ver también”, “Artículos relacionados”, breadcrumbs, links inline. Es la navegación más poderosa para SEO porque distribuye autoridad y mantiene al usuario engaged.
Reglas para no fallar
Consistencia: el menú primario debe verse igual en todas las páginas. Predictibilidad: links nombrados igual que su destino (no “Aprende más” sino “Servicios de SEO”). Reciprocidad: si A linkea a B, B debería linkear a A o a un nodo padre común.
Breadcrumbs: cuándo agregan valor real
Las migas de pan (breadcrumbs) son la línea horizontal tipo “Inicio > Servicios > Diseño Web > Bucaramanga” que ubica al usuario en la jerarquía del sitio.
Cuándo SÍ usar breadcrumbs
Sitios con jerarquía profunda (3+ niveles): e-commerce con categorías y subcategorías, blogs con muchas categorías, portales de servicios por ciudad, plataformas educativas con cursos por área.
Cuándo NO usar breadcrumbs
Sitios planos con 1-2 niveles (landing pages, sitios brochure pequeños). Solo añaden ruido visual sin valor.
Breadcrumbs y SEO
Schema BreadcrumbList implementado correctamente aparece en SERPs reemplazando la URL. Mejora CTR en búsquedas. SEOPress Pro lo implementa con un toggle.
Breadcrumbs y accesibilidad
Usar nav con aria-label=“Breadcrumb”. Marcar la página actual con aria-current=“page”. Esto permite a screen readers anunciarlo correctamente.
Buscadores internos: el componente que casi nadie optimiza
El buscador interno es donde los usuarios “rebeldes” que no quieren navegar van directo. Si funciona mal, pierde esa intención de búsqueda.
Datos que justifican optimizar
Estudio de Baymard: 30% de visitantes en sitios e-commerce usan el buscador interno. Esos usuarios convierten 2-3x más que los que solo navegan. Pero el 50% de búsquedas internas no devuelven resultados relevantes en sitios sin optimizar.
Tipos de buscador
WordPress nativo: básico, sin ranking inteligente, no maneja typos. Reemplazar siempre. Plugins: SearchWP (premium, excelente ranking custom), Relevanssi (bueno y gratis), Algolia (premium, búsqueda enterprise). Para e-commerce: Doofinder (especializado, AI search).
Qué optimizar
Autocomplete con sugerencias mientras se escribe. Tolerancia a typos (“zapato” debe encontrar resultados de “zapaots”). Sinónimos manuales (en e-commerce de calzado, “tenis” y “deportivos” deben dar mismos resultados). Logging de búsquedas sin resultados para detectar gaps de contenido.
Profundidad de navegación: la regla de los 3 clicks
La regla histórica dice “ningún contenido debe estar a más de 3 clicks desde la home”. Es una guía útil pero no dogma absoluto.
Por qué 3 clicks importa
Para SEO: páginas a 4+ clicks de la home reciben menos PageRank interno (Google las considera menos prominentes). Para UX: cada click adicional aumenta probabilidad de abandono según estudios de Nielsen Norman Group.
Excepciones legítimas
E-commerce con catálogos masivos (10K+ productos) puede tener 4-5 niveles. Se soluciona con buscador interno potente y filtros faceted search. Plataformas educativas con módulos largos: 4-6 niveles aceptables si la jerarquía es clara.
Soluciones cuando hay mucho contenido
Mega menus en navegación primaria que muestran 2-3 niveles simultáneos. Tags y categorías cruzadas que crean atajos. Búsqueda interna potente. Páginas pilar (como esta misma estrategia de topic clusters) que actúan como “concentradores” temáticos.
Arquitectura para SEO: silos, hubs, clusters
La arquitectura SEO moderna se basa en tres conceptos relacionados.
Silos (silos)
Estructura tradicional: el contenido se agrupa en categorías estancas que no se cruzan. Ejemplo: SEO siloed (todo el contenido SEO en /blog/seo/) y diseño en /blog/diseno/. Funciona pero es rígido.
Hub-and-spoke
Una página pillar (hub) actúa de centro temático con contenido amplio. Páginas satélite (spokes) cubren subtemas específicos y enlazan al hub. El hub enlaza a todos los spokes. Es la arquitectura SEO dominante en 2026.
Topic clusters
Evolución del hub-and-spoke. Múltiples hubs interconectados forman un cluster temático. Cada hub se especializa pero comparten autoridad cruzada. Es lo que aplicamos en este sitio: cluster Google Ads + cluster Diseño Web + cluster SEO, con cross-links estratégicos entre clusters.
Por qué importa para SEO
Google entiende contexto temático mejor cuando ve estructura clara. Sitios con topic clusters densos rankean mejor que sitios con páginas dispersas porque demuestran autoridad temática profunda. Lo cubrimos con detalle en diseño web y SEO integrados.
Validación con usuarios reales antes de programar
El error común: arquitectura de información definida en una reunión, programada, y validada cuando el sitio ya está en producción. A esa altura cambiarla es 10x más caro.
Tree testing
Validación específica de jerarquía. El usuario recibe una tarea (“Encuentra el precio del servicio X”) y navega solo con texto del menú (sin diseño). Revela si la estructura tiene sentido sin la muleta visual.
First-click testing
El usuario ve el sitio (mockup o real) y se le pide ubicar algo. Se mide dónde hace el primer click. Si los usuarios no hacen click en el lugar correcto al primer intento, hay problema de IA.
Tests con prototipos
Figma, Adobe XD o Penpot permiten crear prototipos navegables baratos. Probar la arquitectura con 5-8 usuarios objetivo ANTES de programar revela el 90% de problemas.
Encuestas a usuarios actuales
Para sitios existentes con tráfico, encuestar usuarios actuales con preguntas tipo “¿Qué te costó encontrar?”, “¿Qué buscaste y no encontraste?”. Hotjar y Survicate facilitan estas encuestas in-page.
Errores típicos en arquitectura web que sabotean conversión
Menús sobrepoblados
Header con 12+ links primarios. La regla: si todo es importante, nada es importante. Reducir a 5-7 máximo. Lo demás va a footer o submenús.
Vocabulario interno
Etiquetar el menú como lo nombran internamente en la empresa, no como lo busca el usuario. “Soluciones Cloud Empresariales” cuando el usuario busca “Hosting” es traición a la intención de búsqueda.
Categorías recursivas
Categorías que dependen unas de otras formando bucles. Ejemplo: “Servicios” contiene “Diseño”, y dentro de “Diseño” otra vez aparece “Servicios”. Confunde a Google y al usuario.
Páginas huérfanas
Páginas sin links internos apuntándolas. Solo accesibles por URL directa o sitemap. Google las indexa pobremente. Auditoría con Screaming Frog detecta huérfanas.
Categorías con un solo post
Categoría “WordPress” con un único artículo. Diluye autoridad temática. O se llena con más contenido o se elimina la categoría.
Footer mega-listado
Footer con 100+ links repitiendo todas las categorías y subcategorías. Se considera link spam por Google y desordena la distribución de autoridad. Footer debe tener máximo 20-30 links curados.
Breadcrumbs fake
Breadcrumbs que muestran jerarquía falsa. Ejemplo: “Inicio > Blog > Categoría > Subcategoría > Post” cuando técnicamente el post no tiene subcategoría. Schema mal configurado lo penaliza.
Caso real: rediseño de IA que duplicó conversión en sitio B2B
Cliente: empresa de software B2B en Medellín. Sitio existente con 47 páginas, menú primario con 11 links, navegación caótica. Bounce rate 78%, tiempo en página 1:14.
Diagnóstico
Card sorting con 12 prospectos: el vocabulario interno del cliente (“Suite XYZ Pro”) era incomprensible. Tree testing: solo 35% completaba la tarea “encontrar precios” en menos de 90 segundos. Dato clave: 70% de usuarios buscaba la palabra “demo” pero el botón decía “Solicitar consulta”.
Cambios
Menú primario reducido a 5 links: Productos, Soluciones, Precios, Recursos, Contacto. Vocabulario reescrito en términos del usuario. Tree testing post-cambio: 88% completa la tarea en menos de 60 segundos. Botón principal renombrado a “Ver demo”.
Resultados a 90 días
Bounce rate: 78% → 51%. Tiempo en página: 1:14 → 3:42. Solicitudes de demo: +127%. Conversión total: 1.4% → 3.1%. Sin cambiar la oferta ni el precio, solo arquitectura de información.
