So pruefen Sie den technischen Zustand Ihres PrestaShop-Shops in 30 Minuten

Warum regelmaessige technische Audits wichtig sind

PrestaShop-Shops verschlechtern sich mit der Zeit. Module werden installiert und vergessen. PHP-Versionen fallen zurueck. Fehlerprotokolle fuellen sich mit Warnungen, die niemand liest. Datenbanktabellen blaehen sich auf mit Daten aus abgebrochenen Warenkoerben und abgelaufenen Sitzungen. Sicherheitspatches werden nicht angewendet. Jedes dieser Probleme ist fuer sich genommen klein, aber zusammen fuehren sie zu langsamen Seitenladezeiten, Sicherheitsluecken und letztlich zu Ausfallzeiten oder Datenverlust.

Das Problem ist, dass die meisten Shopbetreiber diese Probleme erst entdecken, wenn etwas kaputtgeht. Ein Kunde beschwert sich ueber einen langsamen Checkout. Google stuft Ihre Rankings herab, weil Ihre Website die Core Web Vitals nicht besteht. Oder schlimmer noch: Sie entdecken, dass Ihr Admin-Panel kompromittiert wurde, weil Sie nie den Standard-Admin-Pfad geaendert haben und Ihre PHP-Version eine bekannte Sicherheitsluecke hatte.

Ein 30-minuetiges technisches Gesundheits-Audit, monatlich durchgefuehrt, verhindert all dies. Es ist kein tiefer Tauchgang in jede Konfigurationseinstellung. Es ist eine fokussierte Checkliste, die die haeufigsten und gefaehrlichsten Probleme erkennt, bevor sie zu Notfaellen werden. Dieser Leitfaden fuehrt durch jede Pruefung mit ungefaehren Zeitschaetzungen und gibt Ihnen einen wiederholbaren Prozess, dem Sie jeden Monat folgen koennen.

Pruefung 1: PHP-Version und Konfiguration (3 Minuten)

PHP ist der Motor, der PrestaShop antreibt, und eine veraltete Version zu verwenden ist sowohl ein Leistungs- als auch ein Sicherheitsrisiko. PHP-Versionen erhalten zwei Jahre aktiven Support und ein weiteres Jahr Sicherheitsupdates. Danach bleiben bekannte Sicherheitsluecken ungepatcht.

PHP-Version pruefen

Gehen Sie in Ihr PrestaShop Back Office und navigieren Sie zu Erweiterte Einstellungen > Informationen. Die PHP-Version ist im Abschnitt Server-Informationen aufgefuehrt. Alternativ koennen Sie sie in Ihrem Hosting-Kontrollpanel (cPanel, Plesk oder aehnlich) pruefen.

Stand 2026 sind die aktiv unterstuetzten PHP-Versionen 8.2, 8.3 und 8.4. Wenn Sie PHP 8.1 oder aelter verwenden, sollte ein Upgrade Prioritaet haben. PrestaShop 8.x erfordert PHP 7.2 oder hoeher, performt aber deutlich besser mit PHP 8.1 und hoeher. PrestaShop 1.7.x unterstuetzt PHP 7.1 bis 8.1, abhaengig von der spezifischen Version.

Wichtige PHP-Einstellungen ueberpruefen

Pruefen Sie auf der Informationsseite diese PHP-Konfigurationswerte:

memory_limit sollte mindestens 256M fuer PrestaShop betragen. Wenn es niedriger ist, koennen bei der Verarbeitung grosser Kataloge oder der Erstellung von Berichten weisse Seiten oder unvollstaendige Operationen auftreten.

max_execution_time sollte mindestens 300 (5 Minuten) betragen. Niedrigere Werte koennen Timeouts bei Importvorgaengen, Cache-Neuaufbauten und Modulinstallationen verursachen.

upload_max_filesize und post_max_size sollten mindestens 16M betragen, oder hoeher, wenn Sie regelmaessig grosse Produktbilder oder Importdateien hochladen.

OPcache sollte aktiviert sein. OPcache speichert kompilierten PHP-Code im Arbeitsspeicher und reduziert die Seitenladezeiten dramatisch. Wenn es deaktiviert ist, laeuft Ihr Shop deutlich langsamer als er koennte.

Pruefung 2: Fehlerprotokoll-Ueberpruefung (4 Minuten)

