Migracja strony bez utraty ruchu w Google - kompletny przewodnik

Migracja strony to moment, w którym najłatwiej stracić coś, czego budowanie zajęło lata. Nowa wersja serwisu wygląda lepiej, działa szybciej i wreszcie da się nią zarządzać, a trzy tygodnie później w Search Console widać spadek ruchu organicznego o sześćdziesiąt procent. Najgorsze jest to, że prawie zawsze dało się tego uniknąć.

W tym artykule rozkładamy migrację na części: jakie są jej rodzaje i która jest najbardziej ryzykowna, dlaczego ruch spada, jak zbudować mapę adresów, jak wdrożyć i przetestować przekierowania, co sprawdzić w dniu przełączenia i według jakiego harmonogramu kontrolować efekty przez kolejne tygodnie. Na końcu znajdziesz checklistę i listę źródeł, z których korzystaliśmy.

Czym jest migracja strony i kiedy o niej mówimy

Migracja strony to każda zmiana, która wpływa na to, pod jakimi adresami wyszukiwarka znajduje Twoje treści albo w jaki sposób je odczytuje. Wbrew nazwie nie chodzi wyłącznie o przenoszenie plików z serwera na serwer.

Migracją jest zmiana domeny, przebudowa struktury adresów URL, przejście na inny system zarządzania treścią, połączenie kilku serwisów w jeden, przejście z HTTP na HTTPS i redesign, przy którym zmienia się nawigacja albo sposób generowania metadanych. Zwykła zmiana hostingu bez zmiany adresów też jest migracją, tylko o wiele mniej ryzykowną.

W praktyce rzadko występuje jeden typ naraz. Najczęstszy scenariusz w małych i średnich firmach wygląda tak: firma zamawia nową stronę, przy okazji zmienia się CMS, layout, struktura menu i połowa adresów. To już nie jest jedna migracja, tylko cztery jednocześnie - i właśnie dlatego kończy się spadkiem.

Rodzaje migracji i poziom ryzyka

• Zmiana hostingu - co się zmienia: serwer, adres IP; ryzyko: niskie; na co uważać: okno przełączenia DNS, wydajność nowego serwera
• HTTP na HTTPS - co się zmienia: protokół; ryzyko: niskie; na co uważać: przekierowania na wersję https, mieszana treść, certyfikat SSL
• Redesign bez zmiany adresów - co się zmienia: wygląd, układ treści; ryzyko: średnie; na co uważać: utrata treści, zmiana nagłówków, wolniejsze ładowanie
• Zmiana CMS - co się zmienia: system, technologia, często adresy; ryzyko: wysokie; na co uważać: nowe adresy, utrata metadanych, dane strukturalne do odtworzenia
• Zmiana struktury URL - co się zmienia: ścieżki wszystkich podstron; ryzyko: wysokie; na co uważać: kompletność mapy przekierowań, linkowanie wewnętrzne
• Zmiana domeny - co się zmienia: cały adres; ryzyko: najwyższe; na co uważać: historia nowej domeny, linki zewnętrzne, zgłoszenie w Search Console
• Połączenie serwisów - co się zmienia: dwie witryny w jedną; ryzyko: najwyższe; na co uważać: kanibalizacja treści, konflikty adresów, podwójne przekierowania

Reguła, która ratuje najwięcej projektów: rób jedną zmianę naraz. Google w swojej dokumentacji zaleca dokładnie to samo - jeśli planujesz nową domenę, nowy CMS i nowy układ, wprowadzaj te zmiany pojedynczo. Kiedy coś pójdzie nie tak przy jednej zmianie, wiesz, co naprawiać. Kiedy wszystko dzieje się naraz, zostaje Ci zgadywanie.

Dlaczego po migracji spada ruch organiczny

Wyszukiwarka nie zna Twoich intencji. Zna adresy, treści i sygnały, które je łączą. Migracja zrywa część tych połączeń i dopóki ich nie odtworzysz, Google traktuje nową stronę jak nową stronę - a nie jak kontynuację starej.

