Narzędzia AI w SEO: mój zestaw i testy, które go ukształtowały

Mój zestaw narzędzi AI w SEO to modele językowe, płatne dane o wynikach Google, program do skanowania serwisów i własne skrypty. Model dobrze porządkuje dane, opisuje je i pisze kod. Wynik z jednego zrzutu wyników albo z jednej odpowiedzi modelu bywa jednak przypadkowy. Dlatego pokazuję testy, które zmieniły sposób, w jaki korzystam z tych narzędzi. Nie układam rankingu od 1 do 10, bo nie porównałem tych narzędzi obok siebie na tych samych danych.

Co AI robi w SEO dobrze, a czego nie?

Model językowy dobrze czyta, porządkuje i pisze, ale źle liczy z pamięci i nie widzi danych, których mu nie dasz. 26 i 27 września 2026 sprawdziłem modele językowe na 17 typach zadań SEO, każdy na poziomie łatwym i trudnym. Część typów zbudowałem na podstawie 103 ogłoszeń o pracę dla specjalistów SEO. Ogłoszenia najczęściej wymieniały audyt techniczny, raportowanie i analizę danych. Z narzędzi najczęściej wymieniały Search Console, Google Analytics 4 (GA4), Ahrefs, Semrush i Screaming Frog.

Najmocniejsze modele miały prawie 100% w niemal każdym typie zadań, więc różnice pokazały dopiero słabsze modele. Do czołówki należały między innymi Claude Opus 5.5, Fable 5.1, Codex i Gemini 3.1 Pro. Przy liczeniu z pliku na trudnym poziomie Claude Haiku 4.5 dostał 2 z 10 punktów. Gemini 3.8 Flash z niskim poziomem rozumowania dostał 1 z 10, a lokalna Gemma 4 12B 0 z 10. W zadaniach, w których model mógł policzyć dane skryptem w Pythonie, wszystkie badane modele w chmurze dostały komplet punktów. Także najsłabsze z nich dostały komplet. Dane w tych zadaniach to eksporty ze Screaming Frog, 45 tys. zdarzeń GA4 i log serwera ze 160 tys. linii. Dlatego liczby w mojej pracy liczy skrypt, który model pisze i uruchamia.

Tekst po polsku oceniały na ślepo dwa modele i tu różnice były duże. Oceniający nie wiedzieli, który model napisał tekst. Skala miała 5 stopni, a 5 oznaczało tekst gotowy do wysłania klientowi bez poprawek. Tylko Claude Opus 5.5 i Claude Sonnet 5 dostały 5 na trudnym zadaniu pisarskim. Gemini 3.1 Pro dostał 2, bo zmyślił „wczorajszą rozmowę” z odbiorcą. Oceniający Claude Opus był surowszy od oceniającego Gemini, zarówno dla odpowiedzi Claude'a, jak i dla pozostałych modeli.

Ten sam model potrafi dać inny wynik przy kolejnym uruchomieniu tego samego testu. Claude Haiku 4.5 dostał w dwóch przebiegach 62 i 39 punktów na 102. W tekście o audycie SEO opisałem, dlaczego model AI nie zrobi pełnego audytu strony sam.

Mój zestaw: do czego używam którego narzędzia?

Narzędzia dzielę na sześć zastosowań w pracy, a nie według producentów. Ten sam model bywa w kilku zastosowaniach, bo inaczej używam go do czytania danych, a inaczej do kontroli. Przy każdym zastosowaniu podaję test, po którym zmieniłem sposób pracy.

Których modeli językowych używam i do czego?

Główną pracę robię w Claude Code, czyli w Claude działającym w terminalu z dostępem do plików, skryptów i danych. Claude pisze i uruchamia skrypty, czyta eksporty i przygotowuje szkice raportów. Codex (OpenAI) i Gemini (Google) dostają te same materiały do drugiej kontroli.

Teksty i raporty sprawdzam drugim modelem innego producenta, w dwóch rundach. Pierwsza runda szuka błędów faktów i luk. Druga runda sprawdza tylko poprawki, bo przy poprawianiu powstają nowe błędy. W październiku 2026 w jednym projekcie druga runda znalazła w przewodniku złą liczbę wszystkich linków, od której liczony był odsetek: 79 zamiast 76. Ten błąd powstał dopiero przy poprawkach. Mój skrypt kontrolny go nie znalazł.