Fehlerprotokolle zeigen Ihnen, was hinter den Kulissen kaputtgeht, selbst wenn das Frontend normal zu funktionieren scheint. Warnungen und Hinweise, die die Seite nicht zum Absturz bringen, deuten dennoch auf Probleme hin, die Serverressourcen verschwenden und sich zu echten Ausfaellen entwickeln koennen.

PrestaShop-Protokolle

Gehen Sie im Back Office zu Erweiterte Einstellungen > Protokolle. Sortieren Sie nach Datum (neueste zuerst) und scannen Sie die Eintraege der letzten Woche. Konzentrieren Sie sich auf Schweregrad 3 (Fehler) und Schweregrad 4 (Kritisch). Haeufige kritische Fehler umfassen Datenbankverbindungsfehler, Dateiberechtigungsfehler, Modul-Ausnahmen und Zahlungsverarbeitungsfehler.

Wenn Sie wiederholt Fehler vom selben Modul sehen, hat dieses Modul einen Bug, der Aufmerksamkeit erfordert. Wenn Sie Datenbankfehler sehen, gehen Ihrem Datenbankserver moeglicherweise die Verbindungen oder der Speicherplatz aus.

PHP-Fehlerprotokoll

Der Speicherort des PHP-Fehlerprotokolls haengt von Ihrer Hosting-Umgebung ab. Gaengige Speicherorte sind /var/log/php/error.log, /var/log/apache2/error.log oder ein in Ihrem Hosting-Kontrollpanel angegebener Pfad. Ueberpruefen Sie die letzten 100 Zeilen auf schwerwiegende Fehler, Warnungen und Veralterungshinweise.

Veralterungshinweise sind besonders wichtig zu verfolgen. Sie warnen Sie, dass eine Funktion oder ein Feature, das Ihr Code verwendet, in einer zukuenftigen PHP-Version entfernt wird. Diese jetzt zu beheben verhindert, dass Ihr Shop beim naechsten PHP-Upgrade kaputtgeht.

Was mit Fehlern tun

Versuchen Sie nicht, jeden Fehler waehrend des Audits zu beheben. Das Audit dient der Identifizierung. Erstellen Sie eine Liste der kritischsten und haeufigsten Fehler, priorisiert nach Schweregrad. Schwerwiegende und kritische Fehler erfordern sofortige Aufmerksamkeit. Warnungen sollten innerhalb des Monats behoben werden. Hinweise und Veralterungswarnungen koennen fuer Ihr naechstes Wartungsfenster eingeplant werden.

Pruefung 3: Modul-Audit (5 Minuten)

Module sind die haeufigste Quelle von Sicherheitsluecken, Leistungsproblemen und Kompatibilitaetsproblemen in PrestaShop. Ein schnelles Modul-Audit identifiziert toten Ballast und potenzielle Risiken.

Ungenutzte Module identifizieren

Gehen Sie zu Module > Modul-Manager. Suchen Sie nach Modulen, die installiert, aber deaktiviert sind. Diese Module haben immer noch Dateien auf Ihrem Server und moeglicherweise Datenbanktabellen, aber sie erfuellen keinen Zweck. Sie vergroessern Ihre Angriffsflaeche (eine Sicherheitsluecke in den Dateien eines deaktivierten Moduls kann dennoch ausgenutzt werden) und verlangsamen Backups.

Entscheiden Sie fuer jedes deaktivierte Modul, ob Sie es wieder verwenden werden. Wenn nicht, deinstallieren Sie es vollstaendig (nicht nur deaktivieren). Die Deinstallation entfernt die Datenbanktabellen und die Konfiguration des Moduls. Loeschen Sie nach der Deinstallation auch das Modulverzeichnis aus /modules/, um seine Dateien vollstaendig vom Server zu entfernen.

Updates pruefen

Suchen Sie im Modul-Manager nach Modulen mit verfuegbaren Updates. Veraltete Module sind ein primaerer Angriffsvektor fuer Sicherheitsexploits. Update-Benachrichtigungen erscheinen als Badges in der Modulliste. Priorisieren Sie Updates fuer Module, die sensible Daten verarbeiten: Zahlungsmodule, Kundenkonto-Module und jedes Modul, das Formulare verarbeitet.

