Checklista migracji WordPressa krok po kroku

Jak korzystać z checklisty

Checklista sprawdzi się niezależnie od tego, czy przenosisz stronę z WordPressa na Next.js, Webflow lub Shopify, przebudowujesz ją na nowym motywie WordPressa, czy zmieniasz hosting. Nie każdy punkt dotyczy każdego projektu: przebudowa motywu z zachowaniem wszystkich adresów URL może pominąć większość pracy nad przekierowaniami, a zmiana platformy z nową strukturą adresów wymaga jej w całości.

Skopiuj punkty do swojego narzędzia do zarządzania projektami, przypisz każdemu osobę odpowiedzialną i ustal termin względem dnia publikacji. Większość problemów przy migracji to nie awarie techniczne, tylko zadania, o których każdy myślał, że zajmuje się nimi ktoś inny.

Inwentaryzacja i stan wyjściowy

Nie ochronisz tego, czego nie masz zapisanego. Zrób to przed rozpoczęciem jakichkolwiek prac i zanim cokolwiek zmieni się na działającej stronie.

Treści i adresy URL

Przeskanuj całą stronę crawlerem i wyeksportuj każdy adres URL z kodem odpowiedzi, tytułem, meta opisem, nagłówkiem H1, tagiem kanonicznym i informacją o indeksowalności.
Dołącz adresy z mapy strony XML, z raportu indeksowania stron w Search Console oraz strony docelowe z analityki z ostatnich 12 miesięcy.
Wskaż podstrony z największym ruchem organicznym, największą liczbą konwersji i linków przychodzących; na każdym kolejnym etapie poświęć im szczególną uwagę.
Spisz typy treści, szablony, taksonomie (kategorie, tagi, własne taksonomie) i autorów.
Wyeksportuj istniejące przekierowania z wtyczek do przekierowań, pliku .htaccess lub konfiguracji serwera; je także trzeba przenieść.
Dla każdego adresu URL zdecyduj: przenieść bez zmian, połączyć z innym, przekierować czy wycofać.

Funkcje

Spisz każdą aktywną wtyczkę i to, co robi, a potem przy każdej funkcji zaznacz: odtworzyć, zastąpić usługą czy zrezygnować.
Udokumentuj każdy formularz: pola, odbiorców, integracje, komunikaty potwierdzające i ochronę przed spamem.
Spisz skrypty zewnętrzne: analitykę, menedżera tagów, piksele reklamowe, widżety czatu, narzędzie do zarządzania zgodami, osadzone elementy.
Poszukaj ukrytych funkcji: zadań cyklicznych, automatycznych e-maili, webhooków, kont użytkowników i procesów w panelu administracyjnym.

Stan wyjściowy

Sesje organiczne i konwersje dla każdej strony docelowej, najlepiej w podziale na tygodnie z ostatnich kilku miesięcy.
Kliknięcia, wyświetlenia i najważniejsze zapytania z Search Console. Wyeksportuj je, bo Search Console przechowuje dane o skuteczności tylko przez około 16 miesięcy.
Liczbę zaindeksowanych podstron i ewentualne istniejące błędy indeksowania lub skanowania.
Dane z rzeczywistego użycia (field data) dla Core Web Vitals, jeśli są dostępne, oraz laboratoryjne wyniki PageSpeed dla każdego kluczowego szablonu.
Każdy eksport zapisz z datą. Po publikacji będą potrzebne, żeby odróżnić prawdziwe zmiany od wahań sezonowych.

Analiza SiteRefactor może być tu przydatną migawką: wykryte technologie i wtyczki, wyniki PageSpeed, podstawy SEO i szacunkowa liczba podstron na podstawie mapy strony. Sprawdza do 20 podstron, więc uzupełnia pełny crawl, a nie go zastępuje.

Kopie zapasowe i środowisko testowe

Zrób pełną kopię zapasową plików i bazy danych, przechowuj jej egzemplarz poza serwerem i sprawdź, czy da się ją faktycznie przywrócić.
Wyeksportuj też treści w przenośnym formacie (eksport XML WordPressa, CSV lub zrzut z API).
Przechowuj kopie zapasowe przez kilka miesięcy po publikacji; problemy czasem wychodzą na jaw dopiero po kilku tygodniach.
Zabezpiecz środowisko testowe hasłem lub ograniczeniem dostępu do wybranych adresów IP, a nie tylko tagiem noindex czy plikiem robots.txt, żeby nie dało się go zaindeksować ani przypadkiem upublicznić.
Uzgodnij zamrożenie treści albo plan synchronizacji treści, które w trakcie budowy będą edytowane na działającej stronie.
Spisz wszystkie konta i osoby z dostępem: rejestrator domeny, DNS, hosting, CDN, poczta (rekordy MX), Search Console, analityka, menedżer tagów i wszelkie abonamenty platform.

