Arquitectura web y SEO: estructura que posiciona | Ighenatt

Qué es la arquitectura web y por qué Google la necesita

Imagina que tu sitio web es un edificio de apartamentos. Googlebot es el cartero que tiene que entregar correo a cada uno de los pisos. Si el edificio no tiene ascensor, la señalización está incompleta y algunos pasillos no conectan con otros, el cartero va a perder mucho tiempo — o directamente no va a llegar a algunas puertas. La arquitectura web es exactamente eso: el plano del edificio que determina cómo se mueve Google por tu sitio.

Y el problema con muchos sitios es que nadie pensó en el plano antes de construir. Se fueron añadiendo páginas, secciones y categorías sin una lógica de conjunto, hasta que la estructura resultante es un laberinto.

Adrien Menard, CEO de Botify, lo cuantificó en 2019 con un dato que todavía circula en los debates de SEO técnico profesional: más del 50% de las páginas en sitios enterprise directamente no son rastreadas por buscadores. La causa principal no es la velocidad ni el contenido — es la arquitectura.

La arquitectura web comprende tres cosas concretas:

• Cómo se organizan las páginas en jerarquías (homepage → categorías → subcategorías → páginas de detalle)
• Cómo se enlazan entre sí (qué páginas apuntan a qué otras)
• Cómo se reflejan esas decisiones en la estructura de URLs

Estas tres variables determinan dos cosas que Google le importan mucho: cuántas páginas puede rastrear en cada visita (el crawl budget) y cuánta autoridad distribuyen esas páginas entre sí a través del enlazado interno.

Estructura plana vs. profunda: cuándo usar cada una

La profundidad de un sitio se mide en clics desde la homepage. Una página a 1 clic está en el menú principal. A 2 clics, en una categoría. A 5 clics, enterrada en una subcategoría de una subcategoría de una categoría.

Hay dos modelos extremos y muchos puntos intermedios entre ellos.

Arquitectura plana

Todas las páginas están a pocos clics de la homepage. Para un restaurante de Barcelona con 15 páginas (carta, reservas, historia, equipo, contacto…), la arquitectura plana es lo natural: menú principal con 6-7 secciones, cada una apuntando directamente a la página correspondiente.

Ventajas concretas:

• Googlebot llega a todas las páginas en pocas visitas
• La autoridad de la homepage se distribuye directamente a páginas estratégicas
• El usuario también navega sin fricción

Arquitectura profunda

Cuantas más páginas tiene un sitio, más difícil resulta mantenerlas todas a pocos clics. Una tienda online con 3.000 productos necesita categorías, subcategorías y filtros que inevitablemente añaden profundidad. El riesgo aquí es que los productos importantes queden a 5-6 clics de la homepage y Google los rastree con poca frecuencia.

La documentación oficial de Google Search Central es clara al respecto: las páginas importantes deben ser accesibles en pocos clics desde la homepage. No dice cuántos exactamente, pero la recomendación práctica del sector es no superar 3-4 clics para ninguna página que quieras que Google rastree activamente.

Para un ecommerce de moda con 500 referencias activas, la estructura óptima sería:

Homepage (0 clics)
  → /ropa-mujer/ (1 clic)
    → /ropa-mujer/vestidos/ (2 clics)
      → /ropa-mujer/vestidos/vestido-lino-azul/ (3 clics)

Cuatro niveles para cualquier producto. Manejable. Si la misma tienda añade filtros de talla, color y ocasión como URLs indexables, puede acabar con páginas a 6-7 clics que Google nunca ve.

La regla práctica

Para sitios de menos de 1.000 páginas: arquitectura plana, máximo 3-4 clics para cualquier página. Para sitios de más de 10.000 páginas (ecommerce grande, portales de contenido, marketplaces): acepta la profundidad pero asegura que las categorías principales estén a 1-2 clics y los productos o artículos a 3-4. Más allá de 4 clics, cada página añadida tiene rendimientos decrecientes en términos de rastreo.

Diseño de URLs SEO-friendly: principios y errores

