PrestaShop-Migration ohne Verlust von Umsatz und Rankings

Wenn Sie hier gelandet sind, steht bei Ihnen eine PrestaShop-Migration an – und Sie möchten verhindern, dass am Montag das Telefon klingelt und Sie den Lieblingssatz jedes E-Commerce-Managers hören: „Der Shop lädt nicht.“ Ich zeige Ihnen, wie wir das in echten Projekten machen, mit den Details, die in YouTube-Tutorials kaum jemand erwähnt.

Ob Sie den Hoster wechseln, zwei Shops zusammenführen, auf PrestaShop 8 aktualisieren oder einfach die Domain umziehen: Der Prozess hat mehrere Ebenen – Dateien, Datenbank, Konfiguration, Zahlungsmodule, Versanddienstleister und, am heikelsten, SEO. Wer auch nur eine davon überspringt, bekommt verlorene Bestellungen, 500-Fehler und mit etwas Glück nur eine Standpauke vom Marketingleiter.

Diese Anleitung richtet sich an Shops, die in Spanien verkaufen und echte Volumen haben – vom KMU mit 200 Bestellungen im Monat bis zu B2B-Projekten mit 30.000 Artikeln im Katalog. Sie erfahren, in welcher Reihenfolge Sie vorgehen, welche Tools Sie nutzen und wo die Fallen liegen, von denen kaum jemand erzählt.

Vor der PrestaShop-Migration: Was Sie entscheiden müssen

Bevor Sie irgendetwas anfassen, nehmen Sie sich zehn Minuten, um den Umfang zu klären. Ein PrestaShop-Umzug auf einen anderen Server mit gleicher Version und Domain ist etwas ganz anderes, als den Umzug gleich für ein Update von 1.7.8 auf PrestaShop 8.x zu nutzen. Jede Kombination hat ihr eigenes Risiko.

Vier Fragen, die Ärger ersparen

• Wechseln Sie die Version? Ein Sprung von 1.7 auf 8 ist keine Migration, sondern ein Projekt. Sie müssen jedes Modul einzeln prüfen und fast sicher das Theme anpassen.
• Wechseln Sie die Domain? Dann richten Sie die 301-Weiterleitungen ein, bevor Sie die DNS-Einträge ändern.
• Unterstützt der neue Hoster Ihren Stack? PHP 8.1+, MySQL 5.7 oder MariaDB 10.3+, Erweiterungen wie GD, intl, zip, soap …
• Haben Sie ein echtes Wartungsfenster? Im B2C gehen in den frühen Morgenstunden von Dienstag bis Donnerstag meist die wenigsten Bestellungen ein. Vorsicht bei Sonntagen: In manchen Nischen schießen dann die Verkäufe nach oben.

Mit den Jahren lernt man: Die Entscheidung, was migriert wird und was zurückbleibt, ist genauso wichtig wie das Wie. Nutzen Sie den Umzug, um ausgelistete Produkte, verwaiste Kategorien und die 47 Module aufzuräumen, die Sie „zum Testen“ installiert und nie wieder geöffnet haben. Je weniger Ballast Sie mitnehmen, desto schneller läuft der neue Shop.

Bei einem sehr großen Katalog oder ERP-Anbindungen lohnt es sich, für den Umstellungs- und Rückfallplan eine auf PrestaShop spezialisierte Agentur hinzuzuziehen. Bei einem Shop mit 30 Artikeln kann man improvisieren, bei 30.000 nicht.

Vollständiges Backup: die Lebensversicherung des Umzugs

Das ist nicht verhandelbar. Bevor Sie PrestaShop umziehen, brauchen Sie zwei vollständige Kopien an verschiedenen Orten: eine auf Ihrem Rechner und eine in einem externen Speicher (Drive, Dropbox Business, S3 – was auch immer Sie nutzen). Wenn etwas schiefgeht, können Sie damit ohne Tränen zurück.

Was das Backup enthalten muss

1. Alle Dateien aus dem Stammverzeichnis: /admin, /modules, /themes, /img, /upload, /download sowie die Konfigurationsdateien (app/config/parameters.php oder je nach Version die ältere config/settings.inc.php).
2. Ein komprimierter SQL-Dump der Datenbank. Ist sie groß, nutzen Sie mysqldump per SSH statt phpMyAdmin, das bei großen Katalogen hängen bleibt.
3. Eine Liste der aktiven Module mit ihren Versionen. Ein Screenshot aus dem Backoffice reicht.
4. Die Serverkonfiguration: PHP-Version, Limits (memory_limit, max_execution_time, upload_max_filesize), Cronjobs und eigene .htaccess-Regeln.

