Sitemap in Shopware: Bordmittel, Plugin oder Eigenbau
Drei Wege, eine Entscheidung. Wir bauen selbst ein Sitemap-Plugin — und sagen trotzdem in den meisten Fällen, dass der Standard reicht.
Wir entwickeln und pflegen ein eigenes Sitemap-Plugin für Shopware (Sitemap Generator). Das ist der Grund, warum dieser Text nicht empfiehlt, eines zu kaufen — sondern beschreibt, woran man erkennt, ob man eines braucht.
Die Frage taucht meist auf, wenn eine URL nicht im Index ist und jemand die Sitemap als Ursache vermutet. In der Mehrzahl der Fälle liegt es nicht daran.
Erst die Diagnose
Bevor eine der drei Optionen zur Debatte steht, gehört eine Frage beantwortet: Welche URLs fehlen, und warum?
Der Kern speist die Sitemap aus fünf Quellen — Startseite, Kategorien, Produkte, Landingpages und selbst gepflegte URLs. Was dort nicht vorkommt, steht nicht drin. Details dazu in Die Sitemap in Shopware: was drinsteht und was fehlt.
Daraus ergeben sich drei Fälle, und nur einer davon führt zu einer Erweiterung:
| Befund | richtige Antwort |
|---|---|
| Seitentyp gehört zu den fünf Quellen, fehlt trotzdem | Konfiguration prüfen: Verkaufskanal, Ausschlussmuster, letzter Lauf |
| Wenige einzelne URLs fehlen | custom_urls ergänzen |
| Ein ganzer Seitentyp fehlt systematisch | Quelle erweitern — hier wird eine Erweiterung relevant |
Die drei Optionen
Bordmittel
Reicht, wenn: Ihre wichtigen Seiten Produkte, Kategorien und Landingpages sind; Sie einsprachig oder mit wenigen Sprachen arbeiten; und die Bildersuche kein nennenswerter Kanal ist.
Das trifft auf die meisten Shops zu. Der Standard ist unauffällig, wird mit jeder Version mitgepflegt und kostet nichts an Wartung.
Grenzen, gemessen: keine Bild-Einträge, keine hreflang-Angaben in der Sitemap, keine Quellen ausserhalb der genannten fünf.
Plugin
Lohnt, wenn mindestens einer dieser drei Bedarfe besteht:
- Bild-Einträge — messbar relevant nur, wenn ein spürbarer Teil des Traffics aus der Bildersuche kommt. Sehen Sie in der Search Console nach, bevor Sie das annehmen.
- hreflang in der Sitemap — sinnvoll bei sehr grossen mehrsprachigen Katalogen, wo die Angaben gebündelt gelesen werden sollen.
- Zusätzliche Seitentypen — Hersteller, eigene Entitäten, Inhalte aus Erweiterungen.
Unsere eigene Erweiterung deckt genau diese Bedarfe ab — Bild-Einträge,
hreflang als xhtml:link und zusätzliche Inhaltstypen, je Verkaufskanal
steuerbar. Was sie im Einzelnen tut, steht auf der
Produktseite; ob Sie sie brauchen,
entscheidet die Tabelle weiter unten.
Was Sie dafür eintauschen: Eine Erweiterung mehr, die bei jedem Versionswechsel geprüft werden muss. Wie schnell so etwas still ausfällt, haben wir an einem eigenen Fall gemessen — wenn der Shopware-Kern eine Plugin-Route verdrängt.
Das ist kein Argument gegen Erweiterungen. Es ist ein Argument dafür, eine Erweiterung nur einzusetzen, wenn sie einen benannten Bedarf deckt.
Eigenbau
Lohnt fast nie. Eine Sitemap ist ein gelöstes Problem; sie selbst zu erzeugen heisst, Blockverarbeitung, Dateiteilung, Komprimierung und einen Index nachzubauen, die es schon gibt.
Es gibt eine Ausnahme: Wenn die Sitemap Inhalte aus einem System ausserhalb von Shopware enthalten muss — etwa ein Magazin auf einer anderen Plattform unter derselben Domain. Dann ist der richtige Weg meist kein Eigenbau innerhalb von Shopware, sondern ein Sitemap-Index, der auf beide Systeme verweist.
Die Entscheidungshilfe
| Frage | ja | nein |
|---|---|---|
| Fehlt ein ganzer Seitentyp, der nicht zu den fünf Quellen gehört? | Plugin prüfen | weiter |
| Kommt spürbarer Traffic aus der Bildersuche? | Plugin prüfen | weiter |
| Sehr grosser, mehrsprachiger Katalog mit Bedarf an hreflang in der Sitemap? | Plugin prüfen | weiter |
| Muss die Sitemap Inhalte ausserhalb von Shopware abdecken? | Sitemap-Index über beide Systeme | weiter |
| Sonst | Bordmittel, plus Konfiguration |
Vier Fragen. Wer alle mit nein beantwortet — und das sind die meisten —, braucht keine Erweiterung, sondern eine saubere Konfiguration.
Was in keinem Fall hilft
Eine Sitemap repariert keine Indexierung. Sie ist ein Vorschlag. Wenn eine Seite nicht indexiert wird, liegt das häufiger an Inhalt, internen Links, Canonical-Angaben oder Robots-Signalen als am Fehlen eines Eintrags.
Mehr Einträge sind nicht besser. Eine Sitemap mit 200.000 URLs, von denen 150.000 dünn sind, macht das Problem sichtbarer, nicht kleiner.
Häufigkeits- und Prioritätsangaben ändern nichts. Google hat mehrfach erklärt, sie nicht auszuwerten. Eine Erweiterung, die damit wirbt, wirbt mit einer Funktion ohne Wirkung.
Wie wir das im Projekt entscheiden
Wir sehen zuerst in der Search Console nach, welche URLs tatsächlich fehlen und welchen Status sie haben. Meist zeigt sich dabei, dass die Sitemap nicht das Problem war — sondern ein Canonical, ein Redirect oder eine Seite ohne eingehende Links.
Wenn ein echter Bedarf bleibt, entscheiden wir mit der Tabelle oben. Auch dann gilt: eine Erweiterung ist eine Verpflichtung über Versionswechsel hinweg, kein einmaliger Einkauf.
Wie wir SEO-Fragen dieser Art angehen, steht auf SEO-Agentur. Wenn es um die technische Umsetzung im Shop geht, gehört das zu Shopware-Support.
Häufige Fragen
- Wir haben 200.000 Produkte. Brauchen wir ein Plugin?
- Nicht deshalb. Der Kern legt ab 49.999 URLs eine weitere Datei an und schreibt einen Index darüber. Wenn die Erzeugung zu lange dauert, ist die Blockgrösse der erste Hebel, nicht eine Erweiterung.
- Bringt eine Bild-Sitemap messbar etwas?
- Das hängt davon ab, wie viel Ihres Traffics aus der Bildersuche kommt. Sehen Sie zuerst in der Search Console nach; ohne nennenswerten Anteil ist es Aufwand ohne Gegenwert.
- Reicht hreflang in der Storefront nicht?
- In den meisten Fällen ja. Google wertet beide Wege aus. Der Vorteil der Sitemap-Variante liegt bei sehr grossen mehrsprachigen Katalogen, weil die Angaben dort gebündelt und ohne Seitenabruf lesbar sind.
- Was ist mit Erweiterungen, die ihre eigenen Seiten mitbringen?
- Deren URLs kennt der Kern nicht. Entweder liefert die Erweiterung selbst eine Sitemap-Quelle, oder die URLs kommen über die selbst gepflegten Einträge dazu.