SEO WordPressa w 2026 roku: 11 kroków, wtyczki i ustawienia

Poradnik dla właściciela strony na WordPressie i początkującego SEO-wca: 11 kroków, stan na 14.10.2026. SEO WordPressa to głównie konfiguracja: jedna wtyczka SEO, poprawne ustawienia widoczności i bezpośrednich odnośników, noindex dla cienkich archiwów, cache i lekkie obrazy, a potem kontrola w Google Search Console. WordPress nie wymaga już grzebania w header.php, ale ustawienia domyślne potrafią zostawić indeksowalne archiwa tagów, autora i załączników, a jeden odhaczony checkbox potrafi wyłączyć całą stronę z Google.

Wersje wtyczek, ceny i nazwy ustawień w tym poradniku są aktualne na 14 października 2026 roku. Przykłady biorę z bynajmniej.pl, który działa na WordPressie 7.1 z motywem Twenty Twenty-Five, Yoast SEO 28.7, LiteSpeed Cache i Redirection.

SEO WordPressa w skrócie: 11 kroków

Optymalizacja SEO WordPressa składa się z 11 kroków, od ustawień w kokpicie do monitoringu w Google Search Console:

1. Ustawienia WordPressa: widoczność w wyszukiwarkach, bezpośrednie odnośniki i sitemapa.
2. Jedna wtyczka SEO: Yoast SEO, Rank Math albo SEOPress.
3. Tytuły (title) i meta description.
4. Nagłówki w motywie blokowym.
5. Archiwa tagów, autora, dat i strony załączników.
6. Szybkość i Core Web Vitals: cache i obrazy WebP/AVIF.
7. Dane strukturalne.
8. Linkowanie wewnętrzne.
9. Przekierowania 301 i błędy 404.
10. Bezpieczeństwo i spam SEO.
11. Google Search Console: indeksacja, sitemapy, raporty AI.

Część funkcji SEO WordPress ma w rdzeniu (sitemapy, tag title, lazy loading obrazów), a część wymaga wtyczki SEO. Podział funkcji między rdzeń WordPressa i wtyczkę:

Wersje WordPressa podane w tabeli funkcji SEO rdzenia pochodzą z notek deweloperskich WordPressa: sitemapy w 5.5, lazy loading w 5.5, automatyczne aktualizacje w 5.5, WebP w 5.8, AVIF w 6.5, fetchpriority w 6.3 i strony załączników w 6.4.

Krok 1. Ustaw widoczność, bezpośrednie odnośniki i sitemapę

„Proś wyszukiwarki o nieindeksowanie witryny”

Checkbox „Proś wyszukiwarki o nieindeksowanie witryny” w Ustawienia → Czytanie (sekcja „Widoczność w wyszukiwarkach”) musi być odznaczony na stronie produkcyjnej. Według dokumentacji WordPress.org zaznaczona opcja od wersji 5.3 dodaje do <head> tag <meta name='robots' content='noindex,nofollow' />. Ta sama opcja wyłącza też sitemapy rdzenia WordPressa.

Checkbox „Proś wyszukiwarki o nieindeksowanie witryny” zaznacza się na stronie testowej i zapomina odznaczyć po przeniesieniu na domenę docelową. Moim zdaniem to najczęstszy powód, dla którego „nowa strona na WordPressie nie wchodzi do Google”, a po migracji sprawdzam go jako pierwszy.

Do wersji 5.2 ta sama opcja działała inaczej: według dokumentacji WordPressa dopisywała Disallow: / do pliku robots.txt zamiast tagu w <head>. Wyłącza też pingi do usług aktualizacji. Sprawdzenie zajmuje minutę: w źródle strony szukasz słowa noindex, a w Google Search Console strona z tym tagiem ma w raporcie Indeksowanie stron status „Wykluczono za pomocą tagu „noindex””.

Bezpośrednie odnośniki: „Nazwa wpisu”

Strukturę adresów ustawiasz w Ustawienia → Bezpośrednie odnośniki. Instalator WordPressa najpierw próbuje ustawić strukturę „Dzień i nazwa” (/%year%/%monthnum%/%day%/%postname%/), potem tę samą strukturę z prefiksem /index.php/, a gdy serwer nie obsługuje żadnej, zostają „Zwykłe” adresy /?p=123. Na nowej stronie wybieram „Nazwa wpisu” (/%postname%/), bo adres bez daty nie starzeje się przy aktualizacji treści. Bynajmniej.pl ma /%postname%/ od lat.

