Antes de rediseñar, cuenta tus familias de URLs
Un censo de cinco sitemaps públicos halló que el 80% de las URLs vive en familias de más de 100 páginas. Cómo contar las tuyas y qué cambia al rediseñar.
Casi todos los rediseños se pelean con la evidencia equivocada. El equipo pasa semanas discutiendo el hero, la escala tipográfica y el menú móvil, publica el sitio nuevo y doce meses después la curva de tráfico se parece sospechosamente a la anterior. Cambió el diseño. No cambió el inventario.
El dato que anticipa si un rediseño va a pagarse es aburrido y medible: qué porcentaje de las URLs que envías pertenece a una familia capaz de ganar un clic. Todo lo demás del rediseño va detrás de ese número, incluido cuántas plantillas necesitas diseñar.
Una familia es una ruta padre, no una página
Agrupa todas las URLs del sitemap por su ruta padre y el sitio deja de parecer 5.000 páginas para parecer 20 plantillas. /productos/camisa-lino, /productos/abrigo-lana y /productos/cinturon-cuero viven en /productos/. Eso es una familia, tres miembros, una plantilla.
Hice ese censo sobre cinco índices de sitemap públicos el 1 de noviembre de 2026 —dos minoristas de ropa, una marca de calzado, una publicación de diseño y un blog de ingeniería— y muestreé 34.750 URLs. Los sitios quedan sin nombre a propósito: lo que importa es la forma, y nombrarlos convertiría un hallazgo estructural en una crítica al catálogo de alguien.
El 80,4% de esas URLs estaba en familias de 100 miembros o más. Solo el 3,3% estaba en familias de diez o menos. Cuatro de los cinco sitios se ubicaron entre 89% y 96%. El valor atípico fue la publicación, con 34,6%.
Toma los decimales como aproximados. La clasificación es heurística: una familia es todo lo que comparte ruta padre, muestreé los sitemaps hijos a intervalos regulares en vez de tomar los primeros, y un minorista con catálogo grande siempre va a verse más generado que una revista. Lo que importa es la dirección, y ahí no hay discusión.
| Tipo de sitio | URLs muestreadas | En familias de 100+ | Familia más grande | Peso en el sitemap |
|---|---|---|---|---|
| Minorista de ropa A | 5.854 | 93,7% | /products/ bajo prefijos regionales | 16,4% por prefijo |
| Minorista de calzado | 2.202 | 96,1% | /collections/ | 61,1% |
| Minorista de ropa B | 8.572 | 89,1% | /products/ | 33,9% |
| Publicación de diseño | 7.913 | 34,6% | /author/ | 21,0% |
| Blog de ingeniería | 10.209 | 96,3% | entradas en la raíz | 36,3% |
La familia más grande casi nunca es la que vende
Vuelve a la fila de la publicación. Su familia más grande, con diferencia, es /author/: el 21% de todo lo que envía. Le sigue /category/, con 5,8%. Esas páginas existen porque el CMS las genera. No son lo que la publicación vende ni lo que un lector viene a buscar. Una de cada cinco URLs enviadas es una página que nadie decidió publicar.
Las filas de comercio tienen una versión más silenciosa del mismo problema: duplicación por prefijo. Un minorista enviaba casi el mismo número de productos bajo tres prefijos regionales distintos. La plantilla contaba tres veces, el catálogo una. Otro tenía /products/ y un /products/ con prefijo de idioma con cifras casi idénticas. Eso no es un problema de contenido ni de diseño: es un problema de política de URLs, y un rediseño que arrastra la lógica de rutas lo reproduce tal cual.
El patrón se sostiene en todas las categorías, y por eso dejé de tratarlo como una curiosidad de SEO. El sitemap es la descripción más honesta de de qué está hecho un sitio. Casi ningún equipo lo ha leído nunca.
El censo de una hora
No necesitas una herramienta. Necesitas una hora y la disposición a deprimirte.
- Descarga el índice de sitemaps, no solo
sitemap.xml. Si el índice es largo, toma los sitemaps hijos a intervalos regulares para no muestrear únicamente el feed de productos. - Reduce cada URL a su ruta y agrupa por ruta padre. Una función de hoja de cálculo o veinte líneas de script bastan. Solo cuentas miembros por familia.
- Abre el informe Páginas de Search Console y aplica el filtro de prefijo una vez por familia. Anota clics, impresiones y posición media.
- Ordena por clics, no por tamaño. La familia grande y la familia que factura rara vez son la misma.
- Clasifica cada familia como comercial, soporte, duplicada o cobertura generada, y suma el peso comercial sobre el total enviado.
Ese último paso es todo el ejercicio. Si el 8% de tu sitemap son páginas que pueden terminar en compra o en lead, tu problema no es un LCP lento ni un hero cansado. Es que el 92% restante diluye el 8% que te importa.
El veredicto es por familia, no por página
Cuando las familias están clasificadas, la decisión deja de ser cuestión de gusto. Cada familia recibe uno de cuatro veredictos, y cada veredicto tiene una prueba que un responsable no técnico puede resolver en una reunión.
| Familia | Prueba | Veredicto |
|---|---|---|
| Comercial — aquí caen clics e ingresos | ¿Un desconocido que llega en frío ve una oferta en una pantalla? | Se queda. Recibe el presupuesto de diseño y plantilla. |
| Soporte — documentación, comparativas, políticas, detalle de precios | ¿Elimina una objeción concreta antes de comprar? | Se queda, con la plantilla compartida. Sin diseño a medida. |
| Duplicada — segunda ruta al mismo texto | ¿Mismo H1, mismo contenido, otra URL? | Se consolida en una URL canónica y el resto se redirige. |
| Cobertura generada — variantes que nadie busca | Cero clics en 90 días y ningún enlace interno que defenderías | Se elimina con un 410. No con noindex. |
La cuarta fila es donde se equivocan casi todos los proyectos de limpieza, así que conviene ser preciso.
"Ponle noindex a la basura" no hace lo que la gente cree
La documentación de presupuesto de rastreo de Google es inusualmente directa en este punto. Desaconseja noindex justo para este caso, porque el rastreador igual tiene que descargar la página para ver la etiqueta: "Don't use noindex, as Google will still request, but then drop the page when it sees a noindex meta tag or header in the HTTP response, wasting crawling time."
Y es igual de directa al aclarar que bloquear no genera un regalo para tus páginas comerciales: "Don't use robots.txt to temporarily reallocate crawl budget for other pages... Google won't shift this newly available crawl budget to other pages unless Google is already hitting your site's crawl capacity limit."
Sobre eliminación definitiva, un 410 o un 404 es la señal fuerte, mientras que las URLs bloqueadas permanecen más tiempo en la cola y se vuelven a rastrear cuando se levanta el bloqueo.
Lee las tres frases juntas y la conclusión es inevitable: desindexar páginas generadas es higiene de índice, no una palanca de rendimiento. Limpia lo que reporta Search Console y evita que el rastreador reprocese páginas que nadie quiere. No le entrega más rastreo a tus páginas de servicio. Si un proveedor te vende un programa de desindexación como solución de posicionamiento, pregúntale cuál de esas tres frases cree que está equivocada.
Los usos honestos de un 410 son más estrechos y mejores: matar familias que duplican una canónica y familias sin dueño comercial. Ese par casi siempre representa una porción relevante del sitemap: alcanza para justificar un sprint y rara vez alcanza por sí solo para explicar una caída de tráfico.
Qué cambia esto en un rediseño
Aquí el censo deja de ser un ejercicio de SEO y empieza a definir alcance real, que es la parte que le toca a quien construye el sitio. El inventario de plantillas de un rediseño debería ser igual al número de familias que sobrevivieron al censo, no al número de tipos de página que tenía el sitio viejo por casualidad.
Tres reglas que se desprenden, y que aplico en trabajo con clientes cada vez que hay un rediseño sobre la mesa:
- Ninguna plantilla a medida sin dueño y sin ruta de conversión. Si nadie puede decir para qué existe la familia y qué debería hacer un visitante ahí, recibe la plantilla compartida o recibe un 410.
- Toda familia generada necesita un camino de enlaces hacia una comercial. Las plantillas deciden si una página puede posicionar; los enlaces internos deciden si alguna vez lo hará. Un catálogo que solo enlaza a otros catálogos es un callejón sin salida con mil puertas.
- El esfuerzo de diseño sigue al peso comercial. Si una cuarta parte de lo enviado concentra los clics, la revisión de diseño pertenece a esa cuarta parte. El resto es una decisión de plantilla, no de diseño.
Y la incómoda: si el sitio nuevo regenera el mismo mapa de familias, con la misma proporción de URLs que ganan y que no ganan, el rediseño es un cambio de piel con mejor tipografía. Ese es el resultado que entregan la mayoría de los rediseños, y el censo es la forma más barata de descubrirlo antes de firmar el contrato.
Una lectura gruesa del peso comercial, a partir de la forma de los cinco sitemaps:
| Peso comercial de las URLs enviadas | Qué significa | Qué hacer primero |
|---|---|---|
| Por encima de 40% aproximadamente | La estructura no es tu restricción | No rediseñes. Arregla la oferta, la prueba y el mensaje. |
| Entre 15% y 40% | La mitad del sitemap es lastre | Consolida duplicados y luego diseña bien las plantillas comerciales. |
| Por debajo de 15% | El sitemap es el producto | Restringe y desduplica antes de empezar cualquier diseño. |
Esas bandas son criterio, no medición. El censo es la medición, y toma una hora. Un rediseño toma un trimestre. Haz primero lo barato. Y si quieres que el rediseño se defina por lo que el sitemap realmente contiene y no por cómo se ve la portada, eso es trabajo de diseño y desarrollo web, no un tablero de referencias visuales. Si prefieres que alguien haga el censo sobre tu sitemap antes de decidir, cuéntanos qué vas a rediseñar y empezamos por el inventario, no por el hero.
Dos lecturas relacionadas si quieres profundizar: la mecánica de sacar páginas del índice sin romper nada está en qué hace realmente noindex en páginas compartibles, y si el censo te convence de que el problema es el stack, la arquitectura componible es la comparación honesta. También conviene revisar la arquitectura multilingüe si tu sitemap tiene prefijos por idioma como los del ejemplo: es exactamente donde aparece la duplicación silenciosa.
Preguntas Frecuentes
¿Qué es una familia de URLs en un sitemap?
Una familia de URLs son todas las URLs que comparten la misma ruta padre. En /productos/camisa-lino, /productos/abrigo-lana y /productos/cinturon-cuero la familia es /productos/ y tiene tres miembros. Agrupar el sitemap así muestra de qué plantillas está hecho realmente el sitio, en lugar de tratar 5.000 URLs como 5.000 decisiones distintas.
¿Cómo cuento las familias de URLs en Search Console?
Abre el informe Páginas y usa el filtro de prefijo de URL (por ejemplo /colecciones/), luego lee clics e impresiones de ese filtro. Repite por cada familia. En una hora tienes los clics por familia, que es el dato que decide si una familia merece plantilla propia, una consolidación o una eliminación definitiva.
¿Conviene aplicar noindex a las páginas generadas o eliminarlas?
Depende del objetivo. noindex saca la página del índice, pero Google igual la descarga para ver la etiqueta, así que no ahorra tiempo de rastreo. robots.txt bloquea la descarga pero deja la URL en la cola, y Google dice que no reasignará ese presupuesto a otras páginas salvo que el sitio ya esté tocando su límite de capacidad. Si la página no debe existir nunca más, la respuesta limpia es un 410.
