PrestaShop-SEO-Leitfaden: Einstellungen, Duplicate Content

Ich verantworte die gesamte Technik von 23 PrestaShop-Shops in 22 Märkten und migriere sie gerade auf PrestaShop 9 und Hummingbird. Dieser Leitfaden ist die Reihenfolge, in der ich SEO auf einem laufenden Shop abarbeite: zuerst die Einstellungen, dann die Duplicate-Content-Quellen eine nach der anderen, dann die Templates, die den Umsatz tragen, und zuletzt das, was erst zählt, wenn der Rest stimmt.

Es ist keine Modul-Einkaufsliste. Das meiste, was die bezahlten „SEO-Module“ verkaufen, steckt seit 1.7 im Core, und ein Shop mit den richtigen Einstellungen und einem sauberen Theme braucht fast keines davon. Wo ein Modul wirklich die Antwort ist, wird es genannt.

Zuerst sehen, was Google tatsächlich sieht

Bevor Sie eine Einstellung anfassen, besorgen Sie sich zwei Dinge: Ihre Search-Console-Daten und das rohe Zugriffsprotokoll Ihres Servers.

Die Search Console zeigt, welche URLs Impressionen bekommen und welche aus welchem Grund ausgeschlossen sind. Das Zugriffsprotokoll zeigt, was der Googlebot tatsächlich anfragt - und das ist bei PrestaShop meist eine Überraschung: Filterkombinationen, Sortierungen, paginierte Seiten, Druckansichten und Kombinations-URLs, die in keiner Sitemap stehen, aber den Großteil des Crawlings fressen. Nehmen Sie eine Woche Apache- oder Nginx-Logs und laden Sie sie in meinen kostenlosen Access-Log-Viewer; er gruppiert Anfragen nach User-Agent und URL-Muster, und die Verschwendung ist in einer Minute sichtbar.

Alles Folgende dient dazu, diese beiden Sichten in Deckung zu bringen: Die URLs, die Sie indexiert haben wollen, sind die, auf denen Google seine Zeit verbringt - und sonst keine.

Die SEO-&-URL-Einstellungen, in der richtigen Reihenfolge

Alle liegen unter Shop-Parameter > Traffic & SEO (in älteren Versionen SEO & URLs). Die Reihenfolge zählt, weil mehrere davon URLs verändern und jede URL-Änderung eine Weiterleitung braucht.

Sprechende URLs

Einschalten. Ohne sie ist jede Seite index.php?id_product=847&controller=product, und nichts in diesem Leitfaden greift. Bei einem Shop, der ohne sprechende URLs live war, ändert der Schalter jede Adresse - also gehen Sie nach dem Verfahren unter „URL-Änderungen und Weiterleitungen“ weiter unten vor.

Weiterleitung zur kanonischen URL

Auf 301 (dauerhaft) setzen. Es ist die wertvollste Einstellung auf der Seite und steht erstaunlich oft auf „keine Weiterleitung“. Mit ihr werden ein Produkt, das über eine Nicht-Standard-Kategorie erreicht wird, eine Kategorie mit einem verirrten Parameter und eine URL mit falschem Sprachpräfix alle auf die eine Adresse weitergeleitet, die indexiert werden soll. Ohne sie liefert PrestaShop dieselbe Seite bereitwillig unter mehreren Adressen aus und überlässt Google die Wahl.

URLs mit Akzenten

Aus, außer es gibt einen konkreten Grund. Akzentzeichen in URLs sind erlaubt, werden aber von Browsern, Tools und beim Kopieren unterschiedlich kodiert - und dasselbe Produkt existiert im Netz in zwei Schreibweisen.

URL-Schema und die Frage nach den IDs

Die Routenmuster bestimmen, wie Produkt- und Kategorie-URLs aussehen. Die Standards erzeugen Adressen wie /kleidung/3-bedrucktes-t-shirt.html, und die Zahl ist die Produkt-ID. Die häufigste Frage, die ich bekomme, ist, wie man sie entfernt.

