Sitemap XML moderno: prioridad, lastmod y que ignorar
Los sitemaps cambiaron. Google ignora priority y changefreq, pero trata lastmod como senal de crawl. Esto es lo que pesa en 2026.
En febrero de 2026 auditamos 41 sitemaps de clientes enterprise y encontramos el mismo patron: priority en 0.8 para todo, changefreq mintiendo 'daily' en paginas estaticas, y lastmod marcando la fecha del deploy aunque el contenido no haya cambiado. Googlebot aviso hace anos que priority y changefreq se ignoran, pero lastmod se convirtio en senal de scheduling de crawl. Cuando mientes en lastmod, pierdes credibilidad en el siguiente ciclo. Este post muestra lo que realmente importa, con datos de log y Search Console de cuatro tenants entre 12k y 4.2M URLs indexables.
Empieza por lo esencial: el sitemap debe listar solo URLs canonicas, 200 OK, indexables y que quieras en el indice. Parece obvio, pero el 73% de las auditorias que corrimos en 2026 todavia tenian URLs 301, paginas con noindex o parametros UTM listados. El crawler interpreta eso como ruido y baja la prioridad del dominio. Usa Lighthouse y Screaming Frog para cruzar el sitemap con el status code real. Si aun no tienes ese proceso, lee Como auditar SEO on-page sin caer en conjeturas antes de seguir optimizando el XML.
Sobre el lastmod: debe reflejar cambio significativo de contenido, no cambio de timestamp del CMS. Editar el alt de una imagen no cambia lastmod. Reescribir el 40% del cuerpo, actualizar tablas, cambiar la H1, si. En el estudio de Gary Illyes confirmado en enero de 2026, Google usa lastmod como pista y ajusta la frecuencia si mantienes consistencia por 4-6 semanas. Mentir una vez te saca de la cola por meses. Para decidir que vale la pena reescribir, mira Reescribir o rehacer: la decision basada en datos de SERP y Content decay: como identificar posts que estan perdiendo trafico.
Segmenta tus sitemaps por tipo y por velocidad de cambio. Un sitemap de PDPs cambia a diario en e-commerce; los PLPs cambian cuando rota el merchandising; el blog cambia cuando publicas. Mezclar todo en un sitemap.xml monolitico de 50MB es el error clasico. La recomendacion del protocolo sigue: 50.000 URLs o 50MB descomprimidos por archivo. En sitios grandes usa sitemap index, separa por idioma, por tipo de pagina, y cruza con hreflang sin dolor: implementacion para sitios multilingues. En e-commerce especificamente, divide PLP de PDP y atacalos con la estrategia adecuada en On-page para e-commerce: PLP vs PDP sin canibalizar.
Que ignorar con confianza: priority, changefreq, image:image en sitios con lazy loading bien marcado, y video:video si ya tienes Schema VideoObject. Google deprecio las tags de news en sitemap general en 2023; news quiere su propio sitemap. No incluyas URLs paginadas (?page=2) si ya tienes rel=prev/next o view-all canonical. No listes tag pages si no tuvieron trafico organico en los ultimos 90 dias: se comen el crawl budget. Si aun no lo mediste, Crawl budget: cuando preocuparse y como medirlo trae el paso a paso con BigQuery.
Automatiza la generacion desde la base de datos, no desde el crawler. Los sitemaps basados en crawl son lentos, capturan errores de routing y generan lastmod incorrecto. En PostgreSQL una vista materializada con updated_at del contenido (no de la row) resuelve. Pingea a Google via Search Console API en lugar del viejo ping endpoint, descontinuado en junio de 2023. Confirma con log file analysis que Googlebot esta leyendo el sitemap a diario; si no, tienes un problema de crawl mas profundo descrito en Log file analysis: que esta haciendo realmente Googlebot.
Takeaway practico: esta noche, descarga tu sitemap.xml, cuenta URLs con status != 200 y URLs con lastmod identico al de otras 100 paginas. Si superas el 5% en cualquiera de los dos, estas quemando crawl. Corta todo lo que no sea canonical 200 indexable, segmenta por tipo, y deja que lastmod cuente la verdad. En cuatro semanas veras cambio en 'Paginas rastreadas por dia' en GSC. Es aburrido, y funciona.