Crawlowanie i indeksowanie 2026 - przewodnik dla początkujących

Crawlowanie i indeksowanie to dwa pierwsze etapy, przez które musi przejść każda strona, zanim zacznie się jej pozycjonowanie. Jeśli Googlebot jej nie odwiedzi albo indexer jej nie zaakceptuje, nic się nie wydarzy – niezależnie od tego, jak dobra jest treść i jak mocne są linki.

Ten artykuł tłumaczy mechanikę obu procesów po ludzku, pokazuje realne błędy i ich naprawę, oraz daje listę kontrolną, od której zacząć w pierwszym tygodniu. Osadzamy wszystko w kontekście przewodnika po SEO podstawy, który łączy te tematy z całością strategii.

W skrócie

Crawlowanie – Googlebot odwiedza Waszą stronę. Indeksowanie – strona trafia do bazy.
Crawl budget to limit żądań Googlebota na domenę; determinują go autorytet i szybkość serwera.
80% problemów początkujących to nie sitemapa, tylko jakość treści („crawled – not indexed”).
Pięć najważniejszych narzędzi: Search Console, Bing Webmaster Tools, sitemap XML, robots.txt, URL Inspection.
Dla nowej domeny pierwsza indeksacja trwa 7-30 dni, dla istniejącej 3-7 dni.

Czym różni się crawlowanie od indeksowania

Crawlowanie to odwiedziny robota na URL-u. Indeksowanie to zapisanie strony w bazie Google. Można być zaindeksowanym bez świeżego crawla i można być scrawlowanym bez zaindeksowania. Rozróżnienie jest kluczowe dla diagnozy problemów.

