Closed Shania567 closed 1 year ago
zonky2
commented
1 year ago 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
commented
1 year ago ... oder ein no-follow in die Filterwidgets, die URLs erzeugen - siehe https://github.com/MetaModels/core/issues/1468
Shania567
commented
1 year ago 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
commented
1 year ago 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 https://github.com/contao/contao/issues/3925#issuecomment-1012338897 - die Suche nach kaputten Links darf dabei aber nicht auch an sein - siehe https://github.com/contao/contao/issues/3925#issuecomment-1012475382
Shania567
commented
1 year ago 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
commented
1 year ago 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
commented
1 year ago 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 inmm_filteritem_default.html5geändert? Was die Suche betrifft nur<!-- indexer::stop --> <!-- indexer::continue -->
zonky2
commented
1 year ago 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
commented
1 year ago @Shania567 habe nochmal nachgesehen - die (Standard)Templates für den Filter-Wrapper, Clear-All und Pagination haben alle ein
<!-- indexer::stop --> <!-- indexer::continue -->
zonky2
commented
1 year ago Fixed in MM 2.3 - we add data-escargot-ignore
Checklist before I submit this issue report
I confirm that:
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:
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.