Model jako sędzia jakości potrafi mierzyć coś innego niż człowiek, dlatego sprawdzam go na tekstach, które już oceniłem. 7 października 2026 dałem dwóm modelom do oceny 87 opisów patentów Google. Wśród nich było 8 opisów, które wcześniej sam uznałem za gotowe, a sędziowie o tym nie wiedzieli. Fable, model firmy Anthropic, uznał za gotowe 5 z tych 8. Codex z wysokim poziomem rozumowania uznał 1 z 8.

Te dwa wyniki mówią tylko o tekstach, które sam uznałem za gotowe. Pozostałych 79 opisów nie oceniłem, więc nie wiem, ile odrzuceń było słusznych. Codex odrzucił łącznie 51 z 87 opisów, bo każde zdanie opisu porównywał z zastrzeżeniami, czyli z prawnym zakresem patentu. Zgodność sędziów między sobą była bliska przypadkowej. Kappa Cohena wyniosła 0,06, gdzie 0 oznacza zgodność przypadkową, a 1 pełną.

Modeli lokalnych na własnym komputerze z kartą graficzną używam do masowych etykiet, bo nie płacę za każdą sztukę. 1 października 2026 sprawdziłem modele lokalne na czterech prostych czynnościach. Danymi były strony trzech polskich sklepów internetowych. Gemma 4 31B rozpoznała rodzaj strony w 98,5% z 403 stron. Rodzaje stron to produkt, lista produktów, artykuł albo inna. Skrypt z regułami trafiał w 84% tych stron.

Gemma prawie bez błędów odczytała ceny i oceniła zgodność liczb, ale część wzorców w tym teście pochodziła z modelu, a nie od człowieka. Wzorcem rodzaju strony były etykiety ze skryptu poprawione przez model Claude Opus. Gemma odczytała poprawnie cenę ze wszystkich 177 kart produktu. Wzorcem była cena z danych strukturalnych, zgodna z tekstem strony. W 99,3% ze 134 przypadków Gemma poprawnie oceniła, czy liczba w zdaniu zgadza się z danymi. Połowa tych zdań miała celowo zmienioną liczbę. Gemma rozpoznała też rodzaj popytu we frazie (oferta, poza ofertą albo porada) w 97,7% z 218 fraz. Wzorcem były tu etykiety modelu Claude Opus.

Ta sama rodzina modeli zawiodła przy porównaniu liczb między dwoma plikami w prawdziwej ofercie. 12 października 2026 dwie wersje Gemmy 4, 26B i 31B, porównały 63 wiersze i zgłosiły tylko fałszywe sprzeczności. Uznały na przykład, że „-34%” i „jedna trzecia” to sprzeczne wartości. Jedyny prawdziwy problem w tym tekście nie dotyczył liczb, tylko przesadnego słowa przy wyniku z tabeli. Nie należał więc do zadania Gemmy. Teraz skrypt sprawdza, czy każda liczba z jednego pliku występuje w drugim. To kontrola obecności liczb, a ich znaczenie sprawdza człowiek albo drugi model.

Jakich narzędzi używam do danych o pozycjach i popycie?

Dane o wynikach Google biorę z DataForSEO, Search Console i Ahrefs, a każde z tych źródeł ma inną pułapkę. DataForSEO sprzedaje zrzuty wyników Google i dane o popycie z opłatą za każde zapytanie. Od 17 września do 14 października 2026 zleciłem tam 17 076 zadań za 99,89 USD. Wśród nich było 13 085 zrzutów wyników Google.

Jeden zrzut wyników nie wystarcza do pomiaru pozycji, bo kolejne zrzuty tej samej frazy wyglądają inaczej. 7 października 2026 pobrałem wyniki dla 94 fraz trzy razy co godzinę i dwa razy w tej samej minucie, za 1,57 USD. Potem porównałem domeny z pierwszej dziesiątki w dwóch zrzutach tej samej frazy. Wspólne domeny stanowiły w medianie ok. 15% wszystkich różnych domen z obu zrzutów. W zrzutach z tej samej minuty było to ok. 8%. Jedna fraza miała w medianie 4 warianty wyników. Dlatego zamiast pozycji liczę odsetek zrzutów, w których domena jest w pierwszej dziesiątce. Zrzutów jest ok. 10 i wysyłam je naraz.

