Co to jest crawling i jak roboty wyszukiwarek skanują stronę?

Crawling to proces automatycznego odwiedzania stron internetowych przez roboty, nazywane crawlerami, botami albo spiderami. Robot zaczyna od znanych mu adresów, pobiera znajdujące się pod nimi dokumenty, analizuje linki i dzięki nim odkrywa kolejne URL-e. W przypadku Google jednym z najważniejszych crawlerów związanych z wyszukiwarką jest Googlebot. Zanim strona może zostać przeanalizowana i znaleźć się w indeksie, wyszukiwarka musi najpierw wiedzieć, że jej adres istnieje i mieć możliwość jego odwiedzenia.

Crawling jest jednym z fundamentów SEO technicznego. Nie oznacza jednak tego samego co indeksowanie. Robot może odwiedzić stronę, ale wyszukiwarka nie musi jej zaindeksować. Może również znać adres, którego nie może pobrać. W większych serwisach dochodzi jeszcze jeden problem: crawler może zużywać dużą część zasobów na filtry, parametry, wyszukiwarki wewnętrzne i duplikaty zamiast docierać do produktów, kategorii i treści, na których naprawdę zależy firmie.

Co to jest crawling?

Crawling można najprościej opisać jako automatyczne skanowanie internetu. Crawler otrzymuje adres URL. Wysyła żądanie do serwera. Serwer odpowiada. Robot pobiera dokument, analizuje jego zawartość i znajdujące się w nim odnośniki. Część odkrytych URL może następnie trafić do kolejki kolejnych adresów do odwiedzenia. W ten sposób robot przechodzi: strona główna → kategoria → produkt → kolejna podstrona. Albo: artykuł → powiązane hasło → usługa. Nie oznacza to, że każdy odkryty URL zostanie natychmiast odwiedzony. Crawler musi zdecydować między innymi:

• które adresy warto pobrać,
• jak często do nich wracać,
• czy strona się zmieniła,
• czy dostęp nie został ograniczony,
• ile zasobów można przeznaczyć na konkretny serwis,
• czy serwer jest w stanie obsługiwać kolejne żądania.

Crawling jest więc przede wszystkim procesem odkrywania i pobierania. Nie jest jeszcze decyzją o tym, czy dokument powinien pojawić się w wynikach wyszukiwania.

Czym crawler różni się od użytkownika?

Użytkownik zwykle trafia na stronę z Google, reklamy, wiadomości, social media albo wpisując adres bezpośrednio. Crawler porusza się automatycznie. Analizuje przede wszystkim:

• adresy URL,
• linki,
• HTML,
• statusy HTTP,
• przekierowania,
• metadane,
• instrukcje robots,
• zasoby potrzebne do wyrenderowania strony.

Nowoczesne roboty wyszukiwarek potrafią również wykonywać JavaScript. Nie oznacza to jednak, że podstawową treść i linkowanie warto bez potrzeby uzależniać od skomplikowanego kodu wykonywanego dopiero w przeglądarce. Im prostsza droga do informacji, tym mniej rzeczy może po drodze przestać działać.

Co to jest Googlebot?

Googlebot to crawler wykorzystywany przez Google do odkrywania i pobierania stron. Nie jest jednym człowiekiem ani jednym komputerem odwiedzającym cały internet. To część rozproszonej infrastruktury wykonującej ogromną liczbę żądań do serwerów. Googlebot może odwiedzać znane strony ponownie, aby sprawdzić, czy ich zawartość się zmieniła. Może również odkrywać nowe adresy. To, że Googlebot odwiedził stronę, nie oznacza jednak automatycznie, że zostanie ona zaindeksowana. To dopiero kolejny etap procesu.

Jak crawler odkrywa nowe strony?

Jednym z podstawowych mechanizmów są linki. Jeżeli crawler znajduje na stronie odnośnik prowadzący do: /nowa-usluga/ może odkryć istnienie tego adresu i dodać go do kolejki. Właśnie dlatego linkowanie wewnętrzne ma znaczenie nie tylko dla użytkownika. Tworzy również ścieżki, którymi robot może poruszać się po serwisie. Drugim ważnym mechanizmem są mapy XML. Sitemap może poinformować wyszukiwarkę: „te adresy istnieją i są dla mnie ważne”. Nie powinna jednak zastępować prawidłowej architektury strony. Jeżeli istotny produkt znajduje się wyłącznie w sitemapie, ale nie prowadzi do niego żaden zwykły link, warto zapytać, dlaczego użytkownik i crawler mieliby traktować go jako ważną część serwisu.

Crawling a indeksowanie – jaka jest różnica?

