Migracja na headless: czy stracisz pozycje w Google?

„Przejdziemy na storefront w Next.js albo Astro, a Google zapomni, że Twój sklep istnieje.” Tak mniej więcej brzmi obawa, którą słyszymy najczęściej. Warto ją potraktować serio, bo sklep, który zarabia, żyje z ruchu organicznego, a każda niekontrolowana zmiana to realne pieniądze.

Nasza teza jest prosta i bywa niewygodna dla obu stron sporu:

Technologia headless nie zabija pozycji. Zabija je niechlujna migracja — a ta jest w pełni przewidywalna.

Poniżej pokazujemy, co dokładnie może pójść źle, jak to wykrywamy, zanim zobaczy to Google, oraz czego uczciwie obiecać się nie da. To część serii o headless commerce.

Co Google naprawdę ocenia

Wyszukiwarka nie wie, czy Twój sklep stoi na WooCommerce, PrestaShop czy Next.js. Widzi:

• adresy URL i to, czy ich zachowanie jest stabilne,
• treść w HTML: tytuły, nagłówki, opisy, tekst kategorii,
• linkowanie wewnętrzne: menu, breadcrumbs, powiązane produkty, paginację,
• sygnały techniczne: kody odpowiedzi, canonical, robots, sitemapy,
• dane strukturalne: produkt, cena, dostępność, opinie,
• szybkość i stabilność działania strony.

Skoro zmiana platformy nie zmienia nic z tej listy, ranking nie ma powodu się zmieniać. Problem w tym, że w praktyce migracja zmienia je po cichu, jeśli nikt tego nie pilnuje.

Pięć mechanizmów utraty pozycji

1. Adresy URL bez przekierowań 1:1

Najczęstszy i najdroższy błąd. Nowy front ma inną strukturę (/kategoria/sofy/ zamiast /sofy-c12/), stare adresy zwracają 404 albo — co gorsze — wszystkie trafiają na stronę główną. Google traktuje to jako usunięcie stron i kasuje ich pozycje wraz z linkami zewnętrznymi, które na nie wskazywały.

Typowe wariacje: łańcuchy przekierowań (A → B → C), przekierowania tymczasowe (302) zamiast stałych (301), pominięte adresy z parametrami, stare adresy obrazków i plików.

2. Treść, której nie ma w HTML

Jeśli front jest aplikacją renderowaną wyłącznie w przeglądarce, robot dostaje pustą stronę i musi wykonać skrypty, żeby coś zobaczyć. Google potrafi to robić, ale z opóźnieniem i niezawodnością gorszą niż przy gotowym HTML. Next.js i Astro domyślnie generują pełny HTML po stronie serwera lub podczas budowania — tak powinno być, ale konfiguracja decyduje: wystarczy, że kluczowy fragment (opis kategorii, lista produktów) ładuje się po wejściu użytkownika.

3. „Zgubione” elementy techniczne

W starym sklepie wiele rzeczy dzieje się przez wtyczki i szablon, o których nikt nie pamięta, dopóki nie znikną: dane strukturalne produktu, canonical dla filtrów, paginacja, hreflang, breadcrumbs, mapa strony, tytuły generowane według reguł. W nowym froncie trzeba je odtworzyć świadomie. To klasyczna przyczyna niewyjaśnionego spadku po miesiącu.

4. Pogorszenie treści i linkowania

Podczas przebudowy łatwo przypadkiem usunąć tekst z kategorii („bo ładniej bez”), uprościć menu, wyciąć „powiązane produkty” albo zmienić paginację. Dla designera to porządek, dla Google — utrata sygnałów. Zmiana wyglądu jest bezpieczna, zmiana struktury informacji i linków wewnętrznych — niekoniecznie.

5. Wpadki wdrożeniowe, które kosztują najwięcej

Najgłupsze błędy robią największe szkody:

• pozostawiony na produkcji noindex albo Disallow: / w pliku robots ze środowiska testowego,
• niepoprawne przekierowanie wersji z www i bez,
• niedziałające HTTPS lub błędy certyfikatu,
• wolny pierwszy bajt po przełączeniu, gdy brakuje pamięci podręcznej,
• błędy 5xx w pierwszych godzinach, gdy Googlebot odwiedza stronę,
• zła mapa strony lub brak jej zgłoszenia.

