SW 5.4.6 => SW 5.5.3 explodierende Anzahl an "Urls"

N’abend,

nach dem Update von SW 5.4.6 auf 5.5.3 hatte ich mich schon beim “Cache-Aufwärmen” über den Anstieg der zu generierenden Seiten um den Faktor 10x gewundert.
Um so mehr wundert es mich jetzt aktuell, dass auch die Anzahl der bei Google über die Sitemap eingereichten Seiten ungefähr auf den 10-fachen Wert gestiegen ist.
Bei derzeit 172 Artikeln sind aktuell 1993 Urls übermittelt, wovon 195 indexiert sind, was in etwas der “alten Anzahl” an übermittelten Urls entspricht.

So wirklich sauber kommt mir das nicht wirklich vor - hat da wer eine Erklärung zu?

Zudem ist wohl auch gerade ein Crawler im Shop gewesen - (IP / Name kann ich erst ab morgen besorgen) - hat Tablet-View aufgerufen, und mit jedem Aufruf einen “Besucher” erzeugt. Sollte wohl auch nicht so sein, oder?

Hast du denn mal in die Sitemap reingeschaut? Wüsste nicht, was da sonst anderes drin sein soll, als vorher. Das kannst du ja ganz gut einmal nachschauen.

Die Parameter für das Cache-Warming kannst du selbst definieren.

Es ist halt nun möglich alles aufzuwärmen, bspw. auch den Wechsel über Ajax oder Artikel mit C-Parameter. Wie Sinnvoll das ist, muss man individuell entscheiden. Das Thema hatten wir ja schon einmal hier: https://forum.shopware.com/discussion/comment/235820/#Comment_235820

Bei kleinen Shops kann man sicherlich alles machen, bei Shops mit vielen Artikeln macht es kaum Sinn, alles aufzuwärmen.

@sonic schrieb:

Zudem ist wohl auch gerade ein Crawler im Shop gewesen - (IP / Name kann ich erst ab morgen besorgen) - hat Tablet-View aufgerufen, und mit jedem Aufruf einen „Besucher“ erzeugt. Sollte wohl auch nicht so sein, oder?

Dazu wollte ich noch was schreiben, eben ganz vergessen

Besucher kann ich mir fast nicht vorstellen, da die ja anhand der IP auseinander gehalten werden. Da müsste schon jeder Request ein anderer Bot sein. Die Statistik schließt nicht generell jeden Bot aus, da es keine zuverlässige Methode zur Bot-Erkennung gibt (bspw. Useragents können geändert werden), daher durchaus denkbar, dss der in der Statistik landet, aber wenn die IP gleichbleibt dann natürlich auch nur einmal mit x Impressions.

Naja, jetzt 1900 Einträge in der Sitemap zu überprüfen ist mir für das Wochenende doch etwas zu arg. 
Der „Cache“ ist ja das eine. Hab grad mal den SEO gelert und nochal den Cache aufgewärmt… jetzt wurden 1279 von 1075 Urls aufgewärmt *lol*
(Fast) Keine Varianten! Ggf. sind Artikel mal in 3 max 4 (2 Stream) Kategorien enthalten. Aber damit komme ich nicht auf den Faktor 10. (Im Shop mit mehr Varianten ist die Sitemap derzeit ca. Faktor 3 so groß)

Das „Aufwärmen“ ist ja das eine - „Platz“ ist kein Problem , aber warum die Sitemap so aufgebläht wird, dürfte das ja nicht erklären, ob es so gut ist, wenn auf 1 Artikel 10 Einträge kommen (abzüglich ein paar wenige Kategorien, Seiten & Blogeinträge)?!?
Muss ich mir bis Montag mal durch den Kopf gehen lassen… Ggf. geh ich doch erstmal wieder zu 5.4.6 zurück.

P.S: Gleich bekomme ich wahrscheinlich so, wie ich es sonst selber mache, die Doku und Suche um die Ohren geschlagen. Ich habe zwei Stream-Kategorien: Newomer und Angebote. Die dürften eigentlich gar nicht in die Sitemap, finde ich.
 