Meine Antwort nach Erfahrung im großen Maßstab: bei einem etablierten Shop nicht. Die ID hat keinen Einfluss auf Ihre Rankings. Sie zu entfernen erfordert ein Modul, das den Dispatcher überschreibt, um Produkte nur über den Rewrite aufzulösen, ändert jede Produkt- und Kategorie-URL der Website und schafft eine dauerhafte Abhängigkeit von diesem Modul. Für einen neuen, noch nicht gestarteten Shop ist eine saubere Route in Ordnung. Für einen Shop mit Rankings ist es eine URL-Migration ohne Gegenwert.

Was sich in den Routen lohnt: den Kategoriepfad aus Produkt-URLs heraushalten, wenn Produkte in mehreren Kategorien liegen, damit das Canonical nicht vom Pfad abhängt, über den der Besucher kam.

Meta-Titel und -Beschreibungen

Jedes Produkt, jede Kategorie, CMS-Seite, jeder Hersteller und Lieferant hat eigene Felder für Titel und Beschreibung. Kategorien sind der Ort, an dem sie am meisten zählen, weil Kategorieseiten für die Begriffe mit Volumen ranken sollen - und weil die meisten Shops sie auf dem Standardmuster „Kategoriename - Shopname“ lassen. Schreiben Sie die zwanzig wichtigsten Kategorien von Hand; den Rest über eine Vorlage.

Meta-Keywords leer lassen. Google ignoriert das Feld seit über einem Jahrzehnt, und ein leeres Feld kostet nichts.

robots.txt

Der Button robots.txt generieren schreibt eine vernünftige Datei, die Admin, Warenkorb, Konto, Bestellung und Suche in jeder Sprache sperrt. Nach dem Hinzufügen einer Sprache oder eines Shops neu generieren, dann die Sitemap-Zeile ergänzen. Filterparameter hier nicht sperren; gefilterte URLs werden weiter unten an der Quelle behandelt, und eine robots-Sperre auf einer bereits indexierten URL hält sie für immer im Index.

Shop-URL und SSL

Ein kanonischer Host, überall HTTPS, SSL auf allen Seiten erzwungen. Wenn der Shop noch auf http:// oder auf www und der nackten Domain ohne Weiterleitung antwortet, wird das am Server behoben - vor allem anderen.

Duplicate Content, Quelle für Quelle

PrestaShop erzeugt Duplikate an sechs Stellen. Jede hat ihre eigene Lösung, und die Canonical-Weiterleitung von oben schließt die meisten nur dann, wenn das Theme ein korrektes Canonical ausgibt. Prüfen Sie nach jeder Änderung das rohe HTML eines Produkts, einer Kategorie und einer paginierten Kategorie.

Produkte in mehr als einer Kategorie

Ein Produkt in drei Kategorien ist über drei Pfade erreichbar. Das Canonical muss auf die URL aus der Standardkategorie des Produkts zeigen, und mit aktiver 301-Weiterleitung leiten die anderen beiden Pfade dorthin. Prüfen Sie, ob das Canonical Ihres Themes wirklich die Standardkategorie nutzt und nicht die aktuelle.

Kombinationen

Je nach Version und Theme tragen Produkt-URLs die Kombinations-ID im Pfad oder wechseln Kombinationen per URL-Fragment. Fragmente sind für Google unsichtbar und in Ordnung. Kombinations-IDs im Pfad sind es nicht - außer das Canonical entfernt sie konsequent. Entscheiden Sie sich für ein Verhalten und prüfen Sie es im HTML; beides kommt in der Praxis vor.

Paginierung

?page=2 und folgende müssen crawlbar sein, auf sich selbst kanonisieren und kein noindex tragen. Der alte Rat, jede Seite auf Seite eins zu zeigen, versteckt alles hinter der ersten Seite vor dem Index, und die rel="next"- und rel="prev"-Links, die Leitfäden noch empfehlen, nutzt Google seit 2019 nicht mehr als Indexierungssignal. Selbst-Canonical, indexierbar, fertig.

Sortierung

?order=product.price.asc und Verwandte sind dieselbe Liste in anderer Reihenfolge. Sie müssen auf die unsortierte Kategorie-URL kanonisieren. Die meisten Themes machen das richtig; einmal prüfen.

Gefilterte Kategorie-URLs

