Google Tag Manager

Wir haben dedizierte Module für beides: Facebook Pixel und Google Analytics GA4. Die Installation ist unkompliziert — geben Sie Ihre Tracking-IDs in der Modulkonfiguration ein und der Tracking-Code wird automatisch auf allen Seiten injiziert, einschließlich E-Commerce-Events (In den Warenkorb, Kauf, etc.). Keine Code-Bearbeitung erforderlich.

Eine XML-Sitemap ist für Suchmaschinen — sie ist eine strukturierte Datei, die alle Ihre Seiten auflistet, damit Google sie effizient entdecken und indexieren kann. Eine HTML-Sitemap ist eine reguläre Seite auf Ihrer Website für menschliche Besucher, die Links zu allen Bereichen auflistet. Beide sind nützlich: die XML-Sitemap für die Indexierung, die HTML-Sitemap für Navigation und interne Verlinkung. Unser Sitemap Builder generiert XML-Sitemaps.

PrestaShop Produkt-Feeds: Google Shopping, Facebook-Katalog und mehr

Produkt-Feeds sind das Rückgrat der modernen E-Commerce-Werbung. Sie verbinden den Produktkatalog Ihres PrestaShop-Shops mit Werbeplattformen wie Google Shopping, Meta (Facebook und Instagram), Pinterest und Preisvergleichsportalen. Ein gut optimierter Produkt-Feed kann Ihre Sichtbarkeit drastisch erhöhen, qualifizierten Traffic generieren und den Umsatz steigern. Dieser Leitfaden deckt alles ab - von der Einrichtung Ihres ersten Feeds bis hin zu fortgeschrittenen Optimierungstechniken, die Ihren Produkten einen Wettbewerbsvorteil verschaffen.

Was ist ein Produkt-Feed und warum ist er wichtig

Ein Produkt-Feed ist eine strukturierte Datendatei (typischerweise XML, CSV oder JSON), die detaillierte Informationen über jedes Produkt in Ihrem Katalog enthält. Werbeplattformen verarbeiten diese Datei, um Ihre Produkte in Shopping-Anzeigen, Marktplatzlistungen und Social-Commerce-Funktionen anzuzeigen.

Die Qualität Ihres Produkt-Feeds beeinflusst direkt:

• Anzeigenberechtigung - Produkte mit fehlenden oder falschen Daten werden abgelehnt und nie Käufern angezeigt
• Anzeigenrelevanz - Bessere Produkttitel und Beschreibungen bedeuten, dass Ihre Anzeigen bei relevanteren Suchanfragen erscheinen
• Klickrate - Genaue Preise, hochwertige Bilder und überzeugende Beschreibungen generieren mehr Klicks
• Kosten pro Akquisition - Optimierte Feeds führen zu besseren Qualitätswerten, was Ihre Kosten pro Klick senkt

Google Shopping Feed einrichten

Voraussetzungen

Bevor Sie Ihren Google Shopping Feed erstellen, benötigen Sie:

1. Google Merchant Center Konto - Erstellen Sie eines unter merchants.google.com. Verifizieren und beanspruchen Sie Ihre Website-URL.
2. Google Ads Konto - Erforderlich, wenn Sie Shopping-Kampagnen schalten möchten (kostenlose Listings benötigen dies nicht).
3. Produktkennzeichnungen - GTIN (EAN-13 in Europa, UPC in Nordamerika), MPN und Marke müssen für die meisten Produktkategorien vorhanden sein.
4. Konforme Website - Ihr Shop muss klare Rückgaberichtlinien, Versandinformationen und Kontaktdaten für Käufer sichtbar haben.

Erforderliche Feed-Attribute

Feed in PrestaShop einrichten

Option A - PrestaShop Marketing with Google (Offizielles Modul)

Das offizielle Modul verbindet sich direkt mit dem Google Merchant Center. Installieren Sie es vom PrestaShop Addons Marketplace oder aus Ihrem Back Office. Konfigurationsschritte:

1. Navigieren Sie zu Module > Modulmanager, suchen Sie nach "PrestaShop Marketing with Google"
2. Installieren und klicken Sie auf Konfigurieren
3. Verbinden Sie Ihr Google-Konto über OAuth
4. Ordnen Sie Ihre Produktattribute den erforderlichen Google-Feldern zu
5. Wählen Sie, welche Produkte einbezogen werden sollen
6. Legen Sie die Synchronisierungshäufigkeit fest (täglich empfohlen)

Option B - Drittanbieter-Feed-Module

Drittanbietermodule bieten oft mehr Flexibilität. Achten Sie auf Module, die unterstützen:

• Benutzerdefiniertes Attribut-Mapping
• Feed-Filterung (Produkte nach Kategorie, Hersteller, Lager, Preis ausschließen)
• Mehrere Feed-Formate (XML, CSV, TXT)
• Geplante Generierung via Cron
• Unterstützung für Produktkombinationen/Varianten

Facebook- und Instagram-Katalog-Feed

Meta-Produktkatalog einrichten

1. Gehen Sie zum Meta Commerce Manager unter business.facebook.com/commerce
2. Erstellen Sie einen neuen Katalog und wählen Sie "E-Commerce" als Katalogtyp
3. Wählen Sie "Datenfeed" als Upload-Methode
4. Richten Sie eine geplante Feed-URL ein, die auf Ihren PrestaShop-Feed verweist

Erforderliche Attribute für Meta

Meta-Pixel-Integration

Damit Dynamic Ads effektiv funktionieren, benötigen Sie das Meta Pixel auf Ihrem PrestaShop-Shop. Das Pixel verfolgt das Nutzerverhalten und gleicht es mit Ihrem Produktkatalog ab, um relevante Remarketing-Anzeigen zu zeigen. Wichtige Events:

• ViewContent - Wenn ein Nutzer eine Produktseite betrachtet
• AddToCart - Wenn ein Nutzer ein Produkt zum Warenkorb hinzufügt
• Purchase - Wenn ein Nutzer eine Bestellung abschließt

Best Practices zur Feed-Optimierung

Titeloptimierung

Produkttitel sind das einflussreichste Element Ihres Feeds:

• Markenname zuerst - "Nike Air Max 90 Herren-Laufschuhe" funktioniert besser als "Herren-Laufschuhe von Nike"
• Schlüsselattribute hinzufügen - Farbe, Größe, Material und Modellnummer helfen bei der Zuordnung zu Suchanfragen
• Wichtige Keywords an den Anfang - Google kürzt Titel nach etwa 70 Zeichen in Shopping-Anzeigen
• Werbetexte vermeiden - "SALE" oder "Kostenloser Versand" in Titeln verstößt gegen Googles Richtlinien

Bildoptimierung

• Verwenden Sie weiße oder neutrale Hintergründe für Google Shopping
• Zeigen Sie das Produkt deutlich ohne Wasserzeichen, Logos oder Werbeüberlagerungen
• Mindestens 800x800 Pixel für Standardprodukte, 1200x1200 für Bekleidung
• Zusätzliche Bilder über das Attribut additional_image_link bereitstellen (bis zu 10)

Preis- und Verfügbarkeitsgenauigkeit

Google und Meta überprüfen beide, ob Preis und Verfügbarkeit in Ihrem Feed mit dem übereinstimmen, was auf Ihren Produktseiten angezeigt wird. Abweichungen führen zu Ablehnungen. Stellen Sie sicher, dass Ihr Feed häufig genug regeneriert wird, um widerzuspiegeln:

• Preisänderungen durch Aktionen oder Sales
• Lagerstandänderungen
• Sonderpreise (verwenden Sie das Attribut sale_price mit sale_price_effective_date)

Umgang mit Produktvarianten (Kombinationen)

PrestaShop-Kombinationen erfordern eine spezielle Handhabung in Produkt-Feeds. Jede Kombination sollte als separates Element eingereicht werden mit:

• Einer eindeutigen id (z.B. produkt_id-kombinations_id)
• Dem übergeordneten Produkt gruppiert über item_group_id
• Spezifischen Attributen wie color, size, material
• Dem korrekten Preis für die spezifische Kombination
• Dem Bild, das die spezifische Variante zeigt (falls verfügbar)

Feed-Generierung mit Cron automatisieren

# Google Shopping Feed alle 6 Stunden regenerieren
0 */6 * * * php /var/www/html/modules/ihrfeedmodul/cron.php > /dev/null 2>&1

# Oder wenn Ihr Modul einen URL-basierten Cron bietet
0 */6 * * * curl -s "https://ihrshop.com/modules/ihrfeedmodul/cron.php?token=IHR_TOKEN" > /dev/null 2>&1

Häufige Feed-Probleme beheben

Produkte wegen fehlender Kennzeichnungen abgelehnt

Wenn Google Produkte wegen fehlender GTIN/MPN ablehnt, prüfen Sie, dass das EAN-13-Feld in PrestaShop für jedes Produkt ausgefüllt ist, die GTIN gültig ist und der Hersteller für jedes Produkt gesetzt ist.

Preisabweichungsfehler

Dies tritt auf, wenn der Preis in Ihrem Feed nicht mit dem auf der Produktseite angezeigten Preis übereinstimmt. Häufige Ursachen: Feed zeigt Preis ohne MwSt., aber Produktseite zeigt Preis mit MwSt., Währungsabweichung, oder Warenkorb-Regeln, die den angezeigten Preis ändern.

Bildablehnung

Google lehnt Bilder ab, die zu klein sind, Wasserzeichen haben oder Werbetext enthalten. Stellen Sie sicher, dass Ihre Produktbilder mindestens 100x100 Pixel groß sind, keine Textüberlagerungen haben und das Produkt mindestens 75% der Bildfläche ausfüllt.

Feed-Performance messen

Überwachen Sie im Google Merchant Center aktive Produkte, abgelehnte Produkte, Klickrate und Impression Share. Im Meta Commerce Manager prüfen Sie die Katalogdiagnose und die Item-Match-Rate.

Was Google Lighthouse misst

Google Lighthouse ist ein automatisiertes Audit-Tool, das in die Chrome DevTools integriert ist und Webseiten in vier Hauptkategorien bewertet: Performance, Barrierefreiheit, Best Practices und SEO. Jede Kategorie erzeugt eine Bewertung von 0 bis 100, und jede Bewertung wird aus spezifischen Metriken und Prüfungen berechnet, die unterschiedliche Gewichtungen haben. Zu verstehen, was diese Bewertungen tatsächlich für einen PrestaShop-Shop bedeuten und welche realistischen Ziele erreichbar sind, ist wesentlich, bevor Sie Zeit in die Optimierung investieren.

Lighthouse läuft in zwei Umgebungen. Labordaten stammen aus einer simulierten Umgebung mit kontrollierter Netzwerkdrosselung und CPU-Verlangsamung. Felddaten stammen von echten Benutzern über den Chrome User Experience Report (CrUX). Die Bewertungen, die Sie beim Ausführen von Lighthouse in den Chrome DevTools sehen, sind Labordaten. Die Bewertungen, die Google für Ranking-Zwecke verwendet (Core Web Vitals), stammen aus Felddaten. Diese Unterscheidung ist wichtig, da Labor- und Feldergebnisse oft erheblich voneinander abweichen und die Optimierung für das eine nicht immer das andere verbessert.

Für PrestaShop-Shops ist Lighthouse besonders aufschlussreich, da die Standardkonfiguration von PrestaShop und die meisten Themes nicht für moderne Performance-Standards optimiert sind. Ein typischer nicht optimierter PrestaShop-Shop erzielt zwischen 15 und 40 bei der Performance, 60 bis 80 bei der Barrierefreiheit, 70 bis 85 bei Best Practices und 75 bis 90 bei SEO. Diese Ausgangswerte zeigen Ihnen, wo die größten Verbesserungsmöglichkeiten liegen.

Performance-Bewertung: Die komplexeste Kategorie

Die Performance-Bewertung ist ein gewichtetes Gesamtergebnis aus sechs Metriken. Jede Metrik erfasst einen anderen Aspekt davon, wie schnell die Seite lädt und interaktiv wird. Das Verständnis der einzelnen Metriken ist weitaus nützlicher als die Fokussierung auf die Gesamtzahl.

Largest Contentful Paint (LCP)

LCP misst, wann das größte sichtbare Inhaltselement fertig gerendert ist. Auf einer PrestaShop-Produktseite ist dies normalerweise das Hauptproduktbild. Auf einer Kategorieseite könnte es das erste Produktbild oder ein Kategorie-Banner sein. Google betrachtet LCP als gut, wenn er unter 2,5 Sekunden liegt, als verbesserungswürdig zwischen 2,5 und 4 Sekunden und als schlecht über 4 Sekunden.

