La arquitectura web es la forma en que se organiza, jerarquiza y enlaza el contenido de un sitio para que los usuarios, los buscadores y los asistentes de IA encuentren cada página con el menor esfuerzo posible. En SEO sirve para tres cosas: facilitar el rastreo, repartir la autoridad interna hacia las URLs que importan y dejar claro de qué trata tu web.
La regla práctica cabe en una frase: estructura plana, páginas importantes a pocos clics de la home y enlazado interno guiado por relaciones temáticas. En esta guía te cuento cómo conseguirlo: los dos grandes tipos (horizontal y vertical), ejemplos, los topic clusters, las decisiones técnicas (subdominios o subcarpetas, multiidioma, paginación) y cómo adaptarlo todo a los buscadores con IA.
Llevo desde 2008 auditando proyectos, desde pymes hasta marcas como Santander o LG, y hay una constante que se repite: muchos problemas de visibilidad no nacen del contenido, sino de cómo está estructurado.
¿Qué es la arquitectura web en SEO?
La arquitectura web (también llamada arquitectura de la información o arquitectura de un sitio web) es la estructura jerárquica de un sitio: cómo se agrupan las URLs en categorías, a qué profundidad queda cada una y cómo se enlazan entre sí. En SEO condiciona qué páginas rastrea Google, cómo se reparte la autoridad interna y si el usuario encuentra lo que busca.
Dicho de otro modo: el contenido es qué dices y la arquitectura es cómo lo ordenas. Ese orden es lo que convierte un montón de URLs sueltas en un proyecto que un buscador puede interpretar como coherente y especializado en un tema.

La propia guía de inicio de SEO de Google recomienda organizar el sitio de forma lógica y agrupar los temas similares en directorios, sobre todo cuando la web tiene miles de URLs.
Profundidad web: ¿cuántos clics o niveles debe tener una web?
La profundidad web es el número de clics necesarios para llegar desde la home hasta una página concreta. No existe un número oficial de niveles: Google no ha publicado ningún límite y la «regla de los 3 clics» no es una norma del buscador. El criterio que sí funciona es que las páginas importantes queden a pocos clics de la home.
¿Por qué importa entonces? Porque cuanto más profunda está una URL, menos enlaces internos suele recibir, menos importancia transmite la propia web sobre ella y con menos frecuencia tiende a rastrearse. Los 3 clics valen como referencia práctica para revisar una web, no como frontera: una página a 4 clics bien enlazada puede funcionar mejor que una a 2 clics a la que solo apunta un enlace perdido.
Por eso, como criterio general, conviene una arquitectura más horizontal que vertical: pocos niveles, atajos hacia el contenido relevante y un enlazado que acerque a la superficie lo que de verdad quieres posicionar. Necesitarás más niveles cuando el contenido lo exija (un catálogo grande, un blog extenso), pero el objetivo es siempre el mismo: que ni el usuario ni el bot tengan que excavar.
Dibujado, queda así:

En una auditoría la profundidad la medimos con un rastreador: Screaming Frog, por ejemplo, indica para cada URL a cuántos clics está de la home, y con eso se ve enseguida qué páginas de negocio han quedado enterradas. Si prefieres verlo dibujado, Sitebulb lo representa en un mapa de rastreo.
Tipos de arquitectura web: horizontal y vertical
Los dos tipos de arquitectura web que importan en la práctica son la horizontal (o plana), en la que se llega al contenido final en muy pocos clics, y la vertical, en la que hay muchos niveles entre la home y la última página. Para SEO, la arquitectura horizontal es la opción recomendable en casi todos los proyectos.
Arquitectura web horizontal (plana)
La arquitectura horizontal permite llegar al contenido profundo en uno o dos clics desde la home. El bot entiende antes los patrones del sitio, la autoridad se reparte de forma más eficiente y el usuario encuentra lo que busca sin fricción. Cuanto más sencillo es el esquema, mejor lo entiende un buscador.
Tiene un límite: plana no significa enlazarlo todo desde la home. Un menú con cien opciones tampoco ayuda a nadie. Se trata de pocos niveles, pero bien agrupados.
Arquitectura web vertical
La arquitectura vertical mete mucha distancia entre la home y la última página (en un ecommerce, normalmente la ficha de producto). Si para llegar a una URL hacen falta cinco o seis clics, hay un problema: esas páginas reciben poca autoridad interna y se rastrean peor.
La verticalidad casi nunca es una decisión deliberada. Suele ser el síntoma de una taxonomía (el sistema de categorías y subcategorías) mal diseñada o que ha ido creciendo sin plan.