Ein Backup, dessen Wiederherstellung Sie nie getestet haben, ist kein Backup, sondern nur eine große Datei, die Platz belegt.

Ich empfehle, die Kopie vorab in einer Staging-Umgebung wiederherzustellen. Startet der Shop dort mit den Backup-Daten, wissen Sie, dass die Kopie funktioniert. Startet er nicht, finden Sie das besser jetzt heraus als um drei Uhr morgens am Tag der Migration.

Neuen Server vorbereiten und Dateien übertragen

Mit dem Backup in der Hand bereiten Sie das Ziel vor. Wenn Sie den Hoster für PrestaShop wechseln, achten Sie darauf, dass der neue Anbieter SSH-Zugang und Cronjobs erlaubt und sein Panel keine PHP-Funktionen sperrt, die PrestaShop braucht (exec, in manchen Fällen shell_exec für Wartungsaufgaben).

Dateien effizient übertragen

Vergessen Sie, 12 GB Datei für Datei per FTP hochzuladen. Packen Sie alles per SSH auf dem Quellserver in ein einziges .tar.gz, übertragen Sie es mit rsync oder scp auf den neuen Server und entpacken Sie es dort. Das dauert Minuten statt Stunden und erspart Ihnen die typischen beschädigten Dateien durch Timeouts.

Rechte und Eigentümer

Nach dem Entpacken setzen Sie die Rechte. Die übliche Regel: 755 für Ordner, 644 für Dateien, Eigentümer ist der Benutzer des Webservers (meist www-data oder der cPanel-Benutzer). Wenn Sie diesen Schritt auslassen, sehen Sie tagelang Fehler wie „/var/cache ist nicht beschreibbar“.

Datenbank

Legen Sie die neue, leere Datenbank an, importieren Sie das SQL und aktualisieren Sie die Zugangsdaten in app/config/parameters.php (PrestaShop 1.7+) oder config/settings.inc.php (1.6). Bei einem Domainwechsel müssen Sie die URLs in den Tabellen ps_shop_url und ps_configuration anpassen (Schlüssel PS_SHOP_DOMAIN und PS_SHOP_DOMAIN_SSL). Ein falsches UPDATE macht den Shop hier unerreichbar – also Vorsicht mit dem WHERE.

Meine Empfehlung: Arbeiten Sie mit einer temporären Subdomain wie neu.ihrshop.de, bis alles läuft, und leiten Sie erst dann die echte Domain um.

Module, Zahlungsanbieter und die Probleme, vor denen Sie niemand warnt

Hier fangen die meisten Migrationen an zu knirschen. Module sind die größte Stärke von PrestaShop und zugleich das größte Kopfzerbrechen. In einem durchschnittlichen Shop sind 40 bis 80 installiert, und mindestens 20 % davon sind inkompatibel, verwaist oder haben eine abgelaufene Lizenz.

Die Reihenfolge, die funktioniert

1. Leeren Sie den gesamten Cache im Backoffice der neuen Umgebung (Erweiterte Einstellungen > Leistung).
2. Gehen Sie die Modulliste durch und deaktivieren Sie alles, was Sie nicht nutzen. Jedes aktive Modul ist eine mögliche Fehlerquelle.
3. Installieren Sie die kritischen Module einzeln neu: Zahlungsanbieter (Redsys, Stripe, Bizum), Versanddienstleister (SEUR, MRW, GLS, Correos Express) sowie Schnittstellen zum ERP oder zur E-Rechnung.
4. Prüfen Sie die Lizenzen. Manche Premium-Module sind an Domain oder IP gebunden und funktionieren nach dem Umzug erst wieder, wenn der Entwickler sie neu aktiviert.

Zahlungsanbieter: der heikelste Punkt

