Sitemap-Prioritäten in Shopware 6: Was wirklich zählt – und was ein Mythos ist - Shopware Agentur

Lesezeit: 11 Min · getestet auf Shopware 6.7.x

Kurz vorweg (TL;DR): Die XML-Sitemap-Tags <priority> und <changefreq> werden von Google vollständig ignoriert – und von Bing ebenfalls. Wer Stunden damit verbringt, Kategorien auf 0.9 und Produkte auf 0.7 zu setzen, optimiert ein totes Signal. Das einzige Sitemap-Datum, das Google nutzt, ist <lastmod> – und nur, wenn es ehrlich ist. Die echten Hebel sind Sitemap-Hygiene (nur kanonische, indexierbare 200er-URLs) und ein korrektes lastmod. In diesem Beitrag zeigen wir die Faktenlage mit Originalquellen – und die saubere Umsetzung in Shopware 6.7 inkl. Code.

Das Problem, das diesen Beitrag ausgelöst hat

Bei einem Audit eines Shopware-6-Shops fiel uns eine typische Sitemap-Struktur auf:

Seitentyp	priority	changefreq
Startseite	1.0	daily
Kategorien	0.5	daily
Produkte	0.5	hourly
Hersteller	0.5	daily
Blog-Beiträge	1.0	daily
Navigation	0.5	daily

Zwei Dinge springen sofort ins Auge: Die Blog-Beiträge stehen mit priority 1.0 höher als die umsatztragenden Kategorieseiten (0.5), und alle Produkte melden changefreq hourly – als ob sich das Sortiment stündlich änderte. Auf den ersten Blick ein klarer SEO-Fehler.

Auf den zweiten Blick ist die Geschichte interessanter – und lehrreicher. Denn diese Werte sind größtenteils Shopware-Standard plus Plugin-Defaults, und sie sind für Google schlicht irrelevant. Die eigentlichen Probleme liegen woanders. Genau das macht das Thema zu einem perfekten Lehrstück für sauberes technisches SEO.

Was der Standard sagt (sitemaps.org)

Das offizielle Sitemap-Protokoll definiert <priority> als Wert zwischen 0.0 und 1.0, Standard 0.5. Entscheidend ist die ausdrückliche Einschränkung: Der Wert ist rein site-intern relativ und hat keinen Einfluss darauf, wie deine Seiten gegen andere Websites bewertet werden. Wörtlich heißt es im Protokoll, die Priorität beeinflusse „not likely“ die Position in den Suchergebnissen.

Die zweite, oft übersehene Konsequenz: Weil der Wert relativ ist, bringt es nichts, allen URLs eine hohe Priorität zu geben. Das sitemaps.org-Protokoll warnt explizit, dass das Hochsetzen aller URLs nutzlos ist – die Skala ergibt nur Sinn, wenn sie differenziert.

<changefreq> kennt genau sieben Werte – always, hourly, daily, weekly, monthly, yearly, never – und ist laut Protokoll ausdrücklich „a hint and not a command“. Crawler dürfen hourly-Seiten seltener und yearly-Seiten häufiger besuchen, ganz nach eigenem Ermessen.

Was Google tatsächlich macht

Hier wird aus „relativ unwichtig“ ein klares „wird ignoriert“.

In der offiziellen Google-Search-Central-Dokumentation (Stand Dezember 2025) steht unmissverständlich, dass Google die Werte von <priority> und <changefreq> ignoriert. Das ist keine neue Erkenntnis:

Bereits 2015 relativierte Googles John Mueller die Tags als kaum noch relevant und empfahl, stattdessen direkt den Zeitstempel zu pflegen.
2017 wurde Gary Illyes (Google) auf die Frage, welche Sitemap-Felder Google ignoriert, deutlicher und nannte priority/changefreq sinngemäß „a bag of noise“ – also selbstgemeldetes Rauschen, dem Google nicht traut.

Der Grund ist simpel: Es sind unverifizierbare Selbstauskünfte. Jeder Shop könnte alles auf 1.0/hourly setzen. Ein Signal, das jeder zu seinen Gunsten manipulieren kann, ist für eine Suchmaschine wertlos.

Was Google aus der Sitemap nutzt, ist dagegen klar: die Liste der kanonischen URLs selbst (welche Seiten du indexiert sehen willst) und – mit Einschränkung – <lastmod>.

Und Bing? (Plus die eine Ausnahme)

