Hace tres meses llegó a la agencia un proyecto con 340.000 URLs indexables y una caída sostenida de tráfico orgánico del 28% respecto al año anterior. La primera reacción del cliente fue pedir contenidos nuevos. La del equipo técnico, mirar los logs. Ahí estaba todo: Googlebot rastreando 11.000 combinaciones de filtros por día mientras las fichas de producto reales recibían visita cada 40-50 jornadas.
Este artículo recoge lo que el equipo técnico ha aprendido diagnosticando errores SEO técnicos en sitios grandes y lo que ya se observa en los primeros proyectos de 2026. No hablamos de teoría. Hablamos de patrones que se repiten cuando un catálogo supera las 50.000 URLs y las herramientas convencionales dejan de servir.
Por qué un fallo técnico pequeño se multiplica cuando tienes 200.000 URLs
En un blog de 400 artículos, un problema de canonicalización afecta a un puñado de páginas. Molesta. Se resuelve. En un e-commerce con 200.000 fichas, ese mismo problema puede estar duplicando decenas de miles de recursos rastreables sin que nadie lo note en el panel de Search Console. La escala cambia la naturaleza del error.
¿Y por qué no lo detectan las auditorías estándar? Porque están pensadas para muestrear. Cogen 500 URLs, sacan porcentajes, extrapolan. Pero en un proyecto grande, el 1% que se escapa del muestreo puede ser exactamente donde está la sangría.
El efecto compuesto: cuando un 3% de páginas rotas equivale a 6.000 pérdidas
La cuenta es cruel. Tres por ciento de 200.000 son 6.000 URLs. Si cada una debería recibir tráfico modesto (pongamos 40 visitas mensuales, cifra baja para un long tail decente), se pierden 240.000 sesiones al mes. Un directivo tarda cinco minutos en aprobar una reunión de emergencia con esa cifra encima de la mesa.
Un ejemplo real: proyecto de moda con 187.000 productos. La auditoría interna decía «salud técnica: 94%». Cruzando ese dato con logs de tres meses, el 6,2% del catálogo estaba en cadenas de redirect 301→301→200. Ese 6% concentraba el 31% de las llamadas de Googlebot. Y al mismo tiempo, otro 4% no recibía visita del rastreador desde hacía 60 días.
Síntomas que un Screaming Frog convencional no detecta a escala
Screaming Frog es una herramienta magnífica y forma parte del flujo diario. Pero tiene un techo. Cuando le pides que crawlee 300.000 URLs con render de JavaScript activado, el equipo tarda tres días, consume 40 GB de RAM y devuelve un CSV que nadie va a leer entero.
Los síntomas que se escapan son concretos: fluctuación de canonicals según parámetros de la petición, respuestas 200 con contenido de error dentro del HTML, hreflang que apuntan a URLs que ya no responden, y variaciones de rendering entre user agents. Nada de esto sale en un crawl secuencial.
El flujo aquí combina Screaming Frog para el mapa base, un procesador de logs propio (BigQuery más un dashboard sencillo) y el CrUX Dashboard para el rendimiento real. Sin esos tres pilares cruzados, cualquier diagnóstico en un portal grande es especulación.
Crawl budget mal repartido: la hemorragia silenciosa de las webs con catálogo
El crawl budget es el número finito de peticiones que Googlebot dedica a un dominio en un periodo de tiempo, condicionado por el rendimiento del servidor y la calidad percibida de las URLs. En sitios de más de 50.000 páginas, ese presupuesto se convierte en el factor limitante real: si se malgasta en URLs de bajo valor, las páginas estratégicas quedan sin rastrear durante semanas.
El presupuesto de rastreo no desaparece. Se redirige mal. ¿Qué ocurre en la práctica cuando el reparto es defectuoso? Que las URLs importantes se rastrean cada 40 días y las combinaciones de filtros paginadas se rastrean cada 6 horas. Es surrealista, pero es un patrón que aparece cada trimestre.
Cómo saber si Googlebot está gastando el 70% del rastreo en URLs sin valor
La forma directa: 60 días de logs, filtrar por user-agent de Google (verificado por reverse DNS, no solo por cadena UA), agrupar por directorio o patrón de URL y ordenar por número de hits. Si el top 20 de URLs más rastreadas no incluye las categorías principales ni los productos estrella, hay un problema estructural.
En el último proyecto de electrodomésticos analizado, el top 15 estaba compuesto en su totalidad por URLs con parámetros de ordenación (?sort=price_asc, ?sort=rating). Ninguna categoría real aparecía hasta el puesto 47. Ese portal recibía 320.000 peticiones diarias del rastreador y solo 71.000 iban a contenido con valor.
Aquí la trampa: se creyó al principio que bastaba con bloquear esos parámetros por robots.txt. Error. Al bloquearlos sin más, Googlebot dejó de rastrear también las URLs canónicas asociadas y se perdió indexación durante tres semanas. La corrección: canonicals bien declarados y un nofollow selectivo en los enlaces internos que generaban esas variantes.
Facetas, filtros y parámetros: el triángulo que devora presupuesto de rastreo
Este es el problema clásico y en 2026 sigue siendo el número uno en los diagnósticos. Una navegación facetada mal implementada puede generar millones de combinaciones. Literalmente millones. Cinco facetas con seis opciones cada una ya son 7.776 permutaciones por categoría.
¿Cuáles indexar? Solo aquellas con demanda de búsqueda real y volumen suficiente. El resto: canonical al padre, enlace interno con rel=»nofollow» o directamente cargados con JavaScript tras interacción del usuario. No hay una receta única; depende de cómo esté construida la plantilla.
Lo que sí es innegociable: el sistema tiene que ser gobernable desde un panel único donde el equipo pueda añadir o quitar facetas indexables sin tocar código. Si cada cambio requiere un deploy, el proyecto muere en burocracia.
Canibalización a gran escala: cuando 400 fichas compiten entre sí
La canibalización en un blog es aburrida de resolver pero manejable. En un catálogo con miles de fichas parecidas (variantes de color, tallas, modelos con especificaciones casi idénticas), el problema muta. Ya no compiten dos URLs por una keyword; compiten 40 URLs por 15 variaciones de la misma intención.
Diagnóstico con logs y datos de Search Console cruzados
El método: exportar consultas de Search Console de los últimos 90 días, filtrar las que reciben impresiones repartidas entre más de tres URLs del mismo directorio, y cruzarlas con la frecuencia de rastreo de cada una. Si Google rota entre cinco URLs mostrando en SERP a veces una y a veces otra, hay canibalización activa.
En una tienda de suplementos deportivos se identificaron 2.340 clusters de canibalización así. El 60% se resolvía consolidando en la ficha padre y redirigiendo variantes muy similares. El 40% restante requería diferenciación real de copy y schema.
Consolidación vs. diferenciación: qué aplicar según tipo de plantilla
Consolidación cuando el usuario no percibiría diferencia entre las páginas. Un producto con seis colores en URLs distintas normalmente debería ser una sola URL con selector de color. Ahorra rastreo, concentra señales, mejora la experiencia.
Diferenciación cuando cada variante responde a una intención distinta. «Zapatillas running mujer talla 38» y «zapatillas running mujer minimalistas» pueden convivir si el contenido, el schema y las imágenes lo respaldan. La regla aplicable: si no se es capaz de escribir 150 palabras únicas y útiles para cada variante, entonces no merece URL propia.
Por cierto, aquí es donde una agencia de SEO técnico especializada en catálogos grandes aporta más valor: en decidir qué se consolida y qué se preserva sin cargarse la taxonomía existente. Es una decisión híbrida entre negocio y arquitectura de información.
Indexación descontrolada: por qué Google ignora el 40% de tu catálogo
Este dato es real y aparece repetidamente: el 40% de las URLs de un catálogo grande puede estar en estado «detectada pero no indexada» o «rastreada pero no indexada». Google decide que no vale la pena guardarlas en su índice. Y la mayoría de veces tiene razón.
¿Por qué? Porque en 2026 el listón de calidad ha subido. Contenido thin, plantillas repetitivas sin diferenciación, señales de baja demanda: cualquiera de estos factores hace que el buscador descarte la URL antes incluso de considerarla para ranking.
Cadenas de redirects, soft 404 y páginas huérfanas heredadas de migraciones
Las migraciones dejan cadáveres. Redirects encadenados de tres o cuatro saltos que en su día tenían sentido y ahora nadie recuerda por qué existen. En una migración de 2019 se pueden encontrar en 2026 rutas del tipo /categoria-antigua/ → /categoria-provisional/ → /categoria-final/ que Googlebot sigue visitando semanalmente.
Los soft 404 son peores. Devuelven código 200 pero muestran «producto no disponible» o «página no encontrada» en el contenido. Google los detecta como 404 y no indexa. Pero siguen consumiendo rastreo.
Y las huérfanas: URLs que existen técnicamente, que Google conoce por sitemap o por enlaces externos antiguos, pero que ya no reciben enlaces internos desde el propio sitio. Suelen ser residuo de restructuraciones. Recomendación clara: o se recuperan con enlazado y contenido, o se cierran con 410. El 301 a categoría genérica solo pospone el problema.
Sitemap segmentado y ping selectivo: la técnica que sí escala
Un sitemap único de 50.000 entradas es un error en 2026. La estrategia correcta pasa por segmentar por tipo de contenido (productos activos, productos descatalogados con demanda residual, categorías, blog, páginas informativas) y por frecuencia de actualización.
Ejemplo real de estructura que funciona en un cliente con 180.000 URLs:
- sitemap-productos-nuevos.xml (últimos 30 días, alta prioridad)
- sitemap-productos-consolidados.xml (histórico con tráfico)
- sitemap-categorias.xml
- sitemap-blog.xml
- sitemap-descatalogados-relevantes.xml
Cada uno con su propia frecuencia de actualización y su ping selectivo. Cuando se publican 200 productos nuevos, se actualiza solo ese sitemap. Reduce ruido, acelera descubrimiento y facilita el debugging cuando algo falla.
Arquitectura y enlazado interno: el fallo estructural que ninguna auditoría genérica ve
Se puede tener el mejor contenido, los canonicals perfectos y los logs limpios. Si la arquitectura interna es defectuosa, no importa. La autoridad no fluye, las páginas profundas mueren de sed y el rastreador no encuentra motivos para volver.
Profundidad de clic más allá del nivel 4 y cómo aplanarla sin perder taxonomía
Regla operativa: cualquier URL con potencial de tráfico debe estar a máximo 3-4 clics de la home. En un catálogo de 200.000 productos suena imposible, pero con paginación inteligente, hubs temáticos y bloques de enlazado curado es perfectamente viable.
¿Cómo aplanar sin cargarse la taxonomía? Con capas de navegación paralelas. La taxonomía oficial (Categoría → Subcategoría → Producto) se mantiene para el usuario. En paralelo, se crean hubs por atributos cruzados que enlazan directamente productos profundos desde niveles superiores. Un hub tipo «productos rebajados esta semana» o «más vendidos en marzo» puede llevar tráfico y autoridad a fichas que de otro modo estarían enterradas.
Enlazado contextual automatizado: dónde se rompe en 2026
Los sistemas de enlazado automático (relacionados, complementarios, ya visto) funcionaban bien cuando la lógica era simple. En 2026, con recomendadores basados en IA, se detecta un patrón nuevo: los relacionados devuelven productos casi idénticos, lo que refuerza la canibalización en vez de aliviarla.
La solución aplicable combina similaridad semántica con criterios de diversidad forzada. Si se muestran cinco relacionados, al menos dos deben pertenecer a subcategorías distintas del producto principal. Suena contraintuitivo, pero mejora tanto el enlazado como la exploración del usuario.
Tratamiento: hoja de ruta priorizada según impacto y esfuerzo
Diagnóstico sin plan de acción es teatro. Todo lo anterior sirve para nada si no se traduce en tareas concretas, priorizadas por impacto probable y coste de implementación. La matriz aplicable es sencilla: impacto alto/bajo por esfuerzo alto/bajo. Empezar siempre por impacto alto + esfuerzo bajo.
Qué atacar en las primeras dos semanas para ver movimiento en logs
Prioridades de arranque, en este orden estricto:
- Bloquear en robots.txt los parámetros que generen combinatoria sin valor (ordenación, filtros no indexables). Impacto casi inmediato en el reparto de rastreo.
- Corregir cadenas de redirect de 2+ saltos. Objetivo: cero cadenas encadenadas en las 5.000 URLs con más tráfico histórico.
- Detectar soft 404 masivos y aplicar 410 o restauración de contenido según corresponda.
- Reestructurar el sitemap en los segmentos descritos antes.
- Revisar canonicals inconsistentes (URL canonical distinta según user agent o parámetros de la petición).
En proyecto medio esto son entre 40 y 70 horas de trabajo repartidas entre desarrollo y consultoría. Y los logs suelen empezar a moverse a partir del día 10-14, cuando Googlebot recalibra su reparto.
Qué dejar para el trimestre siguiente sin comprometer la indexación
Todo lo que sea reestructuración profunda de arquitectura, migración de plantillas o rediseño de sistemas de enlazado contextual. Esto merece planificación con QA en staging, muestras de comparación pre/post y ventanas de despliegue controladas.
El error más común aquí: querer arreglar todo a la vez. Ejemplo de un proyecto de 2024 donde intentaron ejecutar simultáneamente cambios en canonicals, en sitemap, en robots y en plantillas de categoría. El resultado fueron seis semanas de fluctuación imposible de atribuir. Nadie sabía qué había causado qué. Lección aprendida: un cambio importante por sprint, medición limpia, decisión siguiente.
Preguntas frecuentes sobre errores SEO técnicos en sitios grandes
¿Cuáles son los errores SEO técnicos más comunes en sitios grandes?
Los cinco patrones que se repiten en diagnósticos: crawl budget mal repartido (Googlebot rastreando parámetros en lugar de contenido de valor), canibalización a escala entre variantes de producto, cadenas de redirects heredadas de migraciones, soft 404 con código 200 y arquitectura con profundidad de clic superior al nivel 4. En sitios de más de 100.000 URLs, estos errores no se detectan con auditorías por muestreo: requieren análisis de logs cruzado con Search Console.
¿Cómo se detecta un problema de crawl budget?
Con 60 días de logs de servidor filtrados por user-agent de Googlebot (verificado por reverse DNS). Si al ordenar por número de hits el top 20 no incluye las categorías principales ni los productos estrella, hay un problema de reparto. Otro indicador claro: frecuencia media de rastreo superior a 30 días en URLs con demanda de búsqueda.
¿Qué es la canibalización SEO y cómo afecta a un e-commerce?
La canibalización ocurre cuando varias URLs del mismo dominio compiten por la misma intención de búsqueda. En un e-commerce con miles de variantes de producto, no se limita a dos URLs peleando por una keyword: pueden ser 40 URLs compitiendo por 15 variaciones. El efecto: Google rota entre ellas en SERP, ninguna consolida ranking y el CTR global cae.
¿Cuántas URLs puede rastrear Google al día?
No hay número fijo. Googlebot ajusta el crawl budget según dos variables: capacidad de respuesta del servidor y calidad histórica percibida del contenido. Sitios bien optimizados pueden recibir entre 200.000 y 500.000 peticiones diarias del rastreador. Sitios con problemas de rendimiento pueden bajar a 30.000 o menos, insuficiente para catálogos superiores a 100.000 URLs.
Conclusión: el diagnóstico manda sobre la intuición
Todo lo anterior se resume en una idea. En un portal de estas características, la intuición del especialista sirve para formular hipótesis, no para tomar decisiones. Cada intervención necesita datos previos (logs, Search Console, análisis de canibalización) y datos posteriores para medir. Sin esa disciplina, el trabajo técnico se convierte en superstición.
La buena noticia es que los patrones se repiten. Cinco o seis diagnósticos en portales similares y ya se reconocen la mayoría de las hemorragias antes de abrir el proyecto. La mala es que cada portal de envergadura tiene siempre una anomalía única, algo heredado de una decisión olvidada de hace cinco años, que solo aparece cuando cruzas fuentes que nadie había cruzado antes. Ahí es donde se gana la partida.
