Google desaconseja el truco del sitemap que fuerza rastreo diario: qué sí funciona, medido

Alguien encontró un atajo para que Google rastree su web todos los días: añadir un parámetro con marca de tiempo —?v= y el timestamp— a las URLs de los ficheros de sitemap listados dentro del índice, de modo que cada día parezcan direcciones nuevas. Es la misma técnica de cache busting que se usa para forzar la recarga de un CSS.

Y funcionaba: el rastreador volvía a diario. John Mueller, de Google, ha respondido que es mala idea, y el intercambio deja a la vista algo más útil que el truco.

Qué respondió Google

Según recoge Search Engine Journal, Mueller preguntó primero para qué serviría eso —«¿por qué usarías cache busting en un fichero de sitemap?»— y, tras la aclaración, fue explícito:

«Creo que es mala idea, porque estás señalando que la URL canónica de un contenido debería estar cambiando constantemente. Eso no es bueno para los buscadores, y no es bueno para tu medición. Tener URLs limpias y estables es importante.»

Un matiz que conviene no pasar por alto: quien describe la técnica dice que el parámetro va en las URLs de los ficheros de sitemap dentro del índice, no en las URLs de las páginas. La respuesta de Mueller, en cambio, habla de la canónica del contenido. Sea porque la advertencia va más allá del caso concreto o porque el planteamiento se prestaba a confusión, la conclusión práctica es la misma: Google lo desaconseja y no hay que hacerlo. Tampoco lo ha calificado de spam.

Nota de transparencia: el intercambio ocurrió en Bluesky y, a fecha de publicación de esta pieza, solo lo recoge un medio. Las citas van atribuidas a esa cobertura y no hemos podido contrastar el hilo original.

Lo que sí dice la documentación oficial

Aquí ya no hay interpretación, porque está escrito en la documentación de Google Search Central. Dos frases que deberían cerrar la mitad de los debates sobre sitemaps:

• «Google ignora los valores <priority> y <changefreq>.» Los dos campos que medio sector sigue rellenando con esmero no los mira nadie. Poner changefreq: daily no hace que le visiten a diario.
• «Google usa el valor <lastmod> si es coherente y verificable», por ejemplo comparándolo con la última modificación real de la página.

Esa segunda frase es la que explica por qué el truco no era necesario y por qué mentir tampoco funciona: Google contrasta la fecha que usted declara con lo que encuentra en la página. Si su sitemap dice que todo cambió hoy y el contenido es idéntico al de hace un mes, el campo deja de ser fiable y pierde su valor.

La propia documentación precisa qué cuenta como cambio: una actualización del contenido principal, de los datos estructurados o de los enlaces de la página es significativa; actualizar el año del aviso de copyright no lo es.

Lo que hacemos aquí, medido

En MarketingHoy tenemos el problema justo al que apunta esa técnica, así que en lugar de teorizar contamos lo que medimos.

Nuestros sitemaps solo se descargan cuando los reenviamos. Lo comprobamos a diario con la API de Search Console, y el patrón se repite: el fichero puede pasar horas sin que nadie lo pida, y en cuanto se envía, Google lo descarga en el mismo segundo.

Dos lecturas reales de anoche, tomadas antes y después de reenviar:

• Antes: última descarga del sitemap.xml a las 15:20, con 4.008 URLs.
• Reenviado a las 01:53:13 → descargado a las 01:53:14, ya con 4.010.
• El news-sitemap, lo mismo: enviado a las 01:53:10, descargado a las 01:53:11.

Un segundo de diferencia, las dos veces. Ese es el mecanismo que sí responde, y no requiere ensuciar ninguna URL.

Tiene además una consecuencia operativa que conviene entender si publica varias veces al día: si solo reenvía por la mañana, todo lo que publique después no se lee hasta el día siguiente. En un sitemap de noticias, que solo cubre 48 horas, una pieza puede caducar dentro del propio fichero antes de que Google llegue a mirarlo.

Qué hacer, entonces

• Ponga lastmod y que sea verdad. Es el único campo del sitemap que Google declara usar, y solo mientras resulte creíble.
• Deje de mantener priority y changefreq. Están documentados como ignorados. El tiempo que dedique a afinarlos es tiempo perdido.
• Reenvíe el sitemap cuando publique, no una vez al día por costumbre. Si publica en varios tramos, reenvíe al cierre.
• Compruebe la fecha de descarga, no la de envío. Son campos distintos, y solo el segundo demuestra que alguien lo leyó.
• No toque las URLs. Ni parámetros de versión, ni marcas de tiempo, ni nada que las haga cambiar. Es lo que Google desaconseja y lo que le romperá la medición.

Preguntas frecuentes

¿Sirve de algo changefreq: always? No. La documentación de Google dice literalmente que ignora ese valor y también priority.

¿Puedo poner la fecha de hoy en todas las URLs para que las rastreen? Puede, pero se vuelve en su contra: Google comprueba si el lastmod es coherente con la página. Un campo que siempre miente deja de servir para las veces que sí importa.

¿Cada cuánto conviene reenviar el sitemap? Cuando haya contenido nuevo que merezca rastreo. Reenviar sin novedades no aporta; publicar y no reenviar sí resta.

¿El news-sitemap vacío es un error? No, si no ha publicado en 48 horas. Ese fichero solo cubre esa ventana por diseño.

Foto de portada: «Salle des catalogues de la Bibliothèque Mazarine, Paris», de Marie-Lan Nguyen, bajo licencia CC BY 2.0 fr. Fuentes: documentación de Google Search Central sobre sitemaps, consultada el 3 de septiembre de 2026, y Search Engine Journal, 2 de septiembre de 2026, de donde proceden las declaraciones de John Mueller. La traducción de las citas es nuestra. Las mediciones de descarga proceden de la cuenta de Search Console de MarketingHoy.

Para seguir el hilo: los informes de IA de Search Console · el hueco de datos que dejó GA4 y cómo lo comprobamos · la presión europea sobre los datos de búsqueda de Google.