Tutoriale

Migracja strony bez utraty pozycji w Google: od listy adresów do monitoringu

Inwentaryzacja starych adresów, mapa przekierowań 301, testy przed przełączeniem, zmiana domeny w Search Console i to, co obserwować przez kolejne tygodnie

DualFroz - VulCode CEO·3 września 2026·20 min czytania

Po przebudowie strony pozycje w Google tracą najczęściej adresy, których nikt nie wpisał do mapy przekierowań: stary wpis na blogu, do którego od lat linkuje portal branżowy, PDF z cennikiem, podstrona oferty z parametrem w adresie. Migracja strony bez utraty pozycji to przede wszystkim praca na liście adresów. Konfiguracja serwera jest na końcu i zajmuje najmniej czasu.

Trzeba też uczciwie powiedzieć, czego się spodziewać. Google w przewodniku po przenoszeniu witryn pisze, że widoczność w wynikach może się w trakcie przeprowadzki chwilowo wahać i że to normalne, a przy średniej wielkości stronie pokazanie nowych adresów zamiast starych może zająć kilka tygodni lub dłużej. Dobra migracja nie eliminuje tego okresu, ale usuwa przyczyny, przez które strona po nim zostaje niżej na stałe.

W skrócie

Zbierz stare adresy z kilku źródeł naraz: mapy strony, Search Console, analityki, logów serwera i bazy CMS-a. Każde źródło wyłapuje coś, czego nie widzą pozostałe.
Każdy stary adres przekierowuj przekierowaniem 301 albo 308 na najbliższy odpowiednik. Adresy bez odpowiednika mają zwracać 404 lub 410, a nie prowadzić na stronę główną.
Przetestuj całą mapę skryptem przed przełączeniem i po nim. Przekierowania zostaw co najmniej na rok, a najlepiej na zawsze.
Przy zmianie domeny użyj narzędzia zmiany adresu w Search Console dla wszystkich wariantów domeny, także z www i bez.
Zmieniaj jedną rzecz naraz. Domena, CMS i nowy układ strony w jednym dniu to trzy możliwe przyczyny spadku i żadnego sposobu, żeby je odróżnić.

Rodzaje migracji strony i co każda zmienia dla Google

"Migracja" obejmuje bardzo różne zmiany, a od rodzaju zależy, ile pracy wymaga po stronie SEO. Rozstrzyga jedno pytanie: czy adresy widoczne dla użytkownika się zmieniają. Jeśli nie, dla Google zmienia się niewiele. Jeśli tak, każdy stary adres potrzebuje przekierowania.

Zmiana	Czy adresy się zmieniają	Co jest potrzebne
Nowy hosting albo CDN	Nie	Obniżony TTL w DNS przed przenosinami, stary serwer włączony do czasu, aż przestanie dostawać ruch
Przejście z HTTP na HTTPS	Tak, zmienia się protokół	Przekierowania 301 z każdego adresu http na odpowiednik https, bez narzędzia zmiany adresu
Nowa struktura adresów w tej samej domenie	Tak	Pełna mapa przekierowań, nowe linki wewnętrzne, nowa mapa strony
Zmiana domeny	Tak	Mapa przekierowań, narzędzie zmiany adresu w Search Console, prośby o aktualizację linków
Nowy CMS albo przebudowa strony	Zwykle tak, bo każdy system buduje adresy po swojemu	Jak przy nowej strukturze adresów, plus sprawdzenie treści i szablonów
Połączenie kilku stron w jedną	Tak	Mapa przekierowań z każdej domeny i decyzja, które treści zostają

Sama zmiana hostingu jest najprostsza. Google w opisie przenosin infrastruktury radzi obniżyć TTL rekordów DNS do kilku godzin co najmniej tydzień wcześniej, a stary serwer wyłączyć dopiero wtedy, gdy w jego logach ruch spadnie do zera. Uprzedza też, że tuż po przenosinach Googlebot zwykle chwilowo zwalnia pobieranie, a w kolejnych dniach je zwiększa, czasem powyżej poprzedniego poziomu.

Przy każdej pozostałej zmianie liczą się adresy. Linki i sygnały, które strona zebrała przez lata, są przypięte do konkretnych adresów. Przekierowanie 301 mówi wyszukiwarce, że nowy adres przejmuje rolę starego. Bez przekierowania stary adres przestaje istnieć, a nowy startuje od zera.