Słowo kluczowe w adresie URL ma niewielkie znaczenie. Przewodnik SEO Google dla początkujących mówi, że słowa kluczowe w nazwie domeny albo w ścieżce URL same w sobie prawie nie mają wpływu poza pojawieniem się w ścieżce nawigacyjnej (w dokumentacji Google po angielsku: „hardly any effect beyond appearing in breadcrumbs”). Zmiana struktury odnośników na działającej stronie zmienia adresy wszystkich wpisów, więc bez przekierowań 301 (krok 9) oznacza utratę zaindeksowanych URL-i. Działającej struktury nie zmieniam dla kosmetyki.

Prefiksy „category” i „tag” można zmienić w tym samym ekranie (na bynajmniej.pl kategorie mają prefiks /k/, a tagi /t/), ale według dokumentacji WordPressa nie da się ich usunąć bez wtyczki.

Sitemapa: wp-sitemap.xml albo sitemapa wtyczki

WordPress od wersji 5.5 generuje sitemapę pod adresem /wp-sitemap.xml. Według notki deweloperskiej WordPressa pojedyncza sitemapa rdzenia mieści maksymalnie 2000 adresów, a domyślnie obejmuje publiczne typy treści, taksonomie (kategorie i tagi), stronę główną i archiwa autorów. Yoast SEO wyłącza sitemapę rdzenia i podaje własną.

Na bynajmniej.pl adres /wp-sitemap.xml przekierowuje 301 na /sitemap_index.xml z Yoasta, który zawiera 6 sitemap: wpisy, strony, podcast, kategorie, tagi i autorów. W Google Search Console zgłaszasz jedną sitemapę, tę z wtyczki. Google ignoruje znaczniki <priority> i <changefreq>, więc ich nie ustawiam.

Sitemapa powinna zawierać tylko indeksowalne URL-e, które zwracają kod 200. Limit 2000 adresów na plik sitemapy rdzenia zmienisz filtrem wp_sitemaps_max_urls. W crawlu Screaming Frog bynajmniej.pl z 14.10.2026 (441 wewnętrznych URL-i) sitemapa Yoasta zawierała adres /podcast/ z przekierowaniem 301 (po poprawce już go tam nie ma), a poza sitemapą zostały 23 indeksowalne URL-e, głównie strony paginacji (/page/2/, /k/seo/page/2/, /author/.../page/2/).

robots.txt: wirtualny plik WordPressa

Plik robots.txt w WordPressie jest wirtualny, dopóki na serwerze nie leży fizyczny plik o tej nazwie. Funkcja do_robots() generuje trzy reguły: User-agent: *, Disallow: /wp-admin/ i Allow: /wp-admin/admin-ajax.php, a sitemapa rdzenia jest do niego dopisywana automatycznie. Na zwykłym blogu nic więcej tam nie potrzeba.

Robots.txt nie służy do wyłączania stron z indeksu. Dokumentacja Google o blokowaniu indeksowania mówi, że Google nie obsługuje reguły noindex w pliku robots.txt, a żeby zobaczyć tag noindex na stronie, Googlebot musi tę stronę pobrać. Strona z noindex zablokowana w robots.txt może więc dalej wisieć w indeksie, bo Google tagu nigdy nie przeczyta.

Krok 2. Wybierz jedną wtyczkę SEO

Wtyczka SEO dla WordPressa daje kontrolę nad title, meta description, noindex, canonical, sitemapą i danymi strukturalnymi. Sama instalacja pozycji nie poprawi, wtyczka tylko udostępnia ustawienia. Na stronie instaluje się jedną wtyczkę SEO, bo dwie generują podwójne title, canonicale i dane strukturalne.

Dane o wersjach, liczbie instalacji i cenach Yoast SEO, Rank Math i SEOPress pochodzą ze stron wtyczek na WordPress.org (Yoast SEO, Rank Math, SEOPress) i z cenników Yoast, Rank Math i SEOPress.

Moim zdaniem na blog albo stronę firmową wystarczy darmowa wersja dowolnej z trzech wtyczek. Yoast w wersji darmowej nie ma przekierowań, dlatego bynajmniej.pl używa Yoasta razem z darmową wtyczką Redirection. Rank Math ma przekierowania, monitor 404 i integrację z GSC za darmo, więc na nowej stronie bez historii daje najwięcej w wersji bezpłatnej. Działającej konfiguracji Yoasta nie migruję do innej wtyczki tylko dla nowych funkcji.

Osobną kategorią jest Site Kit by Google (wersja 1.189.0, 5+ mln aktywnych instalacji). Site Kit nie zastępuje wtyczki SEO, bo nie ma pól na title ani meta description, tylko pokazuje w kokpicie dane z Search Console, Analytics i PageSpeed Insights. Może działać obok Yoasta, Rank Matha albo SEOPressa bez konfliktu.

