ChatGPT i Screaming Frog w SEO: jak połączyć API z crawlerem

Crawler od dawna umie zbierać dane. Model językowy od dawna umie je przetwarzać. Połączenie tych dwóch rzeczy w jednym procesie brzmi jak oczywisty krok, ale w praktyce mało kto robi to poprawnie. Większość osób kończy na jednorazowym teście na kilku adresach URL i wraca do ręcznej pracy, bo konfiguracja wygląda na skomplikowaną. Nie jest, jeśli rozumie się, co się dzieje pod maską.

Screaming Frog od pewnej wersji pozwala uruchamiać własny kod JavaScript w trakcie crawlowania strony. Ten kod może odpytać dowolne zewnętrzne API, w tym API OpenAI, wysłać mu fragment treści i zapisać odpowiedź jako kolejną kolumnę w raporcie. To wszystko. Cała reszta to konfiguracja i dyscyplina w promptach.

Co się dzieje technicznie, gdy crawler pyta model

Screaming Frog w standardowym trybie pobiera kod HTML strony, parsuje go i wyciąga dane: tagi title, nagłówki, statusy odpowiedzi, linki wewnętrzne. Żeby dołożyć do tego zapytanie do modelu, crawler musi mieć włączone renderowanie JavaScript, bo mechanizm custom extraction bazuje na silniku przeglądarki wbudowanym w narzędzie. Bez tego kroku edytor customowego kodu nie ma gdzie się wykonać.

Po włączeniu renderowania otwiera się edytor niestandardowego JS. To zwykły fragment kodu, który crawler odpala dla każdego przetwarzanego adresu URL. W tym miejscu wywołuje się zapytanie sieciowe do endpointu OpenAI, przekazując klucz API, wybrany model językowy, parametr temperatury oraz treść promptu zbudowaną z danych pobranych ze strony, np. z nagłówka h1 i pierwszych akapitów treści.

Kluczowe jest to, że każdy request do API to osobne zapytanie sieciowe i osobny koszt liczony w tokenach. Crawler nie wie nic o limitach konta OpenAI, więc jeśli puścisz to na kilka tysięcy adresów URL bez wcześniejszego testu, dowiesz się o problemie dopiero po fakcie, patrząc na zużyte środki w panelu rozliczeniowym.

Model, temperatura i długość odpowiedzi

Wybór modelu ma znaczenie dla kosztu i jakości. Tańszy model wystarczy do prostych zadań typu generowanie meta title, droższy model ma sens przy bardziej złożonych zadaniach, np. ocenie spójności tematycznej treści. Temperatura odpowiada za losowość odpowiedzi. Niska temperatura daje przewidywalne, powtarzalne wyniki, wysoka temperatura daje więcej wariacji, ale też więcej ryzyka, że model odjedzie od faktów zawartych na stronie.

Warto też ograniczyć długość odpowiedzi parametrem max tokens. Bez tego model potrafi wygenerować akapit tam, gdzie potrzebujesz jednego zdania, a to oznacza dłuższy czas przetwarzania i wyższy koszt przy dużej skali.

Co realnie da się zautomatyzować

To nie jest narzędzie do pisania całej strategii SEO za ciebie. To narzędzie do masowego przetwarzania powtarzalnych, drobnych zadań, które przy ręcznej robocie zajmują tygodnie. Kilka scenariuszy, które mają sens produkcyjny:

• Generowanie propozycji meta title i meta description na podstawie treści strony i nagłówka h1, z jasną instrukcją co do długości znakowej i miejsca nazwy firmy w tagu.
• Ocena spójności między nagłówkiem h1 a resztą treści, przydatna przy audycie dużego serwisu, gdzie ręczne przejrzenie każdej podstrony jest niepraktyczne.
• Wstępna kategoryzacja tematyczna adresów URL na podstawie treści, przydatna przy planowaniu architektury linkowania wewnętrznego.
• Wykrywanie tekstów, które brzmią identycznie lub bardzo podobnie na wielu podstronach, jako sygnał ostrzegawczy przed kanibalizacją słów kluczowych.
• Generowanie roboczych opisów alt do obrazów na podstawie kontekstu strony, jako punkt startowy do dalszej korekty.