PrestaShop-spezifische LCP-Probleme umfassen übergroße Produktbilder, die ohne ordnungsgemäße responsive Größenanpassung ausgeliefert werden, render-blockierendes CSS von Modulen, die auf jeder Seite laden, Server-Antwortzeiten, die durch nicht optimierte Datenbankabfragen verlangsamt werden (besonders auf Kategorieseiten mit vielen Produkten), und JavaScript von Drittanbieter-Modulen, das die Rendering-Pipeline verzögert.

Um den LCP in PrestaShop zu verbessern, beginnen Sie mit der Bildoptimierung. Stellen Sie sicher, dass Produktbilder für jeden Kontext richtig dimensioniert sind (liefern Sie kein 2000x2000-Bild, wenn der Anzeigebereich 400x400 ist). Aktivieren Sie Lazy Loading für Bilder unterhalb des sichtbaren Bereichs, aber stellen Sie sicher, dass das LCP-Bild NICHT lazy geladen wird, da dies sein Rendering verzögert. Implementieren Sie Preload-Hinweise für das LCP-Bild mit einem <link rel="preload">-Tag im Seitenkopf. Serverseitig aktivieren Sie OPcache, konfigurieren Sie MySQL-Query-Caching und stellen Sie sicher, dass Ihr Hosting über ausreichende Ressourcen verfügt.

Cumulative Layout Shift (CLS)

CLS misst die visuelle Stabilität. Jedes Mal, wenn ein sichtbares Element seine Position nach dem ersten Rendern ändert, trägt es zur CLS-Bewertung bei. Google betrachtet CLS als gut, wenn er unter 0,1 liegt, als verbesserungswürdig zwischen 0,1 und 0,25 und als schlecht über 0,25.

PrestaShop-Shops leiden häufig unter CLS, verursacht durch Bilder, die ohne definierte Abmessungen laden (der Browser weiß nicht, wie viel Platz reserviert werden soll, sodass der Inhalt springt, wenn das Bild lädt), Web-Schriftarten, die laden und Text zum Neuanordnen bringen (FOUT, Flash of Unstyled Text), dynamisch eingefügte Banner oder Benachrichtigungsleisten von Modulen, Cookie-Consent-Banner, die den Seiteninhalt nach unten drücken, und lazy-geladene Produktbilder in Rastern, die umliegende Produkte verschieben, wenn sie erscheinen.

Die Behebung von CLS in PrestaShop erfordert das Setzen expliziter Breiten- und Höhenattribute auf allen Bildern (oder die Verwendung von CSS aspect-ratio), das Vorladen kritischer Web-Schriftarten mit font-display: swap oder font-display: optional, das Reservieren von Platz für dynamische Elemente wie Cookie-Banner mittels CSS min-height und das Sicherstellen, dass Werbe- oder Promotions-Module Inhalte einfügen, ohne bestehende Elemente zu verschieben.

First Contentful Paint (FCP)

FCP misst, wann das erste Inhaltselement auf dem Bildschirm erscheint. Dies kann Text, ein Bild, ein SVG oder ein Canvas-Element sein. Bei PrestaShop wird FCP stark von der Serverantwortzeit (Time to First Byte) und der Menge an render-blockierenden Ressourcen (CSS und JavaScript) beeinflusst, die heruntergeladen werden müssen, bevor der Browser etwas anzeigen kann.

Die Standardkonfiguration von PrestaShop lädt eine erhebliche Menge an CSS und JavaScript synchron im Head jeder Seite. Jedes installierte Modul kann eigene CSS- und JavaScript-Dateien hinzufügen. Ein Shop mit 30 Modulen könnte 15 bis 25 separate CSS-Dateien und 20 bis 30 JavaScript-Dateien laden, bevor irgendein Inhalt erscheint. Dies erhöht direkt den FCP.

Total Blocking Time (TBT)

TBT misst die Gesamtzeit zwischen FCP und Time to Interactive, in der der Haupt-Thread lang genug blockiert war, um die Eingabereaktion zu verhindern. Jede Aufgabe, die länger als 50 Millisekunden dauert, zählt mit ihrer überschüssigen Zeit zum TBT. Beispielsweise trägt eine 200-Millisekunden-Aufgabe 150 Millisekunden zum TBT bei.

PrestaShop-Shops sind berüchtigt für hohe TBT-Werte. Häufige Verursacher sind jQuery und seine Plugins, die synchron ausgeführt werden, Modul-JavaScript, das beim Seitenladen schwere DOM-Manipulationen durchführt, Analytics- und Tracking-Code von mehreren Modulen, Produktseiten-Scripte, die gleichzeitig Slider, Zoom-Funktionalität und Kombinationsselektoren initialisieren, sowie Chat-Widgets und Social-Media-Einbettungen.

Die Reduzierung von TBT erfordert das Verschieben nicht-kritischen JavaScripts, das Aufteilen langer Aufgaben in kleinere asynchrone Blöcke, das Entfernen ungenutzten Modul-JavaScripts und das Laden von Drittanbieter-Widgets nach dem Zeitpunkt, an dem die Seite interaktiv wird.

Speed Index

Der Speed Index misst, wie schnell der sichtbare Bereich der Seite gefüllt wird. Er erfasst den gesamten visuellen Fortschritt des Seitenladens. Eine Seite, auf der Header, Navigation und erste Produktreihe schnell erscheinen, aber der Rest schrittweise lädt, hat einen besseren Speed Index als eine Seite, auf der alles auf einmal nach einer langen Verzögerung erscheint.

Für PrestaShop verbessert sich der Speed Index, wenn Sie das Rendering von Above-the-Fold-Inhalten priorisieren. Das bedeutet, kritisches CSS inline einzufügen (das CSS, das zum Rendern des sichtbaren Bereichs der Seite ohne Scrollen benötigt wird), Below-the-Fold-Bilder zu verschieben und JavaScript zu vermeiden, das das Rendering sichtbarer Inhalte blockiert.

Interaction to Next Paint (INP)

INP hat First Input Delay (FID) im März 2024 als Core Web Vital abgelöst. Es misst die Reaktionsfähigkeit einer Seite über ihren gesamten Lebenszyklus, nicht nur die erste Interaktion. Jeder Klick, jedes Tippen und jeder Tastendruck wird gemessen, und die schlechteste Interaktionslatenz (ungefähr) wird zum INP-Wert. Google betrachtet INP als gut unter 200 Millisekunden.

PrestaShop-Shops haben oft schlechte INP-Werte auf Produktseiten, wo das Klicken auf ein Kombinationsattribut eine synchrone AJAX-Anfrage auslöst, die die Benutzeroberfläche blockiert, auf Kategorieseiten, wo Klicks auf Facetten-Filter schwere JavaScript-Verarbeitung verursachen, und auf jeder Seite, auf der Modul-JavaScript während der Benutzerinteraktion den Haupt-Thread monopolisiert.

Barrierefreiheits-Bewertung

Die Barrierefreiheits-Bewertung bewertet, ob Ihre Seite von Menschen mit Behinderungen genutzt werden kann, einschließlich derer, die Screenreader, Tastaturnavigation oder andere Hilfstechnologien verwenden. Lighthouse prüft auf spezifische WCAG 2.1-Konformitätselemente und weist jedem eine Gewichtung basierend auf der Benutzerauswirkung zu.

Häufige PrestaShop-Barrierefreiheitsfehler

Fehlender Alt-Text bei Bildern ist das häufigste Problem. PrestaShop-Shops mit Tausenden von Produkten haben oft Produkte, die ohne Alt-Text-Beschreibungen hochgeladen wurden. Lighthouse markiert jedes Bild ohne Alt-Attribut. Die Lösung besteht darin, allen Produktbildern über das Back Office aussagekräftigen Alt-Text hinzuzufügen, was auch der SEO zugutekommt.

Unzureichender Farbkontrast ist in PrestaShop-Themes extrem verbreitet. Der Theme-Designer hat möglicherweise Farben gewählt, die visuell ansprechend aussehen, aber nicht das WCAG-Mindest-Kontrastverhältnis von 4,5:1 für normalen Text und 3:1 für großen Text erfüllen. Typische Probleme sind hellgrauer Text auf weißem Hintergrund (oft für Produktpreise, Beschreibungen oder Footer-Links verwendet), weißer Text auf farbigen Buttons, deren Farbe nicht dunkel genug ist, und Platzhaltertext in Suchfeldern.

Fehlende Formularbeschriftungen betreffen PrestaShops Suchformulare, Newsletter-Anmeldeformulare und Kontaktformulare. Viele Themes verwenden Platzhaltertext als einzigen Hinweis darauf, wofür ein Eingabefeld gedacht ist, aber Platzhalter sind keine barrierefreien Beschriftungen. Jedes Eingabefeld muss ein zugehöriges <label>-Element haben.

Fehlerhafte Überschriftenhierarchie ist häufig, wenn Themes Überschriftenebenen überspringen (von <h1> auf <h3> springen) oder wenn Module Inhalte mit Überschriftenebenen einfügen, die die Dokumentgliederung der Seite durchbrechen.

Fehlende ARIA-Attribute bei interaktiven Elementen wie Dropdown-Menüs, modalen Dialogen und Tab-Interfaces bedeuten, dass Screenreader den Zweck und Zustand dieser Elemente nicht an die Benutzer vermitteln können.

Realistische Barrierefreiheitsziele

Die meisten PrestaShop-Themes können mit Aufwand 85 bis 95 erreichen. Eine perfekte 100 ist erreichbar, erfordert aber Theme-Template-Modifikationen, die bei Updates überschrieben werden können. Konzentrieren Sie sich zuerst auf die Elemente mit der größten Wirkung: Bild-Alt-Text, Farbkontrast, Formularbeschriftungen und Tastaturnavigation für die wichtigsten Benutzerabläufe (Stöbern, In den Warenkorb legen, Checkout).

Best-Practices-Bewertung

Die Kategorie Best Practices umfasst allgemeine Signale für die Qualität der Webentwicklung: HTTPS-Nutzung, Vermeidung veralteter APIs, Fehlerfreiheit in der Konsole und Sicherheits-Header.

Häufige PrestaShop Best-Practices-Fehler

Browser-Konsolenfehler werden von Lighthouse markiert. PrestaShop-Shops haben häufig JavaScript-Fehler durch Modulkonflikte, veraltete jQuery-Funktionsaufrufe oder fehlgeschlagene AJAX-Anfragen. Jeder Konsolenfehler reduziert die Best-Practices-Bewertung. Überprüfen Sie Ihre Browser-Konsole auf jedem Seitentyp (Startseite, Kategorie, Produkt, Warenkorb, Checkout) und beheben oder unterdrücken Sie die Fehler.

Fehlende Sicherheits-Header reduzieren die Bewertung. PrestaShop setzt standardmäßig keine Header wie Content-Security-Policy, X-Content-Type-Options, Permissions-Policy oder Referrer-Policy. Das Hinzufügen dieser über Ihre .htaccess oder Webserver-Konfiguration verbessert die Best-Practices-Bewertung und die Sicherheitslage Ihrer Website.

Veraltete APIs lösen Warnungen aus, wenn ältere PrestaShop-Themes oder -Module JavaScript-APIs verwenden, die Browser als veraltet eingestuft haben. Häufige Beispiele sind document.write(), synchrone XMLHttpRequest und der unload-Event-Listener. Diese finden sich typischerweise in älteren Modulen, die nicht für moderne Browser-Standards aktualisiert wurden.

Mixed Content (Laden von HTTP-Ressourcen auf einer HTTPS-Seite) wird schwerwiegend markiert. Dies passiert, wenn Modul-Assets, externe Schriftarten oder Tracking-Pixel HTTP-URLs verwenden. Stellen Sie sicher, dass alle Ressourcen über HTTPS geladen werden.

Bilder ohne explizite Breite und Höhe (was auch CLS unter Performance beeinflusst) werden hier ebenfalls markiert. PrestaShop-Themes, die CSS-only-Dimensionierung für Bilder verwenden, ohne HTML-Attribute zu setzen, lösen diese Prüfung aus.

Realistische Best-Practices-Ziele

Ein gut gewarteter PrestaShop-Shop sollte 90 bis 100 anstreben. Die meisten Best-Practices-Probleme sind unkompliziert über Serverkonfiguration und Modul-Bereinigung zu beheben.

