Migracja strony a SEO – jak nie stracić pozycji i ruchu z Google?

Migracja strony internetowej może poprawić szybkość, użyteczność, bezpieczeństwo i możliwości rozwoju serwisu. Źle przygotowana zmiana może jednak doprowadzić do utraty widoczności, spadku ruchu organicznego, problemów z indeksacją oraz pojawienia się setek błędów 404.

Ryzyko jest szczególnie wysokie, gdy migracja obejmuje zmianę domeny, struktury adresów URL, systemu CMS albo połączenie kilku serwisów. Google musi wtedy ponownie odnaleźć strony, odwiedzić stare i nowe adresy, przetworzyć przekierowania oraz przenieść sygnały do nowych URL-i.

Prawidłowo zaplanowana migracja strony SEO pozwala ograniczyć wahania widoczności i zachować zgromadzony potencjał domeny. Nie oznacza to, że pozycje pozostaną całkowicie niezmienne. Google oficjalnie informuje, że podczas istotnych zmian mogą wystąpić przejściowe wahania, ponieważ wyszukiwarka musi ponownie zeskanować i zindeksować witrynę.

W przypadku małej lub średniej strony przeniesienie większości adresów w indeksie może potrwać kilka tygodni. Duże serwisy potrzebują zwykle więcej czasu. Tempo zależy m.in. od liczby URL-i, szybkości serwera i sprawności wdrożonych przekierowań.

Co to jest migracja strony internetowej?

Migracja serwisu to istotna zmiana techniczna lub strukturalna wpływająca na sposób działania strony, jej adresy, infrastrukturę albo zawartość.

Może obejmować:

• zmianę domeny,
• przejście z HTTP na HTTPS,
• zmianę systemu CMS,
• zmianę hostingu,
• przebudowę struktury adresów URL,
• połączenie kilku domen,
• podział jednego serwisu na kilka,
• zmianę wersji językowych,
• przeprojektowanie strony,
• przeniesienie sklepu na inną platformę,
• zmianę subdomeny na katalog,
• zmianę katalogu na subdomenę.

Nie każda migracja wiąże się ze zmianą adresów URL. Przeniesienie strony na nowy hosting może zachować identyczne adresy, ale nadal wymaga kontroli wydajności, DNS, dostępności serwera i blokad indeksowania.

Rodzaje migracji strony a SEO

Migracja domeny

Migracja domeny polega na przeniesieniu serwisu, np.:

staradomena.pl → nowadomena.pl

Jest to jedna z najbardziej wymagających zmian, ponieważ każdy adres otrzymuje nową domenę.

Trzeba wtedy:

• przygotować mapę starych i nowych URL-i,
• wdrożyć przekierowania 301,
• zweryfikować obie domeny w Google Search Console,
• przesłać zmianę adresu,
• zaktualizować canonicale,
• przygotować nową mapę witryny,
• zmienić linki wewnętrzne i zewnętrzne,
• monitorować indeksowanie obu domen.

Szczególnej ostrożności wymaga zakup domeny mającej wcześniejszą historię. Przed jej wykorzystaniem warto sprawdzić, jakie treści znajdowały się na niej wcześniej, jakie linki do niej prowadzą i czy nie była używana do działań spamerskich. Pomocny będzie poradnik Jak sprawdzić historię domeny przed zakupem?.

Zmiana struktury adresów URL

Przykład:

sklep.pl/index.php?id=234

zostaje zastąpiony przez:

sklep.pl/kategoria/nazwa-produktu/

Nowe adresy mogą być czytelniejsze, ale ich wdrożenie wymaga dokładnego mapowania. Każdy stary URL generujący ruch, wyświetlenia lub linki powinien prowadzić do najbardziej odpowiedniego nowego adresu.

Nie wolno zakładać, że Google samodzielnie połączy stare i nowe wersje wyłącznie na podstawie podobieństwa treści.

Zmiana systemu CMS

Migracja z jednego systemu na drugi może powodować zmiany:

• adresów URL,
• title i meta description,
• nagłówków,
• canonicali,
• danych strukturalnych,
• paginacji,
• filtrów,
• map witryny,
• pliku robots.txt,
• linkowania wewnętrznego,
• sposobu renderowania treści.

Nawet jeśli wygląd strony pozostaje podobny, nowy CMS może wygenerować całkowicie inną strukturę techniczną.

Przed uruchomieniem należy porównać obie wersje i sprawdzić, czy podczas przenoszenia nie zniknęły istotne elementy.

Zmiana hostingu bez zmiany URL-i

Przeniesienie na nowy serwer jest zwykle mniej ryzykowne niż zmiana domeny, ale również może wpłynąć na widoczność.

