Migracja strony pod kontrolą SEO

Jak wygląda współpraca przy migracji

Migrację prowadzimy w pięciu etapach. Każdy kończy się czymś, co da się sprawdzić: listą adresów, mapą przekierowań, wynikiem testu, listą kontrolną startu i porównaniem widoczności.

Jeśli migracja już się odbyła i widoczność spadła, zacznij od części Co zrobić, gdy widoczność spadła po migracji.

Co przygotować do rozmowy o migracji

• Adres obecnej strony i planowany termin publikacji.
• Zakres zmiany: domena, platforma lub adresy podstron.
• Kontakt do osoby, która wdraża nową wersję.
• Informacja, czy migracja jest dopiero planowana, czy strona działa już pod nowymi adresami.

Do analizy potrzebne będą dane o starych adresach i widoczności. Sposób udostępnienia Search Console i wersji testowej ustalamy z Twoim zespołem.

Rodzaje migracji i różnice w ryzyku

Migracja SEO to każda zmiana, po której robot Google musi ponownie ustalić, gdzie leży dawna treść. Im więcej adresów się zmienia, tym większe ryzyko spadku widoczności.

• Zmiana domeny. Wszystkie adresy dostają nowy początek. Ryzyko jest wysokie, a poprawne przekierowania to jeden z głównych warunków powodzenia, obok testów nowej strony i kontroli indeksowania.
• Zmiana protokołu z http na https. Zmienia się każdy adres, treść zostaje. Ryzyko jest mniejsze, jeśli przekierowania, canonicale i linki wewnętrzne wskazują wersję https, a certyfikat TLS jest ważny.
• Zmiana CMS lub platformy sklepu. Nowy system ma inne szablony i znaczniki, a często także inne zasady generowania adresów. Ryzyko wynika z tego, że zmienia się kod strony, a często też adresy. Trzeba sprawdzić, które adresy zostają, a które wymagają przekierowań.
• Zmiana struktury adresów. Podstrony zmieniają adresy na tej samej domenie, na przykład po zmianie nazw kategorii. Ryzyko rośnie z liczbą objętych adresów. Więcej o tym przypadku: zmiana adresów URL w tej samej domenie.
• Połączenie serwisów. Kilka domen lub sklepów trafia pod jeden adres. Trzeba rozstrzygnąć, które treści zostają, które się łączą, a które znikają.

Gdy migracja łączy kilka zmian naraz, trudniej ustalić przyczynę spadku. Jeśli da się rozdzielić je w czasie, warto to zrobić.

Inwentaryzacja adresów przed migracją

Przekierować można tylko to, o czym wiadomo, dlatego pełna lista adresów starego serwisu jest pierwszym krokiem. Żadne źródło samo nie pokazuje wszystkiego, więc łączymy kilka.

• Skanowanie serwisu. Robot idzie po linkach jak Google. Nie znajdzie podstron, do których nic nie prowadzi.
• Search Console. Raport skuteczności pokazuje adresy, które wyświetlały się w wynikach, razem z frazami. Raport stron pokazuje, co jest w indeksie.
• Mapa witryny. Pokazuje adresy zgłaszane wyszukiwarce. Adresy z mapy, których nie znalazło skanowanie, mogą wskazywać strony osierocone. Najpierw wykluczamy blokady, błędy serwera i ustawienia crawla.
• Linki zewnętrzne. Eksport z narzędzia do analizy linków pokazuje adresy, na które linkują inne strony. Adres bez wejść z wyszukiwarki może mimo to przekazywać wartość.
• Obrazy, filmy i pliki. Adresy obrazów, filmów oraz plików JavaScript i CSS też trafiają do planu, bo trzeba je przenieść tak jak resztę treści.

Z tych źródeł powstaje jedna tabela: adres, kod odpowiedzi, tytuł, linki, wyświetlenia i frazy, indeksacja. Zapisujemy też punkt startu widoczności: frazy w TOP10, widoczność domeny i cytowania w odpowiedziach ChatGPT, Gemini, Perplexity i Claude. Po migracji porównujemy z nim nowe pomiary.

Mapa przekierowań 301 jeden do jednego

