Nella sitemap principale, la data lastmod per le sitemap sottostanti è errata:
Ad esempio, vedi https://meta.discourse.org/sitemap.xml
Le date per sitemap_2.xml fino a sitemap_5.xml sono tutte uguali ‘2024-03-14T14:02:32Z’ - che è esattamente ‘3 giorni fa’.
Temo che un’ottimizzazione qui complichi enormemente le cose per un beneficio molto esiguo.
Pensaci bene…
Diciamo che ci sono 6 blocchi su meta. Se viene toccato un argomento dall’ultimo blocco… l’intero blocco diventa non valido, devi rimuovere l’argomento da lì e metterlo nel blocco frontale.
Ottimizzare qui è un po’ inutile per un sito che vede un qualsiasi tipo di attività e le date all’interno del blocco sugli argomenti effettivi vanno bene.
Non si tratta di spostare argomenti in diversi sitemap-chunk. Gli argomenti possono rimanere nello stesso sitemap-chunk in cui si trovano già.
(La mappatura argomento-a-sitemap-chunk è comunque arbitraria poiché l’istruzione select del database con limit non ha order definito.)
Il bug report riguarda il fatto che la data lastmod di ogni sitemap-chunk dovrebbe rappresentare la data lastmod dell’argomento più recente contenuto nello sitemap-chunk.
Il modo per Google dovrebbe essere:
Carica sitemap.xml
→ Controlla lastmod degli sitemap-chunk e accoda gli sitemap-chunk che necessitano di un aggiornamento
(data lastmod più recente dell’ultima volta scaricata)
Carica gli sitemap-chunk accodati sitemap_[1-5].xml
→ Controlla lastmod degli URL degli argomenti e accoda gli URL degli argomenti che necessitano di un aggiornamento
(data lastmod più recente dell’ultima volta scaricata)
Carica gli URL degli argomenti accodati.
Se in sitemap.xml il lastmod degli sitemap-chunk è errato:
→ Google non accoda gli sitemap-chunk modificati (passaggio 1)
→ Google non aggiorna gli sitemap-chunk modificati in modo tempestivo (passaggio 2)
→ Google non aggiorna gli argomenti modificati in modo tempestivo (passaggio 3)
Di nuovo, questo non è strettamente vero… last_mod è inteso come l’ultima data in cui la sitemap è stata modificata, non la data massima degli argomenti.
Se un argomento è stato rimosso dalla sezione della sitemap oggi e l’ultima modifica nel chunk risale a una settimana fa… il chunk è cambiato oggi. Un argomento è stato rimosso da esso oggi.
Quindi la stessa identica logica porta a:
Se un argomento nella sezione della sitemap è cambiato oggi e l’ultima modifica nel blocco è di oggi… il blocco è cambiato oggi [nota: non 3 giorni fa]. Un argomento al suo interno è cambiato oggi.
Per il tuo e il mio esempio qui sopra, l’implementazione attuale dice:
i blocchi della sitemap sitemap_[2-5].xml sono cambiati 3 giorni fa. Questo è sbagliato. Dovrebbe dire ‘cambiati oggi’.
Include solo tutti gli argomenti modificati negli ultimi 3 giorni
Viene rinnovato ogni ora (tempo di cache interno di Rails di 1 ora)
Ha una data lastmod corretta in sitemap.xml
sitemap_[1-5].xml:
Include veramente tutti gli argomenti, e include anche tutti gli argomenti modificati negli ultimi 3 giorni
Viene rinnovato ogni 24 ore (tempo di cache interno di Rails di 24 ore)
sitemap_[2-5].xml ha una data lastmod errata di 3.days.ago in sitemap.xml
La data lastmod errata per sitemap_[2-5].xml non ha importanza, poiché Google otterrà tutte le modifiche recenti degli argomenti tramite sitemap_recent.xml in modo tempestivo.