english
español
Magdalena Szypulska
Błędne adresy, brak przekierowań czy problemy z indeksacją mogą szybko odbić się na ruchu. Dlatego jeszcze przed rozpoczęciem migracji dobrze mieć pełny obraz starego portalu i wiedzieć, co dokładnie będzie przenoszone.
Zacznij od analizy starego serwisu
Wieloletni portal zwykle ma znacznie więcej adresów, niż widać na pierwszy rzut oka. Niektóre artykuły mogą od dawna nie być dostępne z menu, a mimo to nadal pojawiać się w Google albo przynosić wejścia z innych stron.
Takie adresy określa się jako orphan pages, czyli strony osierocone. Nie mają linków z głównej struktury serwisu, ale nadal mogą być dostępne dla użytkowników lub robotów wyszukiwarki.
Przed migracją przydają się dane z Google Search Console, Google Analytics, logów serwerowych, crawlera SEO oraz bazy starego CMS-a. Crawler pozwala sprawdzić między innymi strukturę portalu, linki i odpowiedzi serwera.
Dzięki temu wiadomo, które adresy rzeczywiście generują ruch, jakie treści są najczęściej odwiedzane i z jakich funkcji korzysta redakcja. Na tym etapie można też znaleźć stare adresy lub mechanizmy, które łatwo pominąć przy ręcznym planowaniu migracji.
Zaplanuj zmianę adresów URL
Jeżeli artykuł przez lata funkcjonował pod konkretnym adresem, zdobywał linki i pojawiał się w wynikach wyszukiwania, jego zmiana wymaga przygotowania odpowiedniego przekierowania.
Podstawą jest mapa przekierowań, czyli zestawienie starych i nowych adresów.
Przykładowo:
stary adres: /wiadomosci/nowa-droga-w-miescie
nowy adres: /lokalne/nowa-droga-w-miescie
Po uruchomieniu nowego portalu stary URL powinien prowadzić bezpośrednio do odpowiadającego mu artykułu.
Najczęściej stosuje się mapowanie 1:1. Jeden stary adres wskazuje konkretny nowy odpowiednik. Przy dużych archiwach ma to duże znaczenie, ponieważ błędne przypisania mogą dotyczyć tysięcy materiałów.
Do trwałej zmiany adresu Google rekomenduje przekierowania serwerowe, w tym 301 lub 308.
Nie warto kierować setek starych artykułów na stronę główną tylko po to, żeby pozbyć się błędów 404. Jeżeli materiał ma swój odpowiednik w nowym serwisie, przekierowanie powinno prowadzić właśnie tam. Google również ostrzega przed masowym kierowaniem niepowiązanych adresów na stronę główną.
Gdy strona została trwale usunięta i nie ma dla niej odpowiednika, można zastosować 410.
Uważaj na łańcuchy i pętle przekierowań
Stary adres nie powinien prowadzić najpierw do jednego URL-a, a dopiero potem do właściwej strony. Taki łańcuch przekierowań wydłuża drogę do docelowego adresu i przy dużej skali może stać się problemem.
Jeszcze gorzej wygląda redirect loop, czyli pętla przekierowań. Adres A kieruje do B, ale B kieruje z powrotem do A. Przeglądarka wykonuje kolejne przekierowania, cały czas trafiając między te same adresy. Artykułu nie da się otworzyć, a użytkownik kończy z komunikatem o błędzie.
Do takich sytuacji może dojść, gdy część reguł została pozostawiona ze starego systemu, a nowe reguły zaczęły działać równolegle. Przyczyną mogą być również sprzeczne zasady ustawione na serwerze.
Innym częstym błędem jest tzw. soft 404, czyli sytuacja, w której strona wygląda jak błąd (np. pokazuje komunikat „nie znaleziono”), ale serwer mimo to zwraca kod 200. Dla Google to mylący sygnał: strona wydaje się istnieć, więc trafia do indeksu, choć nie ma żadnej wartości dla użytkownika. Przy migracjach zdarza się to najczęściej wtedy, gdy stary adres bez odpowiednika zostaje przekierowany na stronę główną albo listing kategorii zamiast otrzymać poprawny kod 404 lub 410.
Duży portal może mieć tysiące, a nawet dziesiątki tysięcy starych URL-i. Przy takiej skali ręczne tworzenie pojedynczych reguł nie jest dobrym rozwiązaniem. Całą mapę trzeba przygotować tak, aby serwer mógł ją sprawnie obsłużyć i nie dochodziło do konfliktów między regułami.
Warto też pamiętać, że kod 410 nie powinien być domyślną odpowiedzią całego serwera - to sygnał dla pojedynczych, świadomie usuniętych adresów, a nie ustawienie stosowane masowo.
Przenieś pełne dane artykułów
Przenosząc artykuły, trzeba uwzględnić title, meta description, daty publikacji i modyfikacji, autora, kategorie, tagi, dane strukturalne, zdjęcia, galerie oraz linkowanie wewnętrzne.
Nie można pominąć relacji między materiałami. Jeżeli stary portal pokazuje pod artykułem podobne publikacje, najnowsze materiały z działu albo popularne teksty, po migracji te mechanizmy również powinny działać zgodnie z założeniami nowego systemu.
Co z publikacjami powstającymi podczas migracji?
Migracja nie zatrzymuje pracy redakcji. W tym czasie pojawiają się nowe artykuły, aktualizacje i zdjęcia, a wcześniej opublikowane materiały mogą być zmieniane.
Przy Delta-Sync cała baza jest przenoszona na początku, a później synchronizowane są tylko treści dodane lub zmienione.
Innym rozwiązaniem jest Dual-Publishing, czyli publikowanie wybranych materiałów równolegle w starym i nowym systemie.
W chwili przełączenia portalu nowy CMS powinien mieć również aktualne treści, a nie wyłącznie archiwum przeniesione kilka dni wcześniej.
Testy przed publikacją
Nowa wersja powinna najpierw działać na środowisku testowym, gdzie można sprawdzić portal bez ingerowania w aktualnie działający serwis.
Taką wersję należy zabezpieczyć przed dostępem z zewnątrz oraz przed indeksowaniem przez Google. Jednym z prostych rozwiązań jest Basic Auth, czyli zabezpieczenie dostępu do strony loginem i hasłem na poziomie serwera.
W testowym serwisie można sprawdzić adresy URL, przekierowania, adresy kanoniczne, mapę witryny, dane strukturalne, obrazy, linkowanie i sposób wyświetlania stron.
Google zaleca dokładne przetestowanie nowej wersji przed rozpoczęciem migracji, a przy zmianie adresów przygotowanie mapowania starych URL-i na nowe.
Sprawdź adres kanoniczny każdej strony
Jedna treść może być dostępna pod kilkoma adresami, dlatego każda strona powinna mieć prawidłowo wskazany adres kanoniczny.
Dla nowej wersji artykułu jako kanoniczny powinien być wskazany właściwy, docelowy adres. Przy zmianie URL-i Google zaleca również aktualizację linków wewnętrznych tak, aby wskazywały nowe adresy.
Jeżeli chcesz uporządkować ten obszar, więcej informacji znajdziesz w naszym materiale o polach SEO.
Google News i Google Discover
Dla portalu informacyjnego ważne są również źródła ruchu związane z Google News i Google Discover.
W nowym systemie powinny zostać zachowane elementy wykorzystywane przy publikacji aktualnych treści, między innymi daty publikacji i modyfikacji, dane strukturalne, obrazy oraz News Sitemap.
Więcej informacji o wymaganiach technicznych związanych z Google News znajdziesz w naszym poradniku o Google News.
O Google Discover warto pamiętać szczególnie przy serwisach, które mają duży udział ruchu z rekomendacji Google. Sama migracja nie gwarantuje utrzymania takiego ruchu, dlatego po uruchomieniu nowej wersji trzeba obserwować dane w Search Console.
CMS4media i migracje portali
CMS4media to nasz system do prowadzenia portali informacyjnych. Łączy panel redakcyjny z narzędziami potrzebnymi przy codziennej publikacji, SEO, reklamach, wyglądzie serwisu i zarządzaniu wieloma portalami.
Mamy doświadczenie w migracjach portali z wieloletnimi archiwami. Przy takich projektach zajmujemy się przenoszeniem treści, adresami URL, przekierowaniami, indeksacją oraz sprawdzeniem serwisu po uruchomieniu.
W 2026 roku na CMS4media przeniesiono sześć portali należących do Hartmann Media Consulting. Ich archiwa obejmowały lata publikacji, dlatego migracja objęła również zdjęcia i metadane. Po uruchomieniu nowych wersji przeprowadzono audyt starych adresów, uporządkowano przekierowania 301 i sprawdzono indeksację oraz dane w Google Search Console.
Po uruchomieniu nowych serwisów kwiecień był jeszcze okresem testów i przyzwyczajania się użytkowników do zmian. Od czerwca wyniki zaczęły rosnąć. W kolejnych miesiącach ruch z Google Discover wzrósł o blisko 41%, a z Google News o 14,9%. Ruch z wyszukiwarki został utrzymany. Są to dane z opisanego case study, opartego na danych powdrożeniowych i rozmowie z wydawcą.
Jeśli korzystasz z paywalla
Jeżeli część treści jest dostępna tylko dla subskrybentów, przy migracji trzeba zachować również informacje o ograniczeniu dostępu.
W nowym systemie powinny pozostać odpowiednie dane strukturalne, między innymi isAccessibleForFree oraz hasPart.
Sprawdź wydajność nowego serwisu
Zmiana CMS-a może zmienić sposób generowania stron, zapytania do bazy danych, cache'owanie oraz obsługę reklam.
Jednym z podstawowych parametrów jest TTFB (Time to First Byte). Warto również sprawdzić rzeczywiste czasy ładowania stron i zachowanie serwisu przy większym ruchu.
Więcej o zależności między szybkością strony i CMS-em a SEO piszemy w osobnym materiale.
Wydawcy korzystają z rozwiązań takich jak Prebid.js. Przy migracji trzeba więc sprawdzić integracje reklamowe, sposób ładowania formatów i działanie powierzchni reklamowej.
Przy większym portalu migracja CMS-a może być też okazją do uporządkowania obsługi reklam i współpracy z reklamodawcami.
Nasi wydawcy mogą korzystać z Ads4media, naszej platformy łączącej portale z reklamodawcami. Platforma działa niezależnie od CMS-a, więc jest dostępna również dla wydawców pracujących na innych systemach.
W Ads4media wydawca może prezentować swoją ofertę reklamową i otrzymywać zlecenia na artykuły sponsorowane, kampanie banerowe i inne formy reklamy. Cała współpraca z reklamodawcami może być prowadzona z jednego miejsca.
CMS powinien pasować do pracy redakcji
Powodem zmiany systemu może być wydajność, brak potrzebnych funkcji, problemy z reklamami albo zbyt duża zależność od pracy programistów.
W praktyce o jakości nowego CMS-a decyduje również to, jak redakcja korzysta z niego każdego dnia: jak szybko publikuje i aktualizuje materiały, jak pracuje ze zdjęciami i galeriami oraz jak łatwo można rozwijać portal.
CMS4media łączy panel redakcyjny z narzędziami do obsługi SEO, reklam, wyglądu serwisu i wielu portali.
Gdy prowadzisz kilka portali
Każdy serwis ma własne treści, ustawienia i historię, ale zaplecze technologiczne może być wspólne.
CMS4media umożliwia zarządzanie wieloma portalami z jednego panelu. Poszczególne serwisy pozostają odrębne, a część procesów można obsługiwać z jednego miejsca.
Co sprawdzić po uruchomieniu?
Po publikacji nowej wersji najważniejsze są ruch, błędy serwera i indeksacja.
Dane z Google Search Console można porównać z okresem sprzed migracji. Szczególną uwagę warto zwrócić na liczbę zaindeksowanych stron, błędy 404 i 5xx oraz zachowanie najważniejszych adresów.
Google zaleca monitorowanie ruchu zarówno na nowej, jak i starej wersji serwisu. W Search Console można obserwować między innymi indeksację, sitemapę i błędy pojawiające się po migracji.
Trzeba też sprawdzić codzienne korzystanie z portalu: działanie na urządzeniach użytkowników oraz czas ładowania stron.
Po migracji obserwuj serwis
Przed rozpoczęciem prac należy przeanalizować obecny portal, przygotować mapę URL-i, zaplanować przeniesienie danych i treści publikowanych w czasie migracji oraz przetestować nową wersję.
Po uruchomieniu trzeba obserwować ruch, indeksację, błędy serwera i wydajność.
Pierwsze dni pozwalają wychwycić problemy techniczne, natomiast pełniejszy obraz daje dopiero obserwacja kolejnych tygodni. Google zwraca uwagę, że widoczność może czasowo się zmieniać podczas migracji, zanim nowe adresy zostaną prawidłowo przetworzone. W opisanym wcześniej case study Hartmann Media Consulting kwiecień był czasem testów i przyzwyczajania się użytkowników do zmian, a wyraźny wzrost wyników był widoczny od czerwca. To pojedynczy przykład, nie reguła, ale daje orientacyjną ramę czasową, na jaką warto się przygotować.
Wtedy można ocenić, czy adresy są prawidłowo indeksowane, ruch zachowuje się zgodnie z oczekiwaniami i czy nowy CMS działa stabilnie pod rzeczywistym obciążeniem.
