Techniczne SEO — sitemap, robots.txt, crawlability

Co to jest sitemap, robots.txt i crawlability — i po co marketerowi?

Sitemap (zwykle sitemap.xml) to plik, który mówi wyszukiwarce: „to są adresy URL, które istnieją i chcesz je odkryć”. Nie jest magicznym przyciskiem „indeksuj teraz”, ale bardzo ułatwia Google rozpoznanie struktury serwisu, zwłaszcza w dużych witrynach, z blogiem, e-commerce lub wieloma kategoriami.

→ Ile kosztuje pozycjonowanie strony w Polsce — widełki i co decyduje?

→ Agencja SEO vs. freelancer vs. samodzielne SEO — co wybrać?

→ Jak Google ocenia jakość treści (E-E-A-T)?

robots.txt to plik, który odpowiada na pytanie: „które ścieżki mogą być crawl’owane (skanowane) przez boty?”. Uwaga: robots.txt nie usuwa z indeksu. To tylko instrukcja dla crawlerów. Jeśli zablokujesz w nim stronę, a później dziwisz się, że nie ma jej w wynikach — to klasyk.

Crawlability to w praktyce zdolność witryny do tego, żeby robot mógł wejść, przejść dalej i szybko zrozumieć strukturę. Na crawlability wpływa m.in.:

• limity budżetu indeksowania i responsywność serwera,
• liczba zbędnych URL-i (np. parametry, wersje do druku, filtry),
• wewnętrzne linkowanie (czy robot ma „drogi” między tematami),
• błędy typu 404/500 i przekierowania łańcuchowe,
• logika „to jest ważne / to nie jest ważne”.

W skrócie: sitemap i robots.txt to sterowanie ruchem bota. Crawlability to to, jak ten ruch działa w realnym serwisie.

Sitemap — jak zbudować, wysłać i nie zrobić sobie krzywdy

Najczęstsza pułapka: wrzucamy do sitemap „wszystko jak leci”, bo „to przecież pomaga”. Pomaga tylko do pewnego momentu. Google i tak będzie wybierał, co indeksować, ale Ty zwiększasz ryzyko, że w sitemap zaczną dominować URL-e niskiej jakości: duplikaty, puste katalogi, strony z parametrami, które i tak nie powinny rankować.

Jak powinien wyglądać sitemap

• Format: standard XML.
• Zakres: tylko URL-e, które chcesz, żeby Google odkrywał (i finalnie indeksował).
• Brak duplikatów: unikaj wielu wariantów tej samej treści (np. różne parametry sortowania).
• Aktualność: sitemap ma odzwierciedlać realny stan publikacji.

Benchmark: ile stron realnie powinno „żyć” w indeksie

W praktyce (na projektach dla klientów SMB do mid-market) spotykałem sytuacje, gdzie witryna ma np. 20–50 tys. URL-i technicznie dostępnych, ale sensownie indeksowalnych jest 5–15 tys. To normalne. Problem zaczyna się, gdy sitemap zapełnia się URL-ami, które mają 0–5% unikalnej wartości (np. filtry, tagi, archiwa z bardzo cienką treścią).

Jak to zweryfikować w Google Search Console

Wejdź w Google Search Console > Sitemaps i sprawdź:

• czy sitemap jest „przetworzony” bez ostrzeżeń,
• czy rośnie liczba URL-i „added to index”,
• czy nie ma długich okresów błędów (np. 404 w sitemap).

Jeśli w GSC widzisz dużą rozbieżność: sitemap zawiera 30 tys., a indeks ma 5 tys., to nie zawsze znaczy „Google ignoruje”. Często oznacza to: treści są duplikowane, przekierowują, są zablokowane przez noindex, albo robot nie widzi drogi do tych URL-i.

