Modernizacja starszych stron korporacyjnych z WordPress

W 2026 roku stara strona korporacyjna (legacy site) to coś więcej niż tylko nieaktualny design. To balast.

To magazyn długu technicznego, luka w bezpieczeństwie czekająca na wykorzystanie i wąskie gardło, które uniemożliwia zespołowi marketingu reakcję na rynkowe zmiany. Duże korporacje często trzymają się tych systemów, bo myśl o migracji brzmi jak „cyfrowy przeszczep serca”.

Jednak ryzyko pozostania przy starym rozwiązaniu jest obecnie wyższe niż ryzyko zmiany. Drupal 7 przestał dostawać poprawki bezpieczeństwa 5 stycznia 2025 roku, platformy licencjonowane co roku wystawiają fakturę, a utrzymywany WordPress daje nowej stronie udokumentowany zestaw narzędzi do importu, przekierowań i integracji.

W tym przewodniku przechodzimy przez strategiczne i techniczne fazy modernizacji starszej strony korporacyjnej z WordPressem.

#Jak zrobić audyt starej strony przed migracją

Pierwszym krokiem modernizacji nie jest budowanie, lecz inwentaryzacja.

• Dług treści: czy Twoja firma naprawdę potrzebuje wpisów z 2011 roku? Używamy AI do analizy historycznego ruchu i decydujemy, co przenieść, co zarchiwizować, a co usunąć.
• Dług techniczny: mapowanie niestandardowych integracji, których nikt nie dotykał od pięciu lat.
• Kapitał SEO: identyfikacja adresów o najwyższej skuteczności, które muszą zostać zabezpieczone podczas migracji, żeby uniknąć załamania ruchu.

#Po czym poznać, że strona firmowa wymaga przebudowy

• CMS nie dostaje już poprawek bezpieczeństwa. Drupal 7 osiągnął koniec wsparcia 5 stycznia 2025 roku, co ogłosił zespół bezpieczeństwa Drupala, a wiele stron korporacyjnych nadal na nim działa.
• Publikacja nowej strony docelowej wymaga zgłoszenia do programisty zamiast dziesięciu wolnych minut redaktora.
• Marketing chce podłączyć analitykę, CRM albo marketing automation, a platforma nie potrafi rozmawiać z żadnym z tych systemów.

#Lista inwentaryzacji przed migracją strony

Po stronie treści: każda podstrona i jej URL, archiwum aktualności, biblioteka mediów razem z PDF-ami, każdy formularz, funkcje specjalne, takie jak wyszukiwarka czy konfigurator, oraz każda integracja z CRM, ERP lub analityką. Po stronie technicznej: stos technologiczny, Core Web Vitals, ruch organiczny i linki zwrotne dla każdego URL-a, znane podatności i zgodność z WCAG.

Stare zgłoszenia z formularzy i listy newslettera zwykle zawierają dane osobowe. Na gruncie RODO zdecyduj, co faktycznie przenosisz, a co usuwasz, zamiast domyślnie kopiować całą bazę danych.

#Które wtyczki WordPressa zastępują funkcje starego CMS-a

Wszystko, co nie ma wiersza w tej tabeli, to development na zamówienie i ta część projektu wymaga najstaranniejszej wyceny zakresu.

#Headless czy monolityczny WordPress dla strony korporacyjnej

Modernizacja nie zawsze oznacza wymianę 1:1.

• Podejście monolityczne: najlepsze dla marek, które chcą maksymalnej łatwości obsługi dla działów marketingu. Króluje tu edytor blokowy.
• Podejście decoupled (headless): dla korporacji, które potrzebują najwyższego poziomu bezpieczeństwa i chcą serwować treść do aplikacji mobilnych, kiosków i stron z jednego „mózgu” WordPressa.

#Jaka architektura WordPressa pasuje do wielkości strony

Strona z kilkuset podstronami zwykle najlepiej działa na zarządzanym WordPressie (motyw blokowy, ACF Pro, Redis jako object cache, Cloudflare lub Bunny.net przed hostingiem w rodzaju Kinsta czy WP Engine). Wiele tysięcy adresów albo treść zasilająca także aplikacje wskazują na headless: WPGraphQL z frontendem w Astro lub Next.js. Grupy wielojęzyczne często wybierają Multisite z WPML lub Polylang, co opisujemy w przewodniku po globalnej strategii treści w WordPressie.

#Wymagania serwera WordPress przy migracji strony korporacyjnej w 2026

Umowa hostingowa na nową stronę zwykle zostaje podpisana, zanim powstanie pierwszy szablon, więc środowisko uruchomieniowe trzeba określić wcześnie. Oficjalna strona wymagań WordPressa zaleca PHP 8.3 lub nowsze, MySQL 8.0 lub nowszy albo MariaDB 10.11 lub nowszą oraz obsługę HTTPS. WordPress nadal działa na PHP 7.4 i MySQL 5.5.5, ale ta sama strona ostrzega, że te wersje osiągnęły koniec wsparcia i mogą narazić stronę na podatności.

