XML Sitemap Dynamisch Bijwerken

[egonolieux]

Ik weet niet goed of dit best bij programming of internet marketing hoort, maar aangezien dit eerder een implementatievraag is, gok ik op programming.

Ik heb een aantal vragen over wat de beste strategie is bij het genereren en bijwerken van een XML sitemap op een dynamische site. Met een dynamische site bedoel ik dat er frequent items (urls) toegevoegd en verwijderd worden.

Stel dat ik een URL aan de sitemap wil toevoegen. De meest naieve manier van werken lijkt me de sitemap geheel opnieuw genereren (vanuit een database bvb, al dan niet op een bepaald tijdsinterval). Dit heeft als voordeel dat eventuele verwijderde URLs ook uit de sitemap verwijderd worden. Deze manier van werken is echter niet efficiënt als je een groot aantal pagina's hebt.

Een ander probleem is de file modified date van de sitemap(s). Stel dat een sitemap in 10 delen is opgesplitst (gepagineerd), dan is het niet gewenst dat de file modified date telkens gereset wordt naar de datum van het opnieuw genereren. Deze file modified date is belangrijk voor het genereren van de sitemap index (lastmod).

Een betere manier lijkt me de nieuwe URLs gewoonweg toevoegen aan de bestaande sitemap. Op die manier blijven de file modified dates intact. Het grootste probleem bij deze aanpak lijkt me het verwijderen van specifieke URLs. De gehele sitemap zou dan afgelopen moeten worden wat niet echt efficiënt is.

Als ik naar bestaande libraries kijk om sitemaps te genereren (PHP), lijkt geen enkele het toevoegen van URLs te ondersteunen; enkel opnieuw genereren. Moest ik zelf een systeem programmeren die wel URLs kan toevoegen zodat de timestamps intact blijven, kan het dan kwaad dat ik verwijderde URLs in de sitemap laat zitten? Geeft google mij een penalty bij 404s in de sitemap? Hoe doen andere grote dynamische sites (zoals Tweakers) dit?

[johnkeates]

Maakt toch niks uit qua timestamps? Gewoon een compleet nieuwe genereren, dat is hoe het bedoeld is.

[egonolieux]

johnkeates schreef op maandag 9 oktober 2017 @ 02:18:
Maakt toch niks uit qua timestamps? Gewoon een compleet nieuwe genereren, dat is hoe het bedoeld is.

De file timestamps zelf niet nee, maar hoe bepaal je dan de lastmod timestamps voor de sitemap index?

Stel dat ik 10000 items heb, verdeeld over 10 sitemap bestanden (gepagineerd). Als er een pagina verwijderd wordt die oorspronkelijk in bestand 1 zat, dan zal de nieuwe index lastmod van elk sitemap bestand overeenkomen met de nieuwe datum van het opnieuw genereren aangezien alle sitemap files effectief veranderd zijn omdat de URLs doorgeschoven zijn.

Indien er een pagina verwijderd wordt die oorspronkelijk in bestand 5 zat, dan moet de lastmod van bestanden 1-4 onveranderd blijven aangezien er niets aan hun inhoud veranderd is. De meest voor de hand liggende manier is dus de file modified date gebruiken als lastmod. Als alle sitemap bestanden opnieuw gegenereerd worden, dan ben je deze datum dus kwijt.

[Caelorum]

Waarom is het belangrijk voor je dat de lastmod van de bestanden niet verandert? (nog afgezien van dat je die zelf kan zetten).

[johnkeates]

dan moet de lastmod van bestanden 1-4 onveranderd blijven aangezien er niets aan hun inhoud veranderd is

Of je zet de lastmod gewoon op de datum van het genereren van de sitemap en dan werkt het net zo goed?
Stel dat je heel graag de modificatiedatum van de resource waar de sitemap naar linkt wil gebruiken, dan doe je dat? Ik snap het probleem hier niet zo

Zo'n XML bestand poep je in minder dan een seconde uit, ook als je 100k pagina's hebt.

[Barryvdh]

egonolieux schreef op maandag 9 oktober 2017 @ 02:54:
[...]


De file timestamps zelf niet nee, maar hoe bepaal je dan de lastmod timestamps voor de sitemap index?

