Techniczna optymalizacja SEO WordPressa: poradnik dla właściciela strony

Techniczna optymalizacja SEO WordPressa sprowadza się do dziesięciu rzeczy: Google musi mieć dostęp do strony, robots.txt nie może blokować ważnych plików, mapa witryny ma zawierać tylko właściwe adresy, noindex i canonical porządkują duplikaty, zmienione adresy dostają przekierowanie 301, strona ładuje się szybko, obrazki mają opisy, dane strukturalne zgadzają się z treścią, a błędy w Search Console sprawdzasz, zanim zaczniesz je naprawiać. Większość z tego ustawisz w jednej wtyczce SEO i w kokpicie WordPressa. Największe ryzyko: optymalizacja szybkości potrafi po cichu zepsuć formularz.

To poradnik techniczny. Jeśli zaczynasz od zera i chcesz najpierw zrozumieć frazy, treści i strukturę strony, przeczytaj poradnik SEO krok po kroku dla strony na WordPressie, a potem wróć tutaj. Jeśli strony jeszcze nie masz, zacznij od poradnika, jak stworzyć stronę internetową.

Zanim zaczniesz: jedna wtyczka SEO i Search Console

Jedna wtyczka SEO. Yoast SEO, All in One SEO, Rank Math czy SEOPress robią podobne rzeczy: tytuły i opisy, mapę witryny, noindex, canonical i dane strukturalne. Wybierz jedną i nie instaluj drugiej obok.

Google Search Console. Bez niej zgadujesz. Dodaj stronę i potwierdź własność. Każdy kolejny krok sprawdzisz właśnie tam.

1. Indeksacja: czy Google w ogóle może widzieć stronę

W kokpicie wejdź w Ustawienia, Czytanie i sprawdź pole „Proś wyszukiwarki o nieindeksowanie witryny”. Według dokumentacji WordPressa zaznaczone pole dodaje do każdej podstrony znacznik noindex, nofollow, a mapa witryny WordPressa przestaje działać.

Potem wklej adres strony głównej i jednej usługi do narzędzia sprawdzania adresów URL w Search Console. Zobaczysz, czy adres jest w indeksie, i jeśli nie, z jakiego powodu.

Przy okazji sprawdź, czy strona otwiera się pod adresem z https i czy wersja z http przekierowuje na nią. Google traktuje bezpieczne połączenie jako część wrażeń ze strony, a w Search Console ma osobny raport HTTPS.

2. robots.txt: co blokować, a czego nie

Plik robots.txt mówi robotom, gdzie mogą chodzić. Według Google służy głównie do zarządzania ruchem robotów, a nie do ukrywania stron. Adres zablokowany w robots.txt może pojawić się w wynikach, tylko bez opisu.

Dla małej strony usługowej robots.txt zwykle nie wymaga żadnej pracy. Sprawdź tylko, czy:

• nie ma w nim linii `Disallow: /`, która blokuje całą stronę,
• nie blokuje katalogów z plikami CSS, JavaScript i obrazkami, bo bez nich Google nie zobaczy strony tak, jak widzi ją człowiek,
• zawiera adres mapy witryny (wtyczka SEO dopisuje go sama).

3. Mapa witryny

Mapa witryny to plik z listą adresów, które chcesz mieć w Google. Od wersji 5.5 WordPress tworzy ją sam pod adresem `/wp-sitemap.xml`. Wtyczki SEO zwykle wyłączają tę wbudowaną mapę i dają własną, np. `/sitemap_index.xml`.

Trzy kroki:

1. Otwórz mapę w przeglądarce i sprawdź, czy są tam usługi, wpisy i ważne podstrony.
2. Usuń z mapy to, czego nie chcesz w Google: strony tagów, autorów, podziękowań. Wtyczka SEO zwykle robi to sama po ustawieniu noindex.
3. Zgłoś adres mapy w Search Console, w sekcji Mapy witryny.

4. noindex: które podstrony ukryć