SEO-Bewertung

Das SEO-Audit prüft grundlegende technische SEO-Anforderungen. Dies ist die einfachste Kategorie, um gut abzuschneiden, da die Prüfungen unkompliziert sind und PrestaShop viele davon standardmäßig erfüllt.

Was Lighthouse bei SEO prüft

Das Audit überprüft, ob die Seite ein gültiges <title>-Tag hat, eine Meta-Beschreibung, ein gültiges Viewport-Meta-Tag, ob Links beschreibenden Text haben (nicht nur "hier klicken"), ob die Seite nicht von der Indexierung blockiert ist, ob Bilder Alt-Attribute haben, ob das Dokument ein gültiges hreflang-Attribut hat, wenn es mehrere Sprachen bedient, ob die Schriftgröße auf Mobilgeräten lesbar ist und ob Tap-Targets (Buttons, Links) ausreichend groß und beabstandet sind.

Häufige PrestaShop-SEO-Fehler

Fehlende oder doppelte Meta-Beschreibungen sind häufig bei Kategorieseiten, besonders bei automatisch generierten. PrestaShop ermöglicht es Ihnen, Meta-Beschreibungen pro Kategorie und pro Produkt festzulegen, aber viele Shopbetreiber lassen diese Felder während des Massenimports von Produkten leer.

Nicht-beschreibender Linktext erscheint, wenn Themes generischen Text wie "Mehr lesen" oder "Details" für Produktlinks verwenden, ohne zusätzlichen Kontext. Screenreader und Lighthouse markieren diese gleichermaßen.

Kleine Tap-Targets betreffen mobile Benutzer. PrestaShop-Themes mit kompakten Produktrastern auf Mobilgeräten können Links und Buttons haben, die zu nah beieinander oder zu klein sind. Google empfiehlt ein minimales Touch-Target von 48x48 CSS-Pixeln mit mindestens 8 Pixeln Abstand zwischen benachbarten Zielen.

Blockierte Ressourcen können dazu führen, dass Lighthouse meldet, dass JavaScript- oder CSS-Dateien nicht zugänglich sind. Dies passiert, wenn robots.txt den Zugriff auf Asset-Verzeichnisse blockiert. PrestaShops Standard-robots.txt blockiert manchmal Verzeichnisse, die CSS- oder JavaScript-Dateien enthalten, die für das Rendering durch Suchmaschinen benötigt werden.

Realistische SEO-Ziele

Ein PrestaShop-Shop sollte 90 bis 100 beim SEO-Audit anstreben. Die meisten Punkte sind einfache Konfigurationsanpassungen. Die eine anhaltende Herausforderung ist Bild-Alt-Text bei Shops mit großen Katalogen und historischen Importen, bei denen Alt-Text übersprungen wurde.

Labordaten vs. Felddaten

Das Verständnis des Unterschieds zwischen Labor- und Felddaten ist entscheidend für die korrekte Interpretation von Lighthouse-Ergebnissen und die Priorisierung Ihrer Optimierungsarbeit.

Labordaten (Lighthouse)

Wenn Sie Lighthouse aus den Chrome DevTools oder der Kommandozeile ausführen, erstellt es eine simulierte Umgebung. Es drosselt die Netzwerkverbindung (typischerweise auf eine langsame 4G-Geschwindigkeit von etwa 1,6 Mbit/s mit 150 ms Latenz) und verlangsamt die CPU (typischerweise 4-fache Verlangsamung). Diese simulierte Umgebung liefert konsistente, reproduzierbare Ergebnisse, spiegelt aber nicht die Erfahrung eines bestimmten realen Benutzers wider.

Labordaten sind nützlich zum Debuggen spezifischer Probleme, zum Vergleichen von Vor- und Nach-Optimierungsänderungen und zur Identifizierung spezifischer Engpässe im Ladeprozess. Die Bewertungen sollten jedoch nicht als repräsentativ für die reale Benutzererfahrung betrachtet werden.

Felddaten (CrUX)

Der Chrome User Experience Report (CrUX) sammelt echte Performance-Daten von Chrome-Benutzern, die dem Teilen von Nutzungsstatistiken zugestimmt haben. Diese Daten werden am 75. Perzentil aggregiert, was bedeutet, dass der gemeldete Wert die Erfahrung von 75 Prozent Ihrer Benutzer repräsentiert, die bei oder besser als diesem Schwellenwert liegen.

Felddaten sind das, was Google tatsächlich als Ranking-Signale über die Core Web Vitals verwendet. Sie können Ihre Felddaten in der Google Search Console unter dem Core Web Vitals-Bericht einsehen, in PageSpeed Insights (das sowohl Labor- als auch Felddaten zeigt) und über die CrUX-API oder den BigQuery-Datensatz.

Warum sich die Bewertungen unterscheiden

Laborbewertungen sind typischerweise niedriger als Feldbewertungen für PrestaShop-Shops, da Lighthouse aggressive Drosselung verwendet. Ein Shop auf einem schnellen Server mit CDN könnte im Lighthouse-Labormodus 35 erzielen, aber perfekt akzeptable Feldmetriken haben, weil echte Benutzer mit ordentlichen Verbindungen den Shop viel schneller erleben als die simulierte langsame 4G-Umgebung. Umgekehrt können Shops mit Problemen, die nur unter realen Bedingungen auftreten (JavaScript-Fehler bestimmter Browser-Versionen, Verlangsamung durch Drittanbieter-Widgets oder geografische Latenz zu Benutzern weit vom Server entfernt), bessere Laborbewertungen als Feldbewertungen haben.

Was priorisieren

Für Google-Ranking-Zwecke priorisieren Sie Felddaten und Core Web Vitals (LCP, INP, CLS). Für Entwickler-Debugging und Optimierungsarbeit verwenden Sie Labordaten, da sie konsistent sind und detaillierte Diagnoseinformationen liefern. Wenn Ihre Felddaten bestandene Core Web Vitals zeigen, aber Ihre Labor-Performance-Bewertung 40 ist, geht es Ihren Benutzern gut und Google wird Sie nicht benachteiligen. Wenn Ihre Laborbewertung 90 ist, aber Felddaten fehlgeschlagene Core Web Vitals zeigen, haben Sie ein Problem, das Lab-Tests nicht erfassen.

Realistische Bewertungsziele für PrestaShop

Das Setzen realistischer Ziele verhindert verschwendeten Aufwand bei der Jagd nach abnehmendem Grenznutzen. Hier sind erreichbare Ziele für einen typischen PrestaShop 1.7 oder 8.x Shop.

Performance: 50 bis 75 (Mobil), 80 bis 95 (Desktop)

Mobile Performance-Bewertungen über 75 sind für PrestaShop-Shops mit reichhaltigen Produktseiten, mehreren Modulen und dynamischen Inhalten extrem schwierig. Die gedrosselte mobile Simulation ist streng. Eine Bewertung von 50 bis 65 auf Mobilgeräten mit bestandenen Core Web Vitals in Felddaten ist ein gutes Ergebnis. Desktop-Bewertungen von 85 bis 95 sind mit Standard-Optimierungen erreichbar.

Jagen Sie nicht einer mobilen Performance-Bewertung von 100 nach. Der Aufwand, um von 70 auf 100 auf Mobilgeräten zu kommen, erfordert typischerweise das Entfernen von Funktionen, die Ihr Shop benötigt (Produktbild-Zoom, dynamische Warenkorb-Updates, Kombinationsselektoren). Konzentrieren Sie sich stattdessen darauf, die Core Web Vitals-Schwellenwerte in Felddaten zu bestehen.

Barrierefreiheit: 85 bis 95

Dieser Bereich ist mit Theme-Template-Korrekturen und inhaltlicher Disziplin erreichbar. Der hauptsächliche laufende Aufwand besteht darin sicherzustellen, dass alle neuen Produkte Alt-Text haben und dass neue Module keine Rückschritte bei der Barrierefreiheit einführen.

Best Practices: 90 bis 100

Erreichbar mit Serverkonfiguration, Bereinigung von Konsolenfehlern und aktuell gehaltenen Modulen. Diese Bewertung tendiert dazu, im Laufe der Zeit zu sinken, wenn neue Module hinzugefügt werden, daher hilft regelmäßige Überwachung.

SEO: 90 bis 100

Am einfachsten zu erreichen und zu halten. Die meisten Punkte sind einmalige Konfigurationsanpassungen.

Handlungsorientierte Verbesserungs-Checkliste

Diese Checkliste priorisiert Optimierungen nach Wirkung, beginnend mit den Änderungen, die die größten Bewertungsverbesserungen bei geringstem Aufwand erzielen.

Hohe Wirkung, geringer Aufwand

Aktivieren Sie PrestaShops CCC-Funktion (Combine, Compress, Cache) unter den Performance-Einstellungen, um CSS- und JavaScript-Dateien zusammenzuführen und zu minifizieren. Fügen Sie Breiten- und Höhenattribute zu allen Bildern in Theme-Templates hinzu. Setzen Sie explizite Abmessungen für Produktbilder. Aktivieren Sie Browser-Caching durch ordnungsgemäße Cache-Header in Ihrer Serverkonfiguration. Komprimieren Sie Textressourcen mit Gzip oder Brotli. Entfernen oder deaktivieren Sie Module, die Sie nicht aktiv nutzen. Fügen Sie Sicherheits-Header zu Ihrer Serverkonfiguration hinzu.

Hohe Wirkung, mittlerer Aufwand

Implementieren Sie kritisches CSS-Inlining für Above-the-Fold-Inhalte. Verschieben Sie nicht-kritisches JavaScript mit dem Attribut defer oder async. Optimieren und dimensionieren Sie Produktbilder richtig (liefern Sie verschiedene Größen für verschiedene Kontexte mittels srcset). Laden Sie kritische Ressourcen vor (LCP-Bild, primäre Schriftdateien). Beheben Sie alle Browser-Konsolenfehler. Fügen Sie fehlenden Alt-Text zu allen Produkt- und Kategoriebildern hinzu.

Mittlere Wirkung, höherer Aufwand

Implementieren Sie ein CDN für statische Assets und Bilder. Wechseln Sie zu einem performance-orientierteren PrestaShop-Theme, wenn Ihr aktuelles Theme grundlegend langsam ist. Optimieren Sie die serverseitige Leistung (Datenbankindizes, OPcache, Redis für Caching). Implementieren Sie WebP-Bildauslieferung mit JPEG-Fallback. Auditieren und optimieren Sie Drittanbieter-Modul-JavaScript hinsichtlich der Blockierung des Haupt-Threads.

Überwachung über die Zeit

Ein einmaliges Lighthouse-Audit ist weniger wertvoll als regelmäßige Überwachung. Bewertungen ändern sich, wenn Sie Produkte hinzufügen, Module installieren, Themes aktualisieren und Konfigurationen ändern. Richten Sie automatisierte Lighthouse-Tests ein mit Tools wie Google PageSpeed Insights API, web.dev Measure oder selbst gehostetem Lighthouse CI. Führen Sie Tests mindestens wöchentlich und nach jeder signifikanten Shop-Änderung durch.

Verfolgen Sie sowohl die Gesamtbewertungen als auch die einzelnen Metriken. Ein Rückgang der Performance-Bewertung von 65 auf 55 ist besorgniserregend, aber zu wissen, dass er durch eine CLS-Regression eines neu installierten Banner-Moduls verursacht wurde, ist handlungsfähig. Ohne Tracking auf Metrikebene raten Sie bei den Ursachen.

Achten Sie besonders auf Core Web Vitals in der Google Search Console. Google aktualisiert diese Daten monatlich, und jede Verschlechterung von "Gut" auf "Verbesserungswürdig" oder "Schlecht" kann Ihre Suchrankings beeinflussen. Richten Sie Warnungen für Core-Web-Vitals-Änderungen ein, damit Sie reagieren können, bevor die Auswirkung in den Traffic-Daten sichtbar wird.

Die versteckten Kosten maschinell übersetzter E-Commerce-Inhalte

Die Erweiterung eines PrestaShop-Shops um mehrere Sprachen ist eine der effektivsten Möglichkeiten, den Umsatz zu steigern. Studien zeigen konsistent, dass Verbraucher es überwältigend bevorzugen, in ihrer Muttersprache einzukaufen, und ein erheblicher Prozentsatz wird nicht auf einer Website kaufen, die nur in einer Fremdsprache verfügbar ist. Die Chance ist klar. Die Frage ist, wie man dorthin gelangt.

