„Za kwartał przełączamy stronę”. Co marketing MUSI ogarnąć, zanim ta poprzednia zniknie?

Spotkanie statusowe, ostatni punkt agendy, ktoś rzuca: „aha, za trzy miesiące przesiadamy się na nowy stack”. A Twój zespół dopiero co ustabilizował ruch organiczny i kampanie na obecnej stronie. Przebudowa serwisu to moment, w którym marketing ryzykuje najwięcej. A w firmach technologicznych, gdzie stroną na co dzień rządzą devowie, często dowiaduje się o niej ostatni.  

Spisaliśmy więc, co musisz zabezpieczyć, zanim stara strona zniknie. I dlaczego to jest też Twój najlepszy moment na marketingową ofensywę, nie tylko na obronę.

Skąd się biorą przebudowy stron? (podpowiedź: rzadko ze starego kodu)

Firmy przebudowują strony średnio co około 3 lata (realny przedział to 2–5 lat, zależnie od branży i tempa zmian). I prawie nigdy nie robią tego dlatego, że „kod się zestarzał”.

Robią to, bo zmienia się biznes: rebranding, wejście na nowe rynki, rozbudowa oferty o nowe usługi, zmiana modelu sprzedaży. Technologia jest tylko narzędziem tej zmiany. Pisaliśmy zresztą niedawno o głośnym wariancie tego trendu, czyli przesiadkach firm IT z WordPressa na Astro.

I tu pojawia się coś, co obserwujemy w firmach technologicznych. Skoro trigger przebudowy jest BIZNESOWY, to projekt powinien mieć właściciela wyniku BIZNESOWEGO. A ma właściciela repozytorium.

Jest jeszcze jedna warstwa, o której mówi się rzadziej. Szef marketingu ma na tę decyzję mniej czasu, niż mu się wydaje: średnia kadencja CMO to 4,1–4,3 roku, najkrócej w całym C-suite. Wjeżdża dodatkowa presja na szybki, widoczny wynik. A mało który projekt jest tak widoczny jak nowa strona: na efekt czeka pół organizacji, co tydzień ktoś dopytuje «to kiedy odpalamy?», a uwagi potrafi zgłaszać dziesięć zespołów naraz. Taki projekt umie zbudować pozycję szefa marketingu. Pod warunkiem że masz policzone, co możesz na nim wygrać, a co przegrać.

Co musisz mieć w dokumentacji i Excelu, zanim devowie wyłączą starą stronę

“Przecież wszystko przenosimy, będzie jeden do jednego, tylko szybciej”. 

“To projekt techniczny, marketing dostanie nową stronę i będzie zadowolony”. 

My widzimy (i potwierdzamy z naszego doświadczenia i obserwacji), to co mówią branżowe przewodniki migracji i raporty agencyjne po nieudanych przeprowadzkach.

Natychmiastowe spadki ruchu organicznego rzędu 30–50%, których naprawa trwa miesiącami. Nie dlatego, że nowa technologia była zła. Dlatego, że nikt nie spisał, czego nie wolno pominąć.

Google w dokumentacji migracji uprzedza wprost, że nawet poprawnie przeprowadzona przeprowadzka oznacza przejściowe falowanie widoczności, a przekierowania trzeba utrzymać co najmniej rok. Twoja rola to sprawić, żeby falowanie trwało tygodnie, a nie kwartały. Trzy (podstawowe) rzeczy muszą powstać, zanim ktokolwiek zamrozi projekt nowej strony.

Baseline i inwentaryzacja – musisz wiedzieć, co masz do stracenia

Zanim cokolwiek się zmieni, wyeksportuj 12 miesięcy danych: ruch organiczny per podstrona (GA4), dane z GSC, zapytania i pozycje, konwersje per szablon strony, podstrony z najsilniejszymi linkami zewnętrznymi itd. (lista jest długa i musi być dokładna). 

Do tego pełny crawl serwisu, czyli wszystkie indeksowalne adresy, statusy, canonicale, dane strukturalne.