Problemem mogą być:

• błędne rekordy DNS,
• zbyt długi czas propagacji,
• wolniejszy serwer,
• błędy 5xx,
• blokowanie Googlebota,
• brak certyfikatu SSL,
• utrata pliku weryfikacyjnego Search Console,
• pozostawienie blokady robots.txt,
• nieprawidłowe wersje plików i bazy danych.

Google informuje, że po zmianie hostingu może nastąpić tymczasowy spadek częstotliwości crawlowania, a następnie stopniowy wzrost aktywności Googlebota. Jeżeli nowa infrastruktura działa poprawnie, sytuacja powinna się ustabilizować.

Przejście z HTTP na HTTPS

Zmiana:

http://domena.pl/

na:

https://domena.pl/

jest dla Google migracją adresów URL.

Należy:

• wdrożyć certyfikat SSL,
• przekierować wszystkie wersje HTTP na HTTPS,
• zmienić canonicale,
• zaktualizować mapę witryny,
• poprawić linki wewnętrzne,
• usunąć zasoby ładowane po HTTP,
• zweryfikować nowe warianty w Search Console,
• zaktualizować narzędzia analityczne i reklamowe.

Dla migracji z HTTP do HTTPS nie korzysta się z narzędzia zmiany adresu w Google Search Console.

Połączenie kilku serwisów

Łączenie domen może przynieść korzyści, jeżeli treści są podobne, a marki mają zostać skonsolidowane. Jest to jednak skomplikowany proces wymagający decyzji, które strony:

• zostaną przeniesione,
• zostaną połączone,
• wymagają przekierowania,
• powinny zostać usunięte,
• nie mają odpowiednika.

Nie należy przekierowywać każdego adresu ze starego serwisu na stronę główną domeny docelowej. Przekierowania muszą prowadzić do tematycznie odpowiadających stron.

Czy migracja strony powoduje spadki pozycji?

Migracja może powodować przejściowe wahania. Jest to naturalne, ponieważ Google musi ponownie przetworzyć strukturę serwisu.

Skala i czas trwania spadku zależą od:

• wielkości witryny,
• rodzaju migracji,
• poprawności przekierowań,
• szybkości serwera,
• liczby zmienionych elementów,
• linkowania wewnętrznego,
• częstotliwości crawlowania,
• jakości nowej wersji,
• dostępności treści,
• liczby błędów.

Dobrze przeprowadzona migracja nie powinna prowadzić do trwałej utraty widoczności wyłącznie dlatego, że zastosowano przekierowania 301. Google wskazuje, że trwałe przekierowania, w tym 301, nie powodują utraty PageRanku.

Nie oznacza to jednak, że można dowolnie zmieniać strukturę bez konsekwencji. Straty mogą wynikać z błędnego mapowania, usunięcia wartościowych treści, pogorszenia jakości albo problemów technicznych.

Najważniejsza zasada: nie zmieniaj wszystkiego jednocześnie

Jednym z najczęstszych błędów jest jednoczesna:

• zmiana domeny,
• zmiana CMS-a,
• przebudowa wyglądu,
• zmiana treści,
• zmiana struktury URL-i,
• usunięcie kategorii,
• modyfikacja nawigacji.

Jeżeli po uruchomieniu pojawi się spadek, trudno wtedy określić jego przyczynę.

Google zaleca wprowadzanie dużych zmian kolejno. Jeżeli firma chce zmienić domenę, CMS i wygląd strony, bezpieczniej rozdzielić te procesy, o ile jest to technicznie i biznesowo możliwe.

Każda dodatkowa zmiana zwiększa liczbę elementów, które mogą wpłynąć na indeksowanie oraz sposób oceny serwisu.

Jak przygotować migrację strony?

1. Określ zakres migracji

Na początku trzeba dokładnie ustalić:

• co się zmienia,
• które adresy pozostają bez zmian,
• które adresy zostaną zastąpione,
• które treści będą usunięte,
• czy zmienia się domena,
• czy zmienia się hosting,
• czy zmienia się CMS,
• czy zmienia się wersja językowa,
• czy serwis zostanie połączony z inną domeną.

Zakres powinien zostać zapisany i zaakceptowany przed rozpoczęciem wdrożenia.

2. Zbierz dane przed migracją

Bez zapisania stanu początkowego trudno później ocenić skutki.

Należy zebrać:

• wszystkie adresy URL,
• kody odpowiedzi,
• title i meta description,
• nagłówki H1,
• canonicale,
• dyrektywy robots,
• dane strukturalne,
• linki wewnętrzne,
• mapy witryny,
• ruch organiczny,
• kliknięcia i wyświetlenia,
• pozycje fraz,
• konwersje,
• linki zewnętrzne,
• najważniejsze strony docelowe.