Noindex to znacznik, który mówi Google: tej podstrony nie pokazuj w wynikach. Na stronie eksperta lub małej firmy dobrzy kandydaci to:

• strona podziękowania po wysłaniu formularza,
• archiwa tagów i autora, jeśli tylko powtarzają wpisy,
• wyniki wewnętrznej wyszukiwarki,
• strony testowe i robocze.

Uwaga: noindex działa tylko wtedy, gdy Google może wejść na podstronę. Jeśli zablokujesz ją w robots.txt, robot nie zobaczy znacznika, a adres może dalej wisieć w wynikach. Więcej o samym znaczniku przeczytasz we wpisie meta robots noindex: co to jest i kiedy stosować.

Cztery narzędzia, które najczęściej się myli:

5. Canonical: jeden adres dla jednej treści

Ta sama treść potrafi być dostępna pod kilkoma adresami, np. z dopiskiem `?utm_source=newsletter` z linku w newsletterze. Znacznik canonical wskazuje, który adres jest główny. Wtyczka SEO ustawia go automatycznie na adres samej podstrony i w większości przypadków to wystarczy.

Według Google canonical to silny sygnał, ale nie rozkaz. Silniejsze jest przekierowanie, słabsze sama obecność adresu w mapie witryny. Google odradza też używanie noindex do wybierania głównego adresu w obrębie jednej strony, bo noindex usuwa podstronę z wyników całkowicie. Więcej we wpisie link rel canonical: co to jest i kiedy stosować.

6. Przekierowania 301 przy zmianie adresu

Zmieniasz adres podstrony, łączysz dwie usługi w jedną albo przenosisz stronę na nową domenę? Każdy stary adres powinien prowadzić na nowy przekierowaniem stałym. Google zaleca przekierowania po stronie serwera z kodem 301 albo 308, przygotowanie mapy „stary adres, nowy adres” i trzymanie przekierowań co najmniej rok.

W WordPressie przekierowanie ustawisz wtyczką do przekierowań albo w części wtyczek SEO. Po zmianie kliknij stary adres i sprawdź, czy prowadzi od razu na właściwą podstronę, a nie przez kilka przekierowań po drodze albo na stronę główną.

Zanim cokolwiek przekierujesz, zajrzyj w Ustawienia, Bezpośrednie odnośniki. Domyślnie WordPress dokleja do adresów wpisów datę. Na stronie usługowej czytelniejsze jest ustawienie „Nazwa wpisu”, ale zmieniaj je tylko na nowej stronie. Na działającej zmiana dotyczy wszystkich wpisów naraz i każdy stary adres potrzebuje przekierowania.

Przy zmianach w całym serwisie uprzedzam klientów, że przez pierwsze 2 do 4 tygodni ruch z Google może chwilowo spaść, bo Google musi przeindeksować nową strukturę.

7. Szybkość i Core Web Vitals bez psucia formularzy

Google mierzy wrażenia użytkownika trzema wskaźnikami Core Web Vitals. Dobre wartości według web.dev to:

• LCP (wczytanie największego elementu): do 2,5 sekundy,
• INP (reakcja na kliknięcie): do 200 milisekund,
• CLS (przesuwanie się układu strony): do 0,1.

Wynik jest dobry, gdy co najmniej 75% odsłon mieści się w tych wartościach, osobno na telefonach i komputerach. Sprawdzisz go w PageSpeed Insights i w raporcie Podstawowe wskaźniki internetowe w Search Console.

Wynik w PageSpeed Insights mówi, że jest problem, ale nie mówi, gdzie. Do konkretnych poprawek u klientów, których strony prowadzę, używam narzędzi pokazujących, co dzieje się w środku strony, np. WebPageTest i Query Monitor. Potem idę w kolejności od najbezpieczniejszej zmiany do najbardziej ryzykownej:

1. Podstawy: lżejsze grafiki i fonty, cache, zmniejszenie plików CSS i JavaScript, wyłączenie skryptów tam, gdzie nie są potrzebne.
2. Dopiero potem odraczanie i opóźnianie skryptów. Tu zaczyna się ryzyko dla funkcji strony.
3. Na końcu CDN i płatne usługi. Gdy problemem jest słaby serwer albo kilka kreatorów stron (builderów) naraz, CDN, czyli sieć serwerów podająca pliki strony bliżej odwiedzającego, maskuje problem zamiast go rozwiązać. Często największy skok szybkości daje zmiana hostingu.

Dlaczego krok 2 jest ryzykowny? U jednego z klientów opcja odraczania JavaScriptu w optymalizatorze dołożyła atrybut `defer` do plików, ale nie mogła odroczyć powiązanych z nimi krótkich skryptów wpisanych w kod strony. Te uruchamiały się za wcześnie i jedna z funkcji przestała działać. Ten sam mechanizm może wystąpić w każdej wtyczce, która odracza skrypty, niezależnie od marki.

Dlatego po każdej zmianie w optymalizacji klikam ręcznie najważniejsze akcje: wysyłkę formularza (i sprawdzenie, czy wiadomość doszła), zapisy, popupy, a w sklepie koszyk i zamówienie. Każdą w trzech warunkach: jako zalogowany, niezalogowany i w oknie incognito. Różnica między nimi to miejsce, w którym awaria chowa się najczęściej.

8. Obrazki i tekst alternatywny

Obrazki często ważą najwięcej na całej stronie. Przed wgraniem zmniejsz je do rozmiaru, w jakim faktycznie się wyświetlają, i skompresuj. Zdjęcie prosto z telefonu w nagłówku potrafi samo wydłużyć wczytanie największego elementu (LCP).

Drugi element to tekst alternatywny (alt). Google używa go razem z analizą obrazu i treścią strony, żeby zrozumieć, co jest na grafice. Pisz go jak opis dla osoby, która obrazka nie widzi, np. „Fizjoterapeutka pokazuje pacjentowi ćwiczenie na kręgosłup” (przykład wymyślony na potrzeby tekstu). Google ostrzega przed upychaniem fraz w alt: to pogarsza odbiór i może zostać uznane za spam. Grafiki czysto dekoracyjne mogą mieć pusty alt. Więcej przykładów znajdziesz we wpisie alt obrazka: co to jest i kiedy stosować.

9. Dane strukturalne: co ma sens, a co jest stratą czasu

Dane strukturalne to opis strony zapisany w kodzie w formie czytelnej dla Google: kto jest autorem wpisu, jaka firma prowadzi stronę, gdzie ma siedzibę. W projektach, które prowadzę, ustawiam je od startu przez wtyczkę SEO: dane firmy, wpisy, a w sklepie produkty.

Trzy fakty, które oszczędzają czas:

• Dane muszą opisywać to, co widać na stronie. Google nie pozwala oznaczać treści niewidocznej dla czytelnika.
• Poprawne dane nie gwarantują wyników rozszerzonych. Google pisze wprost, że umożliwiają je, ale nie obiecują.
• Wyniki rozszerzone FAQ zniknęły z Google. Od 2023 roku pokazywały się tylko na stronach rządowych i medycznych, a w 2026 roku Google przestał je wyświetlać. Dopisywanie FAQ do kodu z myślą o rozwijanych pytaniach w wynikach nic już nie da.

Dla firmy usługowej z lokalnymi klientami najwięcej sensu ma opis firmy (LocalBusiness) spójny z Profilem Firmy w Google. Jak go uporządkować, opisałem w tekście o wizytówce Google dla specjalisty. Samych danych strukturalnych jako osobnej optymalizacji nie robię. Gdy wyświetlenia rosły, zawsze szło to w parze z uporządkowaniem treści, więc efektu nie da się przypisać samym danym strukturalnym.

Po zmianach sprawdź kod w Teście wyników z elementami rozszerzonymi od Google albo w walidatorze Schema.org. Stary Structured Data Testing Tool, polecany w wielu poradnikach, nie jest już narzędziem Google.