Brzmi jak żmudna robota? Jest nią (ale my to na luzie automatyzujemy z naszymi autorskimi aplikacjami z działu R&D). Ale baseline pełni dwie funkcje naraz. Po pierwsze, bez niego nie wykryjesz, gdzie po starcie przecieka ruch. 

Po drugie: bez punktu odniesienia nie udowodnisz zarządowi, że migracja cokolwiek dała. Albo że spadek nie wynika z Twoich działań.

Mapa przekierowań 301, czyli polisa na wypracowany autorytet domeny

Praktycznie każdy stary adres URL musi mieć swój odpowiednik na nowej stronie, zmapowany jeden do jednego. Arkusz z tą mapą (stary URL, nowy URL, decyzja: zostaje, przekierowujemy, łączymy, usuwamy) musi istnieć, zanim devowie zamrożą strukturę adresów. Nie po launchu. Nie „w następnym sprincie”.

Najczęstszy błąd krytyczny to wszystkie stare adresy przekierowane hurtem na stronę główną. Dla Google to sygnał, że stare podstrony po prostu zniknęły, razem z całym autorytetem, który latami na siebie pracowały.

Metadane i analityka – nie pozwól, żeby strona oślepła po starcie

Osobny rozdział to pomiar. GTM, eventy, cele, consent mode, piksele, integracja z CRM: wszystko musi działać od pierwszej sekundy po starcie, na tych samych property. Inaczej stracisz ciągłość danych i atrybucję leadów. A wtedy nawet udana migracja będzie wyglądać w raportach jak katastrofa, bo nie będzie czym jej obronić.

Widoczność w AI (tak, znowu ten wątek), czyli czego nie ma na typowych checklistach

O tym, że GPT i większość botów LLM nie renderują JavaScriptu świadomość jest różna, my ZAWSZE sprawdzamy to przy okazji naszej pracy podczas pozycjonowania w AI. Przy migracji dochodzą trzy rzeczy, których nie znajdziesz na standardowych listach.

• URL-e cytowane przez AI to osobna klasa ryzyka. Sprawdź, które adresy Twojej strony pojawiają się w odpowiedziach ChatGPT, Perplexity czy AI Overviews + potwierdź to z referallami w GA4 (my mamy na to swoją aplikację LLM Reporter). To niekoniecznie strony z największym ruchem. Każdy z nich traktuj jako „must-redirect” jeden do jednego.
• Nowa infrastruktura potrafi po cichu zablokować boty AI. Raporty migracyjne z 2025 i 2026 roku raportują, że nowe CDN-y potrafią domyślnie blokować GPTBota, ClaudeBota czy PerplexityBota (mechanizmy bot-management robią to automatycznie, bez pytania). Test jest banalny: zapytanie o stronę z user-agentem bota AI ma zwrócić 200, nie 403. Na stagingu i po starcie.
• Stabilność cytowanych fragmentów. Modele składają odpowiedzi z konkretnych treści. Redesign, który „przemiela” pytaniowe nagłówki i sekcje odpowiedzi, każe im uczyć się Twojej strony od zera.

I uczciwie, jak zawsze przy tym temacie: dostępny HTML i ciągłość sygnałów to warunek konieczny widoczności w AI, nie gwarancja cytowań. Ale strony, której boty po migracji nie widzą, nie zacytuje nikt.

Kto decyduje, że nowa strona idzie na produkcję? I po co to określać?

Strona firmowa nie ma jednego właściciela. Marketing odpowiada za treść, przekaz i konwersję, devowie za platformę, bezpieczeństwo i release’y. Ten podział działa, dopóki ktoś nie ustali, że launch może się odbyć bez gotowego X, Y czy Z, „bo deadline”.

Dlatego w projekcie migracji potrzebujesz dwóch rzeczy: modelu odpowiedzialności (kto ownuje mapę 301, kto metadane, kto analitykę) i sign-offu SEO jako warunku premiery. 

Jeśli staging nie przeszedł crawlu porównawczego, premiera czeka. I nie jest hamowanie projektu. To powód, dla którego marketing w ogóle siedzi przy tym stole, zamiast dowiadywać się o wszystkim z maila po deployu.

To, co jest moją oczywistością, a o której zapominamy – najdroższa migracja to ta, którą trzeba naprawiać po spadkach