Przykład: opublikujecie artykuł w poniedziałek. Googlebot przychodzi we wtorek (crawl #1). W środę strona jest „Crawled – not indexed” – to znaczy, że Google ją odwiedził, ale nie dodał do indeksu. W piątek (po rozbudowie treści) nowy crawl i strona trafia do indeksu. Cały proces to 5 dni, a nie jeden krok.

W Search Console obserwujecie oba etapy osobno. Raport „Statystyki indeksowania” pokazuje crawlowanie (liczba żądań, czasy odpowiedzi). Raport „Indeksowanie stron” pokazuje wynik – co zostało dodane, co odrzucone.

Jak Googlebot odkrywa nowe strony

Googlebot nie skanuje internetu chaotycznie. Ma listę URL-i do odwiedzenia i priorytetyzuje ją. Sposobów, w jakie URL trafia na listę, jest kilka:

Sitemap XML – najpewniejszy sposób. Plik /sitemap.xml zgłoszony w Search Console lub w robots.txt.
Linki wewnętrzne – z innej strony tej samej domeny, która już jest znana Googlowi.
Linki zewnętrzne – backlink z innej domeny. To najsilniejszy sygnał „ta strona istnieje i jest ważna”.
URL Inspection Tool – ręczne zgłoszenie w Search Console. Limit ~10 dziennie.
IndexNow – API protokół, wspiera go Bing i niektóre inne wyszukiwarki (Google oficjalnie nie, ale sygnał się rozprowadza).
RSS / Atom – kanały automatycznie pingują wyszukiwarki.

W praktyce: zawsze macie poprawną sitemapę, zawsze linkujecie wewnętrznie ze strony głównej / kategorii do nowych artykułów, a dla kluczowych stron robicie ręczne URL Inspection.

Crawl budget – ile żądań dziennie dostajecie

Crawl budget to ograniczenie, ile żądań Googlebot zrobi na Waszej domenie w jednostce czasu. Nie jest to sztywny limit – zmienia się w zależności od wielu czynników:

Szybkość serwera (czas odpowiedzi < 200ms = więcej żądań).
Autorytet domeny (DR / DA w narzędziach SEO).
Liczba zindeksowanych stron (im większa, tym większy budget).
Częstotliwość publikacji (aktywne strony są odwiedzane częściej).
Udział błędów 4xx i 5xx (spadek o 30-70% przy dużej liczbie błędów).

Typowe budżety w 2026:

Rozmiar strony	Crawl budget / dzień
Nowy blog (1-50 URL)	10-50 żądań
Mały blog (50-500 URL)	50-500 żądań
Średni portal (500-5000 URL)	500-5000 żądań
Duży portal (5000-50000 URL)	5000-50000 żądań
Duży sklep (10000+ produktów)	10000-100000 żądań

Sprawdzicie to w Search Console > Ustawienia > Statystyki indeksowania. Wykres „Łączna liczba żądań” pokazuje trendy przez 90 dni.

Optymalizacja crawl budgetu – cztery największe dźwignie

Szybki serwer. LiteSpeed, NGINX z cache, Cloudflare, HTTP/3. Każde 100ms mniej to kilkanaście procent więcej crawla.
Wyeliminowanie pożeraczy budgetu. Tagi bez wartości (noindex + follow), filtry sklepu (parametry URL w Search Console > Parameter Handling), paginacja bez realnej treści.
Czysta sitemapa. Tylko zindeksowalne strony, bez 404, 301 i duplikatów. Regenerowana przy każdej publikacji.
Usuwanie martwych URL. Strony z 410 Gone są szybciej usuwane z indeksu niż z 404. Dla trwale usuniętych: 410.

Kontekst szerszych optymalizacji technicznych – Core Web Vitals, schema, infrastruktura hostingu – znajdziecie w tekście techniczne SEO – lista kontrolna.

Sitemapa XML – jak zrobić ją poprawnie

Sitemapa XML to lista URL-i, które chcecie, żeby Google odwiedził i zindeksował. W WordPressie generuje ją automatycznie RankMath, Yoast, AIOSEO lub SEOPress. W innych CMS-ach często potrzebujecie pluginu albo ręcznego generatora.

Wymagania Google dla sitemapy:

Maksymalnie 50 000 URL w jednym pliku.
Maksymalnie 50 MB nieskompresowany.
UTF-8, bez BOM.
URL bezwzględne, z domeną (np. https://example.com/post/).
Tylko URL, które mają wrócić status 200 i są indeksowalne.

Dla większych stron używacie sitemapy indeksowej (sitemap_index.xml), która wskazuje na kilka sitemap dzielonych tematycznie: post-sitemap.xml, product-sitemap.xml, category-sitemap.xml.

Lastmod – tag, który warto mieć

Tag <lastmod> mówi Google, kiedy strona była ostatnio zmieniona. To pomaga Googlebotowi priorytetyzować świeże strony. Dla WordPressa większość pluginów SEO aktualizuje ten tag automatycznie przy edycji posta.

Uwaga: lastmod ma być prawdziwy. Jeśli zmieniacie datę na „dzisiaj” bez realnej zmiany treści – Google to wykrywa i ignoruje tag na danej domenie.

Robots.txt – co naprawdę robi i czego nie robi

Plik robots.txt to instrukcja dla crawlerów: co mogą odwiedzać, czego nie. Żyje w /robots.txt w korzeniu domeny i jest pierwszym plikiem, który Googlebot sprawdza.

Co robi robots.txt:

Blokuje crawlowanie konkretnych ścieżek (np. /wp-admin/).
Wskazuje lokalizację sitemapy.
Kontroluje częstotliwość crawla (choć Google ignoruje Crawl-delay).

Czego robots.txt NIE robi:

Nie blokuje indeksacji (do tego służy noindex).
Nie zabezpiecza poufnych danych (plik jest publiczny).
Nie usuwa stron z indeksu (trzeba noindex albo 410).

Typowy robots.txt dla WordPressa:

User-agent: * Disallow: /wp-admin/ Allow: /wp-admin/admin-ajax.php Sitemap: https://example.com/sitemap_index.xml

Najczęstsze błędy robots.txt, które blokują całą stronę

Obserwujemy je niemal w każdym audycie:

Disallow: / – blokuje całą stronę (typowy błąd po migracji z dev na prod).
Disallow ścieżki z treścią (Disallow: /blog/) – zablokuje Wam cały blog.
Brak sitemapy w robots.txt.
Robots.txt zwracający 404 – Google zakłada „brak ograniczeń”, ale marnuje żądanie.
Sprzeczne reguły (Allow i Disallow dla tej samej ścieżki).

Noindex – jak wykluczyć stronę z indeksu

Tag <meta name="robots" content="noindex, follow"> mówi Google: nie indeksuj tej strony, ale podążaj za linkami z niej. To najczęściej używana dyrektywa dla stron, które nie mają wartości SEO, ale zachowują PageRank dla innych stron (tagi, paginacja, wewnętrzne wyszukiwarki).

Dwa sposoby ustawienia noindex:

Meta tag w <head> – dla pojedynczych stron w CMS-ie.
Nagłówek HTTP X-Robots-Tag: noindex – dla plików (PDF, obrazki) lub dla grup URL.

Noindex działa dopiero, kiedy Googlebot odwiedzi stronę i zobaczy tag. Jeśli strona jest zablokowana w robots.txt, Google nie zobaczy noindex i może ją dalej trzymać w indeksie (częsty błąd). Zasada: żeby usunąć ze indeksu = odblokujcie w robots.txt + dodajcie noindex.

URL Inspection Tool – Wasze najważniejsze narzędzie

URL Inspection to funkcja w Search Console, która pokazuje dokładny status konkretnego URL w Google:

Czy jest zindeksowany.
Kiedy był ostatnio crawlowany.
Jakie ma rendered HTML (co widzi Googlebot).
Screenshot strony z punktu widzenia robota.
Wykryte strukturyzowane dane.
Ewentualne problemy indeksacji.

Codzienne użycie: publikujecie artykuł, wklejacie URL w Search Console, klikacie „Poproś o zaindeksowanie”. Google dodaje URL do priorytetowej kolejki i zwykle indeksuje w 1-6 godzin (nowa domena 1-3 dni).

Limit: ~10 URL-i dziennie na property. Dla większych publikacji użyjcie sitemapy z lastmod.

Pięć najczęstszych problemów indeksacji i ich naprawa

Problem 1 – Crawled, currently not indexed. Google odwiedził, ale uznał treść za za słabą. Naprawa: rozbudowa do 2000+ słów, dodanie autora, schema, wewnętrznych linków z rankingujących stron.

Problem 2 – Discovered, currently not indexed. Google wie o URL, ale nie odwiedził. Naprawa: dodanie linków wewnętrznych, zgłoszenie w URL Inspection, sprawdzenie crawl budgetu.

Problem 3 – Duplicate without user-selected canonical. Treść duplikuje inne strony. Naprawa: ustawienie canonical, scal duplikujące się strony w jedną silniejszą.

Problem 4 – Excluded by noindex tag. Niechciane noindex (często po migracji lub przez plugin). Naprawa: sprawdźcie meta robots, usuńcie noindex.

Problem 5 – Page with redirect. URL przekierowuje, więc Google indeksuje cel, nie ten URL. To nie jest błąd, jeśli to zamierzone.

Indeksacja obrazów i wideo – osobny świat

Googlebot-Image crawluje obrazki osobno od zwykłego Googlebota. W 2026 obrazki w Google Images to źródło 5-15% ruchu dla e-commerce i portali lifestyle.

Wymogi dla indeksacji obrazów:

Obraz dostępny pod URL (nie ukryty za autoryzacją).
Format: WebP, JPEG, PNG, AVIF, SVG.
Rozsądny rozmiar (do 300 KB dla zdjęć, do 50 KB dla ikon).
Atrybut alt opisujący zawartość (nie keyword stuffing).
Lazy loading nie przeszkadza – Google sobie radzi.
Schema ImageObject z contentUrl i license dla obrazów chronionych.

Dla wideo podobna logika, ale z dodatkową sitemapą sitemap-video.xml i schemą VideoObject.

Indeksacja stron sklepów e-commerce

Sklepy mają specyfikę: strony kategorii z setkami produktów, filtry generujące tysiące URL-i z parametrami, paginacja, wersje językowe. Bez kontroli łatwo o 500 000 stron, z czego Google zindeksuje 20 000 słabej jakości.

Standardowa strategia indeksacyjna dla e-commerce:

Kategorie główne – pełna indeksacja.
Podkategorie – pełna indeksacja.
Produkty – pełna indeksacja.
Strony filtrów z niską wartością (np. rozmiar S) – noindex.
Strony filtrów z wysoką wartością (np. kategoria + marka) – indeksacja, jeśli są wystarczająco unikalne.
Paginacja – noindex, follow (lub canonical na stronę 1).
Wyszukiwarka wewnętrzna – noindex, zwykle też blokada crawla.

Jeśli prowadzicie sklep, głębiej omawiamy to w przewodniku SEO dla e-commerce.

Kiedy strona znika z Google – diagnoza

Nagłe zniknięcie dużej liczby stron z indeksu zwykle oznacza jedną z pięciu sytuacji:

Manualna akcja Google – wiadomość w Search Console. Reakcja: analiza, naprawa, reconsideration request.
Core update – dewaluacja jakościowa. Reakcja: poczekać 14 dni, potem analiza.
Błąd techniczny – noindex wdrożony masowo, robots.txt z Disallow: /.
Hack / spam – strona została zhackowana, Google usunął masowo.
Migracja bez 301 – URL-e się zmieniły, stare są 404 i wypadają z indeksu.

Diagnoza zaczyna się od Search Console: raport „Ręczne działania”, raport „Indeksowanie stron”, statystyki crawlowania. Porównujecie datę spadku z datami wdrożeń, core updates, zmian technicznych.

Narzędzia do monitoringu indeksacji

Narzędzie	Co robi	Koszt
Search Console	Pełny obraz indeksacji z punktu widzenia Google	0 zł
Bing Webmaster Tools	To samo dla Binga + ChatGPT Search	0 zł
Screaming Frog	Lokalny crawl, walidacja sitemapy	0 zł do 500 URL
Sitebulb	Desktopowy crawler z wizualizacjami	$13/mc
JetOctopus / OnCrawl	Log analyzer + crawler (enterprise)	od $150/mc
Google Search Operator `site:`	Szybkie sprawdzenie, ile stron Google indeksuje	0 zł

Mapa wdrożenia – pierwsze 30 dni

Konkretny plan dla osoby, która nigdy nie dotykała crawlowania i indeksowania:

Tydzień 1:

Zweryfikujcie Search Console i Bing Webmaster Tools.
Sprawdźcie sitemapę XML – istnieje? Działa? Zawiera wszystkie ważne URL?
Sprawdźcie robots.txt – nie blokuje nic ważnego?
Przejrzyjcie raport „Indeksowanie stron” w GSC.

Tydzień 2:

Wylistujcie wszystkie „Excluded” z GSC i sklasyfikujcie według powodu.
Dla „Crawled not indexed” – lista stron do rozbudowy treści.
Dla „Duplicate” – ustawcie canonical albo scal strony.
Dla „noindex” – zweryfikujcie, czy to zamierzone.

Tydzień 3-4:

Naprawcie top 10 najważniejszych problemów indeksacji.
Zgłoście naprawy w URL Inspection.
Monitorujcie statystyki indeksowania – czy crawl budget rośnie.
Rozpocznijcie systematyczne publikowanie nowych treści, by utrzymać crawl demand.

Log analysis – zobaczcie, co Googlebot naprawdę robi

Log serwera to najbardziej wiarygodne źródło danych o crawlowaniu. Pokazuje każde żądanie Googlebota – z dokładnym URL, statusem, rozmiarem, czasem. Narzędzia do analizy: Screaming Frog Log File Analyser, Semrush Log File Analyzer, OnCrawl.

Co odkrywa analiza logów w praktyce:

Googlebot nie odwiedza stron kategorii – bo głębokość kliknięć do nich jest zbyt duża (trzeba sitewide linków).
60% crawl budgetu idzie na filtry sklepu – należy je oznaczyć noindex + dodać parametr w GSC.
Googlebot napotyka łańcuchy 301 – każdy 301 to marnotrawstwo, dążymy do bezpośredniego 200.
Stare archiwa (2017, 2018) mają 3x więcej crawla niż nowe 2026 – brakuje świeżego linkowania wewnętrznego.
AdsBot odwiedza strony lądowania z Google Ads – jego crawl nie wlicza się do budżetu Googlebota.

Log analysis to technika zaawansowana, ale raz zrobiona w roku pokazuje konkretne wąskie gardła. W przypadku dużych sklepów może dać +30% więcej zindeksowanych stron w 60 dni.

Orphan pages – strony bez wewnętrznych linków

Orphan page to strona, do której nie prowadzi żaden link wewnętrzny. Jest w sitemapie, ale nie jest dostępna z menu, homepage ani innych artykułów. Googlebot nie ma się jak tam dostać, a nawet jeśli dotrze przez sitemapę – traktuje ją jako mniej istotną.

Typowe orphan pages: stare artykuły bez widocznej kategorii, landing pages z kampanii Ads, strony z promocji okresowych, archiwalne case studies. Znajdziecie je przez Screaming Frog (porównanie crawla z sitemapą).

Naprawa: dodanie linków wewnętrznych z 3-5 rankingujących artykułów oraz z menu głównego lub stopki. Czas efektu: 14-30 dni.

Soft 404 – fałszywe strony z treścią

Soft 404 to strona, która zwraca status 200, ale treściowo jest pusta lub prawie pusta („Nie znaleziono produktu”). Google klasyfikuje je jako de facto 404 i nie indeksuje. Raport „Strona z przekierowaniem” w GSC pokazuje soft 404.

Jak zidentyfikować i naprawić:

Strony wyszukiwania z pustym wynikiem – zwróćcie 404 albo noindex.
Puste karty produktów po usunięciu – 301 na kategorię.
Strony kategorii bez produktów – noindex, dopóki nie ma produktów.
„Ta strona wymaga logowania” bez treści – noindex.

Indexing API – alternatywa dla URL Inspection

Google oferuje Indexing API, ale oficjalnie tylko dla dwóch typów treści: ogłoszeń pracy (JobPosting) i transmisji na żywo (BroadcastEvent). Praktycznie jednak wiele witryn używa go do wszystkiego – Google rzadko blokuje.

Zalety Indexing API:

Natychmiastowe zgłaszanie (nie trzeba czekać na crawl sitemapy).
Brak limitu dziennego (w przeciwieństwie do URL Inspection).
Możliwość masowego zgłaszania po publikacji batch’a.

Implementacja wymaga konta Google Cloud, service account i prostego skryptu (Python / Node). Dla blogów z 2-3 publikacjami tygodniowo nie warto. Dla dużych portali z 50+ publikacjami dziennie – konieczność.

Wielojęzyczność a indeksacja – pułapki hreflang

Strona wielojęzyczna musi sygnalizować Google, która wersja jest dla którego języka/kraju. Tag hreflang to najczęstszy sposób. Błędy w hreflang to drugi powód zgubionej indeksacji dla międzynarodowych serwisów.

Najczęstsze błędy hreflang:

Asymetria – strona A linkuje do B, B nie linkuje do A. Google ignoruje całą grupę.
Zły kod języka – „en-uk” zamiast „en-GB” (ISO 3166-1).
Brak self-reference – strona nie linkuje sama do siebie.
Hreflang do noindex – wersja docelowa ma noindex, całość się rozpada.
Brak x-default – nie wskazuje domyślnej wersji.

Weryfikacja: narzędzie „Międzynarodowe targetowanie” w Search Console pokazuje błędy hreflang. Dla sklepów multi-country sprawdzajcie co miesiąc.

Indeksacja stron z autoryzacją (intranet, ekstranet)

Strony za login wall Google nie widzi i nie indeksuje. To normalne. Ale są przypadki pośrednie:

Paywall (np. portale newsowe) – Google oferuje Flexible Sampling, pozwala na 3-5 darmowych artykułów dziennie + oznaczenie schemą.
Membership content – trzeba zdecydować: publiczny fragment + CTA „czytaj więcej po zalogowaniu” albo pełne noindex.
Treści A/B testowane – kanoniczne na wersję główną, test wariantów z noindex.

Crawl patterns dla różnych typów stron

Googlebot nie crawluje wszystkich stron tak samo. Ma różne wzorce zachowania w zależności od typu serwisu. Poznanie tych wzorców pozwala przewidzieć, gdzie pojawią się problemy.

Blog z regularnymi publikacjami. Homepage crawlowana codziennie, kategorie 2-3x w tygodniu, indywidualne artykuły 1x na 7-14 dni, stare posty (2+ lata) 1x na 30-60 dni. Strona O nas i Kontakt – 1x miesięcznie.

Sklep e-commerce. Homepage 2-4x dziennie, kategorie główne codziennie, karty produktów 1-3x tygodniowo (top sellery częściej), paginacja rzadko. Produkty z niskim stockiem mogą wypaść z priorytetu.

Portal newsowy. Homepage co 5-15 minut, sekcje co godzinę, artykuły w pierwszej dobie po publikacji co 1-2 godziny, starsze 1x dziennie.

Strona usługowa B2B. Homepage 2-3x tygodniowo, strony usług i case studies 1x tygodniowo, blog 1x na 7-14 dni, formularze kontaktowe 1x miesiąc.

Jeśli Wasz wzorzec odbiega od typowego, warto to zbadać. Nagły spadek crawla o 60% to zwykle sygnał problemu (blok, 5xx, nadmierny thin content). Gwałtowny wzrost – zwykle dobry znak (Google docenia aktywność i jakość).

Jak zwiększyć priorytet crawla dla kluczowych stron

Nie każda strona zasługuje na takie same zasoby crawla. Strony, które konwertują, powinny być crawlowane częściej niż stare posty bez ruchu. Cztery techniki, które przesuwają priorytet:

Wewnętrzne linki z homepage i top kategorii. Bezpośrednio przekłada się na crawl frequency.
Aktualny lastmod w sitemapie. Pokazuje, że strona jest żywa.
Zewnętrzne linki. Nowe backlinki z autorytatywnych domen przyciągają Googlebota.
Regularne edycje treści. Nie „zmiana daty” – realne uzupełnienia, które Google weryfikuje.

Wielokrotne renderowanie – druga fala Googlebota

W 2026 Google renderuje JavaScript w dwóch falach. Pierwsza fala – Googlebot pobiera surowy HTML i od razu go indeksuje (jeśli zawiera treść). Druga fala – Web Rendering Service uruchamia headless Chromium, wykonuje JS, rerenderuje i uaktualnia indeks.

Opóźnienie między falami: od kilku minut do kilku tygodni. Dla SPA bez SSR treść pojawia się w indeksie dopiero po drugiej fali – oznacza to 2-4x wolniejszą indeksację niż dla statycznej strony.

Rozwiązania:

Server-Side Rendering (SSR) – Next.js z getServerSideProps, Nuxt, SvelteKit.
Static Site Generation (SSG) – generacja HTML w czasie buildu.
Dynamic rendering (deprecated przez Google, ale nadal używane) – inny HTML dla botów.
Hydration – statyczny HTML plus wzbogacenie JS po stronie klienta.

Canonical tag – szczegóły, których wszyscy nie znają

Tag rel="canonical" to sygnał, który mówi Google: „to jest wersja wzorcowa tej strony”. Dla Google jest to wskazówka, nie bezwzględny rozkaz – w praktyce zwykle jest respektowana, ale nie zawsze.

Poprawne scenariusze canonical:

Self-canonical – każda strona wskazuje sama na siebie (bez query params).
Canonical do produktu głównego – warianty (rozmiar, kolor) wskazują na produkt bazowy.
Canonical do pierwszej strony paginacji – strona 2, 3, 4 wskazuje na 1 (ostrożnie – czasem lepiej noindex).
Canonical do strony kanonicznej w cross-domain – syndykacja treści (identyczny artykuł na dwóch domenach).

Niepoprawne scenariusze (często widywane):

Canonical na homepage dla wszystkich stron – Google zignoruje.
Canonical do 404.
Sprzeczne canonicals w HTML i w HTTP header.
Canonical do strony z noindex.
Canonical łańcuchowy (A -> B -> C).

Duplicate content – kiedy naprawdę jest problemem

Duplicate content to treść, która pojawia się pod więcej niż jednym URL. W 99% przypadków Google nie karze za duplikaty – po prostu wybiera jedną wersję i ignoruje pozostałe. Problem zaczyna się, gdy:

Google wybiera niewłaściwą wersję jako kanoniczną (np. wariant zamiast produktu głównego).
Wewnętrzna duplikacja rozprasza link equity – 10 wersji strony dostaje linki, zamiast jedna mocna.
Treść powiela się z zewnątrz (opisy producenta w sklepie) – Google woli oryginał.

Naprawa: canonical, scalenie stron, hreflang (dla różnych wersji językowych), noindex na duplikatach, które nie niosą wartości SEO.

FAQ – crawlowanie i indeksowanie

Dlaczego moja sitemapa pokazuje 200 URL, a Google indeksuje tylko 80?

Sitemapa mówi Google, co chcecie indeksować. Google sam decyduje, co faktycznie zaindeksuje. Jeśli 120 URL jest „Excluded”, w raporcie „Indeksowanie stron” zobaczycie podział na przyczyny. Najczęściej: thin content, duplikaty, canonical wskazujący na inną stronę. Sama obecność w sitemapie nie gwarantuje indeksacji – to wskazówka, nie rozkaz.

Ile czasu zajmuje zaindeksowanie nowego artykułu?

Dla istniejącej domeny z autorytetem: 3-24 godziny (po zgłoszeniu w URL Inspection) lub 3-7 dni (bez zgłoszenia, przez sitemapę). Dla nowej domeny: 7-30 dni na pierwszą indeksację, potem proces przyspiesza. Dla domen z historią kary: nawet 60-90 dni. Jeśli artykuł nie jest zaindeksowany po 14 dniach, sprawdźcie status w URL Inspection – tam jest dokładny powód.

Czy muszę mieć sitemapę XML?

Technicznie nie – Google radzi sobie z linkami. Ale praktycznie: tak, zawsze. Sitemapa przyspiesza indeksację nowych stron o 2-4x, szczególnie dla stron z ubogim linkowaniem wewnętrznym. Dla sklepów z 1000+ produktów sitemapa jest praktycznie niezbędna – bez niej Google może nigdy nie dojść do stron leżących 4+ kliknięcia od homepage.

Co zrobić, kiedy tysiące stron jest w „Crawled, currently not indexed”?

To typowy problem dużych serwisów z thin contentem. Rozwiązań kilka: (1) masowe rozbudowanie treści (pracochłonne), (2) scalenie podobnych stron w silniejsze (efektywne), (3) przejście na noindex dla stron bez szans (oczyszcza raport i podnosi crawl budget dla reszty), (4) audyt tematyczny – może cały dział nie jest użyteczny. Nie próbujcie „naprawiać” masowo techniką – to jakościowy problem.

Czy Google Search Console indeksuje szybciej po zgłoszeniu?

Tak, ale nie gwarantuje indeksacji. URL Inspection „Poproś o indeksowanie” dodaje URL do priorytetowej kolejki. Dla dobrych stron to 1-6 godzin na crawl, dla słabych – Google i tak może odmówić indeksacji. Limit to ~10 URL dziennie na property. Nadużywanie (zgłaszanie tego samego URL 5 razy) nie przyspiesza – Google traktuje to jako szum.

Co to jest crawl rate limit i jak go zmienić?

Crawl rate limit to maksymalna liczba jednoczesnych żądań Googlebota na Waszej domenie. Google dostosowuje go automatycznie do czasu odpowiedzi serwera. Szybki serwer = wyższy limit. W 2023 Google wycofał możliwość ręcznego ustawienia (było w Search Console). Dzisiaj jedyny sposób to: szybszy hosting, Cloudflare, brak 5xx, prawidłowe nagłówki. Nie ma „przycisku” do zwiększenia.

Dlaczego Bing indeksuje moje strony szybciej niż Google?

Bing ma bardziej agresywny crawling – szczególnie dla małych domen. Dodatkowo Bing wspiera protokół IndexNow, który pinguje wyszukiwarkę natychmiast po publikacji. Google nie wspiera IndexNow. W praktyce: Bing indeksuje nowe treści średnio 2-5x szybciej. Wniosek: nie porównujcie Google z Bingiem pod kątem szybkości – to różne systemy. Ruch z Binga bywa 10-20% ruchu z Google, ale dzięki ChatGPT Search jego wartość strategiczna rośnie.

Jak usunąć stronę z Google raz na zawsze?

Dwa kroki: (1) ustawcie noindex lub zwróćcie 410 Gone, (2) w Search Console > Usuwanie > Nowa prośba o usunięcie wklejcie URL. Usunięcie z SERP to 6 miesięcy – potem trzeba ponowić. Dla trwałego usunięcia stosujcie 410 i zostawcie w robots.txt dostęp dla Googlebota, żeby mógł zobaczyć status. Usunięcie z robots.txt nie usuwa z indeksu – odwrotnie, może utrzymać URL w indeksie bez treści.

Co dalej

Jeśli rozumiecie już crawlowanie i indeksowanie, warto iść krok dalej w kierunku technicznej listy kontrolnej, która zawiera Core Web Vitals, schema, infrastrukturę hostingu. Zrozumienie, jak działa cała wyszukiwarka Google, uzupełni wątki o AI Overviews i algorytmy. Cały kontekst SEO z 2026 łączy pillar SEO podstawy, do którego warto wracać po każdym szczegółowym artykule.