Aquí viene el punto contraintuitivo que muchos SEOs no esperan: la estructura de carpetas en la URL importa bastante menos de lo que se cree.

John Mueller, Search Advocate de Google, lo explicó con precisión en un Webmaster Hangout de marzo de 2022:

“Para nosotros, no nos importa tanto la estructura de carpetas, nos centramos esencialmente en el enlazado interno. Es realmente como desde la homepage o desde la página principal — ¿qué tan rápido podemos llegar a esa página específica?”

Esto tiene una implicación directa: la URL /auditoria-seo/ no posiciona peor que /servicios/seo/tecnico/auditoria/ por ser “más corta” o tener “menos jerarquía”. Lo que determina la importancia de la página para Google es cuántos clics la separan de la homepage a través de enlaces internos, no cuántos directorios tiene la URL.

Lo que sí importa en las URLs:

Legibilidad y consistencia. Las URLs deben describir el contenido que contienen, usando palabras (no IDs o parámetros) y separadores de guión (-), no guión bajo. /que-es-el-seo/ es mejor que /que_es_el_seo/ o /p?id=347.

Sin parámetros innecesarios. Los filtros de búsqueda, las sesiones de usuario y los parámetros de campaña añadidos directamente a la URL crean versiones duplicadas del mismo contenido. Google puede acabar rastreando /productos/?color=azul&talla=M&orden=precio como una URL independiente, multiplicando el número de páginas que tiene que visitar sin que ninguna de ellas aporte valor.

Canonical y deduplicación. Cuando la misma página es accesible desde varias URLs (con y sin www, con y sin https, con parámetros de sesión), hay que establecer la URL canónica para evitar que Google distribuya el presupuesto de rastreo entre versiones duplicadas del mismo contenido.

Evitar cambios frecuentes. Cada vez que cambia la URL de una página, si no hay una redirección 301 correcta, Google pierde el historial de rastreo de esa URL. Una migración web mal ejecutada puede causar pérdidas de tráfico que tardan meses en recuperarse.

Modelos de arquitectura: silo, hub-and-spoke, flat

Más allá de “plano vs. profundo”, en SEO se trabaja con tres modelos de organización que tienen implicaciones distintas para el enlazado interno.

Modelo silo

El contenido se organiza en grupos temáticos aislados. El enlazado interno fluye preferentemente dentro del mismo silo: la página de categoría enlaza a las de subcategoría, las de subcategoría enlazan a las de detalle, y el enlazado entre silos distintos se mantiene mínimo.

La lógica detrás del modelo silo es la consolidación de relevancia topical. Si un despacho de abogados tiene una sección de derecho penal y otra de derecho laboral, mantenerlas como silos separados con enlazado interno propio puede ayudar a Google a entender que el despacho tiene autoridad diferenciada en cada área.

La limitación práctica es la rigidez. Los silos puros son difíciles de mantener cuando el contenido tiene conexiones naturales entre áreas temáticas. Forzar esa separación puede resultar en una experiencia de usuario artificial.

Modelo hub-and-spoke

Hay páginas “hub” (núcleo) que funcionan como centros temáticos y páginas “spoke” (radio) que desarrollan subtemas relacionados y enlazan de vuelta al hub. Es el modelo detrás de las estrategias de contenido pilar o topic clusters.

Un hub podría ser una guía completa sobre “SEO para ecommerce”. Los spokes serían artículos específicos sobre velocidad de carga, estructura de URLs de producto, schema de producto, gestión de variantes… Todos enlazan al hub y el hub enlaza a todos ellos.

Este modelo funciona bien para sitios de contenido (blogs, portales de recursos) porque refuerza la relevancia topical sin imponer la rigidez del silo.

Arquitectura plana (flat)

Para la mayoría de PYMEs con sitios de 20-100 páginas, la arquitectura plana es la opción más práctica y suficiente. Menú principal que enlaza directamente a las páginas más importantes. Pocas categorías intermedias. Máxima accesibilidad desde la homepage.