To jedno z najczęściej mylonych pojęć w SEO. Crawling oznacza: robot pobrał dokument. Indeksowanie oznacza: wyszukiwarka przeanalizowała dokument i zdecydowała, czy oraz w jaki sposób uwzględnić go w swoim indeksie. Możliwa jest więc sytuacja: Google zna adres. Googlebot go odwiedził. Strona nadal nie znajduje się w indeksie. Powodem może być między innymi:

• dyrektywa noindex,
• duplikacja,
• inny wybrany canonical,
• bardzo mała wartość treści,
• przekierowanie,
• błąd serwera,
• problem z interpretacją dokumentu.

Dlatego zdanie: „Google widzi stronę” jest zbyt mało precyzyjne. Trzeba ustalić: czy zna URL? czy go crawluje? czy pobiera poprawną odpowiedź? czy go indeksuje?

Crawling a robots.txt

Robots.txt jest jednym z podstawowych sposobów zarządzania dostępem crawlerów do określonych części serwisu. Plik może informować robota: nie odwiedzaj tego katalogu. Nie pobieraj adresów pasujących do określonego wzorca. Nie crawluj technicznej części strony. Ma to szczególne znaczenie przy dużych serwisach, gdzie system generuje ogromną liczbę URL, których wyszukiwarka nie potrzebuje regularnie odwiedzać. Robots.txt steruje przede wszystkim crawlingiem. Nie jest uniwersalnym mechanizmem usuwania dokumentów z indeksu.

Dlaczego blokada w robots.txt nie oznacza automatycznie usunięcia z Google?

Wyszukiwarka może znać adres bez odwiedzania jego zawartości. URL może zostać znaleziony:

• w linku na innej stronie,
• w starej wersji indeksu,
• w zewnętrznym serwisie,
• w sitemapie.

Jeżeli robots.txt blokuje pobranie dokumentu, crawler nie może zobaczyć jego treści. Może jednak nadal wiedzieć, że adres istnieje. Dlatego: „Disallow” nie jest tym samym co: „usuń ten adres z wyników”.

Crawling a noindex

Noindex działa inaczej niż robots.txt. Dyrektywa noindex mówi wyszukiwarce: „możesz pobrać ten dokument, ale nie umieszczaj go w wynikach”. Aby crawler mógł zastosować tę instrukcję, musi ją najpierw zobaczyć. Może być ona przekazana na przykład w HTML: <meta name="robots" content="noindex"> Jeżeli jednocześnie zablokuję ten sam URL w robots.txt, powstaje problem. Robot nie może odwiedzić dokumentu. Nie może więc przeczytać znajdującej się w nim instrukcji noindex. Dlatego crawling i indeksowanie trzeba traktować jako dwa oddzielne poziomy kontroli.

Crawling a sitemap XML

Mapa XML pomaga wyszukiwarce odkrywać ważne adresy. Powinna jednak zawierać przede wszystkim URL, które rzeczywiście chcę prezentować jako właściwe strony serwisu. Jeżeli sitemap zawiera:

• 404,
• przekierowania,
• adresy noindex,
• duplikaty,
• nieaktualne URL,

wysyłam sprzeczny komunikat. Z jednej strony: „to ważna strona”. Z drugiej: „ta strona już nie istnieje” albo „nie chcę jej indeksować”. Mapa powinna być uporządkowanym zestawem właściwych adresów. Nie eksportem wszystkiego, co system kiedykolwiek wygenerował.

Crawling a linkowanie wewnętrzne

Linkowanie wewnętrzne tworzy graf połączeń pomiędzy stronami. Robot może przejść: strona główna → oferta → konkretna usługa. Albo: kategoria → podkategoria → produkt. Im bardziej logiczna architektura, tym łatwiej zrozumieć relacje pomiędzy poszczególnymi dokumentami. Dzięki temu crawler nie otrzymuje wyłącznie listy URL. Dostaje również kontekst. Widoczność linku może sygnalizować: ta strona jest istotna. Ta treść rozwija poprzedni temat. Ten produkt należy do tej kategorii. Ten artykuł jest powiązany z tym pojęciem.

Co to jest orphan page?

Orphan page to strona osierocona. Nie prowadzi do niej żaden normalny link wewnętrzny. Może nadal:

• znajdować się w sitemapie,
• mieć backlinki,
• być znana Google,
• pojawiać się w indeksie.

Ale z punktu widzenia architektury serwisu praktycznie nie istnieje. Takie strony często powstają po:

• zmianie menu,
• usunięciu kategorii,
• migracji,
• przebudowie struktury,
• ręcznym utworzeniu strony bez późniejszego podlinkowania.

Podczas audytu dobrze jest więc porównywać crawl serwisu z sitemapą oraz innymi źródłami URL.

Co to jest crawl depth?

