PrestaShop-SEO: URLs, Indexierung, Inhalte und technische Prüfungen

So würden wir vorgehen

Wir würden mit den verkaufsrelevanten Seiten beginnen, die Kunden finden sollen, und klären, ob das Problem bei Auffindbarkeit, Indexierung, Suchdarstellung oder Kaufprozess liegt. Das richtige Vorgehen hängt von Ihrer bestehenden PrestaShop-Version, Theme, Modulen, Integrationen, Katalogdaten, Sprachen und Märkten sowie den Personen im Team ab, die das Ergebnis pflegen können. Dokumentieren Sie vor Einstellungsänderungen oder dem Kauf eines weiteren SEO-Werkzeugs die genauen PrestaShop-, Theme- und Modulversionen zusammen mit der gerenderten Shopausgabe. Gleichen Sie versionsspezifische Routen, Template-Pfade und erzeugte Regeln mit der installierten Version ab.

Halten Sie funktionierende URLs und nützliche indexierte Seiten stabil. Betrifft ein Fehler ein gemeinsames Template oder eine Routing-Regel, reproduzieren Sie ihn auf einer geschützten Staging-Kopie mit derselben relevanten Konfiguration und denselben Daten. Erproben Sie Korrektur, Kundenwege und Crawler-Prüfungen, dokumentieren Sie das Rückgängigmachen und vereinbaren Sie eine geplante Live-Umstellung mit einer benannten verantwortlichen Person. Trennen Sie diese Kopie von produktiven E-Mail-, Zahlungs- und Auftragsabwicklungsanbindungen. Ein öffentlicher Staging-Shop kann selbst doppelte Seiten erzeugen und Kundeninformationen offenlegen.

Einen Ausgangspunkt wählen

Wählen Sie eine betroffene und eine vergleichbare nicht betroffene Seite, bevor Sie die folgenden Detailabschnitte öffnen. So erhalten Sie einen sinnvollen Vergleich und einen Weg durch das Nachschlagewerk, ohne alle Einstellungen gleichzeitig zu ändern.

Für eine shopspezifische priorisierte Diagnose liefert der PrestaShop SEO Audit & Action Plan rein lesend ermittelte Befunde und Korrekturvorschläge. Umsetzung, Texterstellung, Linkaufbau und laufende Überwachung sind separate Leistungen.

Stabile URLs wählen und erforderliche Routenfelder beibehalten

Beginnen Sie unter Shop-Einstellungen → Traffic & SEO → SEO & URLs. Prüfen Sie unter URLs einrichten die Einstellung für benutzerfreundliche URLs und die aktuellen Routenmuster. Exportieren Sie bei einem aktiven Shop die vorhandenen URLs, bevor Sie sie ändern.

Eine Produkt-URL wie index.php?id_product=42&controller=product kann zu einem lesbaren Pfad wie /42-mens-leather-wallet.html werden. Numerische IDs verhindern kein Ranking einer Seite. Behalten Sie etablierte URLs bei, sofern die Änderung keinen klaren Zweck hat.

Das Speichern von „URLs einrichten“ löst die Erzeugung der .htaccess für Apache aus. Prüfen Sie, dass URL-Rewriting und der physische Basispfad des Shops funktionieren. Nginx liest keine .htaccess; konfigurieren Sie entsprechende Regeln auf dem Server. Liefern benutzerfreundliche URLs 404 zurück, prüfen Sie Rewrite-Konfiguration, Basispfad und angeforderte Route, bevor Sie Produkte umbenennen.

Core-Routen benötigen weiterhin IDs

Die Core-Routen für Produkte und Kategorien benötigen ihre ID-Schlüsselwörter. Das Entfernen von {id} aus dem Routenfeld ergänzt keine Slug-basierte Entitätssuche. Das standardmäßige Produktmuster von PrestaShop 9 lässt den Kategorieanteil weg, enthält aber weiterhin die Produkt-ID und die optionale Varianten-ID.

# PrestaShop 9 core product route
{id}{-:id_product_attribute}-{rewrite}.html

# Core category route
{id}-{rewrite}

ID-freies Routing benötigt eine Implementierung, die diese Routen auflöst sowie Kollisionen und Weiterleitungen behandelt; siehe die Hilfe zu Smart SEO Friendly URL Manager, wenn dies die Anforderung ist.

Vor einer Routing-Änderung den Kollisionsbereich prüfen

Verwenden Sie das tatsächliche Datenbankpräfix. Die folgende Leseabfrage findet Produkt-Slugs, die unterschiedliche Produkt-IDs innerhalb desselben Shops und derselben Sprache gemeinsam nutzen. Sie ist eine Vorprüfung für Slug-basiertes Routing, kein Grund, funktionierende Core-URLs zu ändern.

SELECT id_shop, id_lang, link_rewrite,
       COUNT(DISTINCT id_product) AS product_count
FROM ps_product_lang
GROUP BY id_shop, id_lang, link_rewrite
HAVING COUNT(DISTINCT id_product) > 1;

Verwendet Ihre Routing-Implementierung Kategoriepfade, beziehen Sie den wirksamen Pfad in die Kollisionsprüfung ein. Prüfen Sie Produkte, Kategorien, CMS-Seiten, Marken und alle Modulrouten, die denselben Namensraum verwenden. Zählen Sie dasselbe Produkt in mehreren Shops nicht als mehrere kollidierende Produkte.

• Verwenden Sie beschreibende Wörter und Bindestriche. Bevorzugen Sie lesbare Slugs gegenüber einer festen Wortzahlregel.
• Wählen Sie für jeden Routentyp eine einheitliche Regel für abschließende Schrägstriche und Suffixe. Core-Kategorien benötigen nicht grundsätzlich einen abschließenden Schrägstrich.
• Stimmen Sie interne Links, Canonicals, Sitemap-Einträge und Weiterleitungen auf diese Regel ab.
• Planen Sie eine permanente Weiterleitung, wenn eine bestehende URL tatsächlich umzieht.

HTTPS, Domainvereinheitlichung und Umzugsweiterleitungen prüfen

Stellen Sie zuerst ein gültiges Zertifikat bereit. Aktivieren Sie dann SSL und SSL auf allen Seiten unter Shop-Einstellungen → Allgemein. Prüfen Sie Shop-Domain und SSL-Domain, erzeugte Asset-URLs und die Mixed-Content-Warnungen des Browsers.

Der Front-Controller von PrestaShop führt SSL-Weiterleitungen aus. Ein Reverse Proxy muss HTTPS-Informationen korrekt weitergeben, sonst kann die Anwendung falsche URLs erzeugen oder in eine Weiterleitungsschleife geraten. Serverregeln können Anwendungsweiterleitungen ergänzen und Host- und Schema-Vereinheitlichung zusammenfassen.

1. Wählen Sie den bevorzugten HTTPS-Host mit oder ohne www.
2. Testen Sie HTTP, den alternativen Host, den bevorzugten Host und repräsentative Sprachpfade.
3. Prüfen Sie jedes Weiterleitungsziel und die abschließende Antwort. Streben Sie eine direkte Weiterleitung zum endgültigen Ziel an.
4. Testen Sie Produkte, Kategorien, CMS-Seiten, Modul-URLs, Kasse und Callbacks nach Änderungen an Serverregeln.

curl -I -L https://example.com/42-mens-leather-wallet.html
curl -I -L http://www.example.com/42-mens-leather-wallet.html

Drei unterschiedliche Weiterleitungssteuerungen

Exportieren Sie alte URLs und ordnen Sie jede geänderte Adresse ihrem entsprechenden Ziel zu. Vermeiden Sie Ketten und pauschale Weiterleitungen zur Startseite. Ein Theme-Wechsel benötigt nur dann URL-Weiterleitungen, wenn URLs tatsächlich wechseln; testen Sie dessen Canonicals, Schema, interne Links und Überschriften separat.

Prüfen Sie Startseitenvarianten wie /, /index.php, /en/ und /en/index.php. Erhalten Sie beabsichtigte Sprachfassungen. Verwenden Sie keine pauschale index.php-Regel, die auch funktionale Routen mit Abfrageparametern erfasst. Vereinheitlichen Sie ?page=1 nur, wenn es dieselbe erste Listenseite bezeichnet, und erhalten Sie andere Parameter.

