Indexed Search und News-Datensätze - Index-Aktualisierung und doppelte Einträge

Lars Brinkmann

Hallo zusammen,

Ich stehe gerade vor einer kleinen Herausforderung und suche nach einer praktikablen Lösung. Es geht hier um eine TYPO3 12 Seite mit der Extension News und Indexed Search. Vielleicht habt ihr ja ein paar erhellende Ideen?

Die Seitenstruktur ist dabei wie folgt:

+ **Beiträge**
+++ **Aktuelle Beiträge** (zeigt die Listenansicht aktueller Beiträge)
      Url: domain.de/beitraege/aktuelle-beitraege/
+++++ Einzelansicht aktuelle Beiträge (zeigt die Detailansicht eines aktuellen Beitrags)
	    Url: domain.de/beitraege/aktuelle-beitraege/einzelansicht-aktuelle-beitraege/titel-des-beitrags/ 
+++ **Archivierte Beiträge** (zeigt die Listenansicht der archivierten Beiträge / Archivdatum) 		
        Url: domain.de/beitraege/aktuelle-beitarge/
+++++ Einzelansicht archivierte Beiträge (zeigt die Detailansicht eines archivierten Beitrags)
	    Url: domain.de/beitraege/aktuelle-beitarge/einzelansicht-archivierte-beitraege/titel-des-beitrags/

Die Struktur steckt sowohl in einem Rootline-Menü (domain > Beiträge > Aktuelle Beiträge > Einzelansicht) als auch in einem Untermenü (Aktuelle Beiträge / Archivierte Beiträge). Zudem befindet sich eine entsprechende einleitende Überschrift oberhalb des Plugins auf der Einzelansicht (Aktueller Beitrag / Archivierter Beitrag).
An dieser - möglicherweise etwas ungewöhnlichen Konfiguration - kann ich nichts ändern. Das ist so die Vorgabe.

Die Extension Crawler ist bislang nicht installiert.

Wenn nun ein aktueller News-Beitrag aufgerufen wird, wird er auch im Suchindex mit dem Pfad »aktuelle-…« aufgenommen und kann darüber gefunden werden.

Ist bei diesem News-Beitrag das Archiv-Datum erreicht, erscheint der Beitrag in der Liste der archivierten Beiträge. Wird er von dort aufgerufen, erscheint er mit dem Pfad »archivierte-…« im Suchindex.

Wenn ich nun nach diesem Beitrag suche, finde ich zwei Beiträge: 1x über »aktuelle« und 1x über »archivierte« Beiträge. Auch bei Google und co. wären beide URLs dann zu finden.

Welche kluge Lösung gibt es hierfür? Theoretisch müsste man ja sogar noch eine 301-Weiterleitung von aktuell nach archivierte anlegen, damit es bei den Suchmaschinen korrekt indexiert wird. Und auch in meiner internen Suche möchte ich zum einen erreichen, dass alle Beiträge, egal ob aktuell oder archiviert, über die Suche gefunden werden können, aber eben auch nur einmal in den Suchergebnissen erscheinen.

Und wenn eine News mal völlig »verschwinden« soll, zum Beispiel weil gelöscht oder ein Enddatum für die Veröffentlichung gesetzt wurde, dann müsste diese ja komplett aus dem Index verschwinden?!?

Viele Grüße, Lars

Mogens Fiebrandt

Vielleicht schaust Du Dir mal EXT:ke_search an. Dort werden Inhalte nicht durch Aufruf der Seiten indexiert, sondern über einen Indexer. Für eigene Datensätze muss man selbst Indexer schreiben. Aber für News wird einer mitgeliefert. Das sollte Dein Problem für die Suche auf der Website schon einmal lösen können.
Wenn Du unbedingt bei indexed_search bleiben willst, dann musst Du Dir sicherlich auch etwas bauen, dass den Index löscht und neu crawlt. Crawler-Extension hast Du ja schon genannt.

Die Indexierung bei Google kannst Du über die Sitemap steuern. Hier ist die Konfiguration der EXT:seo für die Sitemap von Seiten:
https://github.com/TYPO3/typo3/blob/b3934a278a347b9696966443a89ff04c102e6ec4/typo3/sysext/seo/Configuration/TypoScript/XmlSitemap/setup.typoscript#L39

