SEO im Headless-Shopware-Frontend: Metadata, Canonicals & strukturierte Daten mit Next.js
In der Standard-Storefront ist SEO weitgehend gelöst: Shopware erzeugt sprechende URLs, füllt Meta-Tags, rendert Canonical-Links und strukturierte Daten. Sobald das Frontend auf Next.js läuft, fällt dieser komplette Apparat weg — und viele merken das erst, wenn Google nach dem Relaunch weniger indexiert als vorher. Headless ist ein SEO-Gewinn, wenn man die Arbeit macht, und ein SEO-Risiko, wenn man annimmt, sie passiere von selbst. Was du im Next.js-Frontend selbst bauen musst und wo die Fallstricke liegen.
1. Warum Headless-SEO nicht „von selbst" funktioniert
Die klassische Storefront rendert im Twig-Layer alles, was Suchmaschinen brauchen — Titel, Meta-Description, Canonical, hreflang, Open-Graph und JSON-LD stecken in den Standard-Templates. Bei einem entkoppelten Setup liefert Shopware nur noch Daten über die Store API; das HTML samt aller SEO-Signale entsteht im Frontend. Damit wandert die Verantwortung für jeden einzelnen Meta-Tag zu dir. Das ist kein Nachteil — Next.js hat mit der Metadata API ein sauberes, typisiertes Werkzeug dafür. Aber es ist Arbeit, die aktiv passieren muss. Der häufigste Fehler ist nicht ein falscher Tag, sondern ein fehlender: Produktseiten, die stumm den Layout-Default-Titel erben, weil niemand die Metadaten pro Seite befüllt hat.
2. Die versteckte Falle: keine SEO-URLs für API-Verkaufskanäle
Bevor es um Meta-Tags geht, kommt die URL — und hier lauert der erste Stolperstein. Seit Shopware 6.6 werden für Verkaufskanäle vom Typ „API" gar keine SEO-URLs mehr generiert. Die Begründung ist plausibel — dein Frontend bestimmt seine URL-Struktur selbst, Shopware soll keine ungenutzten Datensätze produzieren. In der Praxis heißt das aber: Wenn dein Frontend an einem reinen API-Kanal hängt, sind die sprechenden Pfade nicht da, wo du sie vielleicht erwartest. Zwei Wege sind gangbar: Entweder du legst einen Storefront-Verkaufskanal parallel an, dessen seoUrls du über die Store API ausliest und im Frontend spiegelst, oder du baust die URL-Logik komplett selbst und nutzt Shopware nur als Datenquelle. Wichtig ist, das bewusst zu entscheiden — die SEO-URL-Templates in den Einstellungen greifen sonst ins Leere.
3. generateMetadata: Titel, Description und Canonical pro Route
Der zentrale Baustein ist generateMetadata in jeder dynamischen Route — also in der page.tsx für Produkt, Kategorie und Landingpage. Die Funktion bekommt die params, lädt über die Store API das Produkt und leitet daraus Titel, Description und Canonical ab. Entscheidend: Der Canonical wird aus dem aufgelösten Slug gebildet, nicht hart verdrahtet — jede Seite zeigt auf sich selbst. Shopware liefert dafür bereits passende Felder: metaTitle, metaDescription und keywords am Produkt. Sind sie leer, fällt man sinnvoll zurück — Produktname plus Herstellername als Titel, die ersten ~155 Zeichen der Beschreibung als Description. Über das alternates.canonical-Feld setzt du den kanonischen Link, über openGraph die Vorschau für Social-Previews. So bekommt jede der potenziell tausenden Produktseiten ihren eigenen, korrekten Head — der Punkt, an dem sich Headless-SEO entscheidet.
4. Canonical & hreflang für mehrsprachige Kataloge
Sobald der Shop mehrere Sprachen fährt, reicht der Self-Canonical nicht mehr. Google muss wissen, welche URL welche Sprachversion bedient — das leistet hreflang, in der App-Router-Welt über alternates.languages. In generateMetadata gibst du für jede Sprache die URL an, plus ein x-default für Nutzer, deren Sprache zu keiner Version passt. Die eiserne Regel: Der Canonical jeder Sprachversion zeigt auf sich selbst, niemals auf eine andere Sprache. Canonicalisierst du die deutsche Produktseite versehentlich auf die englische, sagst du Google damit, die deutsche Seite fallenzulassen — ein Fehler, der still ganze Sprachbäume aus dem Index kippt. Die Store API liefert die sprachspezifischen Daten über den sw-language-id-Header; die passende Sprach-ID pro Locale kennst du aus deiner Routing-Schicht — dieselbe, die schon den Context-Token je Kanal verwaltet.
5. Strukturierte Daten aus Store-API-Feldern
Rich Results — Preis, Verfügbarkeit, Bewertungssterne direkt im Suchergebnis — entstehen über schema.org/Product-Markup. In der Standard-Storefront rendert Shopware das mit; headless baust du es aus denselben Store-API-Feldern selbst. Ein Product-Objekt mit name, image, sku und einem verschachtelten offers-Block (Preis, Währung, availability aus dem Lagerstatus) deckt den Kern ab. Dazu gehört ein BreadcrumbList-Schema aus dem Kategoriepfad. Zwei Dinge sind kritisch: Erstens muss der ausgezeichnete Preis dem sichtbaren Preis entsprechen — bei erweiterten Preisen steht der echte Wert in calculatedPrices, nicht immer im simplen calculatedPrice. Zweitens: Erfinde keine Felder — ein Nutri-Score oder eine Bewertung, die nur der Plugin-Default ist, darf nicht ins Markup, sonst produzierst du unbelegte Auszeichnungen. Wie du Rich Snippets speziell für FAQ-Inhalte nutzt, steht im Beitrag zu FAQ Rich Snippets.
6. sitemap.ts, robots.ts — und der stille Killer im try/catch
Damit Crawler den Katalog überhaupt vollständig finden, braucht es eine dynamische Sitemap. Next.js bietet dafür die Datei-Konvention sitemap.ts: Eine Default-Funktion mit Rückgabetyp MetadataRoute.Sitemap lädt alle Produkt- und Kategorie-Slugs aus der Store API und liefert sie mit lastModified aus — bei großen Katalogen über eine Sitemap-Index-Struktur. Dazu die robots.ts, die die Sitemap-URL bekanntgibt und Warenkorb-, Konto- und Checkout-Pfade sperrt. Der teuerste Fehler wartet aber in generateMetadata selbst: Umschließt du den Store-API-Aufruf mit einem try/catch, das im Fehlerfall ein leeres {} zurückgibt, verschluckst du still jede API-Inkompatibilität. Ich habe genau das erlebt: Eine Route rief den Produkt-Endpunkt per GET auf, der in Shopware 6.6 aber nur POST unterstützte — Antwort 405, der Catch griff, und jede der 764 Produktseiten erbte lautlos den Layout-Default-Titel, ohne Description, Canonical oder OG-Bild. Kein Fehler im Log, die Seite lud mit Status 200. Lehre: Metadaten einer Unterseite nach jedem Deploy aktiv gegenprüfen — <title>, Canonical und OG-Image im ausgelieferten HTML —, nicht nur schauen, ob die Seite rendert.
7. Fazit: SEO ist im Headless-Setup ein Feature, kein Nebenprodukt
Der Wechsel auf ein Next.js-Frontend nimmt dir nicht das SEO weg — er macht es zu einer bewussten Aufgabe. Sprechende URLs, Metadaten pro Route, self-canonical plus hreflang, strukturierte Daten aus echten Feldern, Sitemap und Robots: Das ist keine Raketentechnik, aber es muss jemand tun, und zwar vollständig. Wer nach dem Relaunch nur prüft, ob die Seiten laden, übersieht die stillen Ausfälle — verschluckte Fehler, fehlende Canonicals, ausgelassene Sprachversionen. Die gute Nachricht: Einmal sauber aufgesetzt, ist Headless-SEO oft präziser als das der Storefront, weil du jeden Tag exakt kontrollierst. Der Schlüssel ist, es als Teil der Frontend-Architektur zu behandeln, nicht als Kosmetik danach — und nach jedem Deploy den Head einer echten Produktseite zu kontrollieren, bevor es der Google-Bot tut.
Verliert dein Headless-Shop nach dem Relaunch Sichtbarkeit?
Lass uns in 30 Minuten den Head deiner Produktseiten durchgehen — Canonical, hreflang, strukturierte Daten und die stillen Ausfälle, die kein Log meldet. Kein Sales-Call.