Screaming Frog 2026 — nowe funkcje dla audytu technicznego i JavaScript SEO

TL;DR: Screaming Frog 2026 to największa aktualizacja od czasu wydania wersji 20 — renderowanie JavaScriptu w silniku Chromium 124, natywne integracje z Google Search Console, GA4, PageSpeed Insights i OpenAI, tryb segmentów do audytów dużych sklepów, crawl analysis w czasie rzeczywistym oraz raporty dedykowane dla AI Overviews i treści odczytywanych przez LLM. Dla profesjonalnych audytów technicznych i JavaScript SEO jest to wciąż narzędzie numer jeden — pod warunkiem że wiesz, jak skonfigurować crawlera pod konkretny case i nie traktujesz eksportu CSV jako finalnego deliverable.

W tym przewodniku pokazuję krok po kroku, które nowe funkcje Screaming Frog 2026 warto wdrożyć od razu w procesie audytowym, jak zbudować kompletny framework audytu technicznego na bazie SF (9 etapów), jakie błędy najczęściej popełniają SEO-wcy podczas crawla oraz kiedy warto sięgnąć po narzędzie uzupełniające lub zamienne (Sitebulb, JetOctopus, FandangoSEO). Artykuł pisany jest z perspektywy praktyka, który audytuje tygodniowo 3-5 witryn o różnej skali — od stron jednoproduktowych po sklepy z 2 milionami URL-i.

Co nowego w Screaming Frog 2026 i dlaczego to zmienia reguły gry?

Screaming Frog SEO Spider w 2026 roku przestał być jedynie crawlerem — stał się pełnoprawną platformą do technicznego audytu SEO i JavaScript SEO, z natywnymi integracjami, renderingiem nowoczesnych frameworków i eksportem danych bezpośrednio do Looker Studio. Największe zmiany dotyczą silnika renderującego, wydajności przy dużych crawlach i integracji z narzędziami z ekosystemu Google oraz modeli językowych.

Pod maską SF 2026 pracuje Chromium 124 (wcześniej 114), co oznacza pełne wsparcie dla Viewport Transitions API, View Timeline API, Container Queries oraz natywnych Web Components w wersji 3. To pierwszy moment, w którym crawler renderuje frameworki takie jak Next.js 15 z Turbopack, Nuxt 4 czy Astro 5 w sposób praktycznie identyczny jak Googlebot.

Drugim przełomem jest Segment Mode — funkcja, która pozwala podzielić gigantyczny crawl na logiczne segmenty (np. kategoria produktowa, blog, landing page) i analizować je niezależnie, bez konieczności uruchamiania czterech osobnych crawli. Dla witryn e-commerce powyżej 500 000 URL-i to oszczędność 2-3 godzin pracy przy każdym audycie miesięcznym.

Trzecia nowość to AI Readability Report — dedykowany raport pokazujący, jak treści witryny są strukturyzowane pod kątem cytowania przez LLM-y (ChatGPT, Gemini, Perplexity, Claude). Raport analizuje obecność TL;DR, gęstość list i tabel, czystość HTML (brak inline stylingu w treści), spójność schematu Article oraz głębokość nagłówków — dokładnie te sygnały, które aktualnie wpływają na citation probability w AI Overviews.

Jakie konkretne nowe funkcje warto wdrożyć w procesie audytu od razu?

Poniżej lista dziewięciu funkcji, które w praktyce oszczędzają najwięcej czasu i podnoszą jakość audytu. Każdą testowałem na minimum pięciu projektach w pierwszym kwartale 2026 i wszystkie trafiają do mojego defaultowego templatu konfiguracji SF.