Gałąź PHP decyduje, jak długo nowa platforma działa do pierwszej wymuszonej aktualizacji. Daty pochodzą ze strony wspieranych wersji PHP:

Strona uruchomiona w 2026 roku na PHP 8.2 traci poprawki bezpieczeństwa z końcem tego samego roku. Wpisz PHP 8.3 albo 8.4 do specyfikacji hostingu, a ścieżkę aktualizacji do kolejnej gałęzi do umowy serwisowej, żeby problem starego systemu nie zaczął się od nowa na nowej platformie.

Jeśli zastępowana strona to już stara instalacja WordPressa, a nie inny CMS, praca dotyczy głównie kodu (motywu, wtyczek, bazy danych) i tę ścieżkę opisuje nasz przewodnik po modernizacji starszych baz kodu WordPress.

#Jak przenieść treści ze starego CMS-a do WordPressa

Migracja danych ze starego, zamkniętego CMS-a do WordPressa kiedyś była pracą ręczną. Dziś to proces mapowania oparty na skryptach.

• Normalizacja pól: bierzemy nieustrukturyzowane treści i mapujemy je na ustrukturyzowane bloki WordPressa.
• Migracja zasobów: przenoszenie tysięcy zdjęć i PDF-ów z zachowaniem linkowania wewnętrznego i metadanych SEO.

#Jak zaimportować treści ze starego CMS-a przez WP-CLI

WordPress nie ma importera dla Sitecore, autorskiego portalu .NET ani większości systemów zamkniętych. Standardowa droga to eksport ze starej platformy własnym skryptem, zapis wyniku jako plik WXR (format XML, którego używa eksport samego WordPressa) i import tego pliku z linii poleceń.

• wp import to interfejs linii poleceń do wtyczki WordPress Importer. Opcja --authors przyjmuje create, mapping.csv albo skip, więc konta autorów ze starego systemu można przypisać do istniejących kont redaktorów przez plik CSV zamiast zakładać je pojedynczo.
• wp media import tworzy załączniki z plików lokalnych lub adresów URL. Przyjmuje --post_id, żeby przypiąć plik do właściwej strony, --alt dla tekstu alternatywnego i --preserve-filetime, żeby zachować datę pliku jako datę publikacji.
• wp search-replace podmienia stare ścieżki i domeny w całej bazie. Poprawnie obsługuje zserializowane dane PHP, a --dry-run pokazuje każdą zmianę bez zapisu i właśnie ten przebieg warto przejrzeć przed właściwym.

Import uruchamiaj na stagingu, porównaj liczbę stron dla każdego szablonu z inwentaryzacją i dopiero potem powtórz go jako końcowy import różnicowy tuż przed startem.

#Etapy migracji strony krok po kroku

1. Przygotowanie. Zamroź listę adresów z ruchem dla każdego URL-a, przygotuj szkic mapy przekierowań, napisz skrypty eksportu ze starego CMS-a i postaw środowisko stagingowe.
2. Budowa. Zbuduj frontend, wdroż mapę funkcji, podłącz integracje, potem uruchom import skryptami.
3. Testy. QA funkcjonalne na różnych urządzeniach i przeglądarkach, QA treści względem inwentaryzacji, QA SEO przekierowań, metadanych, map stron i danych strukturalnych, przegląd Core Web Vitals, pełny audyt bezpieczeństwa WordPressa i kontrola WCAG 2.2.
4. Start. Najpierw spisz procedurę wycofania zmian, potem przełącz DNS, włącz przekierowania, zgłoś nową mapę strony w Google Search Console i przez pierwsze 48 godzin uważnie obserwuj ruch, błędy i wydajność.
5. Po starcie. Porównaj ruch organiczny z okresem przed migracją, popraw zabłąkane błędy 404 i przeszkol redaktorów.

#Jak nie stracić pozycji w Google przy migracji strony

Projekt modernizacji kończy się porażką, jeśli stracisz pozycje w wyszukiwarce.

• Mapowanie URL: tworzymy mapę 1:1 starych adresów na nowe. Jeśli stara strona używała rozszerzeń .aspx lub .cgi, dbamy, by wskazywały bezpośrednio na przyjazne dla SEO slugi WordPressa.
• Zachowanie metadanych: eksportujemy wszystkie tagi title i meta opisy ze starego systemu, by zachować ciągłość w oczach Google.

Najlepsze przekierowanie to takie, którego nie trzeba robić, więc zachowuj adresy bez zmian wszędzie, gdzie nowa struktura na to pozwala. Poza tytułami i opisami przenieś tagi canonical, hreflang, linki wewnętrzne i dane strukturalne.