Leiten Sie eingestellte Produkte nur auf einen tatsächlich gleichwertigen Ersatz weiter. Behalten Sie andernfalls hilfreiche Informationen zum nicht verfügbaren Produkt bei oder geben Sie einen passenden Status 404/410 zurück. Eine Weiterleitung auf einen lediglich ähnlichen Artikel kann Käufer verwirren und als Soft 404 behandelt werden.

Hilfreiche Titel, Beschreibungen und Seiteninhalte schreiben

Bearbeiten Sie Produktmetadaten im SEO-Bereich des Produkts, Kategoriemetadaten im Kategorieeditor und CMS-Metadaten im jeweiligen Seiteneditor. Prüfen Sie unter Traffic & SEO den Eintrag index für die Startseite und die übrigen Einträge statischer Seiten, einschließlich Kontakt und Filialen.

Ersetzen Sie ps_ durch das Präfix Ihrer Installation. Ein leerer Produkt-Metatitel kann auf den Produktnamen zurückfallen; der endgültige Titel hängt auch vom installierten Theme und den SEO-Modulen ab. Prüfen Sie den gerenderten Titel, statt ein bestimmtes Suffix anzunehmen.

Praktische Muster für Titel und Beschreibungen

Product: Main product name - useful distinction | Shop name
Category: Category name - useful distinction | Shop name
CMS: Page topic | Shop name

Beginnen Sie mit dem Thema und machen Sie jeden Titel unterscheidbar. Ein knapper Titel mit etwa 50 bis 60 Zeichen kann ein redaktionelles Ziel sein, aber Google hat keine feste Zeichengrenze und kann den angezeigten Titel umschreiben oder kürzen. Folgen Sie Googles Titelhinweisen.

Schreiben Sie eine seitenspezifische Beschreibung, die den Inhalt korrekt zusammenfasst. Nennen Sie hilfreiche Eigenschaften, Lieferdetails oder Handlungsaufforderungen nur, wenn sie für die Seite zutreffen. Google kann stattdessen Seitentext verwenden, und die Snippet-Länge variiert je nach Gerät und Suchanfrage. Programmatisch erzeugte Beschreibungen sind geeignet, wenn sie lesbar und spezifisch bleiben. Ein leeres Feld ist nicht grundsätzlich besser als eine gute Vorlage. Siehe Googles Hinweise zu Snippets.

Massenänderungen

Sichern Sie die Datenbank und zeigen Sie Massenänderungen an Metadaten vor jedem Update als SELECT-Vorschau an. Verknüpfen Sie Produkt-, Standardkategorie- und Übersetzungsdaten innerhalb des richtigen Shops und der richtigen Sprache. Erhalten Sie manuell geschriebene Werte, sofern deren Ersetzung nicht beabsichtigt ist. Nutzen Sie unterstützte Importe oder APIs, wenn Sie Validierung, Hooks und Cache-Invalidierung benötigen.

SELECT id_product, id_shop, id_lang, name, meta_title
FROM ps_product_lang
WHERE meta_title IS NULL OR TRIM(meta_title) = '';

Inhalte und Überschriften

Geben Sie Kategorieseiten hilfreiche Beschreibungen, die die Auswahl erklären und relevante Unterkategorien verlinken. PrestaShop 8 und 9 bieten eine zusätzliche Kategoriebeschreibung; ihre Platzierung hängt vom Theme ab. Benötigt ein älterer Shop diesen zusätzlichen Inhaltsbereich, nutzen Sie die Hilfe zu Second Category Description.

Ersetzen Sie kopierte Lieferantenbeschreibungen durch korrekte produktspezifische Informationen. Priorisieren Sie wirtschaftlich wichtige Seiten und erweitern Sie dann den Umfang. Ergänzen Sie eigene Kaufberatung, Maße, Materialien, Kompatibilitäts- und Pflegeangaben, wenn diese dem Kunden helfen. Prüfen Sie automatisch erzeugte Texte vor Veröffentlichung.

Aus einem Suchthema eine nützliche Inhaltsvorgabe machen

Ordnen Sie das Suchthema zunächst einer bestehenden Kategorie, einem Produkt oder Ratgeber zu, bevor Sie eine weitere Seite erstellen, und gleichen Sie diese Wahl mit Search-Console-Anfragen und Kundenfragen ab. Beginnen Sie bei einer Bürostuhlkategorie mit den Fragen, die die Auswahl bestimmen: Sitzverstellung, Platz unter dem Schreibtisch, Materialien und Eignung für den vorgesehenen Einsatz. Platzieren Sie die kurze Erklärung dort, wo sie bei der Wahl hilft, und verlinken Sie passende Sortimente oder einen Ratgeber zur richtigen Einstellung. Ein Satz, der nur „Bürostühle“ wiederholt, ohne die Entscheidung zu unterstützen, ergänzt das Produktraster kaum.

Sammeln Sie bei einem einzelnen Stuhl vor dem Schreiben bestätigte Maße, Verstellbereich und enthaltene Teile. Stammen diese Fakten aus einem Import, ermitteln Sie die maßgeblichen Felder und die für Korrekturen verantwortliche Person. Ein Titel, der verstellbare Armlehnen verspricht, muss sowohl mit den Produktdetails als auch mit der in den Warenkorb übernommenen Option übereinstimmen. Halten Sie Liefer- oder Verfügbarkeitszusagen aus wiederverwendbaren Texten heraus, sofern Ihr Team sie nicht für jeden betroffenen Markt aktuell halten kann.

Prüfen Sie das Ergebnis auf der tatsächlichen mobilen Seite: Können Kunden die Auswahl sehen, die Kaufberatung finden und das verlinkte Sortiment erreichen? Eine gespeicherte Kategoriebeschreibung, die das Theme nie anzeigt, beantwortet die Käuferfrage nicht. Bewahren Sie die hilfreiche Inhaltsvorgabe bei den Produktdaten auf, damit spätere Übersetzungen und Importe ihre Bedeutung erhalten.

Nutzen Sie eine klare Hauptüberschrift und eine semantische Hierarchie, die für Screenreader funktioniert. Google verlangt weder genau eine H1 noch eine magische Überschriftenanzahl. Stimmen Sie die Überschrift auf das sichtbare Thema ab und halten Sie wichtige Inhalte auf schmalen Bildschirmen zugänglich. Der Leitfaden zu Produkt-SEO-Inhalten behandelt den Inhaltsablauf.

Canonical-URLs, Crawling und Indexierung trennen

Ein Canonical-Link kennzeichnet die bevorzugte URL für doppelte oder sehr ähnliche Inhalte. Er ist ein Signal, und Google kann eine andere URL wählen. Eine Weiterleitung verschiebt die Anfrage. noindex verhindert die Indexierung, wenn der Crawler es lesen kann. Eine robots.txt-Regel steuert das Crawling.

<link rel="canonical" href="https://example.com/42-mens-leather-wallet.html">

Prüfen Sie den endgültigen HTML-Head und die Antwortheader Ihres tatsächlichen Themes. Testen Sie ein normales Produkt, eine Variante, einen alternativen Kategoriepfad, eine gefilterte Liste, eine sortierte Liste und eine Tracking-URL. Die Canonical-Weiterleitung des Cores entfernt im Allgemeinen keine beliebigen Abfrageparameter: Ein zusätzlicher Query-String kann ohne Weiterleitung akzeptiert werden.

Der Listing-Controller von PrestaShop 9 setzt noindex, wenn q oder order übermittelt wird. Prüfen Sie das gerenderte Ergebnis, da Themes und Module es verändern können. Gehen Sie nicht davon aus, dass jeder individuelle Filter, alte Parameter oder jede Modulroute gleich behandelt wird.

Prüfen Sie bei Multishop Host, Pfad, Sprache und Canonical in jedem Shop-Kontext. Domainübergreifende Canonicals sind nur geeignet, wenn Sie doppelte Inhalte bewusst auf einer anderen Domain zusammenführen möchten. Für ausdrückliche Produktausnahmen siehe die Hilfe zu Product Canonical Manager.