Przekierowanie 301 informuje przeglądarki i roboty, że adres zmienił się na stałe. Szczegóły w tekście jak ustawić i sprawdzić przekierowanie 301. Mapa przekierowań przypisuje każdemu staremu adresowi jego odpowiednik treściowy.

1. Z listy adresów oznaczamy te, które mają linki, wyświetlenia lub pozycje.
2. Dla każdego wskazujemy odpowiednik na nowej stronie. Przy regularnym wzorze adresów wystarczy reguła, resztę mapujemy ręcznie.
3. Strony, które znikają, przekierowujemy tylko wtedy, gdy nowa witryna ma treść, która je zastępuje. Gdy takiej treści nie ma, adres zwraca kod 404 lub 410.
4. Sprawdzamy mapę skryptem: stary adres z odpowiednikiem ma zwracać 301 i kończyć na adresie z kodem 200, a adres bez odpowiednika kod 404 lub 410.

Czego unikać

• Łańcuchy przekierowań. Gdy A prowadzi do B, a B do C, robot traci czas. Przekierowanie ma prowadzić od razu na adres docelowy.
• Przekierowanie wszystkiego na stronę główną. Strona główna nie jest odpowiednikiem usuniętej podstrony, więc takie przekierowanie myli użytkowników, a Google może je potraktować jak pozorny błąd 404.
• Przekierowania 302. Kod 302 oznacza zmianę tymczasową. Migracja jest stała, więc używamy 301 albo 308.
• Pętle przekierowań. Dwa adresy wskazujące na siebie uniemożliwiają wczytanie strony.
• Pominięte warianty. Adresy z ukośnikiem i bez, z www i bez też mogą mieć linki.
• Przekierowania w JavaScripcie. Mogą się nie wykonać, dlatego przekierowanie ustawiamy na serwerze.

Jak czytać przekierowania w raporcie Search Console po migracji, opisujemy w tekście „Strona zawierająca przekierowanie”: kiedy to problem.

Test nowej wersji przed startem

Wersja testowa to kopia nowej strony pod osobnym adresem. Ma ujawnić błędy, zanim zobaczy je Google, więc najpierw musi być zamknięta przed indeksacją.

• Hasło lub dostęp tylko z wybranych adresów IP. Najpewniejsza metoda, bo robot nie zobaczy treści.
• Znacznik noindex. Dodatkowe zabezpieczenie. Trzeba go usunąć przy starcie.
• Zakaz w robots.txt. Blokuje skanowanie, ale adres może trafić do indeksu, gdy ktoś na niego zalinkuje. Przy starcie plik trzeba zmienić. Różnice opisujemy w tekście czym robots.txt różni się od noindex.

Na wersji testowej sprawdzamy:

• przekierowania z mapy, bez łańcuchów,
• adresy kanoniczne wskazujące adresy docelowe i poprawne meta robots,
• tytuły, opisy i nagłówki przeniesione ze starych stron,
• linki wewnętrzne prowadzące od razu na nowe adresy,
• dane strukturalne, mapę witryny i hreflang,
• renderowanie: czy treść jest widoczna po wykonaniu JavaScriptu,
• wydajność nowej wersji w testach. Po starcie, gdy są dane z rzeczywistych wizyt, oceniamy Core Web Vitals: LCP do 2,5 s, INP do 200 ms i CLS do 0,1 dla 75% wizyt.

Skan wersji testowej porównujemy ze skanem starej strony i szukamy adresów, które zniknęły lub zmieniły treść.

Dzień startu: lista kontrolna

1. Zrób kopię starej strony oraz plików robots.txt i mapy witryny.
2. Wdróż nową stronę i włącz przekierowania 301 z mapy.
3. Usuń blokady z wersji testowej i sprawdź robots.txt na działającej stronie.
4. Przejrzyj strony kluczowe: kod 200, poprawny canonical, brak noindex.
5. Sprawdź skryptem całą mapę przekierowań na działającym serwerze.
6. Prześlij w Search Console nową mapę witryny z adresami docelowymi.
7. Jeśli domena się zmieniła, zweryfikuj jej usługę w Search Console.

Zapisz datę startu, a przy wdrożeniu miej pod ręką programistę i osobę decydującą o odwrocie.

Pierwsze tygodnie po starcie: co monitorować