Warto wykonać pełny crawl starej strony i zachować raport. Powinien on stanowić punkt odniesienia po uruchomieniu nowej wersji.

3. Wskaż najważniejsze podstrony

Nie wszystkie adresy mają taką samą wartość. Szczególnej ochrony wymagają strony:

• generujące największy ruch,
• zdobywające najwięcej wyświetleń,
• przynoszące konwersje,
• mające linki zewnętrzne,
• zajmujące wysokie pozycje,
• ważne dla sprzedaży,
• pełniące funkcję głównych kategorii lub usług.

Listę można przygotować na podstawie Google Search Console, systemu analitycznego, danych sprzedażowych oraz narzędzi do analizy linków.

4. Przygotuj środowisko testowe

Nowa wersja strony powinna zostać przetestowana przed uruchomieniem.

Środowisko testowe nie powinno trafiać do wyników Google. Można zabezpieczyć je hasłem albo ograniczeniem dostępu. Jeżeli zastosowano noindex lub blokadę robots.txt, przed migracją trzeba przygotować procedurę ich usunięcia.

Jednym z najgroźniejszych błędów jest uruchomienie nowej strony z pozostawionym:

<meta name="robots" content="noindex">

albo:

User-agent: *
Disallow: /

Taka blokada może odciąć Google od całego serwisu.

5. Przeprowadź crawl wersji testowej

Crawler powinien sprawdzić:

• kody odpowiedzi,
• title,
• meta description,
• H1,
• canonicale,
• noindex,
• robots.txt,
• linki wewnętrzne,
• błędy 404,
• przekierowania,
• obrazy,
• pliki PDF,
• dane strukturalne,
• paginację,
• hreflang,
• wersję mobilną,
• zasoby JavaScript i CSS.

Dane należy porównać ze starą wersją.

Mapa przekierowań – podstawa bezpiecznej migracji

Jeżeli adresy się zmieniają, trzeba przygotować dokładną mapę:

Każdy stary adres powinien zostać przypisany do jednej z kategorii:

1. pozostaje bez zmian,
2. przenosi się do odpowiadającego nowego URL-a,
3. łączy się z inną treścią,
4. zostaje usunięty bez zamiennika,
5. nie powinien być dostępny publicznie.

Przekierowania jeden do jednego

Najlepszą praktyką jest przekierowanie starego adresu do najbardziej odpowiadającej nowej strony.

Przykład:

/stara-oferta/audyt-seo/

powinien prowadzić do:

/oferta/audyt-seo-strony/

Nie powinien być kierowany do strony głównej tylko dlatego, że nowy serwis nie ma identycznej struktury.

Google ostrzega, że masowe przekierowanie wielu niepowiązanych URL-i do jednego nietrafnego miejsca może zostać potraktowane jak soft 404.

Wyjątkiem jest sytuacja, w której kilka podobnych stron zostało świadomie połączonych w jeden kompleksowy materiał. Wtedy wszystkie stare URL-e mogą prowadzić do nowej, skonsolidowanej strony.

Jakiego rodzaju przekierowania stosować?

Przy trwałej zmianie adresu należy wykorzystać stałe przekierowanie:

• 301,
• 308.

Najczęściej stosuje się przekierowanie 301 po stronie serwera.

Przykładowy schemat:

stary URL → 301 → nowy URL → 200

Należy unikać:

stary URL → 301 → adres pośredni → 301 → nowy URL

oraz:

URL A → URL B → URL A

Pierwszy przykład tworzy łańcuch, a drugi pętlę przekierowań.

Wszystkie linki wewnętrzne powinny po migracji prowadzić bezpośrednio do nowych adresów, a nie korzystać z przekierowań.

Jak długo utrzymywać przekierowania?

Google zaleca pozostawienie przekierowań przez co najmniej rok. W tym czasie wyszukiwarka może:

• ponownie odwiedzić stare adresy,
• przetworzyć ich nowe lokalizacje,
• przenieść sygnały,
• ponownie przypisać linki prowadzące ze stron zewnętrznych.

Z perspektywy użytkowników warto rozważyć pozostawienie przekierowań bezterminowo, szczególnie jeśli stare adresy nadal występują:

• w artykułach zewnętrznych,
• zakładkach użytkowników,
• wiadomościach,
• katalogach,
• materiałach drukowanych,
• kampaniach.

Co zrobić z usuniętymi stronami?

Nie każda stara podstrona musi mieć odpowiednik.