Zum vermeintlichen Bot:
Ich bekomme nur kurz nach Mitternacht die täglichen Zugriffslogs - dann kann ich etwas sagen - also ab morgen, oder wohl eher Montag 
Was ich zur Beobachtung in dem Shop sagen kann (Stichprobe vorhin): 138 Besuche - dazu 138 einzelne Tablet-Views auf 138 Artikel - nichts doppelt etc, in eher kurzer Zeit.

Naja, du sollst ja nicht 1900 Einträge prüfen. Aber wenn man die XML öffnet, sieht man schon ganz gut, wie viele Einträge die hat. Ich hab das mal bei der Seite, die ich von dir kenne, gemacht, da sind das definitiv keine 1900 Einträge die da drin sind. Vielleicht auch einfach ein Anzeigefehler bei Google aufgrund der neuen Sitemap? Sonst schick mir mal ein Beispiel, wo viele “falsche” Urls in der Sitemap sind.

Fehler gefunden, aber nicht den Grund des Fehlers.

1. Für eine Kategorie wurden sehr viele Artikel 30x identisch in die Sitemap eingetragen.
2. Die Kategorie ist eine Streamkategorie mit Filter auf Newcomer
3. Aus irgendeinen Grund hatte die Kategorie zum Stream zusätzlich den Tab Kategorien Artikelzuordnung nicht mehr ausgegraut und es waren neben dem Stream noch zusätzlich 84 Artikel - aus der Newcomer-Liste  - zugeordner. Eigentlich sollte das ja gar nicht passieren.
   Gemacht getan:
4. Streamzuordnung entfernt
5. alle Artikel aus der Kategorie entfernt
6. Der Kategorie wieder Stream zugewiesen => Artikelzuordnung-Tab nun ausgegraut.
7. sitemap neu erstellt
   Resultat: Sitemap ist nicht mehr 356kb sondern nur noch 39kg groß 

Dafür gibt es jetzt ein neues Problem:
Die Artikel, die nicht mehr in der Stream-Kategorie sind, aber noch in ihrer Haupt-Kategorie, werden in der Sitemap nur noch für die Stream-Kat gelistet, aber nicht für ihre Basis-Kat.

Ich glaube, da hilft derzeit nur noch ein “Zurück” zu 5.4.6 mit nem Backup am Montag. 

Keine API-Zugriffe auf den Shop, keine WaWi, keine Plugins.
Wie und warum aus dem Stream Artikel der Kategorie zugeordnet wurden? Keine Ahnung. Ggf. Updarte 5.4.6 => 5.5.3 oder “Hochsetzen” der Tage für Newcomer? *Schulter Zuck*

Update:
Cache geleert, SEO-Index geleert, SEO neu erstellt, Kategoriebaum neu erstellt und sitemap neu erstellt. Nun sind die Artikel auch wieder in der sitemap in ihrer Stammkategorie.
Cache aufwärmen nun: 990 von 990 Urls

Ein echter schwarzer Freitag (Abend) 

Ggf. werde ich am Montag einen Testshop aus dem Pre-Backup vor Update von 5.4.6 auf 5.5.3 aufsetzen (vom letzten Montag), und gucken, ob da schon der “Wurm” drinne war, und ggf. das Update noch mal durchführen.

Edit:
Eine MÖGLICHE Fehlerquelle, weil fast alle Artikel aus einem Kategorie-Zweig waren: Ein “erster” Artikel wurde (möglicher Weise) versehentlich nicht nur seiner Stammkategorie zugewiesen, sondern auch der Kategorie “Neuheiten”. Danach wurde munter dupliziert. =>

1. Sollte eine Kategorie, die eine Streamkategorie ist, nicht einem Artikel zugewiesen werden können.
2. Sollte bei Zuweisung eines Streams zu einer Kategorie ggf. vorhandene Artikel aus der Kategorie entfernt werden.

Kann man ja nicht unbedingt voraussetzen, dass Backenduser weiß, dass “Neuheiten” per Stream gefiltert werdem und nicht extra zugewiesen werden müssen. Wie gesagt: KÖNNTE die Fehlerquelle gewesen sein. Das Stream-Kategorien Artikel zugewiesen werden können, muss eigentlich die Backend-Logic abfangen, bzw. bereinigen.