Mapowanie adresów URL i przekierowania 301

Przekierowania to najważniejsza ochrona widoczności w wyszukiwarce i linków przychodzących.

Tworzenie mapy przekierowań

Zachowaj istniejące adresy URL wszędzie tam, gdzie pozwala na to nowa platforma. Każdy zachowany adres to jedno przekierowanie mniej.
Przypisz każdy zmieniony adres jeden do jednego do jego najbliższego odpowiednika. Nie kieruj wszystkiego na stronę główną.
Treści celowo usunięte bez zamiennika niech zwracają kod 404 lub 410, zamiast przekierowywać na niezwiązaną z nimi podstronę.
Uwzględnij adresy, o których łatwo zapomnieć: archiwa kategorii, tagów i autorów, paginację (np. /page/2/), strony załączników, kanały RSS, pliki PDF i obrazy w /wp-content/uploads/, do których prowadzą linki z zewnątrz, oraz adresy z parametrami, które mają ruch.
Zaktualizuj stare przekierowania tak, żeby prowadziły prosto do docelowego adresu, bez łańcuchów.

Wdrożenie i testy

Używaj przekierowań stałych (301 lub 308), a nie tymczasowych (302 lub 307).
Ujednolij protokół, host i ukośniki na końcu adresów: HTTP na HTTPS, jedna wersja (z www albo bez), jedna konwencja ukośnika.
Przetestuj automatycznie całą mapę w środowisku testowym: każdy stary adres powinien trafiać na podstronę z kodem 200 jednym przekierowaniem.
Zaktualizuj linki wewnętrzne, menu i przyciski tak, żeby prowadziły do nowych adresów, zamiast polegać na przekierowaniach.

Metadane, tagi kanoniczne i hreflang

Metadane

Przenieś tytuły podstron i meta opisy, również te zapisane przez Yoast, Rank Math lub podobne wtyczki.
Nie przepisuj wszystkich tytułów w trakcie migracji; gdy zmieniasz jedną rzecz naraz, łatwiej zdiagnozujesz problemy.
Sprawdź strukturę nagłówków: jeden wyraźny nagłówek H1 na podstronę i logiczna hierarchia.
Odtwórz tagi Open Graph i inne tagi do udostępniania w mediach społecznościowych, łącznie z obrazami.

Tagi kanoniczne i indeksowanie

Każda indeksowalna podstrona ma tag kanoniczny wskazujący na samą siebie, z bezwzględnym adresem produkcyjnym.
Domena środowiska testowego nie pojawia się nigdzie: w tagach kanonicznych, mapach strony, adresach Open Graph ani w linkach wewnętrznych.
Meta tagi robots i plik robots.txt pozwalają skanować wszystko, co ma być zaindeksowane, łącznie z plikami CSS i JavaScript.
Mapa strony XML zawiera tylko kanoniczne, indeksowalne adresy zwracające kod 200 i jest wskazana w pliku robots.txt.
Decyzje o indeksowaniu archiwów, tagów i paginacji są takie same jak na starej stronie, chyba że świadomie je zmieniasz.

hreflang (strony wielojęzyczne)

Każda wersja językowa wskazuje wszystkie wersje alternatywne, łącznie z samą sobą, a oznaczenia są wzajemne.
Używaj adresów bezwzględnych zgodnych z adresami kanonicznymi oraz x-default tam, gdzie masz stronę wyboru języka lub wersję domyślną.
W planie przekierowań przypisz osobno każdy adres w każdym języku, na przykład w wersji polskiej i angielskiej; struktury wielojęzyczne to częste źródło błędów.

Dane strukturalne i media

Dane strukturalne

Spisz istniejące dane strukturalne: Organization, WebSite, BreadcrumbList, Article, Product, LocalBusiness i inne. Wtyczki SEO dodają dużą część z nich automatycznie, dlatego łatwo je zgubić.
Odtwórz je na nowej stronie i zweryfikuj w teście wyników z elementami rozszerzonymi (Rich Results Test) lub w Schema Markup Validator.
Upewnij się, że dane strukturalne zgadzają się z treścią widoczną na podstronie.

