Tworzenie stron WordPress – specjalista SEO który koduje, nie projektant który "robi SEO"

Tworzenie stron WordPress – łączę web development z SEO bo rozdzielone projekty kończą się przeprojektowaniem strony po 6 miesiącach

Znam ten schemat na pamięć: klient zamawia stronę u webdesignera, a kilka miesięcy później dzwoni do specjalisty SEO z prośbą o pomoc, bo strona nie rankuje. Specjalista SEO otwiera kod, wzdycha i mówi: „trzeba przebudować strukturę, przepisać nagłówki, zmienić permastruktury, bo inaczej się nie da”. I projekt zaczyna się od nowa — tym razem za podwójne pieniądze.

Dlatego robię to inaczej. Gdy buduję strony internetowe, SEO nie jest dodatkiem naklejonym po fakcie — jest wbudowane w każdą decyzję architektoniczną od pierwszego dnia. Wiem, jak WordPress obsługuje indeksowanie, jak Googlebot przechodzi przez drzewo DOM, co spowalnia Core Web Vitals i dlaczego źle skonfigurowany plik robots.txt może zablokować roboty crawlerskie na tygodnie.

Jeśli świadomie wybrałeś WordPress i szukasz kogoś, kto zna ten ekosystem od środka — nie tylko wiesz, jak zainstalować motyw, ale rozumie cały stos technologiczny: od child theme przez konfigurację Gutenberga, po optymalizację bazy danych — to dobrze trafiłeś. Poniżej pokazuję konkretnie, co robię i jak podchodzę do każdego projektu.

WordPress od środka — co musi skonfigurować specjalista SEO przed publikacją

Większość webdesignerów instaluje motyw, wgrywa treści i klika „opublikuj”. Ja przed uruchomieniem każdej strony przechodzę przez checklistę techniczną, która zajmuje kilka godzin — ale oszczędza miesięcy frustracji po starcie.

Oto co konfiguruję obowiązkowo w każdym projekcie WordPress:

Permastruktury URL (/%postname%/) — Domyślny WordPress używa ?p=123, co jest bezużyteczne dla SEO. Ustawiam strukturę /%postname%/, która generuje czytelne, słownikowe adresy URL. To standard, który Google preferuje i który ułatwia późniejsze pozycjonowanie konkretnych podstron.
Yoast SEO / RankMath — konfiguracja schematów — Sam plugin nie wystarczy. Konfiguruję typy schematów dla każdego rodzaju treści (Article, Service, LocalBusiness, FAQPage), wyłączam powielone meta tagi i ustawiam prawidłowy canonical dla strony głównej. Więcej o samym SEO znajdziesz tutaj.
Robots.txt — co blokować — Blokuję wp-admin, wp-includes, /search/, ?s= oraz katalogi systemowe. Zbyt otwarty robots.txt powoduje, że Google marnuje crawl budget na strony, które nigdy nie powinny trafić do indeksu.
XML Sitemap — dynamiczne generowanie — Konfiguruję sitemap tak, by automatycznie obejmowała nowe wpisy i wykluczała strony z noindex (np. strony dziękujemy, polityka prywatności, duplikaty). Sitemap zgłaszam w Google Search Console.
Lazy loading obrazów — WordPress 5.5+ ma wbudowany lazy load, ale konfiguruję go świadomie: obrazy above-the-fold (hero, logo) NIE dostają atrybutu loading=”lazy”, bo opóźniają LCP. Reszta — tak.
WebP i nowoczesne formaty obrazów — Konwertuję wszystkie obrazy do WebP (lub AVIF tam, gdzie wsparcie przeglądarek na to pozwala). Różnica w wadze pliku wynosi zwykle 30–50% przy identycznej jakości wizualnej.
Critical CSS i defer JS — Wyodrębniam style niezbędne do renderowania first viewport i wklejam je inline w sekcję <head>. Wszystkie skrypty, które nie są krytyczne, ładuję z atrybutem defer lub async.
Limit rewizji (baza danych) — Domyślny WordPress przechowuje nieograniczoną liczbę rewizji wpisów. Przy aktywnym tworzeniu treści baza danych rośnie w tempie, które po roku spowalnia zapytania SQL. Ustawiam limit (np. 5 rewizji) w wp-config.php.
Polityka auto-update — Automatyczne aktualizacje wtyczek bez testowania to prosta droga do awarii strony. Konfiguruję auto-update wyłącznie dla jądra WordPress (bezpieczeństwo), a aktualizacje wtyczek i motywu przeprowadzam ręcznie, po testach na środowisku stagingowym.