Zauważ, że żaden z tych błędów nie jest wadą headless. To po prostu błędy migracji. Dokładnie te same występują przy przenosinach z jednego klasycznego sklepu na inny.

Dlaczego pewne wahania są normalne

Warto powiedzieć to otwarcie: nawet w idealnej migracji pozycje mogą przez kilka tygodni się wahać. Google ponownie crawluje strony, aktualizuje indeks i przenosi sygnały. Uczciwa obietnica nie brzmi „nic się nie zmieni”, tylko:

Nie stracisz niczego niekontrolowanie. Będziemy widzieć każdą zmianę w dniach, nie w miesiącach, i będziemy wiedzieć, co ją spowodowało.

Różnica między „wahaniem” a „katastrofą” polega na tym, że w pierwszym przypadku masz dane i plan działania, a w drugim dowiadujesz się o problemie z faktur za reklamy.

Jak to robimy: proces z bramkami

Pracujemy jak agencja wspierana AI, ale dla nas AI to narzędzie do sprawdzania i porównywania na dużą skalę, nie obietnica „wszystko będzie dobrze”. Decyzje i odpowiedzialność pozostają po stronie ludzi. Każdy etap ma bramkę: nie przechodzimy dalej, dopóki wynik nie spełnia progu.

Etap 0. Zdjęcie stanu wyjściowego (baseline)

Zanim ruszy jakakolwiek praca, zapisujemy punkt odniesienia:

• pełny crawl obecnego sklepu: wszystkie adresy, kody odpowiedzi, tytuły, nagłówki, canonical, dane strukturalne, linki wewnętrzne,
• eksport z Google Search Console: zapytania, strony, wyświetlenia, kliknięcia,
• pozycje najważniejszych fraz,
• przychód i transakcje z podziałem na strony wejścia,
• logi serwera: które adresy faktycznie odwiedza Googlebot,
• listę adresów z linkami zewnętrznymi.

Bez tego nie da się później powiedzieć, czy coś spadło, ani co.

Etap 1. Inwentarz adresów i zasada „nie ruszamy URL-i”

Domyślnie zachowujemy dotychczasowe adresy. To najtańszy sposób na bezpieczeństwo. Jeśli struktura musi się zmienić (np. stara platforma generowała brzydkie adresy), tworzymy mapę 1:1 starych na nowe. AI pomaga dopasować tysiące adresów według treści i kategorii, ale każdą grupę zatwierdza człowiek, a w mapie nie ma „wszystko na stronę główną”.

Etap 2. Staging zablokowany przed Google i test równoważności

Nowy storefront działa na środowisku testowym zabezpieczonym hasłem i noindex. Następnie automatycznie porównujemy go ze starym sklepem:

• czy każdy adres z baseline istnieje albo ma przekierowanie,
• czy tytuły, nagłówki, canonical i dane strukturalne są zgodne,
• czy treść kategorii i opisów jest obecna w HTML (bez wykonywania skryptów),
• czy liczba i cele linków wewnętrznych są porównywalne,
• czy nie pojawiły się nowe błędy.

Raport różnic jest klasyfikowany: krytyczne (blokują wdrożenie), istotne, kosmetyczne. AI przyspiesza porównanie tysięcy stron i grupuje podobne różnice, żeby człowiek zajął się wyjątkami, a nie przeglądał wszystko ręcznie.

Etap 3. Test przekierowań

Każdy adres z baseline musi dać jedną z dwóch odpowiedzi: 200 albo pojedyncze 301 do właściwego celu. Sprawdzamy brak łańcuchów, pętli i 404 na stronach, które miały ruch lub linki zewnętrzne. To etap, w którym wykrywa się najwięcej poważnych problemów.

Etap 4. Wydajność i obciążenie

Mierzymy czas odpowiedzi i stabilność wizualną strony na środowisku zbliżonym do produkcji oraz zachowanie pod obciążeniem. Chodzi o to, żeby w dniu przełączenia pierwszy odwiedzający Googlebot trafił na szybką, działającą stronę. Zob. Core Web Vitals.

Etap 5. Termin i plan wycofania

