SEO • INDEKSACJA
Jeżeli strona nie pojawia się w Google, problem nie zawsze oznacza błąd techniczny.
Google może:
- nie znać URL,
- znać go, ale jeszcze go nie crawlowac,
- crawlowac go i zdecydować, że na razie go nie indeksuje,
- uznać inną stronę za canonical,
- zobaczyć
noindex, - zostać zablokowanym przez robots.txt,
- otrzymać redirect albo błąd serwera,
- uznać treść za duplikat lub stronę o zbyt małej wartości względem innych URL.
Dlatego pierwsze pytanie nie powinno brzmieć:
„Jak zmusić Google do indeksacji?”
Tylko:
„Na którym etapie Google zatrzymuje się dla tego URL?”
Najprostsza ścieżka diagnostyczna wygląda tak:
URL Inspection → crawl → indexability → canonical → status GSC → internal links → sitemap → jakość / unikalność strony
Krótka odpowiedź: dlaczego Google nie indeksuje strony?
Najczęstsze przyczyny to:
- Google jeszcze nie odkrył URL,
- URL jest
noindex, - robots.txt blokuje crawling,
- strona zwraca niewłaściwy status HTTP,
- URL przekierowuje,
- canonical wskazuje inną stronę,
- Google wybrał inny canonical,
- strona jest słabo podlinkowana wewnętrznie,
- sitemap nie zawiera właściwego URL,
- treść jest bardzo podobna do innych stron,
- strona ma niewiele własnej wartości,
- Google crawlowal URL, ale go obecnie nie indeksuje,
- Google zna URL, ale jeszcze go nie crawlowal,
- JavaScript lub rendering utrudnia zobaczenie głównej treści,
- witryna generuje zbyt wiele mało wartościowych URL.
Przycisk „Poproś o zindeksowanie” nie naprawia żadnej z tych przyczyn.
Może jedynie poprosić Google o ponowny crawl konkretnego URL.
Najpierw sprawdź, czy strona naprawdę nie jest indeksowana
Najlepszym punktem startowym dla własnej strony jest Google Search Console → URL Inspection.
Wpisz pełny URL.
Search Console pokaże między innymi:
- czy URL jest w indeksie,
- kiedy był crawlowany,
- czy crawl był dozwolony,
- czy indeksacja jest dozwolona,
- jaki canonical zadeklarowała strona,
- jaki canonical wybrał Google.
„URL is on Google” nie oznacza gwarantowanej widoczności na każde zapytanie
Indeksacja i ranking to dwie różne rzeczy.
Strona może być:
- zaindeksowana,
- ale nie rankować na frazę, którą sprawdzasz.
Może też rankować bardzo daleko.
Dlatego problem:
„Nie widzę strony po wpisaniu mojej frazy”
nie zawsze oznacza:
„Google jej nie zaindeksował”.
Najpierw sprawdź status konkretnego URL w GSC.
Indeksacja, crawling i ranking — trzy różne etapy
Crawling
Googlebot odwiedza URL i pobiera jego zawartość.
Indexing
Google analizuje stronę i może dodać ją do indeksu.
Ranking
Google decyduje, czy i gdzie pokazać zaindeksowaną stronę dla konkretnego zapytania.
To ważne, ponieważ można mieć:
- problem z crawlingiem,
- problem z indeksacją,
- albo po prostu problem z rankingiem.
Te trzy sytuacje wymagają innych działań.
1. Google jeszcze nie zna URL
Jeżeli Search Console pokazuje, że URL jest Google nieznany, problem dotyczy discovery.
Google może odkrywać strony między innymi przez:
- internal links,
- sitemap,
- linki z innych stron,
- wcześniejsze crawl serwisu.
Co zrobić?
Sprawdź:
- czy URL znajduje się w sitemapie,
- czy prowadzą do niego normalne linki HTML,
- czy jest osiągalny z kategorii/usługi/blogu,
- czy nie istnieje tylko w formularzu wyszukiwania lub JS.
Dobra strona nie powinna być „wyspą”.
Jeżeli jest ważna, powinna mieć logiczne miejsce w architekturze.
2. noindex blokuje stronę
noindex mówi Google:
nie dodawaj tej strony do indeksu.
Może znajdować się jako:
- meta robots w HTML,
X-Robots-Tagw nagłówku HTTP.
Typowe przypadki
- WordPress miał włączoną opcję zniechęcania wyszukiwarek,
- dev/staging został skopiowany na produkcję,
- plugin SEO ustawił noindex dla typu treści,
- template odziedziczył błędne ustawienie.
Jak sprawdzić?
W URL Inspection:
- zobacz
Indexing allowed?, - wykonaj Live Test,
- sprawdź HTML / nagłówki, jeśli trzeba.
Ważne: robots.txt może uniemożliwić Google zobaczenie noindex
Google musi crawlowac stronę, aby odczytać noindex.
Jeżeli robots.txt całkowicie blokuje URL, crawler może nie zobaczyć dyrektywy.
To dlatego robots.txt i noindex nie są tym samym narzędziem.
3. robots.txt blokuje Googlebot
robots.txt służy głównie do kontrolowania crawlingu.
Nie jest właściwym sposobem na usuwanie zwykłych stron HTML z Google.
Jeżeli ważny URL jest przypadkowo zablokowany, Google może nie móc pobrać jego treści.
Sprawdź szczególnie reguły:
Disallow: /- blokady całych katalogów,
- blokady
/blog/, - blokady
/produkty/, - stare reguły po development,
- blokady parametrów obejmujące normalne URL.
Nie poprawiaj robots.txt „na ślepo”
W dużym sklepie część ograniczeń crawla może być celowa.
Najpierw ustal:
- co jest blokowane,
- dlaczego,
- które URL powinny być indeksowane.
4. Strona nie zwraca 200 OK
URL przeznaczony do indeksacji zazwyczaj powinien zwracać poprawną odpowiedź 200.
Problematyczne sytuacje:
301/308— URL przekierowuje,404— strona nie istnieje,410— strona usunięta,5xx— problem serwera,- timeout,
- błędna pętla przekierowań.
Jeżeli URL ma redirect
Google nie powinien indeksować starego URL jako głównej strony.
Powinien analizować target redirectu.
Dlatego zawsze sprawdzaj docelowy URL, a nie tylko adres, który wpisałeś.
5. Canonical wskazuje inną stronę
Strona może być technicznie indeksowalna, ale deklarować:
<link rel="canonical" href="https://example.com/inny-url/">
Wtedy sygnalizujesz Google:
preferowaną wersją jest inny URL.
Błąd po redesignie
Nowy template może przypadkowo generować ten sam canonical dla wielu podstron.
Na przykład wszystkie usługi wskazują homepage.
Wizualnie strony działają.
Indeksacja — niekoniecznie.
6. Google wybrał inny canonical niż Ty
Canonical jest sygnałem, nie absolutną komendą.
Google może zdecydować, że inna wersja jest bardziej właściwa.
W URL Inspection sprawdź:
- User-declared canonical
- Google-selected canonical
Jeżeli są różne, trzeba ustalić dlaczego.
Najczęstsze konflikty
- bardzo podobna treść,
- różne URL tego samego produktu,
- HTTP/HTTPS,
- www/non-www,
- parametry,
- print version,
- filtry,
- slash/no slash,
- canonical sprzeczny z internal links,
- canonical sprzeczny z sitemapą.
Wzmocnij spójność sygnałów
Jeżeli URL ma być główny:
- używaj go w internal links,
- umieszczaj go w sitemapie,
- ustaw właściwy canonical,
- przekieruj oczywiste duplikaty.
7. Strona jest duplikatem albo niemal duplikatem
Google nie musi indeksować każdej wersji tej samej treści.
Przykład lokalny:
/seo-gdansk//seo-gdynia//seo-sopot/
i każda strona ma ten sam tekst z podmienionym miastem.
Technicznie są to trzy URL.
Dla użytkownika mogą być prawie tą samą stroną.
Dotyczy również e-commerce
- warianty koloru,
- parametry filtrów,
- sortowanie,
- tracking parameters,
- duplikowane kategorie,
- producent + kategoria generujące podobny listing.
Rozwiązaniem nie jest zawsze:
„napisz więcej słów”.
Trzeba ustalić, czy dany URL w ogóle potrzebuje być osobną stroną indeksowaną.
8. Treść ma bardzo mało własnej wartości
Status techniczny może być poprawny:
- crawl allowed,
- indexing allowed,
- 200 OK,
- self-canonical.
A Google nadal może nie indeksować URL.
To szczególnie pasuje do statusu:
Crawled — currently not indexed
Google już odwiedził stronę.
Nie ma więc sensu diagnozować wyłącznie robots.txt.
Sprawdź wtedy:
- czy strona odpowiada na konkretny intent,
- czy nie powiela innego URL,
- czy ma realne informacje,
- czy jest kompletna,
- czy użytkownik miałby powód wybrać ją zamiast podobnych stron,
- czy nie jest wygenerowana automatycznie w setkach wariantów.
Nie chodzi o „minimalną liczbę słów”.
Chodzi o powód istnienia URL.
9. Co oznacza Crawled — currently not indexed?
To jeden z najczęściej źle interpretowanych statusów.
Oznacza:
Google crawlowal stronę, ale obecnie jej nie zaindeksował.
Może ją zaindeksować w przyszłości.
Czego ten status nie oznacza automatycznie?
Nie oznacza:
- kary,
- problemu robots.txt,
- że trzeba naciskać Request Indexing 20 razy.
Google już był na stronie.
Dlatego najpierw analizuj:
- treść,
- podobieństwo do innych URL,
- jakość całego template,
- internal linking,
- renderowanie,
- sens indeksacji.
10. Co oznacza Discovered — currently not indexed?
Ten status oznacza:
Google zna URL, ale jeszcze go nie crawlowal.
To inna sytuacja niż Crawled — currently not indexed.
Sprawdź:
- ile takich URL istnieje,
- czy serwis generuje ogromną liczbę parametrów,
- czy ważne strony są dobrze podlinkowane,
- czy sitemap zawiera tylko właściwe URL,
- czy hosting odpowiada stabilnie,
- czy Google ma powód priorytetyzować te strony.
Przy dużym sklepie problem może wynikać z tego, że system generuje znacznie więcej URL, niż biznes rzeczywiście potrzebuje w Search.
11. Słabe linkowanie wewnętrzne
Strona może istnieć w sitemapie, ale prawie nie być częścią witryny.
Na przykład:
- nie ma jej w kategorii,
- nie linkuje do niej żadna usługa,
- istnieje tylko w XML sitemap,
- jest 8 kliknięć od homepage.
Internal linking pomaga Google zrozumieć:
- relacje,
- hierarchię,
- znaczenie URL.
Dla ważnej strony zapytaj:
- z jakich stron prowadzą do niej linki?
- czy anchor wyjaśnia temat?
- czy użytkownik naturalnie mógłby ją znaleźć?
12. Sitemap zawiera złe URL albo nie zawiera ważnych
Sitemap powinna pomagać w discovery.
Nie jest jednak:
„listą URL, które Google ma obowiązek zaindeksować”.
Google traktuje ją jako wskazówkę.
Dobra sitemap powinna zawierać głównie URL:
200,- canonical,
- indeksowalne,
- wartościowe dla Search.
Typowe problemy
Sitemap zawiera:
- redirecty,
- 404,
- noindex,
- duplicate parameters,
- stare URL,
- dev environment.
To obniża jakość sygnału.
13. Request Indexing nie jest przyciskiem „dodaj do Google”
Google oficjalnie mówi:
request crawling/indexing nie gwarantuje obecności w indeksie.
Narzędzie:
- sprawdza podstawową możliwość indeksacji,
- dodaje URL do kolejki.
Nie klikaj kilkanaście razy
Google wprost informuje, że wielokrotne prośby dla tego samego URL nie przyspieszają crawla.
Dla wielu URL:
- aktualizuj sitemap,
- zapewnij internal links,
- napraw źródło problemu.
Kiedy Request Indexing ma sens?
Na przykład po:
- publikacji ważnej pojedynczej strony,
- usunięciu noindex,
- naprawie błędu,
- istotnej aktualizacji.
Ale nie jako stały sposób indeksowania każdego wpisu.
14. JavaScript ukrywa główną treść
Google potrafi renderować JavaScript.
Ale jeżeli strona:
- zwraca prawie pusty HTML,
- wymaga błędnego JS do pokazania treści,
- request API się nie wykonuje,
- renderer widzi error,
- content pojawia się tylko po interakcji,
może dojść do problemu.
Jak sprawdzić?
W Search Console:
- URL Inspection,
- Test Live URL,
- View Tested Page,
- screenshot / HTML / resources.
Sprawdź, czy Google rzeczywiście widzi:
- H1,
- treść,
- linki,
- produkt,
- cenę.
Ważne szczególnie przy:
- SPA,
- custom JS,
- headless,
- rozbudowanych frontach.
15. Serwer jest niestabilny
Jeżeli Googlebot często otrzymuje:
5xx,- timeout,
- connection reset,
- bardzo wolną odpowiedź,
crawl może być ograniczony.
Użytkownik może widzieć stronę poprawnie w danym momencie, ale Googlebot mógł trafić na awarię kilka godzin wcześniej.
Sprawdź:
- hosting logs,
- uptime,
- odpowiedzi serwera,
- CDN,
- firewall,
- WAF,
- bot protection.
Szczególnie ważne: nie blokuj Googlebota przypadkowo narzędziem security.
16. Nowa domena potrzebuje czasu
Nowa strona nie ma historii crawl.
Nie oznacza to, że trzeba codziennie zgłaszać każdy URL.
Zadbaj o:
- sitemap,
- logiczne linkowanie,
- wartościowe główne strony,
- stabilny serwer,
- Search Console.
Google podaje, że crawling po zgłoszeniu może potrwać od kilku dni do kilku tygodni.
Nie istnieje gwarantowany termin indeksacji.
17. Strona jest zaindeksowana, ale pod innym URL
Przykład:
Ty sprawdzasz: /usluga?ref=menu
Google wybrał: /usluga/
To nie musi być problem.
Problemem jest dopiero sytuacja, gdy Google wybiera niewłaściwą wersję.
Dlatego zawsze sprawdzaj Google-selected canonical w GSC.
18. HTTP i HTTPS, www i non-www
Stare serwisy czasami działają pod wieloma wersjami:
http://example.comhttps://example.comhttps://www.example.comhttp://www.example.com
Powinna istnieć jedna spójna wersja.
Pozostałe powinny prowadzić do niej permanentnym redirectem.
Inaczej:
- linki się rozpraszają,
- canonical może być niespójny,
- crawl trafia na duplikaty.
19. Trailing slash i duplikaty techniczne
Dla serwera:
/oferta/oferta/
mogą być dwoma URL.
Podobnie:
- uppercase/lowercase,
- index.php,
- query parameters.
Jeżeli wszystkie wersje zwracają 200, strona może generować duplicate URLs.
Warto ujednolicić:
- redirect,
- canonical,
- internal links.
20. Parametry i filtry tworzą tysiące stron
Klasyczny problem e-commerce.
Na przykład:
?color=black ?size=m ?sort=price ?brand=x ?page=2
Kombinacje mogą wygenerować ogromną liczbę URL.
Nie wszystkie powinny być indeksowane.
Audyt powinien ustalić:
- które filtry mają search demand,
- które zasługują na landing page,
- które są tylko narzędziem UX,
- jak działa canonical,
- jak działa crawl.
Indeksowanie wszystkiego „bo Google może” nie jest strategią.
21. Produkty niedostępne
Produkt może zniknąć z indeksu, jeśli system:
- usuwa URL,
- zwraca soft 404,
- ustawia noindex,
- przekierowuje wszystko do kategorii.
Nie istnieje jedna zasada dla każdego produktu.
Produkt wróci?
Zachowaj stronę i jasno pokaż stan.
Produkt usunięty na zawsze, ma zamiennik?
Można rozważyć redirect do najbardziej odpowiadającego zamiennika.
Nie ma zamiennika?
404/410 może być poprawne.
Nie przekierowuj każdego starego produktu do homepage.
22. Strony lokalne są prawie identyczne
Przy local SEO łatwo wygenerować:
- usługa Gdańsk,
- usługa Gdynia,
- usługa Tczew,
- usługa Kwidzyn,
z dokładnie tą samą treścią.
To zwiększa liczbę URL, ale niekoniecznie zwiększa wartość.
Strona lokalna powinna mieć realny sens:
- lokalny intent,
- rzeczywistą obsługę obszaru,
- właściwe informacje,
- różnicę względem innych lokalizacji.
23. Tag pages i archiwa WordPress
WordPress może generować:
- tagi,
- autorów,
- daty,
- kategorie,
- media attachments,
- search results.
Nie każda automatycznie wygenerowana strona zasługuje na indeksację.
Audyt powinien zdecydować:
- co jest wartościowym landingiem,
- co pomaga nawigacji,
- co tylko duplikuje posty.
Nie ma zasady:
„wszystkie tagi noindex”
dla każdego projektu.
Decyzja wynika z wartości i architektury.
24. Staging został zaindeksowany zamiast produkcji
Bardzo nieprzyjemna sytuacja.
Nowa wersja działa na: dev.example.com
i Google ją znajduje.
Potem production: example.com
ma podobną treść.
Staging powinien być naprawdę zabezpieczony
Najpewniej:
- authentication / password protection,
- ograniczony dostęp.
Samo noindex jest użyteczne, ale dev środowisko nadal jest publicznie dostępne.
Po launch:
- sprawdź canonical,
- noindex,
- robots,
- sitemap,
- internal links.
25. Content został opublikowany, ale nie ma własnego intentu
Przykład:
Artykuł:
„SEO — wszystko, co musisz wiedzieć”
i pięć innych artykułów:
- czym jest SEO,
- SEO dla firm,
- jak działa SEO,
- podstawy SEO,
- SEO poradnik.
Jeżeli wszystkie odpowiadają prawie na to samo, problemem nie jest indeksacja pojedynczej strony.
Problemem jest architektura contentu.
Zasada FreenetPro:
jeden główny intent = jeden główny URL
Nie trzeba tworzyć nowej strony dla każdej drobnej odmiany frazy.
26. Czy thin content zawsze nie jest indeksowany?
Nie.
Krótka strona może być bardzo wartościowa.
Na przykład:
- kalkulator,
- definicja,
- odpowiedź na konkretny problem,
- strona produktu z jasnymi parametrami.
Problemem nie jest liczba słów.
Problemem jest brak wystarczającej wartości względem celu strony.
Nie wydłużaj tekstu sztucznie tylko dlatego, że URL jest „Crawled — currently not indexed”.
27. Czy duplicate content powoduje karę?
Zwykle problemem nie jest „kara za duplikat”.
Google musi po prostu zdecydować:
- którą wersję pokazać,
- którą uznać za canonical,
- które URL w ogóle warto utrzymywać w indeksie.
Dlatego zamiast bać się „duplicate content penalty”, uporządkuj:
- canonical,
- redirecty,
- internal linking,
- podobne strony.
28. Czy brak backlinków blokuje indeksację?
Nie istnieje wymóg:
„musisz mieć backlink, aby wejść do Google”.
Google może odkryć stronę przez internal links i sitemap.
Ale linki pomagają:
- w discovery,
- w zrozumieniu znaczenia,
- w ocenie strony.
Jeżeli witryna jest całkowicie odizolowana i nie ma wewnętrznych ani zewnętrznych sygnałów, discovery może być wolniejsze.
29. Czy szybkość strony wpływa na indeksację?
Słaby PageSpeed score sam w sobie nie oznacza:
„Google nie zaindeksuje strony”.
Ale ekstremalne problemy techniczne mogą utrudniać:
- crawl,
- rendering,
- stabilność serwera.
Dlatego trzeba rozdzielić:
- typowy performance issue,
- realną awarię crawla/renderowania.
Nie próbuj naprawiać indeksacji, polując na 100/100 PageSpeed, jeśli GSC jasno pokazuje błędny canonical.
30. Jak diagnozować jeden konkretny URL krok po kroku?
Krok 1 — URL Inspection
Sprawdź status indeksacji.
Krok 2 — Live Test
Czy URL jest dostępny teraz?
Krok 3 — HTTP
Czy zwraca 200?
Krok 4 — Crawl allowed?
Czy robots.txt pozwala?
Krok 5 — Indexing allowed?
Czy nie ma noindex?
Krok 6 — Canonical
Czy self-canonical jest poprawny?
Krok 7 — Google-selected canonical
Czy Google wybrał ten sam URL?
Krok 8 — Rendering
Czy główna treść jest widoczna dla Google?
Krok 9 — Internal links
Czy strona jest realnie częścią serwisu?
Krok 10 — Sitemap
Czy znajduje się w odpowiedniej sitemapie?
Krok 11 — Intent i unikalność
Czy URL ma powód istnieć jako osobna strona?
Krok 12 — Request Indexing
Dopiero po naprawie można wysłać request.
31. Jak diagnozować problem całego serwisu?
Jeżeli nie indeksuje się jeden URL — sprawdzasz URL.
Jeżeli problem dotyczy 5 000 URL — szukasz wzorca.
Sprawdź grupy:
- /produkty/,
- /tag/,
- /filter/,
- /blog/,
- konkretne template'y.
W GSC eksportuj przykłady.
Porównaj:
- indexed,
- crawled not indexed,
- discovered not indexed,
- duplicates,
- noindex,
- redirect.
Szukamy przyczyny systemowej
Na przykład:
- jeden template generuje zły canonical,
- wszystkie produkty mają noindex,
- filtry tworzą milion URL,
- serwer blokuje boty,
- system usuwa internal links.
Naprawa template jest lepsza niż ręczne zgłaszanie tysięcy URL.
32. Czy site: jest dobrym testem indeksacji?
Operator site: może być pomocny orientacyjnie, ale przy diagnostyce własnego URL lepiej użyć URL Inspection w Search Console.
GSC pokazuje:
- crawl,
- indexability,
- canonical,
- status konkretnego URL.
To znacznie bardziej użyteczne niż zgadywanie na podstawie pojedynczego wyszukiwania.
33. Jak długo trwa indeksowanie strony?
Google oficjalnie nie daje gwarantowanego czasu.
Po request:
- crawl może nastąpić w kilka dni,
- czasami potrwać kilka tygodni.
W wielu przypadkach nowa wartościowa strona pojawia się szybciej.
Ale nie ma SLA.
Jeżeli po kilku tygodniach nadal brak indeksacji
Nie klikaj tylko ponownie.
Sprawdź:
- status GSC,
- canonical,
- crawl,
- treść,
- internal links,
- sitemap,
- wzorzec w całym serwisie.
34. Czy można „przyspieszyć indeksację”?
Można ułatwić Google pracę.
Nie można jej zagwarantować.
Najlepsze działania:
- poprawna architektura,
- normalne internal links,
- sitemap,
- stabilny hosting,
- wartościowe URL,
- brak sprzecznych sygnałów.
Request Indexing jest dodatkiem.
Nie fundamentem.
35. Czego nie robić?
Nie wysyłaj tego samego URL 20 razy
Nie przyspieszy crawla.
Nie kupuj „indexing service” w ciemno
Najpierw napraw przyczynę.
Nie twórz tysięcy pustych stron
Więcej URL ≠ więcej SEO.
Nie przekierowuj wszystkiego do homepage
Redirect musi mieć logiczny target.
Nie zdejmuj robots/noindex bez zrozumienia architektury
Część URL może być celowo wykluczona.
Nie zmieniaj URL tylko dlatego, że nie jest indeksowany
Nowy slug nie rozwiązuje problemu wartości strony.
Z praktyki FreenetPro: najpierw identyfikujemy etap problemu
Przy problemach indeksacji nie zaczynamy od „sztuczek”.
Najpierw ustalamy:
czy Google zna URL → czy może go crawlowac → czy może go indeksować → jaki canonical wybiera → czy URL ma sens jako osobna strona.
To pozwala bardzo szybko odróżnić:
Problem techniczny
Na przykład:
- noindex,
- robots,
- 5xx,
- zły canonical.
Problem architektury
- brak internal links,
- tysiące parametrów,
- duplicate landing pages.
Problem selekcji do indeksu
- Google crawlowal stronę,
- ale nie uznał jej obecnie za potrzebną w indeksie.
Każda z tych sytuacji wymaga innej odpowiedzi.
Nie naprawiamy indeksacji przyciskiem. Naprawiamy przyczynę, dla której URL nie przechodzi kolejnego etapu.
Checklista: Google nie indeksuje strony
URL
- ☐ URL jest poprawny
- ☐ zwraca 200
- ☐ nie przekierowuje
- ☐ działa na HTTPS
Crawling
- ☐ Google zna URL
- ☐ robots.txt nie blokuje
- ☐ serwer nie blokuje Googlebota
- ☐ nie ma 5xx / timeout
Indexability
- ☐ brak noindex
- ☐ brak X-Robots-Tag noindex
- ☐ canonical jest właściwy
- ☐ Google-selected canonical jest właściwy
Discovery
- ☐ URL ma internal links
- ☐ jest w sitemapie
- ☐ sitemap zawiera canonical URL
- ☐ nie jest orphan page
Content
- ☐ ma własny intent
- ☐ nie jest kopią innej strony
- ☐ wnosi realne informacje
- ☐ nie jest automatycznie wygenerowanym thin URL
- ☐ główna treść jest widoczna po renderowaniu
GSC
- ☐ sprawdzony URL Inspection
- ☐ sprawdzony Live Test
- ☐ sprawdzony Page Indexing report
- ☐ wiadomo, czy status to Crawled / Discovered / Duplicate / Noindex
- ☐ Request Indexing używany dopiero po naprawie
FAQ
Dlaczego Google nie indeksuje mojej strony?
Najczęściej przez noindex, blokadę crawla, błędny canonical, problemy HTTP, słabe discovery, duplikację albo dlatego, że Google crawlowal stronę, ale obecnie nie zdecydował się jej indeksować. Najpierw sprawdź URL Inspection w Search Console.
Jak sprawdzić, czy strona jest zaindeksowana?
Dla własnej witryny użyj Google Search Console → URL Inspection. To narzędzie pokazuje indeksację, crawl, canonical i indexability konkretnego URL.
Co oznacza „Crawled — currently not indexed”?
Google pobrał stronę, ale obecnie nie dodał jej do indeksu. Nie musi to oznaczać błędu technicznego. Warto sprawdzić jakość, unikalność, internal linking, renderowanie i sens istnienia URL.
Co oznacza „Discovered — currently not indexed”?
Google zna URL, ale jeszcze go nie crawlowal. Przy większej liczbie takich stron sprawdź architekturę, sitemapę, internal links, liczbę generowanych URL oraz stabilność serwera.
Czy Request Indexing gwarantuje indeksację?
Nie. Google oficjalnie mówi, że request nie gwarantuje ani natychmiastowego crawla, ani obecności URL w indeksie.
Czy ponowne klikanie Request Indexing przyspiesza Google?
Nie. Google informuje, że wielokrotne requesty dla tego samego URL nie przyspieszają crawla.
Czy sitemap gwarantuje indeksację?
Nie. Sitemap pomaga Google odkrywać nowe i zmienione URL, ale nie jest poleceniem ich zaindeksowania.
Czy robots.txt blokuje indeksowanie?
robots.txt kontroluje crawling. Nie jest właściwym mechanizmem do usuwania normalnej strony HTML z indeksu. Do blokowania indeksacji służy noindex, ale Google musi móc crawlowac URL, aby go odczytać.
Czy noindex działa, jeśli robots.txt blokuje stronę?
Może nie zadziałać tak, jak oczekujesz, ponieważ Google musi pobrać stronę, aby zobaczyć meta noindex lub X-Robots-Tag.
Czy canonical może powodować brak indeksacji?
Tak. Jeśli canonical wskazuje inny URL albo Google wybiera inny canonical, sprawdzany URL może nie być przechowywany jako główna wersja w indeksie.
Czy brak indeksacji oznacza karę Google?
Nie. Najczęściej nie. Brak indeksacji może wynikać z techniki, discovery, canonicalization lub decyzji o niewłączeniu konkretnego URL do indeksu.
Czy mała ilość tekstu blokuje indeksację?
Nie istnieje minimalna liczba słów wymagana do indeksacji. Ważniejsza jest wartość i sens strony. Krótka, konkretna treść może być bardziej użyteczna niż długi tekst powtarzający inne strony.
Jak długo Google indeksuje nową stronę?
Google nie gwarantuje czasu. Crawling po request może potrwać od kilku dni do kilku tygodni. Dla wielu URL najlepiej użyć sitemap i poprawnej architektury.
Czy Google indeksuje JavaScript?
Google może renderować JavaScript, ale błędy renderowania lub content ładowany w sposób niedostępny dla Google mogą powodować problemy. URL Inspection Live Test pozwala sprawdzić renderowaną wersję.
Czy każdy produkt w sklepie powinien być indeksowany?
Nie zawsze. Produkty aktywne i wartościowe zwykle tak, ale filtry, parametry i techniczne warianty nie muszą tworzyć osobnych indeksowanych URL.
Najważniejsza zasada
Nie pytaj:
„Jak zaindeksować URL?”
dopóki nie wiesz:
„Dlaczego ten URL nie jest indeksowany?”
Jeżeli problem to noindex — zdejmujesz noindex.
Jeżeli canonical — poprawiasz canonical.
Jeżeli URL jest orphan — poprawiasz architekturę.
Jeżeli Google już crawlowal stronę — poprawiasz powód, dla którego warto przechowywać ją w indeksie.
A dopiero potem prosisz Google o ponowny crawl.
