Migracja ze starego WordPressa na nowoczesny stack — kiedy redesign nie wystarczy
Nowy motyw nie naprawi wolnego ładowania ani słabego PageSpeed. Czasem jedynym wyjściem jest zmiana silnika strony — i to wcale nie musi być katastrofa.
Większość klientów przychodzi do mnie z prośbą o nową szatę graficzną. Ale gdy zaczynam patrzeć pod maskę ich WordPressa z 2015 roku — okazuje się, że problem nie leży w kolorach ani typografii. Leży w architekturze. I wtedy muszę powiedzieć wprost: redesign tu nie pomoże. Trzeba zmienić silnik.
Kiedy redesign to za mało?
Strona może wyglądać przestarzale, ale jej główne bolączki są głębiej. Czas ładowania powyżej 4 sekund, wyniki Core Web Vitals w czerwieni, plugin blokujący aktualizację PHP bo autor go porzucił — to nie są problemy do naprawienia nowym motywem. To symptomy platformy, która przerosła swoje możliwości lub nigdy ich nie miała.
- Strona ładuje się dłużej niż 3 sekundy na mobile
- PageSpeed Insights pokazuje poniżej 50 punktów na mobile
- Aktualizacja WordPressa regularnie psuje wtyczki
- Motyw jest oparty na page builderze z 2014 roku
- Każda zmiana treści wymaga ingerencji developera
- Hosting kosztuje więcej niż przynosi wartości
- Strona nie wyświetla się poprawnie bez JavaScript
- Brak HTTPS lub mieszana zawartość (mixed content)
Co znaczy zmienić silnik strony?
Nie chodzi o to, żeby wyrzucić wszystko i zacząć od zera — choć czasem i to jest najrozsądniejsza opcja. Chodzi o przeniesienie treści i logiki biznesowej na platformę, która radzi sobie z wymaganiami współczesnego internetu. W moim przypadku domyślnym wyborem jest Next.js na froncie z headless CMS na zapleczu. Treści zostają, adresy URL zostają, SEO zostaje — zmienia się to, co pod spodem.
Jak wygląda taka migracja w praktyce?
Zanim napiszę pierwszą linię kodu, audytuję obecną stronę. Inwentaryzuję typy treści, sprawdzam które URL-e generują ruch organiczny, eksportuję dane z bazy WordPressa. Dopiero potem projektuję architekturę nowego systemu. Migracja idzie etapami — nigdy nie wyłączam starej strony bez wcześniejszego przetestowania każdego przekierowania i zweryfikowania, że nowa wersja działa poprawnie na produkcji.
- Audyt techniczno-contentowy starej strony i eksport danych
- Inwentaryzacja URL-i i przygotowanie mapy przekierowań 301
- Wybór nowego stacku dopasowanego do faktycznych potrzeb klienta
- Przeniesienie treści — ręcznie lub przez API eksport
- Budowa nowej strony i testy równoległe obu wersji
- Uruchomienie nowej wersji z przełączeniem DNS
- Monitoring ruchu i błędów przez 48h po migracji
Czego nie robić podczas migracji?
Największy błąd, jaki widzę, to migracja bez mapowania przekierowań. Firma traci latami budowane pozycje w Google z dnia na dzień, bo nikt nie pomyślał o 301-kach. Drugi błąd to migracja 'na raz' bez okresu równoległego działania obu wersji. Trzeci — wybór nowej platformy pod presją czasową i modą, bez analizy czy faktycznie rozwiązuje konkretne problemy starej strony.
Zmiana silnika strony to poważna decyzja biznesowa. Robiłem to już kilkanaście razy i za każdym razem okazuje się, że przygotowanie zajmuje dwa razy tyle co samo wdrożenie. Ale gdy po migracji PageSpeed skacze z 35 do 95 punktów, a bounce rate spada o 20% — widać wyraźnie, że to była właściwa decyzja.
Jeśli Twoja strona ma podobne objawy jak te opisane wyżej, warto zacząć od rzetelnego audytu technicznego. Dopiero on pokaże, czy wystarczy redesign, czy konieczna jest głębsza zmiana. Nie warto inwestować w nowy wygląd na fundamencie, który i tak trzeba będzie wkrótce rozebrać.
