WordPress dla dużych serwisów i portali. 8 decyzji, które trzeba podjąć przed pierwszą linijką kodu

WordPress dobrze sprawdza się w dużych serwisach: portalach informacyjnych, bazach wiedzy, katalogach firm i serwisach z wieloma autorami. Problemy, które klienci przypisują „WordPressowi”, prawie zawsze wynikają z decyzji podjętych na początku projektu albo z ich braku. Poniżej osiem decyzji, które przy każdym dużym serwisie omawiamy jeszcze przed projektem graficznym.

1. Model treści: typy, pola i taksonomie

W małej stronie wystarczą wpisy i strony. W portalu każdy rodzaj treści, który ma inną strukturę, powinien być osobnym typem treści (custom post type): artykuł, wydarzenie, firma w katalogu, autor zewnętrzny, oferta. Każdy typ dostaje własne pola (na przykład data i miejsce wydarzenia) i własne taksonomie (kategorie, tagi, regiony).

Dobrze zaplanowany model daje trzy korzyści: redakcja wypełnia pola zamiast formatować tekst ręcznie, szablony same układają treść spójnie, a dane strukturalne dla Google i odpowiedzi AI można generować automatycznie z pól. Typowy błąd to setki tagów zakładanych „przy okazji”. Każdy tag tworzy osobną podstronę archiwum, często z jednym wpisem, czyli słabą stronę w indeksie.

2. Struktura adresów URL na lata

Adres wpisu trudno zmienić bez kosztów. Ustal na starcie, czy w adresie jest kategoria, data, czy tylko nazwa wpisu. W serwisach, które przenoszą artykuły między działami, kategoria w adresie zwykle szkodzi, bo każda zmiana działu to nowy adres i kolejne przekierowanie. Zaplanuj też adresy archiwów i paginacji, żeby nie powstawały duplikaty.

3. Hosting dobrany do ruchu, nie do ceny

Oficjalne wymagania WordPressa zalecają PHP w wersji 8.3 lub nowszej oraz MySQL 8.0 lub MariaDB 10.11 i nowsze. Starsze wersje nadal działają, ale WordPress.org ostrzega, że nie mają już wsparcia i mogą narażać stronę na luki bezpieczeństwa. Przy portalu liczą się też: limit procesów PHP, ilość pamięci, osobne środowisko testowe (staging) i możliwość uruchomienia Redis lub Memcached. Hosting współdzielony, który świetnie obsługuje wizytówkę, przy kilkudziesięciu tysiącach wpisów i ruchu z mediów społecznościowych bywa wąskim gardłem.

4. Cache na trzech poziomach

• Cache stron zapisuje gotowy HTML i oddaje go kolejnym czytelnikom bez uruchamiania PHP i bazy danych.
• CDN, na przykład Cloudflare, serwuje pliki i strony z serwera blisko czytelnika i chroni przed nagłym skokiem ruchu.
• Trwały cache obiektów (persistent object cache) przechowuje wyniki zapytań do bazy między kolejnymi wywołaniami. Dokumentacja WordPressa wymienia jako popularne silniki Redis, Memcached, APC i system plików. Przy dużym serwisie to często różnica między panelem, który się „mieli”, a panelem, który działa płynnie, bo redakcja zalogowana zwykle omija cache stron.

Efekt mierzysz w Core Web Vitals. Google uznaje wynik za dobry, gdy dla 75% wizyt LCP (wczytanie głównej treści) wynosi do 2,5 s, INP (reakcja na kliknięcie) do 200 ms, a CLS (przesunięcia układu) do 0,1. Jak czytać te wyniki, opisuję w tekście o Core Web Vitals w PageSpeed Insights.

5. Wyszukiwarka wewnętrzna

Wbudowana wyszukiwarka WordPressa przeszukuje bazę prostym dopasowaniem tekstu. Przy kilkuset wpisach to wystarcza. Przy dziesiątkach tysięcy jest wolna, nie odmienia polskich słów i słabo układa wyniki według trafności. W portalach stosujemy dedykowany indeks wyszukiwania, na przykład Elasticsearch lub OpenSearch, albo wtyczkę z własnym indeksem. To decyzja, którą warto podjąć przed startem, bo wpływa na hosting i budżet.

6. Zadania w tle: WP-Cron i importy