10. Błędy w Search Console: co naprawiać, a co zostawić

Search Console prawie zawsze o czymś informuje i nie jest to sygnał awarii. Według pomocy Google większość stron ma niezaindeksowane adresy i to może być w porządku. W indeksie mają być ważne podstrony.

Jak czytać raport Indeksowanie stron:

• „Alternatywna strona zawierająca prawidłowy tag strony kanonicznej”: wszystko działa, nic nie rób.
• „Strona zawierająca przekierowanie”: stary adres prowadzi na nowy, tak ma być.
• „URL zawiera tag „noindex””: sprawdź listę. Jeśli są tam tylko podziękowania i tagi, to celowe. Jeśli jest tam usługa, masz problem do naprawy.
• „Nie znaleziono (404)”: jeśli usunięta podstrona miała następcę, ustaw 301. Jeśli nie miała, 404 jest poprawną odpowiedzią.
• „Strona zeskanowana, ale jeszcze niezindeksowana”: Google był na stronie i na razie jej nie dodał. Ponowne zgłaszanie nie pomoże. Zastanów się, czy podstrona wnosi coś, czego nie ma gdzie indziej.

Przy mailach z Search Console działam w trzech krokach: sprawdzam, czy to w ogóle problem, potem jakich adresów dotyczy (często to celowe wykluczenia), i dopiero przy prawdziwych podstronach poprawiam ustawienia, czyszczę cache i proszę w Search Console o sprawdzenie poprawki.

Kiedy zrobić to samemu, a kiedy zlecić

Zrób sam, gdy: masz prostą stronę usługową, jedną wtyczkę SEO i chcesz przejść tę listę raz, spokojnie, z kopią zapasową pod ręką. Punkty 1 do 5 to głównie klikanie w ustawieniach, a pojedyncze przekierowania i lżejsze obrazki też ogarniesz sam.

Zleć, gdy: chcesz włączać odraczanie skryptów, zmieniasz adresy wielu podstron, przenosisz stronę na nową domenę albo Search Console zgłasza noindex lub 404 na usługach i nie wiesz skąd. Także wtedy, gdy strona po zmianach przestała działać: wtedy najpierw naprawa WordPressa, dopiero potem optymalizacja.

Mój zespół może przejrzeć stronę w ramach audytu strony, a jeśli wolisz, żeby ktoś pilnował techniki na bieżąco, zobacz, na czym polega opieka nad stroną. Szerzej o widoczności w Google piszę na stronie o pozycjonowaniu.

Najczęstsze pytania

Czy muszę naprawiać każdy błąd z Search Console?

Nie. Część komunikatów to informacja albo celowe wykluczenia, np. noindex na stronie podziękowania. Naprawiasz te, które dotyczą usług i ważnych wpisów.

Która wtyczka cache jest najlepsza dla SEO?

Ta, którą przetestujesz po włączeniu. Odraczanie skryptów może psuć formularze w każdej wtyczce, która je odracza, więc ważniejsze od nazwy jest włączanie opcji po kolei i test po każdej zmianie.

Ile czasu mija, zanim Google zobaczy poprawki?

Różnie, zależnie od tego, jak często Google odwiedza stronę. W Search Console możesz poprosić o sprawdzenie poprawki konkretnego problemu. Przy zmianach w całym serwisie licz się z kilkoma tygodniami przejściowych wahań ruchu.

Zobacz też: która wtyczka SEO do WordPressa i co naprawdę zmienia oraz wtyczki bezpieczeństwa: czego używam, a czego nie instaluję.

Search Console straszy, a Ty nie wiesz, co jest groźne?

Dostajesz maile o błędach indeksowania albo strona zwolniła i boisz się ruszać ustawień? Napisz do mnie, jaki komunikat dostajesz i na jakiej stronie. Powiem, czy to w ogóle problem i od czego zacząć. Odpowiadam zwykle tego samego dnia roboczego.