

Screenshot
Migracja strony nie musi oznaczać utraty widoczności w Google. Ryzyko pojawia się przede wszystkim wtedy, gdy podczas zmiany serwisu tracimy lub modyfikujemy elementy, które wcześniej pracowały na jego wyniki: adresy URL, treści, metadane, strukturę czy sposób, w jaki roboty wyszukiwarki mogą poruszać się po stronie. Dlatego o SEO warto pomyśleć jeszcze przed rozpoczęciem prac nad nową witryną, a nie dopiero wtedy, gdy developer jest gotowy do jej publikacji.
Najlepszy model to współpraca osoby odpowiedzialnej za marketing, developera i specjalisty SEO od początku projektu. Pozwala najpierw ustalić, co na starej stronie warto zachować, później kontrolować istotne zmiany, a przed uruchomieniem zweryfikować nową wersję. To ważne również dlatego, że migracja nie zawsze oznacza zmianę domeny. Może obejmować nowy CMS, hosting, strukturę serwisu czy adresów URL, a czasem nawet sam redesign, jeśli wraz z wyglądem zmieniają się treści i ich hierarchia.
Migracja strony to każda większa zmiana serwisu, która może wpłynąć na sposób, w jaki Google go odczytuje i ocenia. Może oznaczać zmianę domeny, CMS-u lub hostingu, przejście z HTTP na HTTPS, przebudowę architektury informacji czy zmianę struktury adresów URL. W praktyce często kilka takich operacji odbywa się jednocześnie – firma przy okazji tworzenia nowej strony zmienia CMS, wygląd, strukturę i domenę. Z perspektywy SEO oznacza to więcej elementów, które trzeba zabezpieczyć i później zweryfikować.
Co ważne, migracją z punktu widzenia SEO może być również redesign strony, nawet jeśli domena i część adresów URL pozostają bez zmian. Nowy projekt może zmienić hierarchię nagłówków, rozmieszczenie treści, menu czy całą architekturę informacji. Dlatego pytanie nie powinno brzmieć wyłącznie „czy zmieniamy adresy?”, ale raczej „co na nowej stronie będzie inne niż na obecnej?”. Dopiero taka lista zmian pozwala ocenić, które elementy wymagają szczególnej uwagi i gdzie rzeczywiście pojawia się ryzyko utraty wypracowanej widoczności.
Włączenie specjalisty SEO na kilka dni przed uruchomieniem nowej strony to zdecydowanie za późno. Na tym etapie struktura serwisu, adresy URL, menu, treści czy makiety są zwykle już przygotowane, więc wykrycie problemu może oznaczać cofnięcie części prac. Znacznie lepiej uwzględnić SEO już podczas planowania migracji. Specjalista może wtedy przeanalizować projekt i architekturę informacji, przygotować wytyczne dla developera oraz zwrócić uwagę na rozwiązania, które mogą mieć znaczenie dla dotychczasowej widoczności.
W praktyce dobrze sprawdza się bezpośrednia współpraca trzech stron: osoby odpowiedzialnej za projekt po stronie firmy, developera i specjalisty SEO. Nie chodzi przy tym o to, żeby SEO przejmowało rolę programisty. Każdy odpowiada za swój obszar, ale decyzje, które dotyczą widoczności, są konsultowane zanim zostaną wdrożone. Specjalista SEO może dzięki temu na bieżąco sprawdzać kolejne etapy prac, a przed publikacją zweryfikować, czy nowa strona jest gotowa do uruchomienia z punktu widzenia SEO.
Przed migracją warto dokładnie przyjrzeć się obecnej stronie: sprawdzić jej widoczność, ruch, pozycje na ważne frazy i podstrony, które mają znaczenie dla biznesu. Chodzi o ustalenie, co już działa i czego nie chcemy przypadkowo stracić podczas przebudowy. Jeżeli serwis zdobył dobre pozycje i generuje wartościowy ruch, celem migracji powinno być zabezpieczenie tych efektów. Jeżeli natomiast jego potencjał ogranicza stary CMS lub niewłaściwa architektura,
Jednym ze sposobów na zapisanie technicznego stanu strony przed migracją jest wykonanie jej pełnego crawlu. Dzięki temu mamy listę adresów URL i możemy później porównać ją z nową wersją serwisu, sprawdzając m.in. statusy odpowiedzi oraz najważniejsze elementy SEO poszczególnych podstron. Taki punkt odniesienia ułatwia wychwycenie zmian, które przy dużym serwisie trudno byłoby zauważyć ręcznie. Po przygotowaniu nowej wersji analogiczny crawl pozwala zestawić oba serwisy i sprawdzić, czy podczas przenosin nie zniknęły istotne adresy lub elementy, które planowaliśmy zachować.
Jednym z najważniejszych elementów jest ustalenie, co stanie się z dotychczasowymi adresami URL. Jeśli adres konkretnej podstrony się zmienia, a w nowym serwisie istnieje jej odpowiednik, trzeba zaplanować przekierowanie 301. Najlepiej zrobić to jeszcze przed uruchomieniem strony, przygotowując mapę starych i nowych adresów. Pozostawienie tego na koniec zwiększa ryzyko, że część wartościowych podstron zacznie zwracać błędy 404 albo użytkownicy i roboty Google będą trafiać w niewłaściwe miejsca.
Dobrze przygotowana mapa migracji powinna określać los każdego istotnego adresu starego serwisu. Jeśli URL pozostaje bez zmian, nie potrzebuje przekierowania. Jeśli się zmienia, powinien otrzymać przekierowanie 301 do możliwie najlepiej odpowiadającej mu podstrony w nowym serwisie. Część adresów może też świadomie przestać istnieć, jeśli nie ma dla nich wartościowego odpowiednika i nie chcemy zachowywać danej treści. Warto przy tym sprawdzić nie tylko, czy przekierowania zostały wdrożone, ale również dokąd prowadzą. Należy unikać łańcuchów przekierowań, pętli oraz automatycznego kierowania wielu niepowiązanych podstron na stronę główną.
| Co dzieje się z podstroną? | Co zrobić z URL-em? | Przykład |
| Podstrona pozostaje pod tym samym adresem | Zostawić URL bez zmian | /pozycjonowanie/ → /pozycjonowanie/ |
| Podstrona zmienia adres | Zastosować przekierowanie 301 do jej nowego odpowiednika | /seo/ → /pozycjonowanie/ |
| Stara treść została zastąpiona inną stroną o tej samej tematyce | Przekierować do najbardziej adekwatnego odpowiednika | stara podstrona usługi → nowa podstrona tej usługi |
| Podstrona znika i nie ma sensownego odpowiednika | Świadomie zakończyć jej funkcjonowanie zamiast kierować użytkownika w przypadkowe miejsce | nieaktualna oferta bez następcy |
Nie oznacza to jednak, że podczas migracji trzeba za wszelką cenę zachować każdą podstronę starego serwisu. To również dobry moment, żeby uporządkować zasoby i zrezygnować z treści, które są już nieaktualne lub nie mają wartości. Taka decyzja powinna być jednak świadoma i poprzedzona analizą. Szczególnej uwagi wymagają adresy, które wcześniej generowały ruch, były widoczne na istotne frazy albo odpowiadały ważnym obszarom oferty – ich przypadkowe usunięcie może oznaczać utratę efektów wypracowanych przed migracją.
Sama mapa przekierowań nie wystarczy. Podczas migracji trzeba również sprawdzić, co dzieje się z treściami, metadanymi, nagłówkami i strukturą informacji. Jeżeli dobrze widoczna podstrona po przeniesieniu zachowuje adres lub otrzymuje prawidłowe przekierowanie, ale jednocześnie traci dużą część treści albo zmienia się jej tematyka, efekt SEO może być inny niż zakładaliśmy. Dlatego wartościowe elementy starej strony warto przenosić możliwie konsekwentnie, a większe zmiany wprowadzać świadomie, wiedząc, co i dlaczego modyfikujemy.
Dotyczy to również menu i całej architektury serwisu. Nowa strona ma być wygodniejsza i lepiej odpowiadać aktualnej ofercie, więc nie chodzi o kopiowanie starej struktury jeden do jednego. Trzeba jednak sprawdzić, czy podczas jej upraszczania nie znikają ważne kategorie, podstrony usługowe lub treści odpowiadające na istotne potrzeby klientów. Szczególnie w rozbudowanych serwisach i e-commerce sposób uporządkowania kategorii pomaga zarówno użytkownikom dotrzeć do właściwej oferty, jak i robotom Google poruszać się po witrynie.
Przy migracji trzeba też zadbać o elementy, których użytkownik strony zwykle nie widzi. Jeśli zmieniła się struktura serwisu, należy zaktualizować sitemapę i przekazać ją w Google Search Console. Równie ważne jest sprawdzenie narzędzi wykorzystywanych do pomiaru i marketingu – w podcaście wskazano m.in. Google Analytics oraz kody związane z Google Ads i Facebookiem. Ich poprawne działanie warto zweryfikować jeszcze przed uruchomieniem nowej wersji.
To istotne z dwóch powodów. Po pierwsze, brak prawidłowego pomiaru może sprawić, że po migracji zobaczymy w raportach spadek ruchu, choć problem leży w zbieraniu danych, a nie w samej widoczności strony. Po drugie, dane o zachowaniu użytkowników i konwersjach są wykorzystywane także w działaniach reklamowych. Migracja powinna więc obejmować nie tylko to, co widać w Google, ale cały zestaw rozwiązań, od których zależy późniejsza ocena efektów marketingowych.
Wersja developerska strony powinna być miejscem, w którym można spokojnie sprawdzić efekty prac, zanim serwis zostanie udostępniony użytkownikom. Z perspektywy SEO ważne jest jednak, żeby staging nie został przypadkowo zaindeksowany. W podcaście zwracamy uwagę na stosowanie noindex podczas prac nad stroną – dzięki temu wersja robocza nie powinna pojawić się w wynikach wyszukiwania obok właściwego serwisu.
Problem może pojawić się również w dokładnie odwrotnej sytuacji: zabezpieczenie działa poprawnie na stagingu, ale po publikacji nikt go nie usuwa. Jeśli noindex zostanie przeniesiony na wersję produkcyjną, Google otrzymuje informację, że tych stron nie powinno być w indeksie. Dlatego zdjęcie blokady indeksowania powinno być jednym z punktów kontroli podczas uruchamiania nowej strony.
Na stagingu warto jednak sprawdzić znacznie więcej niż sam noindex. To moment na porównanie nowej wersji ze starą i wychwycenie zmian, które mogłyby umknąć podczas pracy nad serwisem. Trzeba zweryfikować m.in. działanie przekierowań, statusy najważniejszych adresów URL, linkowanie wewnętrzne, canonicale, sitemapę i ustawienia robots.txt. Warto również sprawdzić, czy na właściwe miejsca trafiły treści, metadane i nagłówki, które zgodnie z planem miały zostać zachowane.
| Element | Co sprawdzić przed publikacją? | Po co? |
| Indeksowanie | Czy staging jest zabezpieczony i czy blokada zostanie zdjęta na produkcji | Żeby wersja robocza nie trafiła do indeksu, a właściwa strona mogła być indeksowana |
| Przekierowania | Czy 301 prowadzą do właściwych nowych adresów | Żeby stare URL-e nie kończyły się błędem lub w przypadkowym miejscu |
| Linkowanie wewnętrzne | Czy linki prowadzą bezpośrednio do nowych URL-i | Żeby strona nie korzystała niepotrzebnie z przekierowań |
| Canonicale | Czy wskazują właściwe adresy | Żeby nie wysyłać Google sprzecznych sygnałów dotyczących preferowanych URL-i |
| Sitemap | Czy zawiera właściwe adresy nowego serwisu | Żeby przekazać wyszukiwarce aktualną strukturę adresów |
| robots.txt | Czy ważne obszary serwisu nie są przypadkowo blokowane | Żeby roboty mogły dotrzeć do stron, które chcemy udostępnić |
| Treści i metadane | Czy istotne elementy ze starej strony zostały zachowane zgodnie z planem | Żeby podczas migracji przypadkowo nie utracić wartościowych elementów SEO |
| Analityka | Czy pomiar ruchu i konwersji działa | Żeby po migracji móc wiarygodnie oceniać wyniki |
Taka kontrola ma prosty cel: znaleźć problemy, zanim zaczniemy diagnozować ich skutki w działającym serwisie. Jeżeli coś jest nie tak z przekierowaniami, indeksowaniem czy strukturą strony, poprawienie tego przed publikacją jest zwykle znacznie prostsze organizacyjnie niż reagowanie już po migracji.
Nowej strony nie warto uruchamiać w momencie, w którym za chwilę nikt nie będzie mógł jej sprawdzić. Dlatego w podcaście odradzamy migracje w piątek po południu czy w weekend. Nie jest to żadna zasada Google – chodzi po prostu o zarządzanie ryzykiem. Po publikacji mogą ujawnić się problemy, których nie było widać na stagingu, a wtedy liczy się możliwość szybkiej diagnozy i reakcji.
Termin warto więc ustalić wspólnie z osobami zaangażowanymi we wdrożenie. Developer powinien być dostępny, jeśli trzeba będzie coś poprawić, a specjalista SEO – zweryfikować kluczowe elementy i wychwycić potencjalne problemy. Szczególne znaczenie ma to w e-commerce, gdzie błąd po wdrożeniu może wpływać nie tylko na widoczność, ale również na działanie sklepu w okresie dużego ruchu. Dobra migracja nie kończy się więc kliknięciem „publikuj”. To moment, od którego przez pewien czas trzeba szczególnie uważnie obserwować stronę.
Po publikacji nowej wersji trzeba obserwować, co dzieje się z widocznością serwisu i czy nie pojawiają się błędy techniczne. Pomagają w tym Google Search Console, narzędzia do monitorowania pozycji i widoczności oraz crawlery. Warto sprawdzać m.in. problemy z indeksowaniem, błędy związane z adresami URL i działanie przekierowań. Jeżeli coś zaczyna się zmieniać, dane pozwalają szybciej ustalić, czy mamy do czynienia z pojedynczym problemem, czy z szerszym skutkiem migracji.
Właśnie tutaj przydaje się analiza wykonana jeszcze przed rozpoczęciem prac. Wyników nowej strony nie oceniamy w próżni, ale porównujemy je ze stanem sprzed migracji. Patrzymy na indeksację, widoczność, ruch i konwersje, a jeśli pojawiają się różnice – sprawdzamy, których podstron i zapytań dotyczą. Takie porównanie pozwala odróżnić problem SEO od sytuacji, w której zmiana wynika na przykład ze świadomego usunięcia części oferty albo z nieprawidłowego pomiaru danych.
Sam spadek nie mówi jeszcze, co poszło nie tak. Przyczyną może być pozostawiony noindex, blokada robotów po stronie serwera, problem z dostępnością części serwisu czy zmiana konkretnej podstrony istotnej dla danej frazy. Dlatego zamiast od razu uznawać migrację za nieudaną, warto zejść poziom niżej i sprawdzić, które adresy oraz zapytania straciły widoczność. Taka diagnoza daje developerowi i specjaliście SEO konkretny punkt zaczepienia do znalezienia przyczyny i wprowadzenia poprawek.
Migracja wiąże się z ryzykiem, ale nie oznacza automatycznie pogorszenia wyników. Jeśli dotychczasową stronę ograniczał CMS, nieprzemyślana architektura informacji czy struktura, która utrudniała rozwijanie nowych obszarów tematycznych, przebudowa serwisu może stworzyć lepsze warunki do dalszych działań SEO. Właśnie dlatego przed migracją warto nie tylko pytać „jak nie stracić tego, co mamy?”, ale też „co możemy zrobić lepiej na nowej stronie?”.
Nie ma jednego wykresu, który pokazuje, jak „powinna” wyglądać widoczność po migracji. Dużo zależy od zakresu zmian, momentu włączenia SEO w projekt oraz tego, co dzieje się z serwisem już po wdrożeniu. Dobrze pokazują to trzy anonimowe projekty, przy których pracowaliśmy. W każdym punktem wyjścia była migracja, ale jej zakres, ograniczenia i późniejsze efekty były zupełnie inne.
W 2025 roku jeden z obsługiwanych przez nas sklepów internetowych zdecydował się nie tylko na zmianę wyglądu strony, ale również na istotną przebudowę asortymentu. O planowanej migracji dowiedzieliśmy się około miesiąca przed jej przeprowadzeniem, dlatego możliwości wpływania na część wcześniejszych decyzji dotyczących nowego serwisu były już ograniczone. Wraz ze zmianą strony usunięto wiele dotychczasowych produktów i kategorii, a jednocześnie pojawiły się nowe.
Migracja została przeprowadzona około listopada 2025 roku i w tym okresie widoczność serwisu w Senuto wyraźnie spadła. Nie można jednak interpretować tego wykresu wyłącznie jako skutku technicznej zmiany strony. Jednocześnie zmienił się asortyment i struktura sklepu, a część podstron, które wcześniej budowały widoczność, przestała istnieć. Po migracji naszym zadaniem stała się analiza zmian oraz dalsza praca nad widocznością nowego serwisu. W kolejnych miesiącach trend się odwrócił i widoczność zaczęła ponownie rosnąć, choć na moment przygotowania tego materiału nie wróciła jeszcze do najwyższego poziomu sprzed migracji.

