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.Sitemaps protocol, maintained jointly by Google, Bing, and others, sets two hard constraints on a single sitemap file: no more than 50,000 URLs, and no larger than 50MB uncompressed. These aren't suggestions. Googlebot will stop parsing the file at whichever limit it hits first.
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) `` sitemap_index.xml ├── sitemap-posts-1.xml (up to 50,000 blog posts) ├── sitemap-posts-2.xml (overflow posts) ├── sitemap-products-1.xml (up to 50,000 products) ├── sitemap-products-2.xml (overflow products) └── sitemap-pages.xml (static pages) ``
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>.<sitemapindex> as the root element instead of <urlset>. Each child is wrapped in a <sitemap> tag with a <loc> pointing to the child file, and optionally a <lastmod> timestamp.
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)
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.sitemap-{type}-{page}.xml . Don't use dates in the filename. I made that mistake on a news site in 2019 and ended up with filenames like sitemap-articles-2019-march.xml that became completely meaningless the moment we needed to regenerate historical content. Stick to numbered pages.
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.<lastmod> element in your child sitemaps should reflect when the content was actually last modified, not when you regenerated the sitemap. I've seen setups where every regeneration stamps every URL with today's date. That trains Googlebot to ignore your lastmod entirely because the signal is noise. Use your CMS's actual modified timestamp. In WordPress, that's post_modified_gmt from the wp_posts table.
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. handles sitemap indexes automatically once you have more than 1,000 URLs per post type. It generates clean, segmented files. But the default batch size is 1,000 URLs per child sitemap, which is conservative. You can filter that up with
wpseo_sitemap_entries_per_page. I usually push it to 5,000 on well-hosted servers. - 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. does the same, with slightly more granular control over which post types and taxonomies get their own child sitemaps. On a recent client site with 80,000 WooCommerce products, Rank Math's segmentation out of the box was cleaner than Yoast's.
- 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. is what I reach for when the site has unusual content types or the plugin-generated sitemaps are too slow to generate. I've written scripts that query the database directly, paginate results in chunks of 10,000, write the XML to disk, and then write the index file last. Runs in under 30 seconds for 200,000 URLs. The key is writing to a temp file and atomically moving it into place so Googlebot never hits a half-written file.
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.Screaming Frog SEO Spider can crawl your site and generate a sitemap index for you, though it's better as a validation tool than a production sitemap generator. For production, generate sitemaps from your data source, not from a crawler. Crawlers miss things.
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.Google Search Console, open the Sitemaps report, and submit your index file URL. One URL. That's it.
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. The "Discovered URLs" count should be climbing toward your actual URL count. If it plateaus weirdly early, you likely have a crawl budget issue or a malformed child sitemap.
- 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. Search Console will show you each child sitemap and its status. If one child is returning an error, you can isolate it without touching the others. This is the underrated advantage of the index structure.
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. If a URL has a noindex meta tag or X-Robots header, it should not be in your sitemap. Full stop. A sitemap is a recommendation to crawl and index. Including noindexed URLs wastes crawl budget and confuses the signal. I run a quick Screaming Frog crawl against the sitemap URLs and filter for noindex responses before any major site launch.
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. Even worse than noindex: URLs that are disallowed in robots.txt but still listed in the sitemap. Googlebot can see the contradiction. It won't penalise you for it, but it's sloppy and it wastes time.
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. This sounds obvious but it trips up custom implementations. You add a new content type, generate a new child sitemap file, and forget to add the <sitemap> entry to the index. The child file exists on disk but nothing points to it. I've seen this sit unnoticed for months.
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. If you have 12 child sitemaps and you submit all 12 to Search Console separately, you've lost the organisational benefit. Submit the index. Let it cascade.
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.Google's documentation on crawl budget is worth reading if you're operating at this scale. The short version: Googlebot has a finite amount of time it'll spend on your site per day, and a well-structured sitemap index helps it spend that time on your highest-priority content first.
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.sitemap-recent.xml that only contains URLs modified in the last 30 days, refreshed hourly. Googlebot recrawls that one aggressively. The older historical sitemap files get crawled less frequently, which is fine because that content isn't changing.
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.need to, but it's worth doing for large files. A 50MB sitemap compresses down to roughly 3-5MB with gzip. Googlebot accepts .xml.gz files without any configuration. Most modern web servers will handle this transparently if you enable gzip compression at the server level. For static-file sitemaps generated to disk, I pre-compress with gzip and serve the .xml.gz directly.
¿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.