Najczęstsze przyczyny spadków wyglądają tak:

• Brakujące lub niekompletne przekierowania. Stary adres zwraca błąd 404, a razem z nim znika pozycja, którą zbierał przez lata, i wartość linków, które do niego prowadziły.
• Przekierowania zbiorcze na stronę główną. Formalnie działają, praktycznie kasują dopasowanie treści do zapytania. Google traktuje takie przekierowanie jak miękki błąd 404.
• Zablokowana indeksacja. Wersja testowa miała `noindex` albo `Disallow` w robots.txt i wjechała z tym ustawieniem na produkcję. To najczęstsza pojedyncza katastrofa migracyjna.
• Utrata treści. Nowa strona jest ładniejsza i o połowę uboższa. Podstrony, które generowały ruch, zniknęły albo skurczyły się do trzech zdań.
• Zmiana metadanych. Tytuły i opisy wygenerowane automatycznie przez nowy CMS zastąpiły te pisane pod konkretne frazy.
• Zerwane linkowanie wewnętrzne. Menu i linki w treści prowadzą do starych adresów, więc każdy robot i każdy użytkownik przechodzi przez dodatkowe przekierowanie.
• Wolniejsza strona. Nowy serwer albo nieoptymalizowana wersja pogarszają Core Web Vitals, co przy dużych serwisach widać w wynikach.

Warto rozdzielić dwie sytuacje. Krótkotrwały spadek po dobrze przeprowadzonej migracji jest normalny - wyszukiwarka potrzebuje czasu na ponowne zaindeksowanie i przypisanie sygnałów do nowych adresów. Spadek, który nie odbija po kilku tygodniach, oznacza błąd, a nie cierpliwość.

Ile trwa powrót do formy

Przy poprawnie wykonanej migracji małego serwisu firmowego pierwsze wahania widać w ciągu kilku dni, a stabilizacja następuje zwykle w dwa do sześciu tygodni. Przy dużych serwisach i sklepach proces potrafi trwać kwartał, bo Google musi przejść przez tysiące adresów.

To orientacyjne widełki, nie obietnica. Zależą od wielkości serwisu, częstotliwości odwiedzin robota i tego, jak dużo się faktycznie zmieniło. Jeśli ktoś gwarantuje Ci brak spadków, mówi o czymś, czego nie kontroluje.

Moment, w którym trzeba reagować, a nie czekać: ruch spada dalej po trzech tygodniach, w Search Console rośnie liczba błędów indeksowania albo stare adresy wciąż zwracają 404 zamiast przekierowywać.

Przygotowanie: co zebrać, zanim cokolwiek ruszysz

Migracja zaczyna się na długo przed dniem przełączenia. To etap, na którym decyduje się, czy będziesz mieć czym naprawiać ewentualne błędy.

Audyt i eksport danych

Zrób audyt SEO starej wersji i wyeksportuj wszystko, co da się wyeksportować. Potrzebujesz co najmniej:

• pełnej listy adresów z ruchem organicznym z Google Search Console, wraz z kliknięciami, wyświetleniami i pozycjami,
• raportu stron z Google Analytics 4 za ostatnie dwanaście miesięcy,
• listy adresów, do których prowadzą linki zewnętrzne,
• eksportu mapy witryny,
• listy tytułów, opisów i nagłówków każdej podstrony.

Te dane mają dwie funkcje. Po pierwsze, są materiałem do mapy przekierowań. Po drugie, są punktem odniesienia - bez nich za miesiąc nie odpowiesz na pytanie, czy ruch spadł, bo zwyczajnie nie będziesz wiedzieć, ile go było.

Pełny crawl starej strony

Google Search Console pokazuje adresy, które Google zna i odwiedza. Nie pokazuje wszystkich. Dlatego przed migracją przejedź serwis crawlerem, na przykład Screaming Frogiem, i zapisz kompletną listę adresów wraz ze statusami odpowiedzi, tytułami i przekierowaniami, które już istnieją.