Seitennavigation

Halten Sie nützliche Kategorieseitennavigation crawlbar und geben Sie jeder Seite eine eigene Canonical-URL. Eine zweite Listenseite enthält andere Produkte als Seite eins. Verweisen Sie nicht alle Seiten auf Seite eins und setzen Sie nicht automatisch jede Seite nach Seite drei auf noindex. Google verwendet rel="next" und rel="prev" nicht mehr als Indexierungssignale. Folgen Sie den Hinweisen zur Seitennavigation.

Stellen Sie normale crawlbare Links zu späteren Seiten und zurück zum Kategorieanfang bereit. Auch endloses Scrollen oder ein Button „Mehr laden“ benötigt auffindbare paginierte URLs. Mehr Produkte je Seite reduzieren die Seitenzahl, verändern aber auch den Darstellungsaufwand. Testen Sie daher Bedienbarkeit und Leistung. Prüfen Sie mit einem Produkt, das erst auf einer späteren Seite erscheint: Folgen Sie gewöhnlichen Links von der Kategorie zu dieser Seite und dann zum Produkt, ohne sich auf Scrollen oder die interne Suche zu verlassen. So erkennen Sie eine Auffindbarkeitslücke, die ein korrektes Canonical auf der ersten Seite verbergen kann.

Facettenkombinationen

Filter können URL-Varianten vervielfachen. Beispielsweise ergeben eine von fünf Farben, eine von acht Größen und eines von vier Preisbändern bereits 160 Kombinationen, noch ohne weitere Optionen. Halten Sie nur bewusst vorgesehene Zielseiten indexierbar. Kombinieren Sie keine robots-Sperre mit der Erwartung, dass Google das noindex- oder Canonical-Tag der Seite liest. Sind unerwünschte Varianten bereits indexiert, klären Sie vor einer Crawling-Sperre, wie der Crawler das Entfernungssignal erhält. Gehen Sie nicht davon aus, dass eine neu gespeicherte robots-Regel sie aus dem Index entfernt.

Sprachliche und regionale Alternativen korrekt zuordnen

Verwenden Sie hreflang, um Google bei der Auslieferung der passenden Sprach- oder Regionalversion zu unterstützen. Google benötigt es nicht, um übersetzte Seiten zu finden oder zu indexieren. Jede Alternative sollte eine erreichbare, indexierbare URL mit gleichwertigen Inhalten sein.

<link rel="alternate" hreflang="en" href="https://example.com/en/42-wallet.html">
<link rel="alternate" hreflang="fr" href="https://example.com/fr/42-portefeuille.html">
<link rel="alternate" hreflang="x-default" href="https://example.com/en/42-wallet.html">

Beziehen Sie jede Seite selbst und die anderen Alternativen ein. Verwenden Sie vollständige URLs und gegenseitige Verweise. Fehlende Rückverweise betreffen die jeweiligen Beziehungen; sie machen nicht zwangsläufig jedes andere Paar ungültig. HTML-Tags, HTTP-Header und XML-Sitemaps sind gleichwertige Übermittlungswege. Wählen Sie daher den Weg, den Sie konsistent pflegen können.

Verwenden Sie reine Sprachcodes wie en oder fr, wo passend. Ergänzen Sie für regionale Versionen eine Region, etwa en-GB oder en-US; en-UK ist falsch. x-default ist ein nützlicher Rückfallwert für nicht zugeordnete Besucher, oft eine Auswahl- oder Standardsprachseite; sein Fehlen allein macht andere Auszeichnungen aber nicht ungültig.

Prüfen Sie wechselseitige Verweise, Canonical-Ziele, Indexierbarkeit und die Zuordnung gleichwertiger Produkte in jedem Shop. Getrennte Domains sind zulässig. Gehen Sie bei shopübergreifenden Zuordnungen nicht davon aus, dass übersetzte Slugs oder Produkt-IDs überall identisch sind. Siehe Googles Hinweise zu lokalisierten Fassungen und den PrestaShop-hreflang-Leitfaden.

Angenommen, ein Produkt wird im englischen Shop verkauft, hat aber keine entsprechende französische Produktseite. Setzen Sie nicht die französische Startseite ein, nur um den Satz alternativer URLs zu vervollständigen. Dokumentieren Sie die fehlende Entsprechung, lassen Sie diese Beziehung weg und testen Sie erneut, sobald die übersetzte Seite veröffentlicht ist. Trennen Sie diese Zuordnungsentscheidung von einem vorübergehenden Ausverkauf des Produkts in einem vorhandenen Markt.

Die Hilfe zu Hreflang Tags Manager erklärt Sprachalternativen auf Basis der eigenen Seitenadressen jedes Shops. Klären Sie bei unabhängigen Shops mit unterschiedlichen Produkt-IDs oder Katalogen vor der Wahl einer Implementierung, wie gleichwertige Seiten zugeordnet werden.

Den tatsächlich gewünschten Rich-Result-Typ validieren

Strukturierte Daten können eine Seite für erweiterte Suchdarstellungen qualifizieren. Gültiges Markup garantiert weder eine Anzeige noch einen Rankinganstieg. Halten Sie Name, Preis, Währung, Verfügbarkeit und Bewertungen konsistent mit der sichtbaren Seite.

Nutzen Sie die jeweils geltenden Anforderungen für Produkt-Snippets oder Händlereinträge. Fehlende Pflichtfelder können die Eignung verhindern. Warnungen zu empfohlenen Eigenschaften unterscheiden sich von Fehlern, und keines von beiden ist automatisch ein allgemeines negatives Rankingsignal. Spam mit strukturierten Daten ist ein separates Thema.

Vor dem Bearbeiten den Erzeuger finden

Suchen Sie im installierten Theme und den Modulen nach application/ld+json und dem relevanten Schema-Typ. Theme-Releases unterscheiden sich. Hummingbirds Produkttemplate bindet _partials/microdata/product-jsonld.tpl ein; nehmen Sie nicht an, dass sein Produktdetail-Partial das Schema verantwortet.

Breadcrumb-Ausgabe und JSON-LD hängen von Theme oder Modul ab. Ermitteln Sie die erzeugende Komponente, statt nach einem universellen nativen Breadcrumb-Modul zu suchen. Eigenes JSON-LD kann als PHP-Array aufgebaut, mit json_encode() sicher codiert und über einen unterstützten Hook oder ein Template ausgegeben werden. Legen Sie für jede überlappende Entität und Eigenschaft eine Zuständigkeit fest. Wählen Sie bei einem Produkt mit Kombinationen eine andere Option und vergleichen Sie sichtbaren Preis, Bestandshinweis und übermittelten Warenkorb mit den strukturierten Daten der getesteten URL. Ändert ein Import die Verfügbarkeit, wiederholen Sie die Prüfung nach dem Import und nach Aktualisierung des betreffenden Caches. Ein manuell im Template korrigierter Wert kann eine veraltete Quelle verbergen, statt sie zu reparieren.

Für verwaltete Product-, Offer-, Breadcrumb- und Organization-Ausgaben siehe die Hilfe zu Automatic SEO Schema Rich Snippets; FAQ-Ausgaben gehören zu einer separaten Implementierung wie SEO Revolution.

1. Testen Sie repräsentative Produkte, Kategorien, die Startseite und Inhaltsseiten im Test für Rich-Suchergebnisse.
2. Prüfen Sie das gerenderte HTML und bestätigen Sie, dass die Werte zur kundensichtbaren Seite passen.
3. Prüfen Sie Preise für abgemeldete Besucher, Währung, Varianten, Steuern und Verfügbarkeit im relevanten Shop-Kontext.
4. Überwachen Sie nach der Veröffentlichung die passenden Rich-Result-Berichte in der Search Console.

Bevorzugte URLs in einer aktuellen XML-Sitemap veröffentlichen