1. Native GSC integration v2 — podłączenie GSC przez OAuth bezpośrednio z poziomu Configuration → API Access daje crawlerowi dostęp nie tylko do impresji i kliknięć, ale również do danych z raportów Page Experience, Core Web Vitals field data i pełnej listy URL-i z Index Coverage. Dzięki temu w jednym widoku widzisz URL-e wykluczone z indeksu i przyczyny.
2. PSI Lab + Field data — nowy moduł automatycznie ściąga zarówno dane laboratoryjne (Lighthouse), jak i dane terenowe (CrUX) dla każdego URL-a. Pierwszy raz w historii SF można w jednym eksporcie zobaczyć LCP, INP i CLS z rzeczywistego ruchu.
3. OpenAI custom prompts — Configuration → API Access → OpenAI pozwala zdefiniować własne prompty do analizy meta tytułów, opisów, H1 czy treści. Ja używam do automatycznego flagowania duplikatów semantycznych w title tagach oraz oceny zgodności treści z intencją zapytania.
4. Segment Mode — dzielenie crawla na logiczne sekcje. Dla sklepu ze 100 kategoriami mogę crawlować każdą kategorię osobno w tej samej sesji.
5. JavaScript Rendering Diff — nowy raport porównuje HTML przed renderem i po renderze, pokazując, które elementy (linki, teksty, canonicale) pojawiają się tylko po wykonaniu JS. Kluczowe dla aplikacji SPA i PWA.
6. Crawl Comparison Pro — porównanie dwóch crawli w czasie (np. przed i po deployu) z wizualną diff-tabelą. Pokazuje dokładnie, które URL-e zmieniły status kodu, canonicala, noindex lub strukturę linków.
7. AI Overviews Presence Check — integracja z Serper.dev lub własnym dataset-em pokazuje, które URL-e z witryny są cytowane w AI Overviews dla śledzonych słów kluczowych.
8. Custom Extraction 3.0 — XPath + regex + CSS selectors + JSONPath w jednym polu, z podglądem wyniku w czasie rzeczywistym. Wreszcie można wyciągać dane ze Schema.org JSON-LD bez uruchamiania osobnych skryptów.
9. Looker Studio Connector — natywny konektor publikuje crawl do BigQuery lub bezpośrednio do Looker Studio, co pozwala tworzyć automatyczne dashboardy audytowe odświeżane po każdym cyklicznym crawl-u.

Jak Screaming Frog 2026 renderuje JavaScript i kiedy to wystarczy?

Renderowanie JavaScript to najbardziej niedoszacowana funkcja Screaming Frog — większość SEO-wców włącza ją tylko „na wszelki wypadek”, nie rozumiejąc, co dokładnie robi i dlaczego domyślna konfiguracja bywa za wolna lub za mało dokładna.

W SF 2026 silnik renderujący oparty na Chromium 124 domyślnie czeka 5 sekund po załadowaniu domu (DOMContentLoaded) przed wykonaniem zrzutu HTML. Dla większości stron to wystarczy, ale dla aplikacji Next.js z Server Components, Remix z deferred loaders albo sklepów Shopify z App Block-ami zalecam zwiększenie tego czasu do 8-10 sekund i włączenie opcji Wait for network idle.

Dla witryn SPA (np. zbudowanych na czystym Reactcie, Vue 3 SPA mode lub Angular) absolutnie konieczne jest włączenie renderingu JavaScript w Configuration → Spider → Rendering → JavaScript i jednoczesne skonfigurowanie User Agent na Googlebot Smartphone. Bez tego crawler odczyta tylko pustą powłokę HTML z komentarzem „This app requires JavaScript” i zaraportuje zero treści na tysiącach URL-i.

Ważny detal: Chromium 124 w SF domyślnie nie wykonuje Service Workerów. To oznacza, że jeśli Twoja witryna korzysta z caching-layeru w SW do serwowania offline-first HTML-a (typowe w PWA), crawler dostanie świeżą odpowiedź z serwera, a nie tę z cache. W większości przypadków to dobre zachowanie, ale dla PWA o złożonej strategii cache zalecam uruchomienie dodatkowego crawla z włączonym Service Worker execution w Configuration → Rendering → Advanced.

Przy dużych crawlach JavaScript-owych (powyżej 100 000 URL-i z renderingiem) używaj trybu Headless Chrome pool — SF 2026 uruchamia do 20 równoległych instancji Chromium zamiast jednej, co skraca crawl o 40-60%. Wymaga to co najmniej 32 GB RAM i szybkiego dysku NVMe.

Które integracje API w Screaming Frog 2026 dają największy ROI?

Największą wartość dają integracje, które eliminują konieczność ręcznego łączenia danych z różnych źródeł w Excelu. W SF 2026 mamy natywnie podłączone: Google Search Console, Google Analytics 4, PageSpeed Insights, Majestic, Ahrefs, Moz, OpenAI i — nowość — Serper.dev dla danych SERP oraz AI Overviews.

Mój default setup to GSC + GA4 + PSI + OpenAI. To wystarcza do 90% audytów. Integracje z Ahrefs lub Majestic włączam dopiero wtedy, gdy robię audyt link building-owy albo analizę backlinków dla konkretnego klastra stron.

Szczególnie silna jest integracja z GA4 — SF 2026 jako pierwszy crawler umożliwia zaciągnięcie danych z custom dimensions, co pozwala np. filtrować URL-e po typie użytkownika (logged-in vs guest) albo po kanale akwizycji. O tym, jak poprawnie skonfigurować custom dimensions w GA4, pisałem w osobnym materiale o GA4 custom dimensions dla SEO.