Anegdota z praktyki: na jednym z projektów dla klienta e-commerce audytowałem sitemap po wdrożeniu nowego silnika. Okazało się, że sitemap zawierała dziesiątki tysięcy filtrów z parametrami, a część z nich zwracała te same treści. Efekt? Indeks „pływał”, a w raportach widzieliśmy duże zużycie crawl budżetu na URL-e, które nie dawały żadnego leadu.

robots.txt — jak nie blokować indeksowania i gdzie najczęściej się myli webmaster

robots.txt zwykle dostaje najwięcej uwagi dopiero wtedy, gdy „Google nie widzi strony”. A problem jest banalny: dyrektywy są zrobione z myślą o stealth, a powinny służyć porządkowi.

Najczęstsze błędy w robots.txt

• Zablokowanie katalogów z ważną treścią (np. sekcja usług, blog, produkty). Jeśli blokujesz, Google nie wejdzie — nawet jeśli treść istnieje.
• Zablokowanie plików zasobów (CSS/JS/obrazków). To może pogorszyć zrozumienie strony przez renderowanie.
• „Disallow: /” lub zbyt szerokie dyrektywy. To zabija crawlability.
• Brak spójności między robots.txt a tagami typu noindex / canonical. Ty blokujesz botom dostęp, a jednocześnie liczysz, że kanoniczność ogarnie temat. Nie ogarnia.

Jak sprawdzić, czy robots.txt nie szkodzi

W GSC użyj narzędzia typu Test robots.txt (w interfejsie będzie dostępne). Sprawdź konkretne URL-e, które chcesz mieć w indeksie:

• czy robots.txt pozwala na crawl,
• czy nie ma przypadkowego „Disallow” dla ścieżek podstron,
• czy nie blokujesz canonicalnych wersji.

Wskazówka mniej oczywista: rozdziel cele dla Google bota i dla „zbędnych” crawlerów

Jeśli Twoja firma ma sporo śmieciowego ruchu botów (np. skanery), to warto stosować reguły dla wybranych user-agentów, zamiast blokować wszystko pod jedną szablonową regułą. Zbyt agresywny robots.txt potrafi obniżyć crawlability bez żadnego zysku w bezpieczeństwie.

Crawlability — co realnie wpływa na to, ile stron Google skanuje

Crawlability to nie jest jeden checkbox. To suma dziesiątek małych elementów. Poniżej masz te, które robią największą różnicę i dają szybkie efekty.

1) Linkowanie wewnętrzne: robot musi mieć „korytarze”

Jeśli blog i kategorie są odcięte od struktury (np. brak breadcrumbów, słabe menu, brak powiązań tematycznych), Google będzie docierał rzadziej. Praktycznie: dodaj kontekstowe linki w ramach klastrów tematycznych i zadbaj o logiczne ścieżki (np. kategoria → podkategoria → produkt/usługa).

2) Budżet crawl: za dużo URL-i i za mało wartości

Google ma ograniczoną przepustowość dla crawlera (to się potocznie nazywa budżetem crawl). Jeśli serwis generuje masę URL-i z parametrami (sortowania, filtry), to crawler „zjada” limit na rzeczy, które nie będą rankować.

Tu pomaga: ograniczenie indeksacji i/lub kanoniczność. Typowe akcje to:

• rel=canonical do głównej wersji kategorii,
• blokada w sitemap dla URL-i filtrów,
• korekta w robots.txt dla pathów, które nie powinny być crawl’owane.

3) Prędkość i błędy HTTP

To brzmi jak banał, ale crawlability to „życie bota”. Jeśli strona wolno odpowiada, a do tego masz sporo 500 i 404, to crawler odpuści. Jeśli w logach i GSC widać wzrost błędów, to jest to pierwszy trop.

4) Redirecty: łańcuchy i pętle

Przekierowania łańcuchowe (np. A→B→C) zwiększają koszty crawl. Minimalizuj liczbę przeskoków. Tak samo pętle redirectów muszą zostać usunięte.

5) Jakość indeksacji a CTR (żeby to nie było „indeks, ale po co”)

