Migracja strony bez utraty pozycji w Google: praktyczna checklista

Migracja strony może oznaczać zmianę domeny, CMS-u, hostingu, szablonu, protokołu, architektury informacji albo adresów URL. Każdy z tych wariantów ma inny poziom ryzyka, ale wspólna zasada pozostaje ta sama: Google i użytkownicy muszą bez przeszkód trafić ze starych zasobów do ich nowych odpowiedników. Ładniejszy projekt nie zrekompensuje utraconych adresów, treści i sygnałów, które wcześniej budowały widoczność.

Nie da się uczciwie zagwarantować braku jakichkolwiek wahań po migracji. Można natomiast ograniczyć ryzyko przez inwentaryzację, mapę przekierowań, środowisko testowe i regularny monitoring. Największe problemy zwykle powstają wtedy, gdy decyzje SEO są podejmowane już po publikacji nowej strony.

Najpierw określ zakres migracji

Zmiana serwera bez zmiany URL-i jest innym projektem niż przejście na nową domenę i całkowicie nową strukturę. Przed rozpoczęciem prac zapisz, które elementy się zmienią: adres domeny, protokół, katalogi, technologia, treść, nawigacja, dane strukturalne, wersje językowe i sposób pomiaru. Im więcej zmian wykonywanych jednocześnie, tym trudniej później zidentyfikować źródło spadku.

Jeśli nie ma uzasadnienia biznesowego, warto zachować dobre adresy i treści. Migracja nie jest okazją do automatycznego usunięcia starszych podstron. Strona z niewielkim ruchem może nadal mieć wartościowe linki zewnętrzne, wspierać temat całego serwisu albo odpowiadać na rzadkie, ale istotne zapytania.

Inwentaryzacja: lista wszystkich ważnych URL-i

Jedna sitemapa nie zawsze zawiera pełny obraz. Adresy trzeba zebrać z kilku źródeł: aktualnego XML sitemap, Google Search Console, narzędzia analitycznego, crawl strony, raportu linków zewnętrznych oraz systemu CMS. Warto uwzględnić pliki PDF, obrazy zdobywające ruch, strony paginacji, warianty językowe i adresy kampanii, jeżeli mają znaczenie.

Mapa powinna być zaakceptowana przed wdrożeniem. Google w oficjalnym poradniku dotyczącym przenoszenia witryny ze zmianą URL-i zaleca mapowanie starych adresów na nowe i zachowanie przekierowań wystarczająco długo. To nie jest zadanie tylko dla programisty — właściciel treści powinien potwierdzić, czy nowa podstrona rzeczywiście odpowiada tej samej potrzebie.

Przekierowania 301 bez łańcuchów i przypadkowych celów

Stałe przekierowanie powinno prowadzić ze starego URL-a bezpośrednio do właściwego nowego adresu. Łańcuch A → B → C wydłuża drogę robota i użytkownika, komplikuje diagnostykę i może z czasem pęknąć. Przed publikacją trzeba też wykryć pętle oraz cele zwracające błąd, kolejne przekierowanie lub stronę nieindeksowalną.

Masowe kierowanie usuniętych podstron na stronę główną jest złym zamiennikiem mapy. Jeżeli nie istnieje trafny odpowiednik, poprawna odpowiedź 404 lub 410 bywa bardziej zrozumiała niż przekierowanie do ogólnej oferty. Dla ważnej, nieaktualnej treści można przygotować nową stronę zbiorczą, ale powinna realnie rozwiązywać ten sam problem.

Kontrola treści i sygnałów SEO

Nowa wersja nie powinna tracić elementów, które wcześniej odpowiadały za trafność: głównego tematu, wartościowych fragmentów, nagłówków, linków wewnętrznych, opisów obrazów i danych strukturalnych. Należy porównać tytuły, meta description, H1, canonicale, hreflang, dyrektywy robots oraz status indeksowania. Canonical na każdej nowej podstronie musi wskazywać właściwy adres, nie środowisko testowe ani starą domenę.

Zmiana projektu może także pogorszyć szybkość, dostępność i obsługę urządzeń mobilnych. Przed migracją dobrze jest zapisać punkt odniesienia: wyniki najważniejszych szablonów, ruch organiczny, konwersje i zestaw monitorowanych zapytań. Nie po to, aby obiecywać identyczne liczby, ale aby szybciej wykryć nieoczekiwane różnice.

Środowisko testowe przed publikacją

Wersja testowa powinna być niedostępna dla indeksowania i przypadkowych użytkowników, ale równocześnie możliwa do pełnego crawl przez zespół QA. Przed startem trzeba sprawdzić na niej statusy, nawigację, linki wewnętrzne, formularze, wyszukiwarkę, wersje językowe, obrazy oraz zdarzenia analityczne. Blokad środowiska testowego nie wolno bezrefleksyjnie przenieść na produkcję.

Checklista przed przełączeniem

• wykonaj kopię możliwą do odtworzenia i ustal plan wycofania zmiany;
• zamroź publikację treści albo zaplanuj synchronizację ostatnich zmian;
• przetestuj pełną mapę 301 oraz najważniejsze ręczne ścieżki;
• sprawdź canonicale, robots.txt, meta robots, sitemapę i hreflang;
• potwierdź działanie formularzy, płatności, telefonu i analityki;
• ustal osobę odpowiedzialną za monitoring w dniu uruchomienia.

Dzień wdrożenia i pierwsze kontrole

Po przełączeniu należy ponownie wykonać crawl produkcji, przetestować reprezentatywną próbkę starych URL-i i sprawdzić logi serwera. Nowa sitemapa powinna zawierać tylko kanoniczne adresy zwracające 200. W Search Console warto zweryfikować własność odpowiednich domen, przesłać sitemapę i obserwować indeksowanie. Przy zmianie domeny stosuje się również właściwe narzędzia zgłoszeniowe opisane w dokumentacji Google.

Jeżeli równocześnie zmienia się hosting, trzeba obserwować błędy 5xx, czas odpowiedzi i wykorzystanie zasobów. W krytycznych godzinach nie planuj kolejnych niezależnych zmian. Prosty dziennik wdrożenia — godzina, czynność, wynik — znacznie ułatwia odnalezienie przyczyny problemu.

Monitoring po migracji

Przez pierwsze dni kontrole powinny być częstsze, później można przejść do rytmu tygodniowego i miesięcznego. Porównuj kliknięcia, wyświetlenia, indeksowanie oraz konwersje z odpowiednim okresem, pamiętając o sezonowości. Osobno obserwuj stare adresy zwracające 404, przekierowania, które nie prowadzą do końcowego 200, oraz nowe strony bez linków wewnętrznych.

Niewielkie wahania nie muszą oznaczać awarii. Alarmem jest trwały spadek obejmujący konkretne katalogi, szybki wzrost błędów, usunięcie dużej grupy stron z indeksu albo brak konwersji po zmianie. Wtedy potrzebna jest diagnoza na poziomie szablonu, przekierowań i treści, a nie kolejna pochopna przebudowa.

Kiedy zaangażować specjalistę

Przy zmianie domeny, dużym serwisie, wielu wersjach językowych lub utrwalonym ruchu organicznym warto zaplanować SEO jeszcze przed pracami deweloperskimi. Audyt SEO WebHeaven może uporządkować ryzyka, a przy zmianie technologii pomocna będzie konsultacja zakresu strony WordPress albo bardziej złożonego portalu internetowego.