Integracja z OpenAI z kolei otwiera zupełnie nowe możliwości automatyzacji. W custom promptach można poprosić model o: klasyfikację intencji zapytania dla każdego URL-a, wykrywanie duplikacji semantycznej między tytułami, ocenę zgodności meta description z treścią strony albo generowanie propozycji rozbudowy H1 dla stron o niskim CTR. Z moich testów wynika, że użycie GPT-4o-mini (najtańszego modelu) kosztuje około 2 USD na crawl 10 000 URL-i, więc jest to bardzo opłacalne.

Jak zbudować kompletny audyt techniczny w Screaming Frog 2026 krok po kroku?

Poniżej dziewięcioetapowy framework audytu, który stosuję dla każdej nowej witryny. Całość trwa od 4 do 16 godzin w zależności od skali projektu (małe strony: 4-6h, sklepy 100k+ URL-i: 12-16h).

1. Discovery i konfiguracja (30-60 minut). Zanim uruchomisz crawl, wyciągnij z GSC listę top 500 URL-i po impresji, policz sitemap XML (ile URL-i zadeklarowanych), sprawdź robots.txt na sandboxie lub wayback machine pod kątem historii zmian i zweryfikuj, czy witryna ma aktywne noindex w meta albo X-Robots-Tag. Dopiero wtedy ustaw w SF: User Agent = Googlebot Smartphone, Rendering = JavaScript, Wait time = 5-8s, Max URLs = zgodnie z rozmiarem (dla sklepów zawsze 10x sitemap, żeby złapać parametry).
2. Crawl seed + sitemap (15 minut setup + czas crawla). Zawsze startuj crawl z podwójnym źródłem: domena główna + lista z sitemap XML (Mode → List). To pozwala wykryć osierocone URL-e (w sitemap, ale bez linków wewnętrznych) oraz nadmiarowe URL-e (indeksowane, ale nie w sitemap).
3. Analiza response codes (30 minut). Filtruj Response Codes → 4xx, 5xx, 3xx redirect chains. Dla każdej grupy wyciągnij TOP 20 przypadków i oznacz priorytet. Redirect chains dłuższe niż 2 hops to czerwona flaga — Google zatrzymuje się po 5 hopach.
4. Canonical + Index coverage (45 minut). Przepnij widok na Directives + Canonicals. Wyłap: noindex na stronach z ruchem, canonicale wskazujące na 404, canonical-loopy, strony self-referencing z parametrami.
5. JavaScript Rendering Diff (45 minut). Przeanalizuj różnice HTML przed i po renderze. Wszystkie linki, które pojawiają się tylko po JS, są ryzykiem — Googlebot renderuje JS z opóźnieniem nawet do kilku dni.
6. Core Web Vitals per URL type (30 minut). Zgrupuj URL-e po typie (produkt, kategoria, blog) i zobacz średnie LCP/INP/CLS dla każdej grupy. Jeśli jedna grupa odstaje, problem jest architektoniczny (np. ciężkie zdjęcia produktów bez lazy loadingu).
7. Internal linking (45 minut). Crawl Analysis → Link Score. Wyłap TOP 50 stron z najniższym Link Score i zobacz, czy są to strony strategiczne. Często odkrywa się, że kluczowe strony landingowe są zepchnięte na głębokość 6+.
8. Schema + E-E-A-T signals (30 minut). Użyj Custom Extraction do wyciągnięcia JSON-LD ze wszystkich stron. Sprawdź: obecność Article/Product/FAQPage, poprawność Author + Publisher, datePublished i dateModified.
9. AI Overviews Presence + AI Readability (45 minut). Ostatni etap: nowy raport SF 2026 pokazuje, które URL-e są cytowane w AIO i jaki mają AI Readability Score. To wprost mapa priorytetów pod content optimization w kolejnym kwartale.

Jak Screaming Frog 2026 wypada w tabeli: funkcje vs use cases?

Poniższa tabela mapuje najważniejsze funkcje SF 2026 na konkretne use case-y audytowe. Używam jej jako szybkiej ściągi przy wycenie audytu dla nowego klienta — każda kombinacja „skala + typ witryny” wymaga innego zestawu modułów.