Jedna zmiana naraz

Google radzi w przewodniku po migracjach, żeby zmiany planować jedna po drugiej, a nie wszystkie naraz. Jako przykład podaje dokładnie ten zestaw, który zdarza się najczęściej: nowa domena, nowy CMS i nowy układ strony. Każdą z tych zmian lepiej zrobić osobno.

Powód jest praktyczny. Jeśli po migracji ruch spadnie, a w tym samym tygodniu zmieniła się domena, struktura adresów, treść i szablon, nie da się ustalić, co zawiodło, bo każda z tych zmian mogła spowodować spadek sama. Przy zmianach rozłożonych w czasie każdy okres mówi tylko o jednej z nich.

Nie zawsze da się to zrobić podręcznikowo. Firma, która zmienia nazwę, chce mieć nową domenę i nowy wygląd w jednym dniu. Wtedy ryzyko ogranicza się na trzy sposoby:

Te same ścieżki w nowej domenie. Jeśli /uslugi/strony-www zostaje /uslugi/strony-www, tylko na innej domenie, mapa przekierowań sprowadza się do jednej reguły, a ryzyko pomyłki w mapowaniu spada do minimum.
Treść bez zmian w dniu przenosin. Teksty, tytuły i nagłówki przenosi się w pierwszej wersji tak, jak były, a przepisuje dopiero po kilku tygodniach, gdy nowe adresy są już w indeksie.
Duża strona w częściach. Google dopuszcza przenoszenie dużych witryn sekcja po sekcji. Łatwiej wtedy wykryć problem i poprawić go, zanim obejmie całą stronę.

Inwentaryzacja: lista adresów, które dziś coś znaczą

Mapa przekierowań jest tak dobra jak lista starych adresów, z której powstaje. Najczęstszy błąd to zbudowanie jej z menu albo z mapy starej strony, które pokazują stan zaplanowany, a nie adresy, które przez lata zebrały linki i ruch.

Google w przewodniku wymienia kilka źródeł listy starych adresów: mapy strony, logi serwera, analitykę, raport linków w Search Console i system zarządzania treścią. Każde z nich wyłapuje coś innego:

Źródło	Co wyłapuje	Czego nie widzi
Mapa strony XML	Adresy, które system uważa za aktualne	Stare adresy, pliki, strony usunięte z menu
Skan obecnej strony crawlerem	Wszystko, do czego prowadzą linki wewnętrzne, także pliki i obrazy	Strony, do których nic już nie linkuje
Search Console, raport skuteczności, zakładka Strony	Adresy, które mają wyświetlenia i kliknięcia w Google	Adresy bez ruchu z wyszukiwarki
Search Console, raport Linki	Strony najczęściej linkowane z zewnątrz	Adresy bez linków zewnętrznych
Analityka, strony docelowe	Wejścia z kampanii, newsletterów, mediów społecznościowych	Ruch sprzed okresu, za który masz dane
Logi serwera z ostatnich miesięcy	Każdy adres, o który ktoś pytał, także Googlebot i stare zakładki	Adresy, o które nikt ostatnio nie pytał
Baza danych CMS-a	Wszystkie opublikowane treści, także ukryte	Adresy spoza CMS-a, na przykład pliki wgrane ręcznie

Przy eksporcie z Search Console uważaj na limit. Eksport bezpośrednio z raportu jest obcięty do 1000 wierszy. Przy większej stronie więcej wierszy dostaniesz przez API Search Console. Przy okazji wyeksportuj dane z raportu skuteczności za możliwie długi okres. Po migracji będą punktem odniesienia do porównań.

Dopisz do listy rzeczy, których nie widać w żadnym raporcie, bo żyją poza stroną: adresy wydrukowane na ulotkach i w kodach QR, linki w stopkach maili, w szablonach ofert, w profilach firmy w katalogach i w aktywnych kampaniach reklamowych. Google przypomina też o zasobach osadzonych: obrazach, plikach wideo, PDF-ach, a nawet plikach JavaScript i CSS. Obrazy z dobrą pozycją w wyszukiwarce grafiki tracą ją tak samo jak podstrony.