Wenn Sie mit Redsys arbeiten (dem spanischen Kartenzahlungs-Gateway, über das fast alle spanischen Banken abrechnen), ist das virtuelle Zahlungsterminal meist an die Antwort-URL gebunden. Wechseln Sie Server oder Domain, muss die Bank die Benachrichtigungs-URL aktualisieren – sonst kommen keine Zahlungsbestätigungen an, und die Bestellungen bleiben ewig auf „Zahlung ausstehend“. Stripe und PayPal sind flexibler, aber auch dort sollten Sie die Webhooks prüfen.

Noch ein Detail: Seit Veri*Factu, das neue spanische Pflichtsystem für Rechnungssoftware, vollständig gilt, sollten Sie prüfen, ob Ihr Rechnungsmodul nach der Migration noch kompatibel ist. Manche älteren Module erzeugen Rechnungen, die die neuen Anforderungen des spanischen Finanzamts (AEAT) nicht mehr erfüllen – ein Problem für alle Selbstständigen und Unternehmen, die in Spanien online verkaufen.

PrestaShop migrieren ohne SEO-Verlust: Weiterleitungen, Sitemap und Search Console

Beim SEO verlieren Sie am meisten Umsatz, wenn Sie nachlässig sind. Ich habe Shops gesehen, die in zwei Wochen 40 % ihres organischen Traffics verloren haben, weil die Weiterleitungen nicht vorbereitet waren. Und es dauert Monate, ihn zurückzuholen.

Wenn Domain und URL-Struktur gleich bleiben

Glückwunsch, dann ist dieser Teil fast eine Formalität. Prüfen Sie, ob die sprechenden URLs aktiviert sind (Shopparameter > Traffic & SEO), generieren Sie die .htaccess neu und kontrollieren Sie, ob eine Handvoll zufälliger URLs der alten Seite im neuen Shop den Status 200 liefert.

Wenn sich Domain oder Struktur ändern

Jetzt ist Feinarbeit gefragt. Sie brauchen eine Zuordnung der 301-Weiterleitungen von alt nach neu. Exportieren Sie die vollständige URL-Liste aus Search Console und Screaming Frog, erstellen Sie das Mapping in einer Tabelle und erzeugen Sie die RewriteRule-Regeln in der .htaccess – oder besser: Nutzen Sie ein eigenes Modul wie "301 Redirects", damit Sie die htaccess nicht von Hand bearbeiten müssen.

SEO-Checkliste nach der Migration

• XML-Sitemap neu erzeugt und in der Search Console eingereicht.
• Robots.txt geprüft (Achtung: Es darf kein Disallow: / aus dem Staging übrig bleiben).
• Canonicals verweisen auf die richtige Domain.
• Strukturierte Daten (Product, Breadcrumb) mit dem Test für Rich-Suchergebnisse validiert.
• Ladezeit vorher und nachher mit PageSpeed Insights gemessen.
• Domain in der Search Console und den Bing Webmaster Tools bestätigt.

Eine Migration ohne Weiterleitungsplan ist wie ein Umzug ohne Nachsendeauftrag: Der Briefträger (Google) klopft noch monatelang an die alte Tür.

Geht Ihr Projekt über einen Hosterwechsel hinaus und denken Sie darüber nach, den Shop neu aufzubauen, lesen Sie, wie wir eine komplette Onlineshop-Migration angehen – mit vorheriger SEO-Analyse und Contentplan. Dateien zu verschieben ist etwas anderes, als die Architektur neu aufzubauen.

Abschlussprüfung, Livegang und Monitoring

An diesem Punkt läuft der Shop auf dem neuen Server unter einer temporären Subdomain oder IP. Bevor Sie die endgültige Domain umstellen, nehmen Sie sich ein paar Stunden Zeit und testen Sie den gesamten Ablauf, als wären Sie ein echter Kunde.

Tests, die Sie nicht auslassen dürfen

1. Ein kompletter Kauf mit jeder aktiven Zahlungsart, mit kleinen echten Beträgen (1 €, 2 €). Der Testmodus zählt nur, wenn er genauso konfiguriert ist wie die Produktivumgebung.
2. Versandkostenberechnung in verschiedene Regionen, auch auf die Kanaren, die Balearen, nach Ceuta und Melilla, für die in Spanien eigene Steuerregeln gelten.
3. Rechnungserstellung und Prüfung, ob die Rechnungen die aktuellen Anforderungen erfüllen (Veri*Factu, falls zutreffend).
4. Versand der Transaktions-E-Mails: Bestellbestätigung, Statusänderung, Passwort zurücksetzen.
5. Backoffice: Login der Mitarbeitenden, Bestellverwaltung, Export von Berichten.