Die EXT:news liefert aber auch eine Konfiguration für die EXT:seo von News Beiträgen:
https://github.com/georgringer/news/blob/ec9ed45557ae4de004d2954c0473981048697dda/Configuration/TypoScript/SeoSitemap/setup.typoscript#L5

Damit müsstest Du eigentlich eine saubere Sitemap hinbekommen.

Lars Brinkmann

Hallo Mogens, vielen Dank für Deinen Input.
Die ke_search habe ich als gedanklichen Backup. Ich muss das mit dem Kunden noch durch diskutieren. Weißt Du, wie dieser mit aktuellen / archivierten News genau umgeht?

Letzendlich würde ich eher auf bestehende Komponenten aufbauen und nicht unbedingt selber etwas basteln (was dann wieder für ke_search spricht).

Die Sitemap habe ich bereits angelegt (Pages). Für die News muss ich dann ja zwei verschiedene Varianten bauen, einmal Aktuell, einmal Archiv. Müsste ja eigentlich so funktionieren, wenn ich die Doku richtig interpretiere.

config { xmlSitemap { sitemaps { news-aktuell { provider = GeorgRinger\News\Seo\NewsXmlSitemapDataProvider config { ...} news-archiv { provider = GeorgRinger\News\Seo\NewsXmlSitemapDataProvider config { ...}

Aber würde das für Google reichen? Immerhin wird ein News-Beitrag ja dann von Aktuell nach Archiv verschoben und ist dann unter Aktuell (offiziell) nicht mehr verfügbar, bzw. der Link kann ja immer noch aufgerufen werden, nur in der Sitemap und in der Listenansicht ist dieser dann nicht mehr sichtbar.

Theoretisch müsste man doch wirklich eine 301-Weiterleitung setzen, wenn das Archivdatum erreicht ist und die Anfrage auf die archivierte Variante schicken. Im Moment kann ich mir jedoch nicht vorstellen, dass ich dies auch in der Praxis umsetzen möchte ;-)

Viele Grüße, Lars

Mogens Fiebrandt

Tut mir leid. Ich weiß leider nicht genau wie ke_search mit den archivierten News umgeht. Das müsstest Du mal testen.

Ob Du für die Sitemap 2 Configs brauchst, kann ich Dir leider auch nicht sagen. Müsstest Du auch testen. :-)

Eigentlich sollte das für Google reichen, wenn Du eine saubere Sitemap hast. Aber da Google ja immer etwas eine Blackbox ist, kann ich das leider auch nicht genau sagen.

Vielleicht weiß ja noch jemand anderes etwas mehr.

Lars Brinkmann

Mogens Fiebrandt Alles klar. Im Code vom News-Indexer der ke_search stehen zumindest Optionen für aktuelle und archivierte News. Da scheint was zu gehen ;-)
Alles andere werde ich erst einmal testen und dann soll der Kunde entscheiden, womit er leben kann und womit nicht. Vielen Dank für Deinen Input.

Lars Brinkmann

Kleine Aktualisierung. Ich für die News-Datensätze zwei Sitemaps erstellt: eine, die nur die aktuellen Datensätze enthält und eine für archivierte Datensätze. Hier ist der Code dazu:

plugin.tx_seo {
    config {
        xmlSitemap {
            sitemaps {
                pages {
                    config {
                        excludedDoktypes = 3, 4, 6, 7, 199, 254, 255
                        additionalWhere = AND no_index = 0
                    }
                }
                news {
                    provider = GeorgRinger\News\Seo\NewsXmlSitemapDataProvider
                    config {
                        excludedTypes = 1,2
                        additionalWhere = archive = 0 OR archive > UNIX_TIMESTAMP()
                        sortField = datetime
                        lastModifiedField = tstamp
                        pid = 3
                        url {
                            pageId = 54
                            fieldToParameterMap {
                                uid = tx_news_pi1[news]
                            }
                            additionalGetParameters {
                                tx_news_pi1.controller = News
                                tx_news_pi1.action = detail
                            }
                        }
                    }
                }
                archive {
                    provider = GeorgRinger\News\Seo\NewsXmlSitemapDataProvider
                    config {
                        excludedTypes = 1,2
                        additionalWhere = archive > 0 AND archive <= UNIX_TIMESTAMP()
                        sortField = datetime
                        lastModifiedField = tstamp
                        pid = 3
                        url {
                            pageId = 575
                            fieldToParameterMap {
                                uid = tx_news_pi1[news]
                            }
                            additionalGetParameters {
                                tx_news_pi1.controller = News
                                tx_news_pi1.action = detail
                            }
                        }
                    }
                }
            }
        }
    }
}

Nun muss ich nur noch eine Lösung suchen, wie ich News-Datensätze möglichst elegant aus dem Suchindex löschen kann. Nur den entsprechenden Eintrag aus der Tabelle index_phash wird ja vermutlich nicht reichen, da (mindestens) in den Tabellen *fulltext, *grlist, *rel und *section Verknüpfungen zum jeweiligen phash angelegt sind.

Im Backend kann ich mit dem Modul "Indizierung" auf der Seite "Einzelansicht aktuelle Beiträge" immer nur 10 Einträge auf einmal löschen. Und das auch nur manuell. Das ist schon etwas umständlich.

Mogens Fiebrandt

Bei Google gab es bis Mitte 2023 die Möglichkeit einen Ping zu senden mit der URL der Sitemap, damit diese neu gecrawled wird.
Geht dort leider nicht mehr. Hier ein wenig mehr Info dazu:
https://developers.google.com/search/blog/2023/06/sitemaps-lastmod-ping?hl=de

Ob andere Suchanbieter das noch anbieten weiß ich nicht. Wäre aber mal eine Recherche wert.
Es gibt da ja noch mehr Anbieter als Dr. Google 😉

Für das Problem mit der Suche, würde ich auf jeden Fall die ke_search testen, bevor Du Dir tausend Gedanken machst, wie Du den Index der indexed_search wieder gelöscht bekommst. Die Extension ist wirklich leicht aufgesetzt. Und meiner Meinung nach ein must-have, wenn man mehr als nur Inhaltsseiten anbietet.

Lars Brinkmann

Mogens Fiebrandt Danke für den Input.
Ich habe die ke_search hier testweise zunächst nur für die Pages installiert und konfiguriert. Das Grundprinzip gefällt mir schon mal viel besser. Das Problem bei diesem Projekt ist jedoch, dass manche Inhalte nicht in der Datenbank stehen, sondern durch Programmierung der Seite hinzugefügt werden. So wird zum Beispiel die H1-Überschrift aus dem Seitentitel der übergeordneten Seite ausgelesen und ausgegeben (war nicht meine Idee....)

Ich werde mal schauen, ob ich dann hierfür nicht ein zusätzliches Feld nutze, um auch diesen Text zu indexieren. Das dürfte in der Summe einfacher sein, als bei der indexed_search nur die aktuellen News-Datensätze aus dem Index zu löschen.

Mogens Fiebrandt

Ein zusätzliches Feld ist natürlich etwas unschön, da Du dieses ja auf jeder Unterseite pflegen musst. Funktioniert natürlich. Aber wenn sich der Seitentitel einer übergeordneten Seite ändert, müsste man auch jede Unterseite anpassen. In kleineren Projekten ist dies sicherlich machbar. In Projekten mit mehreren Redakteuren eher nicht so gut.

Man könnte auch überlegen einen eigenen Indexer zu erstellen und diesen von dem Page-Indexer der ke_search abzuleiten.
Im Page-Indexer gibt es die Methode getPageRecords. Die müsste man eigentlich nur überschreiben und im QueryBuilder einen Join einbauen, um auch die Überschriften der übergeordneten Seiten zu laden.
Dann muss man das sicherlich auch als zusätzliches Feld ausgeben, aber man muss es nicht im Backend pflegen.
Hab ich so noch nie implementiert. Könnte aber funktionieren. Kommt auf einen Test an. 😉

Lars Brinkmann

Mogens Fiebrandt Da die entsprechenden Informationen in den Seiteneigenschaften (abstract, description und keywords) auch gepflegt sind, würde ich schauen, dass ich diese Felder noch in den Indexer mit rein bekomme. Gibt wohl auch einen Hook dafür, bislang ist es mir aber noch nicht gelungen.
Gibt auf GitHub sogar ein Feature-Request aus dem Mai, dass es einfacher möglich sein soll, diese Felder mit aufzunehmen.

Unterstütze das Forum

Hilf mit, den Community Hub für TYPO3 werbefrei zu halten und die Betriebskosten zu decken. Werde Official Community Hub Supporter für nur 5 Euro im Monat (zzgl. USt) und erhalte ein exklusives Supporter-Badge. Jeder Beitrag zählt!

Jetzt Supporter werden

Impressum - Datenschutz - Kontakt - Netiquette - RSS