Crawl depth określa w uproszczeniu, ile kroków dzieli dokument od punktu startowego crawla. Jeżeli zaczynam od strony głównej: strona główna – poziom 0. Kategoria – poziom 1. Podkategoria – poziom 2. Produkt – poziom 3. Nie jest to magiczny czynnik rankingowy. Jest jednak bardzo przydatnym sposobem oceny architektury. Jeżeli najważniejsza usługa znajduje się sześć kliknięć od strony głównej, a przypadkowa strona techniczna jedno kliknięcie, warto sprawdzić, czy struktura rzeczywiście odzwierciedla znaczenie treści.

Czy każda strona powinna być maksymalnie trzy kliknięcia od strony głównej?

Nie traktuję tego jako sztywnej reguły. Serwis mający 30 podstron działa inaczej niż sklep posiadający 200 000 produktów. Najważniejsza jest logiczna hierarchia. Najważniejsze elementy powinny być łatwe do odnalezienia. Nie trzeba natomiast sztucznie spłaszczać całej architektury tylko po to, aby każdy URL spełniał arbitralną liczbę kliknięć.

Co to jest crawl budget?

Crawl budget opisuje w uproszczeniu ilość crawlingu, jaką wyszukiwarka chce i może przeznaczyć na konkretny serwis. Nie jest to jedna stała liczba typu: „Google odwiedza dokładnie 10 000 URL dziennie”. Na crawling wpływają między innymi:

• liczba adresów,
• częstotliwość zmian,
• zainteresowanie konkretnymi stronami,
• wydajność serwera,
• liczba błędów,
• potrzeba ponownego odwiedzania dokumentów.

Google nie chce przeciążyć serwera. Jednocześnie nie ma powodu przeznaczać ogromnych zasobów na regularne odwiedzanie milionów bezwartościowych duplikatów.

Czy każda strona musi martwić się crawl budgetem?

Nie. To bardzo częsty przypadek przesadnej optymalizacji. Strona firmowa posiadająca: 80 podstron, 20 wpisów, kilkanaście realizacji zwykle nie powinna rozpoczynać działań SEO od „optymalizacji crawl budgetu”. Znacznie ważniejsze mogą być:

• indeksowanie,
• struktura,
• treści,
• linkowanie,
• szybkość,
• problemy techniczne.

Crawl budget robi się naprawdę interesujący przy dużych serwisach, bardzo szybko zmieniających się zasobach albo systemach generujących ogromną liczbę adresów.

Crawling w sklepie internetowym

E-commerce jest jednym z miejsc, w których liczba URL może rosnąć znacznie szybciej niż liczba produktów. Sklep posiada:

• produkty,
• kategorie,
• podkategorie,
• marki,
• filtry,
• sortowanie,
• paginację,
• wyszukiwarkę,
• warianty,
• parametry URL.

Tysiąc produktów może więc wygenerować dziesiątki albo setki tysięcy potencjalnych adresów. Jeżeli crawler zaczyna chodzić po wszystkich kombinacjach, struktura przestaje przypominać uporządkowany katalog. Staje się praktycznie nieskończoną przestrzenią URL.

Crawling a faceted navigation

Faceted navigation to filtrowanie oparte na cechach produktów. Użytkownik może wybrać:

• markę,
• kolor,
• rozmiar,
• materiał,
• cenę.

To świetny UX w sklepie. Technicznie może jednak prowadzić do powstania ogromnej liczby kombinacji. Przykład: 10 marek. 8 kolorów. 12 rozmiarów. 5 materiałów. Kilka zakresów cenowych. Liczba potencjalnych zestawień szybko robi się ogromna. Nie każda kombinacja powinna być osobną stroną SEO. Dlatego trzeba świadomie zdecydować: które filtry tworzą wartościowe landing pages? które mają służyć tylko użytkownikowi? które adresy powinny być crawlable? których crawler w ogóle nie potrzebuje?

Crawling a paginacja

Paginacja dzieli duży zbiór elementów na kolejne strony. Kategoria może posiadać: /buty/ /buty/page/2/ /buty/page/3/ Kolejne strony mogą zawierać produkty, których nie ma na stronie pierwszej. Dlatego bezmyślne zablokowanie paginacji może ograniczyć crawlerowi dostęp do części katalogu. To szczególnie istotne wtedy, gdy produkty nie posiadają wielu innych linków wewnętrznych. Paginację trzeba projektować jako część architektury. Nie traktować jak techniczny odpad.

Crawling a infinite scroll

Infinite scroll automatycznie doładowuje kolejne elementy podczas przewijania. Dla użytkownika może być wygodny. Crawler potrzebuje jednak realnej struktury adresów i linków. Jeżeli kolejne produkty istnieją wyłącznie po wykonaniu JavaScriptu i nie posiadają normalnej drogi przez paginację lub linki, część katalogu może być trudniejsza do odkrycia. Dlatego nowoczesny interfejs może działać jako infinite scroll, a pod spodem nadal posiadać zwykłą strukturę paginacji. UX i crawlability nie muszą się wzajemnie wykluczać.