Media

Przenieś wszystkie obrazy, dokumenty i filmy, a adresy plików, do których prowadzą linki, zachowaj lub przekieruj.
Zachowaj teksty alternatywne i podpisy; często są przechowywane osobno od samych plików.
Serwuj responsywne rozmiary i nowoczesne formaty, podawaj wymiary obrazów, żeby uniknąć przesunięć układu, i ładuj leniwie obrazy poniżej pierwszego ekranu.
Wyszukaj na nowej stronie obrazy, które nadal ładują się ze starej domeny lub ze środowiska testowego.

Formularze

Odtwórz każdy formularz i przetestuj go od początku do końca: walidację, ochronę przed spamem, e-maile z powiadomieniami, synchronizację z CRM lub newsletterem i komunikat potwierdzający.
Sprawdź, czy e-maile z powiadomieniami docierają, a domeny wysyłkowe są poprawnie uwierzytelnione (SPF, DKIM, DMARC).
Potwierdź, że śledzenie konwersji nadal działa po wysłaniu formularza.

Analityka

Zainstaluj analitykę lub kontener menedżera tagów na każdym szablonie i sprawdź, czy kluczowe zdarzenia i konwersje są rejestrowane.
Wyklucz ruch ze środowiska testowego i dodaj adnotację z datą publikacji.
Zweryfikuj własność w Search Console w sposób, który przetrwa migrację; najbardziej niezawodna jest usługa typu „domena” zweryfikowana przez DNS.

Zgody i prywatność

Tam, gdzie wymagana jest zgoda, na przykład w UE (a więc także w Polsce) i w Zjednoczonym Królestwie, sprawdź, czy skrypty, które nie są niezbędne, nie ładują się przed jej udzieleniem.
Sprawdź, czy baner zgód zapisuje wybory i czy odwiedzający mogą je później zmienić.
Zaktualizuj politykę prywatności i informacje o plikach cookie, jeśli zmieniają się narzędzia lub przepływy danych.

Wydajność

Porównaj każdy kluczowy szablon ze stanem wyjściowym w PageSpeed Insights, a gdy pojawi się wystarczająco dużo prawdziwego ruchu, także z danymi z rzeczywistego użycia.
Sprawdź nagłówki cache, kompresję, konfigurację CDN i ładowanie fontów.
Ustal budżet na skrypty zewnętrzne; menedżery tagów i widżety często niweczą zyski z przebudowy.
Testuj na telefonie ze średniej półki przy spowolnionym łączu, a nie tylko na szybkim laptopie.
Nie publikuj strony wolniejszej od tej, którą zastępuje, bez udokumentowanego powodu i planu naprawy.

Testy przed publikacją

Przeskanuj środowisko testowe pod kątem niedziałających linków, brakujących lub zduplikowanych tytułów, niezamierzonych tagów noindex, błędów w tagach kanonicznych i mieszanej zawartości (mixed content).
Przejrzyj każdy szablon na telefonie, tablecie i komputerze w najpopularniejszych przeglądarkach.
Porównaj 20–50 podstron z największym ruchem ze starą wersją, jedna obok drugiej: treść, nagłówki, obrazy, linki i wezwania do działania.
Sprawdź podstawy dostępności: obsługę z klawiatury, widoczny fokus, kontrast kolorów, teksty alternatywne i etykiety pól formularzy.
Upewnij się, że własna strona błędu 404 zwraca faktyczny kod 404.
Sprawdź HTTPS, nagłówki bezpieczeństwa i to, czy żadne adresy panelu, środowiska testowego ani narzędzi do debugowania nie są publicznie dostępne.
W sklepach: złóż testowe zamówienia każdą metodą płatności i sprawdź podatki, wysyłkę, e-maile o zamówieniach i zwroty.
Pokaż redaktorom, jak w nowym systemie publikować, podglądać i planować treści.

Dzień publikacji

24–48 godzin wcześniej

Obniż TTL rekordów DNS, które będziesz zmieniać, na przykład do 300 sekund. Zrób to z wyprzedzeniem co najmniej równym obecnemu TTL, żeby serwery DNS zdążyły pobrać krótszą wartość przed przełączeniem.
Wybierz okno o małym ruchu na początku tygodnia, gdy cały zespół jest dostępny. Unikaj piątkowych popołudni i okresów szczytu sprzedaży, takich jak czas przed świętami.
Spisz plan wycofania zmian: co go uruchamia, kto podejmuje decyzję i jak przywrócić poprzednie ustawienia DNS.

