Migrację strony przygotuj od spisu obecnych adresów i decyzji, co stanie się z każdą ważną podstroną. Następnie opracuj mapę „stary URL → nowy URL”, przetestuj przekierowania i zapisz dane, z którymi porównasz wyniki po wdrożeniu. Samo uruchomienie nowej wersji nie kończy pracy: trzeba jeszcze sprawdzić dostępność treści, indeksowanie oraz działanie formularzy i pomiaru. Poniżej znajdziesz wzór mapy i kolejność kontroli, którą możesz wykorzystać przy odbiorze prac.
Najważniejsze informacje w skrócie
- Zmiana hostingu przy zachowaniu adresów wymaga innego planu niż zmiana domeny, struktury URL-i lub systemu zarządzania treścią.
- Listę starych adresów zbierz z kilku miejsc. Skan obecnej strony nie pokaże wszystkich podstron, do których nadal prowadzą zewnętrzne linki.
- Dla każdego adresu zapisz decyzję: zachować, przenieść, połączyć treść albo usunąć bez zastępstwa.
- Trwale przenoszone podstrony kieruj do właściwych odpowiedników przez przekierowania serwerowe 301 lub 308. Nie kieruj wszystkiego na stronę główną.
- Przed startem sprawdź treści, linki wewnętrzne, blokady indeksowania, adresy kanoniczne i pomiar ważnych działań użytkowników.
- Po wdrożeniu porównuj stare i nowe adresy według mapy. Oddziel błąd analityki od rzeczywistego spadku ruchu lub liczby zapytań.
- Dobre przygotowanie ogranicza ryzyko, ale nie daje gwarancji stałych pozycji. Google może potrzebować czasu na przetworzenie zmiany. [1]
Spis treści

