OXID- Shop und 500’ter Fehler: Das unentdeckte Land.

Abbildung: Websniffer zeigt den HTTP- Header des OXID- Shops wenn wir einen Fehler provozieren.

Lange hat es gedauert, bis ich hinter den Mechanismus gekommen bin, der Fehler im OXID- Shop abfängt. Ganz in meinem SEO- Alltag lasse ich den ScreamingFrog den OXID- Shop spiedern und warte auf die Ergebnisse. Super, keine 500 (internal server errors)! Freu! Doch halt, stimmt das wirklich?

Wer OXID kennenlernt muss leider auch lernen, dass OXID in sehr vielen Fehlerszenarien einfach einen 301- Redirect auf die Startseite macht. Einziger Anhaltspunkt ist der Parameter „redirect=1“ oder „redirected=1“. So ist es wenigstens fürs Auge eines Shopbesuchers zu erkennen. Und diese Redirects bleiben für den Shopbetreiber lange Zeit unentdeckt. Es sei denn die Zunahme der 301- Redirects fällt über ein Spider- Tool auf. Auch hilft es hier wenig die Logfiles des Webservers im Auge zu behalten. Die internen Fehler kommen auch hier nicht an. OXID sendet im Fall einer Exception einen sauberen 301- Redirect– Header auf die Startseite. Einziger Anhaltspunkt ist das OXID- eigene Exception- Logfile unter /log/EXCEPTION_LOG.txt. In der zwar einzelne Fehler protokolliert werden, jedoch fehlt hier die Angabe der URL bei der der Fehler auftrat.

Kleiner Tipp am Rande: Wer dieses Verzeichnis noch nicht vor externen Zugriffen über den Webserver geschützt hat sollte dies jetzt erst einmal machen und dann weiterlesen.

Einen Redirect auf die Startseite? Ist das den gut? Was heißt das für unsere Listung bei Google?

Aus SEO- Sicht ist so ein verhalten natürlich der Supergau. Ein Fehler in der Programmierung und schon werden meine gut gelisteten URL’s mit einem 301- Redirect permanent auf die Startseite umgeleitet. Für welches Keyword soll dir Startseite den nun ranken. Ich verweise hier nur auf die Hangouts von John Müller zu den Themen „Sollte ich 404 Fehler auf die Startseite umleiten“ oder „Angenommen eine Unterseite mit einer Pressemitteilung hat hochwertige natürliche Links von Online-Zeitungen erhalten. Sollte man diese auf die Startseite per 301 umleiten oder besser nicht?“.

  1. Handelt es sich zwar um 500- Fehler, jedoch sind diese Fehler ja nicht gewollt und meine Intension ist es die indizierten URL’s im Index zu behalten.
  2. Möchte ich 301- Redirects gerne kontrolliert einsetzen.

Das bedeutet im Klartext, dass durch solch ein Fehler im Livesystem eines OXID- Shops mir meine kompletten Rankings verloren gehen können, ohne dass ich es im schlimmsten Fall merke. Und zu allem Überfluss geschieht dies dauerhaft wenn ich diese Fehler nicht zeitnah entdecke. OXID setzt an dieser Stelle ein 301- Permanent Redirect anstatt eines 302- Temporary Redirect und sorgt so dafür, dass meine gelisteten URL’s durch die URL meiner Startseite getauscht werden soll. Da natürlich die Inhalte meiner Startseite nicht mehr zu den Keywords meiner Unterseiten passen werde ich in den meisten Fällen stark an Sichtbarkeit verlieren.

Hier kann ich nur den Rat geben auf jeden Fall mit einem Test- und einem Livesystem zu arbeiten. Die Seiten regelmäßig mit ScreamingFrog zu testen und die exception_log.txt von OXID im Auge zu behalten. Wobei ich wieder bei der Überzeugung wäre „SEO besteht aus viel Wissen, viel Verständnis für die Materie und die Fähigkeit logisch zu denken aber viel viel mehr Qualitätssicherung.“

Andreas Röne
Über Andreas Röne 12 Artikel
Andreas Röne ist im Bereich Internet ein alter Hase. 1989 startete er mit der Programmierung auf einem Commodore C64 und wechselte 1993 zu seinem ersten PC. Drei Jahre später gründete er mit seinem Klassenkameraden Hasim Citak seine erste Firma in der Software entwickelt wurde. 1996/1997 entstanden die ersten Webseiten auf Basis von HTML und 1998 wurde das Geschäftsmodell in den Bereich Internet Service Provider ausgebaut. Als Testsieger unter den Providern schnitt Röne Multimedia in der Ausgabe 09/1998 der Internetworld als einziger mit der Note "Sehr gut" ab. 2004 wechselte Andreas als CTO zur s.mile DIREKT AG entwickelte die interne Warenwirtschaft und die Onlineshops. Er koordinierte die Zusammenarbeit zwischen der AG und den Lieferanten und war für den gesamten technischen Ablauf der Onlineshops verantwortlich. Bevor er 2011 das Unternehmen verließ war er noch massgeblich an den Gründungen der Tochterunternehmen s.mile DIRECT Inc. in New York und Novakartografija in Belgrad beteiligt. 2011 gründete Andreas "brainlogical Software Development" um seinem eigentlich Ziel der Softwareentwicklung nachzukommen doch Kundenaufträge aus dem Bereich Websiteentwicklung und Suchmaschinenoptimierung blieben nicht aus und so wurde dies ein größer Bestandteil. brainlogical wuchs zu einem TYPO3- Spezialisten heran und setze zahlreiche kleine und große Websites erfolgreich mit TYPO3 um. 2015 wurde aus "brainlogical Software Development" die "3B Kommunikation GmbH" die heute als Onlinemarketing- Agentur ihren Hauptsitz in Schloß Holte- Stukenbrock hat und Büros in Bielefeld und Berlin betreibt. Weitere Qualifikationen und Tätigkeiten: Google AdWords Expert, Google Analytics- zertifiziert & Dozent an der VHS.