Darmowy Yoast reklamuje w 2026 roku zarządzanie plikiem llms.txt. Google 15 czerwca 2026 doprecyzował w przewodniku po optymalizacji pod AI, że pliki llms.txt nie są potrzebne w wyszukiwarce Google (w dokumentacji Google po angielsku: „aren’t needed for Google Search (and won’t negatively or positively impact your visibility or rankings)”). Funkcja jest, ruchu z Google z niej nie będzie.

Krok 3. Napisz title i meta description

Title (znacznik <title>) jest głównym źródłem linku z tytułem w wynikach Google, ale nie jedynym. Według dokumentacji Google o linkach z tytułem Google bierze też pod uwagę główny widoczny tytuł strony, nagłówki <h1>, tag og:title i tekst anchorów linków prowadzących do strony. Google nie ma limitu długości title, a link z tytułem skraca w wynikach do szerokości ekranu urządzenia.

We wtyczce SEO ustawiasz szablon title dla każdego typu treści i nadpisujesz go we wpisach, na których ci zależy. Na bynajmniej.pl szablon Yoasta dla wpisów to %%title%% %%page%% %%sep%% %%sitename%%, czyli „Tytuł wpisu – Bynajmniej”, a dla ważnych wpisów piszę title ręcznie: H1 tego poradnika różni się od jego title.

Meta description nie gwarantuje opisu w wynikach. Dokumentacja Google o snippetach mówi, że snippety powstają głównie z treści strony, a meta description Google używa wtedy, gdy opisuje stronę trafniej niż fragment treści. Meta description pisz więc jako odpowiedź na zapytanie: co jest na stronie i dla kogo. Tagu meta keywords nie wypełniaj, bo Google go nie używa.

Z tego samego powodu pole „Fraza kluczowa” w Yoast SEO albo Rank Math to podpowiedź dla autora, a nie tag wysyłany do Google. Zielona kropka w analizie treści mierzy, ile razy wpisałeś frazę w tekst, a Google w tym czasie czyta resztę internetu. To lista kontrolna, nie prognoza pozycji.

Braki w title i meta description na starym WordPressie idą w dziesiątki. Crawl Screaming Frog bynajmniej.pl z 14.10.2026 pokazał, że meta description brakuje na 122 ze 150 indeksowalnych stron (81%), 92 strony mają title krótszy niż 30 znaków, a 8 stron ma zduplikowany title. Opisy uzupełniłem tego samego dnia, po poprawkach brakuje ich na 2 stronach. Takie braki uzupełniam od stron z największą liczbą wyświetleń w Google Search Console, a nie alfabetycznie.

Strona główna to miejsce, o którym się zapomina. Na bynajmniej.pl meta description strony głównej to wciąż slogan „Paweł (nie) pisze o internetach”. Działa jako żart, jako opis dla wyszukiwarki już mniej.

Krok 4. Sprawdź nagłówki w motywie blokowym

Nagłówki w motywach blokowych (np. domyślne motywy od Twenty Twenty-Two do Twenty Twenty-Five) ustawia się w Edytorze witryny (Wygląd → Edytor), a nie w plikach PHP. Każdy szablon (pojedynczy wpis, strona, archiwum, strona główna) składa się z bloków, a blok „Tytuł wpisu” albo „Tytuł witryny” ma w ustawieniach poziom nagłówka od H1 do H6.

Kolejność nagłówków nie jest czynnikiem rankingowym. Przewodnik SEO Google mówi, że z perspektywy wyszukiwarki nie ma znaczenia, czy nagłówki są ułożone poza kolejnością (w dokumentacji Google po angielsku: „from Google Search perspective, it doesn’t matter if you’re using them out of order”), i że nie ma idealnej liczby nagłówków na stronie. Logiczna struktura H2/H3 pomaga za to czytelnikom, czytnikom ekranu i modelom AI, które wycinają fragmenty strony.

Szablony motywu blokowego sprawdzam pod kątem sensu nagłówków, nie liczby H1. Na pojedynczym wpisie bynajmniej.pl Twenty Twenty-Five daje jeden H1 z tytułem wpisu. Na stronie głównej H1 dostał tytuł jednego wpisu („SEO bez kliknięć?” z maja 2025), a nazwa bloga nie jest nagłówkiem. Google krzywdy z tego nie zrobi, ale strona główna z H1 o nazwie i tematyce bloga byłaby czytelniejsza.

Krok 5. Ogranicz archiwa tagów, autora, dat i załączników

