htaccess wie Umleitung einrichten?

[hpzeller]

[...]
Ich habe nochmals nachgesehen, der ganze Link lautet:
Produkt:::5_268_271.html?language=en?cat=c271_Produkt.html&tpl=mobile
[...]
Wie gesagt, ich bekam eine Nachricht von Google, dass es eine erhebliche Zunahme von nicht gefundenen URL gibt. Dies fängt exakt nach der Umstellung von modified 1.06 auf 2.0 an.
[... ]

Mir scheint das eigentliche Problem in obiger URL liegt nicht hier 'tpl=mobile' sondern hier 'language=en?cat=c271_Produkt.html', deshalb folgender Vorschlag:

In 'includes/modules/set_language_sessions.php' ca. Zeile 20 folgenden Code

Code: PHP  [Auswählen]

    $_GET['language'] = xtc_input_validation($_GET['language'], 'char', '');
 

mit diesem ersetzen

Code: PHP  [Auswählen]

    $_GET['language'] = substr(xtc_input_validation($_GET['language'], 'char', ''), 0, 2);
 

PS:
Die Ursache für 'Status: 404 Not Found' bei Eingabe eines falschen 'language' Parameters liegt an folgendem Code in includes/modules/set_language_sessions.php ca. Zeile 35

Code: PHP  [Auswählen]

  if (isset($_GET['language']) && !isset($lng->catalog_languages[$_GET['language']])) {
    $_GET['language'] = DEFAULT_LANGUAGE;
    $language_not_found = true;
  }
 

welcher in der Shopversion 2.0 neu dazu gekommen ist.

Gruss
Hanspeter

[Viol]

Hallo Hanspeter,

herzlichen Dank für Deine Hilfe, Dein Tipp hat wieder einmal 100%tig geholfen!
Auch die URL, die  filter_id=    enden, finden jetzt ihr Ziel!

[p3e]

Das eigentliche Problem ist aber, dass in der URL der erste Parameter nach der Sprache durch ein ? anstelle einem & getrennt wird. Wäre es ein & dann würde der Shop den Sprachparameter auch richtig einordnen. Außerdem brauchst Du in Deinem Beispiel die Parameter hinter dem Sprachparameter gar nicht, da sie schon durch ":::5_268_271" vorhanden sind und Du das mobile Template nicht mehr nutzt.
Ich kann das bei mir nicht nachvollziehen. Hier werden die Links richtig gebildet.
Vielleicht generierst Du für Google fehlerhafte Sitemaps? Ich denke da solltest Du mal schauen.

[Viol]

Ich habe bislang für Google noch keine sitemap.xml generiert.
Auffällig ist, dass diese URL erst nach dem Umstieg auf modified 2.0 bei Google aufliefen. Lässt sich dort in der Grafik auch sehr deutlich ablesen. Genau am Tag der Umstellungen stiegen die fehlerhaften URL sprunghaft an.

[p3e]

Das schrieb ja hpzeller bereits. Erst in der 2.0 wird überprüft, ob die Sprache überhaupt vorhanden ist. Falls nicht liefert er einen 'Status: 404 Not Found'.
Problem ist dennoch Deine URL.

Produkt:::5_268_271.html?language=en?cat=c271_Produkt.html&tpl=mobile

Wegen dem zweiten Fragezeichen (statt &) ist für den Shop der Parameter 'language' mit dem Wert 'en?cat=c271_Produkt.html' belegt. Die Lösung von hpzeller bewirkt, dass nur die ersten zwei Buchstaben von dem Parameter relevant sind (in dem Beispiel 'en'). Dadurch funktioniert der Link wieder, die URL ist aber dennoch komisch und wenn du keine Sitemap verwendest, hat Google die eventuell noch von deinem alten Shop. Dann war da vermutlich irgendwas falsch.

Eigentlich solltest Du alles ab ?cat abschneiden und per 301 weiterleiten, schau mal nach ob der canonical tag richtig ist, wenn Du diese URL nutzt. In dem Fall lernt Google ja mit der Zeit die richtige URL und Du kannst Dir die Weiterleitung schenken.

[hpzeller]

Hallo p3e,

aufgrund deiner Kritik habe ich den Sachverhalt jetzt ein bischen untersucht, mit folgendem Ergebnis.

Ohne Hack aus meiner Antwort #15 erhällt Google in einem modified 2.0 Shop mit folgender URL
https://demo.modified-shop.org/trunk/Testkategorie-4/Testartikel-13::13.html?language=en?cat=c271_Produkt.html&tpl=mobile