| Criterio | Horizontal (plana) | Vertical |
|---|---|---|
| Clics hasta el contenido final | 1 o 2 | 5, 6 o más |
| Facilidad de rastreo | Alta | Baja |
| Reparto de autoridad interna | Equilibrado | Diluido en cadenas largas |
| Experiencia de usuario | Ágil | Costosa |
| Cuándo usarla | Casi siempre | Casi nunca por diseño |
Ejemplos de arquitectura web: una web de servicios y un ecommerce
Un ejemplo de arquitectura web bien resuelta es un árbol de pocos niveles en el que cada rama agrupa páginas del mismo tema y cada URL responde a una sola intención de búsqueda. En una web de servicios bastan dos o tres niveles; en un ecommerce, categoría, subcategoría y producto, con los filtros bajo control.
Ejemplo de arquitectura de una web de servicios
Este es, simplificado, el esquema que usamos en esta misma web: los servicios cuelgan de una sección, los que forman familia se agrupan bajo una página índice y el blog va en subcarpeta.
ingenieroseo.com/
├── /servicios/
│ ├── /servicios/auditoria-seo/
│ ├── /servicios/seo-tecnico/
│ ├── /servicios/seo-ia/ (página índice de la familia)
│ │ ├── /servicios/seo-ia/consultor-geo/
│ │ └── /servicios/seo-ia/llms/
│ └── /servicios/ppc/ (página índice de la familia)
│ └── /servicios/ppc/google-ads/
└── /blog/
├── /blog/tipos-arquitectura-web/ (este artículo)
└── /blog/estructura-urls-silo/Cualquier servicio está a dos o tres clics de la home, y las páginas índice (SEO para IA, PPC) reparten enlaces hacia sus páginas hijas.
Ejemplo de arquitectura de un ecommerce
tienda.com/
├── /zapatillas/ (categoría)
│ ├── /zapatillas/running/ (subcategoría)
│ │ └── /zapatillas/running/modelo-x/ (ficha de producto)
│ └── /zapatillas/running/mujer/ (filtro con demanda de búsqueda: indexable)
├── /marcas/
│ └── /marcas/marca-y/
└── /blog/La clave del ejemplo está en la última línea de la categoría: solo se convierten en páginas indexables los filtros que la gente busca de verdad. El resto de combinaciones (orden, precio, talla más color) se quedan fuera, como verás en el apartado de navegación facetada.
Topic clusters: qué son y cómo ordenan una web
Los topic clusters (clústeres temáticos) son una forma de organizar el contenido por temas: una página pilar cubre un tema amplio y varias páginas de clúster desarrollan subtemas concretos. Cada página de clúster enlaza a la pilar y la pilar enlaza a todas ellas. Es el modelo más extendido hoy para ordenar contenido y enlazado interno.
¿Por qué funciona? Porque demuestra que cubres un tema de forma completa y no anecdótica, concentra relevancia en la página pilar (que ataca la búsqueda principal), reparte la autoridad interna con lógica y, de paso, ordena la navegación para el usuario. Las páginas de clúster se ocupan de las búsquedas más específicas (long tail).
Un ejemplo de esta casa: este artículo actúa como pilar del tema arquitectura web, y el post sobre la estructura SILO y otros parecidos son clústeres que lo desarrollan y lo enlazan. Si vas a rediseñar una web desde cero, este es el esqueleto por el que conviene empezar antes de tocar una sola plantilla.
Modelos de organización del contenido: jerárquico, en red y secuencial
Según cómo se relacionan las páginas entre sí, hay tres modelos clásicos de organización del contenido: el jerárquico (de lo general a lo específico), el modelo en red (páginas que se enlazan como una malla) y el secuencial (páginas que se leen en orden). La mayoría de webs combinan el jerárquico con algo de red.
Modelo jerárquico
Se aplica cuando la información se ordena por importancia y no por fecha. Una portada general lleva a secciones más específicas. Es el modelo típico de las webs de servicios: piensa en un bufete donde cada sección corresponde a una especialidad del derecho. Es la base de los topic clusters.
Modelo en red
Las páginas se complementan unas a otras formando una malla de enlaces relacionados. Es el modelo de los grandes ecommerce como Amazon, donde cada ficha enlaza a productos similares, complementarios y alternativos. Exige mucha coherencia entre enlaces para no acabar en ruido.
Modelo secuencial
Las páginas se suceden en un orden definido, de modo que para entender una hay que pasar antes por otra. Es propio de contenidos didácticos (cursos, tutoriales paso a paso).
A la hora de aplicarlos, mantén los nodos más relevantes en los primeros niveles y deja los secundarios en segundo plano. No todos los rincones de tu web valen lo mismo para un buscador.
Qué función cumple cada tipo de página en la arquitectura
En una arquitectura web cada tipo de página tiene un trabajo distinto: la home presenta y reparte, las categorías canalizan hacia el siguiente nivel, las páginas finales (producto o servicio) resuelven la necesidad concreta y las landing pages reciben al usuario que llega desde fuera con una intención muy definida.
La home
La home tiene tres trabajos: transmitir de qué va el sitio, abrir el paso a los siguientes niveles y ofrecer accesos rápidos (buscador interno, secciones principales). Mantén enlaces a tus contenidos más recientes para que se descubran antes. Una home sencilla, con un menú claro, permite que el bot extraiga los conceptos principales casi al instante.
Categorías y secciones intermedias
Son los puentes entre la home y el contenido final. Una categoría bien planteada agrupa contenido afín, enlaza hacia sus páginas hijas y recibe enlaces desde la home.
Páginas finales (producto o servicio)
Aquí aterriza la intención más concreta. Deben resolver la necesidad específica del usuario y enlazar hacia otras páginas del mismo nivel temático. Son, casi siempre, las que más conversiones generan.
Landing pages
Son las páginas a las que llega el usuario desde fuera (búsqueda, anuncios, enlaces). Es más probable que alguien entre por una landing específica que por la home, y por eso pesan tanto en SEO. Cada una debe responder a una única intención de búsqueda y tener un objetivo claro. Sacarles más rendimiento ya es trabajo de CRO (optimización de la conversión).
¿Vas a rediseñar tu web o a crear una nueva? Definimos contigo la arquitectura, las URLs y el enlazado antes de tocar una sola plantilla, para que la web nazca ordenada y no haya que rehacerla después.
Cómo hacer la arquitectura de una página web paso a paso
Para hacer la arquitectura de una página web se parte de dos fuentes: qué necesita tu cliente y cómo lo busca. Con eso se agrupan las búsquedas por intención, se asigna una URL a cada grupo, se ordenan en pocos niveles y se decide el enlazado. El proceso cambia según la web sea nueva o esté ya publicada.
- Define a quién te diriges. Una buena arquitectura ofrece la información tal como la buscaría tu público. Por eso conviene trabajar antes el buyer persona, el retrato de tu cliente ideal.
- Estudia cómo busca. Con un keyword research sabrás qué temas tienen demanda y con qué palabras.
- Agrupa por intención de búsqueda. Cada URL debe responder a una única intención. Tener URLs por tenerlas no tiene sentido: dos páginas para lo mismo compiten entre sí, y una página para tres cosas distintas no resuelve ninguna. Para decidir qué búsqueda va en cada página ayuda conocer los tipos de keywords (informativas, transaccionales, de marca).
- Ordena los grupos en categorías. Si dudas sobre cómo llamarlas o agruparlas, un card sorting con usuarios reales te saca de dudas.
- Dibuja el árbol y cuenta los clics. Comprueba que las páginas de negocio quedan cerca de la home.
- Decide el enlazado. Menú, migas de pan, enlaces contextuales entre páginas afines y pie de página.
- Piensa en el crecimiento. La estructura debe admitir nuevas categorías o contenidos sin romper la lógica ni cambiar URLs.
Si la web es nueva
Con una web nueva tienes la ventaja de planificar sin herencias. Fija primero los objetivos de negocio y construye la arquitectura a partir de ellos y de la demanda de búsqueda, no del organigrama de la empresa ni de lo que permite la plantilla.
Si la web ya está publicada
Una web publicada puede arrastrar una arquitectura poco favorable, y casi siempre tiene arreglo. Lo primero es medir: un rastreo para ver profundidad y enlaces internos, Google Search Console para ver qué se indexa y qué no, y Google Analytics 4 para entender cómo se mueven los usuarios. Si la mejora implica cambiar URLs, trátalo como una migración SEO, con sus redirecciones, para no perder lo que ya posiciona.
En mi experiencia, muchas webs que ya venden o captan clientes tienen una arquitectura muy mejorable, y precisamente por eso el margen de mejora al ordenarlas suele ser grande.
Arquitectura para ecommerce y navegación facetada
En un ecommerce, el mayor problema de arquitectura suele ser la navegación facetada: los filtros de color, talla, precio o marca. Cada combinación de filtros puede generar una URL distinta, y eso produce miles de páginas casi idénticas que consumen rastreo, diluyen autoridad y multiplican el contenido duplicado.
La forma de controlarlo es decidir, filtro a filtro, qué combinaciones tienen demanda de búsqueda real (y merecen ser páginas indexables y enlazadas) y cuáles no. Para las que no aportan, la guía de Google sobre navegación por facetas recomienda impedir su rastreo con robots.txt, y señala que el canonical o el nofollow son, a la larga, menos eficaces para ahorrar rastreo.
Dos avisos prácticos. El primero: bloquear por robots.txt y poner noindex a la vez no funciona, porque Google no puede leer la etiqueta de una página que no rastrea (lo explico en el post sobre noindex y robots.txt). El segundo: enlaza internamente solo a las páginas filtradas que sí quieres posicionar.
El mismo problema aparece en los portales de anuncios y clasificados, donde las combinaciones de categoría y ciudad se multiplican igual que los filtros de una tienda: lo trato en el post de SEO para directorios.
Para las páginas que sí quieres en Google, la documentación de Google sobre la estructura de una tienda online es clara: enlaza de los menús a las categorías, de estas a las subcategorías y de ahí a los productos, con enlaces HTML normales. Si quieres ver cómo se aplica en un catálogo grande, tienes un caso real de SEO en una web con más de 15.000 productos.
¿Subdominios o subcarpetas? Qué elegir para SEO
Entre subdominios (blog.dominio.com) y subcarpetas (dominio.com/blog/), la subcarpeta es la opción por defecto para SEO, porque todo el contenido y los enlaces refuerzan un mismo sitio. El subdominio solo compensa cuando hay una separación real: otra plataforma técnica, otra marca u otro equipo.
Conviene desmontar un par de ideas heredadas. Un subdominio no implica una IP distinta, ni la IP es lo que decide aquí. Y Google sabe rastrear e indexar las dos opciones: en su guía para sitios multirregionales presenta subdominios y subdirectorios como estructuras válidas, y apunta que el subdirectorio tiene menos costes de mantenimiento por ir en el mismo host.
El ejemplo más conocido de subdominio son los blogs gratuitos de WordPress.com y Blogger: cada blog vive en un subdominio de la plataforma (tublog.wordpress.com, tublog.blogspot.com) y funciona como un sitio independiente de los demás.

