Wykryto lub zeskanowano, lecz nie zindeksowano: dwie diagnozy

„Strona wykryta” oznacza, że Google zna URL, ale nie ma potwierdzenia jego pobrania. „Strona zeskanowana” oznacza, że adres został pobrany, lecz nie trafił do indeksu. Zacznij od inspekcji konkretnego URL i daty ostatniego skanowania. Dla pierwszego stanu sprawdzaj odkrywanie oraz dostęp serwera; dla drugiego także wyrenderowaną treść, kanoniczność i wartość strony.

Te etykiety w Google Search Console bywają traktowane jak dwa warianty jednej awarii. Prowadzą jednak do innych pytań. Nie ma sensu poprawiać treści tylko dlatego, że znany adres nie został jeszcze pobrany; równie słabo działa wielokrotne zgłaszanie do indeksu strony, która już została odwiedzona, ale nadal wygląda na duplikat. Żaden z tych stanów sam nie dowodzi kary, błędu serwera ani niskiej jakości. Oznacza jedynie etap procesu, który trzeba połączyć z danymi o konkretnym URL.

Google podkreśla w pomocy raportu Indeksowanie stron, że nie każda znana strona musi być w indeksie. Najważniejsze jest, aby znalazły się tam kanoniczne wersje stron ważnych dla użytkownika. Filtr sklepu, parametr śledzenia albo kopia strony może prawidłowo pozostać poza indeksem. Zanim więc uruchomisz audyt SEO, oznacz w swojej próbce strony, które naprawdę powinny być wyszukiwalne.

Jak odczytać raport bez mylenia stanów?

W raporcie Indeksowanie stron kliknij konkretną przyczynę, a następnie wybierz reprezentatywne URL. Nie oceniaj całej witryny po liczbie „nie zindeksowano”: raport obejmuje także wiele adresów, których nie planujesz pokazywać w wynikach. Wybierz próbki z ważnych typów stron: usługi, kategorie, produkty i poradniki. Zapisz datę pomiaru oraz to, czy dany URL znajduje się w sitemapie i ma linki z serwisu.

Następnie użyj narzędzia do sprawdzania adresów URL dla każdej próbki. Porównaj informację zapisaną w indeksie z testem wersji opublikowanej. To dwa różne obrazy: pierwszy mówi, co Google wie z ostatniego przetwarzania, a drugi co jest dostępne teraz. Jeśli strona była niedostępna wczoraj i działa dzisiaj, rozbieżność nie jest sprzecznością. Zapisz oba wyniki, by nie przypisywać bieżącemu HTML przyczyny dawnego statusu.

Sprawdź datę ostatniego skanowania, dozwolenie na pobranie i indeksowanie, odpowiedź HTTP oraz adres kanoniczny zadeklarowany i wybrany przez Google, jeśli dane są dostępne. Dla strony zeskanowanej obejrzyj także wyrenderowany HTML lub zrzut ekranu z inspekcji. W przypadku dużej grupy podobnych URL wybierz po kilka próbek z różnych szablonów. Jeden wadliwy produkt nie dowodzi, że cała kategoria ma tę samą przyczynę.

Ścieżka A: strona wykryta, ale niezindeksowana

Ten stan mówi, że Google zna adres. Oficjalna pomoc wskazuje, że pobranie mogło zostać odłożone, między innymi z obawy o przeciążenie witryny. Data ostatniego skanowania w raporcie jest wtedy pusta. Nie wyciągaj jednak automatycznie wniosku, że serwer jest wolny. To jedna możliwa przyczyna opisana przez Google, a nie diagnoza każdego URL.

Najpierw sprawdź, skąd adres został odkryty. Czy prowadzi do niego zwykły link z odpowiedniej strony, czy występuje wyłącznie w mapie? Czy ważna usługa jest osiągalna z menu lub kontekstowego tekstu, a produkt z kategorii? Jeśli URL ma być docelowy, popraw ścieżkę odkrywania. Nie twórz masowych linków w stopce tylko po to, by zwiększyć ich liczbę. Link powinien pomagać użytkownikowi przejść do kolejnej logicznej strony.

Potem obejrzyj stan serwera i przestrzeń URL. Czy robot odkrywa tysiące filtrów, sortowań albo kalendarzy zamiast wartościowych stron? Czy w logach są wzrosty błędów 5xx, długi czas odpowiedzi lub ograniczenia dostępu? W małej witrynie jeden wykryty URL może po prostu czekać; w dużym sklepie masowe, długotrwałe zaleganie nowych produktów wymaga spojrzenia na skanowanie całej sekcji. Nie stosuj progów „po trzech dniach to awaria” bez danych o normalnym tempie tej witryny.

Sprawdź także, czy adres w sitemapie odpowiada kanonicznej, działającej stronie. Mapa z przekierowaniami, duplikatami i martwymi URL wysyła niejasny sygnał. Gdy usuniesz oczywistą blokadę lub poprawisz linki, możesz poprosić o indeksowanie pojedynczej ważnej strony. Google nie obiecuje, że prośba spowoduje dodanie do indeksu. Obserwuj przejście stanu w czasie, zamiast wysyłać ten sam URL bez końca.