Funkcja SF 2026	Główny use case	Typ witryny	Oszczędność czasu
JavaScript Rendering Diff	Audyt aplikacji SPA i Next.js	SaaS, startupy, PWA	3-4h/audyt
Native GSC integration v2	Index coverage + real query mapping	Każda witryna z GSC	1-2h/audyt
Segment Mode	Crawl ograniczony do sekcji	E-commerce 100k+ URL	2-3h/audyt
OpenAI Custom Prompts	Automatyczna ocena title/H1/meta	Portale contentowe	4-6h/audyt
PSI Lab + Field data	CWV per URL group	Sklepy, portale	1h/audyt
Looker Studio Connector	Dashboard audytowy dla klienta	Projekty retainerowe	2-3h/miesiąc
AI Readability Report	Optymalizacja pod AI Overviews	Portale, blogi eksperckie	2h/audyt
Custom Extraction 3.0	Scraping danych ze Schema i HTML	Porównywarki, agregatory	3-5h/projekt
Crawl Comparison Pro	Pre/post deploy audit	Projekty migracyjne	4-6h/migracja
Serper.dev integration	SERP visibility + AIO tracking	Portale informacyjne	1-2h/audyt

Warto zauważyć, że największy ROI daje kombinacja GSC + PSI + OpenAI — to trzy integracje, które zmieniają SF z crawlera w narzędzie do analizy strategicznej. Jeśli porównujesz SF z alternatywami, warto przeczytać moje zestawienie Ahrefs vs Semrush vs Sistrix 2026, gdzie pokazuję, jak te narzędzia uzupełniają audyt techniczny o warstwę link building-ową i keyword research.

Jakie błędy najczęściej popełniają SEO-wcy podczas crawla w Screaming Frog?

Przez ostatnie trzy lata audytując strony z warsztatem SF obserwuję, że te same błędy powtarzają się u 80% specjalistów. Poniżej najczęstsze, które realnie psują jakość audytu i prowadzą do błędnych rekomendacji.

• Crawl bez włączonego JavaScript Rendering na witrynach JS-heavy. Skutek: crawler raportuje zero treści, zero linków wewnętrznych, same meta description puste — i SEO-wiec wysyła panu klientowi raport, że „strona ma 3000 stron bez contentu”. W rzeczywistości ma 3000 stron doskonale wyrenderowanych, tylko SF tego nie zobaczył. Fix: Configuration → Spider → Rendering → JavaScript, User Agent Googlebot Smartphone.
• Brak wykluczenia parametrów URL. Sklep z filtrami facetowymi (kolor, rozmiar, cena) generuje miliony kombinacji URL-i, z których 95% ma canonical do wersji bazowej. SF bez wykluczenia parametrów marnuje zasoby i zafałszowuje liczby. Fix: Configuration → URL Rewriting → Parameters i wykluczenie gdzie nie ma canonical self-referencing.
• Uruchamianie crawla z User Agentem Screaming Frog SEO Spider. Wiele witryn blokuje lub throttle-uje tego UA w WAF (Cloudflare, AWS WAF, Akamai). Fix: zawsze Googlebot Smartphone jako default, a w przypadku blokady — skontaktuj się z klientem, żeby dodał IP crawlera do allowlist.
• Ignorowanie Crawl Analysis. SF po crawlu ma osobny etap Crawl Analysis (musisz go ręcznie uruchomić z menu), który liczy Link Score, PageRank wewnętrzny i priorytety. Bez tego nie masz pełnego obrazu siły strony w architekturze wewnętrznej.
• Brak podpięcia GSC przed crawlem. Jeśli podepniesz GSC po crawlu, nie dostaniesz danych w ekspansji per URL. Fix: zawsze podłącz GSC w kroku setupu, przed Start.
• Zbyt mała wartość Max URLs dla e-commerce. Domyślne 5 mln URL-i wystarczy dla 99% stron, ale dla marketplace’ów i porównywarek trzeba ustawić 20-50 mln. W przeciwnym razie SF zatrzymuje crawl w połowie i dostajesz niekompletne dane.
• Brak backupu crawla przed deployem. Przed każdą migracją lub dużym deployem zawsze zapisuj crawl z produkcji jako baseline (File → Save Crawl). Potem porównasz go z crawl-em po deployu przez Crawl Comparison Pro.

Czym zastąpić Screaming Frog 2026 w scenariuszach, w których nie sprawdza się najlepiej?

Pomimo dominacji w niszy audytu technicznego, SF nie jest narzędziem uniwersalnym. Są trzy scenariusze, w których rozważam alternatywy: ograniczony budżet (licencja SF to około 299 GBP rocznie), ekstremalna skala (powyżej 5 milionów URL-i) i wymagania wizualizacji raportu end-clientowego.

