Von PrestaShop 1.6 auf 8 migrieren, ohne das SEO zu verlieren

Das Hauptrisiko ist ein anderes als vermutet

Bei einer Migration von PrestaShop 1.6 kreist die Sorge zuerst um die Daten: Gehen Bestellungen, Kunden oder Produkte verloren? In der Praxis kommen diese Daten recht gut durch. Was verloren geht und nicht von allein zurückkehrt, ist der organische Traffic.

Zwischen 1.6 und den modernen Versionen ändert sich die URL-Struktur. Ohne Weiterleitungsplan wird jede indexierte URL zu einer 404. Google entfernt die Seiten aus dem Index, erarbeitete Positionen verschwinden, und der Weg zurück dauert Monate. Genau deshalb kann eine technisch gelungene Migration wirtschaftlich ein Fehlschlag bleiben.

Der Versionspfad ist Pflicht

Erste Regel: Einen direkten Sprung von 1.6 auf 8 gibt es nicht. Die Migrationsskripte bauen inkrementell aufeinander auf; wer Stufen überspringt, hinterlässt eine inkonsistente Datenbank.

Der Pfad lautet: 1.6.1.x → 1.7.8.x → 8.x (und gegebenenfalls anschließend 9.x).

Jede Stufe gehört überprüft, bevor die nächste folgt: Das Backoffice lädt, eine Bestellung lässt sich abschließen, die Produkte werden angezeigt. Eine zu hastig migrierte Datenbank erzeugt Fehler, die erst nach Wochen auffallen – an Funktionen am Rand des Alltagsbetriebs.

Die sechs klassischen Verluste

1. Das Theme. Ein 1.6-Theme läuft weder unter 1.7 noch darüber hinaus. Die Template-Engine hat einen Versionswechsel hinter sich, und die Dateistruktur der Produktseiten wurde komplett neu aufgebaut. Eine automatische Umwandlung gibt es nicht: Das Theme wird neu gebaut oder ersetzt.

2. Sämtliche Overrides. Das Verzeichnis override/ beginnt bei null. Die überschriebenen Klassen haben andere Signaturen, und ein beibehaltener 1.6-Override führt zu einem Fatal Error. Darin steckt auch eine Chance: Die Hälfte der Overrides bedient Anforderungen, die es längst nicht mehr gibt.

3. Die 1.6-Module. Die Hooks wurden umbenannt (aus hookHeader wird beispielsweise hookDisplayHeader), und die Modularchitektur hat sich weiterentwickelt. Jedes Modul muss durch seine moderne Fassung ersetzt oder neu geschrieben werden.

4. Die Produktbewertungen. Das Modul productcomments wechselt das Schema. Kundenbewertungen werden nicht automatisch übernommen: Sie müssen per Skript migriert werden, Tabelle für Tabelle. Diese Inhalte haben echten SEO-Wert – lassen Sie sie nicht liegen.

5. Die Produktbilder. Das Neuerzeugen der Thumbnails über Design > Bildeinstellungen sprengt jenseits einiger Tausend Bilder die erlaubte Ausführungszeit. Ergebnis: Produkte ohne Bild im Frontend. Nötig ist der Weg über die Kommandozeile oder eine Verarbeitung in Paketen.

6. CMS-Blöcke und statische Inhalte. CMS-Seiten, Vertrauensblöcke, Inhalte der Startseite: Je nachdem, welche Module unter 1.6 im Einsatz waren, liegen diese Inhalte in Tabellen, die es nicht mehr gibt. Sie werden vorher exportiert und nachher neu eingepflegt.

Der SEO-Plan, Schritt für Schritt

Das ist der Teil, der die meiste Aufmerksamkeit verdient.

Vor der Migration

1. Alle indexierten URLs exportieren. Führen Sie drei Quellen zusammen: einen vollständigen Crawl der Website, den Seitenexport der Search Console über 16 Monate und Ihre aktuelle Sitemap. Die Search Console ist unverzichtbar: Sie fördert URLs zutage, die der Crawl nicht mehr findet, die aber weiterhin Traffic erhalten.
2. Die Positionen festhalten. Eine Momentaufnahme der rankenden Keywords vor der Umstellung ist danach Ihr einziger objektiver Vergleichspunkt.
3. Die Zuordnungstabelle aufbauen. Jede alte URL braucht ihr neues Gegenstück. Gelöschte Produkte verweisen auf ihre Kategorie, niemals auf die Startseite: Eine pauschale Weiterleitung auf die Startseite wertet Google als Soft-404.

Während der Migration

4. 301-Weiterleitungen auf Serverebene umsetzen, bei großen Mengen nicht über ein Modul. Eine Weiterleitung in PHP über 40 000 URLs belastet die Performance.
5. Canonical-Tags und die Datei robots.txt prüfen. Eine Staging-Umgebung auf noindex, die ohne Entfernen der Anweisung live geht, ist ein klassischer und vollkommen vermeidbarer Totalschaden.

Nach der Migration

6. Die neue Sitemap einreichen und den Abdeckungsbericht einen Monat lang täglich beobachten.
7. Die tatsächlichen 404 verfolgen – in den Serverlogs, nicht nur in der Search Console, die mit Verzögerung meldet. Jede wiederkehrende 404 auf einer URL, die vorher Traffic hatte, ist eine vergessene Weiterleitung.

Welchen Zeitraum Sie einplanen sollten

Eine Migration von 1.6 auf 8 mit neuem Theme und überarbeiteten Modulen rechnet sich in Wochen, nicht in Tagen. Der größte Posten ist fast immer das Theme, gefolgt von der Übernahme der Eigenentwicklungen.

Die beste Investition bleibt der vorgelagerte Audit: Inventar der Module, der Overrides, der überschriebenen Templates und der indexierten URLs. Er macht aus einem groben Angebot eine belastbare Aufwandsplanung – und zeigt oft, dass das Projekt kleiner ausfällt als angekündigt.

Wenn Sie bereits auf Version 8 sind und über den nächsten Schritt nachdenken, lesen Sie unseren Beitrag zum Supportende von PrestaShop 8.

Ihren Shop migrieren lassen

Wir übernehmen die vollständige Migration samt Weiterleitungsplan und beobachten den organischen Traffic nach der Umstellung. Siehe die Seite PrestaShop-Migration.