Bevor Sie ein Modul aktualisieren, pruefen Sie das Changelog, um zu verstehen, was sich geaendert hat. Wenn das Update Sicherheitsbehebungen enthaelt, wenden Sie es sofort an. Wenn es ein Feature-Update ist, testen Sie es zuerst in einer Staging-Umgebung, wenn moeglich.

Gesamtzahl der Module zaehlen

Pruefen Sie, wie viele Module insgesamt installiert sind. PrestaShop wird standardmaessig mit vielen Modulen ausgeliefert, und Shops sammeln im Laufe der Zeit weitere an. Jedes aktive Modul fuegt Hooks hinzu, die bei jedem Seitenaufruf ausgefuehrt werden, was die Antwortzeit erhoeht. Wenn Sie mehr als 80 bis 100 aktive Module haben, ueberpruefen Sie die Liste kritisch. Viele Standard-PrestaShop-Module (wie Social-Sharing-Buttons, Datenschutzhinweise und Statistik-Module) koennen deaktiviert werden, wenn Sie sie nicht verwenden, was zu messbaren Leistungsverbesserungen fuehrt.

Pruefung 4: Datenbankgesundheit (4 Minuten)

Ihre PrestaShop-Datenbank waechst kontinuierlich. Jeder Kundenbesuch erzeugt Sitzungsdaten. Jeder abgebrochene Warenkorb bleibt in der Datenbank. Jeder Protokolleintrag sammelt sich an. Ueber Monate und Jahre verlangsamt diese Aufblaehung Abfragen und erhoeht Backup-Zeiten.

Datenbankgroesse pruefen

Pruefen Sie in Ihrem Hosting-Kontrollpanel (cPanel > phpMyAdmin, zum Beispiel) die Gesamtgroesse der Datenbank. Eine gesunde PrestaShop-Datenbank fuer einen kleinen bis mittleren Shop (unter 10.000 Produkte) sollte unter 500 MB liegen. Wenn Ihre deutlich groesser ist, ist Datenaufblaehung wahrscheinlich die Ursache.

Grosse Tabellen identifizieren

Klicken Sie in phpMyAdmin auf Ihre Datenbank und sortieren Sie die Tabellen nach Groesse. Die ueblichen Verdaechtigen fuer Aufblaehung sind: ps_connections und ps_connections_page (Besucherverfolgungsdaten, die auf Gigabytes anwachsen koennen), ps_log (PrestaShops internes Protokoll), ps_mail (E-Mail-Verlauf), ps_cart und ps_cart_product (Daten abgebrochener Warenkoerbe), ps_guest (anonyme Besuchereintraege) und ps_pagenotfound (404-Fehlerverfolgung).

Diese Tabellen koennen sicher von alten Daten bereinigt werden. Zum Beispiel benoetigen Sie keine Verbindungsdaten von vor zwei Jahren. PrestaShop hat eine eingebaute Funktion zur Bereinigung einiger dieser Tabellen: Gehen Sie zu Erweiterte Einstellungen > Administration und suchen Sie nach den Datenbereinigungsoptionen. Fuer eine gruendlichere Bereinigung kann das kostenlose Modul PrestaShop Cleaner alte Statistikdaten, abgebrochene Warenkoerbe und abgelaufene Sitzungen loeschen.

Fehlende Indizes pruefen

Waehrend Sie in phpMyAdmin sind, pruefen Sie die Struktur Ihrer wichtigsten Tabellen (ps_product, ps_category_product, ps_stock_available) und verifizieren Sie, dass Indizes auf den Spalten existieren, die bei Suche und Filterung verwendet werden. Fehlende Indizes verursachen langsame Abfragen, die die Seitenladezeiten beeinflussen. Fuegen Sie jedoch keine Indizes hinzu, ohne die Kompromisse zu verstehen, da jeder Index Schreiboperationen geringfuegig verlangsamt.

Pruefung 5: Sicherheitsgrundlagen (5 Minuten)

Sicherheitsluecken in PrestaShop-Shops werden aktiv ausgenutzt. Automatisierte Scanner durchsuchen kontinuierlich das Internet nach verwundbaren Installationen. Fuenf Minuten Sicherheitspruefungen koennen einen katastrophalen Einbruch verhindern.

Admin-Panel-URL