Jeżeli materiał został trwale usunięty i nie istnieje tematycznie dopasowana strona docelowa, URL powinien zwracać:

• 404 – nie znaleziono,
• 410 – trwale usunięto.

Nie należy przekierowywać niepowiązanych stron do:

• strony głównej,
• ogólnego bloga,
• przypadkowej kategorii,
• formularza kontaktowego.

Przekierowanie musi pomagać użytkownikowi znaleźć odpowiednik poszukiwanej zawartości.

Canonicale podczas migracji

Po uruchomieniu nowej wersji należy sprawdzić, czy znaczniki:

<link rel="canonical" href="https://domena.pl/nowy-adres/">

wskazują aktualne adresy.

Częstym błędem jest pozostawienie canonicali prowadzących do:

• starej domeny,
• środowiska testowego,
• adresów HTTP,
• starych kategorii,
• niekanonicznych parametrów.

Nowe strony powinny zazwyczaj mieć canonical wskazujący na siebie, czyli self-canonical.

Google traktuje przekierowania i rel="canonical" jako silne sygnały dotyczące preferowanego adresu. Obecność URL-a w mapie witryny jest sygnałem słabszym. Najlepszy efekt zapewnia spójność wszystkich tych elementów.

Linkowanie wewnętrzne po migracji

Samo wdrożenie przekierowań nie wystarczy. Wszystkie linki wewnętrzne należy zaktualizować tak, aby prowadziły bezpośrednio do nowych adresów.

Dotyczy to:

• menu,
• breadcrumbs,
• treści artykułów,
• opisów usług,
• kategorii,
• produktów,
• stopki,
• modułów podobnych treści,
• map HTML,
• danych strukturalnych,
• linków w grafikach.

Pozostawienie starych URL-i zwiększa liczbę przekierowań, obciąża serwer i utrudnia kontrolowanie struktury strony.

Po migracji warto przeprowadzić pełny audyt linkowania. Szczegółowe informacje znajdziesz w poradniku „Linkowanie wewnętrzne w SEO – jak zaplanować strukturę linków na stronie?”.

Aktualizacja linków zewnętrznych

Przekierowania pozwalają przenieść sygnały ze starych adresów, ale warto również zaktualizować najważniejsze linki zewnętrzne.

W pierwszej kolejności należy poprawić:

• profile w mediach społecznościowych,
• Profile Firmy w Google,
• katalogi branżowe,
• wizytówki partnerów,
• artykuły sponsorowane,
• materiały prasowe,
• kampanie reklamowe,
• newslettery,
• linki generujące duży ruch.

W przypadku ważnych publikacji zewnętrznych można skontaktować się z właścicielem serwisu i poprosić o podmianę adresu.

Mapa witryny XML po migracji

Nowa mapa XML powinna zawierać wyłącznie adresy:

• kanoniczne,
• zwracające kod 200,
• dostępne do indeksowania,
• znajdujące się w nowej domenie lub strukturze,
• wartościowe dla użytkownika.

Nie należy umieszczać w niej:

• starych URL-i,
• przekierowań,
• adresów 404,
• stron z noindex,
• duplikatów,
• niekanonicznych wariantów.

Nową mapę należy przesłać w Google Search Console. Pomaga ona Google odkrywać nowe adresy, ale nie zastępuje przekierowań ani linkowania wewnętrznego.

W przypadku dużej migracji można czasowo pozostawić również mapę starych adresów. Ułatwia to monitorowanie, czy Google odwiedza stare URL-e i przetwarza przekierowania. Docelowo główna mapa powinna zawierać nowe adresy.

Google Search Console podczas migracji

Przed zmianą należy zweryfikować w Search Console:

• starą domenę,
• nową domenę,
• wariant z www,
• wariant bez www,
• wersję HTTP,
• wersję HTTPS,
• używane subdomeny.

Najwygodniejsze jest korzystanie z usługi domenowej obejmującej wszystkie warianty, ale w konkretnych przypadkach warto zachować również właściwości prefiksu adresu URL.

Narzędzie zmiany adresu

Przy zmianie jednej domeny na inną należy zgłosić zmianę adresu w Google Search Console.

Przykład:

staradomena.pl → nowadomena.pl

Narzędzie nie zastępuje przekierowań. Przed zgłoszeniem muszą działać poprawne przekierowania ze starej domeny do nowej.

Narzędzia zmiany adresu nie używa się przy:

• przejściu z HTTP na HTTPS,
• zmianie ścieżek w tej samej domenie,
• zmianie samego hostingu,
• zmianie systemu CMS bez zmiany domeny.

Weryfikacja Search Console po zmianie