Filter sind die größte Quelle von Crawl-Verschwendung bei PrestaShop - und die am besten steuerbare. Jede Filterkombination, die ein Besucher anklicken kann, ist eine URL mit Parametern, und der Shop muss pro Filter entscheiden, ob diese URL für Google existiert oder nur für den Besucher.

Die Regel: Standardmäßig ist keine gefilterte URL indexierbar. Eine gefilterte Seite kanonisiert zurück auf ihre Kategorie, und die Links, die sie erzeugen, werden nicht verfolgt. Dann einen Filter nur dort öffnen, wo die Kombination selbst ein Suchbegriff mit Volumen ist - Marke innerhalb einer Kategorie ist der übliche Fall, gelegentlich ein Material oder eine Größenklasse - und dieser Seite ein selbstreferenzierendes Canonical und eigenen Text geben. Jede andere Kombination ist ein Duplikat der Kategorie mit weniger Produkten.

Zwei Prüfungen im rohen HTML klären es: das Canonical auf einer gefilterten Seite und das rel-Attribut der Filterlinks. Stimmt eines nicht, liegt die Lösung im Kategorietemplate des Themes, nicht in einer robots-Regel.

Damit verwandt: Eine Elternkategorie ohne eigene Produkte sollte kein leeres Raster zeigen. Dort die Produkte der Unterkategorien anzeigen oder sie füllen; leere Kategorien sind dünne Seiten.

Sprachen, Shops und Hreflang

Innerhalb eines Shops gibt das Classic-Theme hreflang-Alternativen für jede aktive Sprache aus - korrekt, solange jede Sprache tatsächlich übersetzten Inhalt hat. Eine aktivierte Sprache mit unübersetzten Produkten erzeugt englische Seiten unter deutschen URLs, und Google behandelt sie als das, was sie sind.

Bei einem Multistore-Bestand auf getrennten Domains weiß der Core nicht, dass die Geschwister-Shops existieren, also endet das Hreflang-Set bei den Sprachen des eigenen Shops. Wer Länder-Shops auf Länder-Domains betreibt, muss das domainübergreifende Hreflang im Theme aus einer gemeinsamen Zuordnungstabelle gleichwertiger URLs ergänzen. Das ist die eine Stelle auf einem Bestand mit 22 Märkten, an der ich Code schreiben musste statt zu konfigurieren.

Kategorieseiten: wo die Umsatzbegriffe ranken

Kategorieseiten ranken für die Begriffe, mit denen Menschen tatsächlich kaufen, und PrestaShop liefert sie als Überschrift über einem Raster aus. Drei Änderungen machen Seiten daraus:

• Die Kategoriebeschreibung schreiben, pro Sprache, und sicherstellen, dass das Theme sie zeigt. Classic zeigt eine gekürzte Version mit „mehr“-Schalter; ob über oder unter dem Raster, hängt vom Theme ab. Text über dem Raster, in der Länge einer Einleitung, funktioniert für Nutzer und Crawler besser als ein Aufsatz unter der dritten Produktseite.
• Innerhalb des Textes zwischen Kategorien verlinken: die Elternkategorie, die Geschwister mit denselben Käufern, den Ratgeberartikel, der die Frage vor dem Kauf beantwortet. Der Kategoriebaum gibt Google Struktur; der Text gibt ihm Kontext.
• Eine H1-Überschrift, nämlich der Kategoriename, und keine zweite H1 aus einem Banner-Modul. Im HTML prüfen.

Kategorien, die nur der Navigation dienen und zwei Produkte enthalten, sind kein Ranking wert; zusammenlegen oder auf noindex setzen, statt dünne Seiten im Index zu lassen.

Produktseiten

Die Produktfelder erledigen den Großteil der Arbeit - wenn sie gefüllt sind:

