Ein Kunde kam 2022 Anfang zu mir -- mittleres Mode-Unternehmen, etwa 40.000 organische Sessions monatlich, anständige Domain Rating, vier Jahre auf Shopify. Sie hatten eine Dev-Agentur angeheuert, um alles auf Next.js mit Shopifys Storefront API neu zu bauen. Die neue Seite war atemberaubend. Wirklich schnell. Und innerhalb von sechs Wochen nach dem Go-Live hatten sie 38% ihres organischen Traffic verloren.
Wichtigste Erkenntnis: Headless-Shopify-Migrationen schützen Rankings genauso wie jede Migration es tut: vollständige Redirect-Map, byte-identischer Metadaten-Transport und ein Core Web Vitals Budget für den neuen Build.Headless Shopify migrations protect rankings the same way every migration does: full redirect map, byte-identical metadata transport, and a Core Web Vitals budget on the new build.
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 Moves, die wie ein reiner technischer Gewinn aussehen -- schnelleres Rendering, entkoppeltes Front-End, totale Designfreiheit -- aber wenn du SEO als Nachgedanken behandelst, wirst du dafür bezahlen. Und wie. Ich habe bei Seahawk an 12.000+ Sites gearbeitet und dieses Muster habe ich oft genug wiederholt gesehen, dass ich es mir zur Aufgabe gemacht habe, alles ordnungsgemäß aufzuschreiben.look like a pure technical win -- faster rendering, decoupled front-end, total design freedom -- but if you treat SEO as an afterthought, you'll pay for it. Badly. I've worked on 12,000+ sites at Seahawk and I've seen this pattern repeat itself enough times that I wanted to write it all down properly.
---
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./sitemap.xml is maintained automatically. Structured data for products comes baked in via Liquid. Pagination uses rel="next" and rel="prev" conventions that Shopify manages quietly in the background.
In dem Moment, in dem du Headless gehst -- normalerweise mit einem Framework wie Next.js, Nuxt, Remix oder SvelteKit, das Daten aus der Shopify Storefront API zieht -- besitzt du das alles. Jeden Canonical. Jedes hreflang. Jeden Structured Data Block. Jeden Redirect. Es kommt nicht mehr kostenlos.Next.js, Nuxt, Remix, or SvelteKit pulling data from the Shopify Storefront API -- you own all of that. Every canonical. Every hreflang. Every structured data block. Every redirect. It doesn't come for free anymore.
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. The dev team builds on
staging.mybrand.comor a Vercel preview URL, forgets tonoindexit properly, Google crawls it, and suddenly you have duplicate content competing with your live site. - 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. Headless projects almost always involve URL changes.
/collections/mens-shirtsbecomes/category/shirtsor something worse. Without 301s in place, every inbound link and every Google-indexed URL returns a 404. - 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. If your headless front-end is rendering product content purely client-side without SSR or SSG, Googlebot may not be picking up your content reliably. Google can render JavaScript, but it's processed in a second wave and there's indexing lag. For large catalogues, that lag costs you.
---
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 existierenden Shopify-Site. Nutze Screaming Frog (ich führe es hier lokal in London auf einer dedizierten Maschine aus -- kein Cloud-Crawl, lokal, damit ich alles fangen kann, inklusive JavaScript-gerenderte Seiten). Exportiere jede URL, jeden Status-Code, jedes Title-Tag, jede Meta-Description, jeden Canonical und jedes H1. Das ist deine Baseline. Das ist dein Vorher-Foto. Use Screaming Frog (I run it locally here in London on a dedicated machine -- not cloud crawl, local, so I can catch everything including JavaScript-rendered pages). Export every URL, status code, title tag, meta description, canonical, and H1. This is your baseline. It's your before-photo.
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. Every old URL → new URL. Not just category and product pages. Blog posts. Tag pages. Size guide pages. The /pages/about URL that has 47 backlinks from that press mention in 2020. Every URL that has crawl history, backlinks, or ranking keywords needs to be in this spreadsheet.
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. Filter to pages with at least one referring domain. These are your highest-priority redirect targets. Miss a 301 on a page with 12 referring domains and you've just deleted a meaningful chunk of link equity.
4. Keyword-Ranking-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. Wenn „mens linen trousers" nach dem Go-Live von Position 4 auf Position 22 fällt, musst du das sofort erkennen können. Export your current rankings from Google Search Console -- at minimum, the top 200 queries by click volume. You need this so you can compare pre- and post-migration. If "mens linen trousers" drops from position 4 to position 22 after go-live, you need to be able to spot that immediately.
---
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 verwaltet dein Front-End-Framework das Routing -- was bedeutet, dass Redirects irgendwo anders leben, je nachdem, wo du bereitstellst.
Wenn du auf Vercel bist (wo die meisten Next.js Headless-Shopify-Projekte landen), gehen deine Redirects in vercel.json unter das redirects-Array. Es handhabt 301er sauber und Verels Edge-Netzwerk wendet sie an, bevor die Seite überhaupt rendert, was exakt das ist, was du für SEO brauchst -- der Redirect passiert auf der Infrastruktur-Ebene, nicht in JavaScript.vercel.json under the redirects array. It handles 301s cleanly and Vercel's edge network applies them before the page even renders, which is exactly what you want for SEO -- the redirect happens at the infrastructure layer, not in JavaScript.
Falls du auf Netlify bist, gleiche Idee -- netlify.toml oder eine _redirects Datei.Netlify, same idea -- netlify.toml or a _redirects file.
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.httpstatus.io to verify the chain. A 301 → 301 → 200 chain is bad. You want 301 → 200. Redirect chains bleed link equity and slow things down.
---
Canonicals, Structured Data und die Details, die Teams vergessen
2023 hat Seahawk eine DTC Skincare-Marke zu einem Headless Hydrogen Setup migriert (Shopifys eigenes React Framework). Die Entwickler hatten die Redirects ordentlich hinbekommen. Aber sie haben übersehen, dass Hydrogen canonical Tags nicht automatisch generiert -- du musst sie manuell im <head> mit Hydrogens SEO Component setzen. Das Ergebnis: jede Produktseite kanonisierte sich selbst mit den Query String Parametern angehängt, weil die Cart und Filter Logik Parameter in die URL geschrieben hat. Google sah hunderte von nahezu identischen Produktseiten.<head> using Hydrogen's SEO component. Result: every product page was canonicalising to itself with the query string parameters appended, because the cart and filter logic was writing params into the URL. Google was seeing hundreds of near-duplicate product pages.
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 ist auf deiner Staging Umgebung und allen Vercel/Netlify Preview URLs -- add das zu deiner Deployment Checkliste, nicht zu deiner To-Do Liste.is on your staging environment and any Vercel/Netlify preview URLs -- add this to your deployment checklist, not your to-do list.- Strukturierte Produktdaten (Schema.org-Produkttyp) werden serverseitig im <head> gerendert, nicht von einem clientseitigen Skript nach der Hydration injiziert.Schema.org
Producttype) is being server-rendered in the<head>, not injected by a client-side script after hydration. - Deine robots.txt ist unter der Root-Domain erreichbar und blockiert Googlebot nicht von deinen neuen URL-Mustern.
robots.txtis reachable at the root domain and isn't blocking Googlebot from your new URL patterns. - Die XML Sitemap spiegelt die neue URL Struktur wider -- nicht die alte Shopify Sitemap und nicht eine gecachete Version aus deinem Build Process.
---
Core Web Vitals: Das zweischneidige Schwert
Hier ist das Argument, das die meisten Agenturen machen, wenn sie Headless verkaufen: "Das verbessert deine Core Web Vitals." Und sie haben nicht unrecht -- potenziell. Ein gut gebautes Next.js Frontend mit Image Optimisation, Edge Caching und korrektem Code Splitting kann wirklich grün über alle drei Core Web Vitals Metriken hinweg treffen.potentially. A well-built Next.js front-end with image optimisation, edge caching, and proper code splitting can genuinely hit green across all three Core Web Vitals metrics.
Aber ich habe Headless-Migrationen gesehen, die die CWV verschlechtert haben. Speziell LCP (Largest Contentful Paint) und CLS (Cumulative Layout Shift).worse. Specifically LCP (Largest Contentful Paint) and CLS (Cumulative Layout Shift).
LCP wird schlechter, wenn das Hero Image oder das Above-the-Fold Produktimage nicht richtig preloaded 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 korrekt skalierte Images über ein CDN wie Cloudflare oder Fastly auslieferst.priority flags on hero images (in Next.js, that's the priority prop on <Image>) and that you're serving correctly sized images via a CDN like Cloudflare or Fastly.
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 Data aus Chrome UX Report, wenn die Site lange genug in Staging war, um Daten zu sammeln. Und check auf Mobile -- das sind die Daten, die Google tatsächlich für Ranking nutzt.PageSpeed Insights on your staging URL before go-live, not after. Use field data from Chrome UX Report if the site has been in staging long enough to accumulate it. And check on mobile -- that's the data Google actually uses for ranking.
---
Crawl Budget und große Kataloge
Falls du weniger als 5.000 Product URLs hast, ist Crawl Budget wahrscheinlich nicht dein Hauptproblem. Aber wenn du einen Katalog mit 50.000+ SKUs, Faceted Navigation, mehreren Currency/Region Varianten und einem Blog zurück bis 2015 migrierst -- musst du darüber nachdenken.
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.more URLs than the Shopify setup they're replacing. Faceted filters that were previously handled via AJAX with noindex in Shopify now get their own server-rendered routes if someone hasn't thought carefully about URL parameter handling. Suddenly Googlebot is trying to crawl a 200,000-URL site when you had 30,000 before.
Halte deine robots.txt eng. Disallow das Crawlen von gefilterten URL Patterns, die keinen einzigartigen, rankbaren Content darstellen. Nutze rel="canonical" auf gefilterten Seiten, um zurück zur Root Kategorie zu zeigen. Und erstelle keine individuellen Server-Side Routes für jede Facet Kombination -- das führt zu Wahnsinn und Crawl Verschwendung.robots.txt tight. Disallow crawling of filtered URL patterns that don't represent unique, rankable content. Use rel="canonical" on filtered pages to point back to the root category. And don't create individual server-side routes for every facet combination -- that way lies madness and crawl waste.
---
Ü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 Data für mindestens die ersten drei Monate auf. Track Impressions, Clicks, Durchschnittliche Position und Index Coverage. Beobachte Index Drops -- wenn deine indexierte Seitenanzahl plötzlich von 8.000 auf 4.200 fällt, stimmt etwas nicht und du musst es finden, bevor Google entscheidet, dass diese Seiten für immer weg sind.
Ich habe auch einen Uptime-Monitor (ich nutze Better Uptime) auf der Sitemap-URL selbst eingerichtet -- yourdomain.com/sitemap.xml. Falls sie während eines Deployments anfängt, einen 500er zurückzugeben, willst du das sofort wissen, nicht erst drei Tage später, wenn du merkst, dass die Rankings sinken.yourdomain.com/sitemap.xml. If it starts returning a 500 during a deployment, you want to know immediately, not three days later when you notice rankings sliding.
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 es gibt fast immer etwas Ranking-Volatilität in den ersten vier bis acht Wochen, während Google das neue Setup neu crawlt und neu indexiert. Wenn deine Weiterleitungen solide sind, deine Canonicals korrekt sind und deine strukturierten Daten intakt sind, stabilisiert sich das typischerweise wieder und verbessert sich oft. Die Gefahr liegt darin, wenn Migrationen gehetzt werden -- dann wird kurzfristige Volatilität zu langfristigem 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 im Detail -- Canonical-Management, Sitemap-Generierung und strukturierte Daten. Shopify bietet ein SEO-Utility in der Component Library von Hydrogen an, aber es ist kein Wundermittel. Du brauchst immer noch jemanden, der versteht, was es macht 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.noindex on your entire domain can take two to four months to recover from, sometimes longer for highly competitive terms. The sooner you catch and fix it, the shorter the recovery.
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 richtig migrierst. Lass dich von einer Agentur nicht mit SEO-Vorteilen zum Headless-Ansatz überreden -- 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.if you migrate correctly. Don't let an agency sell you headless by leading with SEO benefits -- the same performance gains can often be achieved with a well-optimised Shopify 2.0 theme and a solid CDN setup, at a fraction of the cost.
---
Migrationen sind keine Launches. Sie sind Vertrauensübertragungen -- von einer alten Umgebung, die Google gut kennt, zu einer, die es nicht kennt. Behandle jedes technische Detail so, als würde es zählen, denn für deinen organischen Channel tut es das.