Mi criterio, después de muchos proyectos y migraciones: en la práctica, un subdominio se comporta casi como una web aparte, y te obliga a construir autoridad varias veces en paralelo. Por eso solo lo recomiendo con un motivo de peso.
| Factor | Subcarpeta (/seccion/) | Subdominio (seccion.) |
|---|---|---|
| Autoridad | Todo suma al mismo sitio | Hay que construirla aparte |
| Recomendada por defecto | Sí | Solo con un motivo claro |
| Caso de uso típico | Blog, servicios, recursos del mismo proyecto | App, centro de ayuda externo, tienda en otro CMS, marca separada |
| Mantenimiento SEO | Menor | Mayor |
¿Y el blog corporativo? Salvo excepción, en subcarpeta.
Arquitectura para webs multiidioma: estructura y hreflang
En una web multiidioma, la arquitectura consiste en dar a cada idioma o país su propia rama de URLs (lo más habitual, subcarpetas como /es/ y /en/) y conectar las versiones equivalentes con anotaciones hreflang, que indican a Google qué versión mostrar a cada usuario según su idioma o región.
Las reglas básicas están en la documentación de Google sobre versiones localizadas: las anotaciones deben ser recíprocas (si dos páginas no se apuntan entre sí, Google las ignora), cada versión debe incluirse también a sí misma y el valor x-default sirve de respaldo para los usuarios cuyo idioma no coincide con ninguna versión.