Die Versuchung, maschinelle Übersetzung zu verwenden, ist groß. Moderne KI-Übersetzungstools sind schneller und günstiger denn je. Sie können einen gesamten Produktkatalog mit 5.000 Produkten in fünf Sprachen in Minuten statt in Monaten übersetzen. Aber Geschwindigkeit und Kosteneinsparungen haben einen Preis, der nicht sofort sichtbar ist. Dieser Preis zeigt sich in Ihren Suchplatzierungen, Ihren Konversionsraten, Ihren Retourenquoten und Ihrer Markenwahrnehmung. In den folgenden Monaten und Jahren untergräbt schlecht übersetzter Inhalt leise den Wert Ihrer internationalen Expansion.

Dieser Artikel untersucht, warum maschinelle Übersetzung allein für E-Commerce-Inhalte unzureichend ist, wo sie den größten Schaden anrichtet und wie Sie eine Übersetzungsstrategie aufbauen, die Qualität und Budget in Einklang bringt. Es geht hier nicht darum, maschinelle Übersetzung grundsätzlich abzulehnen. Es geht darum zu verstehen, wo sie funktioniert, wo sie versagt und wie man sie als ein Werkzeug unter mehreren einsetzt – und nicht als die gesamte Lösung.

Wie maschinelle Übersetzung bei E-Commerce-Inhalten versagt

Maschinelle Übersetzung hat bemerkenswerte Fortschritte gemacht. Für das beiläufige Lesen, Nachrichtenartikel und die allgemeine Kommunikation liefern Tools wie Google Translate und DeepL überraschend brauchbare Ergebnisse. Aber E-Commerce-Inhalte haben spezifische Eigenschaften, die die Schwächen der maschinellen Übersetzung offenlegen.

Produktnamen und Markenbegriffe

Maschinelle Übersetzungssysteme verstehen nicht, dass Produktnamen, Markennamen und proprietäre Begriffe nicht übersetzt werden sollten. Ein Produkt namens "Summer Breeze Moisturizer" könnte wörtlich ins Deutsche als "Sommer Brise Feuchtigkeitscreme" übersetzt werden, wobei die Markenidentität vollständig verloren geht. Technische Produktnamen leiden noch stärker. Ein "DIN-Schienenmontagebügel", der durch ein allgemeines Übersetzungstool geleitet wird, kann einen technisch falschen Begriff produzieren, der Fachleute verwirrt, die genau wissen, was sie brauchen.

In PrestaShop erscheinen Produktnamen an mehreren kritischen Stellen: dem Titel der Produktseite, der Kategorieauflistung, dem Warenkorb, der Bestellbestätigung, der Rechnung und dem Versandlabel. Ein falsch übersetzter Produktname pflanzt sich durch jeden Berührungspunkt der Customer Journey fort.

Einheiten und Spezifikationen

Produktspezifikationen erfordern präzise Terminologie. Gewicht, Abmessungen, Materialzusammensetzungen, Spannungsangaben und Kompatibilitätsinformationen müssen die korrekten Fachbegriffe und Einheiten für jeden Zielmarkt verwenden. Maschinelle Übersetzung produziert oft ungefähre Begriffe, die plausibel klingen, aber technisch falsch sind. Ein Produkt, das als aus "Edelstahl" beschrieben wird, könnte in eine Bezeichnung übersetzt werden, die in der Zielsprache tatsächlich "verchromter Stahl" bedeutet – ein völlig anderes Material mit anderen Eigenschaften und Preispunkten.

Maßeinheiten variieren ebenfalls je nach Markt. Einige Länder verwenden ausschließlich das metrische System, andere verwenden das imperiale System, und manche verwenden eine Mischung je nach Produktkategorie. Maschinelle Übersetzung konvertiert keine Einheiten und passt sich nicht an lokale Konventionen an. Sie übersetzt den Text wörtlich, was eine technisch korrekte Übersetzung erzeugen kann, die dennoch für den lokalen Käufer verwirrend oder wenig hilfreich ist.

Ton und Überzeugungskraft

Produktbeschreibungen sind Verkaufstexte. Sie werden geschrieben, um zu überzeugen, Verlangen zu wecken und Einwände zu überwinden. Dies erfordert ein Verständnis kultureller Erwartungen, das maschinelle Übersetzung schlicht nicht besitzt. Deutsche Käufer erwarten detaillierte technische Spezifikationen und Präzision. Französische Käufer reagieren auf Eleganz und Lifestyle-Rahmung. Japanische Käufer schätzen Höflichkeitsmarker und gruppenorientierte Sprache. Eine Produktbeschreibung, die auf Englisch gut konvertiert, kann in einer anderen Sprache völlig wirkungslos sein – nicht weil die Übersetzung Wort für Wort falsch ist, sondern weil der überzeugende Ansatz nicht mit der Zielkultur resoniert.

Maschinelle Übersetzung bewahrt die Überzeugungsstruktur der Ausgangssprache und ändert dabei die Wörter. Das ist genau das Gegenteil von effektivem Verkauf. Was Sie brauchen, ist die Verkaufsabsicht beizubehalten und die Überzeugungsstruktur an die Zielkultur anzupassen.

Rechts- und Compliance-Texte

Allgemeine Geschäftsbedingungen, Rückgaberichtlinien, Garantieinformationen und regulatorische Compliance-Texte müssen in jedem Markt rechtlich korrekt sein. Maschinell übersetzter Rechtstext ist nicht nur wenig hilfreich – er kann rechtlich gefährlich sein. Eine Rückgaberichtlinie, die aufgrund schlechter Übersetzung mehrdeutige Formulierungen verwendet, könnte in einem Streitfall zugunsten des Kunden ausgelegt werden. Ein Garantieausschluss, der nicht die korrekten juristischen Fachbegriffe verwendet, könnte nicht durchsetzbar sein. DSGVO-Datenschutzhinweise, die aufgrund schlechter Übersetzung unverständlich sind, erfüllen möglicherweise nicht die Anforderung der Verordnung an eine "klare und einfache Sprache".

Die SEO-Auswirkungen schlechter Übersetzungen

Suchmaschinen sind zunehmend in der Lage, die Inhaltsqualität zu bewerten, und schlecht übersetzter Inhalt ist eines der Signale, die sie zur Qualitätsbewertung heranziehen. Die Auswirkungen auf SEO sind sowohl direkt als auch indirekt.

Keyword-Diskrepanz

Wenn Menschen in ihrer Muttersprache suchen, verwenden sie spezifische Begriffe und Phrasen, die möglicherweise nicht die wörtliche Übersetzung des englischen Suchbegriffs sind. Im Deutschen bedeutet das Wort "Handy" "Mobiltelefon", aber kein englischer Muttersprachler würde das erraten. Im Niederländischen bedeutet "actueel" "aktuell" oder "auf dem neuesten Stand", nicht "tatsächlich". Maschinelle Übersetzung kann keine Keyword-Recherche durchführen. Sie übersetzt die Wörter, die Sie ihr geben, nicht die Wörter, nach denen Ihre Zielgruppe tatsächlich sucht.

Effektives mehrsprachiges SEO erfordert Keyword-Recherche in jeder Zielsprache. Sie müssen wissen, welche Begriffe Suchvolumen haben, welche Begriffe kommerzielle Absicht aufweisen und welche Begriffe zu Ihren Produkten passen. Dies ist eine grundlegend andere Aufgabe als Übersetzung, und maschinelle Übersetzung versucht es nicht einmal.

In PrestaShop speichert die Tabelle ps_product_lang die Felder meta_title, meta_description und link_rewrite für jede Sprache. Diese Felder bestimmen direkt, wie Ihre Produkte in den Suchergebnissen erscheinen. Maschinell übersetzte Meta-Titel und -Beschreibungen performen schlecht, weil sie übersetzte Phrasen statt gesuchter Phrasen verwenden.

Dünner Content und Qualitätssignale

Googles Algorithmen bewerten die Inhaltsqualität anhand zahlreicher Signale, darunter Lesbarkeit, thematische Relevanz und Nutzerinteraktionsmetriken. Maschinell übersetzter Content liest sich oft holprig, mit unnatürlichen Satzstrukturen, falschen Kollokationen (Wortkombinationen, die für Muttersprachler falsch klingen) und inkonsistenter Terminologie. Nutzer, die auf solchen Seiten landen, neigen dazu, schnell abzuspringen, weniger Zeit auf der Seite zu verbringen und sich seltener mit internen Links zu beschäftigen.

Diese Verhaltenssignale sagen den Suchmaschinen, dass der Inhalt die Nutzerabsicht nicht befriedigt, was zu niedrigeren Rankings führt. Im Laufe der Zeit kann ein Muster minderwertigen übersetzten Contents die Gesamtautorität der Domain im Zielsprachmarkt beeinträchtigen.

Hreflang und Duplicate Content

PrestaShop unterstützt mehrsprachigen Content durch sein integriertes Sprachsystem, und korrekt konfigurierte Shops verwenden hreflang-Tags, um Suchmaschinen mitzuteilen, welche Sprachversion einer Seite welchen Nutzern angezeigt werden soll. Das hreflang-Setup selbst ist technisch, aber unkompliziert. Das Problem entsteht, wenn der Content hinter den hreflang-Tags von geringer Qualität ist.

Wenn Ihre französischen und spanischen Versionen maschinell übersetzt sind und ein schlechtes Nutzererlebnis bieten, könnten Suchmaschinen stattdessen die englische Version für französische und spanische Nutzer anzeigen oder überhaupt keine Version gut ranken. Hreflang-Tags sind ein Vorschlag an Suchmaschinen, kein Befehl. Wenn der lokalisierte Content schlecht ist, treffen Suchmaschinen ihre eigene Entscheidung darüber, welche Version ausgeliefert wird.

Die korrekte Einrichtung von hreflang-Tags in PrestaShop erfordert, dass jede Sprache eine eigene URL-Struktur hat (entweder Unterverzeichnisse wie /fr/ und /es/ oder separate Domains) und dass die hreflang-Tags auf jeder Seite alle anderen Sprachversionen referenzieren. PrestaShop handhabt dies automatisch über seine Sprachkonfiguration, aber das technische Setup funktioniert nur, wenn der Content dahinter es wert ist, indexiert zu werden.

Wie schlechte Übersetzungen die Konversionsrate beeinträchtigen

Über SEO hinaus reduzieren schlechte Übersetzungen direkt die Konversionsraten. Der Checkout-Prozess ist der Bereich, in dem der Schaden am größten ist.

Checkout-Abbruch

Der Checkout-Prozess umfasst vertrauenssensible Interaktionen: die Eingabe persönlicher Daten, die Bereitstellung von Zahlungsinformationen und die Zustimmung zu Geschäftsbedingungen. Wenn die Sprache auf der Checkout-Seite unnatürlich, verwirrend oder unprofessionell wirkt, zögern Kunden. Sie hinterfragen, ob der Shop seriös ist, ob ihre Zahlungsinformationen sicher sind und ob sie das erwartete Produkt erhalten werden.

Maschinelle Übersetzung produziert häufig unbeholfene Formulierungen bei Formularbeschriftungen, Schaltflächentexten, Fehlermeldungen und Anleitungstexten. Eine Schaltfläche mit der Aufschrift "Proceed to Payment" könnte in eine Phrase übersetzt werden, die in der Zielsprache steif oder mehrdeutig klingt. Eine Fehlermeldung wie "Please enter a valid phone number" könnte in etwas übersetzt werden, das anklagend oder verwirrend klingt. Diese kleinen Reibungspunkte akkumulieren sich während des gesamten Checkout-Prozesses, und jeder einzelne gibt dem Kunden einen Grund, den Kauf abzubrechen.

Produktseitenvertrauen

Produktbeschreibungen bauen Vertrauen auf. Sie beantworten Fragen, adressieren Bedenken und helfen Kunden, sich vorzustellen, das Produkt zu besitzen. Eine maschinell übersetzte Beschreibung, die sich holprig liest, untergräbt diesen Vertrauensaufbau-Prozess. Kunden, die unsicher sind, was sie kaufen, kaufen nicht. Sie gehen, um einen Wettbewerber zu finden, dessen Produktbeschreibungen sie klar verstehen können.