Die DNS-Umstellung

Wenn alles funktioniert, senken Sie die TTL der DNS-Einträge etwa 24–48 Stunden vor der Umstellung auf 300 Sekunden. So ist die Änderung fast sofort aktiv. Schalten Sie den alten Shop in den Wartungsmodus, exportieren Sie ein letztes Mal die Bestellungen aus dem Wartungsfenster, importieren Sie sie in den neuen Shop und stellen Sie die DNS um.

In den ersten 72 Stunden heißt es genau hinsehen: PHP-Fehlerlogs, 404-Fehler in der Search Console, Conversion-Rate in Google Analytics 4 und vor allem die Bestellungen pro Stunde im Vergleich zur Vorwoche. Bricht etwas plötzlich ein, ist das der Hinweis, dass ein Modul oder eine Weiterleitung nicht stimmt.

Für Shops, denen PrestaShop zu klein geworden ist, ist das auch ein guter Moment, die Plattform zu überdenken. Ausführlich behandeln wir das Thema in unserem Bereich E-Commerce, wo wir PrestaShop je nach Geschäftsmodell mit anderen Optionen vergleichen.

Typische Fehler und wie Sie sie vermeiden

Zum Schluss meine gedankliche Liste der Stolpersteine, die wir am häufigsten sehen. Manche klingen banal, aber glauben Sie mir: Ich habe sie mehr als einmal erlebt, auch mit erfahrenen Technikteams.

• Migrieren, ohne die PHP-Version rechtzeitig zu aktualisieren. PrestaShop 8 läuft nicht mit PHP 7.4, aber manche alten Module stürzen unter PHP 8.2 ab. Prüfen Sie vorher die Kompatibilitätsmatrix.
• Den Ordner /img vergessen. Er ist groß und wird manchmal versehentlich ausgelassen. Ergebnis: ein Katalog ohne Fotos.
• Die Vorschaubilder nicht neu erzeugen nach dem Umzug. Die Bilder sind verpixelt oder fehlen in den Kategorien.
• Die Staging-Domain stehen lassen – in einem Konfigurationsfeld oder in E-Mail-Vorlagen. Ihre Kunden erhalten Links zu neu.ihrshop.de, die nicht existiert.
• Redsys bzw. den Zahlungsanbieter nicht informieren, dass sich die Benachrichtigungs-URL geändert hat.
• Die Cronjobs vergessen auf dem neuen Server: Indexierung, Bereinigung abgebrochener Warenkörbe, ERP-Synchronisation.
• Die DSGVO übersehen: Wenn Sie den Hoster wechseln, aktualisieren Sie das Verzeichnis der Verarbeitungstätigkeiten und gegebenenfalls Impressum und Datenschutzerklärung.

Meiner Erfahrung nach scheitern PrestaShop-Migrationen eher an zu viel Selbstvertrauen als an fehlendem Wissen. Der Prozess ist lang, mühsam und zu großen Teilen langweilig, und nach sechs Stunden am Laptop neigt das Gehirn dazu, Schritte zu überspringen. Deshalb ist eine ausgedruckte Checkliste, abgehakt mit Kugelschreiber, immer noch das wirksamste Werkzeug, das ich kenne.

Eine gut gemachte PrestaShop-Migration ist unsichtbar: Die Kunden merken nichts, die Bestellungen laufen weiter, und das SEO bleibt stabil. Schlecht gemacht bedeutet sie ein Wochenende voller Überstunden, Anrufe bei der Bank und Entschuldigungen bei Kunden, die nicht bezahlen können. Der Unterschied liegt selten im technischen Können, sondern in der Planung und darin, die Reihenfolge der Schritte einzuhalten.

Wenn Ihr Shop so viel Umsatz macht, dass ein Tag Ausfall richtig wehtut, planen Sie die Migration in Ruhe, mit einem klaren Wartungsfenster und einem schriftlichen Plan B. Und wenn Ihnen der Umfang über den Kopf wächst – Versionssprünge, ERP-Anbindungen, ein riesiger Katalog –, holen Sie sich Leute, die das schon Dutzende Male gemacht haben. Das kommt günstiger, als zu reparieren, was kaputtgeht.