Crawling a wyszukiwarka wewnętrzna

Wyszukiwarka na stronie może generować praktycznie nieskończoną liczbę adresów. Użytkownik może wpisać: „buty”. „czarne buty”. „buty czarne”. „buty czarne męskie”. I tysiące innych zapytań. Jeżeli każdy wynik tworzy własny URL dostępny dla crawlera, robot może wejść w ogromną przestrzeń stron o małej albo zerowej wartości SEO. Wyszukiwarka wewnętrzna jest świetnym narzędziem dla człowieka. Nie oznacza to, że jej wszystkie wyniki powinny być częścią struktury wyszukiwarki internetowej.

Crawling a parametry URL

Parametry mogą odpowiadać za:

• filtrowanie,
• sortowanie,
• tracking,
• zmianę widoku,
• ustawienia użytkownika.

Adres: /produkt/?utm_source=newsletter nie musi być nową stroną. Może prezentować dokładnie tę samą zawartość co: /produkt/ Jeżeli system generuje wiele wariantów tego samego dokumentu, crawler może niepotrzebnie odwiedzać kolejne wersje. Dlatego projektowanie URL jest częścią architektury technicznej serwisu. Nie wyłącznie kosmetyką.

Crawling a canonical

Canonical pomaga wskazać preferowaną wersję spośród kilku podobnych adresów. Nie jest jednak blokadą crawlingu. Jeżeli tysiąc URL wskazuje canonical na jeden dokument, crawler nadal może odwiedzić te tysiąc stron, aby zobaczyć ich zawartość i sygnały. Canonical rozwiązuje przede wszystkim problem konsolidacji. Nie jest magicznym narzędziem do ograniczania całej przestrzeni adresów. Dlatego zadaję dwa osobne pytania: który URL powinien być kanoniczny? czy pozostałe URL w ogóle powinny być generowane w takiej liczbie?

Crawling a przekierowania

Crawler podąża również za przekierowaniami. Jeżeli: A → B robot może przejść do B. Problemem są długie łańcuchy: A → B → C → D. Każdy krok wymaga kolejnego żądania. Znacznie lepiej, jeśli A prowadzi od razu do D. Przekierowania są normalną częścią internetu. Nie powinny jednak zastępować aktualizacji własnych linków. Jeżeli cały serwis nadal linkuje do starego adresu, który zawsze wykonuje 301, crawler za każdym razem przechodzi przez dodatkowy krok. Wewnętrzne linkowanie powinno prowadzić bezpośrednio do aktualnego URL.

Crawling a statusy HTTP

Status HTTP mówi crawlerowi, co wydarzyło się podczas próby pobrania zasobu. Najczęstsze sytuacje:

• 200 – dokument został zwrócony prawidłowo,
• 301 lub 308 – zasób został trwale przeniesiony,
• 302 lub 307 – przekierowanie tymczasowe,
• 404 – dokumentu nie znaleziono,
• 410 – zasób został usunięty,
• 5xx – wystąpił problem po stronie serwera.

Statusy są językiem komunikacji pomiędzy klientem a serwerem. Dlatego podczas analizy crawlingu patrzę również na mechanikę opisaną szerzej we wpisie o HTTP i HTTPS.

Co się dzieje, gdy serwer zwraca dużo błędów 5xx?

Crawler nie powinien przeciążać serwera. Jeżeli kolejne żądania kończą się błędami, wyszukiwarka może ograniczyć intensywność crawlingu. To logiczne. Serwer mówi: „mam problem z obsługą ruchu”. Dokładanie kolejnych żądań tylko pogorszyłoby sytuację. Dlatego crawling jest również zależny od jakości infrastruktury. Jeżeli źródłem problemu jest niestabilny backend, nie naprawię go zmianą title albo dodaniem kolejnego artykułu.

Crawling a wydajność serwera

Bardzo wolny backend utrudnia sprawne przechodzenie przez duży serwis. Jeżeli pobranie każdego dokumentu zajmuje kilka sekund, zeskanowanie setek tysięcy URL wymaga znacznie większych zasobów. Nie oznacza to prostego wzoru: szybsza odpowiedź = wyższa pozycja. Pokazuje jednak, że wydajność wpływa na więcej niż komfort użytkownika. Przy diagnostyce sprawdzam więc zarówno frontend przez narzędzia takie jak PageSpeed Insights, jak i zachowanie samego serwera.

Crawling a JavaScript