Stel dat ik 10000 items heb, verdeeld over 10 sitemap bestanden (gepagineerd). Als er een pagina verwijderd wordt die oorspronkelijk in bestand 1 zat, dan zal de nieuwe index lastmod van elk sitemap bestand overeenkomen met de nieuwe datum van het opnieuw genereren aangezien alle sitemap files effectief veranderd zijn omdat de URLs doorgeschoven zijn.

Indien er een pagina verwijderd wordt die oorspronkelijk in bestand 5 zat, dan moet de lastmod van bestanden 1-4 onveranderd blijven aangezien er niets aan hun inhoud veranderd is. De meest voor de hand liggende manier is dus de file modified date gebruiken als lastmod. Als alle sitemap bestanden opnieuw gegenereerd worden, dan ben je deze datum dus kwijt.

Je bedoelt dat je nu de lastmod insteld op basis van genereren? Kan je niet gewoon echt zien wat er gewijzigd is? Ik weet niet hoe je de pagina's genereert, maar in een mysql database kan je ook bijhouden wat de laatste wijziging is en dat gebruiken in je sitemap..

[egonolieux]

Barryvdh schreef op maandag 9 oktober 2017 @ 08:46:
[...]


Je bedoelt dat je nu de lastmod insteld op basis van genereren? Kan je niet gewoon echt zien wat er gewijzigd is? Ik weet niet hoe je de pagina's genereert, maar in een mysql database kan je ook bijhouden wat de laatste wijziging is en dat gebruiken in je sitemap..

Voor het genereren van de sitemaps zelf gebruik ik inderdaad timestamps vanuit de database wanneer de resource in kwestie aangemaakt is. Stel dat je een aparte sitemap hebt voor producten, dan kan je inderdaad ergens in de database een timestamp bijhouden als lastmod en die updaten telkens als er een product toegevoegd of verwijderd wordt.

Mijn verwarring/probleem zit hem bij het opsplitsen van eenzelfde (logische) sitemap in meerdere (fysieke) sitemaps; paginering dus. Ik ga er vanuit dat elk sitemap bestand in de index zijn eigen lastmod date moet hebben volgens de officiele sitemap specificatie (lastmod is datum waarop bestand laatst veranderd werd).

Ik zie niet in hoe je die datum per bestand op een voor de hand liggende manier kan achterhalen (tenzij rechtstreeks de file modified timestamps te gebruiken). Als je een een product verwijdert weet je nooit echt welke specifieke sitemap file binnen de gepagineerde reeks "de verandering zal opvangen". Misschien van elke sitemap file een hash van de inhoud en datum bijhouden en bij het opnieuw genereren de hashes vergelijken?

[Verwijderd]

Ik zie het probleem niet - lastmod voor de sitemap zelf is sowieso optional, en op het moment dat je hem opnieuw genereert, op welke manier dan ook, is 'nu' de terechte datum ervoor.

[ Voor 3% gewijzigd door Verwijderd op 09-10-2017 16:00 ]

[egonolieux]

Verwijderd schreef op maandag 9 oktober 2017 @ 16:00:
Ik zie het probleem niet - lastmod voor de sitemap zelf is sowieso optional, en op het moment dat je hem opnieuw genereert, op welke manier dan ook, is 'nu' de terechte datum ervoor.

Het is optioneel ja, maar mijn punt is ALS ik het gebruik.

Dat de nieuwe datum de datum van het opnieuw genereren is, klopt niet volgens de specificatie:

Identifies the time that the corresponding Sitemap file was modified. It does not correspond to the time that any of the pages listed in that Sitemap were changed. The value for the lastmod tag should be in W3C Datetime format.

Als je de sitemap opnieuw genereer en er is niets veranderd, dan moet de lastmod datum onveranderd blijven, ook al komt dit niet overeen met de timestamp van het bestand zelf.

[Verwijderd]

Is wel een beetje multi-interpretabel, maar goed. Is het dan geen optie de sitemapindex eerst in te lezen en de datums daaruit te gebruiken?

[Caelorum]

egonolieux schreef op maandag 9 oktober 2017 @ 15:38:
[...]
Misschien van elke sitemap file een hash van de inhoud en datum bijhouden en bij het opnieuw genereren de hashes vergelijken?

Of je genereert gewoon een nieuwe, vergelijkt de inhoud met de bestaande (via hash of whatever) en als die verschilt sla je em op en anders niet.

