En el sitemap principal, la fecha lastmod de los sitemaps subyacentes es incorrecta:
Por ejemplo, mira https://meta.discourse.org/sitemap.xml
Las fechas de sitemap_2.xml a sitemap_5.xml son todas las mismas ‘2024-03-14T14:02:32Z’, que es exactamente ‘hace 3 días’.
Me preocupa que una optimización aquí complique enormemente las cosas para muy poco beneficio.
Piénsalo…
Digamos que hay 6 fragmentos en meta. Si se toca un tema del último fragmento… todo el fragmento se vuelve inválido, tienes que quitar el tema de allí y ponerlo en el fragmento frontal.
Optimizar aquí es un poco inútil para un sitio que ve algún tipo de actividad y las fechas dentro del fragmento en los temas reales están bien.
No se trata de mover temas a diferentes fragmentos de sitemap. Los temas pueden permanecer en el mismo fragmento de sitemap en el que ya se encuentran.
(El mapeo tema-a-fragmento-de-sitemap es arbitrario de todos modos, ya que la declaración select de la base de datos con limit no tiene order definido.)
El informe de error trata sobre que la fecha lastmod de cada fragmento de sitemap debe representar la fecha lastmod del tema más reciente que contiene el fragmento de sitemap.
El camino para Google debería ser:
Cargar sitemap.xml
→ Comprobar lastmod de los fragmentos de sitemap y poner en cola los fragmentos de sitemap que necesitan una actualización
(la fecha lastmod es más reciente que la última vez que se descargó)
Cargar los fragmentos de sitemap en cola sitemap_[1-5].xml
→ Comprobar lastmod de las URLs de los temas y poner en cola las URLs de los temas que necesitan una actualización
(la fecha lastmod es más reciente que la última vez que se descargó)
Cargar las URLs de los temas en cola.
Si en sitemap.xml el lastmod de los fragmentos de sitemap es incorrecto:
→ Google no pone en cola los fragmentos de sitemap modificados (paso 1)
→ Google no actualiza los fragmentos de sitemap modificados de manera oportuna (paso 2)
→ Google no actualiza los temas modificados de manera oportuna (paso 3)
Nuevamente, esto no es estrictamente cierto… last_mod está destinado a ser la última fecha en que se modificó el sitemap, no la fecha máxima de los temas.
Si un tema salió de la sección del sitemap hoy y la última modificación en el fragmento fue hace una semana… el fragmento cambió hoy. Un tema salió de él hoy.
Entonces, la misma lógica resulta en:
Si un tema en la sección del mapa del sitio cambió hoy y la última modificación en el fragmento es hoy… el fragmento cambió hoy [nota: no hace 3 días]. Un tema en él cambió hoy.
Para tu y mi ejemplo anterior, la implementación actual dice:
fragmentos del mapa del sitio sitemap_[2-5].xml cambiaron hace 3 días. Esto es incorrecto. Debería decir ‘cambió hoy’.
Aquí está el panorama general detrás de todo esto:
sitemap_recent.xml:
Solo incluye todos los temas cambiados de los últimos 3 días
Se renueva cada 1 hora (tiempo de caché interno de Rails de 1 hora)
Tiene la fecha lastmod correcta en sitemap.xml
sitemap_[1-5].xml:
Realmente incluye todos y cada uno de los temas, y también incluye todos los temas cambiados de los últimos 3 días
Se renueva cada 24 horas (tiempo de caché interno de Rails de 24 horas)
sitemap_[2-5].xml tienen la fecha lastmod incorrecta de 3.days.ago en sitemap.xml
La fecha lastmod incorrecta para sitemap_[2-5].xml no importa, ya que Google obtendrá todos los cambios recientes de temas a través de sitemap_recent.xml de manera oportuna.