Wiele współczesnych stron wykorzystuje JavaScript do budowania interfejsu i ładowania danych. Google potrafi renderować JavaScript. Proces może jednak wymagać dodatkowej pracy. Najpierw zostaje pobrany dokument. Później system może wykonać skrypty. Dopiero wtedy pojawia się pełna zawartość. Jeżeli podstawowa treść oraz kluczowe linki mogą znajdować się bezpośrednio w HTML, jest to zwykle prostszy fundament. Nie dlatego, że JavaScript jest „zły dla SEO”. Dlatego, że nie ma powodu komplikować dostępu do informacji, która może zostać dostarczona od razu.

Czy crawler widzi linki dodane przez JavaScript?

Może je zobaczyć po renderowaniu. Nie każdy element wyglądający jak link jest jednak prawdziwym linkiem. Najbardziej przewidywalnym rozwiązaniem pozostaje normalny element posiadający rzeczywisty adres w atrybucie href. Dotyczy to szczególnie:

• menu,
• list produktów,
• paginacji,
• powiązanych wpisów,
• nawigacji kategorii.

Jeżeli kliknięcie działa wyłącznie jako funkcja JavaScript bez URL, crawler nie dostaje tej samej informacji co przy zwykłym linku.

Crawling strony statycznej

W dobrze zbudowanej stronie statycznej crawler może otrzymać od razu gotowy HTML. Nie trzeba generować dokumentu z bazy podczas każdego żądania. Jeżeli architektura jest poprawna, robot dostaje:

• treść,
• nagłówki,
• linki,
• metadane,
• semantyczną strukturę dokumentu.

Nie oznacza to automatycznie idealnego SEO. Static również można zbudować źle. Daje jednak bardzo prosty technicznie punkt wyjścia i ogranicza liczbę elementów potrzebnych do dostarczenia podstawowej zawartości.

Crawling WordPressa

WordPress może być crawlowany całkowicie prawidłowo. Problemy nie wynikają automatycznie z samego CMS-u. Znacznie częściej są efektem konfiguracji. Motyw i wtyczki mogą generować:

• tagi,
• archiwa,
• wyniki wyszukiwania,
• parametry,
• strony autorów,
• dodatkowe endpointy,
• techniczne warianty URL.

Serwis mający 100 właściwych treści może więc posiadać wielokrotnie więcej crawlable adresów. Pytanie brzmi: czy wszystkie są potrzebne?

Crawling WooCommerce

WooCommerce dodatkowo rozszerza przestrzeń adresów. Pojawiają się:

• produkty,
• kategorie,
• tagi,
• atrybuty,
• filtry,
• sortowania,
• paginacja,
• konto klienta,
• koszyk,
• checkout.

Do tego każda dodatkowa wtyczka może tworzyć własne parametry i endpointy. Właśnie dlatego przy dużym sklepie nie oceniam crawlingu na podstawie kilku kart produktów. Trzeba zobaczyć cały system URL.

Jak sprawdzić, co crawler widzi na stronie?

Można wykorzystać kilka różnych źródeł. Pierwszym jest Google Search Console. Pozwala sprawdzać konkretne adresy i informacje związane z ich dostępnością oraz indeksowaniem. Drugim są crawlery SEO. Mogę uruchomić automatyczne przejście przez serwis i zebrać:

• adresy,
• statusy HTTP,
• przekierowania,
• canonicale,
• linki wewnętrzne,
• głębokość,
• metadane.

Trzecim źródłem są logi serwera. One pokazują coś jeszcze ciekawszego: które adresy prawdziwy bot rzeczywiście odwiedzał.

Crawling a Google Search Console

Search Console pomaga odpowiedzieć na pytania: czy Google zna adres? czy crawling jest możliwy? czy strona została pobrana? czy występuje problem z indeksowaniem? Nie jest jednak pełnym crawlerem całego serwisu. Dlatego w większych projektach łączę dane z Search Console z własnym crawlem oraz analizą struktury. Każde źródło pokazuje trochę inną część problemu.

Crawling w narzędziach SEO

Narzędzia audytowe potrafią zachowywać się jak crawler. Przechodzą przez stronę, odkrywają URL i budują własny obraz struktury. To bardzo przydatne podczas audytu technicznego strony lub sklepu. Trzeba jednak pamiętać: crawl wykonany przez zewnętrzne narzędzie nie jest dokładnym zapisem tego, co zrobił Googlebot. Pokazuje potencjalny problem. Nie dowodzi automatycznie, że Google zachowało się identycznie.

Crawling a web scraping

Crawler i scraper technicznie mogą wykonywać podobne działania. Oba pobierają automatycznie strony. Różnica zwykle dotyczy celu. Crawler koncentruje się na odkrywaniu dokumentów i budowaniu obrazu struktury. Web scraping częściej koncentruje się na wydobywaniu określonych danych. Przykład crawl: odkryj wszystkie produkty. Przykład scraping: z każdego produktu pobierz nazwę, cenę, SKU i dostępność. W praktyce jedno narzędzie może wykonywać oba zadania.