WordPress tworzy osobny URL dla każdego tagu, kategorii, autora, miesiąca i (na starszych instalacjach) każdego obrazka. Archiwum z jednym wpisem to cienka treść (thin content): ten sam fragment co we wpisie, inny adres. Google nie karze za duplikaty, przewodnik SEO Google nazywa je nieefektywnymi, ale nie powodującymi ręcznych działań. Problem cienkich archiwów jest inny: setki prawie pustych list wpisów konkurują z wpisami o te same zapytania i rozmywają sygnały między podobne URL-e.

Archiwa tagów, autora, dat i załączników w WordPressie ustawiam według pięciu zasad:

• Kategorie zostawiam indeksowalne, jeśli mają opis i więcej niż kilka wpisów.
• Tagi z 1–3 wpisami ustawiam na noindex albo usuwam i przekierowuję na najlepszy wpis.
• Archiwum autora na blogu jednego autora ustawiam na noindex (Yoast: Ustawienia → Archiwa autora), bo duplikuje listę wpisów ze strony głównej. Czytelnik dalej może je otworzyć, a link „autor” pod wpisami kieruję na stronę o autorze.
• Archiwa dat wyłączam na blogu, który nie jest serwisem newsowym.
• Strony załączników przekierowuję na plik albo wpis nadrzędny.

Strony załączników WordPress 6.4 wyłączył dla nowych instalacji (opcja wp_attachment_pages_enabled = 0), ale strony zaktualizowane ze starszych wersji zachowały je włączone. Sprawdzasz to w WP-CLI poleceniem wp option get wp_attachment_pages_enabled albo w ustawieniach wtyczki SEO.

Panel WordPressa nie ma przełącznika tej opcji, więc na starej instalacji bez wtyczki SEO wyłączasz strony załączników poleceniem wp option set wp_attachment_pages_enabled 0.

Na bynajmniej.pl 200 załączników jest wyłączonych trzy razy: opcją rdzenia, ustawieniem Yoasta i osobną wtyczką. Wystarczyłoby jedno. Z tagami jest odwrotnie: 31 tagów (prefiks /t/), z czego 16 ma 1–3 wpisy, a 6 ma jeden wpis, i wszystkie 31 zwracają 200, są indeksowalne i siedzą w sitemapie post_tag-sitemap.xml. Stare adresy tagów z prefiksem /tag/ przekierowałem już na wpisy, porządki z obecnymi tagami czekają w kolejce. Szewc bez butów, wiadomo.

Archiwa tagów i kategorii bywają też najwolniejszymi stronami WordPressa. W crawlu bynajmniej.pl 10 URL-i odpowiadało dłużej niż 1000 ms i wszystkie były archiwami tagów albo kategorii, a na stronie tagu /t/autoblog/ crawl znalazł tekst „lorem ipsum”, czyli wypełniacz, który trafił do indeksowalnego archiwum. Przy TTFB pojedynczych wpisów poniżej 0,2 s (krok 6) to problem tych szablonów, a nie hostingu.

Krok 6. Przyspiesz stronę: cache, obrazy, Core Web Vitals

Core Web Vitals to trzy metryki szybkości i stabilności strony, a Google podaje dla nich progi: LCP (ładowanie największego elementu) poniżej 2,5 s, INP (reakcja na interakcję) poniżej 200 ms i CLS (przesunięcia układu) poniżej 0,1. INP zastąpił FID 12 marca 2024 roku. Raport Core Web Vitals w GSC ocenia dane polowe z 28 dni, a nie wynik Lighthouse.

Progi Core Web Vitals liczy się dla 75. percentyla odsłon, osobno na urządzeniach mobilnych i komputerach, co opisuje web.dev. Strona, która „ładuje się szybko” na laptopie autora, może więc nie zaliczać LCP na telefonach czytelników.

Na WordPressie szybkość poprawiają cztery rzeczy, w tej kolejności:

1. Cache strony: gotowy HTML zamiast PHP i zapytań do bazy przy każdej wizycie. Na serwerze LiteSpeed/OpenLiteSpeed używa się LiteSpeed Cache, na Apache i Nginx np. WP Rocket albo WP Super Cache. Jedna wtyczka cache, nie dwie.
2. Obrazy w WebP albo AVIF w rozmiarze, w jakim się wyświetlają. WordPress przyjmuje WebP od 5.8 i AVIF od 6.5 (jeśli obsługuje je biblioteka obrazów serwera, co pokazuje Narzędzia → Stan witryny), a Google Grafika obsługuje oba formaty.
3. Mniej wtyczek i skryptów zewnętrznych: każdy widget czatu, slider i piksel reklamowy obciąża INP.
4. Lekki motyw. Moim zdaniem domyślny motyw blokowy (Twenty Twenty-Five) wystarcza na bloga, a ciężkie page buildery dokładają własny CSS i JavaScript do każdej strony.