Un restaurante no necesita un silo de “carta de invierno vs carta de verano”. Una clínica dental no necesita un hub-and-spoke de implantología. La complejidad de arquitectura debe estar justificada por el volumen de contenido, no por la aspiración de parecer un sitio más sofisticado.

Cómo planificar la arquitectura antes de construir

La arquitectura web se diseña antes de desarrollar, no después. Cambiarla a posteriori es posible pero costoso: requiere redireccionamientos masivos, actualizaciones de menús y enlazado interno, y tiempo hasta que Google procese los cambios.

Paso 1: inventario de contenido

Antes de dibujar ningún mapa de sitio, lista todo el contenido que va a tener el sitio. Para cada página, define:

• Qué keyword principal va a abordar
• Qué audiencia específica la va a necesitar
• Si tiene relación con otras páginas del inventario

Este inventario revela automáticamente las agrupaciones naturales y la profundidad que necesitará el sitio.

Paso 2: mapa de jerarquía

Con el inventario en mano, agrupa las páginas en categorías y define cuántos niveles necesitas. La regla es: usa el mínimo de niveles necesarios para que la estructura sea comprensible. Cada nivel añadido es un clic más que Googlebot tiene que dar y un paso más que el usuario tiene que navegar.

Herramientas como Whimsical, Miro o incluso una hoja de cálculo son suficientes para este ejercicio. No necesitas software especial — necesitas claridad sobre la lógica de agrupación.

Paso 3: definición del enlazado interno

La jerarquía de páginas determina el enlazado interno automático (menú, breadcrumbs, listas de categoría). Pero el enlazado interno también incluye los enlaces manuales dentro del contenido, y estos son los que más impacto tienen en la distribución de autoridad.

Define qué páginas son estratégicas (las que más quieres que posicionen) y asegúrate de que reciben enlaces desde múltiples páginas del sitio, no solo desde el menú principal. Una página de servicio que recibe 10 enlaces internos desde artículos de blog relacionados tiene más señales de importancia para Google que una que solo aparece en el menú.

Paso 4: gestión de URLs técnicas con bajo valor

Cualquier sitio genera URLs que no aportan valor: páginas de resultados de búsqueda interna, filtros de ecommerce, parámetros de sesión, páginas de paginación sin contenido único. Estas URLs consumen crawl budget sin aportar valor.

La decisión sobre cada tipo de URL técnica debe tomarse antes de lanzar el sitio, no cuando el problema ya está en producción:

Para sitios ecommerce con miles de productos y variantes, esta gestión es la diferencia entre que Google rastree el 5% o el 80% del catálogo real.

Arquitectura para sitios multiidioma

Los sitios con contenido en varios idiomas añaden una capa de complejidad a la arquitectura: cada página tiene potencialmente tres o cuatro versiones (una por locale), y Google tiene que saber qué versión mostrar a cada usuario según su idioma y ubicación.

La implementación técnica de esto son las etiquetas hreflang, pero las etiquetas hreflang son solo el mecanismo. La arquitectura es la decisión previa.

Opciones de estructura de URL para multiidioma

Subdirectorios por locale (la más habitual): ighenatt.es/en/, ighenatt.es/ca/. Toda la autoridad de dominio se concentra en un solo dominio. Google las procesa bien y es la opción recomendada por la documentación oficial para la mayoría de casos.

Subdominios: en.ighenatt.es, ca.ighenatt.es. Técnicamente funciona pero distribuye la autoridad entre subdominios y requiere más trabajo de verificación en Search Console.

Dominios distintos: ighenatt.com para inglés, ighenatt.es para español. Solo tiene sentido cuando hay una razón de negocio muy clara para mantener presencias de dominio separadas, ya que implica construir autoridad desde cero en cada dominio.

Qué hace que la arquitectura multiidioma falle

El error más habitual no es la elección de estructura de URL, sino la inconsistencia en el enlazado hreflang. Cada URL en un locale debe tener etiquetas hreflang que apunten a sus equivalentes en los otros locales, y esos equivalentes deben tener etiquetas de retorno hacia la primera. Si una página en inglés apunta a su versión en catalán pero la versión catalana no apunta de vuelta, Google puede ignorar la relación.