Ten plik jest najważniejszym dokumentem całego procesu. Jeśli zapiszesz tylko jedną rzecz przed migracją, zapisz właśnie jego.

Kopia zapasowa

Kopia zapasowa plików i bazy danych, wykonana bezpośrednio przed przełączeniem i sprawdzona pod kątem odtwarzalności. Backup, którego nigdy nie odtworzono, jest tylko nadzieją zapisaną na dysku.

Jak odzyskać listę adresów, gdy stara strona już nie istnieje

Bywa, że artykuł taki jak ten trafia do Ciebie za późno: nowa strona działa od tygodnia, stara zniknęła, a nikt nie zrobił crawla. Sytuacja jest do uratowania.

Google Search Console pokaże część adresów w raporcie „Strony” w sekcji „Nie znaleziono (404)”, ale tylko te, które Google zdążył odwiedzić po zmianie. Kompletniejsze źródło to archiwum internetu. Wayback Machine udostępnia publiczne API, które zwraca listę wszystkich zarchiwizowanych adresów danej domeny:

http://web.archive.org/cdx/search/cdx?url=twojafirma.pl*&fl=original&collapse=urlkey

Odpowiedź to zwykły tekst z listą adresów. Po odfiltrowaniu plików graficznych i zasobów zostaje mapa starej struktury serwisu - często kompletniejsza niż to, co pokazuje Search Console, bo archiwum pamięta również podstrony, które Google zdążył już usunąć z indeksu.

Tej metody nie opisuje żaden z popularnych poradników o migracji, a ratuje sytuacje, które wyglądają na przegrane. Sami korzystamy z niej przy przejmowaniu projektów po innych wykonawcach, gdzie dokumentacji zwykle nie ma żadnej.

Mapowanie adresów URL: najważniejszy dokument migracji

Mapowanie adresów URL sprowadza się do arkusza z dwiema kolumnami: stary adres i nowy adres. Brzmi banalnie i właśnie dlatego bywa robiona po łebkach.

Zasada mapowania jeden do jednego

Każdy stary adres, który miał ruch, pozycję albo linki, dostaje konkretny odpowiednik, a nie stronę główną. Jeśli treść przestała istnieć, wskaż najbliższą tematycznie kategorię. Dopiero gdy nie ma nic sensownego, rozważ pozostawienie błędu 404 - bo uczciwy 404 jest dla wyszukiwarki jaśniejszym sygnałem niż przekierowanie prowadzące donikąd.

Przy dużej liczbie adresów podziel mapowanie adresów URL na trzy grupy:

• Odpowiedniki jeden do jednego. Ta sama treść pod nowym adresem. Największa i najprostsza grupa.
• Reguły wzorcowe. Całe sekcje przenoszone według jednego schematu, na przykład wszystko z `/pl/oprogramowanie/` na `/uslugi/oprogramowanie/`. Jedna reguła obsługuje setki adresów.
• Przypadki wymagające decyzji. Treści usunięte, połączone albo rozbite na kilka podstron. Te trzeba przejść ręcznie i to one zajmują najwięcej czasu.

Czego nie robić

Nie przekierowuj masowo niepowiązanych podstron na stronę główną. To najczęstszy skrót i najkosztowniejszy. Google rozpoznaje takie przekierowania i traktuje je jak błąd 404, więc cała praca idzie na marne, a Ty przez kilka tygodni jesteś przekonany, że przekierowania działają.

Nie zostawiaj też starej wersji strony dostępnej równolegle pod innym adresem. Dwie identyczne kopie serwisu to duplikacja treści i konkurencja z samym sobą.

Przekierowania 301: serce migracji

Przekierowanie 301 to komunikat dla przeglądarki i wyszukiwarki: „ten adres zmienił się na stałe”. Przenosi użytkownika i przekazuje sygnały rankingowe na nowy adres.

301 czy 302