Co pokazują logi serwera?

Log może przechowywać informacje o rzeczywistych żądaniach. Dzięki temu mogę zobaczyć między innymi:

• jaki URL został pobrany,
• kiedy,
• przez jaki user-agent,
• jaki status otrzymał,
• jak długo trwała odpowiedź.

To bardzo wartościowe przy dużych stronach. Może się okazać, że crawler większość czasu spędza na parametrach filtrów. Albo że ważny katalog produktów jest odwiedzany bardzo rzadko. Tego nie zobaczę, uruchamiając wyłącznie własny crawler.

Czy user-agent Googlebot oznacza, że odwiedził mnie Google?

Nie zawsze. User-agent można podrobić. Dowolny bot może przedstawić się jako Googlebot. Dlatego przy poważniejszej analizie nietypowego ruchu można dodatkowo zweryfikować, czy żądania rzeczywiście pochodzą z infrastruktury deklarowanego operatora. Ma to szczególne znaczenie wtedy, gdy automatyczny ruch mocno obciąża serwer.

Jak często Google crawluje stronę?

Nie istnieje jeden harmonogram dla całego internetu. Jedna podstrona może być odwiedzana wielokrotnie. Inna znacznie rzadziej. Znaczenie może mieć:

• częstotliwość zmian,
• znaczenie dokumentu,
• popularność,
• historia serwisu,
• wydajność serwera.

Homepage portalu newsowego zmienia się przez cały dzień. Stary regulamin firmy może nie zmieniać się przez kilka lat. Nie ma powodu odwiedzać obu stron z identyczną częstotliwością.

Czy można zmusić Google do crawlowania strony?

Można ułatwić odkrycie adresu. Można:

• dodać właściwe linkowanie,
• umieścić URL w sitemapie,
• zgłosić konkretny adres do ponownego sprawdzenia.

Nie można jednak uczciwie powiedzieć: „Google ma wejść dokładnie teraz”. Wyszukiwarka sama zarządza crawlingiem. Dlatego nie buduję procesu publikacji wokół ręcznego zgłaszania każdej podstrony. Dobrze zbudowany serwis powinien sam tworzyć logiczne ścieżki odkrywania nowych treści.

Crawling a aktualizacja treści

Crawler może wracać do istniejących stron, aby sprawdzić zmiany. Nie ma jednak sensu sztucznie zmieniać daty artykułu tylko po to, aby zasugerować aktualizację. Jeżeli dokument został rzeczywiście zmieniony, nowa data może mieć sens. Jeżeli zmieniła się tylko data, a treść jest identyczna, nie powstała żadna nowa informacja. Sygnał powinien wynikać z rzeczywistości.

Crawling podczas migracji strony

Migracja jest jednym z momentów, w których crawling staje się szczególnie ważny. Crawler zna stare adresy. Nowy serwis może posiadać zupełnie inną strukturę. Trzeba zbudować pomiędzy nimi logiczne przejście. Najczęściej obejmuje to:

• mapę starych i nowych URL,
• przekierowania,
• aktualne linki wewnętrzne,
• nową sitemapę,
• robots.txt,
• canonicale,
• kontrolę statusów HTTP.

Jeżeli po migracji crawler otrzymuje tysiące 404 i długie łańcuchy przekierowań, musi ponownie zrozumieć serwis w znacznie trudniejszych warunkach. Dlatego migrację przygotowuje się przed publikacją nowej wersji. Nie dopiero po zauważeniu spadków.

Crawling środowiska testowego

Środowisko stagingowe nie powinno przypadkowo stać się drugą publiczną wersją strony. Samo: „Disallow: /” w robots.txt nie jest zabezpieczeniem dostępu. Robots.txt jest instrukcją dla robotów respektujących standard. Nie hasłem. Nie firewallem. Nie autoryzacją. Jeżeli środowisko testowe zawiera informacje, których nie powinien zobaczyć przypadkowy użytkownik, trzeba zastosować realną kontrolę dostępu.

Crawling a błędy 404

404 samo w sobie nie jest awarią SEO. Jeżeli dokument rzeczywiście nie istnieje, 404 jest prawidłową odpowiedzią. Problem powstaje wtedy, gdy:

• ważna strona przypadkowo zaczyna zwracać 404,
• menu prowadzi do nieistniejących URL,
• tysiące linków wewnętrznych prowadzą do błędów,
• stare wartościowe adresy znikają po migracji bez odpowiedniego rozwiązania.

Crawler trafia wtedy na martwe ścieżki. Właśnie dlatego automatyczny crawl bardzo dobrze nadaje się do wyszukiwania uszkodzonych linków wewnętrznych.

Co to jest soft 404?