• Die Kurzbeschreibung erscheint in Listen und ist der Fallback für die Meta-Beschreibung. Die Beschreibung ist die Seite. Keine von beiden sollte der Herstellertext sein, den fünfzig andere Shops ebenfalls eingefügt haben; die Bestseller von Hand neu zu schreiben ist die ertragreichste Inhaltsarbeit in einem PrestaShop-Shop.
• EAN, UPC, MPN und ISBN fließen in die strukturierten Daten. Füllen Sie sie; Google gleicht Produkte über Kennungen im Web ab, und Shopping-Flächen hängen davon ab.
• Hersteller zugewiesen, damit die Marke im Markup erscheint.
• Alt-Text der Bilder ist das Bildunterschriften-Feld; mindestens für das Hauptbild füllen.

Wenn ein Produkt offline geht, die Weiterleitung bei Offline auf eine 301 zur Kategorie oder zum Nachfolgeprodukt setzen. Ein gelöschtes Produkt, das mit Rankings im Gepäck einen 404 liefert, ist verlorener Traffic; das Feld gibt es, damit Sie kein Weiterleitungsmodul brauchen.

Strukturierte Daten

Classic und Hummingbird liefern Produkt-Strukturdaten mit; die Fragen sind, ob sie validieren und ob sie vollständig sind. Testen Sie eine Live-Produkt-URL im Test für Rich-Suchergebnisse. Was meist fehlt: brand, sku, gtin, priceValidUntil und die korrekte availability für nicht vorrätige Kombinationen.

Das Breadcrumb-Markup kommt aus der Breadcrumb des Themes und entspricht dem Kategoriepfad - ein weiterer Grund, warum die kanonische Kategorie zählt.

Bewertungen brauchen ein Modul, und das Bewertungs-Markup muss Bewertungen beschreiben, die auf der Seite sichtbar sind. Markup, das Bewertungen behauptet, die die Seite nicht zeigt, ist genau das, was einem Shop die Rich-Ergebnisse kostet.

Sitemaps

Nutzen Sie das offizielle kostenlose Modul Google Sitemap (gsitemap). Es erzeugt einen Sitemap-Index mit einer Datei pro Sprache und Inhaltstyp, schließt inaktive Produkte aus und lässt sich per Cron-URL neu generieren. Zwei Prüfungen nach dem Generieren:

• Jede Sitemap-URL muss die kanonische Form haben, inklusive Sprachpräfix und Host. Widersprechen sich Sitemap und Canonical, vertraut Google dem Canonical und ignoriert die Sitemap.
• Im Multistore pro Shop generieren und einreichen, jeweils in der Search-Console-Property des Shops.

Ladezeit und Core Web Vitals

PrestaShop ist nicht langsam; PrestaShop-Shops sind langsam wegen dessen, was darauf installiert ist. Nach Wirkung geordnet:

1. Module. Jedes Modul, das sich in den Header hängt, lädt sein CSS und JavaScript auf jeder Seite. Deinstallieren, was nicht genutzt wird - nicht nur deaktivieren. Ein Modul-Audit ist meist mehr wert als alle folgenden Einstellungen zusammen.
2. Bilder. Seit PrestaShop 8 können die Bildeinstellungen WebP erzeugen (und in späteren Releases AVIF). Einschalten, Miniaturen neu generieren, prüfen, dass das Theme sie ausliefert. Produktbilder sind auf fast jeder Seite das LCP-Element.
3. Caching. Unter Leistung: Smarty-Cache an und Template-Kompilierung in Produktion auf „nie neu kompilieren“. Auf 1.7 mit Classic bündeln und komprimieren die CCC-Optionen die Assets. Auf 8 und 9 mit Hummingbird sind die Assets vorgebaut, und CCC ist weniger relevant.
4. Server. PHP-Opcache, eine aktuelle PHP-Version, genug Speicher für MySQL und ein Full-Page-Cache vor dem Shop, wenn der Traffic ihn rechtfertigt. Hier gebe ich das AWS-Budget für den betreuten Bestand aus, und hier kommt das letzte Drittel des LCP-Werts her.
5. Drittanbieter-Tags. Analytics, Chat, Consent und Marketing-Tags, die über einen Tag-Manager auf jeder Seite laden. Prüfen Sie sie wie Module.

Messen Sie auf echten Produkt- und Kategorie-URLs im Core-Web-Vitals-Bericht der Search Console, nicht auf der Startseite.

Multistore und internationale Shops