Dieser Effekt ist besonders stark bei Kaufentscheidungen mit hohem Überlegungsbedarf. Ein Kunde, der eine Handyhülle für 10 Euro kauft, toleriert möglicherweise holprige Produktbeschreibungen. Ein Kunde, der professionelle Ausrüstung für 500 Euro kauft, wird es nicht. Je höher der Preis und je komplexer das Produkt, desto wichtiger wird die Übersetzungsqualität.

Auswirkungen auf die Retourenquote

Schlechte Übersetzungen verhindern nicht nur Verkäufe. Sie verursachen falsche Verkäufe. Wenn eine Produktbeschreibung aufgrund von Übersetzungsfehlern unklar oder irreführend ist, bestellen Kunden möglicherweise ein Produkt, das nicht ihren Erwartungen entspricht. Das Ergebnis sind Retouren, Rückerstattungsbearbeitungskosten, Versandkosten und negative Bewertungen. Ein Kunde, der das falsche Produkt erhält, weil die Beschreibung schlecht übersetzt war, wird wahrscheinlich nicht wiederkommen und sehr wahrscheinlich eine negative Bewertung hinterlassen, was den Schaden noch vergrößert.

Der Checkout-Prozess: Wo jedes Wort zählt

PrestaShops Checkout-Prozess enthält Dutzende übersetzbare Zeichenketten. Diese umfassen Formularbeschriftungen (Vorname, Nachname, Adresse, Stadt, Postleitzahl, Telefon), Schaltflächentexte (Weiter, Bestellung aufgeben, In den Warenkorb), Statusmeldungen (Ihre Bestellung wurde aufgegeben, Zahlung akzeptiert, Versand läuft), Fehlermeldungen (Dieses Feld ist erforderlich, Ungültige E-Mail-Adresse, Karte abgelehnt) und rechtliche Kontrollkästchen (Ich stimme den Allgemeinen Geschäftsbedingungen zu, Ich habe die Datenschutzerklärung gelesen).

Jede dieser Zeichenketten existiert in PrestaShops Übersetzungsdateien. PrestaShop 1.7 und 8.x verwenden eine Kombination aus Symfony-Übersetzungskatalogen und Legacy-Übersetzungsarrays. Das Back Office bietet eine Übersetzungsoberfläche unter International > Übersetzungen, wo Sie jede übersetzbare Zeichenkette im System bearbeiten können.

Speziell für den Checkout-Prozess sollte jede Zeichenkette von einem Muttersprachler überprüft werden. Selbst wenn der Rest Ihres Katalogs maschinelle Übersetzung als Ausgangspunkt verwendet, muss der Checkout-Prozess professionell übersetzt werden. Der ROI ist direkt und messbar: bessere Checkout-Übersetzungen bedeuten weniger abgebrochene Warenkörbe.

Professionelle Übersetzung vs. Maschinelle Übersetzung: Eine Kostenanalyse

Professionelle menschliche Übersetzung kostet typischerweise zwischen 0,08 und 0,25 Euro pro Wort, abhängig vom Sprachpaar, dem Fachgebiet und der Lieferzeit. Technische Inhalte und Marketingtexte haben höhere Tarife. Eine typische Produktbeschreibung von 200 Wörtern kostet zwischen 16 und 50 Euro für die professionelle Übersetzung in eine Sprache.

Für einen Katalog mit 1.000 Produkten mit 200-Wörter-Beschreibungen liegen die Kosten der professionellen Übersetzung in eine Sprache zwischen 16.000 und 50.000 Euro. In fünf Sprachen liegen die Kosten zwischen 80.000 und 250.000 Euro. Diese Zahlen lassen Shop-Betreiber innehalten, und das zu Recht.

Maschinelle Übersetzung kostet einen Bruchteil davon. Selbst der kostenpflichtige API-Zugang zu fortschrittlichen maschinellen Übersetzungsdiensten kostet Cent pro tausend Zeichen. Die Übersetzung desselben 1.000-Produkte-Katalogs könnte unter 100 Euro an API-Gebühren kosten.

Aber der Vergleich dieser Zahlen isoliert betrachtet ist irreführend. Der wahre Kostenvergleich muss die Umsatzauswirkungen einbeziehen. Wenn maschinelle Übersetzung Ihre Konversionsrate im Zielmarkt auch nur um 1-2 Prozentpunkte senkt, übersteigen die Umsatzeinbußen schnell die Einsparungen bei den Übersetzungskosten. Für einen Shop, der 50.000 Euro pro Monat in einem Markt umsetzt, bedeutet ein Rückgang der Konversionsrate um 2% einen Verlust von 1.000 Euro pro Monat, was bedeutet, dass sich die professionelle Übersetzung innerhalb weniger Monate bis zu einem Jahr amortisiert.

Der hybride Ansatz: Das Beste aus beiden Welten

Der kosteneffektivste Ansatz für die meisten PrestaShop-Shops ist eine Hybridstrategie, die maschinelle Übersetzung als Ausgangspunkt und menschliche Überprüfung zur Verfeinerung einsetzt. So implementieren Sie ihn.

Stufe 1: Professionelle Übersetzung

Investieren Sie in vollständige professionelle Übersetzung für Ihre wirkungsstärksten Inhalte. Dazu gehören der Checkout-Prozess und alle transaktionalen E-Mails, Ihre Top 50-100 Produkte nach Umsatz, Ihre Startseite und wichtigsten Landingpages, Ihre Allgemeinen Geschäftsbedingungen und rechtlichen Seiten, Ihre Meta-Titel und Meta-Beschreibungen für SEO-kritische Seiten sowie Ihre Hauptkategoriebeschreibungen.

Stufe 2: Maschinelle Übersetzung plus menschliche Überprüfung

Für den Großteil Ihres Produktkatalogs verwenden Sie maschinelle Übersetzung als ersten Durchgang und lassen dann einen Muttersprachler die Ausgabe überprüfen und korrigieren. Dies wird als Post-Editing bezeichnet und ist deutlich schneller und günstiger als eine Übersetzung von Grund auf. Ein professioneller Übersetzer kann maschinell übersetzten Text drei- bis fünfmal schneller überprüfen und korrigieren als von Null übersetzen, was die Kosten proportional reduziert.

In dieser Stufe korrigiert der menschliche Prüfer sachliche Fehler, passt Ton und Stil an, stellt sicher, dass Fachbegriffe korrekt sind, und optimiert für Suchbegriffe des Zielmarkts. Die maschinelle Übersetzung liefert das strukturelle Gerüst; der Mensch liefert die Qualität und kulturelle Anpassung.

Stufe 3: Nur maschinelle Übersetzung

Für Inhalte mit niedriger Priorität, die minimale Auswirkungen auf SEO und Konversion haben, kann maschinelle Übersetzung allein akzeptabel sein. Dazu gehören interne Back-Office-Inhalte, die nur Ihre Mitarbeiter sehen, alte Blogbeiträge mit geringem Traffic und Produktmerkmale, die rein sachlich und numerisch sind (Abmessungen, Gewicht usw.).

Implementierung in PrestaShop

PrestaShops Übersetzungssystem unterstützt diesen gestuften Ansatz gut. Sie können alle übersetzbaren Zeichenketten exportieren, sie durch eine maschinelle Übersetzungs-API laufen lassen, die Ergebnisse importieren und dann selektiv die hochprioritären Zeichenketten über die Übersetzungsoberfläche im Back Office überprüfen und verbessern.

Mehrere PrestaShop-Module erleichtern diesen Workflow. Übersetzungsmodule können sich mit maschinellen Übersetzungs-APIs verbinden und leere Übersetzungen automatisch ausfüllen. Einige Module unterstützen Translation Memory, das zuvor genehmigte Übersetzungen speichert und sie konsistent über Ihren Katalog hinweg anwendet. Andere integrieren sich mit professionellen Übersetzungsdiensten, sodass Sie Inhalte direkt aus Ihrem Back Office zur menschlichen Übersetzung senden können.

Speziell für Produktinhalte kann die Tabelle ps_product_lang exportiert, durch maschinelle Übersetzung verarbeitet, von einem menschlichen Übersetzer überprüft und wieder importiert werden. CSV- und XML-Importtools in PrestaShop unterstützen die Aktualisierung bestehender Produkte mit neuen Sprachdaten, ohne andere Produktattribute zu beeinträchtigen.

Kulturelle Nuancen, die maschinelle Übersetzung übersieht

Über Wörter und Grammatik hinaus erfordert effektive Übersetzung kulturelle Anpassung. Hier sind Bereiche, in denen maschinelle Übersetzung konsequent versagt.

Farb- und Größenbezeichnungen

Farben haben unterschiedliche kulturelle Assoziationen und Benennungskonventionen. Was englischsprachige Personen "burgundy" nennen, könnte in Märkten, in denen dieser Farbbegriff weniger verbreitet ist, einen anderen Namen benötigen. Größenbezeichnungskonventionen variieren dramatisch: S/M/L vs. 36/38/40 vs. I/II/III. Maschinelle Übersetzung übersetzt das Wort, passt aber nicht die Konvention an.

Datums- und Zahlenformate

Datumsformate variieren je nach Land (MM/TT/JJJJ vs. TT/MM/JJJJ vs. JJJJ-MM-TT). Zahlenformate variieren ebenfalls: Das Dezimaltrennzeichen ist ein Punkt in englischsprachigen Ländern und ein Komma in den meisten Ländern Kontinentaleuropas. PrestaShop handhabt dies über seine Lokalisierungspakete, aber benutzerdefinierter Text, der Daten oder Zahlen enthält, erfordert manuelle Aufmerksamkeit.

Zahlungsmethoden-Namen

Zahlungsmethoden haben lokale Namen und lokale Präferenzen. Die prominente Erwähnung von "Klarna" in einem schwedischen Shop baut Vertrauen auf, da es eine bekannte lokale Marke ist. Die Erwähnung in einem Shop, der auf Japan ausgerichtet ist, hat keine Wirkung. Maschinelle Übersetzung übersetzt den umgebenden Text, kann aber diese strategischen Inhaltsentscheidungen nicht treffen.

Saisonale und kulturelle Referenzen

Marketingtexte referenzieren oft Jahreszeiten, Feiertage und kulturelle Veranstaltungen. Ein "Weihnachtsverkauf" muss für Märkte, die Weihnachten nicht feiern, in eine völlig andere Aktion umgewandelt werden. Eine "Back to School"-Aktion braucht unterschiedliche Zeitpunkte in verschiedenen Hemisphären. Maschinelle Übersetzung übersetzt die Wörter, passt aber die kulturelle Referenz nicht an.

Hreflang-Tags in PrestaShop einrichten

Unabhängig von Ihrem Übersetzungsansatz ist eine korrekte hreflang-Implementierung für mehrsprachiges SEO unerlässlich. PrestaShop unterstützt mehrere Ansätze für mehrsprachige URL-Strukturen.

Das häufigste Setup verwendet Sprachunterverzeichnisse: example.com/en/, example.com/fr/, example.com/de/. PrestaShop generiert diese automatisch basierend auf Ihren konfigurierten Sprachen. Jede Sprache hat einen ISO-Code und ein URL-Präfix, das im Back Office unter International > Lokalisierung > Sprachen konfiguriert wird.

PrestaShop generiert automatisch hreflang-Tags im Seitenkopf für jede Sprachversion einer Seite. Diese Tags teilen Google mit, welche Sprach- und Regionalvariante einer Seite Nutzern angezeigt werden soll, die in verschiedenen Sprachen suchen. Ein korrekt konfigurierter PrestaShop-Shop enthält Tags wie:

<link rel="alternate" hreflang="en" href="https://example.com/en/product-name.html" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/nom-du-produit.html" />
<link rel="alternate" hreflang="de" href="https://example.com/de/produktname.html" />

Beachten Sie, dass das Feld link_rewrite in ps_product_lang für jede Sprache übersetzt werden sollte. Eine französische Produkt-URL sollte französische Wörter enthalten, nicht englische. Dies ist sowohl eine SEO-Best-Practice als auch eine Verbesserung der Benutzerfreundlichkeit für Besucher, die die URL in der Adressleiste ihres Browsers oder in den Suchergebnissen sehen.

Häufige hreflang-Fehler, die vermieden werden sollten: hreflang-Tags auf Seiten verweisen lassen, die 404-Fehler zurückgeben (weil die Übersetzung nicht existiert), falsche Sprachcodes verwenden, asymmetrische hreflang-Referenzen haben (Seite A verweist auf Seite B, aber Seite B verweist nicht zurück auf Seite A) und denselben Content für mehrere Sprachversionen verwenden (was Suchmaschinen als Duplicate Content behandeln).