Na końcu połącz źródła w jedną listę bez duplikatów i przy każdym adresie zapisz liczbę wejść z Google i linków z zewnątrz. Te dwie kolumny wyznaczają kolejność pracy: adresy z ruchem i linkami mapujesz ręcznie, a długi ogon bez ruchu obsługujesz regułami.

Mapa przekierowań: każdy stary adres ma swój odpowiednik

Mapa przekierowań to arkusz, w którym każdy wiersz łączy stary adres z nowym. Arkusz jest ważniejszy od konfiguracji serwera: to na nim pracują osoby, które znają treść, a serwer dostaje z niego gotowy plik.

Stary adres	Nowy adres	Decyzja
/o-nas.html	/o-firmie	301, ta sama treść
/oferta.php?id=3	/uslugi/strony-www	301, ta sama usługa pod nowym adresem
/aktualnosci/12-nowa-strona.html	/blog/nowa-strona	301, regułą dla całej sekcji
/realizacje/sklep-meblowy.html	/realizacje/sklep-meblowy	301, ta sama realizacja
/promocja-wiosna-2019.html	brak	410, treść usunięta bez odpowiednika

W prawdziwym arkuszu przydają się jeszcze kolumny z liczbą wejść, liczbą linków zewnętrznych i nazwiskiem osoby, która zatwierdziła dane mapowanie. Przy mapowaniu obowiązuje kilka zasad:

Najbliższy odpowiednik, a nie najbliższa kategoria. Stara podstrona usługi prowadzi na nową podstronę tej samej usługi. Kategoria nadrzędna to wyjście ostateczne.
Treści połączone prowadzą tam, gdzie trafiła ich zawartość. Jeśli trzy stare wpisy zostały połączone w jeden poradnik, wszystkie trzy przekierowują na ten poradnik.
Brak odpowiednika to 404 albo 410. Google w przewodniku odradza przekierowywanie wielu starych adresów na jeden niezwiązany cel, na przykład na stronę główną, a w pomocy Search Console nazywa przekierowanie na stronę główną zamiast odpowiedzi 404 pozornym błędem 404. Użytkownik dostaje wtedy stronę, której nie szukał.
Stare przekierowania też trzeba zaktualizować. Jeśli strona przechodziła już migrację, ma przekierowania z jeszcze starszych adresów. Muszą prowadzić od razu na nowe adresy, a nie na adresy, które po tej migracji same przekierowują dalej.
Parametry, wielkość liter, ukośnik na końcu. Sprawdź, w jakiej postaci stare adresy występują naprawdę: /Kontakt.html i /kontakt.html mogły działać obie, a parametry kampanii, takie jak ?utm_source=, nie powinny psuć dopasowania.

Dla Google adresy 404 i 410 są traktowane tak samo: oba mówią, że treści nie ma. 410 ma tę zaletę, że w logach i w kodzie od razu widać, że usunięcie było zamierzone, a nie jest błędem w mapie.

Przekierowania po stronie serwera: 301 albo 308, bez łańcuchów

Google rozróżnia przekierowania stałe i tymczasowe, i ta różnica ma przy migracji znaczenie:

Rodzaj	Jak traktuje go Google	Kiedy używać
301 i 308 po stronie serwera	Stałe: silny sygnał, że nowy adres ma zastąpić stary w wynikach	Każda migracja
302, 303 i 307	Tymczasowe: w wynikach zostaje stary adres	Krótkie przerwy, na przykład czasowo niedostępna strona
Meta refresh z zerowym opóźnieniem	Stałe	Gdy nie masz dostępu do konfiguracji serwera
Przekierowanie w JavaScripcie	Stałe, ale Google zaleca je tylko w ostateczności	Gdy nie da się użyć żadnej z powyższych metod

Googlebot podąża za łańcuchem do 10 przekierowań, ale Google zaleca kierowanie od razu na adres końcowy. Każdy dodatkowy krok to dodatkowe żądanie, wolniejsze wejście dla użytkownika i kolejne miejsce, w którym coś może się zepsuć.

Przy setkach adresów reguły w konfiguracji serwera powinny wczytywać się z pliku wygenerowanego z arkusza, a nie być pisane ręcznie. W nginx służy do tego dyrektywa map. Poniższa konfiguracja obsługuje zmianę domeny z example.com na example.net połączoną ze zmianą części adresów:

redirects.map

/o-nas.html                         https://www.example.net/o-firmie;
/realizacje/sklep-meblowy.html      https://www.example.net/realizacje/sklep-meblowy;
~^/aktualnosci/\d+-(.+)\.html$      https://www.example.net/blog/$1;

example.com.conf

map $uri $new_url {
    default "";
    include /etc/nginx/redirects.map;
}

map $uri $gone {
    default 0;
    /promocja-wiosna-2019.html 1;
}

map $arg_id $offer_by_id {
    default "";
    3 https://www.example.net/uslugi/strony-www;
    7 https://www.example.net/uslugi/sklepy;
}

server {
    listen 443 ssl;
    server_name example.com www.example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    location / {
        if ($gone) {
            return 410;
        }
        if ($new_url) {
            return 301 $new_url$is_args$args;
        }
        return 301 https://www.example.net$request_uri;
    }

    location = /oferta.php {
        if ($offer_by_id) {
            return 301 $offer_by_id;
        }
        return 404;
    }
}

Kilka szczegółów, które sprawdziliśmy na tej konfiguracji, zanim trafiła do tekstu:

$uri zamiast $request_uri. $uri nie zawiera parametrów, więc /o-nas.html?utm_source=newsletter trafia w ten sam wpis co /o-nas.html, a $is_args$args przenosi parametry na nowy adres. Z kluczami po $request_uri taki adres nie pasuje do niczego.
Wielkość liter. Zwykłe klucze w map są porównywane bez rozróżniania wielkości liter, więc /O-NAS.html też trafia we właściwy wpis.
Wyrażenia regularne. Wpis zaczynający się od ~ obsługuje całą sekcję jedną regułą, a przechwycona część adresu trafia w miejsce $1.
Adresy z parametrem jako identyfikatorem. Gdy o treści decydował parametr, jak w /oferta.php?id=3, osobna mapa po $arg_id przekierowuje każdą ofertę, a nieznane identyfikatory dostają 404.
Ostatnia linia w location /. Adresy spoza mapy trafiają na tę samą ścieżkę w nowej domenie. Jeśli takiej ścieżki tam nie ma, użytkownik zobaczy 404, co jest uczciwsze niż strona główna.

Przy bardzo długich adresach nginx może przy starcie zgłosić konieczność zwiększenia map_hash_bucket_size. To zwykłe ustawienie rozmiaru tablicy, a nie błąd w mapie.

Jak długo trzymać przekierowania? Google pisze: tak długo, jak to możliwe, zwykle co najmniej rok. Rok to minimum, które pozwala wyszukiwarce przenieść sygnały i ponownie pobrać treść. Linki z cudzych stron, zakładki i wydrukowane materiały nie znikną po roku, więc w praktyce przekierowania zostawia się na stałe, a starą domenę opłaca tak długo, jak ktoś z niej przychodzi.

Test mapy przekierowań przed przełączeniem

Google w przewodniku radzi przetestować przekierowania narzędziem do sprawdzania adresów URL dla pojedynczych adresów, a dla większej liczby skryptem. Poniższy skrypt czyta mapę z pliku CSV wyeksportowanego z arkusza i dla każdego wiersza sprawdza trzy rzeczy: czy stary adres zwraca 301 albo 308, czy prowadzi dokładnie tam, gdzie powinien, i czy adres docelowy odpowiada 200 bez kolejnych przekierowań.

sprawdz-przekierowania.sh · bash

#!/usr/bin/env bash
# Użycie: ./sprawdz-przekierowania.sh mapa.csv https://www.example.com
# mapa.csv: stara_sciezka,nowy_pelny_adres (bez wiersza nagłówka)
set -u
map_file="$1"
old_base="$2"
errors=0