Wer in mehrere Länder verkauft, entscheidet die Struktur einmal: ein Shop mit vielen Sprachen, ein Shop pro Land in Unterordnern oder Subdomains, oder getrennte Domains. Die SEO-Folgen unterscheiden sich.

Sprachen in einem Shop teilen sich die Autorität und sind am einfachsten konsistent zu halten. Länder-Shops auf getrennten Domains teilen die Autorität auf, und jeder braucht eine eigene Search-Console-Property, Sitemap und - wie oben - von Hand gebautes domainübergreifendes Hreflang; dafür kann jeder Markt eigenen Katalog, eigene Preise und Inhalte haben. Auf dem Bestand, den ich betreue, war das Länder-Domain-Modell bereits vorhanden, und es funktioniert - aber es kostet echte Entwicklungsarbeit, 22 Märkte auf einer Codebasis zu halten. Wählen Sie es nicht leichtfertig.

Unabhängig von der Struktur gilt: Die Seiten jedes Marktes sind vollständig übersetzt, in der lokalen Währung bepreist und mit ihren Entsprechungen verlinkt. Halb übersetzte Märkte sind das häufigste internationale SEO-Problem, das ich bei PrestaShop sehe, und keine Einstellung behebt sie.

URL-Änderungen und Weiterleitungen

Jede Änderung, die URLs verschiebt - sprechende URLs einschalten, Routen ändern, Kategorien umbenennen, den Baum umbauen - braucht dasselbe Verfahren:

1. Vor der Änderung jede URL mit Impressionen aus der Search Console exportieren.
2. Jede auf ihre neue Adresse abbilden.
3. Die Weiterleitungen auf Serverebene (Apache oder Nginx) oder per Weiterleitungsmodul laden und eine Stichprobe testen.
4. Die Weiterleitungen mindestens ein Jahr behalten, länger, wenn die alten URLs noch gecrawlt werden.

Der PrestaShop-Core kümmert sich um die Weiterleitung einzelner Produkte, wenn sie offline gehen - und um sonst nichts. Für eine strukturelle Änderung ist der Server der richtige Ort für die Regeln.

Module: was sich zu installieren lohnt

• Google Sitemap (offiziell, kostenlos): ja.
• Ein Weiterleitungs-Manager: nur wenn Ihr Team Weiterleitungen aus dem Backoffice pflegen soll statt in der Serverkonfiguration. Für Massenregeln ist der Server besser; für ein Marketing-Team, das eine pro Woche anlegt, das Modul.
• Die bezahlten SEO-Suiten: Ihr legitimer Nutzen sind Massenvorlagen für Meta-Titel über tausende Produkte und Weiterleitungspflege pro Seite. Der Rest der Liste - Canonicals, sprechende URLs, Sitemaps, „Duplicate-Content-Schutz“ - ist aufgehübschte Core-Funktionalität. Wer die Massenbearbeitung braucht, kauft dafür; Ranking-Änderungen vom Modul selbst sollte niemand erwarten.
• Strukturierte-Daten-Module: nur wenn das eingebaute Markup Ihres Themes die Validierung nicht besteht und Sie das Theme nicht reparieren können. Zuerst prüfen.

Was PrestaShop 9 für SEO ändert

Die oben beschriebenen Einstellungen sind in 9 im Wesentlichen dieselben wie in 8. Was sich ändert, liegt darunter: PHP 8.1 oder neuer, ein aktueller Symfony-Kern, eine neue Admin API und Hummingbird als unterstütztes modernes Theme. Hummingbird baut auf Bootstrap 5 ohne jQuery-Abhängigkeit, und bei den Shops, die ich umgezogen habe, kommt die Verbesserung der Core Web Vitals aus dem Theme, nicht aus einer SEO-Einstellung.

Die andere Änderung ist indirekt. 1.7 wird nicht mehr unterstützt, was ungepatchte Angriffsfläche bedeutet - und ein kompromittierter Shop ist ein SEO-Problem, bevor er irgendetwas anderes ist: Eingeschleuste Spam-URLs werden schnell indexiert und brauchen Monate, bis sie verschwinden. Wer noch auf 1.7 ist, für den ist das Upgrade das SEO-Projekt. Wie ich es durchführe, steht auf der Seite PrestaShop Upgrade und Migration.