Przekierowanie 302 oznacza zmianę tymczasową. Przy migracji jest błędem, bo mówi wyszukiwarce, że stary adres wróci. Google z czasem potraktuje długotrwałe 302 jak przeniesienie trwałe, ale „z czasem” to tygodnie opóźnienia, których nie musisz sobie fundować.

Problem polega na tym, że wiele wtyczek, paneli hostingowych i domyślnych ustawień serwera stosuje 302, bo jest bezpieczniejsze w razie pomyłki. Dlatego przy odbiorze migracji pytaj wprost o kod odpowiedzi i sprawdź go samodzielnie.

Łańcuchy i pętle

Przekierowanie prowadzące do adresu, który sam przekierowuje dalej, to łańcuch. Każde ogniwo to dodatkowe zapytanie i opóźnienie, a przy dłuższych łańcuchach robot potrafi przerwać wędrówkę. Mapuj zawsze ze starego adresu bezpośrednio na docelowy, nawet jeśli po drodze istniało kiedyś przekierowanie pośrednie.

Pętla, czyli adres przekierowujący sam na siebie, kończy się błędem w przeglądarce i całkowitą niedostępnością podstrony.

Testowanie przed uruchomieniem

Przygotuj listę kilkudziesięciu najważniejszych starych adresów i sprawdź każdy z nich. Przy niewielkiej liczbie wystarczy narzędzie sprawdzające nagłówki odpowiedzi, przy większej - crawler w trybie listy adresów. Kontrolujesz trzy rzeczy: czy kod to 301, czy adres docelowy jest właściwy i czy nie ma po drodze dodatkowego skoku.

Te same adresy sprawdź jeszcze raz w ciągu godziny po przełączeniu. Konfiguracja na środowisku testowym i na produkcji potrafi się różnić.

Elementy techniczne, które muszą zgadzać się w dniu migracji

robots.txt i noindex

Najczęstsza katastrofa migracyjna nie jest wyrafinowana: wersja testowa miała blokadę indeksacji i pojechała z nią na produkcję. Skutek to wypadnięcie z indeksu w ciągu kilku dni.

Sprawdź robots.txt i znacznik `noindex` jako pierwszą rzecz po przełączeniu, zanim zajrzysz gdziekolwiek indziej. To trzydzieści sekund pracy i różnica między spokojnym tygodniem a paniką.

sitemap.xml

Wygeneruj nową mapę witryny z aktualnymi adresami i zgłoś ją w Search Console. Stara mapa, jeśli nadal istnieje, powinna zostać usunięta dopiero po tym, jak Google przetworzy przekierowania - przez pewien czas obie bywają przydatne, bo stara podpowiada robotowi, gdzie szukać przekierowań.

Mapa nie może zawierać adresów, które przekierowują, ani takich, które zwracają błąd. Zawiera wyłącznie docelowe, działające adresy.

Adresy kanoniczne

Po migracji każdy adres kanoniczny musi wskazywać nową wersję samego siebie. Zostawione canonicale prowadzące na stary adres to sygnał sprzeczny z przekierowaniem i jeden z trudniejszych do wykrycia błędów, bo strona wygląda na działającą.

HTTPS i wersja z www

Ustal jedną wersję kanoniczną - z `www` albo bez, po `https` - i przekieruj na nią wszystkie pozostałe. Cztery warianty tego samego adresu to cztery wersje strony w oczach wyszukiwarki.

Środowisko testowe: jak nie wpuścić wersji roboczej do Google

Nową wersję buduje się na subdomenie testowej albo w osobnym środowisku. Musi ono być zamknięte przed indeksacją, i to nie samym `Disallow` w robots.txt, bo ten nie gwarantuje, że adres nie trafi do indeksu z innego źródła. Pewniejsze jest zabezpieczenie hasłem na poziomie serwera.

Zdarzają się sytuacje, w których do indeksu trafia wersja testowa i zaczyna konkurować z produkcyjną o te same frazy. Usunięcie jej z indeksu trwa dłużej niż zbudowanie całej strony.