while IFS=, read -r old_path expected || [ -n "$old_path" ]; do
  expected="${expected%#x27;\r'}"
  [ -z "$old_path" ] && continue

  read -r code target < <(curl -s -o /dev/null --max-time 15 \
    -w '%{http_code} %{redirect_url}\n' "$old_base$old_path")
  read -r final_code hops < <(curl -s -o /dev/null -L --max-redirs 10 --max-time 30 \
    -w '%{http_code} %{num_redirects}\n' "$old_base$old_path")

  if [ "$code" != "301" ] && [ "$code" != "308" ]; then
    echo "BŁĄD $old_path: kod $code zamiast 301 lub 308"
  elif [ "$target" != "$expected" ]; then
    echo "BŁĄD $old_path: prowadzi do $target zamiast $expected"
  elif [ "$hops" != "1" ] || [ "$final_code" != "200" ]; then
    echo "BŁĄD $old_path: łańcuch przekierowań ($hops), adres końcowy zwraca $final_code"
  else
    echo "OK   $old_path"
    continue
  fi
  errors=$((errors + 1))
done < "$map_file"

echo "Błędnych wierszy: $errors"
[ "$errors" -eq 0 ]

Skrypt wymaga tylko bash i curl. Linia z \r usuwa znak końca wiersza, który zostawia plik CSV zapisany w Excelu. Na mapie z błędami wynik wygląda tak:

wynik.txt

OK   /o-nas.html
OK   /oferta.php?id=3
BŁĄD /kontakt.html: kod 302 zamiast 301 lub 308
BŁĄD /blog/stary-wpis: łańcuch przekierowań (2), adres końcowy zwraca 200
BŁĄD /cennik: prowadzi do https://www.example.net/ zamiast https://www.example.net/uslugi/cennik
Błędnych wierszy: 3

Każdy z tych trzech błędów jest typowy. Pierwszy to przekierowanie tymczasowe, które bywa domyślnym wyborem we wtyczkach i panelach hostingu. Drugi to stare przekierowanie, które teraz prowadzi na adres przekierowujący dalej. Trzeci to wiersz, w którym ktoś na szybko wpisał stronę główną.

Skrypt da się uruchomić przed zmianą DNS: wystarczy na komputerze testującym dopisać do pliku /etc/hosts adres IP nowego serwera dla obu domen. Ten sam skrypt uruchamiasz po przełączeniu, już na produkcji, i po każdej zmianie konfiguracji serwera. Kod wyjścia różny od zera pozwala podpiąć go pod automatyczne sprawdzanie przy wdrożeniu.

Nowa strona przed przełączeniem: canonical, linki wewnętrzne i mapa strony

Przekierowania obsługują ludzi i roboty, które przychodzą ze starymi adresami. Nowa strona musi jeszcze sama mówić spójnie, które adresy są właściwe. Lista z przewodnika Google jest krótka:

Canonical na każdej nowej podstronie wskazuje ją samą. Ani stary adres, ani domena stagingu.
Linki wewnętrzne prowadzą prosto na nowe adresy. Link przez przekierowanie działa, ale dokłada robotowi pracy. Najczęściej zostają takie linki w treści starych wpisów zaimportowanych do nowego CMS-a.
Nowa mapa strony zawiera tylko nowe adresy. Po jej zgłoszeniu Google pozwala usunąć starą mapę, bo dalej będzie korzystać z nowej.
Wersje językowe dostają nowe adresy w hreflang. Każda wersja wskazuje nowe odpowiedniki pozostałych.
Blokady z migracji znikają. Każdy noindex i każda reguła w robots.txt potrzebna tylko na czas przenosin musi zostać zdjęta. Pozostałe punkty z dnia startu opisuje nasza lista kontrolna SEO technicznego przed startem strony.
Serwer gotowy na więcej odwiedzin robota. Google uprzedza, że po migracji pobiera nową stronę intensywniej niż zwykle.

Przy migracji na nową domenę sprawdź jeszcze, czy domena nie ma przeszłości. Google zaleca, żeby przy kupionej domenie sprawdzić w Search Console, czy nie ciążą na niej ręczne działania albo prośby o usunięcie adresów złożone przez poprzedniego właściciela.

Zmiana domeny: narzędzie zmiany adresu w Search Console

Przy przenosinach na inną domenę albo subdomenę Search Console ma narzędzie zmiany adresu. Informuje ono Google o przeprowadzce i przez 180 dni od jej rozpoczęcia przekazuje sygnały ze starej witryny do nowej, preferując nową przy wyborze stron kanonicznych. Po tym czasie Google traktuje obie witryny jako niezwiązane.

Warunki użycia są konkretne:

Musisz być właścicielem obu usług w Search Console i zarządzać nimi z tego samego konta Google.
Narzędzie działa na poziomie domeny, a nie pojedynczych katalogów.
Strona główna starej domeny musi przekierowywać 301 na stronę główną nowej.
Narzędzie trzeba uruchomić dla wszystkich wariantów starej domeny, także z www i bez oraz dla subdomen. Google dopisał to wyraźnie do przewodnika w czerwcu 2026 roku, z uwagą, że migracje domen działają najlepiej, gdy przeniesione są wszystkie warianty.

Narzędzie nie służy do przejścia z HTTP na HTTPS, do zmiany między wersją z www i bez w tej samej domenie ani do przenoszenia podstron w obrębie jednej witryny. W tych przypadkach wystarczą przekierowania i canonical.

Poza Search Console zostaje praca ręczna: prośby o aktualizację odnośników do stron z raportu Linki, zaczynając od tych, które dają najwięcej ruchu, oraz nowe adresy w profilach firmy, podpisach maili, szablonach dokumentów i kampaniach reklamowych.

Dzień przełączenia krok po kroku

Gdy mapa jest przetestowana, a nowa strona gotowa, w dniu przełączenia liczy się kolejność, bo część kroków zależy od poprzednich:

Kopia danych ze starej strony

eksport z raportu skuteczności Search Console, analityki i pełna kopia zapasowa starej strony z bazą danych.

Publikacja nowej strony

nowa strona działa pod docelowym adresem, bez blokad ze stagingu.

Włączenie przekierowań

konfiguracja z mapą przekierowań wgrana na serwer obsługujący stare adresy.

Test mapy na produkcji

skrypt z poprzedniej sekcji przechodzi bez błędów dla całej listy.

Search Console dla nowej witryny

usługa zweryfikowana, nowa mapa strony zgłoszona, najważniejsze adresy sprawdzone narzędziem do sprawdzania adresów URL.

Zmiana adresu

przy zmianie domeny narzędzie zmiany adresu uruchomione dla każdego wariantu starej domeny.

Linki zewnętrzne i kampanie

prośby o aktualizację linków wysłane, kampanie reklamowe przestawione na nowe adresy.

Analityka

sprawdzenie, czy wejścia na nowej stronie są zliczane, zanim pojawi się pytanie, gdzie zniknął ruch.

Przełączenie planuj na porę, w której zespół jest dostępny przez kolejne godziny, a nie na piątkowy wieczór. Błąd w mapie naprawia się w kilka minut, pod warunkiem że ktoś go zauważy.

Monitoring po migracji: pierwsze dni, tygodnie i miesiące

Po przełączeniu Google stopniowo zamienia stare adresy na nowe i opisuje, czego się spodziewać: liczba zindeksowanych adresów ze starej mapy strony spada, z nowej rośnie, ruch na starej witrynie maleje, a na nowej przybywa. Monitoring polega na sprawdzaniu, czy dzieje się dokładnie to, i na szybkim wyłapaniu adresów, które wypadły z tego schematu.

Kiedy	Co sprawdzać	Gdzie
Dzień przełączenia i następny	Odpowiedzi 404 i 5xx na nowej stronie, stare adresy bez przekierowania, zliczanie wejść	Logi serwera, skrypt testujący mapę, analityka w czasie rzeczywistym
Pierwszy tydzień	Czy Googlebot pobiera nowe adresy i czy serwer daje radę	Logi serwera, raport Statystyki indeksowania w ustawieniach Search Console
Tygodnie 2-8	Przechodzenie adresów do indeksu, zapytania i kliknięcia w porównaniu z okresem przed migracją	Raport Indeksowanie stron i raport skuteczności z porównaniem okresów
Miesiące 2-6	Czy ruch wrócił do poziomu sprzed migracji, czy stara domena wciąż dostaje wejścia	Raport skuteczności, logi starej domeny

W logach serwera szukaj adresów, które zwracają 404 i o które pytają ludzie albo Googlebot. Każdy taki adres to brakujący wiersz w mapie. Dopiero prawdziwy ruch pokazuje, co jeszcze było linkowane, więc dopisuj je do arkusza, generuj plik od nowa i puszczaj test.