Inwentaryzacja URL-i
Najpierw ustal, co rzeczywiście się zmienia. Migracja strony internetowej może obejmować domenę, hosting, adresy podstron, technologię albo kilka tych elementów. CMS to system zarządzania treścią, np. WordPress. Jego wymiana może zmienić sposób generowania adresów i szablonów, nawet gdy nazwa domeny zostaje taka sama. Rutynowa aktualizacja wtyczki nie jest tym samym zadaniem co przeniesienie serwisu.
Rozpisz zakres w prostym dokumencie: „co zostaje”, „co zmieniamy” i „kto odbiera wynik”. Osobno oznacz nowy wygląd strony, przeniesienie treści oraz zmianę adresów. Jeżeli projekt tego nie wymaga, rozdziel zmianę domeny, CMS-u i całkowitą przebudowę zawartości na etapy. Google zaleca unikanie wielu dużych zmian jednocześnie. [1]
Inwentaryzacja to lista adresów wraz z informacją, dlaczego są potrzebne. Połącz następujące źródła:
- skan strony, czyli crawl: przejście narzędzia po dostępnych linkach;
- mapy strony XML oraz eksport podstron, wpisów, produktów i kategorii z CMS-u;
- raporty stron i zapytań z Google Search Console;
- raporty stron wejścia i ważnych zdarzeń z analityki;
- dane o linkach przychodzących oraz, jeśli są dostępne, logi serwera pokazujące żądania do adresów.
Przy każdej pozycji zapisz pełny URL, typ treści, odpowiedź serwera, tytuł, główny nagłówek oraz informację o indeksowaniu. Odpowiedź HTTP to kod opisujący wynik żądania: 200 oznacza poprawne dostarczenie treści, 301 trwałe przekierowanie, a 404 brak zasobu. Sam status 200 nie gwarantuje obecności strony w Google. [3]
Dodaj znaczenie biznesowe: czy podstrona prowadzi do kontaktu, sprzedaży, pobrania dokumentu czy tylko uzupełnia ofertę. Najważniejsze podstrony oznacz do ręcznego odbioru. Brak kliknięć w krótkim okresie nie wystarcza, by uznać adres za zbędny. Może obsługiwać sezonową usługę, mieć wartościowe odnośniki albo wspierać klienta po zakupie.
Zapisz punkt odniesienia przed zmianą. W Search Console wyeksportuj kliknięcia, wyświetlenia, CTR i średnią pozycję, zachowując daty oraz filtry kraju, urządzenia i typu wyszukiwania. Raport pozwala analizować dane według stron i zapytań. [4] Praktycznie warto porównywać pełne tygodnie i, przy sezonowym biznesie, analogiczny okres poprzedniego roku, jeśli takie dane są dostępne. To propozycja organizacji pomiaru, nie uniwersalny próg oceny migracji.
W analityce zanotuj ruch organiczny i zdarzenia istotne dla firmy, a poza nią liczbę rzeczywistych zapytań lub zamówień. Własny CRM czy panel sprzedaży pomaga zweryfikować, czy zgłoszenia docierają. W projekcie o małym ruchu nie oceniaj efektu na podstawie jednego dnia ani pojedynczej konwersji.
Mapa stary nowy
Mapa opisuje decyzję dla każdego starego adresu. Nie musi być skomplikowana: wystarczy tabela, którą rozumieją właściciel firmy, wykonawca i osoba odbierająca SEO. Jeden wiersz powinien jednoznacznie wskazywać oczekiwany rezultat, osobę odpowiedzialną i wynik testu.
Poniższy przykład jest hipotetyczny. Skrócone ścieżki służą czytelności; w roboczej mapie wpisuj pełne adresy z protokołem i domeną.
| Stary adres | Decyzja | Adres docelowy | Oczekiwany wynik |
|---|---|---|---|
/kontakt/ |
Zachować | /kontakt/ |
200, bez nowego przekierowania |
/oferta/projekt-www/ |
Przenieść | /uslugi/strony-www/ |
301 → 200, ta sama usługa |
/poradnik-a/ i /poradnik-b/ |
Połączyć treści | /poradnik-kompletny/ |
Każdy stary URL: 301 → 200 |
/pliki/instrukcja.pdf |
Przenieść plik | /do-pobrania/instrukcja.pdf |
301 → 200, właściwy PDF |
/wydarzenie-wycofane/ |
Usunąć bez odpowiednika | Brak | 404 lub 410 |
Do takiej tabeli dodaj kolumny: priorytet, powód decyzji, status wdrożenia, faktyczny adres końcowy, wynik kontroli treści i data testu. Przy łączeniu poradników potwierdź, że nowy materiał rzeczywiście obejmuje ich zagadnienia. Podobny tytuł nie jest wystarczającym dowodem zgodności.
Przekierowanie prowadzi użytkownika i roboty do innego adresu. Przy trwałej zmianie URL-a Google zaleca przekierowanie po stronie serwera; kody 301 i 308 oznaczają trwałe przeniesienie. Przekierowania tymczasowe, np. 302, komunikują inny zamiar. [2] Dla zwykłych podstron informacyjnych najczęściej spotkasz 301. Reguły powinien wdrożyć wykonawca w warstwie odpowiedniej dla serwera, aplikacji lub platformy.
Przy odbiorze otwórz stary adres i sprawdź cały przebieg żądania. Preferowany wynik to jeden skok do końcowej, działającej podstrony. Jeżeli stary URL prowadzi przez wersję HTTP, wariant www i kolejny dawny adres, uprość drogę do aktualnego celu. Sprawdź również, czy reguły nie tworzą pętli, w której dwa adresy odsyłają do siebie.
Nie używaj strony głównej jako automatycznego celu dla wszystkich usuniętych podstron. Google ostrzega przed masowymi przekierowaniami do niepowiązanej treści, które mogą zostać uznane za soft 404. [1] Gdy odpowiednika nie ma i usunięcie jest świadome, poprawna odpowiedź 404 lub 410 informuje o niedostępności zasobu. Strona z komunikatem „nie znaleziono”, zwracająca 200, może zostać rozpoznana jako soft 404. [3]