Además del hreflang:
- Usa el mismo criterio de estructura en todos los idiomas, para que cada página tenga su equivalente claro.
- No adaptes el contenido según la IP del visitante: Google lo desaconseja en su guía para sitios multirregionales. Mejor URLs distintas y enlaces visibles para cambiar de idioma.
- Adapta las palabras clave a cómo busca cada mercado. Traducir literalmente no basta.
- Al traducir, revisa los enlaces internos para que cada versión enlace a páginas de su mismo idioma.
Es uno de los puntos donde más tráfico se pierde por un detalle técnico mal puesto. Si vas a abrir mercados, tienes más detalle en el post de estrategias de SEO internacional.
Enlazado interno: cómo se reparte la autoridad dentro de la web
El enlazado interno es el conjunto de enlaces entre páginas de un mismo sitio, y es lo que hace funcionar la arquitectura: por esos enlaces descubre Google las URLs y por ellos pasa la autoridad de una página a otra (lo que siempre se ha llamado link juice). Qué enlazas y desde dónde decide a qué páginas das prioridad.
Si una URL tiene mucha fuerza, parte de esa fuerza se reparte entre todos los enlaces que salen de ella. Y hay un mínimo que marca la documentación de Google sobre enlaces: toda página que consideres importante debe recibir al menos un enlace desde otra página de tu sitio, y ese enlace debe ser un elemento <a> con atributo href para que pueda rastrearse.
Enlaces contextuales
Los enlaces dentro del contenido (no en menús ni pies de página) son los que más mira el usuario, sobre todo en la zona central de la página, y los que mejor explican la relación entre dos páginas gracias al texto que los rodea. Úsalos para conectar páginas afines y para llevar al lector hacia tus páginas clave, con un texto ancla que describa el destino.
Migas de pan (breadcrumbs)
Las migas de pan son un pequeño índice de la ruta, normalmente bajo la cabecera, que indica al usuario dónde está dentro de la web. Evitan que se pierda y refuerzan la jerarquía. Marcadas con datos estructurados BreadcrumbList, Google puede usarlas para mostrar la ruta en sus resultados de ordenador.