Jeśli ruch organiczny nie zaczyna wracać mniej więcej cztery tygodnie po starcie, sprawdzaj w tej kolejności: brakujące lub błędne przekierowania, raport indeksowania stron w Search Console, zasoby zablokowane przed renderowaniem i tagi canonical, które nadal wskazują stare adresy.

#Co Google zaleca przy przenosinach strony ze zmianą adresów URL

Google opisuje dokładnie ten scenariusz w przewodniku o przenoszeniu witryny ze zmianą adresów URL. Punkty, które zmieniają plan migracji strony korporacyjnej:

• Stosuj stałe przekierowania po stronie serwera (301 lub 308) z każdego starego adresu na nowy i utrzymuj je tak długo, jak się da, zasadniczo co najmniej rok.
• Strony celowo wycofane powinny na nowej stronie zwracać 404 lub 410 zamiast przekierowywać na stronę główną.
• Zaktualizuj linki wewnętrzne do nowych adresów z mapy i upewnij się, że każda mapa witryny zawiera nowe adresy.
• Usuń tagi noindex i blokady w robots.txt, które były potrzebne tylko na etapie stagingu. To najczęstszy błąd dnia startu, bo staging jest słusznie ukryty, a ustawienie przechodzi na produkcję razem z bazą danych.
• Narzędzie do zmiany adresu w Search Console służy tylko do przenosin na inną domenę lub subdomenę. Przebudowa w tej samej domenie go nie wymaga.

Google podaje też, że przy stronie średniej wielkości może minąć kilka tygodni lub więcej, zanim nowe adresy pojawią się w wynikach, a przy dużych stronach dłużej. Raportowanie do zarządu zaplanuj pod to okno, zamiast oceniać migrację po pierwszym tygodniu.

#Jak zabezpieczyć firmową stronę na WordPressie

Niezałatany CMS to łatwy cel, bo jego znane podatności są publiczne i nigdy nie zostaną naprawione. Przejście na utrzymywany WordPress pozwala na:

• Hosting ze ścieżką audytu: wybierz dostawcę zarządzanego hostingu, który przekaże Twojemu zespołowi bezpieczeństwa raport SOC 2 lub ISO 27001, zamiast serwera, którego nikt nie aktualizował od odejścia pierwotnej agencji.
• Logowanie redaktorów przez firmowe SSO: logowanie przez Okta lub Microsoft Entra ID za pomocą SAML albo OpenID Connect, tak żeby usunięcie pracownika z katalogu odbierało mu też dostęp do wp-admin.

#Jak połączyć WordPress z systemami firmy przez API

Stare połączenia z bazą danych, które „rozmawiały” ze starą stroną, zastępujemy nowoczesnymi nakładkami API. WordPress działa jako warstwa prezentacji, która komunikuje się z systemami zaplecza przez zabezpieczone endpointy JSON, dzięki czemu strona jest szybsza i odporniejsza na awarie.

#Jak uwierzytelniać integracje z REST API WordPressa

CRM, ERP albo PIM, który zapisuje treści w WordPressie, potrzebuje własnych danych dostępowych. Według podręcznika uwierzytelniania REST API WordPress od wersji 5.6 ma hasła aplikacji (Application Passwords). Generuje się je na ekranie edycji użytkownika i przesyła przez Basic Auth w zapytaniach obsługiwanych po HTTPS.

Załóż osobnego użytkownika WordPressa dla każdej integracji, nadaj mu najniższą rolę, która wystarcza do zadania, i wygeneruj mu osobne hasło aplikacji. Gdy kończy się umowa z dostawcą, unieważnienie tego jednego hasła odcina mu dostęp bez ruszania kont redaktorów. Zapytania wysyłane z przeglądarki w zalogowanej sesji korzystają z uwierzytelniania ciasteczkiem i muszą zawierać nonce wp_rest, inaczej WordPress traktuje je jako nieuwierzytelnione.

#Jak poprawić Core Web Vitals po migracji na WordPress

Stare strony prawie zawsze są wolne. Modernizacja do WordPressa daje:

• Nowoczesne formaty obrazów: od WordPressa 6.5 można wgrywać i używać obrazów AVIF tak jak JPEG czy PNG, o ile biblioteka Imagick lub GD na serwerze obsługuje AVIF. Automatyczna konwersja istniejących plików wymaga filtra, więc zaplanuj ją jako część importu mediów.
• Cache na brzegu sieci: serwowanie strony korporacyjnej z lokalizacji CDN blisko odwiedzających zamiast z jednego serwera źródłowego.

#Jak policzyć ROI migracji strony