Soft 404 pojawia się wtedy, gdy treść wygląda jak brakująca strona, ale serwer technicznie zwraca status 200. Przykład: produkt został usunięty. Na stronie znajduje się komunikat: „Nie znaleziono produktu”. Serwer odpowiada jednak: 200 OK. Technicznie oznacza to: „dokument istnieje i został zwrócony poprawnie”. Treść mówi coś przeciwnego. Takie niespójności utrudniają interpretację. Status HTTP powinien odpowiadać rzeczywistemu stanowi zasobu.

Crawling a duplikaty

Jeżeli ten sam dokument jest dostępny pod wieloma URL, crawler może odwiedzać kolejne kopie. Źródłem duplikacji mogą być:

• parametry,
• sortowania,
• wersje HTTP i HTTPS,
• wersje z www i bez www,
• błędne warianty slash,
• różne ścieżki prowadzące do tej samej treści.

Jedna duplikacja przy kilku stronach nie jest katastrofą. W serwisie posiadającym setki tysięcy adresów problem może jednak znacząco zwiększyć przestrzeń crawlingową. Dlatego podczas analizy pytam nie tylko: „czy canonical jest ustawiony?”. Pytam również: „dlaczego te duplikaty w ogóle powstają?”.

Crawling a HTTP i HTTPS

Dla crawlera: http://domena.pl/produkt/ i: https://domena.pl/produkt/ są technicznie różnymi adresami. Jeżeli obie wersje działają równolegle bez prawidłowej konsolidacji, serwis może generować niepotrzebną duplikację. Dlatego po wdrożeniu HTTPS powinien istnieć spójny system:

• przekierowań,
• canonicali,
• sitemap,
• linków wewnętrznych.

Nie ma sensu zmuszać crawlera do ciągłego odkrywania starej wersji HTTP tylko po to, aby zawsze przekierowywać go później na HTTPS.

Crawling a boty AI

Nie każdy crawler należy do klasycznej wyszukiwarki. Automatycznie strony mogą odwiedzać również:

• systemy archiwizujące internet,
• narzędzia SEO,
• monitoring,
• scrapery,
• boty wykorzystywane przez systemy AI.

Każdy może posiadać inny user-agent i inne zasady. Dlatego konfiguracja dostępu nie powinna sprowadzać się do myślenia wyłącznie: „Googlebot albo nic”. Internet jest pełen automatycznych klientów.

Crawling a bezpieczeństwo

Crawler może odnaleźć URL, który zwykły użytkownik rzadko zauważa. Dlatego nigdy nie traktuję: braku linku ani: blokady robots.txt jako zabezpieczenia poufnych danych. Jeżeli dokument ma być prywatny, wymaga prawdziwej kontroli dostępu. Przykład: panel klienta. Dokument finansowy. Zaplecze administracyjne. Plik testowy zawierający dane. Nie powinny być chronione wyłącznie dlatego, że „Google ich nie indeksuje”. Indeksowanie i bezpieczeństwo to dwie zupełnie różne rzeczy.

Najczęstsze problemy z crawlingiem

Przypadkowa blokada w robots.txt

Po zmianie środowiska testowego konfiguracja trafia na produkcję i crawler traci dostęp do ważnych adresów.

Brak linkowania

Strony istnieją, ale nie prowadzi do nich żadna logiczna ścieżka.

Nieskończone kombinacje filtrów

Crawler może tworzyć kolejne URL praktycznie bez końca.

Wyszukiwarka wewnętrzna dostępna dla botów

Dowolne zapytanie generuje nową stronę.

Duża liczba parametrów

Ten sam dokument istnieje pod wieloma adresami.

Łańcuchy przekierowań

Crawler wykonuje kilka niepotrzebnych kroków przed dotarciem do właściwego zasobu.

Błędy serwera

Ważne strony okresowo zwracają 5xx.

Linki dostępne tylko przez skomplikowany JavaScript

Struktura katalogu zależy od wykonania wielu warstw frontendu.

Stara sitemap

Mapa prowadzi do nieistniejących albo przekierowanych URL.

Złe połączenie robots.txt i noindex

Crawler ma zastosować noindex, ale jednocześnie nie może pobrać dokumentu, żeby tę instrukcję zobaczyć.

Jak sprawdzić crawling własnej strony?

Zaczynam od prostych pytań. Czy robots.txt nie blokuje ważnych obszarów? Czy sitemap zawiera właściwe URL? Czy ważne strony posiadają linki wewnętrzne? Czy crawler otrzymuje prawidłowe statusy HTTP? Czy istnieją długie łańcuchy przekierowań? Czy serwis generuje tysiące parametrów? Czy filtry tworzą niekontrolowaną liczbę adresów? Czy JavaScript nie ukrywa fundamentalnej nawigacji? Dopiero później przechodzę do bardziej zaawansowanej analizy. Nie warto zaczynać od crawl budgetu, jeżeli trzy najważniejsze strony są przypadkowo zablokowane.