Ten pomiar unieważnił mój wcześniejszy test, w którym porównałem pozycję z jednego zrzutu z cytowaniami z pięciu zrzutów. Wynik testu „zdany” okazał się fałszywy, więc test wstrzymałem. AI Overview, czyli odpowiedź AI nad wynikami Google, był w tym pomiarze stabilny: pojawiał się w 97-99% zrzutów, a lista cytowanych stron się nie zmieniała.

Search Console pokazuje kliknięcia zmierzone przez samo Google, ale eksport z panelu ucina tabelę do 1 000 wierszy. Tysiąc zapytań posortowanych według kliknięć to najbardziej klikalna część danych. 20 września 2026 w jednym serwisie eksport z panelu pokazał CTR 4,28% dla pozycji 1-3 w USA. CTR to odsetek wyświetleń zakończonych kliknięciem. Dane z 16 miesięcy pobrane bez limitu 1 000 wierszy, czyli 123 498 zapytań, dały 1,40%. Takie dane pobieram przez API Search Console, czyli interfejs dla programów. Drugi sposób to raport w Looker Studio, darmowym narzędziu Google do raportów, ze złączem Search Console.

Ahrefs używam do linków, fraz i konkurencji, ale jego szacunki ruchu sprawdzam w Search Console. Kolumna ruchu w Rank Trackerze Ahrefs to szacunek: szacowany popyt pomnożony przez przyjęty odsetek kliknięć. W jednym serwisie ten szacunek był 10-50 razy wyższy niż kliknięcia w Search Console, a w innym ok. 3 razy niższy. Rank Tracker liczy też bloki na stronie wyników jako pozycje. W jednym przypadku spadek z 1. na 13. miejsce oznaczał tylko to, że nad wynikami pojawił się AI Overview.

Jakich narzędzi używam do audytu technicznego?

Do audytu używam Screaming Frog i przeglądarki Chrome bez okna, a model AI czyta wyniki, ale nie zastępuje skanowania serwisu. Screaming Frog przechodzi serwis tak jak robot wyszukiwarki. Chrome uruchomiony bez okna pokazuje stronę po wykonaniu JavaScriptu, więc porównuję obie wersje strony. W jednym audycie skanowania z JavaScriptem i bez niego uruchomione równolegle dały fałszywy sygnał o renderowaniu. Od tego czasu uruchamiam je po kolei.

Gdy zapora sieciowa audytowanego serwisu blokuje mój program do skanowania, pojedyncze adresy pobieram przez usługę Apify Web Fetch. W teście z 12 października 2026 usługa odczytała 8 z 8 stron, których nie mogłem pobrać z mojego adresu IP. Dwie z nich należały do serwisów klientów, a sześć do publicznych serwisów z opiniami, porównywarek i sklepów internetowych. Kosztowało to 0,00155 USD za adres. Usługa czasem zgłaszała jednak udane pobranie z kodem 200, choć pobrała tylko stronę weryfikacji. Bardzo krótki tekst albo tekst o weryfikacji uznaję więc za blokadę i ponawiam pobranie.

Ta usługa nie pokazuje, co widzi prawdziwy robot Google albo robot AI. Łączy się z innego adresu IP, a nawet gdy podam nazwę robota, pozostałe nagłówki zdradzają zwykłą przeglądarkę Chrome. Blokady robotów sprawdzam więc w Search Console i własnym skryptem, który porównuje odpowiedzi serwera dla różnych robotów. W tekście o pliku llms.txt opisałem, jak po adresie IP sprawdzam, czy żądanie wysłał prawdziwy robot.

Asystenta audytów technicznych zbudowałem na audytach mojej agencji z lat 2020-2026 i mierzę go na audytach zrobionych wcześniej przez człowieka. Asystent to agent AI, który zbiera dane o serwisie i sprawdza je według katalogu reguł spisanych z tych audytów. Zakres audytu i priorytety zatwierdzam sam, na początku pracy i przed wysłaniem audytu. Wynik pomiaru dopiszę tutaj po drugim pomiarze na nowym serwisie.

Jakich narzędzi używam do treści i semantyki?

Frazę do strony przypisuję wyszukiwaniem hybrydowym, bo poprzednia wersja mojego narzędzia trafiała tylko w jednej trzeciej fraz. 14 października 2026 wziąłem frazy z Search Console dwóch serwisów, bez fraz z nazwą marki. Dla każdej frazy wzorcem była strona, która dostała co najmniej 60% kliknięć z tej frazy i była wśród zeskanowanych stron serwisu. Poprzednia wersja narzędzia używała modelu MiniLM do embeddingów, czyli zamiany tekstu na wektor liczb. Wskazała stronę wzorcową jako pierwszą w 34% fraz.