Wspólny mianownik tych zastosowań: model produkuje szkic, człowiek go sprawdza. Nikt nie powinien puszczać wygenerowanych meta description bezpośrednio do CMS bez przejrzenia. Model nie zna intencji biznesowej, nie wie, że akurat ta kategoria ma inny priorytet niż wynika z samej treści.

Konfiguracja krok po kroku

Zanim uruchomisz crawl na całym serwisie, przejdź przez konfigurację na pojedynczym adresie URL. To oszczędza czas i pieniądze.

1. Włącz renderowanie JavaScript w konfiguracji crawlera, bo bez tego edytor customowego kodu nie zadziała.
2. Otwórz sekcję custom JavaScript i wybierz pusty szablon albo zacznij od gotowego przykładu, jeśli narzędzie go oferuje.
3. Wklej klucz API wygenerowany w panelu OpenAI. Klucz działa dopóki na koncie są dostępne środki, więc warto ustawić limit wydatków w panelu rozliczeniowym zanim zaczniesz testy.
4. Zbuduj prompt jako zmienną tekstową, łącząc stały fragment instrukcji z dynamicznie pobraną treścią strony, np. tekstem z nagłówka h1 i pierwszym akapitem.
5. Ustaw model, temperaturę i limit długości odpowiedzi zgodnie z zadaniem, jakie chcesz wykonać.
6. Przetestuj cały mechanizm na jednym adresie URL wklejonym ręcznie w panelu testowym crawlera. Sprawdź odpowiedź, popraw prompt, jeśli wynik odbiega od oczekiwań.
7. Dopiero po pozytywnym teście uruchom crawl na docelowej liście adresów, najlepiej zaczynając od małej próbki, np. dwudziestu podstron, żeby ocenić jakość i koszt w skali.

Jedna rzecz, o której często się zapomina: crawler blokuje zmianę konfiguracji renderowania po rozpoczęciu crawlowania. Jeśli chcesz coś poprawić w promptcie w trakcie, musisz zatrzymać proces, zmienić kod i zacząć od nowa albo dokończyć na pozostałych adresach osobnym uruchomieniem.

Gdzie to się psuje najczęściej

Pierwszy problem to dane wysyłane na zewnątrz. Treść strony, w tym czasem dane osobowe klientów widoczne w opiniach czy komentarzach, trafia do zewnętrznego API. Zanim puścisz taki proces na serwisie z danymi wrażliwymi, sprawdź, jakie dane faktycznie pobiera twój prompt i czy nie warto ich wcześniej odfiltrować.

Drugi problem to halucynacje. Model czasem dopisuje fakty, których nie ma w treści źródłowej, zwłaszcza przy wyższej temperaturze albo zbyt ogólnym prompcie. Wygenerowany meta title może sugerować coś, czego produkt nie oferuje. To błąd, który trudno wyłapać przy przeglądaniu tysięcy wierszy w arkuszu, jeśli nie masz dodatkowego etapu weryfikacji.

Trzeci problem to koszt przy skali. Pojedyncze zapytanie do API kosztuje niewiele, ale przy serwisie liczącym kilkanaście tysięcy adresów URL i kilku zapytaniach na podstronę suma robi się odczuwalna. Warto liczyć koszt na próbce, zanim zdecydujesz się na pełny crawl.

Czwarty problem to rate limity API. Zbyt szybkie wysyłanie zapytań kończy się błędami i pustymi wierszami w raporcie. Trzeba dodać opóźnienie między requestami albo ograniczyć liczbę wątków crawlera pracujących równolegle.

Kiedy to nie ma sensu i jaki budżet jest realny

Dla serwisu liczącego kilkadziesiąt podstron ta cała konfiguracja nie ma sensu. Szybciej i taniej wyjdzie ręczne przejrzenie treści przez człowieka, bo czas poświęcony na budowę i test promptu przewyższy czas zaoszczędzony na automatyzacji. Ten mechanizm zaczyna się opłacać dopiero przy serwisach liczących co najmniej kilkaset unikalnych podstron z powtarzalną strukturą, np. duży katalog produktowy albo serwis z rozbudowaną bazą artykułów.

