Przebudowa i modernizacja strony internetowej
Jestem Mariusz Szatkowski i od 2006 roku piszę strony na WordPressie. Przebudowuję witryny, które mają już ruch, treści i pozycje w Google, ale stoją na starym PHP, ciężkim builderze albo motywie, którego nikt nie chce ruszać. Zachowuję adresy i treść, wymieniam to, co pod spodem.
Pracuję sam. Kod, który dostajesz, piszę ja, i ja mam dostęp do Twojego serwera. Projekt graficzny przynosisz Ty: jako plik Figma od swojego projektanta albo jako wypełniony arkusz, który Ci wyślę. Zaznaczasz w nim, jakie elementy mają być na każdym widoku i w jakiej kolejności. Na tej podstawie buduję responsywny motyw.
Trzy rodzaje zleceń pod jedną nazwą
Pod hasłem “przebudowa strony” kryją się trzy różne prace i warto je rozróżnić, zanim padnie wycena.
| Odświeżenie wyglądu | Modernizacja techniczna | Nowy serwis | |
|---|---|---|---|
| Kiedy | Strona sprzedaje, ale wygląd odstaje od marki | Wolne ładowanie, stary PHP, porzucone wtyczki | Zmienił się model biznesowy albo oferta |
| Projekt graficzny | Od Ciebie lub Twojego projektanta | Zostaje obecny albo dostarczasz nowy | Od Ciebie lub Twojego projektanta |
| Co robię | Wdrażam nowy projekt jako motyw | Wymieniam motyw, PHP, hosting, porządkuję bazę | Buduję motyw, przenoszę lub zakładam treści |
| Adresy URL | Bez zmian | Bez zmian albo z mapą 301 | Nowa struktura z pełną mapą 301 |
| Treści | Zostają | Zostają, po przeglądzie | Piszesz je Ty, ja je wdrażam |
Najczęściej łączą się dwie pierwsze kolumny, bo nowy wygląd na PHP 7.4 i WPBakery dalej będzie wolny. Jeśli wychodzi trzecia, zajrzyj na stronę o tworzeniu stron i sklepów WordPress.
Kiedy przebudowa ma sens, a kiedy nie
Powody, które bronią się w rachunku, są dwa.
Pierwszy: zmienił się biznes. Nowa grupa klientów, inna oferta, rebranding, którego stara struktura nie udźwignie. Wtedy najpierw powstaje nowa oferta i nowy projekt graficzny po Twojej stronie, a ja wchodzę z wdrożeniem.
Drugi: zgnił stack. Częsty obraz na polskich stronach: motyw kupiony kilka lat temu z WPBakery, w którym każda podstrona to drzewo shortcode’ów, PHP 7.4, którego hosting już nie łata, WordPress, na którym nowe wtyczki się nie instalują, i setki starych linków do adresów w rodzaju /o-nas-pl/ czy /uslugi-pl/. Utrzymanie takiej strony to co miesiąc spłata odsetek od długu technicznego.
Słaby powód to “wygląd już nie ten” bez liczby, która ma się zmienić. Zanim zamówisz przebudowę, zapisz, co ma się poprawić i o ile: konwersja formularza, czas ładowania na telefonie, ruch z Google. Jeśli odpowiedź brzmi “będzie ładniej”, to jest odświeżenie, a nie przebudowa, i budżet powinien to odzwierciedlać.
Techniczne sygnały, że łatanie przestało działać
- PHP utknięte na 7.4, bo kluczowa wtyczka albo motyw nie przeżyje 8.x.
- Rdzeń WordPressa poniżej 6.0, często niżej, przez zmiany wprowadzone w plikach rdzenia.
- Visual Composer, WPBakery albo Divi, których nie da się odpiąć: po wygaśnięciu licencji strona pokazuje surowe shortcode’y.
- JavaScript motywu oparty na starym jQuery, w którym podmiana jednej biblioteki psuje pół frontendu.
- Lighthouse mobile około 30 mimo cache: blokujące renderowanie skrypty, rozrośnięty DOM, synchronicznie ładowane tagi zewnętrzne.
- Responsywność doklejona do układu desktopowego, z koszykiem, który pęka na telefonie.
- Ponad czterdzieści aktywnych wtyczek, w tym porzucone i takie ze zgłoszonymi podatnościami.
Jeśli Twoja strona ma trzy z tych objawów, pytanie brzmi raczej “teraz czy po następnej awarii”. Pierwsza opcja wychodzi taniej.
Całość naraz czy po kawałku
Przebudowa jednym ruchem jest prostsza do zapisania w umowie, ale to w niej najczęściej przesuwa się termin, a cała strona wisi na jednym stagingu. Jeśli kalendarz pozwala, wolę iść etapami: najpierw nagłówek i nawigacja, potem strony usług albo katalog, potem blog, a koszyk i zamówienia na końcu, bo tam jest przychód. Każdy etap idzie na produkcję, łapie prawdziwy ruch i pokazuje, czy coś poszło nie tak, zanim zacznie się następny.
Jednym ruchem robię to w dwóch sytuacjach: przy pełnym rebrandingu, gdzie wszystkie strony muszą zmienić się w tym samym tygodniu, i przy kodzie tak splątanym, że każda poprawka i tak dotyka całości.
Co może się zepsuć i jak tego pilnuję
Mapa przekierowań 301. Każdy stary adres dostaje odpowiednik w arkuszu, zanim zacznę wdrożenie. Pominięty wiersz to błąd 404 i utracony ruch.
Linki wewnętrzne. Stare wpisy dalej linkują do starych adresów. Przekierowanie zadziała, ale łańcuchy przekierowań poprawiam w bazie przez WP-CLI, a nie samym plikiem reguł.
Integracje. Webhook do CRM oczekujący konkretnego pola formularza, zdarzenia GA4 przypięte do klas CSS, które po zmianie motywu znikają. Każdą integrację spisuję przed startem i sprawdzam na stagingu.
Mapa witryny. Po starcie generuję nową w Rank Math albo Yoast, zgłaszam ją w Search Console i przez kolejne tygodnie patrzę w raport indeksowania. Polskie znaki w slugach sprawdzam osobno, bo część wtyczek cache wciąż źle obsługuje UTF-8.
Dane z ACF i własne typy wpisów. Pola, które nie przeniosły się czysto, obrazki wyróżniające bez tekstu alternatywnego. Po migracji porównuję liczby rekordów wiersz po wierszu.
Redakcja. Ktoś, kto znał WPBakery, teraz widzi edytor blokowy. Dostajesz krótką pisemną instrukcję do trzech najczęstszych zadań: nowy wpis, edycja strony usługi, zmiana banera.
Dostępność: co mówi polska ustawa
Od 28 czerwca 2025 roku obowiązuje ustawa z dnia 26 kwietnia 2024 r. o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze (Dz.U. 2024 poz. 731). Wdraża dyrektywę (UE) 2019/882, czyli Europejski Akt o Dostępności. Wśród usług, które obejmuje, jest handel elektroniczny, bankowość detaliczna, rozpowszechnianie e-booków i część usług transportu pasażerskiego. Zgodnie z art. 4 pkt 1 ustawy nie stosuje się jej do usług świadczonych przez mikroprzedsiębiorców. Nadzór nad usługami sprawuje Prezes Zarządu PFRON.
Jeśli sprzedajesz online konsumentom, a sklep stoi na builderze z dziesiątkami zagnieżdżonych divów, poprawianie dostępności na żywej produkcji wychodzi drożej niż zaplanowanie jej przy przebudowie. Przy wdrożeniu dbam o to, co da się zrobić w kodzie: semantyczny HTML, obsługę klawiatury, widoczny fokus, etykiety formularzy, teksty alternatywne i kontrast zgodny z WCAG 2.2. Kontrast zależy też od projektu graficznego, więc jeśli kolory z projektu go nie spełniają, mówię o tym przed wdrożeniem.
Wydajność i bezpieczeństwo po przebudowie
Czas ładowania mierzę przed startem prac i po uruchomieniu, na tych samych adresach i w tym samym narzędziu. Pracuję na danych z Core Web Vitals (LCP, INP, CLS), a nie na samym wyniku Lighthouse. Typowe działania to obrazy w AVIF z właściwymi wymiarami, mniej JavaScriptu w motywie, cache obiektów, porządek w zapytaniach do bazy i odchudzenie listy wtyczek. Więcej o samym przyspieszaniu piszę na stronie o przyspieszaniu strony WordPress.
Przy przebudowie usuwam nieużywane wtyczki i motywy, ustawiam nagłówki bezpieczeństwa, wyłączam edycję plików z panelu i porządkuję konta administratorów. Nie obiecuję, że strony nikt nigdy nie zaatakuje. Jeśli chcesz najpierw sprawdzić obecny stan, zacznij od audytu bezpieczeństwa WordPress.
Sprawdź gotowość, zanim napiszesz
Audyt gotowości do przebudowy to dziesięć pytań, na które odpowiadasz sam, bez logowania. Wynik pokazuje, które obszary wymagają przebudowy, a które mogą poczekać. Z odpowiedziami łatwiej napisać brief.
Opieka po uruchomieniu
Po starcie mogę przejąć stałą opiekę nad stroną: monitoring dostępności co 1 do 5 minut, kopie zapasowe przechowywane ponad 30 dni w krajach UE, aktualizacje testowane najpierw na stagingu. Przed pierwszym dostępem podpisujemy umowę powierzenia przetwarzania danych zgodnie z art. 28 RODO. Nie obiecuję czasu reakcji ani dyżurów całodobowych. Kontakt jest mailowy, a zmiany opisuję na piśmie i w repozytorium.
Brief wyślesz przez formularz kontaktowy. Napisz, jaki jest adres strony, co nie działa i czy masz już projekt graficzny.