Techniczne SEO ma sens, jeśli finalnie wpływa na widoczność i ruch. Dla kontekstu: w wyszukiwaniu organicznym średni CTR w wynikach (różnie od branży) często mieści się w okolicach 1–5% dla fraz o średniej konkurencji. Jeśli Google pokaże więcej stron, ale z kiepskim dopasowaniem do intencji, CTR spadnie i nie dowieziesz ROI. Dlatego sitemap i crawlability muszą iść w parze z selekcją URL-i i jakością treści.

SEO vs Google Ads — kiedy techniczne SEO jest priorytetem, a kiedy nie

To jest decyzja biznesowa, nie religia.

Kiedy techniczne SEO wygrywa

• Masz bibliotekę treści (blog/kategorie/oferty) i chcesz długofalowo obniżać koszt pozyskania.
• Widoczność jest niska, mimo sensownej oferty (w GSC widać problemy indeksacji).
• W e-commerce masz dużo stron produktowych i kategorii, a indeks i crawl są „chaotyczne”.
• Masz problem z duplikacją i parametrami, który w Ads trudno opisać jako targeting.

Kiedy Ads bierze pierwszeństwo

• Potrzebujesz leadów „od jutra”. SEO to zwykle tygodnie i miesiące.
• Twoja witryna jest technicznie ok, ale konkurencja wygrywa kreatywnością/ofertą i musisz szybciej testować komunikaty.
• Masz budżet na landing page i lejek, a problemem są konwersje, nie indeksacja.

Orientacyjne koszty (widełki rynkowe) — co zwykle obejmują

Kontrolowana niedoskonałość: jeśli ktoś obiecuje Ci „indeks 100% w 7 dni” bez pracy po stronie jakości stron i struktury, to jest to bardziej obietnica marketingowa niż techniczna rzeczywistość. 😉

Krok po kroku: jak ogarnąć sitemap, robots.txt i crawlability w 7 dni

Poniżej masz plan, który sprawdza się u małych firm i freelancerów. Nie wymaga zespołu 10 osób, ale wymaga dyscypliny w priorytetach.

Dzień 1: Zbierz dane w GSC i ustaw cel

• Google Search Console → sprawdź: Coverage (Indeksowanie), błędy typu „excluded”, „discovered not indexed”.
• GSC → Sitemaps: liczby i ewentualne błędy przetwarzania.
• Ustal cel: np. „zwiększyć liczbę URL-i zaindeksowanych z 8 000 do 12 000 w 4–6 tygodni”, ale na URL-ach, które mają znaczenie biznesowe (oferty, kategorie, wpisy z intencją).

Dzień 2: Sitemap — filtruj wartościowe URL-e

• Wygeneruj listę URL-i, które nie powinny być w sitemap (duplikaty, parametry filtrów, strony typu „pusty wynik wyszukiwania”).
• Jeśli masz dużo typów stron, rozważ sitemap index (kilka sitemap pod typy: produkty/usługi/blog).
• Zamień „wszystko” na „to ma znaczenie”. To jest najczęstszy upgrade crawlability.

Dzień 3: robots.txt — test przed wdrożeniem

• W GSC przetestuj URL-e, które chcesz indeksować: czy nie są blokowane.
• Sprawdź ścieżki zasobów (czy nie blokujesz CSS/JS/obrazków).
• Jeśli masz w robots.txt linie „pod zabezpieczenie”, dopasuj je do konkretnych ścieżek, nie do całych katalogów.

Dzień 4: Crawlability — usuń techniczny szum

• Przegląd błędów HTTP: 404/500. Napraw priorytetowe URL-e.
• Wyeliminuj redirect chains.
• Ustaw i zweryfikuj kanoniczność dla stron, które generują duplikaty.

Dzień 5: Linkowanie wewnętrzne — zrób „mapę drogową”