Ihr Admin-Panel sollte nicht ueber eine vorhersehbare URL wie /admin/ oder /backoffice/ erreichbar sein. PrestaShop generiert waehrend der Installation einen zufaelligen Admin-Verzeichnisnamen (wie /admin738xyz/). Ueberpruefen Sie, ob Ihre Admin-URL weiterhin zufaellig ist, indem Sie den Admin-Verzeichnisnamen auf Ihrem Server kontrollieren. Wenn jemand ihn in etwas Erratbares umbenannt hat, benennen Sie ihn zurueck in eine zufaellige Zeichenfolge.

SSL-Zertifikat

Ihr gesamter Shop muss ueber HTTPS laufen. Pruefen Sie dies, indem Sie die URL Ihres Shops mit http:// aufrufen und verifizieren, dass es auf https:// umleitet. Gehen Sie im Back Office zu Shopeinstellungen > Allgemein und ueberpruefen Sie, dass "SSL aktivieren" und "SSL auf allen Seiten aktivieren" beide auf Ja gesetzt sind.

Pruefen Sie auch das Ablaufdatum Ihres SSL-Zertifikats. Let's Encrypt-Zertifikate laufen alle 90 Tage ab und sollten sich automatisch erneuern, aber die automatische Erneuerung scheitert oefter still, als man erwarten wuerde. Klicken Sie auf das Schloss-Symbol in der Adressleiste Ihres Browsers, um die Zertifikatsdetails und das Ablaufdatum zu sehen. Wenn es innerhalb der naechsten 30 Tage ablaeuft, ueberpruefen Sie, ob die automatische Erneuerung konfiguriert ist und funktioniert.

Dateiberechtigungen

Falsche Dateiberechtigungen sind ein Sicherheitsrisiko. Auf Linux-Servern sollten Ihre PrestaShop-Dateien generell dem Webserver-Benutzer gehoeren (typischerweise www-data oder apache) und diese Berechtigungen haben: Verzeichnisse mit 755 (Eigentuemer kann lesen/schreiben/ausfuehren, andere koennen lesen/ausfuehren), Dateien mit 644 (Eigentuemer kann lesen/schreiben, andere koennen lesen), und Konfigurationsdateien wie config/settings.inc.php oder app/config/parameters.php mit 640 oder 440 (eingeschraenkter Lesezugriff).

Ueberpruefen Sie einige kritische Dateien, um sicherzustellen, dass die Berechtigungen nicht zu offen sind. Keine Datei sollte 777 (weltbeschreibbar) sein. Wenn Sie 777-Berechtigungen finden, beheben Sie sie sofort. Sie erlauben jedem Benutzer auf dem Server, diese Dateien zu aendern.

Debug-Modus

Stellen Sie sicher, dass der Debug-Modus auf Ihrem Produktiv-Shop deaktiviert ist. Der Debug-Modus zeigt Besuchern detaillierte Fehlermeldungen, Dateipfade und Datenbankabfragen, was wertvolle Informationen fuer Angreifer darstellt. Pruefen Sie die Datei /config/defines.inc.php und stellen Sie sicher, dass _PS_MODE_DEV_ auf false gesetzt ist. In PrestaShop 8.x pruefen Sie auch die .env-Datei auf die Einstellung APP_DEBUG.

Bekannte Sicherheitsluecken

Pruefen Sie, ob Ihre PrestaShop-Version bekannte Sicherheitsluecken aufweist. Besuchen Sie die PrestaShop-Sicherheitshinweisseite und vergleichen Sie die aufgefuehrten Versionen mit Ihrer. Wenn Ihre Version von einem Hinweis betroffen ist, den Sie nicht gepatcht haben, priorisieren Sie die Anwendung des Fixes.

Pruefung 6: Schneller Performance-Test (4 Minuten)

Performance beeinflusst direkt die Konversionsraten. Jede zusaetzliche Sekunde Seitenladezeit reduziert die Konversionen messbar. Ein schneller Performance-Test identifiziert groessere Engpaesse.

Lighthouse-Audit durchfuehren

Oeffnen Sie Google Chrome, navigieren Sie zur Startseite Ihres Shops, oeffnen Sie die Chrome DevTools (F12) und klicken Sie auf den Lighthouse-Tab. Fuehren Sie ein Audit fuer Performance, Best Practices und SEO auf einem Mobilgeraet durch. Der Test dauert etwa 30 Sekunden.

