Migracja CMS to przeniesienie serwisu na inny system zarządzania treścią z zachowaniem jego dotychczasowej widoczności w wyszukiwarkach. Kluczowe słowo brzmi „z zachowaniem" — technicznie przeniesienie treści jest proste, natomiast utrzymanie pozycji wymaga procedury, której pominięcie kosztuje miesiące odbudowy.
Dlaczego migracje kończą się spadkami
Widzieliśmy wystarczająco dużo nieudanych migracji, żeby wskazać powtarzalne przyczyny.
Najczęstsza to zmiana struktury adresów bez pełnego mapowania. Wystarczy, że kilkadziesiąt podstron z historią linków trafi na błąd 404, a serwis traci dokładnie tę część widoczności, która była najcenniejsza. Druga to porzucenie treści przy okazji „odświeżenia" — nowy serwis jest ładniejszy i o połowę krótszy, a wraz z usuniętymi akapitami znikają frazy, na które strona rankowała.
Trzecia przyczyna jest bardziej subtelna: przeniesienie treści bez warstwy technicznej. Nowy CMS generuje inne nagłówki, gubi dane strukturalne, zmienia obsługę paginacji albo wprowadza duplikaty przez parametry. Strona wygląda tak samo, a robot widzi zupełnie inny serwis. I wreszcie czwarta — publikacja bez testów, gdy środowisko testowe zostaje zaindeksowane albo produkcja startuje z blokadą indeksowania, o której nikt nie pamięta przez dwa tygodnie.
Nasza procedura migracji
1. Inwentaryzacja przed startem
Zbieramy pełny obraz stanu wyjściowego: listę wszystkich indeksowanych adresów, ich pozycje, ruch, profil linków przychodzących, dane strukturalne i konfigurację techniczną. To punkt odniesienia, bez którego nie da się później stwierdzić, czy migracja się powiodła.
2. Mapowanie adresów
Każdy istniejący adres dostaje przypisany odpowiednik w nowym serwisie — jeden do jednego tam, gdzie to możliwe. Adresy bez odpowiednika rozstrzygamy świadomie: przekierowanie do najbliższej tematycznie podstrony albo celowe wygaszenie. Mapowanie akceptuje klient, bo część decyzji jest biznesowa, nie techniczna.
3. Przeniesienie treści i mediów
Przenosimy treść wraz z metadanymi, atrybutami alt, danymi strukturalnymi i wewnętrznym linkowaniem. Zmiany w treści, jeśli są potrzebne, wprowadzamy po migracji, a nie w jej trakcie — inaczej przy ewentualnych spadkach nie da się ustalić przyczyny.
4. Środowisko testowe i gate-check
Nowy serwis budujemy na środowisku odseparowanym i zabezpieczonym przed indeksowaniem. Przed publikacją przechodzimy listę kontrolną: przekierowania, kody odpowiedzi, canonicale, mapa witryny, plik robots.txt, dane strukturalne, wydajność i poprawność mobilna. Publikujemy dopiero, gdy lista jest zamknięta.
5. Publikacja i pierwsze godziny
Wdrożenie planujemy na moment najmniejszego ruchu. Bezpośrednio po nim weryfikujemy przekierowania na produkcji, zgłaszamy nową mapę witryny w Google Search Console i sprawdzamy, czy blokada indeksowania została zdjęta. Utrzymujemy pełną kopię poprzedniego serwisu na wypadek wycofania zmian.
6. Monitoring po migracji
Przez kolejne tygodnie obserwujemy indeksację, błędy crawlowania, pozycje i ruch. Wahania w pierwszych dniach są normalne — istotne jest, czy krzywa wraca do poziomu wyjściowego. Reagujemy na pojedyncze adresy, zanim problem urośnie.
Kiedy migracja jest uzasadniona
Wtedy, gdy obecny system ogranicza rozwój: brakuje potrzebnych funkcji, każda zmiana wymaga programisty, system nie jest już aktualizowany albo utrzymanie stało się nieproporcjonalnie kosztowne wobec tego, co daje. Uzasadnieniem bywa też wydajność — jeśli architektura systemu uniemożliwia osiągnięcie sensownych Core Web Vitals, optymalizacja ma swój sufit.
Migracja nie jest natomiast rozwiązaniem problemu niskiej skuteczności serwisu. Jeśli strona działa poprawnie, a nie sprzedaje, przyczyna leży zwykle w treści i ścieżce użytkownika — tym zajmuje się optymalizacja konwersji.
Migracja a przebudowa serwisu
To dwa różne projekty, które warto rozdzielić w czasie. Migracja przenosi istniejący serwis na nowy system przy zachowaniu treści i struktury. Przebudowa zmienia strukturę, projekt i treść — opisujemy ją przy usłudze strony internetowe.
Gdy oba działania są potrzebne, rekomendujemy zwykle rozdzielenie ich: najpierw migracja z zachowaniem struktury, potem zmiany w treści i architekturze. Jednoczesna zmiana wszystkiego oznacza, że przy spadkach nie da się ustalić, co je spowodowało. Jeśli klient decyduje się na wariant łączony, mówimy wprost, jakie ryzyko przyjmuje.
Co wpływa na zakres projektu
Zakres zależy od: liczby podstron i wpisów do przeniesienia, stopnia różnicy między starą a nową strukturą adresów, liczby integracji i funkcji do odtworzenia, tego czy migrujemy również sklep wraz z historią zamówień oraz od tego, czy migracji towarzyszy zmiana projektu graficznego. Po inwentaryzacji przedstawiamy plan z podziałem na etapy i wskazaniem punktów ryzyka.
Najczęściej zadawane pytania
Przy poprawnie przeprowadzonej migracji spadki są przejściowe i mieszczą się w kilkunastu procentach ruchu przez pierwsze dwa–cztery tygodnie, po czym widoczność wraca. Warunkiem jest pełne mapowanie adresów, przekierowania 301, zachowanie treści i danych strukturalnych. Nie deklarujemy jednak zerowego wpływu — Google potrzebuje czasu na ponowne przetworzenie serwisu i to jest normalna część procesu.
Sam moment publikacji to zwykle kilka godzin, ale cały projekt — od inwentaryzacji, przez mapowanie, budowę na środowisku testowym, po monitoring — trwa najczęściej 4–10 tygodni. Największy wpływ na ten czas ma liczba podstron i stopień, w jakim nowa struktura adresów różni się od dotychczasowej.
Nie musisz, ale każda zmiana adresu wymaga przekierowania 301 i oznacza pewien koszt w postaci czasowego osłabienia sygnałów. Jeśli obecna struktura jest poprawna, rekomendujemy jej zachowanie. Zmianę proponujemy wtedy, gdy dotychczasowe adresy są nieczytelne, niespójne lub blokują sensowną architekturę serwisu — i wtedy robimy to w jednym, dobrze przygotowanym kroku, zamiast rozkładać na kilka.
Przekierowania 301 przenoszą znaczną część wartości tych linków na nowe adresy. Dlatego przed migracją analizujemy profil linków i traktujemy podstrony z najsilniejszymi odnośnikami priorytetowo w mapowaniu — to one najbardziej ucierpią na błędzie. Właścicieli najważniejszych linkujących serwisów warto dodatkowo poprosić o aktualizację adresu, choć nie zawsze jest to wykonalne.
Tak i zawsze zabezpieczamy taką możliwość. Przed publikacją wykonujemy pełną kopię poprzedniego serwisu wraz z bazą danych i konfiguracją. Wycofanie zmian jest ostatecznością — w praktyce większość problemów po migracji rozwiązuje się punktowo, poprawiając konkretne przekierowania lub przywracając pojedyncze treści.
Tak, przy czym migracja sklepu jest projektem o wyższym ryzyku niż migracja serwisu firmowego. Dochodzą dane transakcyjne, konta klientów, historia zamówień, integracje z płatnościami i systemami magazynowymi oraz adresy kart produktów i kategorii, których zwykle są tysiące. Takie projekty prowadzimy razem z pracami opisanymi przy usłudze e-commerce.
