Neu Probleme mit Weiterleitungen

[Tomas]

Hi Leute.

Ich habe aktuell zwei Probleme mit meinen Weiterleitungen.

Zum einen habe ich in den Weiterleitungen sehr viele Einträge dessen URLs mit "$cCanonical" enden.

Hat einer von euch eine Idee wo das her kommen kann? Vermutlich hat Google versucht die Seiten so aufzurufen. Ich frage mich aber, wo Google diese Informationen her hat?


Desweiteren versuche ich eine csv mit URLs zu Importieren. Ich bekomme jedoch immer die Fehlermeldung "Fehler: Der Import konnte nicht durchgeführt werden. Bitte prüfen Sie die CSV-Datei

Die Kopfzeile entspricht nicht der Konvention!"

Was ich bereits versucht habe:
sourceurl;destinyurl
sourceurl;destinationurl
cFromUrl,cToUrl
cFromUrl;cToUrl

Ich finde einfach nicht den Fehler. Es scheint auch überall etwas anderes zu stehen, wie die Datei aufgebaut sein muss. :/


Vielen Dank im Voraus!

LG
Tomas

 

[weitergehts]

Hi Tomas,

ersteres würde mich auch einmal interessieren, weil wir ein ähnliches Problem haben.
Wir haben extrem viele Weiterleitungen mit "%20" Zeichenfolge in diesen Links, die sich auch in den Webmastertools einnisten ohne, dass dies im Quellcode sichtbar ist.

BG
Bernd

 

[Tomas]

Hallo weitergehts,

dein "Problem" scheint aber ganz anderer Natur zu sein. Die '%20' sind ganz normal. Du wirst in deinen URLs sicher viele Leerzeichen haben oder?
Die Leerzeichen in URLs werden durch '%20' ersetzt.

Hier ein paar Infos zum URL-Encoding:
https://de.wikipedia.org/wiki/URL-Encoding

LG
Tomas

 

[weitergehts]

Hi Tomas,
oh sorry, ich habe mich vertippt. Es sind %22 . Wir haben keine Leerzeichen in den URL.
Das ist der Unicode für Anführungszeichen.

In der Search Console haben wir dann praktisch 404er die mit www.domain.de/%22Produkt1%22 stehen und nicht gefunden werden.

In den verlinkenden Seiten ist eine URL in dieser Form allerdings nicht enthalten.

 

[Tomas]

Ah! Also quasi das Problem, welches ich hier habe: https://forum.jtl-software.de/threads/google-search-console-crawlingfehler-22.112006/

Hast du in dem Shop noch das JTL-Debug Plugin am laufen?

Wir hatten das Plugin deaktiviert und die 404er in der Search Console als "Korriert" Markiert. Der zeigt die Fehler dann ja wieder an, wenn die erneut auftauchen.
Nach der Deinstallation des Plugins ist aber nichts mehr aufgetaucht. Auch die Fehler mit dem $cCaconnical haben sich erledigt.

LG
Tomas

 

[weitergehts]

Bingo,

genau das gleiche Problem haben wir auch.
Das mit dem Debug Plugin hatte ich auch schon gelesen. Das ist bei uns deaktiviert. Dann muss ich es nochmal mit deinstalliertem versuchen und lösche Meldungen in der Search Console nochmal.

Dem Braten traue ich aber noch nicht ganz.

Danke für die Hinweise

 

[Tomas]

Dem Braten traue ich aber noch nicht ganz.

Genau deswegen habe ich die "Lösung" noch nicht in die Beiträge geschrieben. Ich will mir das alles vorher nochmal ganz genau in der Search Console anschauen.

 

[djdreh]

Hallo alle zusammen,

wir haben genauso seit ein paar Tagen (genauer gesagt seit dem Shop-Update auf 4.06 und vom Smile-Template) ähnliche Probleme mit lauter Google-Crawler-Fehlern wegen %22 um die Produkt-URLs herum... Diese können wir auch auf Teufel komm raus nicht im Browser sehen oder irgendwie verifizieren, woher diese kommen. Jetzt habe wir mal das Debugging-Plugin deinstalliert (es war eh schon deaktiviert), mal schauen ob die Ergebnisse bei Google besser werden bzw. verschwinden.

Gab es hier von eurer Seite nochmal neue Erkenntnissse zu der Problematik? Es kann ja auch nicht sein, dass man ohne Debug-Plugin "leben" muss, weil es sonst die Google-Crawling-Ergebnisse kaputt macht... Wir brauchen das PLugin auch zum Entwickeln...

Viele Grüße,
Benjamin

 

[en001]

Gibt es denn ein konkretes Beispiel?
Ist es die neue Searchkonsole die Fehler zeigt?

 

[djdreh]

Hallo en001,

nein, es ist die alte Search-Console von Google...

Konkretes Beispiel:

URL:
https://trendplace.de/"Adalya-Cool-Tabak-200gr/"

Error details
Linked from
​

Last crawled: 10/16/18
First detected: 10/16/18
Googlebot couldn't crawl this URL because it points to a non-existent page. Generally, 404s don't harm your site's performance in search, but you can use them to help improve the user experience. Learn more

Linked from: https://trendplace.de/Mazaya-Pure-BreeZ-Tabak-200gr