Widoczność sklepu internetowego w Senuto przed i po migracji przeprowadzonej około listopada 2025 roku. Dane klienta zostały zanonimizowane.
Z innym klientem współpracujemy od kilku lat. Początkowo jego strona służyła przede wszystkim do prezentowania oferty biznesu lokalnego. Z czasem zapadła decyzja o rozbudowaniu serwisu o sklep internetowy oraz systematycznej pracy nad treścią. Realizacja tych planów wymagała przejścia na nowy CMS, a przy okazji strona otrzymała również nową szatę graficzną.
Nowa wersja została uruchomiona w lutym 2025 roku. W tym przypadku migracja nie była więc wyłącznie próbą zabezpieczenia dotychczasowych efektów SEO, ale częścią większego planu rozwoju serwisu. Po zmianie nie obserwowaliśmy gwałtownego załamania widoczności, a w kolejnych miesiącach – wraz z dalszym rozwojem strony i pracą nad treścią – widoczność zaczęła wyraźnie rosnąć. Nie przypisujemy tego wzrostu samej migracji. Nowa strona stworzyła jednak warunki do rozwoju, który był jednym z powodów rozpoczęcia całego projektu.

Widoczność serwisu w Senuto przed i po migracji przeprowadzonej w lutym 2025 roku. Po zmianie strona była dalej rozwijana, m.in. poprzez pracę nad treścią. Dane klienta zostały zanonimizowane.
W trzecim projekcie zakres zmian był znacznie większy: klient musiał przejść na nową domenę, zmienić stronę oraz jej treści. Dodatkowym ograniczeniem było to, że procesu nie mogliśmy planować przy założeniu wykorzystania przekierowań 301 ze starych adresów na ich odpowiedniki w nowym serwisie. Od początku było więc jasne, że nie będzie to wyłącznie techniczna migracja, ale również długofalowa praca nad budowaniem widoczności nowej domeny.
Do procesu zostaliśmy włączeni odpowiednio wcześnie i współpracowaliśmy zarówno z klientem, jak i developerami oraz zespołem odpowiedzialnym za treści. Naszym zadaniem było możliwie dobre przygotowanie serwisu do zmiany, ograniczenie ryzyka spadków oraz stworzenie podstaw do dalszego budowania widoczności. Praca nie zakończyła się w dniu wdrożenia – obejmuje monitoring, dalszą optymalizację, rozwój treści oraz link building i nadal trwa. Ten przykład dobrze pokazuje, że przy tak dużej zmianie nowa domena nie zastępuje od razu widoczności wypracowanej wcześniej przez inny serwis. Osiągnięcie odpowiedniego poziomu widoczności wymaga dalszej pracy również długo po uruchomieniu strony.

