Neu Filter URLs mit einem generellen / anderen Parameter

[ecki]

Hallo,

Wenn ich die Merkmalfilter benutze werden dies immer mit 2x _ also boden__Alu in der URL ausgegeben.
Gibt es die Möglichkeit die __ durch einen anderen Parameter zu ersetzen?
also boden?filter=alu in der URL

Alternativ die __ durch ein # zu ersetzen?

Jemand eine Idee?

Gruß
ecki

 

[FMoche]

Rein theoretisch ja - das ist die Konstante "SEP_MERKMAL", die du prinzipiell über die includes/defines_inc.php modifizieren könntest.
Ich würde aber dringend davon abraten. Insbesondere ist das "#" ja schon für Sprungmarken reserviert.

 

[ecki]

Rein theoretisch ja - das ist die Konstante "SEP_MERKMAL", die du prinzipiell über die includes/defines_inc.php modifizieren könntest.
Ich würde aber dringend davon abraten. Insbesondere ist das "#" ja schon für Sprungmarken reserviert.

Hallo FMoche,
danke für die Antwort. ?filter ist klar die bevorzugte Wahl.
Wie kann ich dies "Updatesicher" ändern?

Es wird von unserem SEO gewünscht, um die URLs via robot.txt vom crawlen auszuschließen.

 

[FMoche]

Updatesicher leider gar nicht - die Konstante ist nicht dazu gedacht, geändert zu werden.

 

[golvreven]

Hallo FMoche,

die Lösung, URLs mit _ zu erzeugen, ist nicht SEO-freundlich und ein weiteres Beispiel für einen unerklärlichen Sonderweg von JTL. Von daher geht Ecki im Ansatz den richtigen Weg! Warum gibt es keine updatesichere Lösung?

Viele Grüße
g.

 

[golvreven]

Hallo zusammen,

ich muss die Frage noch einmal hochholen, da das Thema im Lichte der letzten Google Core Updates von Bedeutung sein könnte: Nutzersignale sind definitiv wertvoller geworden. Dass die paginierten Seiten von Artikellistings URLs mit _ statt mit einem "ordentlichen" Parameter aufgebaut werden, ist dabei ein echtes Eigentor. Denn sämtliche Nutzersignale auf den paginierten Seiten zahlen nicht auf die kanonische SEO-URL ein, zu der die paginierten Seiten gehören, sondern werden von Google auf Ebene der paginierten Seiten separat gezählt. Das Problem betrifft somit gerade Oberkategorien, auf die die SEO eines Shops aufbaut. In gleicher Weise dürfte sich der URL-Aufbau von Merkmal-/Filterseiten mit _ bzw. __ auswirken.

Also: Wie kann der Unterstrich in URLs durch einen "ordentlichen" Parameter ersetzt werden? Und das möglichst updatesicher?

Viele Grüße
g.

 

[jtldudel]

Wir stehen vor dem gleichen Problem, hat jemand eine Lösung?
Wir versuchen mit dem Plugin "SEO Optimierung durch PRG Methode" von Netzdinge zumindest die Flut der möglichen URLs die unnötigerweise indexiert werden einzudämmen, die sich durch die Merkmalfilter ergeben, aber ich verstehe nicht ganz warum es überhaupt so gehandhabt wird von JTL

 

[Ferox]

Ich möchte mich auch gerne an diesem Thema beteiligen und bitte JTL hier um Anpassung. Wir haben das Problem, dass Artikel teils über 5 Merkmale mit z.T. über 20 Merkmalerte haben. Dies hat nun die Folge, dass ein Meta-Crawler unseren ganzen Server lahmlegt, weil er jede neue URL mit FIlterung versucht zu Crawlen. Keine gefilterte Seite darf/sollte gecrawled werden. Eine Lösung mit "__" erachte ich ebenso als nicht charmant, um nicht zu sagen nicht sonderlich professionell. Eine Filterung muss wie hier oben genannt klarer deklariert werden um dies auch in einer robots.txt einem Crawler besser mitzuteilen. Wenn ich hier nun die "__" in der Robots nicht erlaube, erkennt das der Crawler nicht. Dies ist ein erheblicher Mangel.
Wir versuchen nun über eine Cloudflare WAF das etwas zu hemmen, jedoch kann ich den Crawler dahingehend nicht blockieren, da er dann noch aggressiver vorgeht und den Server noch mehr überlastet.

Der letzte Weg ist nun, dass wir jetzt gezwungen sind aufgrund dieses Mangels die Merkmale herunterzustufen/löschen und tiefer zu kategorisieren, was wesentlich Nutzerunfreundlicher ist und somit weniger Verkäufe generiert.

 

[golvreven]

@Ferox Guter Punkt! Habe ich bisher nicht angeführt.

Besonders tragisch finde ich es, dass man in JTL 5 beim Filtern sogar inhaltlich auf derselben URL bleibt (z. B. verschwindet der Kategorietext nicht, wenn ich filtere), aber aus Sicht von Suchmaschinen und Crawlern trotzdem eine neue URL aufgerufen wird. Wir hätten mit unseren vielen Merkmalen wahrscheinlich superlange Verweildauern auf unseren Kategorieseiten (Artikellistings), aber nichts da ... Das wird durch einen der grundlegenden Fehler von JTL torpediert.

 