Dla małych firm i freelancerów świetnie sprawdza się Sitebulb — jednorazowa opłata, lepsze wizualizacje, automatyczne generowanie raportów w PDF. Ma słabszy rendering JS i brak niektórych zaawansowanych custom extractions, ale dla stron do 50k URL-i różnica jest kosmetyczna.

Dla korporacji i agencji pracujących z witrynami powyżej miliona URL-i rekomenduję JetOctopus lub FandangoSEO — oba narzędzia mają architekturę cloud-native, crawlują milionowe strony w ciągu godzin (a nie dni jak SF na lokalnej maszynie), oferują dashboard dla klienta i integrację z BigQuery out of the box.

Dla audytów ad-hoc małych stron bez potrzeby integracji istnieje też darmowy Screaming Frog (limit 500 URL) oraz SEO Pro Extension (Chrome, desktop-only). Oba są w sam raz na szybki check-up landing page-a.

Ciekawym kierunkiem na 2026 rok są też narzędzia łączące crawler z automatyzacją. Jeśli crawlujesz cyklicznie te same strony (np. monitoring konkurencji), warto zbudować pipeline w n8n lub Make z wywołaniem SF w trybie CLI. Więcej o tym podejściu napisałem w materiale o Pythonie w automatyzacji SEO.

Jak Screaming Frog 2026 radzi sobie z AI Overviews i treściami pod LLM-y?

Najciekawsza nowość 2026 roku z perspektywy AIO (AI Optimization) to dedykowany AI Readability Report. Jest to zestaw 12 metryk, które SF wylicza dla każdej strony na podstawie jej HTML-a po renderze:

• Obecność TL;DR lub executive summary na początku artykułu (0/1).
• Ratio list (ul/ol) do akapitów (optimum: 1 lista na 4-6 akapitów).
• Ratio tabel do całości contentu (rekomendowane 1-3 tabele na artykuł pillar).
• Głębokość struktury H-tagów (H2 i H3 preferowane nad płaską strukturą).
• Obecność FAQPage schema i minimum 5 pytań FAQ.
• Obecność Author schema z sameAs do LinkedIn/ORCID.
• Długość pierwszego akapitu (optimum: 40-80 słów).
• Gęstość linków wewnętrznych (2-5 na 1000 słów).
• Liczba named entities (organizacje, osoby, daty) — im więcej, tym lepiej dla ekstraktorów LLM.
• Procent HTML-a, który jest „czysty” (bez inline stylów i nested div-ów głębiej niż 5).
• Obecność datePublished i dateModified w JSON-LD.
• Obecność mainEntityOfPage i breadcrumbs.

Raport można eksportować do CSV i użyć jako baseline do wyliczenia AI Readability Score per URL. Strony z wynikiem poniżej 6/10 to kandydaci do refactoring-u treści. Z moich obserwacji — strony z score 8+ pojawiają się w cytowaniach AIO 3-4x częściej niż te z score 4-5.

Dokumentacja tego raportu wraz z metodologią jest dostępna na oficjalnej stronie Screaming Frog w sekcji changelog dla wersji 21 (wydanie styczeń 2026). Pełny user guide SF 2026 zawiera też szczegółowe instrukcje konfiguracji AI Readability scoringu pod branżę klienta.

Jak wykorzystać Screaming Frog 2026 w projektach migracyjnych bez utraty ruchu?

Migracja witryny to moment największego ryzyka w SEO — jeden źle skonfigurowany redirect potrafi zniwelować trzy lata budowania widoczności. Screaming Frog 2026 z Crawl Comparison Pro jest dziś prawdopodobnie najważniejszym narzędziem w przygotowaniu i kontroli migracji, bo pozwala porównać stan przed i po w jednej, spójnej tabeli.

Mój proces migracyjny zawsze wygląda tak: na dwa tygodnie przed deployem robię pełny baseline crawl środowiska produkcyjnego. Zapisuję go jako plik .seospider w dedykowanym katalogu klienta. Następnie tydzień przed deployem crawluję środowisko staging z tą samą konfiguracją (ten sam UA, ta sama głębokość, te same integracje). Porównuję oba crawle przez Mode → Compare i eksportuję wszystkie rozbieżności — brakujące URL-e, zmienione tytuły, zmienione canonicale, zmienione statusy kodu.

Na bazie tej diff-tabeli tworzę redirect map w Google Sheets. Dla każdego URL-a, który zniknie, przypisuję nowy URL docelowy. Tę mapę następnie konwertuję na nginx rules lub Apache rewrites i przekazuję developerom. Po deployu robię trzeci crawl (produkcja po migracji) i porównuję go z baseline-em. W 90% przypadków wyłapuję 5-15 URL-i, które zostały pominięte w redirect mapie — i które bez SF byłyby stracone.