Ścieżka B: strona zeskanowana, ale niezindeksowana

Tu Google pobrał adres. Raport nie mówi, dlaczego nie włączył go do indeksu, a sam stan nie musi oznaczać błędu. Zanim przeredagujesz tekst, upewnij się, że w ostatnim pobraniu robot otrzymał właściwą odpowiedź i zawartość. Test na żywo może ujawnić różnicę po poprawce, ale nie zmienia historii poprzedniego pobrania. Zapisz datę i porównaj wersje.

Sprawdź najpierw technikę: stabilny HTTP 200, brak przypadkowego noindex, dostęp do zasobów potrzebnych do renderowania, poprawny canonical oraz treść widoczną w HTML, który może odczytać Google. Jeśli skrypt wstawia główny tekst dopiero po działaniu zależnym od użytkownika, robot może zobaczyć inny dokument niż człowiek. Jeśli canonical wskazuje na inny adres, porównaj obie strony i sprawdź, czy ta druga jest właściwą reprezentacją. Nie traktuj wtedy dwóch URL jako dwóch osobnych problemów z indeksowaniem.

Dopiero po usunięciu barier oceń rolę treści. Czy strona odpowiada na odrębną potrzebę, czy jest prawie identyczna z innymi kartami? Czy ma pełną informację o usłudze lub produkcie, czy tylko szablon i kilka zmiennych pól? Czy użytkownik miałby powód wybrać ją spośród stron tej samej witryny? Porównaj z własnymi zaindeksowanymi stronami tego typu, nie z arbitralną liczbą słów. Google nie publikuje progu długości, po którym strona zyskuje indeksację.

Jeżeli jest to strona potrzebna tylko do obsługi interfejsu, jej brak w indeksie może być prawidłowy. Jeśli jest ważnym landing page, popraw konkretne braki: odrębną ofertę, odpowiedzi na realne pytania, link z właściwej sekcji i spójne sygnały kanoniczne. Po zmianie sprawdź, czy nowy HTML rzeczywiście zawiera poprawioną treść. Ponowna prośba o indeksowanie bez materialnej zmiany nie usuwa przyczyny, której jeszcze nie ustalono.

Dwutorowy arkusz diagnostyczny

Poniższy arkusz jest demonstracyjnym modelem pracy, a nie wynikiem audytu tej witryny. Wypełnij go rzeczywistymi URL, datami i dowodami z Search Console oraz serwera. Przypisz każdemu adresowi jedną decyzję redakcyjną: docelowy, duplikat, pomocniczy albo do usunięcia.

Arkusz oddziela obserwację od hipotezy. „Zeskanowano” jest obserwacją; „treść za słaba” pozostaje hipotezą, dopóki nie porównasz strony z jej odpowiednikiem i nie wykluczysz innych barier. „Wykryto” jest obserwacją; „serwer przeciążony” wymaga potwierdzenia w danych. Dzięki temu zespół nie wykonuje kosztownych zmian na wszystkich stronach tylko dlatego, że status brzmi niepokojąco.

Co mierzyć po poprawkach?

Zapisz próbkę adresów przed zmianą, a następnie sprawdź te same URL po kolejnych pobraniach. Patrz, czy Google zyskał dostęp, czy widzi właściwy canonical i czy faktycznie zaindeksował reprezentatywną stronę. Liczba wykluczonych URL może nadal rosnąć, jeśli sklep tworzy nowe parametry; nie oceniaj sukcesu wyłącznie po tej sumie. Ważniejsze są docelowe strony, ich widoczność oraz prawidłowe wykluczenie zbędnych wariantów.

Jeżeli wiele wartościowych URL przechodzi z „wykryto” do „zeskanowano”, jest to postęp w procesie, choć jeszcze nie sukces końcowy. Jeśli po zeskanowaniu pozostają poza indeksem, zastosuj drugą ścieżkę. Gdy problem dotyczy tylko jednej sekcji po wdrożeniu nowego szablonu, porównaj jej HTML i linki z sekcją działającą poprawnie. Jeśli dotyczy całej witryny, rozpocznij szerszy audyt techniczny obejmujący dostęp, renderowanie, kanoniczność i serwer.

Nie oczekuj, że każda strona zostanie zindeksowana. Google wprost wskazuje, że takie oczekiwanie jest błędne. Jeśli ważny URL nadal nie trafia do indeksu, zbierz dowody z inspekcji i przeanalizuj jego rolę. Powtarzanie zgłoszenia bez nowej informacji nie zastąpi diagnozy. Ogólna lista kontroli SEO technicznego pomoże przejść do pozostałych rodzajów problemów.

Co sprawdzić dalej?

Temat łączy się z kolejnymi decyzjami w serwisie. Zobacz także kanoniczny url, robots txt noindex canonical oraz core web vitals jak sprawdzić.