[Ferox]

Für mich ist es absolut nachvollziehbar, dass Aufrufe in 6 bis 7-stelliger Höhe von Crawlern im Zusammenhang mit zuvielen Merkmalen und Merkmalwerten im Zusammenhang steht und damit auch der Umgang von JTL mit der Erstellung von Links. Hier mal ein schönes Beispiel von uns - wir haben einen neuen Shop aufgesetzt in der Free-Edition, weil wir auch nicht mehr als 500 Artikel dort planen. Diese Artikel sind jedoch in sich sehr komplex mit 5 verschiedenen Merkmalen und durchaus über 40 verschiedene Merkmalwerte. Hier mal ein Screen was allein die Shopauswertung sagt, Cloudflare sagt sogar noch mehr. Der Shop ist recht frisch und wird noch nirgendwo verlinkt - noch irgendwo bei Social Media oder unseren anderen Websiten. Google auch kaum in den Top 100.



Wir müssen für unseren Teil also leider umdenken und dies ggf. über einen von JTL zur Verfügung gestellten Konfigurator lösen oder einen eigenen bauen.

Andere Shops von uns, die wirklich nur einfache Artikel haben mit z.B. Farbe Schwarz / Silber sind nicht von solchen "Crawlerattacken" betroffen.

 

[css-umsetzung]

Die Umstellung auf PRG ist bereits in Arbeit und wird wie es scheint, mit der nächsten Version kommen

wir versuchen nun über eine Cloudflare WAF das etwas zu hemmen, jedoch kann ich den Crawler dahingehend nicht blockieren, da er dann noch aggressiver vorgeht und den Server noch mehr überlastet.

Bei den Crawlern handelt es sich nicht immer um erkennbare Bots, da eine klare Kennung fehlt, allerdings kommen diese mit immer neuen IP Adressen.
Für besonders schwer betroffene Seiten habe ich etwas programmiert, dass den Bots das besuchen von verschachtelten Merkmalfiltern sowie den direkten Aufruf der Suchfunktion verbietet.
Mit dieser Programmierung kehrt Ruhe ein und die Serverlast wird mehr als deutlich reduziert.

 

[golvreven]

Die Umstellung auf PRG ist bereits in Arbeit und wird wie es scheint, mit der nächsten Version kommen


Bei den Crawlern handelt es sich nicht immer um erkennbare Bots, da eine klare Kennung fehlt, allerdings kommen diese mit immer neuen IP Adressen.
Für besonders schwer betroffene Seiten habe ich etwas programmiert, dass den Bots das besuchen von verschachtelten Merkmalfiltern sowie den direkten Aufruf der Suchfunktion verbietet.
Mit dieser Programmierung kehrt Ruhe ein und die Serverlast wird mehr als deutlich reduziert.

Verstehe ich es richtig, dass das in JTL 6 sein wird? Oder noch in JTL 5?

 

[css-umsetzung]

Vermutlich 5.7, ich werde mir die heute installieren, dann weiß ich mehr.

 

[golvreven]

@css-umsetzung Und, was sagt die 5.7?

 

[css-umsetzung]

Also die 5.7er hat das PRG enthalten, muss extra aktiviert werden.

JTL hat wie es scheint, in diesem Punkt auch an der Geschwindigkeitsschraube gedreht, dass kann ich aber selbst nicht testen,
da meine DEV Installationen nicht so viel Merkmale haben, als das ich da echte Tests durchführen könnte.

Die Werte die ich gesagt bekommen habe sind aber, wenn sie stimmen, vielversprechend.

 

[golvreven]

Klingt aber erstmal nach einem überraschenden Fortschritt für mich. Eine Frage noch dazu: Betrifft die Umstellung nur die Filterung in Artikellistings oder auch die Merkmaltabellen auf Artikeldetailseiten? Dort befinden sich ja auch die internen Links auf Merkmale, um die es geht.

 

[css-umsetzung]

Die Merkmale auf der Detailseite sind ja einzelne und keine verschachtelten Links.

 

[golvreven]

Richtig. Dennoch können durch diese Merkmaltabellen sehr viele interne Links auf URLs entstehen, die nicht pauschal indexiert werden sollten.

 

[css-umsetzung]

Ich würde Merkmale grundsätzlich nicht indexieren lassen, außer ich habe für jedes Merkmal wertvollen Content hinterlegt.

Letztendlich ist es nur ein Listing von vielen, in dem Produkte vorkommen, die auch in anderen Listings vorhanden sind, daher Frage ich mich was mir diese Indexierung bringen soll.

Ich bin keine SEO Agentur eventuell sehen die da ja einen Mehrwert, dass zu indexieren.

 

[Märztext]

Hallo css-umsetzung,

grundsätzlich stimme ich Dir zu. Die Seiten pauschal auf "noindex" zu stellen, ist aus meiner Sicht aber etwas oberflächlich. Bei genauem Hinsehen kann man die eine oder andere vielleicht nutzen, um damit Nischen-Keywords abzudecken? Das ist allemal besser, als über "Eigene Inhalte" irgendwelche Landingpages ohne ein richtiges Produktlisting anzulegen.

Viele Grüße
Michael