Kluczowy tip: w trakcie crawla staging zawsze ustawiaj Custom robots.txt w Configuration → robots.txt, żeby zasymulować reguły produkcyjne. Staging często ma otwarte robots.txt, które nie odzwierciedla reguł produkcyjnych — bez tego symulacja jest niekompletna.

Jak zintegrować Screaming Frog 2026 z pipelinami automatyzacji w agencji?

Dla agencji obsługujących 20+ klientów kluczowe jest przeniesienie crawli z interaktywnego trybu GUI do cyklicznego trybu CLI. Screaming Frog 2026 ma pełnoprawny interfejs CLI, który pozwala uruchamiać crawle z linii poleceń, zapisywać wyniki w określonym formacie i integrować z cron-jobami, n8n, Make czy Temporal.

Typowy pipeline w agencji wygląda tak: każdego poniedziałku o 3 rano uruchamia się n8n workflow, który dla każdego z 20 klientów wywołuje SF w trybie headless z dedykowaną konfiguracją (plik .seospiderconfig). Wynik zapisuje się do BigQuery przez natywny konektor, po czym dashboard w Looker Studio odświeża się z nowymi danymi. Klient dostaje email z linkiem do dashboardu. Cały proces trwa 4-6 godzin dla 20 stron i nie wymaga ingerencji człowieka.

Konfiguracja CLI jest prosta: komenda „ScreamingFrogSEOSpiderCli –crawl [URL] –config [path-to-config] –export-format csv –output-folder [path]” uruchamia crawl i zapisuje wynik. W pliku konfiguracyjnym definiujesz wszystko: integracje GSC/GA4/PSI, custom extractions, user agent, max URL, rendering settings.

Jak czytać raport Crawl Analysis i co z nim zrobić?

Crawl Analysis to osobny moduł, który trzeba ręcznie uruchomić po zakończeniu crawla (menu Crawl Analysis → Start). Moduł ten przelicza wszystkie metryki dependentne od struktury linków wewnętrznych: Link Score, PageRank wewnętrzny, głębokość per URL, ilość linków wchodzących i wychodzących na każdym URL-u.

Najważniejsza jest zakładka Crawl Analysis → Sitemaps, która pokazuje niespójności między URL-ami w sitemap a tymi wykrytymi w crawl-u. Typowe problemy: URL-e w sitemap z redirect (302/301), URL-e w sitemap z noindex, URL-e w sitemap zwracające 404, URL-e w crawl-u, których nie ma w sitemap.

Drugą kluczową zakładką jest Crawl Analysis → Link Metrics. Tu znajdziesz URL-e z bardzo niskim Link Score (sortuj rosnąco), które jednocześnie mają wysokie impresje w GSC — to są strony „zapomniane” przez architekturę wewnętrzną, ale widoczne dla Googlebota. Dodanie linków wewnętrznych do takich stron to najniższy hanging fruit w optymalizacji internal linking.

Trzecia zakładka, często pomijana, to Crawl Analysis → Inlinks Distribution. Pokazuje histogram rozkładu liczby linków wchodzących per URL. Zdrowa witryna ma rozkład logarytmiczny (kilka stron z bardzo dużą liczbą linków wewnętrznych, potem długi ogon). Jeśli widzisz rozkład płaski albo bimodalny — to znak, że architektura linkowania wymaga refactoringu.

Jak przygotować deliverable z audytu SF dla klienta nietechnicznego?

Raw eksport CSV z SF to ostatnia rzecz, którą chcesz wysłać prezesowi firmy klienta. Dobry deliverable ma trzy warstwy: executive summary (1-2 strony), priorytety z rekomendacjami (5-10 stron) i załącznik techniczny (arkusz Google Sheets z danymi szczegółowymi).

Executive summary powinien zawierać: stan aktualny (liczba zindeksowanych stron vs całość, najważniejsze problemy, ocena ogólna w skali 1-10), trzy kluczowe rekomendacje do wdrożenia w ciągu 30 dni, szacowany impact biznesowy (wzrost ruchu o X% po wdrożeniu rekomendacji). Tę sekcję czyta prezes.

Sekcja priorytetów to praca dla zespołu marketingu i developerów. Każdy priorytet ma: problem, dlaczego jest problemem (business impact), jak go naprawić (konkretne instrukcje dla developera), szacowany czas wdrożenia, szacowany impact. Używam tu zawsze tabeli, bo to najczytelniejszy format dla miksu technical + business.

