Google po cichu zmienił nazwę jednego ze swoich agentów sieciowych, a konsekwencje tej pozornie kosmetycznej korekty sięgają znacznie dalej, niż sugeruje wpis w dokumentacji. Wraz z przemianowaniem NotebookLM na Gemini Notebook koncern zmienił także identyfikator crawlera z Google-NotebookLM na Google-GeminiNotebook. Właściciele witryn, którzy blokowali lub monitorowali stary user agent, mają tylko kilka tygodni na aktualizację reguł, a przy okazji cała sprawa przypomina o niewygodnym fakcie: ten konkretny pobieracz treści w ogóle nie respektuje pliku robots.txt.
Zmiana została opisana 18 lipca 2026 roku i szybko podchwyciły ją serwisy branżowe. Dla specjalistów SEO oraz osób zajmujących się optymalizacją pod modele językowe (AIO) to sygnał, że kontrola nad tym, kto i jak pobiera treść z witryny, staje się coraz bardziej rozproszona i coraz trudniejsza do wyegzekwowania klasycznymi metodami.
Kontekst: od NotebookLM do Gemini Notebook
NotebookLM to narzędzie Google, które pozwala użytkownikowi zbudować osobistą bazę wiedzy z dokumentów, notatek i adresów URL, a następnie zadawać pytania, generować streszczenia oraz tworzyć podcasty audio na bazie wgranych źródeł. Produkt zyskał popularność właśnie dzięki funkcji przetwarzania treści z sieci w przystępne formaty. Teraz Google włącza go głębiej w ekosystem Gemini i porządkuje nazewnictwo, stąd rebranding na Gemini Notebook.
Z perspektywy użytkownika końcowego nic się nie zmienia: narzędzie działa tak samo, oferuje te same funkcje, ma tę samą logikę. Problem leży po stronie serwerowej, tam gdzie administratorzy i zespoły SEO próbują zapanować nad ruchem botów. To właśnie identyfikator user agent decyduje, czy dana wizyta zostanie rozpoznana, policzona, przepuszczona czy odrzucona. Kiedy zmienia się nazwa agenta, wszystkie dotychczasowe reguły oparte na starym ciągu znaków przestają obowiązywać.
Co dokładnie się zmieniło
Rdzeń zmiany jest prosty, ale ma praktyczne skutki. Google zaktualizowało dokumentację infrastruktury indeksowania, usuwając wpis o starym agencie i dodając nowy. Poniższa tabela zestawia najważniejsze parametry.
| Parametr | Stan poprzedni | Stan obecny |
|---|---|---|
| Nazwa produktu | NotebookLM | Gemini Notebook |
| User agent | Google-NotebookLM | Google-GeminiNotebook |
| Typ agenta | Fetcher wywoływany przez użytkownika | Fetcher wywoływany przez użytkownika |
| Respektuje robots.txt | Nie | Nie |
| Okres przejściowy starego agenta | nie dotyczy | do sierpnia 2026 |
Kluczowa informacja praktyczna: stary user agent Google-NotebookLM ma działać jeszcze do sierpnia 2026 roku. To krótkie okno przejściowe. Kto opiera raportowanie ruchu botów, reguły firewalla albo wpisy w pliku .htaccess na starej nazwie, musi je zaktualizować w ciągu najbliższych tygodni, w przeciwnym razie ruch z Gemini Notebook przestanie być widoczny w statystykach albo, co gorsza, przestanie być blokowany.
Dlaczego ten fetcher omija robots.txt
Najważniejszy element całej układanki to klasyfikacja agenta. Google dzieli swoje boty na trzy kategorie: crawlery indeksujące (jak Googlebot), specjalne pobieracze oraz tak zwane fetchery wywoływane przez użytkownika (user-triggered fetchers). Google-GeminiNotebook należy do tej ostatniej grupy.
Logika Google jest następująca: skoro pobranie treści inicjuje konkretny użytkownik, wklejając adres URL albo prosząc o zebranie źródeł na dany temat, to nie jest to automatyczne indeksowanie, lecz działanie w imieniu człowieka. Z tego powodu, zgodnie z dokumentacją koncernu, fetchery wywoływane przez użytkownika nie stosują się do reguł zapisanych w pliku robots.txt. Innymi słowy, dyrektywa Disallow, która skutecznie powstrzymuje Googlebota, nie ma tu żadnego znaczenia.
To rozróżnienie budzi kontrowersje od dawna, bo z punktu widzenia serwera efekt jest identyczny: bot pobiera treść i wykorzystuje ją w produkcie Google. Dla wydawcy nie ma znaczenia, czy pobranie zainicjował algorytm, czy pojedynczy użytkownik Gemini Notebook, jeśli finalnie jego artykuł ląduje w streszczeniu bez żadnego odesłania zwrotnego.
Trzy funkcje, które zwiększają ryzyko scrapowania
Gemini Notebook oferuje kilka mechanizmów, które w praktyce oznaczają pobieranie treści z zewnętrznych witryn. Warto je znać, bo to one generują ruch agenta Google-GeminiNotebook.
- Discover Sources (odkrywanie źródeł): funkcja automatycznie wyszukuje i pobiera nawet do dziesięciu źródeł internetowych dla zapytania zdefiniowanego przez użytkownika, a następnie generuje streszczenia. Efekt dla wydawcy: treść zostaje przetworzona, ale odesłanie zwrotne nie powstaje.
- Konwersja na audio i wideo: narzędzie potrafi zamienić materiały z sieci w podcasty albo objaśnienia wideo. Takie formaty mogą konkurować z oryginalnym źródłem o uwagę odbiorcy, nie kierując do niego ruchu.
- Ręczne dodawanie adresów URL: użytkownik może wkleić dowolny link, a Gemini Notebook pobierze i wykorzysta jego zawartość w swojej bazie wiedzy.
Wspólny mianownik tych funkcji to zerowa liczba odesłań (zero referrals). Treść jest wchłaniana do produktu Google, a użytkownik dostaje gotową odpowiedź bez potrzeby odwiedzania witryny. To dokładnie ten sam problem, który od miesięcy opisujemy w kontekście AI Overviews i asystentów opartych na modelach językowych.
Co to znaczy dla SEO i AIO
Dla branży wyszukiwania ta zmiana jest przede wszystkim przypomnieniem, że tradycyjne narzędzia kontroli dostępu robotów tracą skuteczność. Plik robots.txt pozostaje fundamentem komunikacji z Googlebotem, ale nie chroni przed całą rodziną pobieraczy działających w imieniu użytkownika. Optymalizacja pod modele językowe wymaga więc świadomej decyzji: czy chcemy, aby nasza treść zasilała odpowiedzi Gemini, czy wolimy ją przed tym chronić.
Odpowiedź nie jest oczywista. Z jednej strony obecność w bazach źródeł asystentów AI może budować widoczność marki i cytowania, co jest istotą strategii AIO. Z drugiej, jeśli witryna żyje z ruchu i wyświetleń reklam, przetwarzanie jej treści bez odesłania zwrotnego to realna strata. Każdy wydawca musi przeliczyć ten bilans samodzielnie, a decyzja o blokadzie albo otwarciu treści powinna wynikać z modelu biznesowego, nie z przyzwyczajenia.
Warto też pamiętać, że sposób, w jaki asystenci AI sięgają po źródła, bywa złożony. Analizy ruchu pokazują, że pojedynczy produkt potrafi korzystać z kilku odrębnych kanałów pobierania treści, co dodatkowo utrudnia jednoznaczne zablokowanie dostępu. Piszemy o tym szerzej w materiale o tym, jak asystenci wybierają źródła i przez ile kanałów pobierają treść.
Jak zablokować Google-GeminiNotebook
Skoro robots.txt nie działa na fetchery wywoływane przez użytkownika, jedyną skuteczną metodą pozostaje blokada na poziomie serwera albo zapory sieciowej (WAF). Można to zrobić regułą w pliku .htaccess na serwerze Apache. Przykładowy zapis wygląda następująco.
RewriteEngine On
# Blokada Google-GeminiNotebook
RewriteCond %{HTTP_USER_AGENT} Google-GeminiNotebook [NC]
RewriteRule ^ - [F,L]Analogiczną regułę można skonfigurować w nginx, w regułach firewalla albo w panelu dostawcy CDN. Kto do tej pory blokował starą nazwę Google-NotebookLM, powinien dodać nowy identyfikator, a najlepiej objąć regułą oba ciągi znaków na czas okresu przejściowego, który trwa do sierpnia 2026 roku. W praktyce oznacza to jedną dodatkową linijkę warunku, ale bez niej blokada przestanie obejmować cały ruch narzędzia.
Trzeba mieć świadomość skutków ubocznych. Blokada na poziomie user agent jest tak dobra, jak zgodność deklarowanej nazwy z rzeczywistością, a ciąg znaków można podszyć. Dla legalnego ruchu Google reguła zadziała, ale nie zastąpi pełnej ochrony przed nieuczciwym scrapowaniem, które i tak najczęściej podaje się za zwykłą przeglądarkę. Dlatego blokadę user agenta warto traktować jako element szerszej polityki dostępu, a nie jako komplet zabezpieczeń.
Jak rozpoznać ruch Gemini Notebook w logach
Zanim podejmiesz decyzję o blokadzie, warto sprawdzić, czy narzędzie w ogóle pobiera treść z Twojej witryny i na jaką skalę. Punktem wyjścia są logi dostępu serwera, w których każda wizyta zostawia ślad w postaci ciągu user agent. Wystarczy przefiltrować logi pod kątem obu identyfikatorów, starego i nowego, aby zobaczyć historię odwiedzin agenta.
Na serwerze z dostępem do powłoki pomocne bywa proste zapytanie do logów, na przykład wyszukanie linii zawierających frazę GeminiNotebook lub NotebookLM w pliku access.log. Warto zestawić liczbę takich wizyt z tym, które adresy URL były najczęściej pobierane, bo to pokazuje, które treści narzędzie realnie konsumuje. Jeśli w logach dominują artykuły poradnikowe albo materiały eksperckie, oznacza to, że właśnie one najczęściej trafiają do baz wiedzy budowanych w Gemini Notebook. Taka analiza jest też punktem wyjścia do szerszej oceny, jak boty AI obciążają serwer i ile realnego ruchu oddają w zamian, co warto badać cyklicznie, a nie jednorazowo.
Dopiero na podstawie takich danych decyzja o blokadzie, przepuszczeniu albo selektywnym ograniczeniu dostępu staje się świadoma. Blokowanie w ciemno, bez wglądu w logi, grozi odcięciem kanału, który być może buduje widoczność marki, albo odwrotnie, pozostawieniem otwartej furtki tam, gdzie realnie tracisz ruch i przychody z reklam.
Jak to się ma do Google-Extended
W dyskusjach o kontroli treści pod AI często pojawia się token Google-Extended. To osobny mechanizm: pozwala wydawcom zdecydować, czy ich witryna ma pomagać w ulepszaniu modeli Gemini oraz generatywnych interfejsów Vertex AI. Google-Extended działa jednak na innej płaszczyźnie niż user agent Gemini Notebook i nie należy tych dwóch rzeczy mylić. Ustawienie Google-Extended nie zablokuje fetchera Google-GeminiNotebook, bo dotyczy trenowania modeli, a nie pobierania treści na żądanie użytkownika. To kolejny przykład tego, jak rozproszony i niejednoznaczny stał się zestaw dostępnych kontroli.
Reakcje branży
Wśród specjalistów przeważa ton spokojnej, ale wyraźnej krytyki. Głównym zarzutem jest to, że użytkownik wywołujący pobranie treści nie zmienia natury operacji z punktu widzenia wydawcy: bot i tak konsumuje treść, a odesłanie zwrotne nie powstaje. Rozróżnienie na pobieracze automatyczne i te wywoływane przez użytkownika bywa więc odbierane jako wygodna dla platformy furtka, która pozwala omijać powszechnie akceptowany standard robots.txt.
Serwisy branżowe, które opisały sprawę, zwracają uwagę na krótkie okno przejściowe. Zmiana nazwy agenta w połowie lipca, z wygaszeniem starego identyfikatora już w sierpniu, zostawia administratorom niewiele czasu na reakcję. Dla dużych wydawców z dedykowanymi zespołami to formalność, ale dla mniejszych witryn, które konfigurację botów ustawiły raz i o niej zapomniały, taka cicha zmiana może oznaczać lukę w polityce dostępu, o której nikt się nie dowie, dopóki nie przejrzy logów serwera.
Część komentatorów zwraca też uwagę na kwestię terminologii. Nazywanie automatu, który pobiera dziesięć źródeł na jedno zapytanie, fetcherem wywoływanym przez użytkownika bywa odbierane jako zabieg semantyczny. Z technicznego punktu widzenia to użytkownik klika przycisk, ale samą pracę wykonuje algorytm, który samodzielnie wybiera i pobiera strony. Granica między indeksowaniem a pobieraniem na żądanie staje się więc coraz bardziej płynna, a wraz z nią rozmywa się sens klasycznych dyrektyw dla robotów. To spór, który prawdopodobnie wróci przy kolejnych produktach opartych na modelach językowych, bo dotyka fundamentalnego pytania o to, kto i na jakich zasadach ma prawo korzystać z publicznie dostępnej treści.
Cała sprawa wpisuje się w szerszy trend, który dokumentujemy od miesięcy: boty AI pobierają coraz więcej treści, oddając w zamian coraz mniej ruchu. Dane operatorów infrastruktury sieciowej pokazują rosnący apetyt automatów na zawartość witryn, o czym pisaliśmy w analizie danych Cloudflare o botach AI, które biorą coraz więcej, a oddają coraz mniej.
Co dalej
Najbliższe tygodnie to okres, w którym warto zrobić trzy rzeczy. Po pierwsze, przejrzeć logi serwera pod kątem obecności zarówno Google-NotebookLM, jak i Google-GeminiNotebook, żeby ocenić skalę ruchu tego narzędzia na własnej witrynie. Po drugie, podjąć świadomą decyzję: blokować, przepuszczać czy monitorować. Po trzecie, zaktualizować reguły przed sierpniem 2026 roku, kiedy stary identyfikator przestanie być używany.
W szerszej perspektywie zmiana pokazuje kierunek, w którym zmierza cały ekosystem wyszukiwania. Kontrola nad tym, kto pobiera treść, przestaje być prostą sprawą jednego pliku w katalogu głównym witryny. Wydawcy i specjaliści SEO będą musieli myśleć w kategoriach polityki dostępu obejmującej wiele agentów, wiele produktów i wiele mechanizmów, z których część świadomie omija dotychczasowe standardy. Kto chce zachować kontrolę nad swoją treścią w erze asystentów AI, musi tę politykę aktywnie projektować, zamiast liczyć na to, że raz ustawiony robots.txt załatwi sprawę. Temat legalnych granic pobierania treści rozwijamy też w praktycznym przewodniku o scrapowaniu wyników wyszukiwania i jego limitach.
FAQ
Czym różni się Google-GeminiNotebook od Googlebota?
Googlebot to crawler indeksujący, który respektuje reguły pliku robots.txt i buduje indeks wyszukiwarki. Google-GeminiNotebook to fetcher wywoływany przez użytkownika, który pobiera treść na żądanie w narzędziu Gemini Notebook i nie stosuje się do robots.txt. To dwa różne typy agentów o różnym przeznaczeniu.
Czy robots.txt zablokuje Gemini Notebook?
Nie. Fetchery wywoływane przez użytkownika, do których należy Google-GeminiNotebook, z założenia nie stosują się do reguł robots.txt. Skuteczną blokadą jest reguła na poziomie serwera, na przykład w pliku .htaccess, w konfiguracji nginx albo w firewallu czy panelu CDN.
Do kiedy działa stary user agent Google-NotebookLM?
Według dokumentacji Google stary identyfikator Google-NotebookLM ma funkcjonować do sierpnia 2026 roku. W tym okresie przejściowym warto objąć regułami zarówno starą, jak i nową nazwę agenta, aby monitorowanie oraz blokady pozostały skuteczne.
Czy powinienem blokować ten agent?
To zależy od modelu biznesowego. Jeśli zależy Ci na cytowaniach i widoczności w odpowiedziach asystentów AI, blokada może być niewskazana. Jeśli witryna żyje z ruchu i wyświetleń reklam, a przetwarzanie treści bez odesłania zwrotnego oznacza stratę, blokada ma uzasadnienie. Decyzję warto oprzeć na analizie logów i celach biznesowych.
Czy Google-Extended chroni przed Gemini Notebook?
Nie. Google-Extended to osobny token, który decyduje o wykorzystaniu treści do trenowania modeli Gemini i interfejsów Vertex AI. Nie blokuje pobierania treści na żądanie użytkownika przez agenta Google-GeminiNotebook. To dwa niezależne mechanizmy kontroli.