Przy porównaniach okresów w raporcie skuteczności porównuj tygodnie do tygodni z tymi samymi dniami tygodnia, a przy stronach sezonowych także z tym samym okresem rok wcześniej. Spadek w sierpniu w porównaniu z marcem może nie mieć nic wspólnego z migracją. Ogólny monitoring nowej strony po wdrożeniu, poza SEO, opisaliśmy osobno we wpisie o tym, co obserwować po wdrożeniu.

Gdy ruch spada: jak odróżnić wahanie od błędu

Chwilowy spadek jest wpisany w migrację. Google pisze, że widoczność może się wahać i z czasem się ustabilizuje. Problem zaczyna się wtedy, gdy spadek dotyczy konkretnych stron, a nie całej witryny, albo gdy po kilku tygodniach nie widać żadnego odbicia. Wtedy objaw zwykle wskazuje przyczynę:

Objaw	Prawdopodobna przyczyna	Co sprawdzić
Spadek dotyczy kilku konkretnych stron	Brakujące albo błędne wiersze w mapie	Stare adresy tych stron w skrypcie testującym
Stare adresy wciąż w wynikach po wielu tygodniach	Przekierowania tymczasowe 302 albo stare adresy w mapie strony	Kody odpowiedzi, zawartość zgłoszonej mapy strony
Nowe adresy oznaczone jako duplikaty	Canonical wskazuje stare adresy albo domenę stagingu	Znacznik canonical w kodzie nowych podstron
Dużo pozornych błędów 404	Wiele adresów przekierowanych na stronę główną albo listę	Mapa przekierowań, wiersze z celem ogólnym
Nowa strona w ogóle nie pojawia się w wynikach	Noindex albo blokada w robots.txt przeniesione ze stagingu	Nagłówki i znaczniki meta na produkcji
Pozycje spadły mimo poprawnych przekierowań	Zmieniona treść, tytuły albo struktura nagłówków	Porównanie treści starej i nowej wersji najważniejszych podstron

Ostatni wiersz jest najtrudniejszy, bo przekierowania nie mają z nim nic wspólnego. Jeśli przy przebudowie skrócono teksty, usunięto sekcje odpowiadające na pytania klientów albo zmieniono tytuły, nowa strona może być mniej trafna na zapytania, na które stara była widoczna. Przy treści przeniesionej bez zmian tę przyczynę wykluczasz od razu.

Najczęstsze pytania o migrację strony

Jak długo utrzymywać przekierowania 301 po migracji?

Google pisze, że tak długo, jak to możliwe, zwykle co najmniej rok. W praktyce przekierowania zostawia się na stałe, bo linki z innych stron, zakładki i wydrukowane materiały nie przestają działać po roku. Przy zmianie domeny oznacza to także dalsze opłacanie starej domeny.

Czy przekierowanie 301 przenosi pozycje strony?

Przekierowanie stałe jest dla Google silnym sygnałem, że nowy adres ma zastąpić stary w wynikach. Pozycje zależą jednak także od treści. Jeśli pod nowym adresem jest ta sama treść, nowy adres przejmuje rolę starego. Jeśli treść się zmieniła, pozycje zależą od tego, jak nowa wersja odpowiada na te same zapytania.

Czy zmiana hostingu wpływa na pozycje w Google?

Sama zmiana hostingu, przy której adresy się nie zmieniają, nie wymaga przekierowań ani narzędzia zmiany adresu. Google uprzedza, że Googlebot tuż po przenosinach może chwilowo pobierać stronę wolniej, a w kolejnych dniach szybciej niż wcześniej. Znaczenie ma za to, czy nowy serwer odpowiada bez błędów: przy błędach 5xx Google zwalnia pobieranie, a gdy trwają dłużej, strony mogą wypadać z indeksu.

Czy można przekierować wszystkie stare adresy na stronę główną?

Można technicznie, ale Google to odradza, a przekierowanie na stronę główną zamiast odpowiedzi 404 nazywa pozornym błędem 404. Adres bez odpowiednika powinien zwracać 404 albo 410, a adres z odpowiednikiem prowadzić właśnie do niego.

Ile trwa, zanim pozycje wrócą po migracji?

Google podaje, że przy średniej wielkości stronie zastąpienie starych adresów nowymi w wynikach może zająć kilka tygodni lub dłużej, a przy dużych stronach jeszcze dłużej. Jeśli po dwóch, trzech miesiącach ruch dalej jest wyraźnie niższy, a przekierowania działają poprawnie, przyczyny szukaj w zmianach treści, a nie w konfiguracji.