Sprawdź też starsze przekierowania istniejące przed projektem. Mogą prowadzić do adresów, które właśnie usuwasz. Zachowanie ciągłości adresów URL oznacza również obsługę tych wcześniejszych wejść. Warianty z parametrami oceń oddzielnie: nie usuwaj automatycznie parametrów, które wybierają produkt, język lub konkretną treść.
Zaktualizuj linki wewnętrzne do adresów docelowych. Uporządkuj też canonical, czyli wskazanie preferowanego adresu treści. Linkowanie, mapa XML i deklaracje canonical powinny być spójne; canonical nie przenosi użytkownika tak jak przekierowanie. Google zaleca linkowanie do wersji kanonicznej. [5]
Kontrola przed uruchomieniem
Przed startem potrzebujesz dowodów, że nowa strona działa poprawnie. Zrzut ekranu strony głównej nie wystarczy do odbioru migracji. Ustal listę krytycznych adresów i scenariuszy oraz osobę podejmującą decyzję o uruchomieniu.
Przygotuj kopię plików strony, bazy danych, konfiguracji i reguł przekierowań stosownie do użytej technologii. Sprawdź możliwość odtworzenia kopii zapasowej. W sklepie lub aplikacji zapisującej zgłoszenia uzgodnij także sposób synchronizacji nowych danych. Powrót do starej kopii bez tego ustalenia może pominąć zamówienia przyjęte już po przełączeniu.
Poniższą listę wykorzystaj jako warunki odbioru technicznego:
- Treść i szablony. Najważniejsze podstrony zachowują potrzebne informacje, tytuły i nagłówki. Menu, formularze, koszyk oraz pobieranie plików działają na telefonie i komputerze.
- Adresy. Każda pozycja mapy ma wdrożoną decyzję. Cele przekierowań dostarczają właściwą treść. Nie ma odnośników do środowiska testowego.
- Indeksowanie. Publiczne podstrony przeznaczone do wyszukiwarki nie mają przypadkowego
noindexani blokady pobierania. Kontroluj zarówno kod HTML, jak i nagłówek HTTPX-Robots-Tag.noindexdziała dopiero wtedy, gdy robot może odczytać tę regułę; blokada w robots.txt może to uniemożliwić. [6] - Spójność sygnałów. Linki wewnętrzne, canonical i mapa strony XML wskazują aktualne adresy. Przy wersjach językowych sprawdź również odnośniki między wersjami.
- Pomiar. Analityka działa na właściwej usłudze i nie zlicza zdarzeń podwójnie. Sprawdź wysłanie formularza lub testowy zakup oraz odbiór danych w systemie firmy.
- Infrastruktura. Domena ma poprawny certyfikat HTTPS, a strona na nowym serwerze obsługuje obciążenie. Jeśli zmieniasz hosting, sprawdź konfigurację i plan przełączenia DNS, czyli systemu kierującego domenę na serwer. Stary hosting wyłącz dopiero po potwierdzeniu obsługi ruchu przez nowe środowisko. [7]
Środowisko testowe udostępnij wyłącznie osobom pracującym przy wdrożeniu. Przed publikacją przygotuj docelową konfigurację dostępu i indeksowania, zamiast liczyć na pamięć osoby przełączającej stronę. Gdy nowa wersja ma zastąpić publiczną, ponownie sprawdź te ustawienia już pod docelową domeną.
W Google Analytics 4 użyj DebugView po włączeniu trybu debugowania, aby zobaczyć zdarzenia podczas testu. Uwzględnij stan zgód użytkownika: ograniczenia prywatności lub brak zgody na cookies analityczne mogą wpływać na widoczność zdarzeń w tym widoku. [8] Równolegle sprawdź, czy zgłoszenie rzeczywiście dotarło do skrzynki lub CRM-u. Rejestracja kliknięcia przycisku nie dowodzi dostarczenia formularza.
W dniu zmiany zapisz godzinę wdrożenia, wersję mapy i listę wykonanych testów. Ustal, jakie awarie wstrzymują start lub wymagają wycofania zmiany, np. niedziałający zakup czy brak kluczowej części oferty. Nie utożsamiaj takiego planu awaryjnego z automatycznym powrotem do starej wersji po każdym wahnięciu pozycji.

