Arquitectura
Arquitectura SEO enterprise: por qué la mayoría de los rediseños la rompen y cómo evitarlo.
En organizaciones con decenas de miles de URLs, cada decisión de arquitectura se multiplica a escala. Lo que parece una simplificación razonable suele ser el origen del próximo incidente de tráfico.
El problema no es el diseño, es el modelo mental
La mayoría de los rediseños de sitios enterprise entran en crisis SEO no por un error técnico puntual, sino porque el equipo que los lidera tiene un modelo mental del sitio que no coincide con cómo Google lo está indexando hoy. Se rediseña lo que se ve, no lo que importa.
En un eCommerce con millones de SKUs, el valor SEO no está repartido de forma uniforme. Hay un 5% de URLs que captura el 80% del tráfico orgánico, y hay un 30% de URLs que no debería existir en el índice. Cuando el rediseño empieza desde la experiencia visible y no desde esa distribución real, los cambios golpean justo a las páginas que estaban funcionando.
Las cuatro decisiones irreversibles
Hay cuatro decisiones de arquitectura que, una vez indexadas, son prácticamente imposibles de revertir sin costo. Vale la pena invertir semanas discutiéndolas antes del primer deploy.
1. Patrón de URLs
No existen las “URLs bonitas”. Existen las URLs que soportan crecimiento. Si tu estructura hoy es /categoria/subcategoria/producto/, y mañana lanzás una tercera subcategoría, tenés que poder crearla sin mover nada. Los patrones jerárquicos rígidos son una trampa: funcionan al principio y se rompen cuando la taxonomía evoluciona.
2. Canonicalización
El canonical es la declaración oficial de cuál es la versión preferida de una página. En sitios con facetas, paginación y variantes de producto, una regla de canonicalización mal planteada puede generar decenas de miles de páginas canibalizándose entre ellas, o peor, decenas de miles de páginas señalando a una URL que ya no existe.
3. Estrategia de faceteo
Cada filtro que permitís indexar es una decisión sobre qué demanda querés capturar. La regla por defecto no debería ser “indexamos todo lo que el usuario puede filtrar”. Debería ser “indexamos solo las combinaciones que tienen demanda real medida”. Esa diferencia ahorra años de limpieza posterior.
4. Reglas de hreflang
En sitios multi-región, el hreflang es lo que le dice a Google qué versión mostrarle a cada usuario. Un hreflang mal implementado no se ve en el frontend y no rompe nada visible, pero silenciosamente puede estar mandando tráfico de Argentina a la versión española, o bloqueando la indexación de Brasil. Y cuando se descubre, ya hay meses de tráfico perdido.
Lo que funciona en la práctica
La mejor arquitectura SEO es la que el equipo de producto puede mantener sin consultar a SEO para cada cambio.
Eso implica dos cosas concretas. Primero: reglas documentadas, no reglas orales. Cuando el equipo de ingeniería sabe exactamente qué se indexa, qué se canonicaliza y qué se bloquea, y por qué, las decisiones futuras no dependen de que SEO esté en la reunión. Segundo: tests automatizados en CI que validen las reglas antes del deploy. Si una regla crítica se puede romper en un pull request sin que nadie se entere, es solo cuestión de tiempo hasta que se rompa.
En los proyectos enterprise donde trabajé en los últimos años, la regla que más valor generó fue aburrida: antes de cualquier cambio estructural, listar las 100 URLs que traen más tráfico orgánico y verificar que seguirán existiendo, con la misma URL, después del deploy. Es una verificación trivial. La mayoría de los incidentes de tráfico se habrían evitado con esa sola línea.
Conclusión
La arquitectura SEO enterprise no se gana con una idea brillante. Se gana con disciplina en las cuatro decisiones que no se pueden deshacer, y con la humildad de aceptar que tu modelo mental del sitio probablemente no coincide con la realidad del índice de Google. La mejor inversión que podés hacer antes de un rediseño es mirar los datos reales durante más tiempo del que te parece razonable.