Zmiana widoczności starej i nowej domeny w trakcie procesu migracji. Ze względu na poufność projektu skala i dane zostały zanonimizowane. Proces budowania widoczności nowego serwisu nadal trwa.
Te przypadki pokazują, dlaczego efektów migracji nie warto oceniać wyłącznie na podstawie tego, czy wykres widoczności bezpośrednio po zmianie poszedł w górę czy w dół. W pierwszym projekcie wraz z nową stroną zmienił się asortyment i zniknęła część podstron budujących wcześniejszą widoczność. W drugim migracja była elementem rozwoju serwisu, który później był systematycznie rozbudowywany. W trzecim skala zmian była na tyle duża, że od początku trzeba było zakładać dłuższą pracę nad widocznością nowej domeny.
Dlatego przed migracją warto ustalić nie tylko, co technicznie zmieni się na stronie, ale również jaki jest biznesowy cel całego projektu i które dotychczasowe efekty chcemy zabezpieczyć. SEO może pomóc ograniczyć ryzyko, ale nie działa w oderwaniu od decyzji dotyczących oferty, treści, technologii czy możliwości wykonania przekierowań. Im wcześniej te ograniczenia są znane, tym lepiej można przygotować scenariusz migracji i późniejsze działania.
Sukces migracji trzeba więc oceniać w kontekście celu, który miał realizować nowy serwis. Jeśli firma świadomie ogranicza ofertę i usuwa odpowiadające jej podstrony, spadek łącznej widoczności nie musi oznaczać błędu. Z kolei jeśli migracja ma umożliwić rozwój nowych obszarów, jej efektów nie warto oceniać wyłącznie w dniu wdrożenia. Liczy się to, czy zabezpieczyliśmy najważniejsze elementy starego serwisu i czy nowa strona daje możliwość realizacji celów, dla których została przebudowana.
Migracja strony to nie moment, w którym wystarczy przygotować przekierowania i liczyć, że Google poradzi sobie z resztą. To proces, który zaczyna się jeszcze przed pierwszymi pracami nad nowym serwisem: od sprawdzenia, co na obecnej stronie działa, przez konsultowanie struktury i zmian z developerem, aż po kontrolę przed publikacją i monitoring po wdrożeniu. Im wcześniej SEO pojawi się w tym procesie, tym więcej problemów można wychwycić wtedy, gdy ich naprawienie jest jeszcze stosunkowo proste.
Nie każdej zmiany trzeba przy tym unikać. Nowa strona ma przecież rozwijać biznes, a nie być kopią starej tylko dlatego, że boimy się o pozycje. Kluczowe jest rozróżnienie tego, co warto zachować, od tego, co świadomie chcemy zmienić – i sprawdzenie konsekwencji tych decyzji przed publikacją. Dlatego przy migracji najlepiej sprawdza się współpraca marketingu, developera i SEO: każdy patrzy na stronę ze swojej perspektywy, ale wszyscy pracują nad tym samym efektem.
Dodaj komentarz