Page builders vs bloki Gutenberg — co wybieram i dlaczego

To pytanie słyszę bardzo często i zawsze odpowiadam tak samo: to zależy od projektu — ale mam swoje zdanie i nie będę go ukrywać.

Gutenberg (bloki natywne) to mój domyślny wybór, gdy priorytetem są Core Web Vitals i długoterminowe SEO. Bloki natywne generują czystszy, lżejszy kod HTML, nie dokładają kilkuset kilobajtów własnego CSS i JS do każdej podstrony, a strona zbudowana w Gutenbergu jest zdecydowanie łatwiejsza do optymalizacji wydajności. Wynik PageSpeed Insights 90+ jest realny bez heroicznych wysiłków.

Elementor i Divi dają projektantom więcej swobody wizualnej i szybciej pozwalają budować skomplikowane layouty bez znajomości CSS. Rozumiem ich popularność. Ale ładują własny framework CSS (Elementor ważący ponad 400 KB po parsowaniu), generują głęboko zagnieżdżone struktury divów i dramatycznie utrudniają uzyskanie dobrych wyników CWV — szczególnie LCP i INP.

Moje podejście w praktyce:

Projekty, którym będę robił SEO — Gutenberg lub lekki motyw + FSE (Full Site Editing). Zero Elementora.
Projekty landing page z bardzo złożonym designem i bez ambicji rankingowych — rozważam page builder, ale świadomie.
Migracje istniejących stron na Elementorze — nie przebudowuję od razu, ale planujemy docelowe odejście, jeśli SEO jest celem.

Konkretny powód, dla którego unikam Elementor Pro na stronach SEO: plugin ten rejestruje własny punkt REST API i ładuje swoje skrypty na każdej podstronie, niezależnie od tego, czy dany widok w ogóle używa widgetów Elementora. To oznacza dodatkowe requesty HTTP i czas parsowania JS przy każdym załadowaniu — a to bezpośrednio uderza w wynik INP i TTFB.

WooCommerce — sklepy WordPress które rankują w Google

WooCommerce to najpopularniejsza platforma e-commerce na świecie — i jednocześnie jedna z najtrudniejszych do prawidłowej konfiguracji SEO. Sklepy WordPress generują dziesiątki pułapek technicznych, które potrafią zrujnować widoczność w wyszukiwarce, jeśli ktoś ich nie uprzedzi.

Oto co kontroluję przy każdym projekcie sklepowym:

Canonical dla wariantów produktów — URL w stylu ?color=red&size=M generuje duplikaty treści. Konfiguruję canonical tag tak, by wszystkie warianty wskazywały na główną stronę produktu. Google nie indeksuje wtedy dziesiątek identycznych podstron z minimalną różnicą w parametrze.
Paginacja kategorii (/page/2/) — Strony paginacji są problemem. Nie blokuję ich robotami (to zabija crawl), ale ustawiam właściwe rel=prev/rel=next lub stosuję selektywny noindex na stronach głębokiej paginacji (od /page/5/ wzwyż), gdzie treść ma minimalną wartość dla użytkownika.
Schema Product i Review — automatyzacja — Każdy produkt w WooCommerce powinien mieć Schema.org Product z ceną, dostępnością i oceną. Konfiguruję automatyczne generowanie tych danych strukturalnych tak, by aktualizowały się razem ze zmianami w sklepie — bez ręcznej ingerencji przy każdym produkcie.
Faceted navigation i crawl budget — Filtry (brand, rozmiar, kolor) generowane przez faceted navigation mogą wyprodukować tysiące unikalnych URL-i. Konfiguruję blokowanie parametrów w robots.txt i Google Search Console, żeby Googlebot nie marnował limitu crawl budget na kombinatoryczne warianty filtrowania.
Wydajność sklepu — WooCommerce jest ciężki. Dobry hosting z serwerem obiektowym (Redis/Memcached), CDN dla statycznych zasobów i właściwa konfiguracja cache (z wyjątkami dla koszyka i stron konta) to absolutne minimum. Szczegóły na temat doboru serwera opisuję na stronie o wyborze hostingu WordPress.

