W ciągu ostatniego roku widziałem, jak trzy firmy migrowały do headless CMS. Dwie z nich straciły ponad 40% ruchu organicznego w ciągu kilku tygodni. Nie dlatego, że headless jest zły — tylko dlatego, że założyły, iż ich dotychczasowe ustawienia SEO „przejdą” same. Nie przejdą.
Pierwsza firma, średniej wielkości B2B SaaS, migrowała z WordPressa do Contentful + Next.js. Ich ruch się utrzymał, bo Next.js natywnie obsługuje renderowanie po stronie serwera. Metadane, mapy witryny i tagi kanoniczne — wszystko było uwzględnione w planie migracji. Przygotowali się z wyprzedzeniem.
Druga firma, marka e-commerce, przeszła z Shopify na Strapi + własny frontend oparty na React. Ruch spadł o 43% w trzy tygodnie. Problem? Czyste renderowanie po stronie klienta. Googlebot crawlował te strony, ale widział tylko puste szkielety HTML. Strony produktowe, kategorie i blog — wszystko było praktycznie niewidoczne dla wyszukiwarek aż do drugiej fali renderowania, która po stronie Google ma niższy priorytet, jeśli pierwszy odczyt nie zwraca nic użytecznego.
Trzecia firma, wydawca treści, migrowała z niestandardowego CMS-a w PHP do Sanity + Gatsby. Ruch spadł o 38%. Powód: zmienili całą strukturę URL bez wdrożenia przekierowań 301. Pięć lat budowania wartości linków przychodzących zniknęło z dnia na dzień.
Każdego z tych scenariuszy można było uniknąć. Oto lista kontrolna, która uratowałaby dwie z tych migracji.
Headless CMS oddziela zarządzanie treścią od warstwy prezentacji. Treścią zarządzasz w jednym systemie, a wyświetlasz ją przez osobny frontend — stronę internetową, aplikację mobilną albo dowolny inny kanał — przez API. „Głowa” (frontend) jest odłączona od „ciała” (treści).
Korzyści są jak najbardziej realne:
Pułapka polega na założeniu, że te korzyści dostajesz za darmo. W WordPressie albo Shopify podstawy SEO — metadane, mapy witryny, tagi kanoniczne i HTML renderowany po stronie serwera — są obsługiwane przez platformę. W architekturze headless każda z tych rzeczy staje się twoją odpowiedzialnością.
Kiedy oddzielasz treść od warstwy prezentacji, odcinasz SEO od automatycznych mechanizmów ochronnych, które wcześniej zapewniała platforma.
Ryzyko utraty pozycji. Google potrzebuje spójnych sygnałów do crawlowania, indeksowania i oceniania strony. Jeśli zaburzysz te sygnały podczas migracji, tracisz widoczność w wynikach wyszukiwania. Wspomniany wydawca treści stracił pozycje na 340 fraz w ciągu jednego tygodnia, bo struktura URL zmieniła się bez przekierowań.
Wpływ na ruch i przychód. Dla marki e-commerce spadek ruchu o 43% przełożył się na około 28 000 USD utraconego miesięcznego przychodu. Odzyskiwanie trwało dwa miesiące — i nigdy w pełni nie wrócili do poziomów sprzed migracji na stronach kategorii.
Ochrona lat pracy nad SEO. Backlinki, autorytet domeny, historia indeksacji — budowałeś ten fundament miesiącami albo latami. Niechlujna migracja potrafi to po prostu zaprzepaścić.
(Na marginesie: najbardziej zaskakuje mnie to, jak wiele planów migracji widziałem, w których SEO nie było wspomniane ani słowem. Zespół developerski skupia się na architekturze API. Zespół designu skupia się na nowym frontendzie. Nikt nie myśli o 47 000 organicznych wizyt miesięcznie, które w ogóle finansują ten projekt.)
To jest najważniejsza rzecz z całej listy. URL-e są punktami odniesienia zarówno dla wyszukiwarek, jak i użytkowników. Każda niepotrzebna zmiana powoduje 404, zepsute backlinki i spadki pozycji.
Podczas migracji współpracuj z zespołem developerskim tak, żeby odtworzyć obecną strukturę URL na nowym frontendzie headless. Jeśli zmiany są konieczne (na przykład przez nowy routing w headless CMS), ustaw przekierowania 301 dla każdego zmienionego URL. Bez wyjątków.
Tagi kanoniczne mówią wyszukiwarkom, która wersja strony jest wersją główną. Podczas migracji, szczególnie przy zmianach architektury, ta sama treść może zacząć być dostępna pod wieloma URL-ami. Bez tagów kanonicznych dostajesz zduplikowaną treść, która konkuruje sama ze sobą.
W headless CMS tagi kanoniczne często trzeba dodać ręcznie albo generować przez API. Przed migracją zrób audyt obecnej strony pod kątem podstron, które mogą powodować problemy ze zduplikowaną treścią. Po migracji sprawdź, czy tagi kanoniczne są ustawione na każdej stronie, używając Screaming Frog albo Google Search Console.
Zanim zaczniesz migrację, przygotuj szczegółową mapę przekierowań: stare URL-e do nowych URL-i, w relacji 1:1. Użyj środowiska stagingowego, żeby przetestować przekierowania przed wdrożeniem produkcyjnym.
W przeciwieństwie do WordPressa, który automatycznie generuje metadane, headless CMS wymaga wdrożenia tego samodzielnie przez wywołania API albo niestandardowy kod frontendu.
To właśnie zabiło ruch tej marki e-commerce. Jeśli mocno polegasz na JavaScript renderowanym po stronie klienta, wyszukiwarki mogą nie zobaczyć twojej treści przy pierwszym crawlowaniu.
Rozwiązanie: wdrożenie server-side rendering (SSR) albo static site generation (SSG). Next.js i Nuxt.js wspierają oba podejścia od ręki. W praktyce chodzi o to, żeby robot wyszukiwarki od razu dostał gotowy HTML z treścią, zamiast pustej strony, którą trzeba dopiero wyrenderować JavaScriptem po stronie przeglądarki. To prostsze, bardziej przewidywalne i zwyczajnie bezpieczniejsze dla SEO.
Zoptymalizuj wykonanie JavaScript, dzieląc kod na mniejsze asynchroniczne chunki. Użyj Google Lighthouse, żeby sprawdzić, czy spełniasz wymagania Core Web Vitals.
Headless CMS-y są oparte na API i nie zawsze automatycznie ogarniają tworzenie linków wewnętrznych. Napisz własną logikę, która dynamicznie generuje linki na podstawie struktury treści. Dodaj automatyczne kontrole do pipeline'u CI/CD, żeby wyłapywać niedziałające linki przed deploymentem.
(Jeszcze jedna dygresja: wydawca treści był przekonany, że ich linki wewnętrzne „po prostu będą działać” po migracji, bo przecież treść się nie zmieniła. Tyle że URL-e linków w CMS-ie były zahardkodowane pod starą strukturę domeny. 2,300 linków wewnętrznych zepsuło się po cichu. Zorientowali się dopiero po trzech tygodniach.)
Używaj przekierowań 301 przy trwałych zmianach URL. Nigdy nie używaj 302 (tymczasowych) przekierowań podczas migracji — nie przekazują wartości SEO w ten sam sposób. Wdróż reguły przekierowań w konfiguracji serwera (Nginx albo Apache) albo na poziomie CDN. Monitoruj redirect chains i usuwaj je.
W headless CMS może się okazać, że mapę witryny musisz generować ręcznie albo przez API. Ustaw automatyczne generowanie, które aktualizuje się przy każdym utworzeniu lub zmianie treści. Wyślij mapę witryny do Google Search Console i wyklucz z niej strony niekanoniczne albo zduplikowane.
Jeśli obsługujesz wiele języków albo regionów, tagi hreflang są niezbędne. W architekturze headless często też trzeba dodać je ręcznie. Po migracji zweryfikuj wdrożenie za pomocą Screaming Frog albo Ahrefs.
| Etap | Działania | Harmonogram |
|---|---|---|
| Przed migracją | Audyt URL, mapa przekierowań, eksport metryk bazowych (ruch, pozycje, backlinki, CWV) | 2-4 tygodnie wcześniej |
| Staging | Budowa nowego frontendu, wdrożenie SSR/SSG, konfiguracja metadanych, tagów kanonicznych i mapy witryny. Testowanie przekierowań | Równolegle z developmentem |
| Start | Deployment, wysłanie zaktualizowanej mapy witryny do GSC, monitorowanie błędów crawlowania w czasie rzeczywistym | Dzień 1 |
| Po starcie (Tydzień 1-2) | Monitorowanie pokrycia indeksacji, zmian pozycji i błędów crawlowania. Naprawa błędnych przekierowań i brakujących stron | Codzienny monitoring |
| Po starcie (Miesiąc 1-3) | Porównanie ruchu i pozycji z baseline. Naprawa utrzymujących się spadków. Audyt linków wewnętrznych | Przeglądy tygodniowe |
| Podejście | Przykłady frameworków | Przyjazność dla SEO | Najlepsze zastosowanie |
|---|---|---|---|
| SSR (Server-Side Rendering) | Next.js, Nuxt.js | Doskonała — w pełni wyrenderowany HTML przy pierwszym żądaniu | Dynamiczna treść, spersonalizowane strony, e-commerce |
| SSG (Static Site Generation) | Gatsby, Astro, Next.js (static export) | Doskonała — wcześniej zbudowane pliki HTML | Blogi, strony marketingowe, dokumentacja |
| CSR (Client-Side Rendering) | React SPA, Vue SPA | Słaba bez pre-renderingu albo hydration | Interfejsy aplikacyjne, gdzie SEO ma drugorzędne znaczenie |
Jeśli SEO ma znaczenie dla twojego biznesu — a skoro to czytasz, to ma — wybieraj SSR albo SSG. CSR jest do dashboardów i narzędzi wewnętrznych, a nie do stron, które chcesz, żeby Google indeksowało niezawodnie.
Migracje są stresujące, ale są też szansą. Firma B2B SaaS, która zrobiła to dobrze, skończyła z szybszymi stronami, lepszymi Core Web Vitals i finalnie wyższymi pozycjami niż wcześniej. Kluczem było potraktowanie SEO jako pełnoprawnego wymagania migracyjnego, a nie dodatku „na później”.
Zaplanuj wszystko z wyprzedzeniem. Rozpisz każdy URL. Przetestuj przekierowania na stagingu. Monitoruj codziennie przez pierwsze dwa tygodnie. I na litość dla twojego ruchu: nie zmieniaj struktury URL bez przekierowań 301.
Nie, jeśli dobrze to zaplanujesz. Zachowaj strukturę URL, ustaw przekierowania 301, wdroż SSR albo SSG i zweryfikuj metadane, mapy witryny oraz tagi kanoniczne. Straty pojawiają się wtedy, gdy te kroki są pomijane.
Sam CMS ma mniejsze znaczenie niż framework frontendu. Contentful, Sanity, Strapi i Prismic są w porządku — kluczowe jest to, czy frontend korzysta z SSR/SSG (Next.js, Nuxt.js, Gatsby), czy z czystego CSR.
Jeśli wszystko zrobisz poprawnie, strata ruchu powinna być minimalna. Odzyskiwanie po źle przeprowadzonej migracji zwykle trwa 2-6 miesięcy, zależnie od skali problemów z przekierowaniami i indeksacją.
SSR albo SSG są zdecydowanie rekomendowane. Google potrafi indeksować strony oparte na CSR, ale robi to wolniej i mniej niezawodnie. Dla stron, na których zależy ci na ruchu organicznym, przygotowuj HTML z wyprzedzeniem.
Zmiana URL-i bez wdrożenia przekierowań 301. Sam ten błąd odpowiada za większość spadków ruchu, jakie widziałem.
Powiązane materiały:
no credit card required
No related articles found.