Załącznik techniczny to pełne dane z SF w Google Sheets, pogrupowane w zakładki: Errors 4xx/5xx, Redirect Chains, Canonical Issues, JS Rendering Issues, Core Web Vitals. Każda zakładka ma filtr i możliwość sortowania.

Czy Screaming Frog 2026 jest bezpieczny pod kątem RODO i danych klienta?

To pytanie pojawia się coraz częściej, szczególnie od klientów enterprise. Odpowiedź: SF jest lokalną aplikacją desktopową, która nie wysyła danych crawla na żadne zewnętrzne serwery (poza integracjami, które sam włączasz — GSC, GA4, OpenAI). Wszystkie dane zostają na Twoim komputerze, w plikach .seospider lub w lokalnej bazie SQLite (tryb Database Storage).

Jeśli pracujesz z klientem enterprise, który ma restrykcyjne wymagania compliance, zwracaj uwagę na: 1) integrację OpenAI — dane są wysyłane do API OpenAI i mogą być używane do trenowania modeli (chyba że masz opt-out na poziomie konta OpenAI), 2) storage plików crawla — często zawierają dane produktowe, ceny, szczegóły klientów, 3) User Agent — crawl z UA „Screaming Frog” może wyglądać podejrzanie w logach WAF i wymaga koordynacji z zespołem bezpieczeństwa klienta.

Best practice: zawsze podpisz z klientem umowę NDA przed crawlem i ustal, gdzie będą przechowywane pliki crawla (u Ciebie lokalnie, na Google Drive klienta, czy na SharePoint agencji). Używaj szyfrowania dysku (FileVault, BitLocker) jako minimum.

Najczęstsze błędy przy interpretacji raportów Screaming Frog

Sam crawl to dopiero połowa pracy — największe straty powstają na etapie interpretacji. Poniżej pięć najczęstszych błędów, które widzę w deliverable-ach od konkurencji:

1. Traktowanie „Missing meta description” jako problemu priorytetowego. W 2026 roku Google w ponad 70% przypadków przepisuje meta description z treści strony. Brakujące meta to niski priorytet, jeśli witryna ma zdrowy content. Prawdziwy priorytet to niespójne meta description (ten sam opis na 100 różnych podstronach).
2. Raportowanie wszystkich H1 > 60 znaków jako problem. Długość H1 jest irrelewantna dla Google od 2020 roku. Co jest istotne: brak H1, duplikaty H1 na różnych URL-ach, H1 niespójny z title tagiem.
3. Ignorowanie redirect chains poniżej 3 hops. Nawet 2 hops to redirect chain — jeśli masz ich 10 000, crawl budget Google się marnuje. Priorytetyzuj zawsze.
4. Niewłaściwa interpretacja „Orphan URLs”. Orphan = w sitemap, ale brak linków wewnętrznych. To nie jest błąd — to decyzja architektoniczna. Część stron jest celowo osierocona (np. stare landing page-e kampanijne). Zawsze pytaj klienta przed oznaczeniem jako problem.
5. Przecenianie Link Score. Link Score w SF to heurystyka oparta o PageRank wewnętrzny. Nie jest to dokładna predykcja rankingu — to wskaźnik siły strony w architekturze. Używaj do porównywania grup stron, nie do pojedynczych przypadków.

Często zadawane pytania (FAQ)

Ile kosztuje licencja Screaming Frog 2026 i czy warto?

Licencja roczna SF SEO Spider to 299 GBP (około 1500 PLN). Dla specjalisty SEO freelancera audytującego 2+ strony miesięcznie inwestycja zwraca się po 3-4 miesiącach. Agencje zawsze kupują licencje multi-user (zniżki przy 5+ stanowiskach). W porównaniu do JetOctopus lub FandangoSEO (1500-5000 USD rocznie) SF jest 5-10x tańszy.

Czy Screaming Frog 2026 działa na macOS z procesorem M3/M4?

Tak, od wersji 20.5 SF jest natywnie skompilowany dla Apple Silicon (ARM64). Na M3 Max crawl 500k URL-i z renderowaniem JS trwa około 2-3 godzin. Na M4 Pro — 1.5-2 godziny. To około 30% szybciej niż na Intel i9 z tego samego pokolenia.

Jak skonfigurować Screaming Frog do crawla witryny chronionej Cloudflare?

Cloudflare blokuje SF-owy User Agent domyślnie. Rozwiązania: 1) zmień UA na Googlebot Smartphone (Configuration → User-Agent), 2) poproś klienta o dodanie Twojego publicznego IP do Cloudflare allowlist, 3) w ostateczności — użyj Cloudflare Zero Trust service token. Opcja 2 jest najczystsza i najszybsza.