dieses Resultat

[ Für Gäste sind keine Dateianhänge sichtbar ]

Mit Hack aus meiner Antwort #15 erhällt Google in einem modified 2.0 Shop mit folgender URL
http://(( Wir dulden keine kommerziellen Werbelinks - Bitte Forenregeln beachten! ))/modified2/Testkategorie-2/Testproduct3::3.html?language=en?cat=c271_Produkt.html&tpl=mobile

dieses Resultat

[ Für Gäste sind keine Dateianhänge sichtbar ]

Hier kannst du selbst testen.
Redirect-Checker: http://www.redirect-checker.org/index.php

Fazit:
So wie ich das sehe könnte Viol den Hack auch ruhig weglassen, dann bekommt Google für die falschen URL's nämlich jeweils einen [Status: 410 Gone] und würde infolgedessen diese URL's aus dem Index streichen.

Gruss
Hanspeter

[p3e]

Hallo hpzeller,

mein Post war keinesfalls Kritik an Dich. Deine Lösung finde ich sehr gut und ich finde auch Deine anderen Beiträge hier prima!

Es geht mir darum zu klären, wieso Google diesen komischen Link überhaupt ansteuert (also die Wurzel des Problems). Der Shop sollten ihn so eigentlich nicht ausgeben. Ist eventuell ein Fehler in seinem 1.06 Shop gewesen, der jetzt in der 2.0 erst auffällt. Deshalb habe ich auch empfohlen zu schauen,  ob der canonical tag richtig ist wenn er diese URL aufruft (um duplicate Content zu vermeiden).

[Viol]

Deshalb habe ich auch empfohlen zu schauen,  ob der canonical tag richtig ist wenn er diese URL aufruft (um duplicate Content zu vermeiden).

Hallo p3e,

wenn Du mir verrätst, wie ich wo nach dem canonical tag suchen muss, gerne.
Im Quelltext wird kein <link rel="canonical "ausgegeben. Oder sollte ich zur Überprüfung den Hack ausbauen müssen?

[hpzeller]

Zur Information, in 2.0 gibt es diesen TAG

Code: XML  [Auswählen]

<link rel="canonical" href="https://(( Wir dulden keine kommerziellen Werbelinks - Bitte <a href="index.php?topic=3013.0">Forenregeln</a> beachten! ))/shop_demo/Startseite.html/a" />

nur bei einsprachigen Shops, bei mehrsprachigen Shops werden stattdessen solche TAG's im Header erzeugt.

Code: XML  [Auswählen]

<link rel="alternate" href="http://(( Wir dulden keine kommerziellen Werbelinks - Bitte <a href="index.php?topic=3013.0">Forenregeln</a> beachten! ))/modified2/Testkategorie-2/Testproduct3::3.html?language=en?tpl=mobile" hreflang="x-default" />
<link rel="alternate" href="http://(( Wir dulden keine kommerziellen Werbelinks - Bitte <a href="index.php?topic=3013.0">Forenregeln</a> beachten! ))/modified2/Testkategorie-2/Testprodukt3::3.html?language=de?tpl=mobile" hreflang="de" />
<link rel="alternate" href="http://(( Wir dulden keine kommerziellen Werbelinks - Bitte <a href="index.php?topic=3013.0">Forenregeln</a> beachten! ))/modified2/Testkategorie-2/Testproduct3::3.html?language=en?tpl=mobile" hreflang="en" />

PS:
Um zu überprüfen wie der "canonical" bzw. "alternate hareflang" für Google aussieht, kann man aber nicht einfach eine Adresse in seinem Browser eingeben und im Quelltext nachsehen.

Gruss
Hanspeter

[hpzeller]

Hallo p3e,

also ich sehe begründete Kritik als etwas Positives und es war für mich in diesem Fall einfach der Anlass die Sache etwas vertiefter zu betrachten.

Gruss
Hanspeter

[hpzeller]

Nachtrag zur Antwort #23

Habe gerade festgestellt, das die Sache mit "alternate hreflang" statt "canonical" TAG's nur gilt wenn im Shop Suchmaschinenfreundliche URL's aktiviert sind.

Gruss
Hanspeter

[Viol]

