Fehlgeschlagene Crawl-Anfragen

Ich habe keine Probleme in den letzten 90 Tagen - bin auch bei All Inkl

 

Hallo,
ich bin auch bei All-inkl. und habe ebenfalls keine Probleme. Die fehlgeschlagenen Crawl Anfragen liegen bei 0% in den letzten 90 Tagen.

Gruß Uwe

 

All-Ink Businesspaket oder shared hosting mit 100 Leuten ?

 

Habe das dahingehend bei mir auch geprüft und es sind viele "Crawling-Anfragen: Serverfehler (5xx)"

Wenn ich da einsteige und mir die Beispiele anschaue, sind das im wesentlichen Bilder.
Und zwar solche, die wir auf der Produktdetailseite, in den Zusatzfelder, anzeigen.

Diese Bilder werden in einem von uns erstellten weiteren Unterverzeichnis unter images/products_images/colour_images/ gespeichert
(Ist das ein Problem?)
Im html steht images/products_images/colour_images/bild.jpg.
(Wie bei den anderen Produktbildern auch)

In der Search Console werden diese Bilder mit Serverfehler 5xx angemeckert.

Wenn man sich den Link in der Search Console anschaut, stellt man fest das folgender Link untersucht wird:

(Link nur für registrierte Nutzer sichtbar.)de/images/products_images/colour_images/bild.jpg.

Also mit dem lang-Kürzel /de/.
(Das scheint bei den "normalen" Produktbildern dann wohl nicht der Fall zu sein?!?!)

Wenn man das im Browser aufruft bekommt man
"Absolute paths are not allowed in RelativeFilePathStringType"
Wenn man das /de/ rausnimmt wird das Bild angezeigt.

Wir zeigen an anderen Stellen im Shop auch eigene Bilder aus eigenen Unterverzeichnissen von images/content/.
Die werden alle nicht angemeckert.

Einer eine Idee, was das Problem ist, oder wie ich das umgestalten muss, damit es nicht zu diesen 5xx Fehlern in der Search Console kommt?

 

Frage an Gambio: Müsste der Zugriff auf nicht existierende Bilder nicht einen 404 (not found) anstelle eines 500 (internal server error) liefern?

(Link nur für registrierte Nutzer sichtbar.)

==> Absolute paths are not allowed in RelativeFilePathStringType

Das gleiche Problem tritt bei uns auch auf:

"gambio":"v4.8.0.2",
"phpversion":"8.1.23",

 

Für nicht-existente Bilder wird via RewriteRule in der .htaccess-Datei das Image Processing versucht anzustoßen:

Code:

    # -----------------------------------------------------------------------------
    # Image Processing on the fly
    # -----------------------------------------------------------------------------

    ## if request destination is a product image and size not bigger than 0 try to create the sized image
    RewriteCond %{REQUEST_URI} ".*?\/images\/product_images\/.*\.(?:gif|jpe?g|png)$" [NC]
    RewriteCond %{REQUEST_FILENAME} !-s
    RewriteRule (\.gif|\.jpe?g|\.png)$ %{ENV:BASE}shop.php?do=ImageRequest [L,NC]

Das Originalbild muss nicht verarbeitet werden. Und wenn es nicht existiert, kann es das auch nicht. Man kann entweder das original_images-Verzeichnis explizit ausschließen:

Code:

    # -----------------------------------------------------------------------------
    # Image Processing on the fly
    # -----------------------------------------------------------------------------

    ## if request destination is a product image and size not bigger than 0 try to create the sized image
    RewriteCond %{REQUEST_URI} ".*?\/images\/product_images\/.*\.(?:gif|jpe?g|png)$" [NC]
    RewriteCond %{REQUEST_URI} !.*images/original_images.* [NC]
    RewriteCond %{REQUEST_FILENAME} !-s
    RewriteRule (\.gif|\.jpe?g|\.png)$ %{ENV:BASE}shop.php?do=ImageRequest [L,NC]

oder die Weiterleitung nur für ausgewählte Verzeichnisse aktivieren:

Code:

    # -----------------------------------------------------------------------------
    # Image Processing on the fly
    # -----------------------------------------------------------------------------

    ## if request destination is a product image and size not bigger than 0 try to create the sized image
    RewriteCond %{REQUEST_URI} ".*?\/images\/product_images\/(option_images|gallery_images|info_images|popup_images|properties_combis_images|thumbnail_images)\/.*\.(?:gif|jpe?g|png)$" [NC]
    RewriteCond %{REQUEST_FILENAME} !-s
    RewriteRule (\.gif|\.jpe?g|\.png)$ %{ENV:BASE}shop.php?do=ImageRequest [L,NC]

@DOGS in the CITY : Die letztgenannte Anpassung sollte bei Dir auch den 500er Fehler beseitigen. Problem ist aber, dass überhaupt Bilder aus dem Sprachverzeichnis geladen werden sollen. Dieses Problem gibt's in anderen Shops auch und es ist für mich leider nicht ersichtlich, wie Google an die falschen URLs kommt. Augenscheinlich wirkt auf der Seite alles korrekt.

 

Hallo Domink,

danke für den Tip.

Das führt dann zu einem 404, bin mir nicht sicher, ob das soviel besser ist?!?

Gemäß Til von Gambio liefert der Shop keine URLS von (Produkt-)Bilder aus den images/ Ordner mit der Sprachkennung aus. Also bleibt ja nur, dass über die robots.txt auszuschließen, was aber selbst von Google, bei bereits (vermeintlich) gefundenen Links ja gerne auch mal ignoriert wird, oder das über die .htaccess in diesem Fall so umzuleiten, dass die URLS korrekt sind (also ohne Sprachkenung) und die Bilder gefunden werden.

Dass nun gerade diese (Farb-) Bilder von Google indiziert werden, wäre mir eigentlich nicht so wichtig, aber von Google auf eine hohe Fehlerrate des Servers hingewiesen zu werden, scheint mir nicht erstrebenswert.