Co jest lepsze: Screaming Frog SEO Spider czy Sitebulb?

SF dla zaawansowanych audytów, dużych witryn i custom extractions. Sitebulb dla raportów end-clientowych, mniejszych stron i zespołów juniorskich (lepsza UX, automatyczne rekomendacje). Dla większości profesjonalnych agencji odpowiedź brzmi: oba. SF do crawla i eksportu danych, Sitebulb do wizualizacji raportu dla klienta końcowego.

Ile RAM potrzeba do crawla miliona URL-i?

Minimum 32 GB RAM, rekomendowane 64 GB, optymalnie 128 GB. SF 2026 domyślnie alokuje 4 GB pamięci JVM (Configuration → Memory Allocation) — dla milionowych crawli trzeba podnieść do co najmniej 32 GB. Dodatkowo dysk NVMe o prędkości odczytu 3000+ MB/s jest wymagany, jeśli używasz trybu Database Storage.

Czy Screaming Frog zastąpi GSC w audycie?

Nie. SF pokazuje stan witryny z perspektywy crawlera, GSC — z perspektywy Googlebota i rzeczywistych wyników wyszukiwania. Te dwa narzędzia są komplementarne. SF + GSC + GA4 to minimum dla kompletnego audytu. O tym, jak łączyć dane z GSC i GA4, pisałem w materiale o connected insights GA4 + GSC.

Czy SF 2026 wykrywa problemy z Core Web Vitals automatycznie?

Częściowo. Przez integrację z PSI (Lab data) SF zbiera wartości LCP, INP, CLS dla każdego URL-a. Natomiast SF nie wykonuje własnych pomiarów Lighthouse — pobiera je z API PSI. Dla field data (CrUX) SF od wersji 21 zaciąga 28-dniowe dane terenowe, co jest znacznie bardziej reprezentatywne niż lab data.

Jak często robić pełny crawl witryny w Screaming Frog?

Dla stron statycznych o niskiej częstotliwości publikacji — raz na kwartał. Dla portali z nowymi treściami codziennie — raz w miesiącu. Dla dużych sklepów e-commerce — co 2 tygodnie crawl inkrementalny (tylko nowe URL-e) i raz w miesiącu pełny. Zawsze dodatkowo: crawl przed i po każdym deployu produkcyjnym oraz przed każdą migracją.

Co dalej ze Screaming Frog i audytami technicznymi?

Screaming Frog 2026 to jasny sygnał kierunku, w którym zmierza cały segment narzędzi audytowych: od prostego crawlera do pełnoprawnej platformy łączącej dane crawlera, Google Analytics, Search Console, PageSpeed, modeli językowych i SERP-ów. Przyszłość to integracja i automatyzacja — crawler staje się silnikiem, a warstwa prezentacji, interpretacji i rekomendacji coraz częściej jest generowana przez LLM-y lub dedykowane dashboardy.

Z praktycznego punktu widzenia, jeśli audytujesz witryny zawodowo, powinieneś w 2026 roku: 1) zaktualizować SF do najnowszej wersji (minimum 21), 2) podłączyć integracje GSC + GA4 + PSI + OpenAI, 3) wdrożyć Segment Mode dla klientów z witrynami powyżej 100k URL-i, 4) eksportować dane do Looker Studio i budować dashboardy, 5) używać AI Readability Report jako stałego KPI dla contentu publikowanego na witrynach klienckich.

W kolejnych kwartałach spodziewam się, że SF wypuści: natywny moduł log file analyzer zintegrowany z głównym UI (obecnie jest osobna aplikacja), wsparcie dla custom LLM-ów (lokalnych modeli przez Ollama), głębszą integrację z narzędziami link buildingowymi oraz tryb kolaboracyjny (shared crawls dla zespołów). Jeśli pracujesz w agencji lub jako in-house SEO, warto już teraz zacząć adaptację tego stacka — konkurencja, która tego nie zrobi, zostanie w tyle o kwartał lub dwa.

Pamiętaj: crawler to tylko narzędzie. Jakość audytu technicznego zależy od tego, czy umiesz czytać dane, priorytetyzować problemy i komunikować rekomendacje w sposób zrozumiały dla developerów i decydentów biznesowych. Screaming Frog 2026 daje Ci najlepszy możliwy dataset — ale to od Twojego doświadczenia zależy, czy zamienisz go w realną poprawę rankingu, ruchu organicznego i cytowań w AI Overviews.