Z rozmów z firmami wynosimy jedną powtarzalną obserwację. Firmy, które przychodzą do nas przed migracją, wydają na zabezpieczenie projektu ułamek tego, co firmy, które przychodzą po niej, z wykresem ruchu lecącym w dół i pytaniem „da się to odkręcić?”. 

Da się. Ale odbudowa trwa zwykle od dwóch do nawet ośmiu miesięcy i przez ten czas pipeline nie żyje z organica. Mamy na to zresztą dowód z własnego podwórka: przy migracji sklepu marki biżuteryjnej weszliśmy w projekt jako konsultanci jeszcze przed przełączeniem — i to my doradziliśmy zwolnienie tempa, żeby zdążyć przebudować strukturę i przygotować treści na dzień startu. Efektem była całkowite rozwinięcie oferty, setki przekierowań 301, zero utraty widoczności w trakcie przeprowadzki i +230% widoczności po niej. Inna branża niż IT, ta sama mechanika. Czasem wolniej znaczy lepiej (i w perspektywie taniej). 

Audyt przedmigracyjny to najtańsza polisa na najdroższy projekt marketingowy, jaki firma robi raz na kilka lat. A dla szefa marketingu to dowód, że wszedł w projekt devów ze strategią, a nie z pretensjami.

O tym, co robić, kiedy migracja już poszła źle i ruch poleciał, piszemy w kolejnym materiale z tego cyklu. Będzie też trzeci, o sytuacji, o której mało kto mówi głośno: nowa strona jako pierwszy duży projekt nowego szefa marketingu. Czasem z własnej inicjatywy, częściej na zlecenie zarządu — i tylko z pozoru jest to wdzięczny cel na start. Podpowiemy, jak go poprowadzić i nie podpisać się krwią pod cudzym harmonogramem.

A moje pytanie z tego powyżej brzmi: gdyby devowie ogłosili dziś, że za kwartał przełączają stronę, to wiesz, co masz gotowe na jutro?

FAQ – o co pytają nas firmy przed migracją strony

Czy migracja strony zawsze wiąże się ze spadkiem pozycji?

Przejściowe falowanie pozycji przez 2–8 tygodni jest naturalne, bo Google musi przeindeksować nową strukturę. Trwałe spadki to niemal zawsze efekt błędów: braków w mapowaniu adresów, usuniętych treści, zgubionych metadanych. Dobrze poprowadzona migracja potrafi wręcz pomóc, bo porządkuje architekturę i technologię.

Jak długo trwają skutki źle przeprowadzonej migracji strony?

Według raportów branżowych naprawa błędów po fakcie (na przykład brakujących przekierowań 301) to zwykle 2–6 miesięcy odbudowy ruchu. W tym czasie lukę w organicu trzeba przykrywać budżetem reklamowym. Dlatego audyt przedmigracyjny jest zawsze tańszy niż recovery.

Kto powinien odpowiadać za mapę przekierowań 301?

Za strategię mapowania (który stary adres prowadzi dokąd i dlaczego) odpowiada marketing lub konsultant SEO, bo to oni znają biznesową wartość podstron. Devowie odpowiadają za techniczne wdrożenie mapy. Decyzji „gdzie ma prowadzić stary URL” nie zostawia się programistom, i nie jest to złośliwość wobec programistów.

Czy nowa strona na Astro automatycznie poprawi moje pozycjonowanie w AI?

Nie automatycznie. Astro poprawia czytelność strony dla botów AI, bo serwuje czysty HTML,. Ale to, czy modele cytują Twoją markę, zależy od jakości treści, autorytetu tematycznego i architektury informacji. Migracja otwiera drzwi. Przejść przez nie musi już strategia.

Ile czasu przed startem nowej strony zacząć planowanie SEO?

Idealnie: na etapie projektowania architektury informacji, zanim powstanie design nowego serwisu (ten wizualny i ten technologiczny). Realnie: minimum 4–6 tygodni przed launchem, żeby zdążyć z pełnym inwentarzem, mapą struktury strony i crawlem porównawczym stagingu.