Nie ma uniwersalnej liczby ROI. Z projektu na projekt przenosi się struktura obliczenia.

Dwa typowe punkty wyjścia zachowują się różnie. Przy migracji z Drupala 7 nie ma licencji do wypowiedzenia, punkt zwrotu przychodzi później, a mocniejszym argumentem jest ryzyko: platforma bez poprawek bezpieczeństwa to incydent czekający na datę. Przy migracji z licencjonowanego CMS-a, takiego jak Sitecore, znika największa pozycja rocznego budżetu, a okres zwrotu to w przybliżeniu koszt projektu podzielony przez roczną oszczędność.

Dodaj też kolumnę zgodności. Europejski akt o dostępności (EAA) obowiązuje od 28 czerwca 2025 roku dla wielu usług cyfrowych kierowanych do konsumentów w UE, a w Polsce podmioty publiczne działają na podstawie ustawy o dostępności cyfrowej z 2019 roku. Sam projekt modernizacji wyceniamy indywidualnie po audycie.

#Agencja do migracji starych stron korporacyjnych na WordPress

W WPPoland praca przy migracjach starych stron opiera się na trzech rzeczach.

1. Specjaliści od migracji: obsługiwaliśmy transfery z Sitecore, Drupala 7 i autorskich portali .NET. Dla migracji CMS enterprise z zachowaniem URL (z TYPO3 na WordPress) metoda jest opisana w studium przypadku migracji TYPO3.
2. Obrona SEO: każda migracja zaczyna się od zamrożonej inwentaryzacji adresów i przetestowanej mapy przekierowań, a kończy kontrolą błędów 404, indeksowania i ruchu organicznego względem stanu sprzed migracji.
3. Budowanie na przyszłość: nie tylko naprawiamy starą stronę, budujemy fundament pod wzrost w 2027 i 2028 roku.

#Najczęstsze pytania o modernizację starej strony

1. Czy będzie przestój? Nie. Przy wdrożeniu blue-green nowa strona powstaje i jest testowana równolegle, a stara obsługuje odwiedzających, dopóki DNS lub load balancer nie wskaże nowej.
2. Jak przeszkolić zespół z nowego systemu? WordPress jest wyraźnie prostszy w obsłudze niż większość starych systemów. Przygotowujemy dla zespołu dokumentację wewnętrzną bezpośrednio w kokpicie WordPressa.
3. Co jest tańsze: przebudowa czy łatanie? W całym cyklu życia platformy zwykle wygrywa przebudowa, a sekcja o ROI powyżej pokazuje, jak sprawdzić to na własnych fakturach. Łatanie starego systemu przypomina klejenie taśmą tonącego statku.

#Podsumowanie

Zobacz nasze projekty migracji WordPress, jeśli planujesz przebudowę albo przejście na Astro lub Next.js. Stara technologia nie staje się przestarzała z dnia na dzień, ale koszt zwłoki rośnie. Jeśli strona korporacyjna nadal działa na kruchym stosie z 2018 roku, słaba wydajność, ryzyko bezpieczeństwa i tarcie redakcyjne będą wracać. Uporządkowana modernizacja z WordPressem pozwala zachować to, co działa, i wymienić części, które blokują firmę.

Jeśli stara strona spowalnia zespół, spisz obecny stos technologiczny, ryzykowne integracje i najważniejsze podstrony. To wystarczy, żeby zacząć sensowny brief modernizacji.

#Co ustalić przed migracją strony

Harmonogram kształtują trzy decyzje. Pierwsza to werdykt dla treści: każda stara podstrona dostaje podczas audytu oznaczenie przenieś, zarchiwizuj albo usuń, a adresy o najlepszych wynikach trafiają na listę chronionych. Ta lista staje się mapą przekierowań 301, łącznie ze starymi adresami .aspx czy .cgi, które muszą trafić na nowe slugi WordPressa.

Druga to architektura. Monolit z Gutenbergiem pasuje do zespołu marketingu, który edytuje codziennie, a układ decoupled do firmy, która z tej samej treści zasila też aplikacje mobilne albo kioski. Zmiana tej decyzji w połowie projektu oznacza przebudowę szablonów.

Trzecia to integracje. Spisz każdy system zaplecza, z którym rozmawia stara strona, na przykład SAP albo autorski CRM, i zdecyduj, które dostaną nakładkę API, a które odejdą razem ze starą platformą. Dopisz do tej listy SSO, żeby dostęp pracowników do strony wynikał z dostawcy tożsamości.

Po tych trzech decyzjach terminy z FAQ, około 3 do 5 miesięcy dla średniej strony korporacyjnej i 6 do 12 dla globalnej sieci, stają się czymś, pod co da się planować. Migrację równoległą i przełączenie blue-green przeprowadzaj dopiero, gdy mapa przekierowań jest ostateczna.