Po starcie wyszukiwarka stopniowo przetwarza przekierowania, więc wahania widoczności są normalne. Trwałe błędy trzeba odróżnić od przejściowych, dlatego kontrolujemy regularnie kilka obszarów.

• Przekierowania. Ponowne skanowanie starych adresów: czy te z odpowiednikiem zwracają 301 i kończą na kodzie 200, a pozostałe 404 lub 410.
• Błędy 404. Raport indeksowania w Search Console i logi pokazują adresy spoza mapy. Te z linkami lub wyświetleniami dopisujemy do przekierowań.
• Indeksacja. Liczba nowych adresów w indeksie ma rosnąć, a starych maleć. Gdy nowe nie wchodzą, sprawdzamy noindex, blokady w robots.txt i to, czy canonical wskazuje właściwy adres. Pojedyncze adresy sprawdzamy tak, jak opisuje tekst jak sprawdzić nowy adres w Search Console.
• Frazy w TOP10 i widoczność. Porównanie z punktem startu, osobno dla grup stron: usług, kategorii, artykułów.
• Cytowania w AI. Czy ChatGPT, Gemini, Perplexity i Claude wskazują działające adresy. Stały pomiar zapewnia monitoring obecności marki w odpowiedziach AI.

Wyniki oceniamy w grupach stron. Pojedyncze wahania pozycji są normalne. Sygnałem alarmowym jest grupa, której widoczność stale spada.

Zmiana domeny i narzędzie zmiany adresu w Search Console

1. Sprawdź nową domenę pod kątem historii: spamu i wcześniejszych kar.
2. Dodaj i zweryfikuj w Search Console starą i nową domenę.
3. Wdróż przekierowania 301 ze starej domeny na nową, adres po adresie.
4. W usłudze starej domeny w Search Console użyj narzędzia zmiany adresu i wskaż nową domenę.
5. Prześlij mapę witryny nowej domeny.
6. Zachowaj kontrolę nad starą domeną, bo przekierowania muszą działać tak długo, jak są potrzebne.

Narzędzie informuje Google o przeprowadzce, ale nie zastępuje przekierowań. Nie używa się go przy przejściu z http na https ani przy przenoszeniu podstron w obrębie tej samej domeny.

Po zmianie domeny aktualizujemy też wizytówkę w Google, katalogi firm, profile w mediach i dane organizacji w schema.org, żeby wyszukiwarka i asystenci AI powiązali nową domenę z tą samą marką.

Pełną listę kroków, z wymaganiami narzędzia zmiany adresu i tym, ile może trwać powrót pozycji, opisujemy w tekście Zmiana domeny a pozycjonowanie.

Co zrobić, gdy widoczność spadła po migracji

1. Ustal zakres. Porównaj widoczność i indeksację przed migracją i po niej w grupach stron.
2. Sprawdź blokady. Częste przyczyny to noindex lub zakaz w robots.txt przeniesione z wersji testowej oraz canonicale wskazujące stare adresy.
3. Zweryfikuj przekierowania. Sprawdź adresy z inwentaryzacji, które mają odpowiednik, a nie kończą kodem 200. Brakujące dopisz, łańcuchy skróć.
4. Porównaj treść. Zestaw tytuły, nagłówki i teksty ważnych stron sprzed migracji i po niej. Zniknięcie fraz osłabia dopasowanie do zapytań. Więcej w tekście dlaczego poprawne przekierowania nie wyjaśniają wszystkich problemów po migracji.
5. Sprawdź linkowanie wewnętrzne. Nowy szablon mógł usunąć linki z menu lub treści.
6. Zbadaj wydajność i renderowanie. Nowa platforma mogła pogorszyć Core Web Vitals albo przenieść treść do skryptów.
7. Naprawiaj od tego, co ma największy wpływ. Najpierw blokady i brakujące przekierowania, potem treści i linkowanie.

Po naprawach prosimy Google o ponowne zindeksowanie najważniejszych adresów i obserwujemy te same wskaźniki co przed migracją. Tempo powrotu widoczności zależy od serwisu, więc nie podajemy go z góry. Przed planowaną migracją warto zrobić audyt SEO i GEO. Zasady pracy nad widocznością opisuje strona SEO, a sklepów dotyczy SEO sklepów internetowych.

Opisz spadek po migracji