Indeksacja w WordPressie potrafi wyglądać jak loteria, dopóki nie spojrzy się na stronę jak na system, a nie zbiór podstron. W praktyce większość problemów nie bierze się z „pecha”, tylko z konkretnych decyzji technicznych: konfiguracji wtyczek, ustawień serwera, sposobu generowania URL, błędów w mapach strony czy konfliktów w canonicalach. Gdy robię audyt, szukam tych potknięć metodycznie, bo one prawie zawsze mają wspólny mianownik: Google widzi coś innego niż my.
W tym artykule przeprowadzę Cię przez najczęstsze błędy indeksacji, które wychodzą podczas technicznego przeglądu stron na WordPressie. Skupię się na tym, co sprawdzam, jak to diagnozuję i jak to naprawiam, żeby roboty zaczęły trafiać we właściwą wersję Twojej witryny. Będzie sporo konkretnych przykładów, bo wiem, że sama teoria szybko wpada do kosza.
Dlaczego w WordPressie indeksacja „siada” mimo poprawnej treści
Zdarzyło mi się prowadzić wdrożenie, w którym artykuły były świetne, linkowanie wewnętrzne porządne, a ruch z innych kanałów rósł. A jednak w Google Search Console widać było spadki i mnóstwo nieudanych lub wykluczonych URL. W takich sytuacjach ludzie zwykle szukają problemu „w tekście”. Tymczasem winny bywa kod, konfiguracja i logika generowania stron.
WordPress jest elastyczny, ale ta elastyczność ma cenę. Wtyczki do SEO, cache, optymalizacji obrazów, formularzy, a czasem automaty generujące strony pod wyniki wyszukiwania wprowadzają warianty tego samego adresu. Google nie lubi nadmiaru powtórek, a jeszcze mniej gdy powtórki są „poukładane” tak, że wyszukiwarka dostaje sprzeczne sygnały.
Najczęstszy schemat, który widzę w audycie technicznym strony WordPress, jest prosty: błędnie wskazany docelowy adres, blokada dla robota w warstwie, którą nikt nie pamięta, albo niepoprawne odpowiedzi HTTP dla podstron. Wtedy indeksacja nie tyle „nie działa”, co działa w złym kierunku.
Jak przygotowuję się do technicznego audytu indeksacji
Zanim odpaliłem narzędzia, zawsze zaczynam od uporządkowania mapy strony i tego, jak strona jest wystawiona na świat. Sprawdzam dostępność dla botów, podstawy w rodzaju robots.txt, mapy XML, nagłówki odpowiedzi i statusy w indeksowanych segmentach. Dopiero potem wchodzę w szczegóły, bo bez tej kolejności łatwo przegapić problem, który maskuje resztę.
W praktyce zawsze dążę do tego, żeby odpowiedzieć sobie na trzy pytania: czy Google w ogóle może wejść na właściwe URL-e, czy widzi sygnały kanoniczne w spójny sposób i czy mapa strony wskazuje adresy, które faktycznie istnieją oraz zwracają sensowną odpowiedź HTTP. Jeśli te trzy warstwy są w porządku, reszta zwykle jest mniej bolesna.
Podczas pracy lubię robić „mapowanie konfliktów”: w jednym miejscu zbieram, jakie sygnały pochodzą z WordPressa (np. canonical, meta robots), jakie z serwera (np. statusy, nagłówki), a jakie z wtyczek (np. zmiany w robots.txt lub mapach). To oszczędza mnóstwo czasu, bo wtyczki często walczą ze sobą.
Stan techniczny, który najczęściej rozwala indeksację
Problemy indeksacji rzadko są jednoetapowe. Najpierw coś utrudnia crawl, potem pojawia się konflikt sygnałów, a na końcu dochodzi do wykluczenia lub indeksowania nie tego, co chcieliśmy. Poniżej rozkładam na czynniki pierwsze najczęstsze winowajców, które regularnie spotykam przy audycie technicznym strony WordPress.
1) Robots.txt blokuje ważne zasoby lub całe sekcje
To jeden z najklasyczniejszych tematów. Czasem ktoś ustawia robots.txt „na testy”, czasem wtyczka SEO podmienia reguły po aktualizacji, a czasem konfiguracja serwera dodaje dodatkowe dyrektywy, o których nikt nie pamięta. Jeśli robots.txt blokuje URL-e, Google nie wejdzie na te strony nawet wtedy, gdy mapa XML je pokazuje.
W audycie zawsze porównuję robots.txt z listą URL z mapy strony i raportami z Search Console. Jeśli w mapie masz strony, które są blokowane przez robots.txt, to w praktyce prosisz Google o próbę wejścia na drzwi, których nie otwierasz.
Warto też zwrócić uwagę na dyrektywy typu Disallow dla konkretnych katalogów. Przy WordPressie typowe błędy dotyczą folderów z archiwami, tagami, wynikami wyszukiwania albo zasobów generowanych przez wtyczki.
2) Meta robots noindex, które „przeciekło” na właściwe podstrony
Drugi częsty problem to noindex w meta tagach. Zdarza się, że wtyczka SEO blokuje indeksowanie stron, które miały być „tylko do wglądu”, a potem ustawienie zostało przeniesione na cały typ podstron. Czasem też noindex jest zwracany dynamicznie, zależnie od roli użytkownika albo warunków cache.
Najprostsza diagnoza to podgląd źródła i nagłówków dla kilku przykładowych URL-e, które Google wyklucza. Jeśli widzę noindex tam, gdzie miało go nie być, to naprawa jest zwykle szybka, ale skutki mogą trwać tygodniami, bo Google musi ponownie przetworzyć sygnały.
W jednym wdrożeniu noindex pojawiał się tylko na wersji strony z konkretnym parametrem. Wtyczka generowała canonical na stronę bez parametru, a meta robots ustawiała noindex na tę wersję. W efekcie Google indeksował adres bezparametrowy, ale crawlował warianty, które i tak były zablokowane. To generowało bałagan w logach i w raportach.
3) canonical wskazuje złego „krewnego”
Tag rel=canonical jest jak podpis pod zdjęciem. Jeśli jest źle przepisany, Google przyjmie fałszywe założenie, która wersja jest docelowa. W WordPressie canonical potrafi pękać przez kilka powodów: błędy w konfiguracji wtyczki SEO, przekierowania, mieszanie HTTP i HTTPS, brak spójności www vs non-www albo niepoprawne ustawienia dla archiwów.
W audycie technicznym strony WordPress zwracam uwagę na spójność canonicalu z tym, co zwraca serwer. Jeśli canonical wskazuje URL, który zwraca 404 albo redirect 302 w pętli, to sygnał staje się nieskuteczny. Gorsza sytuacja to canonical prowadzący do wersji z parametrami, których Google nie powinien indeksować.
W praktyce zawsze weryfikuję canonical dla kilku typów stron: wpisów, stron statycznych, stron kategorii i tagów, stron autorów oraz stron z paginacją. W tych miejscach najłatwiej o niespodzianki.
4) Mapy XML zawierają URL-e, które nie powinny się tam znaleźć
Mapa strony ma pomagać w odkrywaniu. Jeśli trafia do niej adres, który zwraca błąd albo jest noindex, to mapa zaczyna działać jak lista zakupów z brakującymi produktami. Google może zignorować mapę, ale częściej po prostu doda kolejne wątki do „dlaczego to nie działa”.
W audycie sprawdzam, czy mapa XML jest aktualizowana, czy nie zawiera duplikatów, a także czy zawiera wyłącznie URL-e, które rzeczywiście zwracają poprawne odpowiedzi. Szczególnie uważałem na mapy, które uwzględniają archiwa generowane przez wtyczki do filtrów i wyszukiwania.
Jeśli w mapie widzę parametry typu ?s= albo ?orderby=, zwykle zaczynam dociekać, kto je dopisuje i dlaczego. Czasem to efekt ustawień wtyczki i jej „optymalizacji pod SEO”, która w rzeczywistości nakręca duplikację.
5) Nieprawidłowe statusy HTTP: 200 dla „nie istnieje” albo 404 dla prawidłowych treści
Statusy HTTP to fundament. Google indeksuje na podstawie tego, co dostaje w odpowiedzi. Jeśli serwer zwraca 200 dla strony, która w praktyce prowadzi do pustej treści, albo 302 do innej wersji, a czasem 200 z treścią 404, wyszukiwarka traktuje to ostrożnie.
W WordPressie problem najczęściej pojawia się przy cache i CDN. Bywa, że cache zapisuje błędne odpowiedzi i potem serwuje je na stałe, a dopiero po czasie „ktoś” to czyści. Ja w audycie zawsze sprawdzam statusy dla kluczowych URL w kilku lokalizacjach: bez cache, z cache, i na poziomie CDN jeśli jest wdrożony.
Jeśli masz dużo wykluczonych stron z powodu „soft 404”, to zwykle w serwerze albo w warstwie aplikacji jest logika, która podmienia treść. Wtedy sam noindex nie uratuje sytuacji.
6) Pętle przekierowań i niespójność wersji domeny
Przekierowania 301 są dla SEO jak porządek na skrzyżowaniu. Jeśli jednak pojawiają się pętle, Google będzie się męczył, a Ty dostaniesz chaos w indeksie. Klasyk to sytuacja, gdy jedna warstwa kieruje z http na https, druga z non-www na www, a trzecia miesza kolejność. W efekcie powstaje sekwencja, która nie kończy się w rozsądnym czasie.
W audycie zawsze weryfikuję, jak strona zachowuje się dla podstawowych wariantów: http, https, www, non-www oraz z wybranymi parametrami. Jeśli jest choć cień pętli, to naprawa zwykle polega na ujednoliceniu reguł na poziomie serwera i w WordPressie.
W jednej realizacji wtyczka SEO robiła canonical na https, ale serwer dopiero po drodze wymuszał https, a po drodze zmieniał też www. Dodatkowo cache trzymał stare nagłówki. Skończyło się na tym, że Google widział jednocześnie kilka wersji tego samego adresu, a część podstron trafiała w indeks w nieoczekiwanej formie.
7) Duplikacja treści przez filtry, sortowanie i parametry URL
To problem, który potrafi urosnąć do skali, której nikt nie przewiduje. WordPress z WooCommerce albo z rozbudowanym katalogiem produktów potrafi generować ogromną liczbę kombinacji: sortowanie, filtrowanie, parametry dostępności. Nawet jeśli te strony nie są „docelowe”, Google może je odkryć przez linki, mapę strony albo linkowanie wewnętrzne.
Ja w audycie szukam dwóch rzeczy: czy te warianty mają wartościowe treści (często nie mają) i czy zwracają spójny sygnał, że nie powinny trafiać do indeksu. Czasem rozwiązaniem jest blokada w robots.txt, czasem noindex, a czasem ustawienie canonical prowadzące do wersji bez filtrów.
Uwaga: nie wolno robić tego na ślepo. Jeśli parametry filtrów prowadzą do sensownych landingów, blokada może Cię uciąć w nogę. Natomiast jeśli mówimy o „tylko zmianie kolejności”, to zwykle lepiej nie karmić indeksu setkami prawie takich samych stron.
Architektura indeksacji: paginacja, archiwa i strony zliczające
WordPress naturalnie tworzy archiwa: kategorie, tagi, strony autorów, daty. W większości projektów nie wszystkie te archiwa zasługują na indeks. To się wydaje proste, ale w praktyce strefy duplikacji lub słabej wartości potrafią być ukryte w konfiguracji motywu i w zachowaniu wtyczek.
W paginacji (strona 2, 3, 4…) kluczowe jest to, czy każda kolejna strona ma realną treść i czy sygnały canonical prowadzą do właściwego adresu. Kiedy jest zlepek krótkich fragmentów i powtarzają się te same elementy, Google zaczyna traktować te URL jako małowartościowe.
Tagi i kategorie: kiedy indeksować, a kiedy składać do archiwum
Widziałem witryny, w których tagi były praktycznie kopiami kategorii, a czasem nawet gorzej opisane, bo autorzy wrzucali je „dla porządku”. W takich przypadkach indeksowanie tagów jest jak drukowanie tych samych ulotek na inny kolor papieru. Tylko więcej kosztuje i rozmywa sygnał.
W innych projektach tagi były rozbudowane, miały sensowne opisy i faktycznie odpowiadały na intencje użytkowników. Wtedy indeksowanie tagów miało sens, ale trzeba je utrzymać: dopilnować canonicali, meta robots i map strony.
W audycie technicznym strony WordPress najczęściej próbuję ustalić granicę: które archiwa są „landingami”, a które są „katalogami generowanymi”. Te drugie zwykle wymagają ograniczenia indeksacji.
Strony autorów, daty i archiwa specjalne
Strony autorów potrafią być wartościowe, szczególnie na blogach eksperckich. Jeśli jednak autorzy publikują mało, a ich archiwa są cienkie treściowo, to indeks może się nimi zapychać. W praktyce wiele witryn cierpi przez archiwa daty: dzień, miesiąc, rok, gdzie liczba wpisów jest marginalna.
W audycie sprawdzam, czy te strony mają unikalną treść (np. opis autora, bios), a jeśli nie mają, to szukam najlepszego wariantu: wyłączenie indeksowania, przekierowania do zbiorczych stron albo ograniczenie w mapach strony.
Najgorsze są przypadki, w których archiwa daty są indexowane, a równocześnie wtyczka SEO tworzy canonical do strony ogólnej. Google widzi sprzeczność i zaczyna mieszać w tym, co uznaje za główną wersję.
Konflikty wtyczek i ustawień: skąd biorą się sprzeczne sygnały
Jeśli miałbym wskazać jeden obszar, gdzie problemy indeksacji pojawiają się najczęściej, to byłby to konflikt ustawień. WordPress daje przestrzeń na wiele pluginów, ale rzadko kiedy wszystkie muszą jednocześnie sterować canonicalami, robots.txt i mapą strony.
Przykładowo: jedna wtyczka modyfikuje robots.txt, druga buduje mapy XML, trzecia dodaje schema, a czwarta optymalizuje indeks. Wtedy sygnały zaczynają się dublować, a w konsekwencji Google widzi miks, którego nie rozumie.
Jak to diagnozuję w praktyce
Zwykle robię prostą rzecz: zawężam problem do jednego typu URL i porównuję, co jest zwracane w kodzie HTML i nagłówkach. Jeśli canonical, meta robots i nagłówki serwera nie są spójne, to szukam wtyczki, która nadpisuje ustawienia.
Kiedy podejrzewam cache, testuję URL w trybie „bez cache” oraz z wyczyszczonym cache. To potrafi szybko pokazać, że problem nie jest w WordPressie, tylko w warstwie, która przechowuje błędne odpowiedzi.
Ja osobiście lubię robić listę zmian: jakie wtyczki i kiedy aktualizowałem, jakie ustawienia przestawiałem, co było włączone przed i po. W kilku projektach to była najszybsza droga do wykrycia, że po aktualizacji jedna wtyczka zaczęła dopisywać noindex do archiwów.
SEO, indeksacja i strona jako „system”: sygnały z serwera i aplikacji
W indeksacji liczy się to, co dochodzi do robota, nie to, co wydaje Ci się, że jest w konfiguracji. Dlatego w audycie zawsze patrzę na poziom serwera: statusy, przekierowania, nagłówki, odpowiedź dla konkretnych URL. Dopiero potem analizuję warstwę aplikacji.
Nagłówki i zachowanie strony przy różnych typach żądań
Googlebot to nie przeglądarka w sensie „klikam i przewijam”. W wielu wypadkach nagłówki i zachowanie serwera mają znaczenie. Jeśli serwer rozpoznaje ruch po user-agencie i zwraca inny wynik, to indeksacja może się nie zgadzać z tym, co widzi użytkownik.
W audycie sprawdzam także odpowiedzi przy kompresji, przy zmiennych nagłówkach i przy przekierowaniach z lub bez trailing slash (ukośnika na końcu). Niby drobiazg, ale w praktyce trailing slash potrafi dzielić indeks na warianty.
HTTPS, HSTS i mieszana zawartość
HTTPS to podstawa, ale czasem problemy są bardziej subtelne. HSTS i wymuszanie HTTPS bywają ustawione inaczej w warstwie serwera niż w aplikacji. Jeśli istnieją równoległe ścieżki, Google dostaje sprzeczne informacje o tym, jak ma obsługiwać domenę.
Zwracam też uwagę na mieszane treści: obrazy lub skrypty ładowane po HTTP. Google może to tolerować, ale to sygnał, że strona nie jest domknięta technicznie. W dłuższym czasie takie niedoróbki lubią wracać w postaci gorszej jakości odpowiedzi.
Diagnostyka w Search Console i na stronie: co analizuję jako pierwsze
Gdy dostaję zespół zaniepokojony indeksacją, zaczynam od danych z Search Console. Nie traktuję tego jak wyroczni, tylko jak mapę, gdzie są czerwone flagi. Potem do mapy dopinam testy i obserwacje zewnętrznych narzędzi.
Najczęściej weryfikuję raporty o stronach i indeksowaniu, zwłaszcza przypadki wykluczeń oraz typy błędów. Jeśli widzę powtarzające się powody, układam plan napraw w kolejności wpływu: najpierw to, co blokuje crawl, potem canonical i duplikację, na końcu sprawy kosmetyczne.
„Dlaczego wykluczono?” jako checklist dla technika
Każdy powód wykluczenia zwykle prowadzi do innej klasy problemu. Dlatego trzymam w głowie checklistę, ale lubię też mieć ją na kartce, dosłownie. Poniżej przykład, jak te kategorie tłumaczę sobie w praktyce, gdy szukam winnych.
| Objaw w Search Console | Najczęstsza przyczyna w WordPressie | Co sprawdzam najszybciej |
|---|---|---|
| Wykluczono przez robots.txt | Reguły w robots.txt nadpisane przez wtyczkę | robots.txt vs URL z mapy XML |
| Wykluczono: noindex | Ustawienia meta robots wtyczki lub szablonu | meta robots i nagłówki dla przykładowych URL |
| Duplikacja / canonical | Zły canonical, pętle przekierowań, brak spójności wersji | rel=canonical i statusy HTTP dla wersji wariantów |
| Soft 404 / błąd | Cache serwuje stronę błędną jako 200 | Statusy i treść odpowiedzi przy próbie bez cache |
| Błędy w mapie | Mapa zawiera URL-e nieistniejące lub zablokowane | czy URL w mapie mają poprawny status i dostępność |
To nie zastępuje analizy szczegółowej, ale przyspiesza decyzje. W audycie technicznym strony WordPress nie ma czasu na zgadywanie, gdy da się działać na danych.
Najczęstsze błędy w mapach strony i canonicalach: jak je porządkować
Mapa XML i canonical to para, która musi działać jak dobrze dobrani partnerzy w tańcu. Jeśli jeden prowadzi w lewo, a drugi w prawo, to Google traci orientację. Dlatego w moich audytach zawsze ustalam: co jest wersją główną, a co ma zostać ograniczone.
Najczęściej naprawa wygląda podobnie: koryguję mapę XML, wyłączam generowanie małowartościowych URL w ustawieniach wtyczki i dopilnowuję, by canonical prowadził zawsze do tej samej wersji dla danego typu strony.
Canonical na poziomie archiwów i wpisów
Wpisy zwykle nie sprawiają problemów, ale archiwa potrafią. Canonical na tagach i kategoriach zależy od konfiguracji: czy archiwum ma być indexowane, czy noindex, czy ma przekierowywać do innej sekcji. Jeśli to jest źle ustawione, Google dostaje sygnał „to jest główna wersja”, mimo że strona jest blokowana lub nie ma sensu.
W audycie pilnuję, żeby canonical nie wskazywał na wersję, która jest zablokowana przez robots.txt albo ma noindex. To rodzaj sprzeczności, która kosztuje czas.
Mapa XML dla paginacji
W paginacji łatwo przesadzić. Zdarza się, że mapa zawiera strony 2, 3, 4, 5 i dalej, choć część z nich nie ma unikalnej wartości. Wtedy indeks nie musi „zgadywać”, ale po prostu otrzymuje zbyt szeroki obraz.
W wielu projektach ograniczam mapy do kluczowych stron i zostawiam paginację do naturalnego odkrywania, zamiast karmić indeks komplet. Decyzję podejmuję na podstawie zachowania serwisu: czy paginacja niesie unikalną treść i czy użytkownicy faktycznie do niej wracają.
Indeksowanie a renderowanie: kiedy problemem nie jest „czy jest”, tylko „jak wygląda”
Czasem strony są indeksowane, ale fragmenty w wynikach są słabe, a Google ma trudność z zrozumieniem treści. Wtedy problem dotyczy renderowania lub tego, że kluczowa treść pojawia się dopiero po czasie. Dotyczy to zwłaszcza motywów z ciężkim JavaScriptem lub sytuacji, gdy cache i optymalizacje wtyczek psują kolejność ładowania.
W WordPressie problem renderowania bywa skutkiem agresywnych optymalizacji frontendu: minifikacji, opóźniania skryptów, łączenia plików w zły sposób lub błędnych reguł w loaderach. Googlebot nadal potrafi renderować, ale jeśli strona podaje niekompletne dane, ucierpi treść, którą dostaje wyszukiwarka.
W audycie sprawdzam, czy krytyczne elementy treści są obecne w początkowym HTML i czy nie znikają przy niektórych wersjach URL. To jeden z tych obszarów, gdzie „wszystko wygląda dobrze na przeglądarce” nie oznacza niczego dla robota.
Praktyczne naprawy: jak krok po kroku uspokajam indeks
Gdy przychodzi kryzys, nie naprawiam wszystkiego naraz. Ustalam kolejność, bo jeśli zrobisz pięć zmian naraz, nie wiesz, co zadziałało. Ja działam jak przy gaśnicy: najpierw odcinam to, co pali najbardziej, potem porządkuję resztę.
Etap 1: uporządkowanie wersji domeny i przekierowań
Zaczynam od spójności: jedna domena, jeden protokół, sensowne przekierowania 301. Dopiero potem ruszam z canonicalami. Jeżeli wcześniej masz warianty http/https albo www/non-www, to canonical i mapa będą tylko dokładały zamieszania.
Po zmianach robię szybki test dostępności URL z kilku wersji i sprawdzam, czy odpowiedzi kończą się w jednym, docelowym miejscu.
Etap 2: robots.txt i meta robots dla typów stron
Potem dopasowuję robots.txt i meta robots. Tu zazwyczaj wybieram podejście „minimum sprzeczności”. Jeśli strona ma być indeksowana, nie blokuję jej w robots.txt. Jeśli ma być wykluczona, upewniam się, że sygnały się zgadzają, czyli nie ma mapy z adresami, które i tak są noindex lub blokowane.
W audycie technicznym strony WordPress szczególnie lubię naprawiać to, co jest najłatwiejsze do zweryfikowania na próbce: kilka reprezentatywnych URL dla każdego typu strony. Po walidacji ruszam szerzej.
Etap 3: canonical i mapy XML
Po uporządkowaniu dostępu i sygnałów blokujących przechodzę do canonicali oraz map. Ustalam docelową wersję: czy archiwa tagów są indexowane, jak wygląda paginacja i czy parametry filtrów powinny w ogóle trafiać do mapy.
W praktyce najczęściej poprawiam trzy rzeczy: canonical przestaje wskazywać warianty, mapa zawęża się do URL o realnej wartości i znika duplikacja generowana przez filtry. Dopiero potem monitoruję, czy Search Console przestaje pokazywać wykluczenia w tych samych kategoriach.
Etap 4: statusy HTTP i cache
Na końcu przychodzą statusy i cache. Jeśli w serwisie jest CDN lub cache serwerowy, to potrafi utrwalać błędne odpowiedzi. Dlatego po każdej istotnej zmianie warto wyczyścić cache i sprawdzić odpowiedzi na świeżo.
Ja lubię też porównać statusy w narzędziach z różnych miejsc, bo czasem problem jest geograficzny lub wynika z reguł routingu. Dopiero gdy statusy są stabilne, uznaję temat za zamknięty.
Co mierzę po wdrożeniu poprawek
Nie robię zmian „na wiarę”. Mierzę efekt w czasie, ale też obserwuję, czy problem zmienia swój charakter. To ważne, bo czasem indeksacja poprawia się częściowo, ale w innym typie stron pojawia się nowy błąd.
Na start patrzę na to, czy w Search Console maleją wykluczenia dla konkretnych powodów. Potem sprawdzam, czy rośnie liczba stron prawidłowo zaindeksowanych dla wybranych typów URL. Jeśli widzę wzrost, ale równocześnie rosną błędy w mapach albo duplikacja, to znaczy, że poprawki uderzyły w jeden obszar, a reszta wymaga korekty.
Po wdrożeniu warto też monitorować logi dostępu lub przynajmniej zachowanie crawl w narzędziach. Jeśli bot zaczyna częściej odwiedzać kluczowe sekcje i rzadziej wraca do wykluczonych wariantów, zwykle oznacza to, że sygnały techniczne są bardziej spójne.
Najbardziej kosztowne błędy, które widziałem w realnych projektach
Da się naprawić większość problemów indeksacji, ale są takie, które kosztują najwięcej czasu i stresu. Poniżej zbieram trzy sytuacje, które zdarzały się często, a ich konsekwencje potrafiły się ciągnąć miesiącami.
Wypchnięcie mapy XML małowartościowymi wariantami
To klasyk w e-commerce. Ktoś włączył mapę, która generuje tysiące URL z filtrami. Wtedy indeks dostaje ogromny katalog prawie tych samych stron. Część z nich wpada do indeksu, część jest wykluczana, ale cały proces powoduje bałagan sygnałów i rozmywa tematykę.
Naprawa polega zwykle na zawężeniu mapy, ograniczeniu parametrów i ustawieniu canonical dla wersji docelowej.
„Noindex dla testu”, który przetrwał do produkcji
Widziałem to wielokrotnie. Ustawienie noindex na środowisku testowym miało zniknąć przed startem, ale ktoś zapomniał lub wtyczka wróciła do stanu sprzed wdrożenia. Efekt? Indeksacja rusza dopiero, gdy ktoś zauważy, że sygnał blokujący jest wciąż obecny.
Przyspieszenie polega na poprawnym przełączeniu ustawień i upewnieniu się, że zmiana trafiła do produkcji, a cache nie trzyma starej wersji.
Sprzeczne canonicale przy przekierowaniach
To problem „z początku drogi”: serwer przekierowuje, a wtyczka canonicalizuje inaczej. Google próbuje się zorientować, które wersje są właściwe. W czasie to się kończy wykluczeniem i indeksowaniem nie tej wersji, którą chciałeś promować.
W audycie zawsze rozbrajam to przez ujednolicenie reguł domeny i dopiero potem poprawiam canonical oraz mapy.
Jak zaplanować proces audytu, żeby nie zgubić się w szczegółach
Gdy robię audyt, nie zaczynam od „wszystkiego”. Zaczynam od tego, co ma największy wpływ na indeksację, czyli od możliwości crawl i spójności sygnałów. Dopiero wtedy przechodzę do subtelności, które są ważne, ale nie zanim podstawy zaczną działać.
Moja praktyczna kolejność zwykle wygląda tak: robots.txt i dostępność, następnie mapy XML i statusy HTTP, potem canonical i meta robots, a na końcu kwestie renderowania i duplikacji z filtrów. Dzięki temu, nawet jeśli wykryję kilka problemów, jestem w stanie je naprawiać po kolei i weryfikować efekt.
WordPress potrafi być uporządkowany, tylko trzeba go prowadzić
WordPress nie musi być chaosem. To narzędzie daje swobodę, ale ja traktuję ją jak narzędzie do budowania porządku, nie jak zachętę do dodawania kolejnych wtyczek bez kontroli. Gdy doprowadzam indeksację do ładu, zwykle wygrywa konsekwencja w sygnałach i stabilność odpowiedzi serwera.
Jeżeli miałbym zamknąć temat jednym zdaniem: indeksacja nie psuje się „z dnia na dzień” bez powodu. Psuje ją konkretne zachowanie strony, w tym sprzeczne sygnały, błędne statusy, konflikty wtyczek albo mapy, które pokazują Google coś, czego nie powinien indeksować. Gdy to uporządkujesz, wyszukiwarka dostaje czytelny obraz, a Ty zaczynasz widzieć wyniki, które mają sens biznesowy.
W kolejnych wdrożeniach wracam do tych samych lekcji: sprawdzaj dostępność, pilnuj canonicali, zawężaj mapy i nie ufaj temu, że „na przeglądarce działa”. Audyt techniczny strony WordPress – najczęstsze błędy indeksacji – to nie lista do odhaczenia. To droga do tego, żeby Twoja strona była logiczna dla robota tak samo, jak dla użytkownika.