Lazy loading obrazów i fetchpriority="high" dla obrazu LCP WordPress dodaje sam, więc osobna wtyczka do lazy loadingu jest zbędna. Według notki do WordPressa 6.3 rdzeń sam wybiera obraz, który najpewniej będzie elementem LCP, i oznacza go wysokim priorytetem.

Efekt tej zmiany widać w danych polowych. Według analizy zespołu wydajności WordPressa po wersji 6.3 odsetek stron z klasycznym motywem, które lazy-loadują obrazek LCP, spadł z 27–28% do 9–10%. WordPress 6.8 włączył z kolei speculative loading (prefetch strony po rozpoczęciu kliknięcia w link), co podniosło medianę odsetka stron z dobrym LCP o ok. 1,9%.

Na bynajmniej.pl LiteSpeed Cache serwuje strony z cache (nagłówek x-litespeed-cache: hit) za Cloudflare, a TTFB wpisu o audycie SEO wyniósł w moim pomiarze curl z 14.10.2026 ok. 0,18–0,19 s. Nowe obrazy wgrywam jako WebP. Starsze mają za to nazwy w rodzaju ChatGPT-Image-Mar-26-2025-02_34_51-PM.png, a Google zaleca krótkie, opisowe nazwy plików i tekst alternatywny (alt) jako najważniejszy opis obrazu.

Rdzeń nie zastępuje też optymalizacji obrazów przed wgraniem. Według notki deweloperskiej WordPressa 5.3 obrazy większe niż 2560 px WordPress skaluje do tego progu, ale oryginał zostaje w katalogu uploads, a wersja 2560 px nadal może ważyć kilka megabajtów. Crawl bynajmniej.pl znalazł 6 obrazów większych niż 2 MB, w tym PNG wygenerowane w ChatGPT w 2025 roku po 2,5–3,7 MB, 26 obrazów większych niż 100 KB, 52 obrazy z pustym atrybutem alt i 6 bez atrybutu alt. Obrazy przed wgraniem konwertuję do WebP i zmniejszam do szerokości kolumny treści.

Krok 7. Dodaj dane strukturalne (bez złudzeń co do FAQ)

Dane strukturalne na WordPressie generuje wtyczka SEO jako JSON-LD w kodzie strony. Na bynajmniej.pl Yoast dodaje do każdego wpisu graf z typami Article, BreadcrumbList, Person, WebSite i ImageObject, bez żadnej konfiguracji poza nazwą witryny i autorem. Wprowadzenie Google do danych strukturalnych opisuje, które typy dają wyniki rozszerzone.

Dane strukturalne FAQ nie dają już wyników rozszerzonych. Według rejestru zmian dokumentacji Google Search Central wyniki rozszerzone FAQ przestały się pokazywać od 7 maja 2026, a dokumentację tej funkcji Google usunął 15 czerwca 2026. Blok FAQ we wpisie nadal ma sens dla czytelnika i jako gotowe odpowiedzi dla AI, ale rozwijanych pytań pod wynikiem w Google już nie będzie. Poradniki, które w 2026 roku obiecują „więcej miejsca w SERP dzięki FAQ schema”, opisują stan sprzed maja.

Typ WebSite na stronie głównej ma jeszcze jedną funkcję: według dokumentacji Google o nazwach witryn dane strukturalne WebSite to najważniejszy sposób, by podpowiedzieć Google nazwę witryny wyświetlaną w wynikach. Nazwę witryny ustawiasz we wtyczce SEO i w Ustawienia → Ogólne, tak samo w obu miejscach.

Krok 8. Linkuj wewnętrznie

Linkowanie wewnętrzne to najtańszy sposób, żeby Google znalazł i zrozumiał nowe wpisy. Przewodnik SEO Google mówi, że Google znajduje strony przede wszystkim przez linki ze stron, które już crawlował, a sitemapa jest dodatkiem. Według dokumentacji Google o linkach Google crawluje zwykle tylko linki w elemencie <a href>, a dobry anchor jest opisowy, zwięzły i pasuje do strony docelowej.

Na WordPressie linkowanie wewnętrzne robię w trzech miejscach:

• Linkowanie wewnętrzne w treści wpisu: 2–5 linków z opisowym anchorem do powiązanych wpisów, dodawanych także do starych wpisów po publikacji nowego.
• W kategoriach i okruszkach (breadcrumbs) z wtyczki SEO, które budują hierarchię strony.
• W bloku „Powiązane wpisy” albo Query Loop w szablonie wpisu.