Jak wygląda crawl techniczny serwisu?

Podczas audytu uruchamiam crawler od określonego punktu, najczęściej strony głównej. System przechodzi przez linki i buduje listę dokumentów. Później mogę analizować między innymi:

• statusy,
• redirecty,
• canonicale,
• indeksowalność,
• głębokość,
• linki przychodzące i wychodzące,
• metadane,
• duplikaty.

Najważniejsze jest jednak nie samo wygenerowanie raportu. Trzeba zrozumieć strukturę problemu. Jeżeli crawler znalazł 30 000 błędnych URL, nie oznacza to automatycznie 30 000 osobnych błędów. Może istnieć jeden wadliwy mechanizm generujący wszystkie te adresy.

Dlaczego liczba URL w crawlu jest ważna?

Załóżmy, że sklep posiada: 5000 produktów. 100 kategorii. 50 stron informacyjnych. Spodziewam się kilku albo kilkunastu tysięcy sensownych URL. Crawler znajduje 1 800 000 adresów. To od razu rodzi pytanie: skąd wzięła się reszta? Najczęściej odpowiedź znajduje się w:

• filtrach,
• parametrach,
• sortowaniu,
• wyszukiwarce,
• kalendarzach,
• generowanych kombinacjach.

Sama różnica pomiędzy liczbą realnych treści a liczbą odkrytych URL potrafi bardzo szybko ujawnić problem architektury.

Dlaczego crawling jest ważny dla SEO?

Bo wyszukiwarka nie może sensownie analizować dokumentu, którego nie potrafi pobrać. Można mieć: najlepszy tekst, świetny produkt, idealny title, najbardziej rozbudowane dane strukturalne. Jeżeli crawler nie dociera do strony, wszystkie te elementy mają ograniczone znaczenie. Właśnie dlatego SEO nie zaczyna się wyłącznie od słów kluczowych. Zaczyna się również od technicznej możliwości dotarcia do informacji.

Crawling nie jest celem samym w sobie

Nie chodzi o to, aby Googlebot odwiedzał jak najwięcej URL. To nie jest konkurs. Jeżeli crawler pobiera milion stron miesięcznie, z czego 900 000 to bezużyteczne kombinacje filtrów, duża liczba nie jest sukcesem. Chcę, żeby system sprawnie docierał do właściwych treści. Nowych produktów. Zaktualizowanych kategorii. Ważnych artykułów. Kluczowych stron oferty. Efektywność jest ważniejsza od samej liczby żądań.

Crawling jako element architektury strony

Dobrze zaprojektowany serwis naturalnie pomaga crawlerowi. Nie wymaga później setek wyjątków. Posiada:

• logiczną strukturę,
• czytelne URL,
• normalne linkowanie,
• uporządkowaną sitemapę,
• przewidywalne statusy HTTP,
• kontrolę nad parametrami.

Im więcej technicznych obejść trzeba dodać później, tym częściej źródłem problemu jest fundament systemu. Dlatego crawling najlepiej uwzględniać już podczas budowania strony albo sklepu. Nie dopiero po kilku latach, gdy crawler odkrył pół miliona przypadkowych adresów.

Jak podchodzę do crawlingu w DIGIKROM?

Nie zaczynam od pytania: „jak zwiększyć crawl budget?”. Najpierw chcę zobaczyć, po czym crawler w ogóle chodzi. Ile istnieje rzeczywistych treści? Ile URL generuje system? Które strony są ważne? Czy crawler może do nich dojść? Czy nie trafia po drodze na błędy? Czy filtry tworzą nieskończoną przestrzeń? Czy robots.txt pomaga, czy przypadkiem blokuje coś potrzebnego? Czy sitemap opisuje faktyczną strukturę? Czy linkowanie prowadzi bezpośrednio do aktualnych adresów? Dopiero wtedy podejmuję decyzje. Przy małej stronie może się okazać, że crawling działa poprawnie i temat nie wymaga żadnej optymalizacji. Przy dużym sklepie jeden źle zaprojektowany filtr może natomiast generować setki tysięcy adresów i całkowicie zaciemnić obraz serwisu. Dlatego w SEO technicznym DIGIKROM crawl traktuję jako diagnostykę całego systemu, a nie jako raport z liczbą błędów. Crawler pokazuje mi, jak strona wygląda wtedy, kiedy przestaję patrzeć na nią jak użytkownik i zaczynam patrzeć jak automat próbujący przejść przez całą strukturę. Bardzo często właśnie wtedy wychodzą na jaw problemy, których nie widać podczas zwykłego kliknięcia kilku podstron. I to jest największa wartość crawlingu. Nie samo skanowanie strony. Możliwość zobaczenia, jak naprawdę została zbudowana.