Die Sitemap-Erzeugung stammt von einem installierten Modul, nicht von der Core-Seite „SEO & URLs“. Installieren Sie gsitemap, falls es fehlt, oder verwenden Sie die für Ihren Shop geeignete Sitemap-Implementierung. Das Modul Google Sitemap unterstützt Bildeinträge, Änderungsdaten und Dateiaufteilung; diese Funktionen erfordern keinen Austausch ab einer beliebigen Produktzahlschwelle.

Nutzen Sie die vom installierten Modul angezeigte URL. Ein üblicher gsitemap-Index ist /1_index_sitemap.xml mit der Shop-ID im Dateinamen, statt einer universellen /sitemap.xml. Nutzen Sie seine erzeugte URL für geplante Aufgaben einschließlich Token und Shop-ID; kopieren Sie keinen alten PHP-Cron-Dateinamen im Stammverzeichnis.

• Nehmen Sie die kanonischen Produkte, Kategorien und Inhaltsseiten auf, die indexiert werden sollen.
• Nehmen Sie Lieferanten- oder Markenseiten auf, wenn diese einen nützlichen kundenseitigen Zweck erfüllen.
• Schließen Sie Weiterleitungen, Fehler, noindex-Seiten, Konto-/Kassen-URLs und nicht ausgewählte Filtervarianten aus.
• Verwenden Sie korrekte lastmod-Daten für wesentliche Änderungen.
• Erzeugen Sie Dateien für die richtigen Shop-Domains und Sprachpfade.
• Erzeugen Sie die Sitemap in einer zu tatsächlichen Katalogänderungen passenden Häufigkeit neu und prüfen Sie Fehler geplanter Aufgaben.

Eine Sitemap ist auf 50.000 URLs oder 50 MB unkomprimiert je Datei begrenzt. Verwenden Sie bei mehreren Dateien einen Index. Reichen Sie die tatsächliche Index-URL in der Search Console ein und verweisen Sie in robots.txt darauf. Die Einreichung unterstützt das Auffinden, erzwingt aber keine Indexierung. Siehe Googles Sitemap-Hinweise.

Googles alter Sitemap-Ping-Endpunkt ist eingestellt. Nutzen Sie Search Console und robots.txt, statt eine erfolgreiche Modulbenachrichtigung als Beleg dafür zu betrachten, dass Google die Sitemap angenommen hat. Googles Hinweis zur Einstellung erklärt das aktuelle Einreichungsverhalten.

Benötigen Sie HTTP-Verifizierung und zusätzliche Ausschlusssteuerungen, siehe die Hilfe zu Advanced SEO Sitemap Builder.

Ein plötzlicher Rückgang veröffentlichter URLs muss untersucht werden. Prüfen Sie Antworten ohne Status 200, Weiterleitungen, noindex-Header oder -Meta-Tags und abweichende Canonicals, bevor Sie annehmen, der Katalog sei aus der Suche verschwunden. Behandeln Sie vorübergehende Serverfehler als erneut zu prüfende Fehler, nicht als intakte Seiten zur Veröffentlichung.

robots.txt für den tatsächlichen Shop erzeugen und testen

Liefern Sie die maßgebliche Datei im Origin-Stammverzeichnis aus, etwa unter https://example.com/robots.txt. Ein unter /shop/ installierter Shop kann sich zur Crawler-Steuerung nicht auf /shop/robots.txt verlassen. Nehmen Sie das tatsächliche Shop-Pfadpräfix in die Regeln auf.

Robots.txt steuert das Crawling. Sie schützt weder das Adminverzeichnis noch private Daten, und eine gesperrte URL kann weiterhin ohne abgerufene Beschreibung in der Suche erscheinen. Zur Entfernung aus dem Index lassen Sie den Crawler eine noindex-Anweisung lesen oder geben Sie den passenden Entfernungsstatus zurück. Verwenden Sie Authentifizierung und serverseitige Zugriffskontrollen für private Ressourcen. Siehe Googles robots.txt-Hinweise.

Mit der erzeugten Datei beginnen

Sichern Sie eigene Regeln vor der Nutzung von Shop-Einstellungen → Traffic & SEO → Robots-Datei erzeugen. Die Erzeugung überschreibt die Datei. Vergleichen Sie das Ergebnis vor der Bereitstellung und stellen Sie anschließend bewusst vorgenommene Anpassungen wieder her.

Die aktuelle Erzeugung von PrestaShop 9 enthält bereits die Parameter q und order, transaktionale Controller, sprachspezifische benutzerfreundliche Routen und physische Shop-Pfade. Sie sperrt außerdem Systemverzeichnisse und erlaubt dabei CSS-, JavaScript- und Bilddateien von Modulen. Erhalten Sie diese Ausnahmen.

Das Folgende ist nur ein Ausschnitt der Muster des aktuellen Generators. Es ist keine vollständige Ersatzdatei.