Na środowisku testowym sprawdzasz komplet: treści, metadane, dane strukturalne, działanie formularzy, poprawność certyfikatu i szybkość ładowania.

Dzień migracji: kolejność działań

• Kopia zapasowa starej wersji, plików i bazy.
• Obniżenie TTL w konfiguracji DNS na kilka godzin przed przełączeniem, żeby zmiana rozeszła się szybciej.
• Przełączenie i natychmiastowe sprawdzenie, czy strona działa pod właściwym adresem.
• Kontrola blokad indeksacji - robots.txt i noindex.
• Test przekierowań na przygotowanej wcześniej liście adresów.
• Zgłoszenie nowej mapy witryny w Search Console.
• Zgłoszenie zmiany adresu, jeśli zmieniła się domena.
• Sprawdzenie analityki - czy kod śledzący działa na nowej wersji i czy zbiera dane.
• Przegląd linkowania wewnętrznego - czy menu i linki w treści prowadzą bezpośrednio na nowe adresy.

Termin też ma znaczenie. Przełączaj wtedy, gdy ruch jest najniższy i gdy przez najbliższe dwa dni ktoś będzie dostępny. Piątek po południu i dzień przed urlopem to najgorsze możliwe wybory.

Narzędzie zmiany adresu w Search Console

Przy zmianie domeny Google udostępnia w Google Search Console funkcję zgłoszenia zmiany adresu. Informuje ona wyszukiwarkę, że cały serwis przeniósł się pod nowy adres, i przyspiesza przeniesienie sygnałów.

Dwie rzeczy warto wiedzieć. Po pierwsze, narzędzie działa tylko wtedy, gdy przekierowania faktycznie są wdrożone - bez nich zgłoszenie nic nie daje. Po drugie, dotyczy wyłącznie zmiany domeny. Przy zmianie samej struktury adresów w obrębie tej samej domeny nie ma czego zgłaszać i wystarczą poprawne przekierowania oraz nowa mapa witryny.

Co i kiedy sprawdzać po migracji

• Pierwsza godzina - dostępność strony, robots.txt, noindex, kody odpowiedzi na liście testowej, działanie formularzy
• Pierwszy dzień - zgłoszona mapa witryny, zbieranie danych w analityce, certyfikat SSL, wersja mobilna
• Pierwszy tydzień - raport indeksowania w Search Console, błędy 404, pełny crawl nowej wersji, linkowanie wewnętrzne
• Drugi tydzień - porównanie ruchu i pozycji z danymi sprzed migracji, kontrola adresów kanonicznych
• Miesiąc - stan indeksacji wszystkich podstron, Core Web Vitals, aktualizacja linków u partnerów i w katalogach
• Kwartał - pełne porównanie widoczności rok do roku, decyzja o ewentualnych korektach

Najważniejsza kolumna to pierwsza. Większość błędów migracyjnych jest tania do naprawienia w pierwszej godzinie i droga po dwóch tygodniach.

Najczęstsze błędy

• Migracja bez mapowania adresów URL. Przekierowania 301 robione „na czuja”, z pominięciem podstron, które nie wyglądały na ważne, a generowały ruch z długiego ogona.
• Wszystko naraz. Nowa domena, nowy CMS i redesign w jednym wdrożeniu. Przy spadku nie da się ustalić przyczyny.
• Zapomniane pliki techniczne. robots.txt skopiowany ze środowiska testowego, mapa witryny z nieaktualnymi adresami.
• Stare adresy w linkowaniu wewnętrznym. Menu prowadzi przez przekierowania, więc każde kliknięcie to dodatkowy skok.
• Brak danych referencyjnych. Nikt nie wyeksportował raportów sprzed migracji, więc nie wiadomo, czy jest gorzej.
• Utrata treści przy okazji redesignu. Podstrony, które przynosiły ruch, zostały skrócone albo usunięte, bo „nie pasowały do nowego układu”.
• Brak monitoringu. Migracja uznana za zakończoną w dniu wdrożenia. Problemy wychodzą po miesiącu, gdy nikt już nie patrzy.
• Panika po trzech dniach. Odwracanie zmian, zanim wyszukiwarka zdążyła przetworzyć nową wersję, robi więcej szkody niż sam spadek.