• Termin poza sezonem sprzedażowym i poza ważnymi kampaniami.
• Zamrożenie zmian treści na starym sklepie na czas migracji.
• Wcześniejsze obniżenie czasu życia wpisów DNS, żeby w razie potrzeby szybko wrócić.
• Stary sklep zostaje w gotowości przez kilkanaście dni.
• Jasno opisane kryteria: kiedy wracamy, a kiedy naprawiamy w locie.

Etap 6. Przełączenie z listą kontrolną

W dniu wdrożenia przechodzimy przez listę, w której na szczególnym miejscu stoi usunięcie blokad ze środowiska testowego: noindex, robots, hasło. Do tego: poprawne HTTPS, przekierowanie domen, mapa strony, zgłoszenie w Search Console, działanie koszyka i płatności, śledzenie konwersji, feed do Google Merchant Center, formularze kontaktowe.

Etap 7. Monitoring przez 30–90 dni

Po przełączeniu zaczyna się najważniejsza część:

• codzienny crawl i porównanie z baseline,
• monitoring indeksowania w Search Console (adresy wykluczone, błędy, odkryte-nieindeksowane),
• analiza logów: czy Googlebot dostaje 200, czy nie trafia na błędy,
• śledzenie pozycji kluczowych fraz oraz wyświetleń i kliknięć,
• alerty na wzrost 404 i 5xx, spadek wyświetleń lub przychodu z konkretnych stron,
• cotygodniowy raport w języku biznesowym: co się stało, co zrobiliśmy, co dalej.

AI przydaje się tu do wykrywania anomalii (np. nagły spadek w jednej kategorii) i do szybkiego łączenia ich z przyczynami, ale reakcję zatwierdza człowiek.

Co robi AI, a co człowiek

AI	Człowiek
porównanie tysięcy stron stary vs nowy	decyzja, co jest krytyczne
dopasowanie adresów do przekierowań	zatwierdzenie mapy
analiza logów i wykrywanie anomalii	wybór terminu i planu wycofania
klasyfikacja różnic w raporcie	ocena wpływu biznesowego
szybki podgląd regresji codziennie	odpowiedzialność za wynik

Dzięki temu migracja jest nie „na 100%, bo tak mówimy”, tylko sprawdzana na każdym kroku, z dowodami.

Czego uczciwie nie obiecujemy

• Zerowych wahań — część procesów po stronie Google nie jest pod naszą kontrolą.
• Natychmiastowego wzrostu — najpierw nie stracić, potem zyskać. Szybsza strona i pełna kontrola nad strukturą sprzyjają widoczności, ale nie gwarantują pozycji.
• Że migracja zawsze się opłaca — zależy od sklepu.

Kiedy nie migrować

• Sklep dobrze sprzedaje, nie hamuje rozwoju i nie ma problemów z szybkością ani bezpieczeństwem.
• Do szczytu sezonu zostały tygodnie.
• Brakuje zasobów na monitoring po wdrożeniu — migracja bez opieki jest hazardem.
• Powód to wyłącznie moda na technologię.

W takich przypadkach lepiej poprawić istniejącą platformę. O tym, kiedy headless się opłaca, piszemy w artykule o przyszłości storefrontów.

Pięć zdań w ofercie migracji, które powinny Cię zaniepokoić

1. „Wszystkie stare adresy przekierujemy na stronę główną.”
2. „SEO zajmiemy się po wdrożeniu.”
3. „Crawl starego sklepu nie jest potrzebny.”
4. „Na stagingu wszystko wygląda dobrze” — bez raportu różnic.
5. „Gwarantujemy, że pozycje nie spadną.”

Każde z nich oznacza brak procesu albo brak szczerości.

Podsumowanie

Pytanie nie brzmi „czy headless szkodzi SEO”, tylko „czy wykonawca ma proces, który wyłapie pięć znanych błędów, zanim Google je zobaczy”. Technologia daje potencjał: szybkość, kontrolę, elastyczność. Ale pozycji nie traci się przez framework — traci się je przez adresy, treść i niedopatrzenia w dniu wdrożenia. Dobry plan to plan mierzalny, odwracalny i monitorowany.

Planujesz migrację i chcesz poznać ryzyka swojego sklepu? Zobacz headless commerce i pozycjonowanie sklepów internetowych albo napisz do nas. Szczegółowy plan techniczny przejścia znajdziesz w migracji krok po kroku.