[egonolieux]

Verwijderd schreef op maandag 9 oktober 2017 @ 16:14:
Is wel een beetje multi-interpretabel, maar goed. Is het dan geen optie de sitemapindex eerst in te lezen en de datums daaruit te gebruiken?

Ja, maar dat werkt enkel als je minder dan 50000 URls hebt.

De max limiet volgens de spec is 50000 URLs per sitemap file, dus zolang je daar onder zit is er eigenlijk geen probleem. Je kan gewoonweg een flag in de database op true te zetten vanaf er bvb een de URL van een product toegevoegd, veranderd of verwijderd wordt. Als deze flag op false staat bij het opnieuw genereren, kan je zoals je zei gewoonweg de datum hergebruiken.

Stel dat je meer dan 50000 product URLs hebt, dan ben je verplicht volgens de specificatie de sitemap in meerdere bestanden op te splitsen. Stel dat je 125000 URLs hebt, dan heb je in totaal 3 sitemap bestanden van 2x 50000 en 1x 25000 URLs.

Als je een product toevoegt, wijzigt of verwijdert, dan kan je dus niet betrouwbaar weten in welk van de 3 bestanden de verandering heeft plaatsgevonden. Het kan dus goed zijn dat bestand 1 en 2 onveranderd blijven, en dat de wijzigingen enkel in bestand 3 gebeurd zijn.

Caelorum schreef op maandag 9 oktober 2017 @ 16:28:
[...]

Of je genereert gewoon een nieuwe, vergelijkt de inhoud met de bestaande (via hash of whatever) en als die verschilt sla je em op en anders niet.

Klopt, minder omslachtig

Maar goed, het lijkt er dus op dat ik na mijn probleem te hebben zitten uittypen mijn eigen vraag reeds beantwoord heb: hashes vergelijken.

[Voutloos]

Als je je sitemap gaat micro-managen is je product wel heel erg definitief af, of kan je je tijd waarschijnlijk beter besteden. En it producten zijn eigenlijk nooit af dus...

Output gewoon wat je wil hebben in een voor jouw systeem makkelijke volgorde in je sitemap bestand(en). Als er wat verdwijnt en de sitemap was de enige bron komt de spider er uiteindelijk niet meer langs, en anders heb je alsnog correct je 301/302/404 voor die oude url.

Tijdstip van de xml bestanden zelf: Lekker boeiend. Dikke kans dat een spider alsnog enkel naar de content kijkt. Het zou mij niets verbazen als de tijd en complexiteit die je steekt in het o zo keurig correct krijgen van de xml lastmod verspilde moeite blijkt te zijn.

[Caelorum]

Wij genereren de sitemaps on-the-fly met de datum van het moment van genereren (van het request dus) en dat heeft nog nooit problemen veroorzaakt. De grote zoekmachines kijken er iig niet naar.

[egonolieux]

Voutloos schreef op maandag 9 oktober 2017 @ 20:49:
Als je je sitemap gaat micro-managen is je product wel heel erg definitief af, of kan je je tijd waarschijnlijk beter besteden. En it producten zijn eigenlijk nooit af dus...

Output gewoon wat je wil hebben in een voor jouw systeem makkelijke volgorde in je sitemap bestand(en). Als er wat verdwijnt en de sitemap was de enige bron komt de spider er uiteindelijk niet meer langs, en anders heb je alsnog correct je 301/302/404 voor die oude url.

Tijdstip van de xml bestanden zelf: Lekker boeiend. Dikke kans dat een spider alsnog enkel naar de content kijkt. Het zou mij niets verbazen als de tijd en complexiteit die je steekt in het o zo keurig correct krijgen van de xml lastmod verspilde moeite blijkt te zijn.

Nu ik weet wat ik moet doen om de lastmod correct te krijgen, ben ik ook niet direct van plan dit te gaan doen. Mijn oorspronkelijke gedachte was "nu ik toch bezig ben mijn sitemap generator te schrijven, kan ik evengoed voor 5 min. werk ook de optionele velden ondersteunen". En toen kwamen een aantal conceptuele vragen naar boven die ik niet direct kon beantwoorden. Maar zoals je zelf zegt, ik heb wel betere dingen te doen .