Child theme i customizacja — jak zmieniam WordPress bez ryzyka utraty zmian

To sekcja dla klientów, którzy słyszeli o child theme, ale nie do końca rozumieją, dlaczego to standard w każdym profesjonalnym projekcie WordPress — i dlaczego brak child theme to jeden z najczęstszych błędów przy samodzielnym zarządzaniu stroną.

Czym jest child theme? To motyw potomny, który dziedziczy wygląd i funkcje motywu nadrzędnego (parent theme), ale przechowuje wszystkie Twoje modyfikacje w osobnym miejscu. Gdy aktualizujesz motyw nadrzędny — co jest konieczne ze względów bezpieczeństwa — Twoje zmiany pozostają nienaruszone. Bez child theme każda aktualizacja motywu kasuje wszystkie ręczne modyfikacje kodu.

Dwa sposoby customizacji, których używam w zależności od zakresu zmian:

WordPress Customizer i opcje motywu — do zmian wizualnych: kolory, czcionki, logo, układ. Zmiany zapisywane są w bazie danych, nie w plikach motywu — więc są bezpieczne nawet bez child theme. Ale to narzędzie ma ograniczony zakres.
functions.php child theme — do modyfikacji funkcjonalnych: dodawanie własnych shortcodes, hooków, filtrów, niestandardowych typów wpisów (CPT), zmian w WooCommerce, rejestracji skryptów. Tutaj child theme jest absolutnie konieczny.

Zachęcam do zapoznania się z podstawami CSS, HTML i JavaScript — to bardzo ułatwia komunikację z deweloperem i świadome zarządzanie własną stroną. Warto też wiedzieć, czym jest WordPress od strony technicznej.

Hosting WordPress — co polecam i dlaczego ma znaczenie dla SEO

Hosting to fundament, o którym 80% klientów myśli dopiero wtedy, gdy strona zaczyna działać wolno. A TTFB (Time to First Byte) — czyli czas odpowiedzi serwera — to jeden z bezpośrednich czynników rankingowych Google i jeden z pierwszych elementów, który sprawdzam przy audycie technicznym.

Strony WordPress na tanim hostingu współdzielonym osiągają TTFB rzędu 800 ms–2 s. Strony na dobrze skonfigurowanym VPS lub hostingu zarządzanym — 50–200 ms. Ta różnica jest bezpośrednio widoczna w wynikach PageSpeed Insights i w pozycjach w Google.

Moje rekomendacje, kryteria wyboru i konkretne porównanie rozwiązań hostingowych opisałem szczegółowo na osobnej stronie: Jaki serwer wybrać pod strony na WordPress. Znajdziesz tam podział na budżet projektu, typ strony (wizytówka, sklep, portal) i wymagania wydajnościowe. Jeśli buduję Twoją stronę, doradztwo w zakresie hostingu jest częścią projektu — nie musisz decydować sam.

Najczęściej zadawane pytania

Gutenberg czy Elementor — co lepsze dla SEO?

Z punktu widzenia SEO technicznego Gutenberg wygrywa bez dyskusji. Bloki natywne generują lżejszy markup HTML, nie dokładają kilkuset kilobajtów własnego CSS i JS do każdej podstrony i nie rejestrują zbędnych punktów REST API. Strony zbudowane w Gutenbergu osiągają lepsze wyniki Core Web Vitals — szczególnie LCP (Largest Contentful Paint) i INP (Interaction to Next Paint) — bez konieczności stosowania agresywnych hacków optymalizacyjnych. Elementor ma swoje miejsce przy bardzo złożonych layoutach, gdzie design jest priorytetem nad wydajnością, ale przy projektach, którym towarzyszę jako specjalista SEO, domyślnie wybieram Gutenberg lub lekki FSE motyw. Jeśli klient ma już stronę w Elementorze i chce poprawić SEO, pracujemy nad tym co mamy — ale przy nowym projekcie z ambicjami rankingowymi decyzja jest oczywista.

Czy WordPress jest bezpieczny — jak zabezpieczam strony?