Trzeba upewnić się, że sposób weryfikacji nadal działa. Jeżeli korzystano z:

• pliku HTML,
• tagu meta,
• Google Analytics,
• Google Tag Managera,

odpowiedni element musi znaleźć się również w nowej wersji.

Nie należy usuwać starej właściwości z Search Console. Dane z obu wersji są potrzebne do monitorowania procesu.

Robots.txt i noindex

Przed uruchomieniem trzeba sprawdzić:

domena.pl/robots.txt

oraz znaczniki robots w kodzie.

Nowa wersja nie może mieć pozostawionej blokady środowiska testowego.

Szczególnie groźne są:

User-agent: *
Disallow: /

i:

<meta name="robots" content="noindex">

Po usunięciu blokad należy ponownie przetestować stronę w Search Console.

Migracja wersji językowych

Serwisy wielojęzyczne wymagają dodatkowej kontroli:

• adresów wersji językowych,
• hreflangów,
• canonicali,
• przekierowań,
• języka treści,
• linkowania pomiędzy wersjami,
• map witryn.

Hreflang powinien wskazywać nowe, działające i kanoniczne adresy. Każda wersja musi odwoływać się do siebie oraz do pozostałych odpowiedników.

Nie należy automatycznie przekierowywać użytkownika i robota do innej wersji językowej wyłącznie na podstawie lokalizacji, jeżeli uniemożliwia to dostęp do właściwego adresu.

Dane strukturalne

Podczas zmiany CMS-a lub szablonu mogą zniknąć dane strukturalne dotyczące:

• organizacji,
• produktów,
• breadcrumbs,
• artykułów,
• ofert,
• lokalnej firmy,
• filmów.

Po migracji należy sprawdzić ich obecność i poprawność. Dane muszą odpowiadać treści widocznej dla użytkownika i wskazywać aktualne adresy.

Obrazy, dokumenty i pliki PDF

Migracja powinna obejmować nie tylko strony HTML.

Ruch i linki mogą prowadzić również do:

• obrazów,
• dokumentów PDF,
• katalogów,
• instrukcji,
• plików do pobrania,
• filmów.

Jeżeli zmieniają się ich adresy, również powinny otrzymać prawidłowe przekierowania.

Szczególnie ważne są pliki generujące ruch z wyszukiwarki albo mające linki zewnętrzne.

Analityka i mierzenie konwersji

Przed migracją należy sprawdzić, czy nowa wersja zawiera:

• kod Google Analytics,
• Google Tag Manager,
• pomiar formularzy,
• śledzenie połączeń,
• pomiar sprzedaży,
• zdarzenia i konwersje,
• baner zgód,
• Consent Mode.

Brak danych po wdrożeniu może być błędnie interpretowany jako spadek ruchu SEO, mimo że problem dotyczy analityki.

W dniu migracji warto dodać adnotację w raportach lub zapisać dokładną godzinę uruchomienia.

Kiedy najlepiej przeprowadzić migrację?

Migrację warto zaplanować na okres mniejszego ruchu.

Należy unikać:

• najważniejszego sezonu sprzedażowego,
• Black Friday,
• kampanii promocyjnej,
• uruchomienia dużej oferty,
• okresu bez dostępnego zespołu technicznego,
• piątku wieczorem, jeśli nikt nie będzie monitorował wdrożenia.

Niższy ruch oznacza mniejsze ryzyko biznesowe i więcej zasobów serwera dostępnych dla Googlebota.

Jednocześnie po uruchomieniu musi być dostępny zespół zdolny szybko naprawić błędy.

Czy przenosić cały serwis jednocześnie?

Google wskazuje, że duże migracje można dzielić na etapy, jeśli jest to technicznie możliwe.

Pilotaż może objąć sekcję:

• rzadziej zmienianą,
• generującą mniejszy ruch,
• reprezentatywną technicznie,
• mniej zależną od sezonu.

Pozwala to sprawdzić:

• działanie przekierowań,
• indeksowanie,
• wydajność serwera,
• zachowanie Googlebota,
• poprawność szablonów.

Nie zawsze jednak migracja części serwisu dokładnie odzwierciedla skutki przeniesienia całej witryny. W większej skali mogą pojawić się dodatkowe problemy.

Testy przed uruchomieniem

Przed migracją trzeba sprawdzić:

Dostępność techniczną

• kody odpowiedzi,
• SSL,
• DNS,
• szybkość serwera,
• robots.txt,
• noindex,
• canonicale,
• przekierowania.

Zawartość

• kompletność treści,
• produkty i kategorie,
• obrazy,
• dokumenty,
• nagłówki,
• metadane,
• FAQ,
• dane kontaktowe.