Yoast SEO Premium podpowiada linki podczas pisania i wyszukuje wpisy bez linków przychodzących (orphaned content). Ja do tego celu napisałem IndexFixer Pro, wtyczkę, która pokazuje status indeksacji każdego URL-a z GSC i linkuje wewnętrznie do wpisów, których Google jeszcze nie zaindeksował. To mój produkt, więc traktuj tę rekomendację z odpowiednim dystansem.

Stare linki i stare wpisy w starym WordPressie

Linkowanie wewnętrzne w starym WordPressie psuje się przy każdej zmianie domeny, protokołu albo struktury odnośników, bo linki w treści wpisów są zapisane w bazie jako pełne adresy. Crawl bynajmniej.pl z 14.10.2026 znalazł 83 linki wewnętrzne po HTTP (stare odnośniki http:// i http://www.), 186 przekierowań 3xx, z czego 61 to łańcuchy, i 60 URL-i z kodem 4xx, głównie obrazy z wpisów z lat 2008–2009. Przykład łańcucha: http://www.bynajmniej.pl/wp-content/uploads/2009/06/kaspar.jpg → 301 → 404. Linki http:// w treści wpisów poprawiłem tego samego dnia.

Linki w treści po zmianie adresów zamieniam w bazie poleceniem WP-CLI wp search-replace, np. wp search-replace 'http://www.example.com' 'https://example.com' --dry-run, a potem bez flagi --dry-run, po zrobieniu kopii bazy. Ten sam crawl pokazał też 45 stron na głębokości 4 lub więcej kliknięć od strony głównej i 77 stron z wewnętrznymi linkami nofollow, które warto zamienić na zwykłe linki.

Stare, cienkie wpisy Google zna, ale nie zawsze indeksuje. Na bynajmniej.pl URL Inspection w GSC pokazał status „Strona zeskanowana, ale jeszcze niezindeksowana” dla 2 wpisów z lat 2008–2009, a crawl znalazł 20 stron poniżej 200 słów. Takie wpisy odświeżam, scalam przez 301 z nowszym wpisem na ten sam temat albo usuwam. Scalanie wpisów o tej samej frazie opisałem w poradniku o kanibalizacji słów kluczowych.

Krok 9. Ustaw przekierowania 301 i pilnuj błędów 404

Przekierowanie 301 przenosi użytkownika i sygnały ze starego adresu na nowy. Według dokumentacji Google o kodach HTTP przekierowania 301 i 308 są silnym sygnałem, że nowy adres ma być kanoniczny, a 302 i 307 słabym. Googlebot przechodzi maksymalnie 10 przekierowań w łańcuchu.

WordPress przekierowuje sam głównie wtedy, gdy zmienisz slug opublikowanego wpisu (i czasem zgaduje podobny adres przy błędzie 404). Usunięty wpis, scalone artykuły, zmiana struktury odnośników i migracja domeny wymagają ręcznych przekierowań. Redirection to darmowa wtyczka bez wersji płatnej, która obsługuje przekierowania 301, wyrażenia regularne, log błędów 404 oraz import i eksport reguł do .htaccess i Nginx.

Na bynajmniej.pl Redirection trzyma ponad 30 reguł, m.in. przekierowania starych tagów na wpisy. Ten poradnik też jest efektem przekierowań: stare wpisy o SEO WordPressa z 2008–2010 roku scaliłem w jeden adres. Przy scalaniu wpisów przekierowuję stary URL na najbliższy tematycznie wpis, nie na stronę główną, bo według poradnika Google o przenoszeniu witryny wiele starych adresów przekierowanych na jeden niepowiązany adres, np. stronę główną, Google może potraktować jak pozorny błąd 404.

Ten sam poradnik Google zaleca przy zmianie adresów przekierowania po stronie serwera (301 albo 308) z każdego starego URL-a na jego odpowiednik, bez łańcuchów, utrzymywane co najmniej rok, oraz aktualizację linków wewnętrznych i sitemapy. Po zmianie struktury odnośników na WordPressie oznacza to też poprawienie starych linków w treści wpisów (krok 8).

Krok 10. Zabezpiecz WordPressa przed spamem SEO

Zhakowany WordPress to problem SEO, nie tylko bezpieczeństwa, bo włamanie często nie zmienia wyglądu strony, tylko dokłada spamowe podstrony albo ukryte linki. Zasady Google dotyczące spamu wymieniają zhakowane treści (treści umieszczone bez zgody właściciela przez lukę w zabezpieczeniach) i spam od użytkowników (komentarze, profile) jako osobne naruszenia. Od 13 kwietnia 2026 zasady Google w sekcji o złośliwych praktykach obejmują też przechwytywanie przycisku Wstecz (back button hijacking), czyli manipulowanie historią przeglądarki tak, żeby użytkownik nie mógł wrócić na poprzednią stronę. Na WordPressie warto więc sprawdzić, co robią skrypty reklamowe i wtyczki „zatrzymujące” czytelnika.

Minimum ochrony WordPressa przed spamem SEO to:

• automatyczne aktualizacje rdzenia WordPressa, wtyczek i motywów (przełącznik per wtyczka od WordPressa 5.5),
• usunięte nieużywane wtyczki i motywy, bo wyłączona wtyczka z luką nadal leży na serwerze,
• uwierzytelnianie dwuskładnikowe dla kont administratorów,
• filtr spamu w komentarzach (np. Akismet) albo wyłączone komentarze,
• kopie zapasowe plików i bazy trzymane poza katalogiem publicznym strony.

Kopie zapasowe w katalogu publicznym łatwo przeoczyć: plik backup.sql albo wp-config.php.bak w katalogu strony serwer odda każdemu jako zwykły tekst. Ślady włamania pokazuje raport Problemy dotyczące bezpieczeństwa w GSC: według pomocy Google raport rozróżnia wstrzyknięcie kodu, treści i adresów URL, złośliwe oprogramowanie i socjotechnikę, a po naprawie prosisz w nim o weryfikację, która trwa od kilku dni do kilku tygodni.

Krok 11. Podłącz Google Search Console

Google Search Console pokazuje, które URL-e WordPressa Google zaindeksował, na jakie zapytania strona się wyświetla i czy ma problemy techniczne. Po podłączeniu WordPressa w GSC robię cztery rzeczy:

1. Zgłaszam sitemapę z wtyczki SEO (np. /sitemap_index.xml) w raporcie Mapy witryn.
2. Sprawdzam raport Indeksowanie stron pod kątem archiwów tagów, załączników i adresów z parametrami.
3. Przeglądam raport Core Web Vitals i Problemy dotyczące bezpieczeństwa.
4. Ustawiam w GSC co najmniej dwóch właścicieli, żeby dostęp nie zależał od jednego konta.

Google Search Console ma od 2026 roku także raporty skuteczności w funkcjach generatywnej AI: Google udostępnił je wszystkim witrynom do 31 sierpnia 2026. WordPress nie potrzebuje do AI Overviews osobnych ustawień: według dokumentacji Google o funkcjach AI nie ma dodatkowych wymagań ani specjalnych optymalizacji, żeby pojawić się w AI Overviews albo AI Mode (w dokumentacji Google po angielsku: „There are no additional requirements to appear in AI Overviews or AI Mode”). Więcej o tym, jak zmienia się ruch z wyszukiwarki, pisałem w tekście SEO bez kliknięć.

Brak specjalnych wymagań nie znaczy, że nic nie trzeba sprawdzić. Pod AI search na WordPressie sprawdzam trzy rzeczy:

• robots.txt: wirtualny plik WordPressa i Yoast SEO nie blokują botów AI, a na bynajmniej.pl GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot i PerplexityBot dostały pełną treść strony (test z podszytym user agentem, więc wynik orientacyjny),
• wtyczki bezpieczeństwa i CDN, które potrafią blokować boty AI niezależnie od robots.txt,
• treść w HTML: motyw Twenty Twenty-Five na bynajmniej.pl wysyła całą treść wpisu w HTML, bez potrzeby uruchamiania JavaScriptu.

Na efekty zmian trzeba poczekać. Przewodnik SEO Google mówi, że część zmian działa po kilku godzinach, a część po kilku miesiącach, i radzi odczekać kilka tygodni przed oceną efektów. Pełną procedurę przeglądu strony, od indeksacji po widoczność w AI, opisałem w poradniku jak zrobić audyt SEO.

Najczęstsze błędy SEO na WordPressie

Najczęstsze błędy SEO na WordPressie, które widzę przy przeglądach stron, wynikają z ustawień, nie z treści:

• błąd: zaznaczone „Proś wyszukiwarki o nieindeksowanie witryny” po migracji ze strony testowej,
• dwie wtyczki SEO naraz (podwójne title, canonical i schema) albo dwie wtyczki cache,
• zmieniona struktura bezpośrednich odnośników bez przekierowań 301,
• noindex wpisany do robots.txt albo strony z tagiem noindex zablokowane w robots.txt, przez co Google tagu nie widzi,
• setki indeksowalnych tagów z jednym wpisem i włączone strony załączników na starej instalacji,
• obrazy wgrywane prosto z aparatu albo generatora AI, bez zmiany rozmiaru i nazwy pliku,
• nieaktualizowane wtyczki i kopie zapasowe w katalogu publicznym,
• usunięte wpisy bez przekierowań, czyli rosnąca lista błędów 404 w GSC.

Jeśli stronę na WordPressie ma prowadzić ktoś z zewnątrz, w tekście czym naprawdę zajmuje się specjalista SEO opisałem, czego od niego oczekiwać.

FAQ: SEO i pozycjonowanie WordPressa

Jaka wtyczka SEO do WordPressa jest najlepsza?

Na nową stronę najwięcej za darmo daje Rank Math, a ważniejsze od wyboru wtyczki SEO jest używanie tylko jednej. Yoast SEO ma 10+ mln aktywnych instalacji, ale w wersji darmowej nie ma przekierowań. Rank Math (4+ mln instalacji) ma za darmo przekierowania, monitor 404 i integrację z GSC. SEOPress PRO jest najtańszy (49 USD rocznie za 1 stronę, stan na 14.10.2026).

Czy WordPress jest dobry dla SEO?

WordPress jest dobry dla SEO, jeśli go skonfigurujesz. Rdzeń ma sitemapę, lazy loading, obsługę WebP i AVIF oraz automatyczne aktualizacje, ale nie ma meta description, danych strukturalnych ani menedżera przekierowań, więc potrzebuje wtyczki SEO i kontroli archiwów.

Według W3Techs WordPress obsługuje 40,0% wszystkich stron internetowych i 58,5% stron ze znanym CMS-em, a 65,7% instalacji działa już na wersji 7 (dane z 14.10.2026).

Jaką strukturę bezpośrednich odnośników wybrać w WordPressie?

Na nowej stronie wybierz „Nazwa wpisu” (/%postname%/). Na działającej stronie nie zmieniaj struktury bez przygotowanych przekierowań 301, bo słowa kluczowe w URL według Google prawie nie wpływają na ranking, a utrata zaindeksowanych adresów wpływa bardzo.

Czy ustawiać noindex na tagach w WordPressie?

Noindex ustawiaj na tagach z 1–3 wpisami i na archiwach, które powielają inne listy wpisów. Tagi z wieloma wpisami i własnym opisem mogą zostać indeksowalne. Archiwum autora na blogu jednego autora lepiej ustawić na noindex.

Ile trwa pozycjonowanie strony na WordPressie?

Google nie podaje jednego terminu. Według przewodnika SEO Google część zmian działa po kilku godzinach, a część po kilku miesiącach, a efekty warto oceniać po kilku tygodniach. Nikt też nie może zagwarantować pierwszego miejsca w Google, co Google pisze wprost.

SEO WordPressa od 2008 roku: co się zmieniło

Pierwsze teksty o SEO WordPressa pisałem tu w 2008 roku, kiedy WordPress miał wersję 2.x, a SEO bloga robiło się w edytorze plików motywu. Wersja z 2010 roku radziła m.in.:

• otworzyć header.php i ręcznie przestawić kolejność w <title>, żeby tytuł wpisu był przed nazwą bloga,
• zamienić H1 w logo na <div>, bo „H1 może być użyty tylko raz”,
• wyrzucić H2 z sidebaru i stopki,
• pisać meta description na 15–20 słów.

W wersji z 2008 roku za przykład złych praktyk robił Antyweb, a kod wklejało się w tagach {code}, które dziś wyświetlają się jako, no cóż, {code}. Już w aktualizacji wpisu z 2010 roku napisałem, że większość tych problemów rozwiązuje wtyczka WordPress SEO by Yoast.

Po 16 latach wtyczka Yoast SEO dalej rozwiązuje problem tagu title, tylko edytujemy header.php klikamy w ustawieniach. „H1 tylko raz” Google zastąpił zdaniem, że kolejność nagłówków dla wyszukiwarki nie ma znaczenia. Meta description na 15–20 słów zastąpiła informacja, że Google i tak pisze snippety głównie z treści strony.

Od 2008 roku w SEO WordPressa nie zmieniło się jedno: strona ma się indeksować, ładować szybko, mieć sensowne adresy i linki, a WordPress dalej nie jest „idealnie zoptymalizowany” po instalacji.

Paweł Zinkiewicz

Członek zarządu i współwłaściciel agencji IF.PL, w SEO od ponad 20 lat (m.in. Gazeta.pl, Wirtualna Polska, Polska Press). Na bynajmniej.pl piszę z pomocą AI: temat, dane i testy są moje, AI pomaga ubrać to w słowa.