Aufbau des Suchindexes seit Contao 4.9 mit MM 2.2 aufgrund vieler MMs, Filter und Seiten nicht möglich

[Shania567]

Checklist before I submit this issue report

I confirm that:

• I have tested this with the latest version available
• I have read documentation @ http://metamodels.readthedocs.org/en/ or http://metamodels.readthedocs.org/de/
• I have checked the Contao community forums for references https://community.contao.org/
• I have checked existing issues for duplicates and found none @ https://github.com/MetaModels/core/issues?q=is%3Aissue

My environment is:

Contao 4.13 & MM 2.3

Issue description

Ich möchte den Suchindex nach dem Upgrade von Contao 4.9 mit MM 2.2 auf Contao 4.13 mit MM 2.3 neu aufbauen.

Dazu bin ich in die Systemwartung gegangen, habe den bisherigen Index gelöscht und klicke auf "Suchindex neu aufbauen" und "Crawler starten".

Der Crawler läuft sich zu Tode bis er abbricht.

Bisherige Analaysen ergaben folgende Ursachen:

• Das Problem mit der fehlerhaften Paginierung erzeugt zahlreiche Links, die keine validen Seiten sind. Paginierung mit GET in Verbindung mit Filter #1493
• Der Crawler liest alle Seiten mit Detailseiten der MM-Liste (also ?page=2, ?page =3 usw.) und möchte jede Seite einzeln indizieren (das mag so korrekt sein)
• Der Crawler liest darüber hinaus alle Kombinationen aus jedem Merkmal eines Filters mit jeder Seite, so dass bei entsprechend zahlreichen Filtern und MMs zigtausende Seiten einzulesen sind. Zu viele für den Server auf dem meine Umgebung läuft (All-Inkl Paket Privat Plus)

Was würde ich mir wünschen?
Ich möchte nur die ersten Seite (seitenalias.html) mit der MM Liste und alle Detailseiten einzeln in den Suchindex aufnehmen. Leben könnte ich auch noch damit, dass die einzelnen Seiten der jeweiligen Liste (also seitenalias?page=2, ?page =3 usw.) mit aufgenommen wird.

Seiten, die durch Filter erzeugt werden, benötige ich nicht in der Suche (./seitenalias/filterausprägung1?page=2, ?page =3) usw. sollten man ausschließen können.

Es würde reichen, wenn all die Seiten im Suchindex wären, die auch in der Sitemap stehen.

Ziel soll sein, dass ich den Suchindex im Backend wieder aufbauen kann.

Zum Hintergrund:
Ich habe zahlreiche MMs auf meiner Seite. Das ist sicherlich der Grund dafür, dass das bei mir zum Problem wird.

10 MM sind auf der Seite zu sehen. Dazu gibt es diverse MMs für die Kriterien, nach denen später gefiltert werden kann. Insgesamt sind es 26 MM.

In der Summe habe ich in dem MMs ca. 1000 Datensätze (Detailseiten) und in den Tabellen für die späteren Filter befinden sich gut 950 Datensätze. Ein kleiner Teil davon ist noch nicht online.

So kann man sich sicherlich vorstellen, wie viele Seiten dadurch entstehen und warum die Laufzeiten dadurch so immens werden und der Job letztendlich abbricht. Ich habe daher versucht den Seitenindex mit nur einem der größten MMs aufzubauen, aber selbst das ist gescheitert bzw. habe ich es nach Stunden von mir aus abgebrochen.

Ich hoffe, das war verständlich beschrieben. Ansonsten gerne nochmal fragen.

[zonky2]

Es würde reichen, wenn all die Seiten im Suchindex wären, die auch in der Sitemap stehen.

Umgedreht! Alle Seiten, die in der sitemap.xml stehen, sollen in den Suchindex - so würde ich mir das vorstellen und das ist eigentlich auch das, was MM liefert: über die Indexierung werden alle Detaillinks der ausgewählten Liste in die sitemap.xml geschrieben und die eigentliche Listenseite automatisch raus genommen.

[zonky2]

... oder ein no-follow in die Filterwidgets, die URLs erzeugen - siehe #1468

[Shania567]