Die Checkliste

Technik:

• Sprechende URLs an, Canonical-Weiterleitung 301, Akzent-URLs aus, HTTPS auf einem Host erzwungen
• Canonical korrekt bei Produkten in mehreren Kategorien, bei Kombinationen, bei paginierten und sortierten Listen
• Gefilterte URLs aus dem Index gehalten, außer den wenigen, die Suchbegriffe sind
• Hreflang vollständig innerhalb des Shops und - bei Multistore-Domains - über Shops hinweg
• Sitemap pro Sprache generiert, pro Property eingereicht, URLs identisch mit den Canonicals
• robots.txt nach jeder Sprach- oder Shop-Änderung neu generiert
• Produkt-Strukturdaten auf Live-URLs valide, mit Kennungen und Marke

Inhalt:

• Top-Kategorien mit handgeschriebenen Titeln, Beschreibungen und Text über dem Raster
• Top-Produkte mit neu geschriebenen Beschreibungen und gefüllten Kennungen
• Dünne Kategorien zusammengelegt oder auf noindex
• Offline-Produkte weitergeleitet, nicht auf 404

Ladezeit:

• Modul-Audit gemacht, ungenutzte Module deinstalliert
• WebP-Erzeugung an, Miniaturen neu generiert
• Cache und Template-Kompilierung auf Produktion gestellt
• Core Web Vitals auf Produkt- und Kategorietemplates in der Search Console geprüft

Häufige Fragen

Ist PrestaShop gut für SEO?

Ja, sobald es konfiguriert ist. Der Core hat seit 1.7 sprechende URLs, Canonical-Weiterleitungen, Meta-Felder pro Seite, Hreflang und Produkt-Strukturdaten. Was Shops bremst, sind die Voreinstellungen - und das ist Konfigurations- und Template-Arbeit, keine Grenze der Plattform.

Wie aktiviere ich SEO-freundliche URLs in PrestaShop?

Unter Shop-Parameter > Traffic & SEO sprechende URLs einschalten, die Canonical-Weiterleitung auf 301 setzen und Akzent-URLs aus lassen. Bei einem laufenden Shop vorher die alten URLs aus der Search Console exportieren und Weiterleitungen am Server laden, weil sich jede Adresse ändert.

Soll ich die ID-Nummern aus PrestaShop-URLs entfernen?

Bei einem etablierten Shop nein. Die ID hat keinen Einfluss auf Rankings, das Entfernen braucht ein Modul, das das Routing überschreibt, und es ändert jede URL der Website. Bei einem noch nicht gestarteten Shop ist eine saubere Route in Ordnung.

Wie behebe ich Duplicate Content in PrestaShop?

Canonical-Weiterleitung auf 301, Theme-Canonical auf die Standardkategorie, paginierte Seiten selbst-kanonisch, sortierte Listen auf die Kategorie kanonisiert, gefilterte URLs aus dem Index außer echten Suchbegriffen. Dann jeden Fall im rohen HTML prüfen.

Welches ist das beste PrestaShop-SEO-Modul?

Das offizielle kostenlose Google-Sitemap-Modul; der Rest sind Core-Einstellungen und das Theme. Bezahlte Suiten lohnen sich nur für Massen-Meta-Vorlagen in großen Katalogen oder Weiterleitungspflege im Backoffice.

Verbessert PrestaShop 9 das SEO?

Die Einstellungen sind im Wesentlichen dieselben wie in 8. Die Gewinne kommen von den besseren Core Web Vitals des Hummingbird-Themes und davon, auf einer unterstützten, gepatchten Version zu sein.

Wie es weitergeht

Alles oben kann ein Shop-Betreiber oder ein hauseigener Entwickler mit einer Staging-Kopie und einem Nachmittag pro Abschnitt selbst umsetzen. Wer es lieber von der Person machen lässt, die es auf 23 Shops betreibt: Dafür gibt es die Seite PrestaShop SEO, und die Seiten zu PrestaShop-Entwicklung und Wartung decken den Rest dessen ab, was ein Shop von einem Spezialisten braucht.