<lastmod> in die /sitemap.xml integrieren

[thomasr]

Hallo
Wie kann ich in Contao 4.13.29 den Lastmode in die /sitemap.xml integrieren?
Habe folgendes probiert:
Im config-Ordner habe ich eine neue Datei «config-rout.yaml» angelegt mit:

contao_sitemap:
    path: /sitemap.xml
    defaults:
        _controller: contao.sitemap_xml
        _format: xml
        _type: default
        _addLastmod: true

Leider funktioniert das nicht.
Gibt es eina andere Möglichkeit?

[Spooky]

Du meinst du willst für jeden Sitemap Eintrag <lastmod> hinzufügen? Dazu müsstest du dir überlegen, wie du diesen Wert ermittelst und diesen dann via contao.sitemap Event hinzufügen.

[thomasr]

Ja, Google bevorzugt Sitemaps mit lastmod, um Änderungen schneller zu erkennen.

[neelix]

Dann sollte das vllt. Standard werden und direkt im Core enthalten sein.

[Spooky]

Dann sollte das vllt. Standard werden und direkt im Core enthalten sein.

Pull Requests welcome, ist aber keine leichte Aufgabe, denke ich.

[thomasr]

Das müsste ja dann ungefähr so aussehen?

<url>
   <loc>https://www.domain/</loc>
   <lastmod>2024-03-04</lastmod>
</url>

[tab]

Pull Requests welcome, ist aber keine leichte Aufgabe, denke ich.

Zumindest für die Erkennung von Änderungen an einer Seite sollte aber eigentlich schon Code vorhanden sein, eigentlich damit auch ein Timestamp für die letzte Änderung. Ich denke da an den Cache von Yanick. Der erkennt das ja auch.

[Spooky]

Zumindest für die Erkennung von Änderungen an einer Seite sollte aber eigentlich schon Code vorhanden sein, eigentlich damit auch ein Timestamp für die letzte Änderung.

Gibt es aktuell nicht, nein.

[tab]

Das wäre aber jedenfalls m.E. eine sinnvolle Herangehensweise dafür. Bei einer Änderung im Backend wird ja derzeit schon erkannt, welche Seiten im Cache nach dieser Änderung als nicht mehr valide/aktuell zu markieren sind und man könnte für die entsprechenden Seiten da gleich einen Timestamp für die letzte Änderung setzen. Für die "normalen" Seiten in der tl_page dürfte das jedenfalls kein schwieriges Problem sein, bräuchte man halt eine zusätzliche Spalte in der tl_page dafür.

Schwieriger wird es wohl mit Nachrichten, Events & Co sein, weil es da nur eine Leserseite für viele Nachrichten gibt. Die Erkennung einer Änderung an so einer Detailseite dürfte für den Public Cache wohl auch schon implementiert sein, oder kommen die derzeit gar nicht in den Public Cache? Aber natürlich müsste der Timestamp auch irgendwo gespeichert werden. In der Leserseite reicht das dann natürlich nicht. In dem Fall müsste der Timestamp dann eher bei den jeweils betroffenen Nachrichten/Events etc selbst gespeichert werden.

Bleibt aber wohl das leidige Problem mit geschützten Seiten und Seiten mit geschützten Inhalten. Die sind nicht im Cache und werden somit auch nicht im Cache als invalide markiert. Wenn die ganze Seite geschützt ist, wird sie wohl aber auch nicht in die Sitemap für Google aufgenommen werden. Spannend bleibt es bei Seiten, die nur einige geschützte Inhalte haben, aber prinzipiell öffentlich zugänglich sind. Bei solchen Seiten könnte man notfalls in der Sitemap auf die Angabe der letzten Änderung verzichten. Oder kann man das nur entweder für alle Seiten oder für gar keine angeben?

So ganz trivial wird das also jedenfalls tatsächlich nicht

[Spooky]

Das wäre aber jedenfalls m.E. eine sinnvolle Herangehensweise dafür. Bei einer Änderung im Backend wird ja derzeit schon erkannt, welche Seiten im Cache nach dieser Änderung als nicht mehr valide/aktuell zu markieren sind und man könnte für die entsprechenden Seiten da gleich einen Timestamp für die letzte Änderung setzen.

Der Cache ist völlig unabhängig davon. Also die Applikation weiß ja "nichts" vom Cache.

[tab]

Der Cache ist völlig unabhängig davon. Also die Applikation weiß ja "nichts" vom Cache.

Hmm, ich fürchte, du hast mal wieder recht. Contao invalidiert keine Seiten, sondern nur Cache-Tags, aus denen der Cache dann erkennt, welche Seiten er nicht mehr direkt ausliefern darf. Der relevante Code sitzt also wohl im Cache. Damit dürfte diese Info für Contao nicht nutzbar sein.

[neelix]

Aber sie teilt dem Cache doch mit, wenn Inhalte ungültig geworden sind und verworfen werden sollen. So hatte ich das von der Vorstellung der Funktion in Erinnerung. (INVALIDATE)

[Spooky]

Genau. Aber wie ist nun die Idee diesen Mechanismus für <lastmod> einer URL der Sitemap zu verwenden?

[neelix]

Wie "merkt" Contao denn, dass ein Inhalt "abgelaufen" ist und der Cache sich eine neue Version holen muss?

[Spooky]

Wie "merkt" Contao denn, dass ein Inhalt "abgelaufen" ist und der Cache sich eine neue Version holen muss?

Beim speichern im Backend werden die Cache Tags invalidated. Also DataContainer::invalidateCacheTags() wird an verschiedenen Stellen im DC_Table aufgerufen. Der fos_http_cache.cache_manager sendet das dann an den Reverse Proxy.

[Spooky]

Bei einem Kunden haben wir mal diese poor man's Lösung gebaut, basierend auf dem tstamp des Suchindex von Contao - welcher sich im Normalfall nur aktualisiert, wenn sich etwas auf der Seite ändert.

Akurat ist das natürlich nicht - und es erfordert eine Art von regelmäßiger Ausführung von contao:crawl --max-depth=3 --subscribers=search-index.

[mlweb]

Ich denke aber, dass man auch genau nachdenken sollte, ob man das wirklich benötigt.

Ich hab es mir vorhin durchgelesen bei Google und habe die unmaßgebliche Meinung, dass das vor allem ein Rolle bei Seiten spielt deren Inhalt häufig aktualisiert wird und bei denen auf Grund des verfügbaren Crawlvolumens unter Umständen nicht alle "Neuerungen" bei Google im Index landen würden.

[Spooky]

Genau, ja. Und nur um das nochmal klarzustellen: es bringt nur etwas, wenn sich der Inhalt von bestehenden Seiten ständig ändert. Wenn man bspw. sehr oft neue Nachrichten veröffentlicht, spielt das keine Rolle - auch nicht für die Seite mit der Nachrichtenliste bspw.