Nawigację

• menu,
• breadcrumbs,
• filtry,
• paginację,
• wyszukiwarkę,
• wersję mobilną,
• linki wewnętrzne.

Funkcje biznesowe

• formularze,
• koszyk,
• płatności,
• logowanie,
• rejestrację,
• konfiguratory,
• zapisy.

Narzędzia marketingowe

• analitykę,
• konwersje,
• piksele reklamowe,
• tagi,
• zgody,
• integracje.

Dzień migracji – kolejność działań

Przykładowy proces może wyglądać następująco:

1. Wykonaj kopię zapasową.
2. Zapisz ostatni crawl starej strony.
3. Wstrzymaj zmiany treści.
4. Opublikuj nową wersję.
5. Usuń blokady środowiska testowego.
6. Włącz przekierowania.
7. Sprawdź stronę główną i kluczowe URL-e.
8. Przetestuj przekierowania.
9. Sprawdź robots.txt i noindex.
10. Zweryfikuj canonicale.
11. Uruchom pełny crawl.
12. Sprawdź działanie analityki.
13. Prześlij mapę witryny.
14. W razie zmiany domeny użyj narzędzia zmiany adresu.
15. Rozpocznij monitoring serwera, ruchu i indeksowania.

Co monitorować po migracji?

Kody odpowiedzi

Należy obserwować:

• błędy 404,
• soft 404,
• błędy 5xx,
• pętle przekierowań,
• łańcuchy przekierowań,
• strony zwracające niewłaściwe kody.

Google Search Console

Sprawdzaj:

• raport indeksowania,
• statystyki crawlowania,
• mapy witryn,
• ręczne działania,
• bezpieczeństwo,
• skuteczność,
• strony kanoniczne,
• konkretne adresy w narzędziu inspekcji.

Ruch i widoczność

Porównuj:

• ruch organiczny,
• kliknięcia,
• wyświetlenia,
• frazy w TOP 10,
• ruch stron ofertowych,
• ruch kategorii,
• widoczność starej i nowej domeny,
• dane rok do roku i okres do okresu.

Konwersje

Spadek ruchu nie zawsze jest jedynym problemem. Trzeba również monitorować:

• formularze,
• połączenia,
• sprzedaż,
• zapisy,
• przychody,
• mikrokonwersje.

Logi serwera

Logi pokażą:

• czy Googlebot odwiedza stare adresy,
• czy przechodzi przez przekierowania,
• jak często odwiedza nowe URL-e,
• czy napotyka błędy,
• czy nowy serwer radzi sobie z obciążeniem.

Google może po migracji intensywniej odwiedzać nowy serwis, ponieważ przetwarza jednocześnie stare i nowe adresy. Serwer powinien być przygotowany na zwiększoną liczbę żądań.

Najczęstsze błędy podczas migracji

Brak mapy starych i nowych URL-i

Automatyczne przekierowanie katalogów nie zawsze wystarczy. Struktura nowej strony może być zupełnie inna, a część podstron wymaga indywidualnego dopasowania.

Przekierowanie wszystkiego na stronę główną

Takie działanie nie zachowuje automatycznie wartości wszystkich podstron. Może zostać potraktowane jako soft 404 i jest nieprzydatne dla użytkowników.

Brak przekierowań

Stare adresy zaczynają zwracać błędy 404, mimo że mają widoczność, ruch i linki zewnętrzne.

Łańcuchy przekierowań

Po kilku migracjach może powstać schemat:

URL z 2022 → URL z 2024 → URL z 2026

Należy go skrócić:

URL z 2022 → aktualny URL

Pozostawiony noindex

Nowa wersja została opublikowana z ustawieniami środowiska testowego i znika z indeksu.

Zablokowany robots.txt

Googlebot nie może odwiedzić strony albo pobrać potrzebnych zasobów.

Canonicale do starej domeny

Nowe strony wskazują, że wersją preferowaną pozostaje stary adres.

Stare adresy w linkowaniu wewnętrznym

Cały serwis korzysta z przekierowań, mimo że linki można było bezpośrednio zaktualizować.

Usunięcie wartościowych treści

Nowy projekt jest bardziej nowoczesny wizualnie, ale zawiera znacznie mniej informacji, opisów kategorii, FAQ i treści ofertowych.

Zmiana treści i struktury jednocześnie

Google otrzymuje nowe adresy, nowy wygląd, mniej treści i inną architekturę. Trudno określić przyczynę spadków.

Nieaktualna mapa XML

Mapa zawiera stare URL-e, przekierowania, błędy albo adresy z noindex.

Niedziałająca analityka