Migracja w zakresie projektu

Migracja to osobna pozycja w zakresie nowej strony, a nie dodatek "na koniec". Lista adresów, mapa przekierowań, testy i monitoring zajmują czas, a jeśli wycena o nich milczy, nikt nie ma ich w planie. We wpisie o tym, jak czytać wycenę software house'u, pisaliśmy, że rzeczy niewymienione w zakresie wychodzą zwykle w środku projektu. Przy przebudowie strony z ruchem z Google migracja jest pierwszą z nich.

Budujemy strony od 2020 roku, a po oddaniu projektu dostajesz pełne prawa do kodu i dokumentację, więc mapa przekierowań i konfiguracja zostają u Ciebie, a nie u wykonawcy. Jak wygląda współpraca od pierwszej wiadomości do startu, opisujemy na stronie Jak pracujemy, a zakres usług jest w ofercie. Jeśli planujesz przebudowę albo zmianę domeny, napisz do nas z adresem obecnej strony.

Czy ten wpis był przydatny?

Zobacz też

19 min czytania

MVP: jak zbudować pierwszą wersję produktu i nie przepalić budżetu

19 min czytania

RODO na stronie internetowej: formularze, zgody, cookies i polityka prywatności

18 min czytania

Migracja strony bez utraty pozycji w Google: od listy adresów do monitoringu

Rodzaje migracji strony i co każda zmienia dla Google

Jedna zmiana naraz

Inwentaryzacja: lista adresów, które dziś coś znaczą

Mapa przekierowań: każdy stary adres ma swój odpowiednik

Przekierowania po stronie serwera: 301 albo 308, bez łańcuchów

Test mapy przekierowań przed przełączeniem

Nowa strona przed przełączeniem: canonical, linki wewnętrzne i mapa strony

Zmiana domeny: narzędzie zmiany adresu w Search Console

Dzień przełączenia krok po kroku

Monitoring po migracji: pierwsze dni, tygodnie i miesiące

Gdy ruch spada: jak odróżnić wahanie od błędu

Najczęstsze pytania o migrację strony

Jak długo utrzymywać przekierowania 301 po migracji?

Czy przekierowanie 301 przenosi pozycje strony?

Czy zmiana hostingu wpływa na pozycje w Google?

Czy można przekierować wszystkie stare adresy na stronę główną?

Ile trwa, zanim pozycje wrócą po migracji?

Migracja w zakresie projektu

Zobacz też

MVP: jak zbudować pierwszą wersję produktu i nie przepalić budżetu

RODO na stronie internetowej: formularze, zgody, cookies i polityka prywatności

Ile kosztuje strona internetowa w 2026: widełki i od czego zależą

Migracja strony bez utraty pozycji w Google: od listy adresów do monitoringu

Rodzaje migracji strony i co każda zmienia dla Google

Jedna zmiana naraz

Inwentaryzacja: lista adresów, które dziś coś znaczą

Mapa przekierowań: każdy stary adres ma swój odpowiednik

Przekierowania po stronie serwera: 301 albo 308, bez łańcuchów

Test mapy przekierowań przed przełączeniem

Nowa strona przed przełączeniem: canonical, linki wewnętrzne i mapa strony

Zmiana domeny: narzędzie zmiany adresu w Search Console

Dzień przełączenia krok po kroku

Monitoring po migracji: pierwsze dni, tygodnie i miesiące

Gdy ruch spada: jak odróżnić wahanie od błędu

Najczęstsze pytania o migrację strony

Jak długo utrzymywać przekierowania 301 po migracji?

Czy przekierowanie 301 przenosi pozycje strony?

Czy zmiana hostingu wpływa na pozycje w Google?

Czy można przekierować wszystkie stare adresy na stronę główną?

Ile trwa, zanim pozycje wrócą po migracji?

Migracja w zakresie projektu

Zobacz też

MVP: jak zbudować pierwszą wersję produktu i nie przepalić budżetu

RODO na stronie internetowej: formularze, zgody, cookies i polityka prywatności

Ile kosztuje strona internetowa w 2026: widełki i od czego zależą