WordPress domyślnie uruchamia zaplanowane zadania (publikacja o zadanej godzinie, wysyłki, czyszczenie) przy okazji wizyt na stronie. Dokumentacja dla deweloperów opisuje, jak wyłączyć ten mechanizm i podpiąć zadania pod systemowy cron serwera. W portalu robimy to zawsze: zadania wykonują się punktualnie i nie spowalniają wizyt czytelników. Importy danych z zewnętrznych systemów uruchamiamy w paczkach, a nie jednym długim procesem.

7. Redakcja: role, akceptacja, porządek w bazie

WordPress ma wbudowane role: administrator, redaktor, autor, współpracownik i subskrybent. Współpracownik może pisać, ale nie publikuje. Redaktor publikuje i edytuje teksty innych. W wielu redakcjach to wystarcza bez dodatkowych wtyczek. Konta administratora powinny mieć tylko osoby, które naprawdę zarządzają serwisem.

Ustaw też limit wersji wpisów (rewizji). Każdy zapis szkicu może tworzyć kolejną kopię w bazie, a przy tysiącach artykułów i wielu autorach baza rośnie bez potrzeby. Podobnie z ustawieniami ładowanymi przy każdym wywołaniu strony: wtyczki usunięte bez sprzątania zostawiają w bazie dane, które spowalniają każdą podstronę.

8. Migracja bez utraty ruchu z Google

Przy przenosinach dużego serwisu najwięcej ruchu traci się na adresach, o których nikt nie pamiętał. Zanim zaczniemy, robimy pełną listę adresów (mapa witryny, Search Console, logi serwera), mapę przekierowań 301 stary adres → nowy adres i test na środowisku testowym. Google zaleca utrzymywać przekierowania jak najdłużej, zwykle co najmniej rok. Po starcie przez kilka tygodni sprawdzamy w Search Console błędy 404 i indeksowanie. Ogólne zasady przeprowadzki opisuję w tekście o przeniesieniu strony bez przerwy w działaniu.

Kiedy WordPress nie jest dobrym wyborem

Uczciwie: nie każdy duży projekt powinien powstać na WordPressie. Jeśli serwis to w praktyce aplikacja, w której każdy użytkownik widzi inne dane w czasie rzeczywistym (giełda, rozbudowany marketplace z rozliczeniami między sprzedawcami, system rezerwacji z dziesiątkami zasobów), lepiej rozważyć dedykowany framework. WordPress jest najmocniejszy tam, gdzie centrum serwisu stanowią treści: artykuły, katalogi, poradniki, oferty, bazy wiedzy.

Utrzymanie po starcie

Duży serwis to system, który żyje: aktualizacje rdzenia i wtyczek, kopie zapasowe, monitorowanie, reakcja na awarie. Aktualne wydanie WordPressa to 7.1.4 z 28 października 2026 r., a wersja 7.2 jest w fazie testów beta. Każda duża wersja wymaga sprawdzenia na środowisku testowym przed wdrożeniem. Jak robimy to bezpiecznie, opisuję w tekście o aktualizacjach WordPressa, a o kopiach w tekście o zasadzie 3-2-1.

Źródła

• W3Techs, Usage Statistics and Market Share of Content Management Systems, dane z 9.11.2026: w3techs.com (dostęp: 9.11.2026)
• WordPress.org, Requirements: wordpress.org (dostęp: 9.11.2026)
• Make WordPress Core, PHP support clarification, spring 2026 edition, 22.05.2026: make.wordpress.org (dostęp: 9.11.2026)
• WordPress Advanced Administration Handbook, Cache: developer.wordpress.org (dostęp: 9.11.2026)
• WordPress Plugin Handbook, Cron oraz Hooking WP-Cron Into the System Task Scheduler: developer.wordpress.org (dostęp: 9.11.2026)
• WordPress Documentation, Roles and Capabilities: wordpress.org (dostęp: 9.11.2026)
• web.dev, Web Vitals (progi LCP, INP, CLS): web.dev (dostęp: 9.11.2026)
• Google Search Central, Przenoszenie witryny ze zmianą adresów URL: developers.google.com (dostęp: 9.11.2026)
• WordPress.org News, wydania 7.1.4 (28.10.2026) i 7.2 Beta 4 (3.11.2026): wordpress.org/news (dostęp: 9.11.2026)