Konzentrieren Sie sich auf den Performance-Score. Ein Score unter 50 deutet auf ernsthafte Performance-Probleme hin. Zwischen 50 und 89 bedeutet, dass es Verbesserungspotenzial gibt. Ueber 90 ist gut. Der Audit-Bericht zeigt spezifische Probleme und Schaetzungen, wie viel Zeit jede Behebung einsparen wuerde.

Wichtige Metriken pruefen

Achten Sie im Lighthouse-Bericht auf den Largest Contentful Paint (LCP), der misst, wie lange es dauert, bis der Hauptinhalt erscheint. Er sollte unter 2,5 Sekunden liegen. First Input Delay (FID) oder Interaction to Next Paint (INP) misst die Reaktionsfaehigkeit. Er sollte unter 200 Millisekunden liegen. Cumulative Layout Shift (CLS) misst die visuelle Stabilitaet. Er sollte unter 0,1 liegen.

Wenn der LCP hoch ist, sind die haeufigsten Ursachen in PrestaShop nicht optimierte Bilder (grosse Produktbilder ohne Komprimierung oder ordnungsgemaesse Groessenanpassung), langsame Serverantwortzeit (pruefen Sie Ihren Hosting-Plan und die Datenbankleistung), render-blockierendes CSS und JavaScript (deaktivieren Sie unnoetige Module, die ihre Assets auf jeder Seite laden) und deaktiviertes Caching (Smarty-Cache und CCC sollten in der Produktion aktiviert sein).

Cache-Konfiguration pruefen

Gehen Sie im Back Office zu Erweiterte Einstellungen > Leistung. Ueberpruefen Sie diese Einstellungen: Smarty-Cache sollte auf Ja stehen, mit dem Cache-Typ "Datei". CCC (Combine, Compress, Cache) sollte CSS- und JavaScript-Minifizierung und -Zusammenfuehrung aktiviert haben. Die Template-Kompilierung sollte auf "Templates neu kompilieren, wenn Dateien aktualisiert wurden" eingestellt sein (nicht "Kompilierung erzwingen", was nur fuer die Entwicklung gedacht ist).

Wenn eine dieser Einstellungen falsch konfiguriert ist, bietet deren Korrektur eine sofortige und spuerbare Leistungsverbesserung.

Pruefung 7: SEO-Grundlagen (3 Minuten)

Technische SEO-Probleme verhindern, dass Suchmaschinen Ihren Shop ordnungsgemaess crawlen und indexieren. Ein paar schnelle Pruefungen erfassen die wirkungsvollsten Probleme.

Robots.txt

Besuchen Sie ihredomain.de/robots.txt in Ihrem Browser. Ueberpruefen Sie, ob sie existiert und sinnvolle Regeln enthaelt. PrestaShop generiert automatisch eine robots.txt-Datei. Pruefen Sie, dass sie keine wichtigen Seiten blockiert. Ihre Produktseiten, Kategorieseiten und CMS-Seiten sollten nicht gesperrt sein. Haeufige Fehler sind das Blockieren aller URLs mit Parametern (was gefilterte Kategorieseiten und Suchergebnisse blockiert) und das Blockieren des /modules/-Verzeichnisses (was verhindern kann, dass CSS und JavaScript von Suchmaschinen-Renderern geladen werden).

Ueberpruefen Sie ausserdem, ob die robots.txt eine Sitemap-Anweisung enthaelt, die auf Ihre XML-Sitemap verweist: Sitemap: https://www.ihredomain.de/1_index_sitemap.xml.

XML-Sitemap

Besuchen Sie die in Ihrer robots.txt aufgefuehrte Sitemap-URL. Ueberpruefen Sie, ob sie laedt, ob sie aktuell ist (pruefen Sie die letzten Aenderungsdaten) und ob sie Ihre wichtigen Seiten enthaelt. Wenn die Sitemap veraltet oder leer ist, regenerieren Sie sie. Wenn Sie den eingebauten PrestaShop-Sitemap-Generator verwenden, gehen Sie zu Module > Modul-Manager, suchen Sie das Google Sitemap-Modul und klicken Sie auf Konfigurieren, um es zu regenerieren.