Checkliste für Übersetzungsqualität in PrestaShop-Shops

Bevor Sie eine neue Sprachversion starten, gehen Sie diese Checkliste durch, um sicherzustellen, dass die Übersetzungsqualität die Mindeststandards erfüllt.

Überprüfen Sie, ob alle Checkout-Zeichenketten korrekt übersetzt sind und sich natürlich lesen. Testen Sie den vollständigen Kaufprozess in jeder Sprache, vom Hinzufügen eines Produkts zum Warenkorb bis zur Bestellbestätigungsseite.

Prüfen Sie, ob Produktnamen nicht fälschlicherweise übersetzt wurden. Markennamen, Modellnummern und proprietäre Begriffe sollten in ihrer Originalform bleiben, es sei denn, es gibt ein lokales Äquivalent, das Kunden tatsächlich verwenden.

Verifizieren Sie, dass Meta-Titel und -Beschreibungen Keywords enthalten, die tatsächliches Suchvolumen in der Zielsprache haben. Verwenden Sie Keyword-Recherche-Tools, die die Zielsprache unterstützen, um Ihre übersetzten Meta-Inhalte zu validieren.

Testen Sie alle E-Mail-Templates in jeder Sprache. Bestellbestätigungen, Versandbenachrichtigungen und E-Mails zur Passwortwiederherstellung sollten alle korrekt übersetzt und ordnungsgemäß formatiert sein.

Prüfen Sie, ob Fehlermeldungen in jeder Sprache klar und hilfreich sind. Testen Sie die Formularvalidierung, indem Sie absichtlich falsche Daten eingeben und überprüfen, ob die Fehlermeldungen den Nutzer zur Korrektur seiner Eingabe anleiten.

Verifizieren Sie, dass Währungs-, Datums- und Zahlenformate den Konventionen des Zielmarkts entsprechen. PrestaShops Lokalisierungspakete handhaben das meiste davon, aber benutzerdefinierte Inhalte erfordern möglicherweise manuelle Anpassungen.

Lassen Sie einen Muttersprachler Ihre Rückgaberichtlinie, Allgemeinen Geschäftsbedingungen und Datenschutzerklärung in jeder Sprache überprüfen. Diese Seiten haben rechtliche Auswirkungen und müssen korrekt sein.

Zusammenfassung

Maschinelle Übersetzung ist ein nützliches Werkzeug, aber sie ist keine Übersetzungsstrategie. Sie als einzigen Ansatz für mehrsprachige E-Commerce-Inhalte zu verwenden, führt zu niedrigeren Suchplatzierungen, reduzierten Konversionsraten, höheren Retourenquoten und Schäden an der Markenwahrnehmung. Der effektivste Ansatz ist eine Hybridstrategie: professionelle Übersetzung für wirkungsstarke Inhalte, maschinelle Übersetzung mit menschlichem Post-Editing für den Großteil Ihres Katalogs und maschinelle Übersetzung allein nur für interne Inhalte mit niedriger Priorität. PrestaShops integrierte mehrsprachige Unterstützung, kombiniert mit einer korrekten hreflang-Implementierung und einem gestuften Übersetzungsansatz, ermöglicht es Ihnen, effektiv in neue Märkte zu expandieren, ohne die Qualität zu opfern, die Besucher in Kunden umwandelt. Die Investition in qualitativ hochwertige Übersetzung amortisiert sich durch bessere SEO-Leistung, höhere Konversionsraten und weniger Retouren. Im internationalen E-Commerce ist die Qualität Ihrer Sprache die Qualität Ihrer Marke.

Was ist die Robots.txt und warum sie für PrestaShop wichtig ist

Die Datei robots.txt befindet sich im Stammverzeichnis Ihrer PrestaShop-Installation und dient als erster Kommunikationspunkt zwischen Ihrem Shop und Suchmaschinen-Crawlern. Sie teilt Bots wie Googlebot, Bingbot und anderen mit, welche Bereiche Ihrer Website gecrawlt werden dürfen und welche übersprungen werden sollen. Obwohl sie kein Sicherheitsmechanismus ist (sie verhindert keinen Zugriff, sondern gibt nur Empfehlungen an Crawler), ist sie eines der wichtigsten Werkzeuge zur Verwaltung Ihres Crawl-Budgets — die Anzahl der Seiten, die eine Suchmaschine innerhalb eines bestimmten Zeitraums auf Ihrer Website crawlt.

Für PrestaShop-Shops ist dies enorm wichtig. Eine typische PrestaShop-Installation kann Tausende von URL-Varianten durch Filter, Sortieroptionen, Paginierung, Währungsumschaltung und Suchanfragen erzeugen. Wenn dies unkontrolliert bleibt, verschwenden Suchmaschinen-Bots ihr Crawl-Budget für diese wertlosen Seiten, anstatt Ihre tatsächlichen Produkt- und Kategorieseiten zu entdecken und zu indexieren.

Wie PrestaShop seine Robots.txt generiert

PrestaShop enthält einen integrierten robots.txt-Generator, der über das Back Office zugänglich ist. Navigieren Sie zu Shopparameter > Traffic & SEO und scrollen Sie nach unten, wo Sie den Abschnitt "Robots-Datei generieren" finden. Ein Klick auf die Schaltfläche erstellt eine robots.txt-Datei im Stammverzeichnis Ihres Shops.

Die standardmäßig generierte Datei enthält typischerweise Regeln wie diese -

User-agent: *
Disallow: /classes/
Disallow: /config/
Disallow: /download/
Disallow: /mails/
Disallow: /modules/
Disallow: /translations/
Disallow: /tools/
Disallow: /*?orderby=
Disallow: /*?orderway=
Disallow: /*?tag=
Disallow: /*?id_currency=
Disallow: /*?search_query=
Disallow: /*?back=
Disallow: /*?n=
Sitemap: https://ihrshop.com/sitemap.xml

Dies ist zwar ein vernünftiger Ausgangspunkt, aber bei weitem nicht vollständig. Viele kritische URL-Muster, die Crawl-Budget verschwenden, sind nicht enthalten.

Was Sie in PrestaShop blockieren müssen

1. Warenkorb-, Kassen- und Kontoseiten

Diese Seiten sind benutzerspezifisch und bieten keinerlei SEO-Wert. Sie sollten immer blockiert werden -

Disallow: /*?controller=cart
Disallow: /*?controller=order
Disallow: /*?controller=authentication
Disallow: /*?controller=my-account
Disallow: /*?controller=identity
Disallow: /*?controller=addresses
Disallow: /*?controller=address
Disallow: /*?controller=history
Disallow: /*?controller=order-detail
Disallow: /*?controller=password
Disallow: /*?controller=discount
Disallow: /*?controller=order-return
Disallow: /*?controller=order-follow
Disallow: /*?controller=guest-tracking
Disallow: /cart
Disallow: /order
Disallow: /login
Disallow: /my-account
Disallow: /password-recovery

2. Facettierte Navigation und Schichtfilter

Die facettierte Navigation ist der größte Crawl-Budget-Killer für E-Commerce-Shops. Wenn ein Kunde Filter wie Farbe, Größe oder Preisbereich verwendet, generiert PrestaShop eindeutige URLs für jede Kombination. Eine Kategorie mit 5 Farben, 4 Größen und 3 Preisbereichen kann Hunderte von URL-Kombinationen erzeugen — von denen keine in Googles Index sein sollte.

# Filter-Parameter der Schichtnavigation blockieren
Disallow: /*?q=
Disallow: /*&q=
Disallow: /*?selected_filters=
Disallow: /*&selected_filters=
Disallow: /module/ambjolisearch/jolisearch

# Preisfilter-Kombinationen blockieren
Disallow: /*?price=
Disallow: /*&price=

# Attribut- und Merkmalfilter blockieren
Disallow: /*?id_attribute_group=
Disallow: /*&id_attribute_group=
Disallow: /*?id_feature=
Disallow: /*&id_feature=

3. Interne Suchergebnisse

Interne Suchergebnisseiten sind dünn an Inhalt und sollten niemals indexiert werden. Sie erstellen häufig nahezu doppelte Seiten und sind eine bekannte Quelle für Qualitätsprobleme -

Disallow: /*?controller=search
Disallow: /*?s=
Disallow: /*&s=
Disallow: /search
Disallow: /*?search_query=
Disallow: /*&search_query=

4. Paginierungsparameter

Während Kategorieseiten selbst crawlbar sein sollten, sollten die Paginierungsparameter, die Sortier-/Seitenvarianten erzeugen, kontrolliert werden -

Disallow: /*?page=
Disallow: /*&page=
Disallow: /*?p=
Disallow: /*&p=

Wichtiger Hinweis - Seien Sie vorsichtig mit der Paginierung. Wenn Sie /*?page= vollständig blockieren, können Sie verhindern, dass Crawler Produkte erreichen, die nur auf tieferen Seiten erscheinen. Ein besserer Ansatz ist die Implementierung von rel="canonical"-Tags, die paginierte Seiten auf die erste Seite verweisen, oder die Verwendung von rel="next" und rel="prev" Paginierungssignalen.

5. Vergleichsseiten und Wunschlisten

Disallow: /*?controller=comparison
Disallow: /comparison
Disallow: /*?controller=wishlist
Disallow: /module/blockwishlist/

6. Admin- und Systemverzeichnisse

Disallow: /admin*/
Disallow: /app/
Disallow: /bin/
Disallow: /cache/
Disallow: /classes/
Disallow: /config/
Disallow: /controllers/
Disallow: /docs/
Disallow: /download/
Disallow: /img/tmp/
Disallow: /localization/
Disallow: /mails/
Disallow: /override/
Disallow: /pdf/
Disallow: /src/
Disallow: /tools/
Disallow: /translations/
Disallow: /upload/
Disallow: /var/
Disallow: /vendor/
Disallow: /webservice/

7. URL-Tracking-Parameter

Marketing-Kampagnenparameter erzeugen doppelten Inhalt, wenn Bots getaggte URLs crawlen -

Disallow: /*?utm_source=
Disallow: /*?utm_medium=
Disallow: /*?utm_campaign=
Disallow: /*&utm_source=
Disallow: /*&utm_medium=
Disallow: /*&utm_campaign=
Disallow: /*?fbclid=
Disallow: /*?gclid=
Disallow: /*?ref=

Was Sie in PrestaShop erlauben müssen

1. Produkt- und Kategorieseiten

Diese sind der Kern Ihres Shops und müssen immer crawlbar bleiben. Blockieren Sie nicht Ihre Hauptinhaltsverzeichnisse.

2. CSS-, JavaScript- und Bilddateien

Google muss Ihre Seiten rendern können, um die Inhaltsqualität zu bewerten. Das Blockieren von CSS- oder JS-Dateien verhindert das Rendering und kann Ihre Rankings beeinträchtigen -

Allow: /themes/*/assets/
Allow: /themes/*/css/
Allow: /themes/*/js/
Allow: /js/
Allow: /img/
Allow: /modules/*/views/css/
Allow: /modules/*/views/js/

3. CMS-Seiten

Ihre rechtlichen Seiten, Über-uns-Seiten und Content-Marketing-Seiten sollten vollständig crawlbar sein. Stellen Sie sicher, dass sie nicht versehentlich von zu breiten Disallow-Regeln erfasst werden.

4. Hersteller- und Lieferantenseiten (falls verwendet)

Wenn Sie umfangreiche Hersteller- oder Lieferantenseiten mit einzigartigem Inhalt pflegen, lassen Sie diese crawlbar. Wenn es sich um dünne, automatisch generierte Seiten handelt, erwägen Sie, diese zu blockieren.

Umgang mit KI-Crawlern

Der Aufstieg von KI-Diensten hat eine neue Kategorie von Crawlern eingeführt, die Inhalte für Trainingszwecke scrapen. Wenn Sie verhindern möchten, dass Ihre Produktbeschreibungen, Bilder und andere Inhalte von KI-Modellen verwendet werden, können Sie spezifische Regeln hinzufügen -

# KI-Training-Crawler blockieren
User-agent: GPTBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: anthropic-ai
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: FacebookBot
Disallow: /

User-agent: Bytespider
Disallow: /

Beachten Sie, dass das Blockieren von Google-Extended verhindert, dass Google Ihre Inhalte für KI-Training (Gemini) verwendet, während normales Googlebot-Crawling und die Indexierung Ihrer Seiten weiterhin möglich bleibt.