Monitoring po migracji
Po uruchomieniu rozpocznij od testów technicznych i biznesowych. Nie czekaj na wykres ruchu, jeśli formularz nie wysyła zgłoszeń albo ważna podstrona zwraca błąd serwera. Poniższy harmonogram jest propozycją pracy redakcji; jego częstotliwość dopasuj do wielkości serwisu, sprzedaży i skali zmiany.
| Moment kontroli | Co sprawdzić | Co zapisać |
|---|---|---|
| Bezpośrednio po starcie | Krytyczne URL-e, przekierowania, dostęp, formularze lub zakup, analityka | Wynik każdego scenariusza i godzinę testu |
| W pierwszych dniach | Błędy 404/5xx, logi, działanie reguł, indeksowanie i przyjmowanie zgłoszeń | Nowe problemy, priorytet, właściciela i poprawkę |
| W kolejnych tygodniach | Ruch i widoczność par stary–nowy, zapytania, zdarzenia i wyniki biznesowe | Porównanie z punktem odniesienia oraz dalsze decyzje |
Prześlij aktualną mapę strony w Search Console. W przypadku zmiany domeny lub subdomeny sprawdź możliwość użycia narzędzia „Zmiana adresu” po wdrożeniu przekierowań. Nie stosuje się go do samego przejścia HTTP → HTTPS, zmiany ścieżek w obrębie domeny, przełączania www ani wymiany hostingu bez zmiany URL-i. [9]
Rozdziel kontrolę bieżącego działania od sprawdzenia indeksu. Inspekcja adresu URL w Search Console pokazuje informacje o wersji znanej Google, a test aktualnego URL-a pomaga ocenić dostępność obecnej wersji. Pozytywny test nie gwarantuje indeksowania. Wybrany przez Google adres kanoniczny sprawdza się w danych indeksowanej wersji, nie przewiduje go test na żywo. [10]
Analizuj odpowiadające sobie treści. Jeśli oferta przeniosła się pod nowy adres, sam spadek kliknięć starego URL-a jest niepełnym obrazem. Zestaw jego wyniki z wynikami następcy. Przy zmianie domeny obserwuj obie właściwości Search Console. Zachowuj te same filtry i porównywalne okresy, a strony usługowe, poradniki i produkty analizuj oddzielnie.
Gdy zobaczysz spadek, wybierz ścieżkę diagnozy:
- Spadają dane w analityce, ale kliknięcia z Google i zgłoszenia są stabilne: sprawdź tagi, zgody i definicje zdarzeń, zanim przypiszesz problem SEO.
- Nie docierają formularze lub zamówienia: przetestuj proces od wejścia na stronę do odbioru w systemie firmy, niezależnie od pozycji.
- Problem dotyczy jednej grupy adresów: porównaj jej przekierowania, treść, linki i ustawienia szablonu ze stronami działającymi poprawnie.
- Widać problemy w całym serwisie: zacznij od dostępności, odpowiedzi serwera i blokad indeksowania, potem sprawdź kolejne sygnały.
Są to hipotezy do sprawdzenia, nie diagnoza wynikająca z samego wykresu. Zestawienie danych technicznych, wyszukiwania i sprzedaży pozwala lepiej ustalić kolejność działań.
Nie usuwaj przekierowań zaraz po pojawieniu się nowych adresów w wynikach. Google zaleca utrzymywanie ich możliwie długo, zasadniczo przez co najmniej rok; dla użytkowników mogą pozostać potrzebne dłużej. Przy zmianie domeny zachowaj więc możliwość obsługi starych adresów, w tym HTTPS. [1] Odbiór projektu powinien obejmować odpowiedzialność za tę obsługę.
Jeśli nowa wersja korzysta z WordPressa, przy odbiorze przyda się także poradnik o przygotowaniu strony WordPress pod SEO. Gdy potrzebujesz oceny ryzyka i kolejności poprawek, sprawdź zakres audytu SEO. Do rozmowy przygotuj listę zmian, mapę adresów i zapisane dane sprzed migracji.
Gdy po przeniesieniu adres nie pojawia się w wyszukiwarce, przejdź przez diagnostykę indeksowania strony w Google.
FAQ
Czy zmiana hostingu zawsze wymaga mapy przekierowań?
Nie. Jeśli protokół, domena, ścieżki i parametry identyfikujące treść pozostają takie same, nie ma nowych adresów, do których trzeba przekierować podstrony. Potrzebujesz jednak inwentaryzacji do testów oraz przeniesienia istniejących reguł. Kontrola nowego hostingu obejmuje działanie strony i ruch po przełączeniu DNS. [7]
Jak uwzględnić PDF-y i obrazy w migracji?
Dodaj je do inwentaryzacji jako osobne zasoby, zwłaszcza jeśli mają wejścia lub linki. Google wprost uwzględnia obrazy i pliki do pobrania w przygotowaniu migracji. [1] Sprawdź ścieżki używane w treści, możliwość pobrania pliku oraz odpowiedniki dla zmienionych adresów. Przy odbiorze otwórz dokument: poprawny kod odpowiedzi nie dowodzi, że przeniesiono właściwą wersję.
Jak postąpić, gdy stare adresy nie mają odpowiedników?
Najpierw potwierdź, że treść ma zniknąć. Jeśli nadal odpowiada na potrzebę klientów, możesz ją zachować lub stworzyć właściwego następcę. Gdy została świadomie usunięta bez zamiennika, zastosuj 404 albo 410. [3] Przygotuj pomocną stronę błędu z nawigacją, ale nie zastępuj tym kodu HTTP ani nie udawaj dopasowania przez przekierowanie do przypadkowej kategorii.
Źródła
- Google Search Central — How to move a site.
- Google Search Central — Redirects and Google Search.
- Google Crawling Infrastructure — How HTTP status codes affect Google's crawlers.
- Google Search Console — Performance report: overview and basic setup.
- Google Search Central — How to specify a canonical URL.
- Google Search Central — Block Search indexing with noindex.
- Google Search Central — Changing your hosting.
- Google Analytics — Monitor events in DebugView.
- Google Search Console — Change of Address tool.
- Google Search Console — URL Inspection tool.