Hallo Hanspeter,
danke für Deine Erklärungen. Ich habe die suchmaschinenfreundlichen URL aktiviert.
Wenn ich jetzt den "fehlerhaften" Link eingebe Produkt:::5_268_271.html?language=en?cat=c271_Produkt.html&tpl=mobile
komme ich dank Deines Hacks auf die richtige Seite.
Im Quelltext sehe ich dann:

Code: XML  [Auswählen]

<link rel="alternate" href="http://www.meinshop.com/category/subcategory/Product:::5_268_271.html?language=en?tpl=mobile" hreflang="x-default" />
<link rel="alternate" href="http://www.meinshop.com/category/subcategory/Product:::5_268_271.html?language=en?tpl=mobile" hreflang="en" />
<link rel="alternate" href="http://www.stradivarishop.com/Katergorie/Subkategorie/Produkt:::5_268_271.html?language=de?tpl=mobile" hreflang="de" />

Ist es das, was Ihr meint? Auch der Hinweis, das bei Google so zu lassen, wäre mir auch recht, wenn es keine negativen Folgen für die Suchergebnisse hätte. Es sind ungefähr 1000 410 Fehler aufgelistet.
Die meisten (ca.950) der URL sehen ähnlich dieser aus:
/Kategorie/Subkategorie/Subkatergorie/-rot:::1_8_64.html?language=de?filter_id=21

[hpzeller]

Nun ich sehe es so, die fehlerhaften Url's welche Google in seinem Index hat stammen aus deinem alten 1.06er Shop, diese Url's verschwinden aus dem Index wenn du den Hack wieder raus nimmst, weil dann bekommt Google den Statuscode 410 Gone, also Seite dauerhaft entfernt und darin kann ich beim besten Willen nichts erkennen was sich negativ auf deinen Shop auswirken könnte.

Die von dir geposteten "alternate hreflang" TAG's sind nicht richtig, z.B. sind hier ja zwei Fragezeichen drin 'href="http://www.meinshop.com/category/subcategory/Product:::5_268_271.html?language=en?tpl=mobile"' und das ist natürlich schlecht, weil Google diese wieder in den Index aufnimmt, nun ist es aber so, dass die von dir geposteten "alternate hreflang" TAG's nicht unbedingt die selben sind die auch Google erhält wenn sie als 'googlebot' die gleiche Adresse aufruft.

Mein Fazit:
Nimm den Hack wieder raus, das ist eine saubere und einfache Lösung.

Gruss
Hanspeter

[Viol]

Mein Fazit:
Nimm den Hack wieder raus, das ist eine saubere und einfache Lösung.

Gruss
Hanspeter

Danke nochmal Euch beiden. Ich habe den Hack wieder entfernt. Die Links in meinem Shop funktionieren ja alle und so sollten sich 410 bei Google auch erledigen...

[hpzeller]

Leider musste ich feststellen, dass das Problem der fehlerhaft erzeugten Querystrings bei Verwendung suchmaschinenfreudlicher URLs auch in modified 2 immer noch besteht.

Beispiel:

https://demo.modified-shop.org/tags/modified-2.00/Testkategorie-1:::1.html?language=en?show=list

Obige Adresse mit falschem Querystring (zwei Fragezeichen) kann man im Demo-Shop reproduzieren, in dem man z.B Testkategorie 1 anklickt dann auf Listenansicht klickt und danach durch klick auf die Sprach-Flagge die Sprache wechselt, als Resultat wird  dann eine Fehlerseite mit Statuscode 410 Gone (siehe Bildanhang) ausgegeben.

Lösung des Problems:

In inc/shopstat_functions.inc.php Zeile 155 folgender Code

Code: PHP  [Auswählen]

    if (strlen($lang) > 0) {
      $link .= $separator.'language='. $lang;
    }
 

ersetzen mit

Code: PHP  [Auswählen]

    if (strlen($lang) > 0) {
      $link .= $separator.'language='. $lang;
      $separator  = '&';
    }
 

Damit erreicht man, das nach anhängen des 'language' Parameters ein '&' und nicht ein '?' als Separator folgt.

PS:
Ich habe mittlerweile festgestellt, dass das oben beschriebene Problem im trunk Demo-Shop nicht mehr besteht, da aber der Fehler in der aktuellen Shopversion noch nicht gefixt ist und Bugfixes vom Modified-Team leider ziemlich intransparent gehandhabt werden, poste ich den Fix hier für diejenigen die es in ihrem Shop korrigieren möchten trotzdem.

Gruss
Hanspeter