Bing zieht 2025 mit. Im Bing Webmaster Blog (Juli 2025, mitgezeichnet von Fabrice Canel) heißt es, optionale Tags wie changefreq und priority würden von Bing ignoriert und beeinflussten weder Crawling noch Ranking. Bing setzt – wie Google – voll auf lastmod, das im KI-/Copilot-Zeitalter sogar wichtiger werde. Da DuckDuckGo seine Ergebnisse überwiegend von Bing bezieht, gilt dort dasselbe.

Die einzige relevante Ausnahme ist Yandex: Dessen Dokumentation listet priority und changefreq weiterhin als unterstützte Tags und nutzt die Priorität für die Crawl-Reihenfolge. Für die allermeisten deutschen Shops ist Yandex-Traffic jedoch vernachlässigbar – kein Grund, die Tags zu pflegen.

Das einzige Datum, das zählt: lastmod

<lastmod> ist der eine Sitemap-Wert, der echten Nutzen bringt – aber nur unter einer Bedingung: Ehrlichkeit. Google nutzt lastmod laut Doku nur, wenn der Wert „consistently and verifiably accurate“ ist, also nachweislich mit der tatsächlichen letzten Änderung der Seite übereinstimmt.

Der klassische Fehler: Viele CMS und Generatoren setzen lastmod bei jeder Sitemap-Erzeugung auf „jetzt“. Mueller dazu sinngemäß: Wenn ihr uns sagt, eine seit sieben Jahren unveränderte Seite habe sich „gestern“ geändert, glauben wir euch irgendwann nicht mehr. Das Vertrauen ist faktisch binär – ist die Historie einmal unzuverlässig, ignoriert Google das Feld komplett.

Regeln für ein gutes lastmod:

Nur bei echter, signifikanter Inhaltsänderung aktualisieren (Hauptinhalt, strukturierte Daten, Links) – nicht bei einer Copyright-Jahr-Anpassung im Footer.
Format: W3C-Datetime / ISO 8601, z. B. 2026-06-05 oder mit Zeit und Zeitzone 2026-06-05T14:30:00+02:00.
Es muss das Änderungsdatum der Seite sein, nicht der Erzeugungszeitpunkt der Sitemap.

Korrektes lastmod hilft Suchmaschinen, geänderte Seiten schneller neu zu crawlen und unveränderte zu überspringen – das ist der eigentliche „Steuerungseffekt“, den viele fälschlich von priority erwarten.

Der wahre Hebel: Sitemap-Hygiene

Wenn priority/changefreq nichts bringen – was bringt dann etwas? Eine saubere URL-Auswahl. Die Grundregel lautet: In die Sitemap gehören ausschließlich kanonische, indexierbare URLs, die HTTP 200 liefern. Alles andere sendet widersprüchliche Signale.

Konkret schaden in der Sitemap:

Per robots.txt gesperrte URLs. Das ist ein direkter Selbstwiderspruch: Die Sitemap fordert Google zum Crawlen auf, robots.txt verbietet es. (Genau dieser Fall lag im eingangs erwähnten Shop vor – die /navigation/-URLs standen in der Sitemap, waren aber per Disallow: /navigation/ gesperrt.)
noindex-URLs – du erzählst Google zwei Geschichten gleichzeitig.
Weiterleitungen (3xx) – der Crawl-Hinweis landet auf einem Umweg statt am Ziel.
Nicht-kanonische / Duplikat-URLs – Google nutzt die Sitemap als einen Faktor bei der Canonical-Wahl; Duplikate verwässern das.
404/410 – signalisieren, nicht existierende Seiten zu indexieren; häufen sich Fehler, sinkt das Vertrauen in die gesamte Sitemap.

Eine „dreckige“ Sitemap lenkt Crawler auf wertlose URLs und erschwert die Diagnose in der Google Search Console (Stichwort „Discovered – currently not indexed“). Best Practice: Sitemap automatisiert aktuell halten und den GSC-Sitemaps-Bericht regelmäßig prüfen.

Die Prioritäts-Hierarchie – wofür sie noch gut ist

Heißt das, die Reihenfolge ist egal? Für Googles Ranking: ja. Konzeptionell: nein. Eine durchdachte Prioritäts-Logik zwingt dich zu einer sauberen Hierarchie deines Shops und hilft bei Audits – und Yandex bzw. manche Crawler werten sie noch. Wenn du sie pflegst (oder dein Plugin sie ohnehin setzt), dann mit dieser bewährten E-Commerce-Staffelung:

Seitentyp	Empfohlene priority	changefreq (realistisch)
Startseite	1.0	daily / weekly
Hauptkategorien	0.9	weekly
Unterkategorien / Hersteller	0.7	weekly
Produkte	0.6	weekly / monthly
Blog-Beiträge	0.5	monthly
Service-/CMS-Seiten	0.3	yearly

Der häufigste Fehler – Blog über Kategorie – wird damit korrigiert: Umsatztragende Landingpages stehen über redaktionellem Content. Und changefreq bleibt ehrlich: Produkte ändern sich nicht stündlich, also auch nicht hourly.

Umsetzung in Shopware 6.7

Jetzt der praktische Teil. (Alle folgenden Service-Tags und Klassen gegen den Shopware-6.7.9-Core verifiziert.)

So baut Shopware die Sitemap

Jeder Seitentyp liefert seine URLs über einen UrlProvider, der von Shopware\Core\Content\Sitemap\Provider\AbstractUrlProvider erbt und am DI-Tag shopware.sitemap_url_provider registriert ist. Im Core sind das:

HomeUrlProvider
CategoryUrlProvider
ProductUrlProvider
LandingPageUrlProvider
CustomUrlProvider

Jeder Eintrag wird als Shopware\Core\Content\Sitemap\Struct\Url erzeugt – mit den Feldern loc, lastmod, changefreq, priority, resource, identifier.

Die Shopware-Defaults (das erklärt die Eingangs-Tabelle)

Der Url-Struct hat priority = 0.5 als Default. Product- und Category-Provider setzen priority nicht explizit → alles landet auf 0.5.
changefreq wird je Provider per Konstante gesetzt: Produkte hourly, Kategorien daily, Home daily (Home zusätzlich priority = 1.0).

Mit anderen Worten: Die „untypische“ Priorisierung aus dem Audit ist überwiegend der Shopware-Standard – plus ein Blog-Plugin, das seine Beiträge auf 1.0 setzt. Kein Drama (Google ignoriert es ja), aber unsauber.

Variante A: Provider dekorieren (sauberste Lösung)

Um priority/changefreq je Typ zu überschreiben, dekorierst du den jeweiligen Core-Provider:

<?php declare(strict_types=1);

namespace Great2gether\SeoTools\Sitemap;

use Shopware\Core\Content\Sitemap\Provider\AbstractUrlProvider;
use Shopware\Core\Content\Sitemap\Struct\UrlResult;
use Shopware\Core\System\SalesChannel\SalesChannelContext;

class ProductUrlProviderDecorator extends AbstractUrlProvider
{
    public function __construct(private readonly AbstractUrlProvider $decorated) {}

    public function getDecorated(): AbstractUrlProvider
    {
        return $this->decorated;
    }

    public function getName(): string
    {
        return $this->decorated->getName(); // 'product'
    }

    public function getUrls(SalesChannelContext $context, int $limit, ?int $offset = null): UrlResult
    {
        $result = $this->decorated->getUrls($context, $limit, $offset);
        foreach ($result->getUrls() as $url) {
            $url->setPriority(0.6);
            $url->setChangefreq('weekly');
        }
        return $result;
    }
}

Registrierung in der services.xml:

<service id="Great2gether\SeoTools\Sitemap\ProductUrlProviderDecorator"
         decorates="Shopware\Core\Content\Sitemap\Provider\ProductUrlProvider">
    <argument type="service"
              id="Great2gether\SeoTools\Sitemap\ProductUrlProviderDecorator.inner"/>
</service>

Das $limit/$offset-Paging unbedingt durchreichen – die Sitemap wird seitenweise erzeugt. Für Kategorien analog CategoryUrlProvider dekorieren (priority 0.9, changefreq weekly).

Variante B: Statische URLs ohne Code

Einzelne URLs lassen sich rein per Konfiguration ergänzen (verarbeitet vom CustomUrlProvider / shopware.sitemap.config_handler):

# config/packages/shopware.yaml
shopware:
    sitemap:
        custom_urls:
            - url: 'https://www.dein-shop.de/spezial-landingpage'
              lastMod: '2026-06-05 00:00:00'
              changeFreq: weekly
              priority: 0.8
              salesChannelId: 'deine-sales-channel-id'

URLs ausschließen (der eigentliche Fix)

Wichtiger als das Justieren von Prioritäten ist das Entfernen falscher URLs. Drei Wege:

Dreischild SEO Professional (sofern im Einsatz) bietet pro Produkt/Kategorie/Landingpage den Schalter „nicht in Sitemap anzeigen“ sowie ein Feld „Priorität in der Sitemap“ (0.0–1.0). Außerdem schließt das Plugin automatisch URLs aus, deren SEO-URL ≠ Canonical ist, die noindex tragen oder die zu category.type = folder gehören – genau die Hygiene-Regeln von oben.
Core-Konfiguration: shopware.sitemap.excluded_urls (URL-Ausschluss) und core.sitemap.excludeLinkedProducts.
robots.txt & Sitemap synchronisieren: Was per Disallow gesperrt ist, darf nicht in der Sitemap stehen. (Im Audit-Fall: /navigation/ aus der Sitemap entfernen.)

Generieren & einreichen

bin/console sitemap:generate

In Shopware ist die Refresh-Strategie (live vs. geplant per Scheduled Task) plus Cache-Dauer in den Sitemap-Einstellungen konfigurierbar. Eingereicht wird die Sitemap über die Sitemap:-Zeile in der robots.txt und zusätzlich in der Google Search Console – dort siehst du auch die Indexabdeckung pro Datei.

Sitemaps nach Typ aufteilen

Für größere Kataloge empfiehlt sich, die Sitemap nach Seitentyp zu splitten (Produkte / Kategorien / Blog / Bilder), gebündelt in einer Sitemap-Index-Datei. Vorteil ist die Diagnose: In der Search Console erkennst du dann „Kategorien zu 95 % indexiert, Produkte nur zu 70 %“ – statt eines globalen Mischwerts. Shopware nutzt ohnehin eine Sitemap-Index-Struktur. Harte Grenzen: 50.000 URLs bzw. 50 MB unkomprimiert pro Datei (gzip erlaubt, hebt das Limit aber nicht auf).

Realitäts-Check: Crawl-Budget

Ein häufiges Gegenargument lautet: „Aber die Prioritäten steuern doch das Crawl-Budget!“ Tun sie nicht. Und für die meisten Shops ist Crawl-Budget ohnehin kein Thema. Google selbst sagt, der Crawl-Budget-Leitfaden sei für Sites mit 1 Mio.+ Seiten oder sehr großen, täglich aktualisierten Katalogen relevant. Ein Shop mit ein paar tausend URLs wird in der Regel am selben Tag gecrawlt.

Die Hebel, die das Crawling wirklich beeinflussen: schnelle Serverantwort, saubere Sitemaps mit ehrlichem lastmod, Entfernen von Duplikaten/Low-Value-URLs und gute interne Verlinkung. Nicht priority.

Praxis-Checkliste

priority/changefreq nicht überoptimieren – Google & Bing ignorieren sie. Wenn dein Setup sie sauber setzt: gut, aber investiere keine Stunden hinein.
lastmod ehrlich pflegen – nur bei echter Inhaltsänderung, ISO-8601-Format. Das ist der eigentliche Gewinn.
Sitemap-Hygiene herstellen – nur kanonische, indexierbare 200er-URLs. Raus mit robots-gesperrten, noindex-, 3xx- und 404-URLs.
robots.txt ↔ Sitemap abgleichen – keine gesperrten Pfade in der Sitemap.
Falls priority gepflegt wird: Money-Pages (Kategorien/Hersteller) über Blog. Blog ≠ 1.0.
Nach Typ splitten – für saubere GSC-Diagnose.
Generieren, einreichen, überwachen – sitemap:generate, robots.txt + GSC, Coverage prüfen.

Fazit

Sitemap-„Prioritäten“ sind das vielleicht überschätzteste Detail im technischen SEO. Google und Bing ignorieren priority und changefreq – belegbar und seit Jahren. Wer hier optimiert, poliert ein Signal, das niemand liest. Die Energie gehört in das, was Suchmaschinen tatsächlich auswerten: eine saubere, kanonische URL-Liste und ein ehrliches lastmod. In Shopware 6.7 ist beides mit überschaubarem Aufwand machbar – per Provider-Dekoration, Konfiguration und konsequenter Sitemap-Hygiene.

Anders gesagt: Nicht welche Zahl an der URL steht, entscheidet – sondern welche URL überhaupt drinsteht.

Quellen

Shopware-Service-Tags und Provider gegen Shopware 6.7.9.0 verifiziert. priority/changefreq-Defaults aus dem Core-Quellcode (trunk) abgeleitet.

Sitemap-Prioritäten in Shopware 6: Was wirklich zählt – und was ein Mythos ist