Auf der Seite https://trendplace.de/Mazaya-Pure-BreeZ-Tabak-200gr findet sich aber nirgends für uns nachvollziehbar der Link auf https://trendplace.de/"Adalya-Cool-Tabak-200gr/" (also mit %22 bzw. " um den Produkt-Teil des Links herum), sondern nur korrekte Links auf die Produkte und eben https://trendplace.de/Adalya-Cool-Tabak-200gr

Und solche "fehlerhaften" Links mit %22 drinnen findet Google halt zu hunderten...Ich habe auch schon "Fetch as Google" ausprobiert, in den dann angezeigten Sourcen finde ich aber auch keinen einzigen der fehlerhaften Links, dadurch kann ich halt ncht mal die Stelle lokalisieren, wo Google den Link gesehen hat auf der Seite. D.h. beim aktuellen Crawlen findet er keine kaputten Links, das war nur am 16.10. (und in den tagen davor so).

Ich kann auch in unseren Templates (einige haben wir ja vom Original angepasst) keine Stellen finden, an denen so ein %22 in die URLs kommen könnte, für die Verlinkungen von anderen Artikeln wird als href immer href="$Arrtikel->cURL" ausgegeben in den entsprechenden tpl-Dateien.

-> Wir haben am 16.10. das JTL-Debug-Plugin deinstalliert, jetzt warten wir mal ob Google nach dem 16.10. immer noch solche Links findet oder nicht.

 

[hula1499]

Dieses %22 ist doch " -> hast die bei deinen Beschreibungen drinnen im Titel?

 

[djdreh]

Nein, definitiv nicht. Es geht ja auch nicht um die Beschreibung, sondern um die Links. In der Datenbank wäre das vermutlich die Spalte tArtikel->cSeo. Im template werden die Links zu anderen Produkten dann über https://trendplace.de/ + $artikel->cURL ausgegeben. Aber in der Datenbank sind überhaupt nirgends Anführungszeichen ("%22") gespeichert, weder bei URL, Name oder Beschreibung.

 

[djdreh]

Seltsam ist auch, dass es vor der Artikel-URL ein " (%22) ist, danach dann erst ein abschließender / und dann das " (%22). Auf den korrekten Seiten (praktisch alles jetzt gerade im Live- Shop, diese seltsamen URLs wurden ja noch nie echt im Browser gesehen) steht nach der Produkt-URL kein /

 

[en001]

Hast du denn beim Fetch durch Google den gerenderten Quelltext angeschaut?
Dieses Debug ist ja jetzt ausgeschaltet.

 

[djdreh]

Ja, im Fetch sehe ich auch nirgends diese Links mit %22... Es ist echt sehr seltsam. Oft sind es halt auch Seiten von Produkten, die aktuell nicht verfügbar sind, da kommt dann vom Shop ja eh ein Redirect Auf die Startseite. Und dort findet Google dann angeblich die kaputten Links, ist aber wie gesgat weder im Fetch-Source als auch in der Live-Verison nachvollziehbar.

Die Crawl-Ergebnisse sind ja auch meisten so um die 3 Tage alt, bis sie in der Console auftauchen. Das macht die Sache nicht leichter...

Debug-Plugin ist sogar deinstalliert, damit kann es also nichts zu tun haben. Wir werden es auch wieder installieren, ich brauche es zum Entwickeln...

 

[djdreh]

Das Problem hat sich jetzt nach Deinstallation des Debug-Plugins gelöst oder zumindest beruhigt.

Es kam dazu auch eine Rückmeldung von JTL: Bei aktiviertem Debug-Plugin kann es angeblich wohl sein, dass der Google-Crawler Objekte in den Debug-Daten als Links erkennt, da stehen dann teilweise die Produkt- oder Kategorie in Anführungszeichen, wie z.B. cSeo: "Produkt-xyz" oder cURL: "prodult-xyz-url"

Diese Daten werden ja aber nur an den Browser geschickt, wenn der Debug-URL-Parameter übergeben wird, zumindest war das bei uns so konfiguriert. Deshalb wundert es mich ein bisschen, wie der Crawler solche "Debug"-Seiten des Shops sehen können sollte...

Was ich festgestellt hatte: Nach dem Shop-Update auf 4.06 wurde wohl das (aktivierte) Debug-Plugin ebenfalls aktualisiert, der URL-Parameter war danach wohl der Default "jtl-debug", bei uns war er vorher auf etwas anderes gestellt. Da die 404-Probleme erst nach dem Shop-Update losgingen ist meine Vermutung, dass der Crawler irgendwoher solche Links "produkt-url?jtl-debug" hatte und diese zum Crawlen aufgerufen hatte. Das wäre zumindest eine etwas plausible Erklärung.

-> Wir haben das Debug-Plugin jetzt wieder installiert, mit einem eigenen (Google hoffentlich unbekannten) Debug-URL-Paramater konfiguriert, und beobachten die Sache mal. Nach Benutzung deaktiviere ich trotzdem jetzt immer das Plugin.

Vielleicht hilft das jemandem weiter hier...

 

[HSRpro]

Hallo, wir haben leider das gleiche, wie das ursprüngliche Problem, dass unsere Tabelle nicht übernommen wird, auch wir haben diverse Kopfzeilen probiert, leider bleibt das Problem. Hat jemand bereits eine Lösung dazu finden können?
Danke und frohe Weihnachte