Estrategia de sitemap para un sitio con mucho contenido en 2026

Al final tendrás un sitemap que aguanta más de 50.000 URL, le dice a los buscadores qué páginas cambiaron de verdad y consigue que los posts nuevos se rastreen en horas en vez de semanas. Es la configuración que usamos en sitios de contenido que publican casi a diario y esperan pasar de mil artículos.

Un sitemap es un archivo que lista las URL de un sitio y, si quieres, cuándo cambió cada una por última vez. En un sitio pequeño apenas importa: Google encuentra cincuenta páginas bien enlazadas sin ayuda. En un sitio grande el sitemap deja de ser un detalle y se convierte en el mapa con el que los rastreadores deciden qué descargar y cada cuánto. Si está mal, los posts frescos quedan invisibles durante semanas mientras el rastreador relee páginas que no se han movido.

Qué necesitas antes de empezar

• La lista de cada URL canónica e indexable del sitio, generada desde la base de datos y no mantenida a mano.
• Una fecha de última modificación fiable por URL, que refleje un cambio real de contenido, no cada escritura en la base de datos.
• Acceso a Google Search Console y a Bing Webmaster Tools para enviar y vigilar.
• Un framework que genere XML en tiempo de petición o de build. Los ejemplos aquí usan Next.js, pero las reglas valen en cualquier lado.

Paso 1: conoce los dos límites duros

Google corta un solo archivo sitemap en 50.000 URL o 50MB sin comprimir, lo que llegue antes (Google Search Central). Puedes comprimir el archivo en gzip para ahorrar ancho de banda, pero el tope de 50MB se mide sin comprimir. Pasa cualquiera de los dos límites y Google rechaza el archivo.

El sitemap index resuelve esto. Es un archivo que lista otros sitemaps en lugar de URL, y puede referenciar hasta 50.000. En teoría son 2.500 millones de URL en un solo index. Ningún blog llega ahí. El punto es más estrecho: en cuanto pasas de 50.000 URL, dejas de publicar un archivo único y empiezas a publicar un index que apunta a varios fragmentos.

Paso 2: divide por tipo de contenido, no por un número al azar

La división ingenua es por cantidad: 50.000 URL por archivo, cortadas en orden de publicación. Funciona, pero tira a la basura una señal de diagnóstico. Mejor divide por tipo de contenido. Los artículos en un sitemap, las páginas de categoría en otro, las páginas estáticas en un tercero. Cada fragmento se queda bajo el límite y Google Search Console informa de la cobertura por cada sitemap. Cuando cae la indexación, ves qué tipo de contenido está afectado en vez de mirar un único número para todo el sitio. Segmentar por tipo es la práctica estándar justo por esto (Google Search Central).

Si un solo tipo sigue pasando de 50.000 URL, divide ese tipo por número: blog-1.xml, blog-2.xml y así, todos listados en el index.

Paso 3: incluye solo las URL que quieres indexar

Un sitemap es la lista de tus mejores URL, no de cada URL que responde. Incluye una página solo si devuelve 200, no está marcada noindex, no está bloqueada por el robots.txt y es su propia canónica. No listes nunca redirecciones, 404, variantes con parámetros o páginas que canonicalizan hacia otra. Mezclar URL no indexables en un sitemap manda una señal contradictoria: le pides a Google que indexe una página que ya le dijiste que ignore. En un sitio grande esas contradicciones se suman y erosionan la confianza en todo el archivo.

En un sitio multilingüe, declara cada variante de idioma con los alternate hreflang dentro de la entrada del sitemap, en vez de publicar tres veces la misma URL. Así las relaciones entre idiomas quedan explícitas y el recuento de URL se mantiene honesto.

Paso 4: mantén el lastmod honesto y quita el resto

Existen tres etiquetas opcionales: lastmod, changefreq y priority. Solo una se gana el sitio. Google ignora por completo priority y changefreq (Google Search Central), y añaden bytes a un archivo que intentas mantener pequeño. Quítalas.

lastmod es otra cosa. Es el único atributo del sitemap que los buscadores modernos usan de verdad, y Google lo lee solo cuando es preciso de forma constante. John Mueller lo dijo sin rodeos: falsear la fecha no ayuda al posicionamiento, y en cuanto Google decide que tu lastmod no es fiable deja de confiar en la etiqueta del todo (Search Engine Journal). La mayoría de los sitios lo mantiene tan mal que Google lo descuenta por defecto.