Vollständige empfohlene Robots.txt für PrestaShop

Hier ist eine umfassende robots.txt-Datei, die Sie für Ihren PrestaShop-Shop anpassen können -

# Hauptsuchmaschinen-Crawler
User-agent: *

# Statische Assets erlauben
Allow: /themes/*/assets/
Allow: /themes/*/css/
Allow: /themes/*/js/
Allow: /js/
Allow: /img/
Allow: /modules/*/views/css/
Allow: /modules/*/views/js/

# Systemverzeichnisse blockieren
Disallow: /app/
Disallow: /bin/
Disallow: /cache/
Disallow: /classes/
Disallow: /config/
Disallow: /controllers/
Disallow: /docs/
Disallow: /download/
Disallow: /img/tmp/
Disallow: /localization/
Disallow: /mails/
Disallow: /override/
Disallow: /pdf/
Disallow: /src/
Disallow: /tools/
Disallow: /translations/
Disallow: /upload/
Disallow: /var/
Disallow: /vendor/
Disallow: /webservice/

# Warenkorb, Kasse, Konto blockieren
Disallow: /cart
Disallow: /order
Disallow: /login
Disallow: /my-account
Disallow: /password-recovery
Disallow: /*?controller=cart
Disallow: /*?controller=order
Disallow: /*?controller=authentication
Disallow: /*?controller=my-account

# Filter und Sortierung blockieren
Disallow: /*?orderby=
Disallow: /*?orderway=
Disallow: /*?n=
Disallow: /*?q=
Disallow: /*?selected_filters=
Disallow: /*?id_currency=
Disallow: /*?tag=
Disallow: /*?back=
Disallow: /*&orderby=
Disallow: /*&orderway=
Disallow: /*&n=
Disallow: /*&q=
Disallow: /*&selected_filters=

# Suche blockieren
Disallow: /*?controller=search
Disallow: /*?search_query=
Disallow: /*&search_query=
Disallow: /*?s=
Disallow: /*&s=
Disallow: /search

# Tracking-Parameter blockieren
Disallow: /*?utm_source=
Disallow: /*?utm_medium=
Disallow: /*?utm_campaign=
Disallow: /*?fbclid=
Disallow: /*?gclid=

# Vergleich und Wunschliste blockieren
Disallow: /*?controller=comparison
Disallow: /comparison

# Sitemap
Sitemap: https://ihrshop.com/1_index_sitemap.xml

# KI-Training-Crawler blockieren
User-agent: GPTBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Google-Extended
Disallow: /

Häufige Fehler, die Sie vermeiden sollten

Das Modules-Verzeichnis komplett blockieren

Die Standard-robots.txt von PrestaShop blockiert /modules/. Während Sie nicht möchten, dass Modul-PHP-Dateien gecrawlt werden, liefern viele Module kritische CSS- und JavaScript-Dateien aus diesem Verzeichnis. Die pauschale Blockierung kann Google daran hindern, Ihre Seiten korrekt zu rendern. Blockieren Sie stattdessen /modules/, erlauben Sie aber explizit CSS- und JS-Unterverzeichnisse wie oben gezeigt.

Robots.txt statt Noindex verwenden

Ein kritisches Missverständnis - robots.txt teilt Bots mit, eine URL nicht zu crawlen, verhindert aber nicht die Indexierung. Wenn eine andere Website auf eine Seite verlinkt, die Sie in robots.txt blockiert haben, kann Google sie trotzdem indexieren (mit der Meldung "Für dieses Ergebnis ist aufgrund der robots.txt dieser Website keine Beschreibung verfügbar"). Für Seiten, die Sie vollständig aus den Suchergebnissen entfernen möchten, verwenden Sie stattdessen das noindex-Meta-Tag oder den X-Robots-Tag-HTTP-Header.

Die Sitemap-Referenz vergessen

Fügen Sie immer Ihre Sitemap-URL am Ende der robots.txt ein. Dies hilft Crawlern, Ihre Sitemap sofort zu finden. Wenn Sie ein Modul verwenden, das mehrere Sitemaps generiert, referenzieren Sie die Sitemap-Index-Datei.

Zu breite Regeln verwenden

Eine Regel wie Disallow: /*? würde jede URL mit einem beliebigen Query-Parameter blockieren, was katastrophal wäre. Seien Sie spezifisch mit Ihren Regeln und testen Sie sie mit dem robots.txt-Tester der Google Search Console, bevor Sie sie bereitstellen.

Testen Ihrer Robots.txt-Konfiguration

1. Google Search Console - Verwenden Sie das Robots.txt-Tester-Tool (unter den Legacy-Tools zu finden), um bestimmte URLs gegen Ihre Regeln zu prüfen
2. Manuelles Testen - Besuchen Sie ihrshop.com/robots.txt direkt in Ihrem Browser, um zu überprüfen, ob die Datei zugänglich und korrekt formatiert ist
3. Abdeckungsbericht - Überwachen Sie nach der Bereitstellung von Änderungen den Abdeckungsbericht in der Google Search Console auf unerwartete Anstiege bei "Ausgeschlossenen" Seiten
4. Log-Datei-Analyse - Überprüfen Sie Ihre Serverprotokolle, um sicherzustellen, dass Bots Ihre Regeln tatsächlich respektieren und kein Crawl-Budget für blockierte URLs verschwenden

Multistore-Überlegungen

Wenn Sie ein PrestaShop-Multistore-Setup betreiben, benötigt jeder Shop (jede Domain) seine eigene robots.txt-Datei in seinem Stammverzeichnis. Der PrestaShop-Generator erstellt Regeln für alle Shops in einer einzigen Datei, aber wenn Ihre Shops auf verschiedenen Domains liegen, müssen Sie diese entsprechend aufteilen. Die robots.txt jedes Shops sollte auf seine eigene Sitemap verweisen und Regeln haben, die seiner URL-Struktur entsprechen.

Wann Sie Ihre Robots.txt regenerieren sollten

Sie sollten Ihre robots.txt regenerieren oder aktualisieren, wenn Sie -

• Neue Module hinzufügen, die öffentlich zugängliche URLs erstellen (Suchmodule, Filtermodule)
• Ihre URL-Struktur ändern oder freundliche URLs aktivieren/deaktivieren
• Themes wechseln (verschiedene Themes können Assets von verschiedenen Pfaden bereitstellen)
• Sprachen hinzufügen oder entfernen (was URL-Präfixe ändert)
• Die Multistore-Funktion aktivieren oder deaktivieren
• Ungewöhnliche Crawl-Muster in Ihren Serverprotokollen oder der Google Search Console bemerken

Denken Sie daran - erstellen Sie immer eine Sicherungskopie Ihrer funktionierenden robots.txt, bevor Sie sie regenerieren. Der PrestaShop-Generator überschreibt die Datei vollständig, und alle manuell hinzugefügten benutzerdefinierten Regeln gehen verloren, sofern Sie sie nicht nach der Generierung erneut hinzufügen.

Den Status 'Gecrawlt — Derzeit nicht indexiert' verstehen

Wenn Sie die Google Search Console öffnen und Seiten mit dem Status "Gecrawlt — derzeit nicht indexiert" sehen, bedeutet das, dass Googles Crawler (Googlebot) diese Seiten besucht, ihren Inhalt heruntergeladen und bewertet hat — und dann entschieden hat, sie nicht in den Suchindex aufzunehmen. Dies ist kein technischer Fehler. Es ist eine Qualitäts- oder Relevanzbewertung durch Googles Algorithmen.

Dieser Status unterscheidet sich von "Entdeckt — derzeit nicht indexiert" (wo Google weiß, dass die URL existiert, sie aber noch nicht gecrawlt hat) und von "Durch Noindex-Tag ausgeschlossen" (wo Sie Google explizit angewiesen haben, die Seite nicht zu indexieren). Bei "Gecrawlt — derzeit nicht indexiert" hat Google Ihre Seite aktiv betrachtet und eine bewusste Entscheidung getroffen, sie zu überspringen.

Für PrestaShop-Shopbetreiber ist dies besonders besorgniserregend, da betroffene Seiten Produktseiten, Kategorieseiten oder CMS-Inhaltsseiten umfassen können, die Sie ausdrücklich in den Suchergebnissen ranken möchten. Lassen Sie uns einen systematischen Ansatz zur Diagnose und Behebung dieses Problems durchgehen.

Warum Google sich entscheidet, Seiten nicht zu indexieren

Google hat eine begrenzte Indexkapazität und priorisiert Seiten, die es als am wertvollsten für Suchende betrachtet. Mehrere Faktoren können diesen Status bei PrestaShop-Shops auslösen -

Dünner oder doppelter Inhalt

Dies ist die Hauptursache Nummer eins für PrestaShop-Shops. Produktseiten mit nur einer Herstellerbeschreibung (vom Lieferanten kopiert oder auf Dutzenden anderer Shops verwendet), kurze Zwei-Satz-Beschreibungen oder Seiten mit überwiegend technischen Spezifikationen und keinem erzählerischen Inhalt sind Hauptkandidaten dafür, gecrawlt, aber nicht indexiert zu werden. Google sieht denselben Inhalt auf mehreren Seiten und wählt die autoritativste Version zur Indexierung.

Schlechte interne Verlinkung

Seiten, die tief in Ihrer Seitenstruktur vergraben sind und wenige oder keine internen Links erhalten, senden ein Signal an Google, dass sie nicht wichtig sind. Wenn eine Produktseite nur über vier Klicks von der Startseite aus erreichbar ist oder nur in Suchergebnissen oder gefilterter Navigation erscheint, kann Google sie als niedrig priorisiert behandeln.

Verschwendung des Crawl-Budgets für wertlose URLs

Wenn Google den größten Teil seines Crawl-Budgets für Filterkombinationen, Suchergebnisseiten und Session-Parameter-URLs aufwendet, hat es möglicherweise nicht genug "Crawl-Aufmerksamkeit" für Ihre wichtigen Inhalte übrig. Wenn es diese wichtigen Seiten schließlich crawlt, kann das Gesamtqualitätssignal der Website verwässert sein.

Nicht vorrätige Produkte

Google priorisiert Produktseiten, bei denen das Produkt über längere Zeiträume nicht verfügbar ist, gezielt herunter. Wenn Ihr PrestaShop-Shop viele nicht vorrätige Artikel ohne Angabe zur Wiederverfügbarkeit hat, kann Google sie crawlen, sich aber entscheiden, keinen Indexplatz für nicht verfügbare Produkte zu verschwenden.

Langsame Seitenladezeiten

Seiten, die langsam gerendert werden oder übermäßige Ressourcen benötigen, können herabgestuft werden. Wenn Googlebot beim Abrufen Ihrer Seiten Zeitüberschreitungen oder Verzögerungen erlebt, kann es sich entscheiden, sie trotz eines erfolgreichen Crawls nicht zu indexieren.

Fehlende oder fehlerhafte strukturierte Daten

Obwohl strukturierte Daten an sich kein Rankingfaktor sind, können Fehler in Ihrem Product-Schema, BreadcrumbList-Schema oder anderen strukturierten Daten Unklarheit darüber schaffen, worum es auf der Seite geht, was zur Nichtindexierung beitragen kann.

Schritt 1 - Prüfen, welche Seiten betroffen sind

Bevor Sie etwas beheben, müssen Sie den Umfang und das Muster des Problems verstehen.

1. Öffnen Sie die Google Search Console und gehen Sie zu Seiten (früher Indexabdeckung)
2. Klicken Sie auf den Tab "Nicht indexiert" und finden Sie "Gecrawlt — derzeit nicht indexiert"
3. Exportieren Sie die vollständige Liste der betroffenen URLs
4. Kategorisieren Sie diese — sind es Produktseiten, Kategorieseiten, CMS-Seiten oder etwas anderes?

Suchen Sie nach Mustern. Wenn alle betroffenen Seiten Produkte einer bestimmten Kategorie sind, kann das Problem kategoriespezifisch sein. Wenn es alles ältere Produkte sind, kann es ein Aktualitätsproblem sein. Wenn sie Merkmale wie kurze Beschreibungen teilen, deutet das auf dünnen Inhalt hin.

Schritt 2 - Probleme mit der Inhaltsqualität beheben

Dies ist die wirkungsvollste Maßnahme und sollte Ihr Hauptfokus sein.

Produktbeschreibungen verbessern

Jede Produktseite, die Sie indexiert haben möchten, braucht einzigartigen, substanziellen Inhalt. Hier ist, was "substanziell" in der Praxis bedeutet -

• Mindestens 300 Wörter einzigartiger beschreibender Text (nicht vom Hersteller kopiert)
• Nutzerabsicht ansprechen - welches Problem löst dieses Produkt? Für wen ist es?
• Nutzungsinformationen einbinden - Installationsanleitungen, Pflegetipps, Kompatibilitätshinweise
• Originale Medien hinzufügen - einzigartige Produktfotos, Größenvergleichsbilder, Videovorführungen

In PrestaShop bearbeiten Sie Ihre Produkte über Katalog > Produkte und konzentrieren sich auf den Beschreibungs-Tab. Die Kurzbeschreibung erscheint in Kategorieauflistungen, während die Langbeschreibung auf der Produktseite selbst erscheint. Beide sind für die Indexierung wichtig.

Kategorieseiten-Inhalt verbessern

Viele PrestaShop-Shops haben Kategorieseiten mit nichts als einem Produktraster. Fügen Sie substanzielle Kategoriebeschreibungen hinzu, die Nutzern helfen, das Produktsortiment zu verstehen -

<!-- Beispiel Kategoriebeschreibungsstruktur -->
<div class="category-description">
  <h2>Begehbare Duschrinnen für moderne Badezimmer</h2>
  <p>Unsere Kollektion linearer Duschrinnen vereint 
  modernes Design mit überlegener Entwässerungsleistung...</p>
  
  <h3>Die richtige Rinnenlänge wählen</h3>
  <p>Die Rinnenlänge sollte der Duschbreite entsprechen...
  Erhältlich in 600mm, 800mm, 1000mm und 1200mm.</p>
</div>

Doppelten Inhalt über Produkte hinweg behandeln

Wenn Sie mehrere Varianten ähnlicher Produkte verkaufen (gleiches Produkt in verschiedenen Größen, Farben oder Konfigurationen), braucht jede Seite differenzierenden Inhalt. Kopieren Sie nicht einfach dieselbe Beschreibung und ändern die Größennummer. Fügen Sie variantenspezifische Details hinzu -

• Spezifische Anwendungsfälle für jede Variante
• Installationsunterschiede zwischen Varianten
• Kundenbewertungen spezifisch für diese Variante
• Einzigartige Bilder, die die Variante im Kontext zeigen

Schritt 3 - Interne Verlinkung stärken

Interne Links sind eines der stärksten Signale, die Sie Google darüber senden können, welche Seiten wichtig sind.

Verwandte Produkte verknüpfen

Gehen Sie in PrestaShop zu jedem Produkt und fügen Sie verwandte Produkte über den Abschnitt Katalog > Produkte > [Produkt] > Optionen hinzu. Verwandte Produkte schaffen wertvolle interne Links zwischen Produktseiten.

Kontextuelle Links in CMS-Inhalten hinzufügen

Wenn Sie einen Blog oder CMS-Seiten haben, verlinken Sie von innerhalb des Inhalts auf spezifische Produkte und Kategorien. Dies ist weitaus wertvoller als Sidebar- oder Footer-Links.

Breadcrumb-Navigation verbessern

Stellen Sie sicher, dass Ihr PrestaShop-Theme ordnungsgemäßes Breadcrumb-Markup generiert. Breadcrumbs schaffen eine klare Verlinkungshierarchie, die Google hilft, Ihre Seitenstruktur zu verstehen.

Eine benutzerdefinierte HTML-Sitemap-Seite erstellen

Erstellen Sie zusätzlich zu Ihrer XML-Sitemap eine CMS-Seite, die als HTML-Sitemap fungiert. Verlinken Sie auf alle Ihre wichtigen Kategorien und Top-Produkte. Dies gibt sowohl Nutzern als auch Crawlern eine Roadmap Ihrer Website.

Schritt 4 - Technische Korrekturen speziell für PrestaShop

Canonical-Tags prüfen

Falsche Canonical-Tags sind ein häufiges Problem in PrestaShop. Wenn eine Produktseite ein Canonical-Tag hat, das auf eine andere URL zeigt, behandelt Google die Seite als Duplikat und indexiert sie möglicherweise nicht. Prüfen Sie Ihren Seitenquelltext -

<!-- Suchen Sie dies im <head>-Bereich -->
<link rel="canonical" href="https://ihrshop.com/produktname.html" />

Die Canonical-URL sollte mit der tatsächlichen Seiten-URL übereinstimmen. Häufige PrestaShop-Probleme umfassen -

• HTTP vs HTTPS Diskrepanzen in Canonical-Tags
• Canonical-Tags mit Query-Parametern
• Mehrere Canonical-Tags auf derselben Seite (verursacht durch Module)
• Canonical-Tags, die auf nicht existierende Seiten zeigen

Server-Antwortcodes überprüfen

Verwenden Sie das URL-Inspection-Tool in der Search Console, um zu prüfen, was Googlebot tatsächlich sieht, wenn es Ihre Seite besucht. Achten Sie auf -

• Weiterleitungsketten (mehrere Weiterleitungen, bevor die endgültige Seite erreicht wird)
• Soft 404s (Seiten, die einen 200-Status zurückgeben, aber "keine Produkte gefunden" anzeigen)
• Mixed-Content-Warnungen (HTTP-Ressourcen auf HTTPS-Seiten)

Seitengeschwindigkeit verbessern

Prüfen Sie Ihre Core Web Vitals in der Search Console. Für PrestaShop umfassen häufige Geschwindigkeitsprobleme -

• Nicht optimierte Bilder - Aktivieren Sie WebP-Konvertierung und Lazy Loading
• Zu viele Module - Jedes Modul fügt CSS- und JS-Dateien hinzu; deaktivieren Sie ungenutzte
• Kein Caching - Aktivieren Sie Smarty-Cache und erwägen Sie ein Caching-Modul oder CDN
• Datenbankabfragen - Überwachen Sie langsame Abfragen, die die Server-Antwortzeit erhöhen

Strukturierte Daten-Fehler beheben

Verwenden Sie Googles Rich Results Test, um Ihre Produktseiten zu prüfen. PrestaShop sollte Product-Schema mit mindestens folgenden Daten ausgeben -

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Produktname",
  "description": "Produktbeschreibung",
  "image": "https://ihrshop.com/img/produkt.jpg",
  "sku": "PROD-001",
  "offers": {
    "@type": "Offer",
    "price": "49.99",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock"
  }
}

Schritt 5 - Nicht vorrätige Produkte richtig behandeln

PrestaShop-Shops haben oft Produkte, die vorübergehend nicht auf Lager sind. So gehen Sie damit um, um Indexierungsprobleme zu vermeiden -

• Vorübergehend nicht auf Lager - Seite aktiv lassen, "nicht verfügbar"-Status anzeigen und strukturierte Daten auf https://schema.org/OutOfStock aktualisieren. Eine "E-Mail bei Verfügbarkeit"-Funktion hinzufügen.
• Dauerhaft eingestellt - Eine 301-Weiterleitung zum nächstähnlichen alternativen Produkt oder zur übergeordneten Kategorie einrichten.
• Saisonale Produkte - Seite ganzjährig aktiv lassen mit aktualisiertem Inhalt, der angibt, wann das Produkt zurückkommt.

Deaktivieren Sie niemals einfach ein Produkt, ohne seine URL zu behandeln. Ein Produkt, das nach der Indexierung einen 404-Fehler zurückgibt, verliert allen angesammelten SEO-Wert.

Schritt 6 - Ihre XML-Sitemap optimieren

Ihre XML-Sitemap signalisiert Google, welche Seiten Sie als wichtig erachten. Optimieren Sie diese durch -

• Nur indexierbare Seiten einschließen - Entfernen Sie Seiten mit noindex-Tags oder Seiten, die Sie nicht indexiert haben möchten
• Priorität und Häufigkeit korrekt setzen - Produktseiten und Kategorien sollten eine höhere Priorität haben als generische CMS-Seiten
• Veraltete URLs entfernen - Wenn Produkte eingestellt und weitergeleitet wurden, entfernen Sie sie aus der Sitemap
• Unter 50.000 URLs bleiben - Verwenden Sie eine Sitemap-Index-Datei für größere Shops

Schritt 7 - Neuindexierung anfordern

Nachdem Sie alle Verbesserungen vorgenommen haben, fordern Sie eine Neuindexierung für die wichtigsten betroffenen Seiten an -

1. Gehen Sie zu Google Search Console > URL-Prüfung
2. Geben Sie die URL einer betroffenen Seite ein
3. Klicken Sie auf "Indexierung beantragen"

Beachten Sie, dass Google die Anzahl der Neuindexierungsanfragen, die Sie pro Tag senden können, begrenzt. Konzentrieren Sie sich zuerst auf Ihre Seiten mit höchster Priorität.

Präventive Maßnahmen für PrestaShop-Shops

Checkliste für Inhaltsqualität bei neuen Produkten

Bevor Sie ein neues Produkt veröffentlichen, stellen Sie sicher, dass es diese Mindestanforderungen erfüllt -

• Einzigartiger Produktname
• Mindestens 300 Wörter einzigartige Beschreibung
• 3 oder mehr einzigartige Produktbilder
• Vollständige Produktattribute (Abmessungen, Gewicht, Materialien)
• Korrekte Kategoriezuordnung
• Ausgefüllter Meta-Titel und Meta-Beschreibung

Regelmäßige Inhaltsprüfungen

Planen Sie monatliche Überprüfungen Ihres Search Console Abdeckungsberichts. Verfolgen Sie die Anzahl der Seiten in jeder Statuskategorie und untersuchen Sie plötzliche Anstiege bei "Gecrawlt — derzeit nicht indexiert"-Seiten. Untersuchen Sie innerhalb der ersten Woche, da Verzögerungen es schwieriger machen, Änderungen mit Indexierungsrückgängen zu korrelieren.

Crawl-Statistiken überwachen

Prüfen Sie in der Search Console unter Einstellungen > Crawl-Statistiken, wie Google Ihre Website crawlt. Achten Sie auf Crawl-Rate, Antwortzeit und Statuscodes.

Wann Sie sich keine Sorgen machen müssen

Nicht jede Seite muss indexiert werden. Wenn die betroffenen Seiten rechtliche Seiten sind, Seiten mit sehr ähnlichem Inhalt, kürzlich veröffentlichte Seiten (geben Sie ihnen 2-4 Wochen), oder für interne Zwecke erstellt wurden, ist die Nichtindexierung möglicherweise akzeptabel. Konzentrieren Sie Ihre Bemühungen auf Seiten, die organischen Traffic generieren oder generieren sollten.

SEO-Audit-Tools bemängeln alles — einschließlich optionaler Markups. Nicht jede Seite braucht jede Art von Schema. Produktseiten sollten Product-Schema haben, Ihre Startseite kann Organization-Schema haben, und FAQ-Seiten profitieren von FAQPage-Schema. Wenn ein Tool sagt „Breadcrumb-Schema fehlt", aber Ihre Breadcrumbs visuell einwandfrei funktionieren, ist die Auswirkung minimal. Konzentrieren Sie sich zuerst auf Product- und Review-Schema — diese haben den größten Einfluss darauf, wie Ihre Seiten in den Suchergebnissen erscheinen.

Read our guide on schema markup best practices

Der Sitemap Builder erstellt automatisch mehrere Sitemap-Dateien: eine für Produkte, eine für Kategorien, eine für CMS-Seiten und eine für Hersteller-/Lieferantenseiten. Wenn eine davon 50.000 URLs oder 50MB überschreitet (Googles Limits), teilt das Modul sie automatisch in mehrere Dateien mit einer Sitemap-Indexdatei auf, die alle miteinander verknüpft. Sie müssen das nicht manuell verwalten.

Das Modul kann 301-Weiterleitungen von alten URLs zu neuen, saubereren URLs erstellen. Dies bewahrt Ihren bestehenden SEO-Wert und teilt Google mit, seinen Index zu aktualisieren. Seien Sie jedoch vorsichtig: Das Ändern von URLs im großen Stil birgt immer ein kurzfristiges Ranking-Risiko während der Übergangsphase. Google braucht Zeit, um die Weiterleitungen zu verarbeiten. Wenn Ihre aktuellen URLs keine Probleme verursachen, lohnt es sich möglicherweise nicht, sie nur aus ästhetischen Gründen zu ändern.

Learn about SEO-friendly URL structures