W trakcie przełączenia

Wykonaj ostatnią synchronizację treści, jeśli coś zmieniło się w czasie zamrożenia.
Zmień tylko te rekordy DNS, które zamierzasz zmienić; rekordy MX i inne związane z pocztą zostaw bez zmian.
Potwierdź ważny certyfikat TLS dla każdej nazwy hosta, zarówno dla wersji z www, jak i dla domeny głównej.
Usuń z produkcji zabezpieczenia i ustawienia noindex przeniesione ze środowiska testowego, a potem sprawdź plik robots.txt i meta tagi robots na działających podstronach.
Uruchom test przekierowań na środowisku produkcyjnym.
Zgłoś nową mapę strony XML w Search Console i sprawdź kilka kluczowych adresów narzędziem do sprawdzania adresów URL.
Wyślij każdy formularz, a w sklepie złóż prawdziwe zamówienie.
Potwierdź, że analityka rejestruje wizyty na działającej stronie.

Po przełączeniu

Utrzymuj starą stronę i hosting, ale bez możliwości indeksowania, dopóki nowa strona nie zacznie działać stabilnie.
Gdy przez kilka dni wszystko działa stabilnie, przywróć zwykłą wartość TTL.

Monitoring po publikacji (4–8 tygodni)

Pierwszy tydzień: codziennie

Sprawdzaj logi błędów 404 i błędów serwera, a dla brakujących adresów, które mają ruch lub linki przychodzące, dodawaj przekierowania.
Obserwuj raport indeksowania stron i statystyki indeksowania w Search Console pod kątem nagłych zmian.
Upewnij się, że zgłoszenia z formularzy, konwersje, a w sklepach także zamówienia, napływają na normalnym poziomie.

Od drugiego do ósmego tygodnia: co tydzień

Porównuj kliknięcia, wyświetlenia i konwersje z ruchu organicznego ze stanem wyjściowym, zestawiając te same dni tygodnia i uwzględniając sezonowość.
Śledź pozycje i strony docelowe dla najważniejszych zapytań.
Przeglądaj Core Web Vitals w miarę gromadzenia się danych z rzeczywistego użycia.
Poproś partnerów, którzy linkują do Twoich najważniejszych starych adresów, o zaktualizowanie linków.

Pewne wahania ruchu z wyszukiwarki są normalne, dopóki roboty ponownie skanują stronę. Jeśli spadek utrzymuje się przez kilka tygodni, przejdź systematycznie przez mapę przekierowań, raporty indeksowania i różnice w szablonach. Utrzymuj przekierowania co najmniej przez rok, a najlepiej na stałe.

Najczęstsze błędy

Publikacja z ustawieniami środowiska testowego: tag noindex na całej stronie albo Disallow: / w pliku robots.txt przeniesione na produkcję.
Przekierowanie wszystkiego na stronę główną zamiast przypisania adresów do ich rzeczywistych odpowiedników.
Pominięcie adresów, które nie są podstronami: obrazów, plików PDF, kanałów RSS i archiwów, do których prowadzą linki z zewnątrz.
Łańcuchy przekierowań powstałe przez nakładanie nowych przekierowań na stare.
Zmiana wszystkiego naraz: domeny, adresów, wyglądu i treści w jednym wydaniu, przez co trudno ustalić przyczynę ewentualnego spadku.
Brak stanu wyjściowego: bez zapisanych eksportów nikt nie oceni, czy ruch naprawdę się zmienił.
Zepsute śledzenie wzięte za utratę ruchu: brakujący tag analityki może wyglądać jak załamanie ruchu.
Zepsucie poczty podczas zmiany DNS przez nadpisanie rekordów MX.
Rezygnacja ze starego hostingu dzień po publikacji, zanim kopie zapasowe i możliwość wycofania zmian przestaną być potrzebne.

Wciąż zastanawiasz się, czy w ogóle migrować? Nasze poradniki z WordPressa na Next.js, z WordPressa na Webflow oraz o kosztach migracji strony omawiają zalety i wady każdej drogi, także to, kiedy lepszym wyborem jest usprawnienie obecnej strony.