En 2021 heredé un sitio WooCommerce con 140,000 URLs de productos, un sitemap.xml único que alcanzaba exactamente 50,000 entradas, y un cliente que no podía entender por qué Google Search Console mostraba solo una fracción de sus páginas indexadas. El archivo sitemap simplemente... se detenía. Sin error. Sin advertencia. Solo truncamiento silencioso. Es el tipo de cosa que te cuesta ranking sin nunca enviar una señal visible de que algo está mal.
Si tu sitio está creciendo más allá de 50,000 URLs, este es el post que necesitas leer antes de chocar contra esa pared.
Por Qué Existe el Límite de 50,000 URLs
El protocolo de Sitemaps, mantenido conjuntamente por Google, Bing y otros, establece dos restricciones estrictas en un archivo sitemap único: no más de 50,000 URLs, y no mayor de 50MB sin comprimir. Estos no son sugerencias. Googlebot dejará de analizar el archivo en el primer límite que encuentre.
Honestamente, el techo de 50MB rara vez es el problema. La mayoría de las URLs son lo suficientemente cortas como para que necesitarías rutas cómicamente largas para alcanzar el límite de tamaño de archivo antes del límite de conteo de URLs. El límite de 50,000 URLs es el que afecta a la gente.
Entonces, ¿qué haces cuando tu catálogo, tu archivo de blog, tu sección de contenido generado por usuarios cruza ese límite? Usas un archivo de índice de sitemap.
Qué es realmente un archivo de índice de sitemap
Concepto simple. En lugar de un sitemap con URLs en él, creas un archivo XML padre que apunta a múltiples sitemaps hijo. Cada sitemap hijo puede contener hasta 50,000 URLs. El archivo de índice en sí puede hacer referencia a hasta 50,000 sitemaps hijo. Entonces el límite teórico es de 2.5 mil millones de URLs. No vas a alcanzarlo.
La estructura se ve así:
`` sitemap_index.xml ├── sitemap-posts-1.xml (hasta 50,000 posts de blog) ├── sitemap-posts-2.xml (posts que se desbordan) ├── sitemap-products-1.xml (hasta 50,000 productos) ├── sitemap-products-2.xml (productos que se desbordan) └── sitemap-pages.xml (páginas estáticas) ``
El archivo de índice usa <sitemapindex> como elemento raíz en lugar de <urlset>. Cada hijo está envuelto en una etiqueta <sitemap> con una <loc> que apunta al archivo hijo, y opcionalmente una marca de tiempo <lastmod>.
Lo que envías a Google Search Console es la URL del archivo de índice, no cada hijo individual. Un envío, una única fuente de verdad.
Cómo dividir tus URLs de forma inteligente
Aquí es donde la mayoría de los tutoriales se equivocan. Dicen "solo divide tus URLs en grupos de 50,000" y listo. Pero los límites de los grupos importan para la mantenibilidad y para la lógica de rastreo de Googlebot.
Divido por tipo de contenido, no por número arbitrario. Siempre. Cada vez.
Divide primero por tipo de contenido
- Los productos en su propia serie de sitemaps (sitemap-products-1.xml,
sitemap-products-2.xml) - Las publicaciones del blog en su propia serie
- Las páginas de categoría y etiqueta juntas (son navegacionales, tratalas como un solo grupo)
- Las páginas estáticas (Acerca de, Contacto, landing pages) en un archivo único, generalmente bien por debajo de 1,000 URLs
¿Por qué importa esto? Porque cuando una base de datos de productos recibe una actualización masiva, solo los sitemaps de productos necesitan regenerarse. No estás invalidando y regenerando un archivo monolítico que mezcle productos con publicaciones de blog. Googlebot también tiende a rastrear los sitemaps secuencialmente, así que agrupar por tipo le da una señal más clara sobre qué tipo de contenido va a encontrar.
Luego pagina dentro de cada tipo
Una vez que un tipo de contenido supera las 50,000 URLs, pagínalo. Usa una convención de nomenclatura consistente desde el primer día. Yo uso sitemap-{type}-{page}.xml. No uses fechas en el nombre del archivo. Cometí ese error en un sitio de noticias en 2019 y terminé con nombres de archivo como sitemap-articles-2019-march.xml que se volvieron completamente inútiles en el momento en que necesitábamos regenerar contenido histórico. Usa páginas numeradas.
Mantén lastmod honesto
El elemento <lastmod> en tus sitemaps secundarios debe reflejar cuándo se modificó realmente el contenido, no cuándo regeneraste el sitemap. He visto configuraciones donde cada regeneración estampa cada URL con la fecha de hoy. Eso entrena a Googlebot a ignorar completamente tu lastmod porque la señal es ruido. Usa la marca de tiempo de modificación real de tu CMS. En WordPress, eso es post_modified_gmt de la tabla wp_posts.
Herramientas: Qué realmente funciona a escala
Para sitios de WordPress (que es la mayoría de lo que construimos en Seahawk), las opciones que realmente uso son:
- Yoast SEO maneja los índices de sitemap automáticamente una vez que tienes más de 1,000 URLs por tipo de contenido. Genera archivos limpios y segmentados. Pero el tamaño de lote predeterminado es 1,000 URLs por sitemap hijo, que es conservador. Puedes filtrar eso hacia arriba con
wpseo_sitemap_entries_per_page. Normalmente lo empujo a 5,000 en servidores bien alojados. - Rank Math hace lo mismo, con un control ligeramente más granular sobre qué tipos de contenido y taxonomías obtienen sus propios sitemaps hijo. En un sitio cliente reciente con 80,000 productos de WooCommerce, la segmentación lista para usar de Rank Math fue más limpia que la de Yoast.
- La generación personalizada con WP-CLI es a lo que recurro cuando el sitio tiene tipos de contenido inusuales o los sitemaps generados por plugins son demasiado lentos para generar. He escrito scripts que consultan la base de datos directamente, paginar resultados en chunks de 10,000, escribir el XML al disco, y luego escribir el archivo de índice al final. Se ejecuta en menos de 30 segundos para 200,000 URLs. La clave es escribir en un archivo temporal y moverlo atómicamente a su lugar para que Googlebot nunca golpee un archivo medio escrito.
Para stacks que no son WordPress, Screaming Frog SEO Spider puede rastrear tu sitio y generar un índice de sitemap para ti, aunque es mejor como herramienta de validación que como generador de sitemap de producción. Para producción, genera sitemaps desde tu fuente de datos, no desde un rastreador. Los rastreadores se pierden cosas.
Envío y validación en Search Console
Ve a Google Search Console, abre el informe de Sitemaps, y envía la URL de tu archivo de índice. Una URL. Eso es todo.
Después del envío, espera 24-48 horas y luego verifica dos cosas:
- Enviado vs Descubierto. El conteo de "URLs descubiertas" debe estar subiendo hacia tu conteo real de URLs. Si se estanca de forma extraña temprano, probablemente tengas un problema de presupuesto de rastreo o un sitemap hijo mal formado.
- Estado individual del sitemap secundario. Search Console te mostrará cada sitemap secundario y su estado. Si uno de ellos está retornando un error, puedes aislarlo sin tocar los demás. Esta es la ventaja subestimada de la estructura de índice.
Bing Webmaster Tools funciona de la misma manera. Envía el archivo de índice, no los secundarios. Te toma dos minutos.
Errores Comunes que Veo Constantemente
Seahawk audita sitios para agencias con bastante regularidad. Los mismos errores de sitemap aparecen una y otra vez.
URLs sin indexar en el sitemap. Si una URL tiene una etiqueta meta noindex o un encabezado X-Robots, no debería estar en tu sitemap. Punto. Un sitemap es una recomendación para rastrear e indexar. Incluir URLs sin indexar desperdicia presupuesto de rastreo y confunde la señal. Ejecuto un rastreo rápido con Screaming Frog contra las URLs del sitemap y filtro las respuestas noindex antes de cualquier lanzamiento de sitio importante.
URLs bloqueadas en el sitemap. Aún peor que noindex: URLs que están desallowidas en robots.txt pero que siguen listadas en el sitemap. Googlebot puede ver la contradicción. No te penalizará por ello, pero es descuidado y desperdicia tiempo.
No actualizar el archivo de índice después de agregar un sitemap secundario nuevo. Esto suena obvio pero atrapa implementaciones personalizadas. Agregas un nuevo tipo de contenido, generas un nuevo archivo de sitemap secundario, y olvidas agregar la entrada <sitemap> al índice. El archivo secundario existe en disco pero nada apunta a él. He visto esto pasar desapercibido durante meses.
Enviar sitemaps secundarios individualmente en lugar del índice. Si tienes 12 sitemaps secundarios y los envías los 12 a Search Console por separado, has perdido el beneficio organizacional. Envía el índice. Deja que se propague.
Presupuesto de Rastreo: La Visión Más Amplia
Los archivos de índice de sitemap se conectan directamente con la gestión del presupuesto de rastreo. La documentación de Google sobre presupuesto de rastreo vale la pena leer si estás operando a esta escala. En resumen: Googlebot tiene una cantidad finita de tiempo que invertirá en tu sitio por día, y un sitemap de índice bien estructurado le ayuda a invertir ese tiempo en tu contenido de mayor prioridad primero.
En sitios grandes, coloco contenido recién actualizado en su propio sitemap hijo. Algunas implementaciones que he hecho usan un sitemap-recent.xml que contiene solo URLs modificadas en los últimos 30 días, actualizado cada hora. Googlebot recrawlea ese agresivamente. Los archivos de sitemap histórico más antiguos se rastrean con menos frecuencia, lo que está bien porque ese contenido no cambia.
Esto no es un truco. Es solo hacer que la señal de rastreo coincida con la realidad del contenido.
FAQ
¿Cuántos sitemaps hijo puede contener un archivo de índice de sitemap?
El protocolo permite hasta 50,000 sitemaps hijo en un único archivo de índice. En la práctica, si te acercas a ese número tienes cientos de millones de URLs y estás enfrentando problemas que la mayoría de sitios nunca enfrentan. Para la gran mayoría de sitios grandes, tendrás entre 5 y 50 sitemaps hijo.
¿Necesito comprimir mis archivos de sitemap con gzip?
No es necesario, pero vale la pena hacerlo para archivos grandes. Un sitemap de 50MB se comprime a aproximadamente 3-5MB con gzip. Googlebot acepta archivos .xml.gz sin configuración adicional. La mayoría de servidores web modernos manejarán esto de forma transparente si habilitas compresión gzip a nivel de servidor. Para sitemaps de archivos estáticos generados en disco, pre-comprimo con gzip y sirvo el .xml.gz directamente.
¿Debo incluir sitemaps de imágenes o videos en el índice?
Sí. Si estás usando extensiones de sitemap de imágenes o sitemaps de video, pueden incluirse como sitemaps hijo en el mismo archivo de índice. Mantenlos en sus propios archivos hijo en lugar de mezclar datos de imágenes en tus sitemaps de URL estándar. Mantiene los archivos más pequeños y facilita regenerar solo el sitemap de imágenes cuando tu biblioteca de medios se actualiza.
¿Qué ocurre si un sitemap hijo devuelve un 404?
Search Console marcará ese hijo como con error en el informe de Sitemaps. Googlebot seguirá procesando los otros sitemaps hijo en el índice. No invalidará el índice completo, pero las URLs que solo aparecen en ese hijo con 404 no se descubrirán a través del sitemap. Corrígelo rápidamente. El error persiste en el informe de Search Console durante semanas incluso después de que lo corrijas, lo que es molesto pero inofensivo.
¿Puedo usar un índice de sitemap en un sitio pequeño?
Técnicamente sí, pero no hay razón para hacerlo. La complejidad adicional no vale la pena por debajo de 10,000 URLs. Un sitemap.xml único es más simple de mantener, más simple de depurar y hace exactamente el mismo trabajo. Usa un archivo de índice cuando lo necesites, no antes.
---
El límite de 50,000 URLs sorprende a la gente cada vez, generalmente en el peor momento posible, como justo antes del lanzamiento de un producto. Estructurar el índice correctamente una vez significa que nunca tendrás que pensar en ello de nuevo mientras el sitio crece. Vale la pena dedicar una hora a la configuración.
Lectura relacionada: Investigación de palabras clave en búsqueda con IA en 2026: qué es, por qué es importante la búsqueda tradicional, búsqueda con IA, y SEO multilingüe.