Menú, cabecera y pie de página
La cabecera debe contener las secciones más consultadas: ahí vive el menú principal. Evita los menús con demasiadas opciones y marca siempre en qué sección está el lector. El pie de página no es un vertedero de enlaces: resérvalo para los de utilidad (aviso legal, contacto, políticas) y poco más.
Sitemap XML
El sitemap XML es un archivo que lista las URLs que quieres que los buscadores conozcan. No sustituye a un buen enlazado interno, lo complementa. Según la documentación de Google sobre sitemaps, donde más ayuda es en sitios grandes o nuevos, y un sitio pequeño (unas 500 páginas o menos) y bien enlazado puede no necesitarlo. Aun así, mantenlo limpio: solo URLs indexables, sin redirecciones ni errores.

Paginación: buenas prácticas actuales
La paginación es la división de un listado largo (una categoría, el archivo del blog) en varias páginas. La práctica actual es que cada página de la serie tenga su propia URL, su canonical apuntando a sí misma y un enlace normal a la página siguiente. Google ya no usa las etiquetas rel=»next» y rel=»prev».
Todo esto está en las prácticas recomendadas de paginación de Google, que piden expresamente no usar la primera página como canónica de toda la serie.
Si usas scroll infinito o un botón de «cargar más», asegúrate de que detrás existe una versión paginada con URLs enlazadas. Los rastreadores de Google no hacen clic en botones, así que lo que solo aparece al pulsar o al hacer scroll puede no llegar a verlo.
Crawl budget: cuándo importa de verdad el presupuesto de rastreo
El crawl budget o presupuesto de rastreo es el conjunto de URLs que Google puede y quiere rastrear en un sitio. Depende de dos cosas: el límite de capacidad de rastreo (lo que tu servidor aguanta sin resentirse) y la demanda de rastreo (cuánto le interesa a Google tu contenido). Solo es un problema real en sitios grandes.
La guía de Google sobre presupuesto de rastreo lo acota a sitios con más de un millón de páginas únicas, o con más de 10.000 páginas cuyo contenido cambia a diario. Y no funciona como un cronómetro por visita: olvida cualquier cifra del tipo «el bot dedica medio segundo por página».
Si tu web tiene unos cientos o unos pocos miles de URLs, no merece la pena obsesionarse. Donde sí importa (ecommerce con catálogos enormes, medios, portales con filtros), una arquitectura plana, un enlazado limpio, sitemaps ordenados y un robots.txt bien optimizado marcan la diferencia entre que Google rastree lo que importa o se pierda en URLs inútiles. El caso de los medios, con miles de noticias, secciones y etiquetas, lo desarrollo en el post de SEO para portales de contenido.
Arquitectura web y GEO: cómo estructurar para los buscadores con IA
La arquitectura web también condiciona si los buscadores con IA (AI Overviews y el Modo IA de Google, ChatGPT, Perplexity, Gemini, Claude) pueden encontrar, entender y citar tu contenido. El GEO (optimización para motores generativos) se apoya en lo mismo que el SEO: páginas rastreables, bien enlazadas y con respuestas fáciles de extraer.
Lo primero es el acceso. En el caso de Google, su documentación sobre funciones de IA dice que no hay requisitos adicionales: basta con que la página esté indexada y pueda mostrarse con fragmento. Otros asistentes usan rastreadores propios (GPTBot, ClaudeBot, PerplexityBot), así que revisa que tu robots.txt no los bloquee si quieres aparecer en sus respuestas. Un matiz: Google-Extended no es un rastreador, sino un token de robots.txt que controla el uso de tu contenido en Gemini, y no afecta a la Búsqueda.
Lo segundo es que el contenido sea fácil de extraer. Estos sistemas trabajan con pasajes, no con páginas enteras, y eso favorece:
- Definiciones directas al inicio de cada apartado.
- Respuestas que se entienden solas, fuera de contexto.
- Encabezados que reproducen cómo pregunta la gente.
- Tablas para comparar, datos con su fuente y un bloque de preguntas frecuentes.
A nivel de sitio, una estructura plana y un enlazado interno coherente ayudan a que quede claro en qué temas estás especializado, que es justo lo que consigue un buen modelo de topic clusters.
¿Y el archivo llms.txt? Es una propuesta para ofrecer a los sistemas de IA un resumen de tu web con enlaces a las páginas clave. Google indica en esa misma documentación que para sus funciones de IA no hace falta crear archivos de este tipo, así que tómalo como algo opcional y no como sustituto de una buena arquitectura. Es lo que trabajamos en consultoría GEO.
Checklist: 8 características de una buena arquitectura web
Una buena arquitectura web cumple ocho condiciones: es útil, usable, encontrable, accesible, creíble, escalable, coherente y está orientada a negocio. Las cinco primeras tienen que ver con la experiencia de usuario y las tres últimas con que la estructura aguante el paso del tiempo. Úsalas como lista de verificación.
- Útil y valiosa. Cada URL responde a una intención de búsqueda real y aporta algo propio. Si una sección no sirve a nadie, sobra. Muchas veces menos es más.
- Usable. Menús y submenús con lógica clara y patrones que el usuario ya conoce (lo principal arriba, lo legal y el contacto en el pie). ¿Se puede llegar a cada sección sin improvisar?
- Encontrable. Usuario y bot localizan cualquier contenido sin perderse. Si entro en una web a buscar un perfume y no lo veo rápido, no lo voy a comprar.
- Accesible. Diseño adaptado a móvil, navegación simple, enlaces que funcionan y contenido utilizable con tecnologías de asistencia. Además puede ser una oportunidad: trabajé con una cadena de restaurantes que puso su carta a disposición de personas con discapacidad visual y lo convirtió en una nota de prensa con mucha repercusión.
- Creíble. El orden transmite confianza. Si el usuario ve que sabes organizar tu casa, se fía más de lo que le ofreces.
- Escalable. Admite nuevas categorías o contenidos sin romper la lógica existente.
- Coherente. Mismo criterio de etiquetado, de nombres y de formato en todo el sitio, con un grupo de etiquetas acotado.
- Orientada a negocio. He trabajado en proyectos donde se primaba el diseño sin pensar en SEO, y es un error caro: ¿de qué sirve una web preciosa si luego no la ve nadie?
Sobre el etiquetado, que es donde más se desordenan las webs con el tiempo: las etiquetas representan bloques de información y, para ser prácticas, deben formar un conjunto ordenado, consistente y específico. Un mal sistema de etiquetas perjudica la navegación y llena la web de páginas casi vacías.