WordPress sam w sobie jest bezpieczny — problem leży w nieaktualizowanych wtyczkach, słabych hasłach i nieodpowiednim hostingu. Moje standardowe zabezpieczenia przy każdym projekcie to: aktualizacja jądra WordPress, motywu i wtyczek do najnowszych wersji, wyłączenie edytora plików w panelu administracyjnym (DISALLOW_FILE_EDIT w wp-config.php), zmiana domyślnego prefiksu tabel bazy danych, ograniczenie liczby prób logowania (limit login attempts), wyłączenie XML-RPC jeśli nie jest potrzebny, SSL/HTTPS na całej domenie, regularne kopie zapasowe na zewnętrznym serwerze oraz monitoring dostępności. Opcjonalnie instaluję Wordfence lub iThemes Security w zależności od wymagań projektu. Bezpieczeństwo traktuję jako proces ciągły, nie jednorazowe ustawienie — dlatego oferuję też pakiety opieki technicznej po wdrożeniu.

Jak szybko może być strona WordPress? Jakie PSI osiągasz?

Na dobrym hostingu VPS, z właściwie skonfigurowanym cache (LiteSpeed Cache lub W3 Total Cache), skompresowanymi i skonwertowanymi do WebP obrazami, zoptymalizowanym CSS i JS oraz aktywnym CDN — strona WordPress osiąga 90–98 punktów w PageSpeed Insights zarówno na desktop, jak i mobile. Sam regularnie weryfikuję wyniki swoich wdrożeń i nie oddaję projektu bez osiągnięcia wyniku powyżej 85 punktów mobile. TTFB poniżej 200 ms, LCP poniżej 1,5 s i zerowy CLS to moje standardowe cele przy nowych projektach. Warto wiedzieć, że wynik PSI nie jest stały — zależy od serwera w danym momencie, CDN i ruchu. Dlatego ważniejsze niż pojedynczy wynik jest konsekwentna konfiguracja warstw technicznych, która zapewnia stabilną wydajność przez całą dobę.

Czy mogę przenieść stronę z innej platformy na WordPress?

Tak — i robię to regularnie. Migracje z Wix, Squarespace, Webflow, Joomla, Drupal, PrestaShop czy autorskich systemów CMS to część mojej pracy. Kluczowa jest tutaj prawidłowa obsługa przekierowań 301 — każdy stary URL musi przekierować na odpowiednik w nowej strukturze, żeby nie stracić zgromadzonej mocy linków i pozycji w Google. Migracja bez mapy przekierowań to jeden z najczęstszych powodów nagłego spadku widoczności po rebrandingu strony. Piszę o tym szczegółowo w artykule jak przenieść stronę internetową na WordPress. Przed każdą migracją audytuję obecną strukturę URL, przygotowuję mapę przekierowań i weryfikuję wyniki w Google Search Console po przeniesieniu — minimum przez 30 dni po starcie.

Czy WordPress nadaje się dla dużego sklepu e-commerce?

WordPress z WooCommerce obsługuje sklepy z dziesiątkami tysięcy produktów — pod warunkiem, że infrastruktura jest odpowiednio dobrana. Na tanim hostingu współdzielonym sklep z 5 000 produktów będzie działał wolno i niestabilnie. Na dedykowanym VPS lub hostingu zarządzanym WordPress (np. Kinsta, WP Engine, Cloudways) z Redis Object Cache, właściwie skonfigurowanym serwerem obiektowym i CDN — WooCommerce skaluje się bardzo dobrze. Znam przypadki sklepów generujących kilka milionów zł miesięcznie opartych na tym stosie. Kluczowe jest dopasowanie hostingu do skali projektu, optymalizacja zapytań SQL (szczególnie przy złożonych filtrach), zarządzanie crawl budgetem przez Google i wdrożenie danych strukturalnych Schema Product dla każdego produktu. Przy dużych sklepach WooCommerce rozmawiam z klientem o architekturze przed pierwszą linią kodu.

Porozmawiajmy o Twoim projekcie WordPress

Buduję strony WordPress z SEO wbudowanym od fundamentów — bez zbędnych pośredników i bez przeprojektowywania po 6 miesiącach. Jeśli chcesz omówić swój projekt, zadzwoń lub napisz. Wycenę przygotowuję w ciągu 24 godzin.

Sebastian Bergier
Tel: 737 495 278
Formularz kontaktowy poniżej

Oceń tę stronę