User-agent: *
Allow: */modules/*.css
Allow: */modules/*.js
Allow: */modules/*.png
Allow: */modules/*.jpg
Allow: */modules/*.gif
Allow: */modules/*.svg
Allow: */modules/*.webp
Allow: */modules/*.avif
Allow: /js/jquery/*
Disallow: /*?order=
Disallow: /*&order=
Disallow: /*?q=
Disallow: /*&q=

Ergänzen Sie eine Sitemap:-Zeile mit der tatsächlichen öffentlichen Sitemap-Index-URL, falls sie fehlt. Sperren Sie nicht sämtliche Query-Strings. Halten Sie Produkt- und Kategorie-URLs sowie für das Rendering benötigte Ressourcen crawlbar.

Jede URL-Familie prüfen

Erlaubte und gesperrte Beispiele testen

1. Rufen Sie die öffentliche Datei im Origin-Stammverzeichnis ab und prüfen Sie, dass der Antwortinhalt dem vorgesehenen Text entspricht.
2. Prüfen Sie repräsentative Produkt-, Asset-, Filter-, Konto- und paginierte URLs mit einem geeigneten Regelvalidator für den jeweiligen User-Agent.
3. Nutzen Sie den robots.txt-Bericht der Search Console zur Prüfung von Abruf und Parsing und anschließend die URL-Prüfung für eine betroffene Seite.
4. Prüfen Sie Bot-Anfragen in Serverprotokollen und überwachen Sie unerwartete Änderungen der Seitenindexierung.

Bei Multishop muss jeder Origin passende Regeln unter /robots.txt ausliefern. Shops mit gemeinsamem Document Root können eine geeignete gemeinsame Datei ausliefern; physisch getrennte Dateien sind nur nötig, wenn Ihre Auslieferung oder Regeln sie erfordern.

Prüfen Sie die Datei nach Änderungen an Routenmustern, öffentlichen Modulrouten, Theme-Asset-Pfaden, Sprachen, Shop-Pfaden oder der Multishop-Konfiguration. Behalten Sie die Sicherung eigener Regeln, damit eine Neuerzeugung sie nicht unbemerkt entfernt.

KI-Training, Suche und nutzerveranlasste Abrufe trennen

Wählen Sie Crawler-Präferenzen nach Zweck. Das Sperren eines Trainingsbots und eines Suchcrawlers hat unterschiedliche Auswirkungen. Robots.txt beruht auf dem dokumentierten Verhalten des Dienstes und ist kein Zugriffsschutz.

Für eine Regelung, die diese beiden Modellentwicklungs-Crawler ausschließt, lauten die zusätzlichen Gruppen:

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

Diese Gruppen drücken Ihre separaten Suchpräferenzen nicht aus. Folgen Sie der offiziellen OpenAI-Dokumentation und der Anthropic-Crawler-Dokumentation zum Zweck jedes Agents.

Google-Extended ist eine separate Steuerung für bestimmte Gemini-Trainings- und Grounding-Nutzungen. Sie bestimmt weder Aufnahme noch Ranking in der Google-Suche. Prüfen Sie Googles Crawler-Dokumentation, bevor Sie diese Regelung wählen.

Bildlegenden setzen und ausgelieferte Bilder messen

Bearbeiten Sie die Bildlegende im Produkteditor und beschreiben Sie knapp, was das Bild zeigt. Legen Sie die Konvention vor Importen fest. Der Core kann bei leerer gespeicherter Legende auf den Metatitel oder Namen des Produkts zurückfallen; ein leeres Datenbankfeld erzeugt daher nicht unbedingt ein leeres alt-Attribut. Prüfen Sie die endgültige Theme-Ausgabe.

Unter Traffic & SEO gibt es keine allgemeine Core-Einstellung für Bild-alt-Vorlagen. Bild-URL-Rewrites und physische Bilddateinamen sind ebenfalls getrennt. Prüfen Sie ausgelieferte URL, sichtbares Bild und alt-Text, statt anzunehmen, dass die Umbenennung eines Slugs jede gespeicherte Datei ändert.

Zeigen mehrere Fotos denselben Artikel, beschreiben Sie die unterscheidende Ansicht dort, wo sie relevant ist, etwa die Verstellelemente des Stuhls oder die Befestigung an der Unterseite. Prüfen Sie neben der Standardsprache auch eine übersetzte Seite. Ist die gespeicherte Bildlegende korrekt, aber der ausgelieferte Alternativtext falsch, verfolgen Sie das Theme oder Modul, das diesen Ersatzwert auswählt, bevor Sie die gesamte Bildbibliothek umschreiben.

Nutzen Sie die Hilfe zu Automatic SEO Images Alt Tags, wenn katalogweite Regeln für Alternativtexte erforderlich sind.

• Wählen Sie zur Darstellungsgröße passende Bildabmessungen und bieten Sie responsive Größen an, sofern das Theme sie unterstützt.
• Vergleichen Sie tatsächliche Bilddateigrößen und sichtbare Qualität. Der Core bietet konfigurierbare Codierung; seine Ausgabe ist nicht grundsätzlich schlecht komprimiert.
• Nutzen Sie unterstützte WebP- oder AVIF-Ausgabe, wenn PrestaShop-Release, PHP-Bildbibliothek und Theme sie unterstützen. Erzeugen Sie nach Einstellungsänderungen die betroffenen Formate oder Vorschaubilder neu.
• Wählen Sie die Qualität anhand gemessener Ergebnisse, statt einen festen Wert auf jedes Format und jeden Katalog anzuwenden.
• Laden Sie Bilder außerhalb des sichtbaren Bereichs verzögert. Laden Sie das gemessene LCP-Bild sofort und machen Sie es leicht auffindbar.
• Geben Sie Bildern intrinsische Abmessungen oder ein reserviertes Seitenverhältnis, um Layoutverschiebungen zu begrenzen.
• Nehmen Sie relevante Bilder in die Sitemap auf, wenn Ihr Generator sie unterstützt.

Benötigt das Theme-Verhalten für Bilder außerhalb des sichtbaren Bereichs zusätzliche Steuerung, nutzen Sie die Hilfe zu Automatic SEO Images Lazy Tags.

Core Web Vitals messen und Asset-Änderungen testen

Nutzen Sie Core-Web-Vitals-Felddaten, um die tatsächliche Kundenerfahrung zu verstehen, und reproduzieren Sie anschließend die langsame Seite oder Interaktion in Entwicklerwerkzeugen. Ein guter Wert garantiert kein Ranking-Ergebnis. Vergleichen Sie repräsentative Startseiten-, Listen-, Produkt- und Kassenrouten.

Bewerten Sie diese am 75. Perzentil der Besuche. PageSpeed Insights kann bei ausreichender Datenmenge CrUX-Felddaten zeigen; ein normaler Lighthouse-Seitenladetest liefert keine gleichwertige INP-Feldmessung. Nutzen Sie reproduzierte Interaktionen und Traces zur INP-Diagnose. Lighthouse Total Blocking Time ist ein nützlicher diagnostischer Näherungswert, nicht INP selbst. Siehe die INP-Hinweise.

Bilder, Schriften und Layout

Ermitteln Sie vor der Optimierung das tatsächliche LCP-Element. Ist es das Hauptbild, vermeiden Sie dessen Lazy Loading, liefern Sie ein passendes Format und eine passende Größe aus und erwägen Sie hohe Abrufpriorität oder gezieltes Vorladen. Prüfen Sie, ob Vorladevorgänge Downloads verdoppeln oder mit wichtigeren Ressourcen konkurrieren.

Reservieren Sie Platz für Banner und spät geladene Inhalte. Verwenden Sie passende Ersatzschriften und testen Sie das Verhalten von font-display auf Layoutverschiebungen. Selbst gehostete Schriften können den Verbindungsaufbau zu Drittanbietern vermeiden, doch messen Sie weiterhin das Ergebnis. Behalten Sie nur erforderliche Schriftschnitte und Zeichenbereiche bei, nutzen Sie gegebenenfalls WOFF2 und laden Sie nur früh benötigte Schriften vor.

PrestaShop-Leistungseinstellungen

Prüfen Sie unter Erweiterte Einstellungen → Leistung Smarty-Caching und CSS-/JavaScript-CCC-Optionen auf Staging. Messen Sie Cache-Verhalten und Darstellung, bevor Sie jede Optimierung produktiv aktivieren. Das Zusammenfassen von Anfragen kann manchen Seiten helfen und auf anderen wenig nutzen oder Reihenfolgeprobleme verursachen.

Prüfen Sie tatsächlich registrierte Dateien und Ausführungsabhängigkeiten. Ein in displayHeader oder displayFooter eingehängtes Modul gibt nicht zwangsläufig JavaScript aus. Direkte Asset-Tags können die Asset-Verwaltung umgehen. Unten platziertes JavaScript ohne defer ist unterstütztes Verhalten und nicht automatisch ein Fehler.

Laden Sie Assets nur auf Seiten, die sie benötigen. Testen Sie defer und async hinsichtlich Abhängigkeiten und Initialisierungsreihenfolge. Prüfen Sie Analytics-, Chat- und Werbeskripte von Drittanbietern anhand von Interaktionsaufzeichnungen, statt sie für jeden Rückgang in Felddaten verantwortlich zu machen.

Nutzen Sie den PrestaShop-Leistungsleitfaden zur Diagnose von Cache, Datenbank, Server und Frontend.

Hilfreiche Navigation und kontextbezogene Links aufbauen

Ordnen Sie den Kategoriebaum danach, wie Kunden Produkte suchen. Verwenden Sie sinnvolle Gruppen wie Schuhe, Herren-Laufschuhe und Trailrunning-Schuhe, wenn der Katalog sie hergibt. Vermeiden Sie leere oder nahezu identische Kategorien, die nur auf eine Keyword-Variante abzielen.

Prüfen Sie Breadcrumbs auf den von Ihnen verwendeten Seitentypen. Im aktuellen PrestaShop-9-Code wählt PS_PRODUCT_BREADCRUMB_CATEGORY die aktuelle Zugriffskategorie oder die Standardkategorie. Setzen Sie einen passenden Standard und testen Sie beide Navigationswege, wenn ein Produkt mehreren Kategorien angehört.

Verknüpfen Sie relevantes Zubehör und verwandte Produkte im Produkteditor und prüfen Sie anschließend, dass das Theme crawlbare Produktlinks ausgibt. Verlinken Sie Größenratgeber, Einbauhinweise, Versandbedingungen und Pflegeanleitungen aus passenden Beschreibungen und Kategorieinhalten. Halten Sie hilfreiche CMS- und Bloginhalte über normale Navigation erreichbar.

Verwenden Sie beschreibende Linktexte und korrekte endgültige URLs. Vermeiden Sie automatische Links, die Sätze verfälschen oder auf unpassende Produkte zeigen. Ein Blog kann Informationsfragen beantworten und natürlich auf hilfreiche Produkte verlinken; halten Sie jede Seite nützlich genug, um ihre Veröffentlichung zu rechtfertigen.

Für verwaltete kontextbezogene Links in Ihren Inhalten siehe die Hilfe zu Automatic Internal SEO Linker.

Status der Seitenindexierung diagnostizieren und realistische Erwartungen setzen

Öffnen Sie den Bericht Seitenindexierung der Search Console und untersuchen Sie URLs, die indexiert sein sollten. Eine hohe Gesamtzahl nicht indexierter Seiten ist nicht automatisch ein Problem: Beabsichtigte Duplikate, Weiterleitungen und noindex-Seiten gehören nicht in den Index.

Prüfen Sie bei einer wichtigen betroffenen URL den indexierten Datensatz und führen Sie einen Live-Test aus. Prüfen Sie Status, robots-Freigaben, noindex-Header oder -Meta-Tags, Canonical, gerenderte Inhalte und interne Links. Vergleichen Sie die Live-Fassung mit der zuletzt von Google verarbeiteten Fassung. Nutzen Sie die Dokumentation zum Bericht zur Seitenindexierung für jeden Status. Führen Sie ein kleines URL-Verzeichnis mit vorgesehener Suchrolle, aktueller Antwort, angegebenem Canonical, gegebenenfalls von Google ausgewähltem Canonical, zuletzt beobachtetem Zustand und Zuständigkeit. Gruppieren Sie URLs nach gemeinsamem Template oder gemeinsamer Regel, um einen einzelnen Produktfehler von einem wiederholten Kategoriefehler zu unterscheiden. Schließen Sie vom erwarteten Ausschluss einer Tracking-URL nicht auf den Zustand des kanonischen Produkts.

Seiten, deren Verbesserung sich lohnt

Stärken Sie hilfreiche Seiten mit korrekten Informationen und relevanten internen Links. Entscheiden Sie bei nahezu doppelten Varianten, welche Seiten eine eigene Indexierung verdienen, und stimmen Sie Inhalts- und Canonical-Strategie darauf ab. Behalten Sie eine nützliche Seite für ein nicht verfügbares Produkt mit korrekter Verfügbarkeit bei, wenn Kunden sie weiterhin benötigen. Entfernen Sie tatsächlich überholte Seiten oder leiten Sie nur auf gleichwertigen Ersatz weiter.

Eine kuratierte Such-Landingpage kann nützlich sein, wenn sie ein stabiles Thema, ausgewählte Produkte, eigene Hinweise und interne Links hat. Eine rohe Suchanfrage mit wiederholten Listen ist ein anderer Seitentyp. Halten Sie gewöhnliche Suchergebnisse aus Sitemaps heraus und veröffentlichen Sie kuratierte Seiten bewusst.

Useful landing page: /search/walk-in-shower-trays with original advice and selected products.
Ordinary search: a raw ?s=shower result with repeated listings and no additional purpose.

Nach einer Korrektur

Halten Sie Sitemaps und interne Links aktuell. Beantragen Sie gegebenenfalls die Indexierung wichtiger geänderter Seiten und die Validierung eines behobenen Berichtsproblems. Wiederholte Einreichungen zwingen Google nicht, eine gecrawlte Seite zu indexieren.

Es gibt keinen festen Termin für SEO-Verbesserungen nach einer Modulinstallation. Google muss Änderungen erneut crawlen und verarbeiten, und dies kann je URL unterschiedlich lange dauern. Ein Modul kann weder Indexierung, Rich-Suchergebnisse, Rankings noch die Wiederherstellung von Zugriffszahlen garantieren. Verfolgen Sie betroffene URLs und Suchleistung über die Zeit, statt das Installationsdatum als Frist anzusehen.

Jeder SEO-Funktion einen klaren Verantwortlichen zuweisen

Betreiben Sie mehrere SEO-Werkzeuge, entscheiden Sie, welche Komponente Canonical-Links, robots-Anweisungen, hreflang, Open-Graph-Tags und jede strukturierte Datenentität verantwortet. Mehrere JSON-LD-Blöcke sind nicht grundsätzlich falsch; widersprüchliche oder doppelte Beschreibungen derselben Entität erfordern Aufmerksamkeit.

Ein vertrauter WordPress-Pluginname belegt keine PrestaShop-Kompatibilität eines ähnlich benannten Produkts oder eines Plugins einer anderen Plattform. Prüfen Sie das tatsächliche Modul und die Plattformversion, die Sie kombinieren möchten.

1. Listen Sie das Theme und die Module auf, die SEO-Ausgaben erzeugen.
2. Wählen Sie einen Verantwortlichen je überlappender Funktion und deaktivieren Sie widersprüchliche Ausgaben an anderer Stelle.
3. Prüfen Sie das endgültige HTML und die Header auf allen wichtigen Seitentypen, Sprachen und Shop-Domains.
4. Testen Sie nach Theme-, SEO-Modul- oder Katalogänderungen erneut.

SEO Revolution enthält eine Theme-Head-Bereinigung, und Blog Revolution kann seine strukturierten Blogdaten an diese Integration abgeben.

Konfiguration, Werkzeug, Entwicklung oder Audit wählen

Nutzen Sie ein Werkzeug für eine wiederkehrende, klar diagnostizierte Anforderung. Ein einzelner falscher Titel, ein versehentliches noindex oder eine fehlende Weiterleitung benötigt möglicherweise nur eine Konfigurations- oder Inhaltskorrektur. Eine Suite ersetzt nicht die Entscheidung, welche URLs existieren und indexiert werden sollen.

Die Produktanzahl eines Katalogs allein bestimmt nicht das Vorgehen. Ein kleiner mehrsprachiger Shop kann einen komplizierten Zuordnungsfehler haben, während ein größerer Shop bereits konsistente Ausgaben pflegt. Fragen Sie vor dem Werkzeugkauf, welche wiederkehrende Aufgabe es übernimmt, wer seine Regeln pflegt und woran Sie erkennen, ob es diese Aufgabe gelöst hat.

Erkennen, wann ein SEO-Audit eine konkrete Frage beantwortet

Beginnen Sie mit einem konkreten Symptom und den betroffenen Seiten. Ein Zugriffsrückgang, eine sinkende Zahl hilfreicher indexierter Seiten, defekte Migrationsweiterleitungen oder verlorene Rich-Result-Eignung können eine nähere Prüfung rechtfertigen. Finden Sie mit Prüfungen auf URL-Ebene die Ursache hinter einer Zahl oder Bewertung.

• Vergleichen Sie Klicks und Impressionen der Search Console mit Analysedaten. Prüfen Sie Zeiträume, Suchanfragengruppen, Land, Gerät und Saisonalität.
• Vergleichen Sie das Änderungsdatum mit Bereitstellungen, URL-Bearbeitungen, robots-Änderungen, Importen und bestätigten Suchupdates.
• Untersuchen Sie, wenn eine hilfreiche Seite aus dem Index verschwindet; behandeln Sie nicht jeden erwarteten Alternativseitenausschluss als Fehler.
• Testen Sie nach einem Redesign Canonical-Links, Schema, Überschriften, Inhalte und interne Links, auch wenn URLs unverändert bleiben.
• Prüfen Sie langsame Antworten, wiederholte Serverfehler und unzugängliche Ressourcen neben suchspezifischen Problemen.

Ein ungeklärter Rückgang ist nicht automatisch ein Fehler in Ihrem Shop. Suchnachfrage, Wettbewerb, Messänderungen und Rankingänderungen bleiben mögliche Ursachen. Auch ein bestätigtes Suchupdate schließt ein gleichzeitiges technisches Problem nicht aus.

Verwenden Sie eine bestätigte Search-Console-Property, die die untersuchten Shop-URLs abdeckt. Fehlt Ihnen der Zugang oder ist der Bericht leer, lassen Sie die zuständige Person Property und Umfang bestätigen, bevor Sie Schlüsse ziehen. Fehlende Daten in der falschen Property belegen nicht, dass Ihre Produkte keine Suchbesuche erhalten.

Eine erste Selbstprüfung

1. Prüfen Sie Trends bei Seitenindexierung und Leistung und untersuchen Sie dann eine kleine Auswahl wichtiger betroffener URLs.
2. Crawlen Sie repräsentative Seiten und suchen Sie nach defekten Links, Schleifen, unerwarteten Canonical-Zielen und widersprüchlichen Anweisungen.
3. Prüfen Sie ein Produkt, eine Kategorie, Seite zwei, eine Filtervariante, eine Sprachalternative und die Startseite.
4. Rufen Sie robots.txt und den tatsächlichen Sitemap-Index ab. Bestätigen Sie, dass Inhalt und aufgeführte URLs geeignet sind.
5. Nutzen Sie den Test für Rich-Suchergebnisse und PageSpeed Insights für die Seitentypen, auf denen das Symptom auftritt.

Eine site:-Suche kann unerwünschte Beispiele zeigen, aber ihre Ergebniszahl ist kein zuverlässiges Indexverzeichnis. Auch die eigenen Grenzen eines Crawlers beeinflussen, was ein schneller Crawl aussagen kann.

# Read the canonical in the returned HTML
curl -sS https://example.com/42-mens-leather-wallet.html | grep -i canonical

# Check public files using their actual locations
curl -sS -o /dev/null -w '%{http_code}
' https://example.com/robots.txt
curl -sS -o /dev/null -w '%{http_code}
' https://example.com/1_index_sitemap.xml

Diese Befehle lesen nur. Ein Canonical kann über mehrere Zeilen laufen oder Attribute in anderer Reihenfolge haben; prüfen Sie daher das vollständige HTML, wenn eine einfache Textprüfung es übersieht. Folgen Sie einer unerwarteten Weiterleitung und prüfen Sie sie, statt jede erste Antwort ungleich 200 als denselben Fehler zu behandeln.

Zeigt die Prüfung ein klares Einzelproblem, beheben Sie es und prüfen Sie die betroffenen Seiten. Widersprechen sich mehrere Systeme oder bleibt die Ursache unklar, sollte ein Audit betroffene URLs, reproduzierbare Befunde, Priorität, Korrekturvorschläge und Validierungsschritte liefern. Vereinbaren Sie Umfang, Zugang und Ergebnisse mit dem Anbieter. Ein Audit diagnostiziert und verspricht keine Traffic-Erholung. Unterscheiden Sie bestätigte Fehler, Hypothesen und Grenzen der Nachweise. Ein Crawler kann keine Seite melden, die er nie entdeckt hat, und sein fehlerfreier Bericht belegt weder, was Google indexiert hat, noch was Kunden in einem anderen Shop-Kontext erhalten.

Eine Kategorie mit sinkenden Suchbesuchen untersuchen

Angenommen, eine Kategorie für Trailrunning-Schuhe verliert nach einer Theme-Veröffentlichung Suchklicks, während eine vergleichbare Kategorie für Straßenlaufschuhe stabil wirkt. Dies ist eine hypothetische Untersuchung, keine Behauptung, dass eine Veröffentlichung stets einen Rückgang erklärt. Bewahren Sie betroffene URLs und Veröffentlichungsprotokoll auf und vergleichen Sie relevante Suchanfragengruppen, Geräte und Länder über vergleichbare Zeiträume, bevor Sie eine Korrektur wählen.

1. Beobachtung prüfen. Bestätigen Sie die richtige Search-Console-Property und den Zielseitenfilter. Vergleichen Sie Impressionen, Klicks und Suchanfragen und prüfen Sie danach Analytics und tatsächliche Bestellungen separat. Eine geänderte Einwilligungs- oder Analytics-Einrichtung kann erfasste Sitzungen verändern, ohne dass sich Suchklicks ebenso ändern.
2. Seiten vergleichen. Prüfen Sie betroffene Kategorie und Vergleichskategorie im selben Shop und derselben Sprache. Kontrollieren Sie Antwort, Header, robots-Anweisungen, Canonical, sichtbare Überschrift, Produktraster und Verlinkungen aus der Navigation.
3. Fehler reproduzieren. Angenommen, die betroffene Kategorie liefert eine normale Seite, gibt aber die Startseite als Canonical an, während die Sitemap weiterhin die Kategorie aufführt. Dokumentieren Sie diese Ausgabe und prüfen Sie den indexierten Datensatz. Gehen Sie nicht davon aus, dass Google dem falschen Signal bereits gefolgt ist.
4. Erzeugende Komponente finden. Vergleichen Sie die Theme-Änderung mit der Komponente, die das Canonical erzeugt. Prüfen Sie kategoriespezifische Einstellungen und Modulüberschreibungen dieser Ausgabe. Verursacht ein gemeinsames Template den Fehler, korrigieren Sie diese Quelle, statt daneben ein weiteres Canonical-Tag einzufügen.
5. Korrektur auf Staging nachweisen. Prüfen Sie das vorgesehene Kategorie-Canonical und testen Sie weitere Kategorien, Paginierung, Filter und Sprachfassungen mit demselben Code. Bestätigen Sie, dass Produktraster, Links und Kaufprozess weiterhin funktionieren.
6. Veröffentlichen und URLs nachverfolgen. Stellen Sie die gezielte Korrektur bereit, prüfen Sie das Live-HTML unabhängig und bewahren Sie den Veröffentlichungszeitpunkt bei den Nachweisen auf. Aktualisieren Sie andere widersprüchliche Signale und verfolgen Sie die betroffenen URL-Datensätze bei Googles erneutem Crawling.

Der unmittelbare Abnahmenachweis sind die korrigierte Ausgabe und ein funktionierender Shop. Eine spätere Erholung der Klicks ist eine Beobachtung, die anhand von Nachfrage und anderen Änderungen bewertet werden muss, kein Beleg dafür, dass jeder verlorene Besuch dieselbe Ursache hatte. War das Canonical bereits korrekt, bewahren Sie dieses Ergebnis auf und untersuchen Sie die nächste plausible Ursache, statt die Beispielkorrektur trotzdem anzuwenden.

Die Ergebnisse der Bewertung vereinbaren

Verlangen Sie nach Geschäftsauswirkung und Aufwand priorisierte Befunde mit Beispiel-URLs, Ursache, Korrekturvorschlag und Validierungsweg. Eine SEO-Prüfung von außen kann öffentliche Seiten nutzen. Rein lesender Search-Console-Zugang ergänzt verfügbare Nachweise zu Indexierung und Leistung. Vereinbaren Sie weiteren Zugang separat, statt vorauszusetzen, dass eine prüfende Person einen Backoffice-Zugang benötigt.

Ein nützlicher Maßnahmenplan unterscheidet Aufgaben, die Ihr Team im Editor erledigen kann, von Modulkonfiguration und Entwicklung. Legen Sie fest, wer umsetzt, wer die Seitenprüfungen freigibt und wer das Ergebnis anschließend überwacht. Eine Diagnose allein enthält diese Arbeiten nicht, und ein allgemeiner Export von Crawler-Warnungen erklärt nicht, welche Aufgabe Ihr Shop zuerst erledigen sollte.

Fragen an Ihre Entwicklung oder Agentur

• Welche wirtschaftlich wichtigen URLs sind betroffen, und welche vergleichbaren Seiten funktionieren weiterhin?
• Welche Nachweise verbinden das Symptom mit der vorgeschlagenen Ursache, und was bleibt unklar?
• Welches Theme, Modul, welche Serverregel oder welcher Import erzeugt die strittige Ausgabe, und könnte eine geplante Aufgabe die Korrektur überschreiben?
• Welche Shops, Sprachen, Währungen und Kundenkontexte werden getestet, einschließlich unverändert bleibender Seiten?
• Was genau wird geändert, wie machen wir es rückgängig, und werden Produkt- oder Bestelldaten berührt?
• Wer veröffentlicht, bewahrt die Nachweise vor und nach der Änderung auf und prüft die betroffenen URLs nach Veröffentlichung?

Technische und SEO-Wartung wiederholbar dokumentieren

Planen Sie eine kurze regelmäßige Prüfung und eine ausführlichere Kontrolle nach größeren Änderungen. In einer halben Stunde können Sie eine Stichprobe prüfen und Folgeaufgaben ermitteln; sie garantiert kein vollständiges Audit für jeden Shop.

Zeigen Sie Bereinigungskandidaten vor dem Löschen in einer Vorschau an, halten Sie angemessene Aufbewahrungsfristen ein und verwenden Sie bei Bedarf begrenzte Stapel. Alte Warenkörbe mit Bestellbezug, aktive Verweise und andere Shops benötigen gezielten Schutz. Löschen Sie Bestell- oder Kundendaten nicht allein deshalb, weil eine Tabelle groß ist.

Für den Bereinigungsablauf mit vorheriger Zählung und aufgabenspezifische Aufbewahrungssteuerung nutzen Sie die Hilfe zu Database Cleanup.

Verfolgen Sie OPcache-Skripte, Speicher, Treffer und Fehltreffer; vergleichen Sie Gruppen langsamer Abfragen nach Route oder Controller und dokumentieren Sie die Anzahl aufgenommener und übersprungener Sitemap-URLs sowie die letzte erfolgreiche Sicherung. Verwenden Sie vergleichbare Zeiträume, damit die Aufzeichnung Trends zeigt.

Für die Diagnose von Modul-Cache-Ebenen und langsamen Abfragen nutzen Sie die Hilfe zu Performance Revolution.

Beheben Sie zuerst Sicherheitslücken und defekte Einkaufsfunktionen. Bearbeiten Sie dann Serverfehler und versehentliche Indexierungssperren, falsche Ziele, Inhalts- und Strukturierte-Daten-Probleme sowie gemessene Leistungsprobleme. Überprüfen Sie Änderungen vor der Bereitstellung auf Staging und wiederholen Sie danach die betroffenen Kunden- und Crawler-Wege.

Änderung erproben und Live-Umstellung planen

1. Ausgangszustand festhalten. Sichern Sie repräsentative URLs, Weiterleitungen, HTML und Header mit Shop, Sprache und relevanter Modulkonfiguration. Nehmen Sie eine nicht betroffene Vergleichsseite und alte Adressen auf, über die weiterhin Kunden kommen.
2. Kopie vorbereiten. Schützen Sie Staging mit Zugriffskontrollen, neutralisieren Sie Transaktions-E-Mails und produktive externe Aktionen und prüfen Sie, ob relevante Themes, Module und Katalogzustände reproduziert werden. Verwenden Sie beim Testen zum Host passende Canonical- und Alternativ-URLs, statt Staging-Adressen für ein versehentliches Kopieren in die Produktion stehen zu lassen.
3. Geplante Änderung dokumentieren. Listen Sie Einstellungen, Dateien, Regeln oder begrenzte Datenbestände auf, die geändert werden, sowie die für jede Ausgabe verantwortliche Komponente. Erzeugt ein Import den Fehler, erproben Sie diesen Import, statt nur manuelles Speichern im Editor zu testen.
4. Abnahmewege durchlaufen. Prüfen Sie betroffene Seitengruppen und beabsichtigte Ausnahmen und navigieren Sie dann von der Navigation zu Produkt, Warenkorb und Checkout. Beziehen Sie bei Änderungen an Server-Rewrites oder Zugriffsregeln funktionale Modulrouten und Anbieter-Callbacks ein.
5. Rücknahme vorbereiten. Bewahren Sie vorherige relevante Konfiguration und Dateien auf und definieren Sie das Symptom, das eine Rücknahme auslösen würde. Behalten Sie bei Datenänderungen die bisherigen betroffenen Werte und ein geprüftes Rücknahmeverfahren. Das Wiederherstellen einer alten Gesamtdatenbank kann neue Live-Bestellungen überschreiben.
6. Veröffentlichung vereinbaren. Wählen Sie ein Zeitfenster, das Ihr Team betreuen kann, benennen Sie die ausführende und prüfende Person und berücksichtigen Sie Importe, Feeds und Cache-Aufgaben rund um die Änderung. Übertragen Sie die getestete Änderung in den aktuellen Shop, statt veraltete Staging-Daten darüberzukopieren.
7. Produktion unabhängig prüfen. Bestätigen Sie nach Aktualisierung der Caches Live-Host, Weiterleitungen, Header, Canonical, Sprachalternativen und betroffene Kundenwege. Prüfen Sie, dass in der Produktion keine versehentlich kopierten Staging-noindex-Anweisungen oder Zugriffssperren vorhanden sind und die geschützte Kopie weiterhin geschützt bleibt.
8. Technische Prüfung und Suchbeobachtung trennen. Prüfen Sie Ausgabe und Einkauf sofort und untersuchen Sie danach betroffene URL-Datensätze und Suchtrends, sobald neue Beobachtungen vorliegen. Dokumentieren Sie andere Veröffentlichungen, damit eine spätere Veränderung nicht automatisch dieser Änderung zugeschrieben wird.

Search Console, ein Website-Crawler, PageSpeed Insights und der Test für Rich-Suchergebnisse beantworten unterschiedliche Fragen. Vergleichen Sie ihre Befunde mit gerenderten Seiten und Serververhalten. Nutzen Sie den Leitfaden zur Fehlerbehebung für Weiterleitungsschleifen, 404- und Anwendungsfehler, bevor Sie weitere SEO-Änderungen vornehmen.

Häufige Fragen von Shopbetreibern

Kann ich ein klares Problem ohne kostenpflichtiges Audit beheben?

Ja. Können Sie die Ursache ermitteln und die Korrektur prüfen, wählen Sie das passende Vorgehen über Konfiguration, Inhalte oder Entwicklung. Eine Diagnose ist sinnvoll, wenn Ursache oder Umfang unklar sind, nicht allein wegen Warnungen in einem Bericht.

Bedeuten mehr ausgeschlossene URLs, dass meine SEO schlechter wird?

Prüfen Sie, um welche URLs es sich handelt. Erwartete Alternativen und Weiterleitungen können zunehmen, während nützliche Seiten indexiert bleiben. Beobachten Sie die verkaufsrelevanten Seiten, die Sie indexieren wollten, und untersuchen Sie Änderungen in dieser Gruppe, statt um jeden Preis eine größere Gesamtzahl anzustreben.

Sollte ein kleiner Shop eine SEO-Suite oder ein Audit kaufen?

Entscheiden Sie anhand des Problems und der Fähigkeit Ihres Teams, die Lösung zu pflegen. Ein einzelner verstandener Fehler benötigt eine Korrektur; wiederkehrende Regeln können ein Werkzeug rechtfertigen; ein unerklärter erheblicher Verlust kann auch bei einem kleinen Katalog eine Bewertung rechtfertigen.

Muss ich für gute Rankings Produkt-IDs entfernen oder das Theme wechseln?

Beides folgt nicht allein aus einem Rankingproblem. IDs stehen Rankings nicht entgegen, und ein Theme sollte anhand seiner tatsächlichen Ausgabe und des Kundenwegs bewertet werden. Klären Sie, was fehlschlägt, bevor Sie sich für einen URL-Umzug oder ein Ersatztheme entscheiden.

Der Crawler meldet keine Fehler. Kann ich die Untersuchung beenden?

Ein Crawl hat einen Umfang und einen Entdeckungsweg. Vergleichen Sie seine Abdeckung mit wichtigen Seiten, der Search Console und dem relevanten Kundenkontext. Eine gültige Antwort belegt weder hilfreiche Inhalte noch korrekte Indexierung oder einen funktionierenden Kauf.

Enthält ein Audit Korrekturen und laufende Überwachung?

Die verlinkte Bewertung liefert Befunde und einen Maßnahmenplan. Umsetzung, Texterstellung, Linkaufbau und laufende Überwachung benötigen einen separaten Umfang und klare Zuständigkeit. Vereinbaren Sie deshalb die Übergabe, bevor Sie einen Bericht als abgeschlossene Behebung betrachten.

Woran erkenne ich vor Rankingänderungen, dass eine Korrektur wirkt?

Bewahren Sie die ursprüngliche Fehlerreproduktion auf und wiederholen Sie ihre Abnahmeprüfungen im Live-Shop. Die korrigierte Antwort oder Ausgabe ist ein direkt verfügbarer Nachweis. Suchsichtbarkeit erfordert spätere Beobachtung und hat keinen garantierten Erholungstermin.

Können wir eine SEO-Veröffentlichung sicher rückgängig machen?

Bereiten Sie die Rücknahme bereits bei der Erprobung vor. Stellen Sie die betroffenen Einstellungen, Dateien oder begrenzten Werte wie geplant wieder her, schützen Sie aktuelle Bestellungen und prüfen Sie anschließend die Produktion erneut. Eine Sicherung ist nur nützlich, wenn Sie verstehen, was ihre Wiederherstellung ersetzen würde.