Die Listenseite wird derzeit nicht aus der sitemap.xml raus genommen und sollte es meiner Ansicht nach auch nicht. Es gibt ja mehrere Arten von Listen. Einmal die, wo die komplette Liste aller veröffentlichten Items zu sehen ist. Hier kann man sicherlich geteilter Ansicht sein, ob die in die sitemap und die Suche muss.

Es gibt aber auch Teilmengen der gesamten Liste, die auf bestimmten Seiten nochmals angezeigt werden. Hier wurde auf ein Merkmal eingeschränkt und vielleicht auch einen andere Listenansicht gewählt. Genau hier wird es ja auch erst spannend MM einzusetzen. Damit man nicht an zwei Seiten Änderungen vornehmen muss. Und diese Seiten sollten keinesfalls aus der sitemap ausgeschlossen werden, nur weil eine MM Liste auf der Seite ist.

Also in die sitemap und auch den Suchindex sollten meiner Ansicht nach:
meinedomain.de/seitenname.xml auf der die Liste angezeigt wird und
meinedomain.de/seitenname-detail/items/erfasstes-item.html

Ein nofollow in den Filterwidget führt derzeit nicht dazu, dass sie aus dem Suchindex ausgenommen werden. Zumindest werden sie ja dann auch noch gecrawlt und hier liegt ja das Problem bei hohen Seitenanzahl, die durch die Filter und Seiten der MMs erzeugt werden. Also alle ihre Kombinationsmöglichkeiten untereinander. Es würde nicht helfen, wenn all diese Kombinationen ins Log der nicht aufgenommenen Seiten geschrieben würden anstatt in den Suchindex.

Einziger derzeitiger Workaround ist es alle Filter auszublenden, dann den Suchindex wieder aufzubauen und dann alle Filter wieder sichtbar zu machen. Aber das ist ziemlich aufwändig bei mir und da der Aufbau des Suchindexes auch so eine Weile läuft, ist die Seite währenddessen nicht wirklich gut nutzbar. Ganz in den Wartungsmodus setzen, möchte ich sie aber auch nicht.

[zonky2]

Ein nofollow in den Filterwidget führt derzeit nicht dazu, dass sie aus dem Suchindex ausgenommen werden. Zumindest werden sie ja dann auch noch gecrawlt und hier liegt ja das Problem bei hohen Seitenanzahl, die durch die Filter und Seiten der MMs erzeugt werden.

Wenn das der Fall ist, wäre das m. E. ein Bug in Contao - siehe contao/contao#3925 (comment) - die Suche nach kaputten Links darf dabei aber nicht auch an sein - siehe contao/contao#3925 (comment)

[Shania567]

Ich habe heute nochmal ein paar Dinge getestet:

Templateanpassungen:
mm_filteritem_default.html5
mm_filteritem_linklist.html5
mm_filteritem_radiobuttons.html5
=> Hier habe ich jeweils ganz oben ein und ganz unten ein eingefügt.
Ergebnis: Die Links mit den verschiedenen Filtern auf der Hauptseite werden dennoch gecrawlt, nicht die, die rechts stehen allerdings nicht. Vielleicht wurden sie das vorher aber auch nicht, das kann ich jetzt nicht genau sagen.

mm_pagination.html5
=> Hier habe ich bei allen Links ein rel="nofollow" ergänzt wie wir es schon im letzten Jahr gemeinsam gemacht hatten @zonky2 und ein ganz oben und ganz unten ein . Hier wird nun tatsächlich nichts mehr indiziert.

Danach waren immer noch zahlreiche Links enthalten mit Seiten und auch mit Filtern. Mir ist dann bewusst geworden, dass es Links auf Seiten in die MMs gibt mit gesetzten Filtern, teilweise auch mit Seitenangaben 😯. Dann habe ich versucht diese nahezu alle mit einem rel="nofollow" zu versehen. Die Seitenangaben habe ich entfernt. Ob ich wirklich alle erwischt habe, sei mal dahin gestellt. Aber viele sind angepasst. Das ist natürlich einem Redakteur nicht zuzumuten, denn ein nofollow kann ich ja nicht über den Editor mitgeben. Das geht nur im Quelltext.