Wyszukiwanie hybrydowe łączy trzy listy stron i trafiało w stronę wzorcową w 80,5% i 77,1% fraz. Pierwsza lista pochodzi z modelu e5-large. Druga to wyszukiwanie po słowach w treści, a trzecia po słowach w tytule, nagłówku H1 i adresie. Listy łączę metodą RRF, która nagradza strony wysoko na kilku listach naraz. Najlepszy pojedynczy model do embeddingów był inny w każdym z serwisów, a hybryda wygrała w obu.

Przy tym teście znalazłem błąd we własnym narzędziu: model nie widział końca większości fragmentów tekstu. Skrypt dzielił tekst na fragmenty po 80 słów, a model przyjmuje 128 tokenów, czyli kawałków słów. Polskie słowa dzielą się na więcej tokenów niż angielskie, więc 89-98% fragmentów było ucinanych. Wynik 34% dotyczy więc poprzedniej wersji narzędzia razem z tym błędem, a nie samego modelu MiniLM. Test mierzy zgodność z kliknięciami w Google, a nie to, która strona najlepiej odpowiada na zapytanie.

Encje, czyli nazwy firm, produktów, osób i pojęć, wyciągam z tekstów lokalnym modelem GLiNER2. W moim teście z lipca 2026 model miał na polskich tekstach F1 0,94, tyle samo co na angielskich. F1 łączy trafność i kompletność, a 1 oznacza wynik idealny. Ten wynik dotyczy etykiet, które się nie pokrywają. Gdy w jednym zapytaniu były naraz etykiety „firma” i „marka”, F1 spadał do 0,85. Model działa na zwykłym procesorze, ok. 20 akapitów na sekundę, bez opłaty za stronę.

Nie używam GLiNER2 do rozpoznawania intencji fraz, bo w moim teście trafiał tylko w 33-42% przypadków. Często mylił się z pewnością 0,99, czyli z prawie najwyższą pewnością, jaką sam podaje.

Mapę tematów tej serii wpisów zrobiłem z encji na 71 stronach konkurencji z Polski i USA. Skrypt wyciągnął 110 encji i 1 764 trójki, czyli zapisy w formie encja, cecha i wartość. Dane kosztowały 0,072 USD. Mapa pokazała role wpisów, pary tekstów do połączenia linkami i tematy, których brakuje na tej stronie.

Jakich narzędzi używam do link buildingu?

Do analizy linków używam Ahrefs, ale linki oznaczone jako utracone sprawdzam na żywo, zanim trafią do wniosków. W październiku 2026 w jednym projekcie Ahrefs pokazywał 360 polskich domen jako utracone. 140 z nich nadal linkowało tym samym adresem. Ok. 70 adresów odpowiadało błędem 403 na pobranie zwykłym programem, więc sprawdziłem je w przeglądarce sterowanej skryptem (Playwright).

Współprowadzę Linko, platformę linkową, więc nie opisuję jej tu jak narzędzia innej firmy. W tekście o link buildingu opisałem, jak oceniam portale przed zakupem publikacji. W tekście o link buildingu w erze AI opisałem, jak AI pomaga przygotować publikacje i kontakt z wydawcami.

Jakich narzędzi używam do pomiaru widoczności w AI?

Narzędzia do pomiaru widoczności marki w AI opisałem w osobnym tekście, więc tu podaję tylko zasadę. Wzmiankę marki w odpowiedzi i cytowanie jej strony liczę osobno. Każde pytanie zadaję kilka razy, bo odpowiedzi asystentów się zmieniają. W tekście o widoczności marki w AI opisałem pomiar, liczbę powtórzeń i pułapki narzędzi. W tekście o pozycjonowaniu w AI opisałem, co robię na stronie, żeby asystenci AI mogli ją cytować.

Jakie narzędzia SEO zbudowaliśmy sami?

Gdy żadne narzędzie nie odpowiada na moje pytanie, piszę z pomocą AI własny skrypt. Większość tych skryptów służy do pracy wewnętrznej: skanowanie, pobieranie danych, encje, kontrola tekstów i liczb. Zanim zacznę używać skryptu w pracy, sprawdzam go na danych z poprawną odpowiedzią.