Realny budżet trzeba liczyć dwutorowo: koszt tokenów API, który zależy od liczby przetwarzanych adresów i długości promptów, oraz czas pracy człowieka nad konfiguracją i weryfikacją wyników. Sama konfiguracja to zwykle kilka godzin pracy specjalisty, który rozumie zarówno strukturę promptów, jak i logikę crawlowania. Koszt tokenów przy typowym zadaniu, np. generowaniu meta description dla tysiąca podstron, jest zwykle niewielki w porównaniu z kosztem czasu poświęconego na weryfikację wyników. To właśnie weryfikacja, nie generowanie, pochłania najwięcej godzin w tym procesie.

Jeśli w firmie nie ma nikogo, kto rozumie zarówno logikę SEO, jak i podstawy pracy z API, lepiej zlecić to jednorazowo specjaliście niż uczyć się na produkcyjnym serwisie. Błędny prompt puszczony na cały katalog produktowy potrafi nadpisać dziesiątki poprawnych meta description tekstem, który trzeba potem ręcznie cofać.

Jak wpleść to w stały proces SEO

Jednorazowy crawl z podpiętym API to ciekawostka. Wartość pojawia się, gdy taki mechanizm staje się elementem cyklicznego audytu. Przykładowo: co kwartał crawler sprawdza nowe podstrony dodane do serwisu, model ocenia spójność nagłówka z treścią i flaguje adresy URL wymagające ręcznej korekty. Zamiast przeglądać cały serwis od nowa, zespół dostaje gotową listę priorytetów.

Podobnie działa to przy kontroli jakości treści tworzonej masowo, np. opisów kategorii w sklepie internetowym. Model porównuje treść z listą wymaganych fraz i sygnalizuje podstrony, gdzie fraza kluczowa w ogóle się nie pojawia albo pojawia się tylko raz w nienaturalnym miejscu. To wciąż wymaga człowieka do finalnej decyzji, ale skraca czas przeszukiwania z dni do godzin.

Warto też pamiętać, że wynik takiej automatyzacji jest tak dobry, jak prompt, który go generuje. Ogólny prompt typu napisz lepszy title da przeciętne, generyczne odpowiedzi. Prompt z jasnymi zasadami: limit znaków, obowiązkowa fraza kluczowa, ton komunikacji, miejsce nazwy marki, da odpowiedzi dużo bliższe temu, czego faktycznie potrzebujesz. Czas zainwestowany w dopracowanie promptu zwraca się przy każdym kolejnym uruchomieniu.

FAQ

Czy trzeba znać programowanie, żeby to skonfigurować?

Podstawowa znajomość JavaScript pomaga, ale nie jest wymagana na poziomie eksperckim. Wystarczy umieć czytać prosty kod, podmieniać zmienne i rozumieć, gdzie wkleić klucz API oraz treść promptu. Trudniejsza część to nie sam kod, tylko logika promptu i interpretacja wyników.

Czy dane ze strony są bezpieczne, gdy trafiają do API OpenAI?

Zależy od tego, co dokładnie wysyłasz w prompcie. Jeśli prompt zawiera tylko publiczną treść strony, ryzyko jest niskie. Jeśli treść zawiera dane osobowe, np. komentarze użytkowników z ich imionami i adresami e-mail, warto to wcześniej odfiltrować albo w ogóle nie przetwarzać takich podstron w tym mechanizmie.

Ile kosztuje przetworzenie dużego serwisu przez API?

To zależy od liczby adresów URL, długości promptu, długości odpowiedzi i wybranego modelu. Najlepiej policzyć koszt na próbce kilkudziesięciu podstron i pomnożyć przez skalę docelową, zamiast zgadywać z góry.

Czy taki proces zastąpi copywritera lub specjalistę SEO?

Nie. Zastępuje część powtarzalnej, mechanicznej pracy, np. pierwszą wersję meta description albo wstępną kategoryzację treści. Decyzje strategiczne, ocenę intencji biznesowej i finalną korektę nadal musi wykonać człowiek.