Dann gibt es ein MM, wo man im Header der Liste die Sortierung ändern kann. Hier wüsste ich gar nicht, wie ein rel="nofollow" ergänzen könnte. Ich habe auch hier die Kopfzeile in eingefasst.

Es gibt noch immer einige Seiten im Index, die auf Filter der MMs gehen, aber ich befürchte, das sind Links die ich auf den Seiten noch nicht gefunden habe. Denn diese ganzen Kombinationen verschiedener Filter sind weg. Vielleicht finde ich nach und nach noch weitere Links, denen ich ein rel="nofollow" verpassen kann.

Der Crawler bricht ab, wenn die Filter auf der Seite angezeigt werden. Ich konnte es jetzt auch nur übers Backend testen, da ich auf der Console eine Fehlermeldung wegen unterschiedlicher php Versionen bekomme. Wenn ich die Filter in #main ausblende, dann läuft es durch und dann sind auch alle Seiten im in der Suche, die da meiner Ansicht nach sein sollten und einige wenige mehr.

[zonky2]

Hallo @Shania567

was meinst du mit

=> Hier habe ich jeweils ganz oben ein und ganz unten ein eingefügt.

?

Das rel="nofollow" ist eine Angabe für den <a>-Tag und muss als Attribut dort eingetragen werden - siehe https://developers.google.com/search/docs/crawling-indexing/qualify-outbound-links?hl=de#nofollow

Beim Filter sollte das Ganze nur relevant sein, wenn die Filterwidgets als Link ausgegeben werden - z. B. mm_filteritem_linklist.html5; was hast Du in mm_filteritem_default.html5 geändert?

Wenn das so mit dem rel="nofollow" so allgemein passt, könnte das als Standard in die entsprechenden Templates.

Ich konnte es jetzt auch nur übers Backend testen, da ich auf der Console eine Fehlermeldung wegen unterschiedlicher php Versionen bekomme.

Guck mal nach dem Pfad im CManager in der Startsequenz und verwende den statt php

[Shania567]

Ich blicke langsam nicht mehr durch, irgendwie kommt immer mal was anderes raus ist mein Eindruck. Jetzt habe ich wieder diverse Seiten drin. Sinnvoll wäre es wohl das ganze mal mit einem reduzierten Datenbestand und weniger MMs testen. Sonst dauert alles ewig und vielleicht habe ich doch was vergessen weg zu klicken oder was weiß ich. Aber dazu fehlt mir gerade die Zeit, sorry.

Das rel="nofollow" ist eine Angabe für den <a>-Tag und muss als Attribut dort eingetragen werden - siehe https://developers.google.com/search/docs/crawling-indexing/qualify-outbound-links?hl=de#nofollow
Ja, das ist mir schon klar. Im Inhaltselement Text macht Contao das automatisch so, auch wenn man es hinter den Link setzt.

was meinst du mit

=> Hier habe ich jeweils ganz oben ein und ganz unten ein eingefügt.

?
Da hat der Editor die Passage gelöscht, sorry.
<!-- indexer::stop --> <!-- indexer::continue -->
Oder greift das ohnehin nicht mehr? Ich finde die aber auch immer noch in Contao Originaltemplates, daher dachte ich, ich versuche es mal.

Beim Filter sollte das Ganze nur relevant sein, wenn die Filterwidgets als Link ausgegeben werden - z. B. mm_filteritem_linklist.html5; was hast Du in mm_filteritem_default.html5 geändert?
Was die Suche betrifft nur
<!-- indexer::stop --> <!-- indexer::continue -->

[zonky2]

Das <!-- indexer::start|stop --> ist dafür da, dass nicht überflüssiger oder ungewollter Text einer Seite in den Suchindex aufgenommen wird - es geht hier aber primär darum, dass der Crawler nicht unnötiger Weise irgendwelchen Links nach geht... und das geht bei einem dezidierten Link mit rel="nofollow"

[zonky2]

@Shania567 habe nochmal nachgesehen - die (Standard)Templates für den Filter-Wrapper, Clear-All und Pagination haben alle ein
<!-- indexer::stop --> <!-- indexer::continue -->

[zonky2]

Fixed in MM 2.3 - we add data-escargot-ignore