La regla es sencilla. Pon lastmod en la fecha de un cambio real de contenido, y en nada más. No lo muevas en cada escritura a la base de datos, cada migración de metadatos o cada deploy. Si el CMS toca una fila por motivos que el lector nunca ve, ese movimiento no debe mover el lastmod. Nosotros lo anclamos a la misma señal que le mostramos al lector como fecha de actualización, así la frescura que ve la máquina y la que ve la persona quedan alineadas. Lo contamos mejor en el artículo sobre la frescura de contenidos y la regla de los 90 días.

Paso 5: avisa al cambiar, porque el ping está muerto

Enviar un sitemap una vez le dice a los buscadores dónde vive. No les dice el momento en que un post nuevo se publica. El viejo empujón, el endpoint de ping del sitemap, ya no está. Google retiró su API de ping en 2023 y Bing dejó de usar la suya en 2022 (Ctrl blog).

El reemplazo es IndexNow, un protocolo que avisa a los buscadores participantes en el instante en que una URL se añade, cambia o se elimina. Lo usan Bing, Yandex, Naver y Seznam. Google lo probó y, a mediados de 2026, aún no lo usa. Bing informa de que el 22% de las URL clicadas en sus resultados vienen ya de envíos por IndexNow. La guía oficial no es lo uno o lo otro: mantén el sitemap como inventario completo y añade IndexNow para las notificaciones instantáneas de cambio (IndexNow.org). Para Google, un sitemap fresco y preciso más un buen enlazado interno sigue siendo la vía de descubrimiento.

Paso 6: genéralo de forma dinámica en Next.js

El XML mantenido a mano se pudre el día en que alguien olvida actualizarlo. Genera el sitemap desde los mismos datos que renderizan las páginas. En el App Router de Next.js, generateSitemaps devuelve un array de ids, y Next sirve cada fragmento en /sitemap/[id].xml (documentación de Next.js). Cuenta el total de posts, divide por un tamaño de bloque por debajo de 50.000 y mapea cada id a un rango de la base de datos. Cachea la consulta 24 horas, así un sitio que publica a diario no reconstruye todo el mapa en cada visita del rastreador.

Cómo verificar que funciona

1. Envía la URL del index en Google Search Console y Bing Webmaster Tools, no los fragmentos hijos. Google descubre los hijos a través del index.
2. Abre el informe de Sitemaps unos días después. Cada fragmento debería aparecer como correcto, con un número de URL descubiertas cercano al que esperas.
3. Revisa al azar un sitemap hijo en el navegador. Debe devolver XML válido, listar solo URL canónicas en 200 y llevar fechas lastmod que coincidan con ediciones reales.
4. Pasa la herramienta de inspección de URL por un post recién publicado. Si Google lo encontró a través del sitemap, el informe lo dice.

Fallos frecuentes y cómo resolverlos

• Sitemaps hijos en la carpeta equivocada. Un sitemap listado en un index debe estar en la misma carpeta o más abajo (Google Search Central). Un index en la raíz no puede referenciar un hijo en una carpeta hermana. Mantenlos al nivel del index o por debajo.
• lastmod que no para quieto. Si cada deploy toca cada fecha, Google aprende que la etiqueta es ruido y la ignora. Ancla el lastmod solo al cambio de contenido.
• Enviar cada fragmento a mano. Añadir cada sitemap hijo por separado ensucia el informe y no aporta nada. Envía solo el index.
• Páginas noindex dentro del sitemap. La contradicción más común. Filtra la lista en el momento de generarla, así una página no puede estar a la vez listada y suprimida.
• Tratar el sitemap como una orden de rastreo. Es una pista, no una orden. Ayuda al descubrimiento, no fuerza la indexación. Las páginas pobres o duplicadas no se posicionan solo por estar en un sitemap.

Para ir más allá

El sitemap es una pieza de la capa de descubrimiento. Combínalo con la disciplina de frescura de nuestra guía de la regla de los 90 días, con las reglas de acceso de rastreadores en Cloudflare y los rastreadores de IA, y con el resto de la base previa al lanzamiento en nuestra checklist de SEO técnico. Si los motores de IA forman parte de tu plan de tráfico, llms.txt describe el archivo que hace por los modelos de lenguaje lo que el sitemap hace por los rastreadores.