Migracja strony internetowej - poradnik

Rodzaje migracji i ryzyko każdej z nich

Słowo „migracja” obejmuje bardzo różne zmiany, a od rodzaju zależy, na co trzeba uważać najbardziej:

Przy dużych projektach zawsze proponuję rozdzielenie zmian w czasie. Gdy po migracji spada ruch, a zmieniło się jednocześnie pięć rzeczy, trudno ustalić, która z nich jest przyczyną.

Przed migracją, czyli inwentaryzacja

Najważniejsza praca dzieje się, zanim cokolwiek zostanie przeniesione. Zbieram pełny obraz starej strony z kilku źródeł, bo każde pokazuje inny wycinek:

• crawl całego serwisu, np. w Screaming Frogu: wszystkie adresy, tytuły, opisy, nagłówki H1, adresy kanoniczne, dane strukturalne i linki wewnętrzne,
• Search Console: adresy z ruchem i wyświetleniami z ostatnich 12–16 miesięcy, także te, których crawl nie znajdzie,
• analityka: strony z największą liczbą wejść i konwersji,
• narzędzia do analizy linków: adresy, do których prowadzą linki z innych domen,
• mapy witryny i logi serwera: adresy, które istnieją, ale nie mają linków.

Na koniec zapisuję punkt odniesienia: widoczność na najważniejsze frazy, ruch z wyszukiwarki, liczbę zaindeksowanych stron i czas odpowiedzi serwera. Bez tego po migracji nie da się rzetelnie ocenić, czy coś poszło źle.

Mapa przekierowań

Mapa przekierowań to tabela, w której każdy stary adres ma przypisany nowy. To dokument, od którego najbardziej zależy wynik migracji:

• każdy stary adres przekierowuję kodem 301 na najbardziej odpowiadający mu nowy adres, a nie na stronę główną czy kategorię nadrzędną,
• adresy bez odpowiednika i bez wartości zostawiam z kodem 404 lub 410, zamiast sztucznie przekierowywać,
• przekierowania prowadzą od razu do adresu docelowego, bez łańcuchów; stare przekierowania z poprzednich zmian aktualizuję tak, żeby wskazywały nowe adresy,
• powtarzalne wzorce, np. zmianę prefiksu kategorii, zapisuję jedną regułą, a wyjątki osobno.

Przekierowania wdrażam regułami serwera w pliku .htaccess lub konfiguracji Nginx, a przy tysiącach adresów albo braku dostępu do serwera na poziomie CDN, tak jak w Edge SEO. Przed wdrożeniem sprawdzam, czy reguły nie tworzą pętli przekierowań.

Strona testowa i przeniesienie danych

Nową wersję buduję i sprawdzam na stronie testowej, chronionej hasłem na poziomie serwera. Samo Disallow w robots.txt nie wystarcza, bo nie chroni przed przypadkowym zaindeksowaniem adresów, do których ktoś dodał link. Na stronie testowej sprawdzam:

• czy wszystkie treści, zdjęcia i pliki do pobrania zostały przeniesione, porównując liczbę adresów z crawlem starej strony,
• czy tytuły, opisy, nagłówki, adresy kanoniczne i dane strukturalne odpowiadają tym ze starej wersji,
• czy linki wewnętrzne prowadzą do nowych adresów, a nie do przekierowań,
• czy wersja PHP, rozszerzenia i limity serwera są zgodne z wymaganiami aplikacji,
• czy formularze, płatności i wysyłka e-maili działają.

Pliki przenoszę przez SFTP albo bezpośrednio między serwerami, a po przeniesieniu porównuję liczbę plików i rozmiar katalogów, bo przerwany transfer potrafi zostawić puste pliki. Dlatego zawsze łączę się z serwerem przez SFTP, a nie przez zwykłe FTP.

Dzień migracji

1. Dzień lub dwa wcześniej obniżam TTL rekordów DNS, np. do 300 sekund, żeby zmiana adresu serwera rozeszła się szybko. Przy okazji sprawdzam całą konfigurację DNS, łącznie z rekordami poczty.
2. Zamrażam zmiany w treściach i zamówieniach albo planuję ich przeniesienie, żeby nic nie zginęło między kopią a przełączeniem.
3. Robię końcową kopię plików i bazy starej strony i sprawdzam, czy da się ją przywrócić.
4. Przełączam DNS lub wdrażam nową wersję, włączam przekierowania i sprawdzam certyfikat SSL.
5. Usuwam blokady ze strony testowej: hasło, noindex i reguły w robots.txt. To krok, o którym zapomina się najczęściej.
6. Przy zmianie domeny zgłaszam ją w Search Console narzędziem do zmiany adresu i dodaję nową mapę witryny.

Po migracji, czyli weryfikacja i monitoring

Wahania ruchu w pierwszych tygodniach są normalne, bo Google przelicza sygnały dla nowych adresów. Niepokoi mnie spadek, który nie zaczyna się odwracać po kilku tygodniach, albo spadek dotyczący konkretnych sekcji, bo zwykle wskazuje na brakujące przekierowania lub treści. Błędy 404 analizuję tak samo jak przy każdym błędzie 404, a ruch robotów przy pomocy analizy logów serwera.

Przekierowania utrzymuję co najmniej rok, a przy zmianie domeny dłużej, i nie oddaję starej domeny, dopóki prowadzą do niej linki. Na koniec usuwam z serwera kopie robocze, archiwa i katalogi testowe, zmieniam hasła i usuwam konta, które były potrzebne tylko na czas przenosin.

Najczęstsze błędy przy migracji

Pełną kontrolę stanu strony po migracji robię w ramach audytu technicznego SEO, porównując wyniki z crawlem wykonanym przed zmianą.