Pruefen Sie die Anzahl der URLs in der Sitemap gegen Ihre erwartete Anzahl. Wenn Sie 1.000 Produkte haben, aber die Sitemap nur 200 URLs auflistet, stimmt etwas mit dem Generierungsprozess nicht. Haeufige Ursachen sind deaktivierte oder nicht vorraetige Produkte, die von der Sitemap ausgeschlossen werden, Kategoriesichtbarkeitseinstellungen, die Produkte herausfiltern, und der Sitemap-Generierungsprozess, der vor der Fertigstellung abbricht.

Kanonische URLs

Besuchen Sie einige Produktseiten und betrachten Sie den Quelltext (Strg+U). Suchen Sie nach dem <link rel="canonical">-Tag im Head-Bereich. Es sollte die saubere URL der aktuellen Seite ohne Abfrageparameter enthalten. Wenn kanonische Tags fehlen oder falsch sind, schaedigen Duplicate-Content-Probleme Ihre SEO. Gehen Sie im Back Office zu Shopeinstellungen > Traffic & SEO und ueberpruefen Sie, ob "Apaches MultiViews-Option deaktivieren" und "Apaches mod_security-Modul deaktivieren" fuer Ihren Server korrekt konfiguriert sind.

Pruefung 8: Backup-Verifizierung (3 Minuten)

Backups, die nie getestet wurden, sind keine Backups. Sie sind Wunschdenken. Diese Pruefung verifiziert, dass Ihr Backup-System tatsaechlich funktioniert.

Aktualitaet des Backups pruefen

Ermitteln Sie, wo Ihre Backups gespeichert werden. Dies variiert je nach Hosting-Anbieter. Pruefen Sie Ihr Hosting-Kontrollpanel auf Backup-Tools (cPanel hat einen Backup-Bereich, Plesk hat einen Backup-Manager). Wenn Sie ein Backup-Modul in PrestaShop verwenden, pruefen Sie dessen Konfiguration und das aktuelle Backup-Protokoll.

Ihr aktuellstes Backup sollte fuer aktive Shops nicht aelter als 24 Stunden sein. Wenn Ihr letztes Backup aelter als eine Woche ist, ist Ihr Backup-System entweder nicht konfiguriert, laeuft nicht oder scheitert still. Beheben Sie dies sofort. Datenverlust durch einen Serverausfall oder Hack ohne ein aktuelles Backup kann geschaeftsbedrohend sein.

Backup-Vollstaendigkeit ueberpruefen

Ein vollstaendiges PrestaShop-Backup umfasst die gesamte Datenbank (alle Tabellen, nicht nur Produktdaten) und das Dateisystem (alle PrestaShop-Dateien, einschliesslich hochgeladener Bilder, Moduldateien und Theme-Anpassungen). Viele Backup-Loesungen erfassen nur die Datenbank oder nur die Dateien. Ueberpruefen Sie, ob Ihre beides erfasst.

Pruefen Sie die Backup-Dateigroessen. Ein Datenbank-Backup fuer einen kleinen Shop sollte mindestens mehrere Megabyte gross sein. Wenn es verdaechtig klein ist (unter 1 MB fuer einen aktiven Shop), koennte es leer oder beschaedigt sein. Ein Datei-Backup sollte Ihr /img/-Verzeichnis enthalten, das typischerweise das groesste Verzeichnis ist und bei Shops mit vielen Produktbildern mehrere Gigabyte umfassen kann.

Offsite-Backup-Speicherung

Backups, die auf demselben Server wie Ihr Shop gespeichert sind, sind denselben Ausfaellen ausgesetzt. Wenn die Festplatte des Servers ausfaellt, verlieren Sie sowohl den Shop als auch das Backup. Ueberpruefen Sie, ob Ihre Backups an einen separaten Ort kopiert werden: einen anderen Server, Cloud-Speicher (wie Amazon S3, Google Cloud Storage oder Dropbox) oder auf einen lokalen Computer heruntergeladen werden.

Pruefung 9: Update-Status (2 Minuten)

Veraltete Software zu betreiben ist der haeufigste Grund, warum PrestaShop-Shops gehackt werden. Diese letzte Pruefung ueberprueft, ob Ihre Core-Installation und kritische Module auf dem neuesten Stand sind.

PrestaShop Core-Version