• Dodaj breadcrumb i zadbaj o spójne kategorie.
• Wewnątrz treści dodaj linki do pokrewnych podstron (nie jako „lista”, tylko jako wsparcie kontekstu).
• Sprawdź, czy strony, które chcesz rankować, mają co najmniej kilka sensownych wejść z poziomu nawigacji.

Dzień 6: Sprawdź renderowanie i dostępność treści

• Jeśli serwis jest SPA / ma dynamiczne ładowanie, upewnij się, że treść docelowa jest dostępna dla bota.
• W praktyce pomaga test URL w GSC + narzędzia do audytu (np. Screaming Frog SEO Spider, Sitebulb).

Dzień 7: Monitorowanie i iteracje

• Utwórz checklistę: sitemap, robots, indeksacja, błędy HTTP, nowe URL-e w GSC.
• Ustal rytm: raport co tydzień przez 4 tygodnie, potem co 2–4 tygodnie.

Benchmark na start: nie oczekuj „instant results”. Realny wzrost indeksacji często zaczyna się po kilku dniach do 2 tygodni, ale stabilizacja i efekty jakościowe (czyli URL-e z intencją i CTR) zwykle potrzebują 4–8 tygodni. To jest normalne.

Najczęstsze błędy (i dlaczego kosztują Twoje pieniądze)

Tu są pułapki, które widzę regularnie. Każda z nich ma prosty mechanizm: pogarsza crawlability lub miesza Google’owi w interpretacji priorytetów.

1) Wrzucenie do sitemap URL-i, które i tak nie powinny rankować

Skutek: Google marnuje crawl budget. W GSC masz większe wolumeny „excluded”, a w wynikach wyszukiwania pojawiają się nie te strony, które generują leady. Najgorsze: płacisz za content i ofertę, ale indeks „pompuje” śmieci.

2) Blokada w robots.txt dla sekcji, które chcesz indeksować

Skutek: bot nie ma dostępu. Potem ludzie próbują „naprawić” to linkowaniem zewnętrznym albo kampaniami Ads — a problem siedzi w podstawach. Jeśli w GSC widać „disallowed by robots.txt”, to oszczędź czas i napraw najpierw robots.

3) Brak spójności między sitemap/robots a noindex i canonical

Przykład praktyczny: strona jest w sitemap, robots pozwala na crawl, ale na stronie masz noindex albo canonical do innego URL-a. Google może ją odkrywać, ale nie indeksować. Wynik: brak efektu, a Ty myślisz, że „SEO nie działa”. Działa, tylko w złych warunkach.

4) „Naprawimy później” redirecty i błędy HTTP

Skutek: bot traci czas, a użytkownik dostaje gorsze doświadczenie. Jeśli generujesz leady, to pamiętaj, że problem techniczny potrafi uderzyć w konwersję szybciej niż w ranking.

Porównanie podejść: samodzielnie vs freelancer vs agencja — co jest sensowne przy technicznym SEO?

Jeśli jesteś małą firmą i nie masz stałego dev teamu, najlepszy model to zwykle: audyt + wdrożenie podstaw + później monitoring w rytmie. Techniczne SEO to nie „projekt na raz”, tylko higiena procesów.

Podsumowanie: gdzie zacząć, żeby zobaczyć efekt

Techniczne SEO sprowadza się do kontroli dostępu i priorytetów: sitemap ma wskazywać wartościowe URL-e, robots.txt ma umożliwiać crawl tego, co ważne, a crawlability ma być na tyle czysta, żeby bot nie marnował budżetu na śmieci.

Moje pytanie do Ciebie: czy u Ciebie w Google Search Console dominują „excluded/discovered not indexed”, czy raczej wszystko wygląda „w miarę”? Jeśli wkleisz (albo opiszesz) 3 najczęstsze powody z raportu Coverage i listę typów stron, które chcesz indeksować (np. usługi/kategorie/produkty/artykuły), to podpowiem, od czego zacząć w Twoim przypadku i jakie zmiany dadzą najszybszy zwrot.