Checklista migracji

Przed

• Pełny crawl starej strony zapisany do pliku
• Eksport danych z Search Console i analityki
• Lista adresów z linkami zewnętrznymi
• Mapowanie adresów URL w formacie stary → nowy, kompletne
• Kopia zapasowa plików i bazy, sprawdzona
• Środowisko testowe zamknięte hasłem
• Metadane, dane strukturalne i treści przeniesione
• Obniżony TTL w DNS

W dniu migracji

• Przełączenie w godzinach niskiego ruchu
• Kontrola robots.txt i noindex
• Test przekierowań 301 na liście kontrolnej
• Zgłoszenie nowej mapy witryny
• Zgłoszenie zmiany adresu, jeśli zmieniła się domena
• Weryfikacja działania analityki
• Sprawdzenie certyfikatu i wersji mobilnej

Po

• Codzienna kontrola indeksacji przez pierwszy tydzień
• Pełny crawl nowej wersji
• Poprawa linkowania wewnętrznego na adresy docelowe
• Aktualizacja linków w profilach firmowych i katalogach
• Porównanie ruchu z danymi referencyjnymi po dwóch tygodniach
• Kontrola Core Web Vitals

Samodzielnie czy z wykonawcą

Migrację prostej strony wizytówkowej bez zmiany adresów da się przeprowadzić samodzielnie, jeśli masz dostęp do serwera i potrafisz zweryfikować kody odpowiedzi.

Wsparcie warto rozważyć, gdy zmienia się domena, gdy serwis ma więcej niż kilkadziesiąt podstron, gdy prowadzisz sklep internetowy albo gdy ruch organiczny jest istotnym źródłem klientów. Koszt migracji zależy przede wszystkim od liczby adresów do zmapowania i od tego, czy zmiana obejmuje jeden element, czy kilka naraz - dlatego rzetelna wycena zaczyna się od pytania o wielkość serwisu, a nie od cennika.

Jeśli wybierasz wykonawcę, zapytaj wprost o mapę adresów, kod przekierowania 301 i sposób testowania. Szerzej o tym, jak weryfikować firmę przed zleceniem, piszemy w artykule o wyborze wykonawcy strony.

Jak podchodzimy do migracji w Getinweb

Traktujemy mapowanie adresów URL jako pierwszy dokument projektu, a nie jako ostatni etap wdrożenia. Powstaje razem z nową architekturą serwisu, więc decyzja o zmianie adresu jest podejmowana świadomie, a nie odkrywana po fakcie.

Przy przejmowaniu projektów po innych wykonawcach, gdzie dokumentacji zwykle nie ma, odtwarzamy strukturę starego serwisu z trzech źródeł naraz: raportu błędów 404 w Search Console, archiwum internetu i profilu linków zewnętrznych. Dopiero mając komplet, budujemy przekierowania 301 - najpierw jeden do jednego dla adresów z ruchem, potem reguły wzorcowe dla całych sekcji.

Zajmujemy się budową i przebudową stron, hostingiem i audytami technicznymi, więc migracja nie jest u nas przekazywana między trzema firmami, z których każda odpowiada za swój kawałek. Jeśli planujesz przebudowę, opisz nam projekt - powiemy, które elementy da się zmienić od razu, a które lepiej rozłożyć na etapy.

FAQ

Czy przekierowanie 301 przekazuje pełną moc strony?

Google potwierdza, że przekierowania 301 nie powodują utraty wartości linków. W praktyce liczy się jednak trafność mapowania - przekierowanie na niepowiązaną treść przekazuje mniej niż przekierowanie na dokładny odpowiednik, bo wyszukiwarka ocenia również dopasowanie treści.

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