7 Kommentare zu OXID- Shop und 500’ter Fehler: Das unentdeckte Land.

    • Hi Marco,

      für mich stellt es keinen Bug da sondern ein gewolltes Verhalten von OXID. Man kann sich drüber streiten ob es ein Bug oder Feature. Hinzu kommt, dass die besagte Installation zum Teil noch ne Enterprise V5 die von OXID eh keine Updates mehr erhält. Aber danke für die Anmerkung. Zumindest für die neueren Versionen könne man das mal anregen.

  1. Okay, nennen wir es “Issue” 🙂

    Also mir hat das Ganze keine Ruhe gelassen, und ich habe mir noch einmal alle entsprechenden Code-Stellen in einer aktuellen Enterprise Version 5.3.3 angeschaut. Ein 301 auf die Startseite passiert ausschließlich dann, wenn sich die URL ändert, weil z.B. der Titel eines Artikels geändert wurde. In dem Fall wird per 301 auf den neuen Titel “permanently redirected”.

    Im Fall fehlerhafter Module oder Templateänderungen gibt es einen sauberen Redirect auf die Startseite mit HTTP header 302. Das ist auch gewünschtes Verhalten, um im Livebetrieb den Fehler nicht anzuzeigen: Das will man weder Kunden noch Hackern zumuten 🙂

    Im Falle eines internal server errors 500 ist meist eh der komplette Shop betroffen. Dann ist oft PHP komplett abgeschmiert und kann nicht mehr in den error.log schreiben.

    Da ich nicht genau weiss, mit welcher Version genau Ihr arbeitet, kann es natürlich gut sein, dass in der Vergangenheit irgend etwas geändert wurde; allerdings finde ich dazu nichts im Bugtracker. Und es ist sicher nicht ausgeschlossen, dass eine Änderung im spezifischen Projekt, z.B. durch ein Modul, zum von Dir beschriebenen Verhalten führt.

    Noch eine Anmerkung zu den Updates:
    Für die v5 gibt es sehr wohl noch Updates, genauer gesagt für den aktuellen maintenance branch 5.3.x wie auch für den aktuellen lagacy branch 5.2.x (entspricht 4.10 und 4.9 der CE): https://oxidforge.org/en/all-releases

    Ich hoffe, ich konnte etwas Licht ins Dunkel bringen – schönes Wochenende! 😉

    • Hallo Marco,

      danke für Deinen Einsatz. Es wäre gut wenn tatsächlich etwas gegen 301- Redirect im Fehlerfall getan wurde. Jetzt kann man streiten ob es besser wäre eine Hinweisseite einzublenden oder mit 302 auf die Startseite weiter zu leiten. Aus SEO- Sicht wäre die Fehlerseite bestimmt besser. Aus Sicht des Shopbetreibers (um die Benutzerführung nicht ganz zu zerstören) die Weiterleitung auf die Startseite. Da wird man auch nie eine Einigung finden.

      Zum Thema “500’ter Fehler & PHP” kann ich Dir leider nicht so ganz beipflichten. Sehr viele Fehler werden (zum Glück) auch vom Apache geloggt. Natürlich nur, wenn das PHP-Script (wie z.B. OXID) die Exception nicht selber abfängt. (Im Prinzip ist das so ja auch richtig) Man muss dies nur wissen und die EXCEPTION_LOG.txt im Auge behalten.

      Wenn ich für OXID eine Erweiterung programmiere und ein Fehler im Controller oder Model auftritt, dann geschieht dies ja auch nur in den Shopbereichen in dehnen ich auf den Controller oder das Model zugreife. Von daher können Fehler schon sehr gut nur in Teilbereichen des Onlineshops auftauchen.

      Im Prinzip geht es mir auch darum nicht einzelne Fehler oder “komisches” Verhalten von OXID herauszuarbeiten. Mir geht es viel mehr darum Shopbetreiber und eCommerce- Manager auf solche Dinge zu sensibilisieren und aufzuzeigen auf was ggf. alles geachtet werden sollte.

      Vielen Dank auf jeden Fall für Deinen Einsatz.

  2. Ich habe jetzt web-sniffer.net auch nochmal auf den Demoshop (quasi Standardauslieferung) losgelassen mit folgendem Ergebnis:
    http://storage6.static.itmages.com/i/17/0210/h_1486754802_2544508_154342f793.png

    Kleiner Tipp am Rande auch von mir:
    Der Ordner log/ für die Log-Dateien ist per default über die .htaccess im Standardshop für Zugriffe von Aussen gesichert. Daran sollte man nicht herumspielen. Wenn Ihr es doch getan habt, kann man sich hier das Original wieder beschaffen: https://github.com/OXID-eSales/oxideshop_ce/blob/master/source/.htaccess#L51

    • Hallo Marco,

      in dem speziellen Fall hat man nachträglich den NGNIX vor den Apache gesetzt. Der NGNIX wurde so konfiguriert, dass er mit einer Condition -f statische Files direkt ausliefern kann. So wurde dann die .htaccess umgangen und das Verzeichnis /log war wieder zugänglich. 🙁

      • Hallo Andreas,

        das erklärt’s natürlich.

        Und Du sagst das im letzten Absatz schon völlig richtig: Es ist wahnsinnig wichtig, immer mit einem Staging-System und Tests zu arbeiten, am besten mit einem vorgelagerten Deployment.

        Ich bin froh, dass wir das so klären konnten 🙂

Kommentar hinterlassen

E-Mail Adresse wird nicht veröffentlicht.


*