Ein Kunde kam 2022 Anfang zu mir, mittlere Modemarke, etwa 40.000 organische Sessions monatlich, ordentliches Domain Rating, vier Jahre auf Shopify. Sie hatten eine Dev-Agentur engagiert, um alles auf Next.js mit Shopifys Storefront API neu aufzubauen. Die neue Website war wunderschön. Wirklich schnell. Und innerhalb von sechs Wochen nach dem Launch hatten sie 38 % ihres organischen Traffics verloren.
Wichtigste Erkenntnis: Bei Headless-Shopify-Migrationen gelten die gleichen Regeln wie bei jeder anderen Migration. Man braucht eine vollständige Redirect-Map, muss die Metadaten exakt übertragen und sollte die Core Web Vitals im Blick behalten. Beim neuen Build wird's eng.
Niemand hatte ein Redirect-Audit gemacht. Die Sitemap war kaputt. Canonical Tags zeigten auf die falsche Umgebung. Es war ein Desaster, und es kostete sie etwa £60.000 an Umsatz, bevor wir die Dinge stabilisiert haben.
Headless-Migrationen sind eine dieser Maßnahmen, die wie ein reiner technischer Sieg aussehen – schnelleres Rendering, entkoppeltes Front-End, totale Gestaltungsfreiheit –, aber wenn du SEO als Nebensache behandelst, zahlst du dafür. Teuer. Ich habe bei Seahawk an über 12.000 Websites gearbeitet und dieses Muster so oft gesehen, dass ich es mir aufgeschrieben habe.
---
Warum Headless Shopify SEO überhaupt erst zerstört
Die Standard-Theme-Architektur von Shopify erledigt viel SEO-Arbeit im Hintergrund, ohne dass du es merkst. Canonical Tags werden automatisch generiert. Die sitemap.xml unter /sitemap.xml wird automatisch gepflegt. Strukturierte Daten für Produkte sind über Liquid bereits eingebaut. Paginierung nutzt die rel="next"- und rel="prev"-Konventionen, die Shopify stillschweigend im Hintergrund verwaltet.
Sobald du Headless gehst, typischerweise mit einem Framework wie Next.js, Nuxt, Remix oder SvelteKit, das Daten von der Shopify Storefront API zieht, trägst du die Verantwortung dafür. Jedes Canonical. Jedes Hreflang. Jeder strukturierte Datenblock. Jeder Redirect. Das kommt nicht mehr kostenlos.
Und hier ist der Punkt: Die meisten Dev Teams werden eingestellt, weil sie gut in React sind. Nicht, weil sie wissen, wie eine Crawl Trap bei facettierter Navigation aussieht.
Die drei Fehler, die ich ständig sehe
- URLs der Staging-Umgebung landen im Production Index. Das Dev Team baut auf staging.mybrand.com oder einer Vercel Preview URL, vergisst das noindex Tag richtig zu setzen, Google crawlt sie, und plötzlich hast du Duplicate Content, der mit deiner Live-Site konkurriert.
- Fehlerhafte oder fehlende Redirects bei URL-Umstrukturierungen. Headless-Projekte beinhalten fast immer URL-Änderungen. /collections/mens-shirts wird zu /category/shirts oder schlimmer. Ohne 301er an Ort und Stelle, gibt jeder eingehende Link und jede von Google indexierte URL einen 404 zurück.
- Client-seitiges Rendering tötet die Crawlbarkeit. Wenn dein Headless-Frontend Produktinhalte rein client-seitig ohne SSR oder SSG rendert, erfasst Googlebot deine Inhalte möglicherweise nicht zuverlässig. Google kann JavaScript rendern, aber das wird in einer zweiten Welle verarbeitet und es gibt einen Indexierungsverzug. Bei großen Katalogen kostet dich dieser Verzug.
---
Das Pre-Migration-Audit, das du nicht überspringen darfst
Ich bin ehrlich: Wenn du das nicht gemacht hast, bevor es live ging, bist du bereits hinten dran. Aber es ist nie zu spät.
Bevor sich auch nur ein DNS-Record ändert, möchte ich vier Dinge in der Hand haben.
1. Ein vollständiger Crawl der bestehenden Shopify-Website. Nutze Screaming Frog (ich fahre es hier in London lokal auf einer dedizierten Maschine, kein Cloud Crawl, lokal, damit ich alles erfasse, einschließlich JavaScript-gerenderter Seiten). Exportiere jede URL, jeden Statuscode, Title Tag, Meta Description, Canonical und H1. Das ist deine Baseline. Das ist dein Vorher-Foto.
2. Ein Mapping-Dokument. Jede alte URL → neue URL. Nicht nur Category- und Product-Pages. Blog-Posts. Tag-Pages. Size-Guide-Pages. Die /pages/about-URL, die 47 Backlinks von dieser Press-Erwähnung 2020 hat. Jede URL, die Crawl-History, Backlinks oder Ranking-Keywords hat, muss in dieser Tabelle stehen.
3. Ein Backlink-Export aus Ahrefs oder SEMrush. Filtere auf Pages mit mindestens einer verweisenden Domain. Das sind deine höchstpriorisierten Redirect-Ziele. Verpasst du einen 301 auf einer Page mit 12 verweisenden Domains, hast du gerade eine bedeutende Menge Link Equity gelöscht.
4. Keyword-Rankings-Snapshot. Exportiere deine aktuellen Rankings aus Google Search Console, mindestens die Top 200 Queries nach Click-Volumen. Du brauchst das, um Pre- und Post-Migration zu vergleichen. Falls „mens linen trousers" von Position 4 auf Position 22 nach dem Launch fällt, musst du das sofort erkennen können.
---
Redirects in einem Headless-Setup implementieren
Hier wird es ein bisschen technisch, bleib aber dabei.
In einem Standard-Shopify-Setup verwaltest du Redirects im Shopify Admin. In einem Headless-Setup handhabt dein Front-End-Framework das Routing, was bedeutet, dass Redirects je nach deinem Deployment-Ziel woanders sind.
Wenn du auf Vercel bist (wo die meisten Next.js Headless-Shopify-Projekte landen), gehen deine Redirects in die vercel.json unter das Redirects-Array. Es handhabt 301er sauber und Vercels Edge Network wendet sie an, bevor die Seite überhaupt rendert – genau das, was du für SEO brauchst, der Redirect passiert auf der Infrastruktur-Ebene, nicht in JavaScript.
Wenn du auf Netlify bist, gleiches Prinzip, netlify.toml oder eine _redirects-Datei.
Wenn du selbst auf etwas wie AWS CloudFront oder einen custom Node Server hostst, musst du Redirects auf der Reverse-Proxy-Ebene implementieren. Nicht im React Router. Edge-Level-Redirects sind es, die Link Equity sauber weitergeben.
Eine Sache, die ich immer mache: Nach jeder implementierten Weiterleitung führe ich einen Batch-Check durch httpstatus.io durch, um die Kette zu verifizieren. Eine 301 → 301 → 200 Kette ist schlecht. Du willst 301 → 200. Redirect-Ketten verursachen Link-Equity-Verluste und verlangsamen die Dinge.
---
Canonicals, Structured Data und die Details, die Teams vergessen
Im Jahr 2023 hatte Seahawk eine DTC-Skincare-Marke zu einem Headless-Hydrogen-Setup migriert (Shopifys eigenes React-Framework). Die Entwickler hatten die Weiterleitungen ordentlich gelöst. Aber sie hatten übersehen, dass Hydrogen keine Canonical-Tags automatisch generiert – man muss sie manuell im <head> mit Hydrogens SEO-Komponente setzen. Resultat: jede Produktseite kanonisierte sich selbst mit den Query-String-Parametern im URL, weil die Cart- und Filter-Logik Parameter in die URL schrieb. Google sah hunderte von quasi-doppelten Produktseiten.
Der Fix dauerte etwa einen Tag, nachdem wir es gefunden hatten, aber die Ranking-Volatilität, die er verursachte, brauchte etwa drei Wochen zum Stabilisieren.
Was du vor dem Launch manuell überprüfen solltest
- Canonical-Tags auf Produktseiten zeigen auf die saubere URL (keine Query Strings, keine UTM-Parameter).
- noindex gehört auf deine Staging-Umgebung und alle Vercel/Netlify-Preview-URLs, füg das zu deiner Deployment-Checkliste hinzu, nicht auf deine To-Do-Liste.
- Strukturierte Produktdaten (Schema.org-Produkttyp) werden serverseitig im <head> gerendert, nicht von einem clientseitigen Skript nach der Hydration injiziert.
- Deine robots.txt ist unter der Root-Domain erreichbar und blockiert Googlebot nicht von deinen neuen URL-Mustern.
- Die XML-Sitemap spiegelt die neue URL-Struktur wider, nicht die alte Shopify-Sitemap und nicht eine gecachte Version aus deinem Build-Prozess.
---
Core Web Vitals: Das zweischneidige Schwert
Das ist das Argument, das du von den meisten Agenturen hörst, wenn sie Headless anpreisen: „Deine Core Web Vitals werden besser." Und ehrlich gesagt, da haben sie nicht ganz unrecht. Ein sauber gebautes Next.js-Frontend mit Image-Optimierung, Edge-Caching und richtigem Code-Splitting schafft tatsächlich durchweg grüne Werte. Bei allen drei Metriken.
Aber ich habe Headless-Migrationen gesehen, die die CWV verschlechtert haben. Speziell LCP (Largest Contentful Paint) und CLS (Cumulative Layout Shift).
LCP wird schlechter, wenn das Hero-Image oder das above-the-fold-Produktbild nicht richtig vorgeladen wird. In einem Headless-Setup ist deine Image-Pipeline deine eigene Verantwortung. Du verlässt dich nicht mehr auf Shopifys CDN, du musst sicherstellen, dass dein Framework Priority-Flags auf Hero-Images nutzt (in Next.js ist das das priority-Prop auf <Image>) und dass du richtig skalierte Images über ein CDN wie Cloudflare oder Fastly auslieferst.
CLS wird schlechter, wenn Schriftarten oder dynamische Inhalte (besonders der Warenkorb-Drawer-Zustand, Werbebanners oder Filter-Chips) während der Hydration Layout-Verschiebungen verursachen. Shopify-Themes handhaben das außerhalb der Box angemessen. Dein benutzerdefiniertes Headless-Frontend wird das nicht tun, es sei denn, jemand hat es speziell dafür designed.
Test mit PageSpeed Insights auf deiner Staging-URL vor dem Go-Live, nicht danach. Nutze Field-Daten aus dem Chrome UX Report, wenn die Site lange genug in Staging war, um Daten zu sammeln. Und check auf Mobile, das ist die Daten, die Google zum Ranking nutzt.
---
Crawl Budget und große Kataloge
Wenn du weniger als 5.000 Produkt-URLs hast, ist Crawl-Budget wahrscheinlich nicht dein Hauptanliegen. Aber wenn du einen Katalog mit 50.000+ SKUs migrierst, facettierte Navigation, mehrere Währungs-/Regionalvarianten und einen Blog aus dem Jahr 2015, musst du dich damit auseinandersetzen.
Headless-Setups erzeugen oft mehr URLs als das Shopify-Setup, das sie ersetzen. Facettierte Filter, die vorher in Shopify über AJAX mit noindex gelöst wurden, bekommen jetzt eigene serverseitig gerenderte Routes, wenn niemand sich Gedanken über URL-Parameter gemacht hat. Plötzlich versucht Googlebot, eine 200.000-URL-Site zu crawlen, obwohl du vorher 30.000 hattest.
Halte deine robots.txt stramm. Unterbinde das Crawlen von gefilterten URL-Mustern, die keinen einzigartigen, rankbaren Content darstellen. Nutze rel="canonical" auf gefilterten Seiten, um zurück zur Root-Kategorie zu verweisen. Und erstelle nicht für jede Facetten-Kombination eigene Server-Side-Routes, das führt zu Chaos und Crawl-Verschwendung.
---
Überwachung nach der Migration (Der Teil, den Leute nach Woche zwei vergessen)
Die Migration geht live, der Client gibt grünes Licht, alle feiern. Und dann schaut keiner für einen Monat in die Search Console. Mach das nicht.
Richte einen wöchentlichen Export von GSC-Daten für mindestens die ersten drei Monate ein. Track Impressionen, Klicks, durchschnittliche Position und Index-Coverage. Achte auf Index-Drops – wenn deine indexierte Seiten-Anzahl plötzlich von 8.000 auf 4.200 fällt, stimmt etwas nicht und du musst es finden, bevor Google diese Seiten für verloren erklärt.
Ich habe auch einen Uptime-Monitor (ich nutze Better Uptime) auf die Sitemap-URL selbst eingerichtet, yourdomain.com/sitemap.xml. Wenn sie während eines Deployments einen 500er zurückgibt, willst du das sofort wissen, nicht drei Tage später, wenn du merkst, dass die Rankings sinken.
Noch eine Sache: Reichen Sie Ihre Sitemap nach dem Go-Live erneut in der Search Console ein. Vielleicht offensichtlich. Aber ich habe gesehen, dass das öfter vergessen wird, als mir lieb ist.
---
FAQ
Schadet Headless SEO immer zunächst?
Nicht immer, aber in den ersten vier bis acht Wochen gibt es fast immer eine gewisse Ranking-Volatilität, während Google die neue Struktur erneut crawlt und neu indexiert. Wenn deine Weiterleitungen solide sind, deine Canonicals korrekt sind und deine strukturierten Daten intakt sind, stabilisiert sich das normalerweise wieder und verbessert sich oft sogar. Die Gefahr liegt darin, wenn Migrationen überstürzt werden – dann verwandelt sich kurzfristige Volatilität in langfristigen Verlust.
Kann ich Shopifys Hydrogen-Framework verwenden und trotzdem gute SEO bewahren?
Ja. Hydrogen nutzt standardmäßig Server-Side Rendering, was die richtige Grundlage für SEO ist. Die Lücken liegen in den Details: Canonical-Management, Sitemap-Generierung und strukturierte Daten. Shopify stellt ein SEO-Utility in Hydrogens Component Library zur Verfügung, aber das ist keine Zauberformel. Du brauchst trotzdem jemanden, der versteht, was es tut und warum.
Wie lange dauert es, bis sich Rankings nach einem Migrationsproblem erholen?
Ehrlich? Das hängt vom Ausmaß ab. Eine fehlende Weiterleitung auf ein paar Seiten könnte sich selbst korrigieren, sobald Sie sie beheben. Ein siteweiter Canonical-Fehler oder ein versehentliches noindex auf Ihrer gesamten Domain kann zwei bis vier Monate oder länger dauern, um sich davon zu erholen, manchmal länger für hochkompetitive Begriffe. Je früher Sie es entdecken und beheben, desto kürzer die Erholung.
Lohnt sich Headless allein aus SEO-Perspektive?
Nein. Headless lohnt sich für Performance, Flexibilität und Developer Experience im Frontend. SEO ist ein neutraler Faktor, wenn du korrekt migrierst. Lass dich von einer Agentur nicht von SEO-Vorteilen beim Headless-Ansatz abspeisen – die gleichen Performance-Gewinne lassen sich oft mit einem gut optimierten Shopify 2.0 Theme und einem soliden CDN-Setup zu einem Bruchteil der Kosten erreichen.
---
Migrationen sind keine Launches. Sie sind Vertrauensübergaben von einer alten Umgebung, die Google gut kennt, zu einer neuen, die Google nicht kennt. Behandle jedes technische Detail so, als würde es zählen, denn für deinen organischen Kanal tut es das.