Technicznie tak, ale to jeden z najkosztowniejszych skrótów. Google traktuje masowe przekierowania niepowiązanych podstron jak błąd 404 i nie przekazuje przez nie sygnałów. Mapuj na najbliższą tematycznie treść.

Jak długo trzymać przekierowania?

Minimum rok, a jeśli nic nie stoi na przeszkodzie - bezterminowo. Google zaleca utrzymywanie ich co najmniej przez rok, bo tyle potrafi zająć pełne przeniesienie sygnałów i aktualizacja linków zewnętrznych.

Czy migracja zawsze oznacza spadek pozycji?

Nie zawsze, ale krótkotrwałe wahania są normalne nawet przy poprawnym wdrożeniu. Niepokojący jest brak odbicia po kilku tygodniach - to sygnał błędu, a nie naturalnego procesu.

Czy przy migracji można od razu usunąć słabe treści?

Można, ale lepiej rozdzielić te działania. Usuwanie treści w trakcie migracji miesza dwie zmienne i przy spadku nie da się ustalić, czy winne są przekierowania, czy usunięte podstrony. Zrób porządek miesiąc później.

Co zrobić, jeśli ruch spadł, a migracja już się odbyła?

Po kolei: sprawdź blokady indeksacji, przetestuj przekierowania na adresach, które miały największy ruch, porównaj raport indeksowania z danymi sprzed migracji i przejedź serwis crawlerem. W tej kolejności, bo pierwsze dwa punkty odpowiadają za większość przypadków.

Czy zmiana samego hostingu wpływa na SEO?

Sama w sobie nie, o ile adresy zostają bez zmian i strona jest dostępna w trakcie przełączenia. Pośrednio wpływa przez szybkość i stabilność nowego serwera.

Podsumowanie

Migracja bez utraty ruchu nie jest kwestią szczęścia, tylko trzech rzeczy: kompletnego mapowania adresów URL, poprawnie wdrożonych przekierowań 301 i kontroli po przełączeniu. Reszta to szczegóły, które da się nadrobić.

Największe ryzyko nie leży w technologii, tylko w kolejności. Strona, która najpierw powstaje, a dopiero potem dostaje mapowanie adresów URL, zawsze będzie ją miała niekompletną - bo część adresów zniknie razem ze starym serwisem, zanim ktokolwiek je spisze.

Jeśli masz przed sobą przebudowę, zacznij od crawla obecnej wersji. To pół godziny pracy, która potrafi uratować lata pozycjonowania.

Źródła

Dokumentacja i narzędzia, z których korzystaliśmy przy pisaniu tego artykułu:

• Google Search Central: przenoszenie witryny ze zmianą adresów URL - oficjalne zalecenia Google dotyczące mapowania adresów, kolejności działań i monitorowania ruchu po przeniesieniu.
• Google Search Central: przenoszenie witryny bez zmiany adresów URL - procedura dla zmiany hostingu i serwera.
• Google Search Console: narzędzie zmiany adresu - warunki i sposób zgłoszenia zmiany domeny.
• Google Search Central: przekierowania i wyszukiwarka Google - rodzaje przekierowań i ich interpretacja przez Google.
• Google Search Central: mapy witryn - zasady przygotowania i zgłaszania sitemapy.
• Google Search Central: robots.txt - działanie pliku i różnica wobec znacznika noindex.
• Wayback Machine CDX Server API - dokumentacja API archiwum internetu, używanego do odtwarzania listy adresów nieistniejącej już wersji serwisu.
• Screaming Frog SEO Spider - crawler wykorzystywany do inwentaryzacji adresów przed migracją i weryfikacji po niej.

Pojęcia użyte w artykule wyjaśniamy w słowniku pojęć IT: migracja strony, przekierowanie 301, kody odpowiedzi HTTP, robots.txt, sitemap.xml i audyt SEO.