Lo mismo con el móvil: buena parte de las visitas llega desde el teléfono, así que el menú y la navegación deben funcionar igual de bien en una pantalla pequeña que en un ordenador.

Y una idea que lo resume: en SEO, «usuario» significa «persona». Si lo tienes presente, la arquitectura empieza a tener sentido real.

Preguntas frecuentes sobre arquitectura web
¿No está tu pregunta? Escríbeme a alberto@ingenieroseo.com y te contesto en menos de 24 horas.
¿Cuántos niveles de profundidad debe tener una web?
No hay un número oficial. Google no ha publicado ningún límite de niveles y la «regla de los 3 clics» es una referencia práctica, no una norma. Lo que funciona es que las páginas importantes queden a pocos clics de la home, porque cuanto más profunda está una URL, menos enlaces internos recibe y peor se rastrea.
¿Qué diferencia hay entre arquitectura web horizontal y vertical?
En la arquitectura web horizontal (plana) se llega al contenido final en uno o dos clics desde la home. En la vertical hay muchos niveles intermedios y pueden hacer falta cinco o seis clics. Para SEO se recomienda la horizontal, porque facilita el rastreo y reparte mejor la autoridad interna.
¿Es mejor un subdominio o una subcarpeta para SEO?
Como norma general, la subcarpeta. Google sabe rastrear e indexar ambas opciones, pero en subcarpeta todo el contenido y los enlaces refuerzan el mismo sitio. El subdominio compensa cuando hay una separación real: una plataforma técnica distinta, una marca diferenciada o un equipo independiente.
¿Cómo sé si mi web tiene una mala arquitectura?
Revisando datos: un rastreo para ver a cuántos clics está cada página, Google Search Console para ver qué URLs importantes no se indexan, y la analítica para ver por dónde se pierden los usuarios. Las señales de alarma más habituales son páginas clave a muchos clics, páginas sin ningún enlace interno y miles de URLs generadas por filtros.
¿Cómo afecta la arquitectura web a los buscadores con IA?
La arquitectura web condiciona que los sistemas de IA puedan rastrear tu sitio y extraer respuestas de él. Ayudan las definiciones directas, los apartados que se entienden solos, los encabezados en forma de pregunta, las tablas y un enlazado interno coherente. Para AI Overviews, Google no pide requisitos técnicos distintos de los de la Búsqueda.
Por dónde empezar con la arquitectura de tu web
Para mejorar la arquitectura de una web ya publicada, el primer paso es medir, no mover cosas: un rastreo completo, los datos de Google Search Console y la analítica te dicen dónde pierdes rastreo, autoridad o usuarios. Con eso se priorizan los cambios, empezando por acercar a la home las páginas de negocio.
¿Sospechas que la estructura de tu web frena el posicionamiento? La revisamos contigo con datos de rastreo y de Search Console, y te decimos qué cambiar primero y qué es mejor no tocar.
Si tienes dudas sobre cómo ordenar tu web o un caso que no encaja en lo que cuento aquí, déjalo en los comentarios y lo vemos.