Brak ruchu w raportach wynika z niewdrożonego kodu, a nie z rzeczywistej utraty widoczności.

Wyłączenie starego hostingu zbyt szybko

Przy zmianie samego hostingu stara infrastruktura powinna pozostać aktywna do czasu, aż ruch i zapytania przestaną do niej trafiać.

Jak długo trwa powrót pozycji po migracji?

Nie istnieje jeden termin.

Google wskazuje, że w przypadku małej lub średniej strony przetworzenie większości adresów może potrwać kilka tygodni. Duże serwisy potrzebują więcej czasu.

Na tempo wpływają:

• liczba adresów,
• szybkość serwera,
• liczba błędów,
• częstotliwość crawlowania,
• jakość mapy przekierowań,
• linkowanie wewnętrzne,
• mapa witryny,
• zakres zmian.

Migracja jest przetwarzana na poziomie poszczególnych adresów. Googlebot musi odwiedzić zarówno stare, jak i nowe URL-e.

Nie należy oceniać rezultatu wyłącznie na podstawie pierwszych kilku dni. Jednocześnie poważne błędy, takie jak blokada indeksowania czy niedziałające przekierowania, trzeba naprawiać natychmiast.

Jak odróżnić naturalne wahania od błędu?

Naturalne może być:

• stopniowe zmniejszanie liczby starych adresów,
• wzrost indeksacji nowych URL-i,
• krótkotrwała zmiana pozycji,
• czasowe obniżenie częstotliwości crawlowania,
• przenoszenie wyświetleń między domenami.

Niepokojące są:

• gwałtowny wzrost błędów 404,
• brak indeksowania nowych stron,
• canonicale do starej domeny,
• wielodniowe błędy 5xx,
• brak przekierowań,
• wyświetlanie środowiska testowego,
• utrata dużej części treści,
• zablokowanie całych katalogów,
• stale malejący ruch bez przejmowania go przez nowe URL-e.

Czy po migracji zgłaszać wszystkie adresy ręcznie?

Nie. Narzędzie inspekcji adresów URL jest przeznaczone przede wszystkim do sprawdzania pojedynczych, ważnych podstron.

Przy dużej liczbie URL-i należy wykorzystać:

• mapę witryny,
• przekierowania,
• linkowanie wewnętrzne,
• poprawną architekturę,
• stabilny serwer.

Wielokrotne zgłaszanie tych samych adresów nie przyspiesza procesu. Google informuje, że ponowne crawlowanie może potrwać od kilku dni do kilku tygodni, a samo zgłoszenie nie gwarantuje indeksacji.

Checklista migracji strony SEO

Przed migracją

• Określ zakres zmian.
• Zapisz pełną listę adresów.
• Wykonaj crawl starej strony.
• Zbierz dane z Search Console i analityki.
• Wskaż najważniejsze podstrony.
• Zbierz dane o linkach zewnętrznych.
• Przygotuj mapę przekierowań.
• Przetestuj środowisko testowe.
• Porównaj title, H1, treści i canonicale.
• Sprawdź dane strukturalne.
• Zweryfikuj wersję mobilną.
• Sprawdź wydajność nowego serwera.
• Przygotuj kopię zapasową.
• Zaplanuj termin mniejszego ruchu.

W dniu migracji

• Opublikuj nową wersję.
• Usuń noindex.
• Usuń blokady robots.txt.
• Włącz przekierowania 301.
• Sprawdź najważniejsze adresy.
• Uruchom crawl.
• Zweryfikuj canonicale.
• Przetestuj formularze i sprzedaż.
• Sprawdź analitykę.
• Prześlij nową mapę XML.
• Zgłoś zmianę domeny w Search Console, jeśli jest potrzebna.
• Monitoruj błędy serwera.

Po migracji

• Kontroluj błędy 404 i 5xx.
• Sprawdzaj przekierowania.
• Aktualizuj linki wewnętrzne.
• Popraw ważne linki zewnętrzne.
• Monitoruj indeksowanie.
• Analizuj ruch i widoczność.
• Sprawdzaj konwersje.
• Analizuj logi serwera.
• Utrzymuj przekierowania minimum rok.
• Nie wyłączaj starej infrastruktury zbyt szybko.
• Porównuj dane ze stanem sprzed migracji.

Kiedy warto zlecić audyt migracji?

Wsparcie specjalisty jest szczególnie potrzebne, gdy:

• zmienia się domena,
• serwis ma tysiące adresów,
• migracja dotyczy sklepu internetowego,
• zmienia się system CMS,
• łączonych jest kilka domen,
• zmieniają się wersje językowe,
• strona generuje znaczną część sprzedaży z SEO,
• występują skomplikowane filtry i parametry,
• poprzednia migracja spowodowała spadki,
• nie ma kompletnej listy adresów.