Pruefen Sie Ihre aktuelle PrestaShop-Version in der Fusszeile des Back Office oder auf der Seite Erweiterte Einstellungen > Informationen. Vergleichen Sie sie mit der neuesten stabilen Version auf der PrestaShop-Website oder der GitHub-Releases-Seite. Wenn Sie mehr als eine Minor-Version hinterherhinken (zum Beispiel 8.1.2 verwenden, waehrend 8.1.5 verfuegbar ist), planen Sie ein Update. Wenn Sie eine Version mit bekannten Sicherheitsluecken verwenden, aktualisieren Sie dringend.

PrestaShop-Major-Version-Upgrades (wie 1.7 auf 8.x) sind komplexe Migrationsprojekte, keine einfachen Updates. Versuchen Sie diese nicht ohne gruendliche Planung und Tests. Minor-Version-Updates (wie 8.1.2 auf 8.1.5) sind jedoch generell sicher und enthalten hauptsaechlich Sicherheits- und Fehlerbehebungen.

Kritische Modul-Updates

Einige Module verarbeiten sensible Operationen und muessen aktuell gehalten werden: Zahlungsmodule (jedes Modul, das Kreditkarten, PayPal oder andere Zahlungsmethoden verarbeitet), das PrestaShop Autoupgrade-Modul (fuer Core-Updates verwendet) und alle sicherheitsrelevanten Module. Pruefen Sie den Modul-Manager auf verfuegbare Updates fuer diese spezifischen Module.

Zusammenfassung der 30-Minuten-Audit-Checkliste

Hier ist die vollstaendige Checkliste mit Zeiteinteilungen, der Sie jeden Monat folgen koennen:

Minuten 1-3: PHP-Version und Konfiguration. PHP-Version ist unterstuetzt pruefen. memory_limit, max_execution_time und OPcache-Status verifizieren.

Minuten 4-7: Fehlerprotokoll-Ueberpruefung. PrestaShop-Protokolle auf Eintraege mit Schweregrad 3 und 4 scannen. PHP-Fehlerprotokoll auf schwerwiegende Fehler und Veralterungshinweise pruefen. Wiederkehrende Fehler fuer Nachverfolgung notieren.

Minuten 8-12: Modul-Audit. Deaktivierte Module ueberpruefen und ungenutzte deinstallieren. Verfuegbare Updates pruefen, insbesondere bei Zahlungs- und Sicherheitsmodulen. Gesamtzahl aktiver Module zaehlen und Kandidaten fuer die Entfernung identifizieren.

Minuten 13-16: Datenbankgesundheit. Gesamtgroesse der Datenbank pruefen. Aufgeblaehte Tabellen identifizieren. Bereinigung alter Verbindungs-, Protokoll- und Warenkorbdaten planen.

Minuten 17-21: Sicherheitsgrundlagen. Admin-URL ist zufaellig verifizieren. SSL-Zertifikat und Ablaufdatum pruefen. Dateiberechtigungen verifizieren. Debug-Modus ist deaktiviert bestaetigen. Bekannte Sicherheitsluecken Ihrer Version pruefen.

Minuten 22-25: Schneller Performance-Test. Lighthouse-Audit auf der Startseite durchfuehren. LCP-, INP- und CLS-Metriken pruefen. Cache- und CCC-Einstellungen im Back Office verifizieren.

Minuten 26-28: SEO-Grundlagen. robots.txt auf Fehler pruefen. Sitemap ist aktuell und vollstaendig verifizieren. Kanonische URLs auf Produktseiten stichprobenartig pruefen.

Minuten 29-30: Backup und Updates. Aktualitaet und Vollstaendigkeit des Backups verifizieren. PrestaShop Core- und kritische Modulversionen mit den neuesten Veroeffentlichungen vergleichen.

Dieses Audit behebt keine Probleme. Es identifiziert sie. Nach Abschluss der Checkliste sollten Sie eine priorisierte Liste von Problemen haben, die behoben werden muessen. Kritische Sicherheitsprobleme und defekte Funktionalitaet stehen an erster Stelle. Performance-Optimierungen und Bereinigungsaufgaben kommen an zweiter Stelle. Kleinere Verbesserungen und Zukunftsplanung an dritter Stelle. Indem Sie dieses Audit monatlich durchfuehren, erkennen Sie Probleme frueh, behalten ein klares Bild des technischen Zustands Ihres Shops und vermeiden die unangenehmen Ueberraschungen, die durch Monate vernachlaessigter Wartung entstehen.