W VerticalSEO przygotowujemy 16 narzędzi SEO, które będą dostępne przez stronę i przez API, także dla agentów AI. Narzędzia nie są jeszcze opublikowane. Testy z 8 października 2026 sprawdzały, czy narzędzia działają zgodnie ze specyfikacją. Przeszło 610 z 610 testów API i 325 z 325 testów narzędzi dla agentów w przeglądarce. Te narzędzia działają w standardzie WebMCP, który udostępnia funkcje strony agentom AI. Testy nie mierzą jeszcze, czy narzędzia dają trafne wnioski SEO.

Test narzędzia do sprawdzania encji pokazał, że sama nazwa nie wystarcza do wskazania encji. Szukałem polskiej platformy handlowej Allegro, ale narzędzie wybierało z grafu wiedzy Google, czyli z jego bazy encji, utwór Vivaldiego. Pod moim imieniem i nazwiskiem wybierało aktora. Teraz narzędzie potwierdza encję dopiero wtedy, gdy Google podaje dla niej sprawdzaną stronę. Potwierdzeniem jest też identyfikator wskazany przez Wikidata albo przez dane strukturalne strony.

LemmeGSC, mój panel do danych z Search Console, przygotowuję do wydania jako otwarte oprogramowanie. Panel pobiera dane z Search Console bez limitu 1 000 wierszy. Pokazuje między innymi kanibalizację fraz, czyli kilka stron jednego serwisu na tę samą frazę.

Jakie darmowe narzędzia SEO wystarczą na początek?

Na początek wystarczą Search Console, Looker Studio, darmowa wersja asystenta AI i darmowa wersja Screaming Frog. Każde z tych narzędzi ma inną rolę:

• Search Console pokazuje kliknięcia, wyświetlenia i zapytania z Google;
• Looker Studio ze złączem Search Console pobiera te dane bez limitu 1 000 wierszy;
• darmowa wersja asystenta AI grupuje frazy, pisze szkice i skrypty, jeśli dasz jej dane;
• darmowa wersja Screaming Frog skanuje do 500 adresów, co wystarcza dla małego serwisu.

Płatne narzędzia do fraz i linków warto dodać dopiero wtedy, gdy wiesz, na jakie pytanie mają Ci odpowiedzieć. Darmowy asystent AI nie zna Twoich danych z Search Console. Najwięcej daje wtedy, gdy dostaje od Ciebie eksport i prośbę o skrypt, który policzy wynik.

Jak testuję narzędzie AI, zanim mu zaufam?

Narzędzie sprawdzam na danych, dla których znam poprawną odpowiedź. Nie każdy test z tego tekstu miał wszystkie elementy z listy poniżej. W teście modeli lokalnych wzorzec rodzaju strony poprawił model, a nie człowiek. Dziś test ma te elementy:

• zbiór wzorcowy z decyzji człowieka albo z danych Google, na przykład strona z większością kliknięć z danej frazy;
• przewidywany wynik zapisany przed uruchomieniem testu;
• powtórka tego samego przebiegu, bo jeden przebieg modelu albo jeden zrzut wyników bywa przypadkowy;
• przypadki z podłożonym błędem, żeby sprawdzić, czy kontrola go wykryje;
• koszt i czas na jedną sztukę;
• liczby sprawdzone skryptem, a nie modelem.

Dane do testów kosztowały mnie niewiele, a najwięcej pracy wymaga zbiór wzorcowy. Test zrzutów wyników kosztował 1,57 USD, a dane do mapy tematów serii 0,072 USD. Zbiór wzorcowy wymaga wcześniejszej oceny człowieka. Podane koszty nie obejmują tej pracy.

Wynik testu zapisuję razem z tym, czego test nie sprawdził. Przy przypisaniu frazy do strony znam zgodność z kliknięciami w Google, ale nie wiem, czy wskazana strona najlepiej odpowiada na zapytanie. Przy modelach lokalnych sprawdziłem cztery proste czynności, a nie pełne zadania. Bez takiego zapisu wynik testu łatwo uznać za szerszy, niż jest.

Najczęstsze pytania o narzędzia AI w SEO

Od czego zacząć?

Zacznij od jednego zadania, które robisz co tydzień, i od danych, które już masz w Search Console. Daj modelowi pełne dane i poproś o skrypt, który policzy to, co dziś liczysz ręcznie. Wynik porównaj z kilkunastoma przypadkami, które sprawdzisz sam. Dopiero gdy wyniki się zgadzają, uruchom skrypt na całych danych. W tekście o strategii SEO opisałem, które dane z Search Console sprawdzam na początku pracy.