Specjaliści 4PEOPLE mogą przeanalizować serwis przed migracją, przygotować zalecenia techniczne, zweryfikować mapę przekierowań i skontrolować nową wersję przed uruchomieniem. Szczegóły znajdziesz w ofercie audytu SEO strony.

Po migracji warto kontynuować rozwój widoczności, monitorować indeksowanie i aktualizować strategię. Sprawdź ofertę SEO i pozycjonowania stron 4PEOPLE.

Migracja strony nie musi oznaczać utraty widoczności

Zmiana domeny, hostingu, CMS-a lub struktury URL-i zawsze wiąże się z ryzykiem. Można je jednak znacząco ograniczyć dzięki dokładnemu przygotowaniu.

Najważniejsze elementy bezpiecznej migracji to:

• zapisanie stanu starego serwisu,
• kompletna mapa adresów,
• przekierowania jeden do jednego,
• aktualne canonicale,
• poprawne linkowanie wewnętrzne,
• nowa mapa witryny,
• brak blokad indeksowania,
• stabilny serwer,
• monitoring Search Console i ruchu,
• szybkie reagowanie na błędy.

Największym zagrożeniem nie jest sama zmiana strony, ale brak kontroli nad tym, co dokładnie zostało zmienione i jak stare adresy łączą się z nowymi.

FAQ – migracja strony a SEO

Co to jest migracja strony?

Migracja strony to istotna zmiana techniczna lub strukturalna, np. zmiana domeny, CMS-a, hostingu, adresów URL, protokołu HTTP na HTTPS albo połączenie kilku serwisów.

Czy migracja strony powoduje spadek pozycji?

Może powodować przejściowe wahania, ponieważ Google musi ponownie odwiedzić i przetworzyć adresy. Prawidłowo przeprowadzona migracja powinna ograniczyć skalę i czas trwania spadków.

Czy przekierowanie 301 obniża pozycje?

Google informuje, że 301 i inne trwałe przekierowania nie powodują utraty PageRanku. Problemem może być jednak nieprawidłowy cel przekierowania, łańcuch, pętla albo brak odpowiedniej treści docelowej.

Czy wszystkie stare adresy należy przekierować?

Wartościowe adresy powinny prowadzić do najbardziej odpowiednich nowych stron. URL-e bez zamiennika mogą zwracać 404 lub 410. Nie należy przekierowywać wszystkiego na stronę główną.

Jak długo utrzymywać przekierowania po migracji?

Google zaleca co najmniej rok. Z perspektywy użytkowników często warto pozostawić je na stałe, zwłaszcza gdy stare linki nadal występują w innych serwisach.

Czy trzeba używać narzędzia zmiany adresu?

Tak, jeśli cała domena zostaje przeniesiona na inną domenę. Narzędzia nie używa się przy przejściu na HTTPS, zmianie samego hostingu ani zmianie ścieżek w obrębie tej samej domeny.

Jak długo Google przetwarza migrację?

W przypadku małych i średnich stron może to potrwać kilka tygodni. Duże serwisy wymagają więcej czasu. Proces zależy od liczby adresów, szybkości serwera i poprawności przekierowań.

Czy podczas migracji można zmienić również treści?

Można, ale jednoczesna zmiana adresów, CMS-a, wyglądu i zawartości zwiększa ryzyko oraz utrudnia diagnozowanie spadków. Bezpieczniej rozdzielać duże zmiany, jeśli jest to możliwe.

Co zrobić z canonicalami po migracji?

Canonicale w nowej wersji powinny wskazywać nowe, właściwe adresy. Nie mogą prowadzić do starej domeny, środowiska testowego ani przekierowanych URL-i.

Czy trzeba aktualizować linki wewnętrzne?

Tak. Po migracji powinny prowadzić bezpośrednio do nowych adresów, a nie przez przekierowania. Dotyczy to menu, breadcrumbs, treści, kategorii, stopki i modułów powiązanych materiałów.

Czy trzeba przesłać nową mapę witryny?

Tak. Nowa mapa XML pomaga Google odkrywać aktualne URL-e. Powinna zawierać wyłącznie kanoniczne adresy zwracające kod 200 i przeznaczone do indeksowania.

Co najczęściej powoduje utratę ruchu po migracji?

Najczęstsze przyczyny to brak przekierowań, błędne mapowanie, pozostawiony noindex, blokada robots.txt, canonicale do starej domeny, utrata treści, błędy serwera, niedziałające linki i zbyt szybkie wyłączenie starej infrastruktury.