El segundo error frecuente es traducir el contenido sin adaptar las URLs. Una URL como /servicios/seo-barcelona/ tiene sentido en español. Su equivalente en inglés debería ser /en/services/barcelona-seo/, no /en/servicios/seo-barcelona/. Google usa la URL como señal de locale, y una URL en español dentro de una sección en inglés genera señales contradictorias.

Auditoría de arquitectura: herramientas y métricas

Una vez que el sitio está en producción, la arquitectura se audita midiendo exactamente qué está rastreando Google y comparándolo con lo que debería rastrear.

El dato que lo cambia todo: el case study del marketplace de vehículos

Botify documentó el caso de un marketplace de vehículos online de EEUU con 10 millones de páginas en el servidor. La situación inicial era la siguiente: Google solo rastreaba 50.000 de esas 10 millones de URLs — el 0,5%. El 98% del crawl budget se consumía en URLs sin valor: filtros de refinamiento con parámetros infinitos, permutaciones de URL que duplicaban el mismo listado de coches con distintos ordenamientos, páginas de paginación que Google visitaba repetidamente sin descubrir contenido nuevo.

Las intervenciones fueron tres:

1. Actualización del robots.txt para bloquear las URL de refinamiento sin valor
2. Reducción del 50% del total de URLs conocidas por Google mediante canonical y noindex
3. Mejora del enlazado interno para que Google llegara más fácilmente a las fichas de vehículos relevantes

Resultado en tres meses: el crawl pasó del 0,5% al 9,5% (+19x), y el tráfico orgánico se duplicó de 40.000 a 80.000 visitas semanales. Las primeras mejoras fueron visibles en seis semanas.

Este caso ilustra algo que vale la pena subrayar: el problema no era falta de páginas, sino exceso de páginas sin valor que impedían a Google llegar a las que sí importaban.

Métricas de auditoría de arquitectura

Click depth desde la homepage. Herramientas como Screaming Frog o Sitebulb rastrean el sitio simulando el comportamiento de Googlebot y te muestran a cuántos clics está cada URL desde la homepage. Una distribución saludable tiene la mayoría de páginas estratégicas a 1-3 clics.

URLs rastreadas vs. URLs enviadas en sitemap. Google Search Console muestra cuántas URLs ha rastreado Google vs. cuántas URLs aparecen en tu sitemap. Si hay una diferencia grande, hay páginas que Google no está alcanzando.

Páginas rastreadas sin valor. Un crawl completo con Screaming Frog identifica cuántas URLs del sitio son parámetros, duplicados, páginas de filtro o paginación que Google está rastreando innecesariamente. Esta cifra dividida por el total de URLs rastreadas da la proporción de “desperdicio” de crawl budget.

Distribución de enlaces internos. Herramientas como Ahrefs, Screaming Frog o Sitebulb muestran cuántos enlaces internos recibe cada URL. Las páginas estratégicas deben recibir más enlaces internos que las páginas de soporte. Si las páginas mejor enlazadas internamente son la política de privacidad y el aviso legal, hay un problema de distribución de autoridad.

Gary Illyes y el crawl más inteligente

En LinkedIn en abril de 2024, Gary Illyes (analista de Google) compartió una observación relevante sobre cómo ha evolucionado el comportamiento del crawl:

“Estamos rastreando aproximadamente lo mismo que antes, sin embargo la programación se ha vuelto más inteligente y nos enfocamos más en URLs que tienen más probabilidad de merecer el rastreo.”

La implicación práctica es directa: si tu sitio tiene muchas URLs de bajo valor, Google va a priorizarlas menos, lo que significa menos visitas a las URLs estratégicas. Optimizar la arquitectura no solo ayuda a que Google llegue a más páginas — también influye en con qué frecuencia vuelve.

Una arquitectura bien diseñada no se ve, pero sí se nota en el rastreo. Si quieres saber qué porcentaje de tu sitio está siendo rastreado y qué estructura tiene más sentido para tu caso, en Ighenatt lo evaluamos en cualquier auditoría SEO inicial. Cuéntanos tu caso.