Agent AI w Google Cloud: dostęp do Search Console i czego API nie zrobi

Agent AI może sam sprawdzać, jak strona radzi sobie w Google. Potrzebuje do tego dostępu do Search Console, czyli narzędzia Google z danymi o wyszukiwaniach i indeksowaniu. Nasz agent dostaje go przez konto serwisowe w Google Cloud. Tak pracujemy przy własnej stronie, więc opisujemy, jak to ustawić, co API potrafi i czego nie zrobi. Na końcu piszemy o zabezpieczeniach, bo agent dostaje klucz do danych firmy.

Tekst jest dla osób, które prowadzą firmową stronę i chcą wiedzieć, na co się zgadzają. Osoba techniczna znajdzie w nim zakres API i limity. Agentem może być na przykład Claude Code albo Codex. Czym jest agent i kiedy się przydaje, opisujemy w artykule Agent AI w firmie.

Czym jest konto serwisowe

Konto serwisowe to konto dla programu, a nie dla człowieka. Ma własny adres e-mail i loguje się bez udziału osoby. Agent na zwykłym komputerze może logować się kluczem tego konta. Klucz to plik z kluczem prywatnym, który pobierasz tylko raz.

Klucz trzeba traktować poważnie. Według Google mieć ten klucz to jak znać hasło użytkownika, bo kto go ma, działa jako to konto. Domyślnie klucz nigdy nie wygasa. W organizacjach Google Cloud założonych od 3 maja 2024 tworzenie kluczy jest domyślnie zablokowane zasadą organizacji. Komunikat o blokadzie przy tworzeniu klucza może więc wynikać z tej zasady.

Jak agent dostaje dostęp

Ustawienie składa się z kilku kroków:

1. Projekt w Google Cloud. W nim włączasz Search Console API.
2. Konto serwisowe. Osobne, tylko do tego zadania.
3. Sposób logowania. Na przykład klucz, choć Google zaleca bezpieczniejsze sposoby, o czym piszemy niżej.
4. Użytkownik w Search Console. Właściciel usługi otwiera Ustawienia, a potem Użytkownicy i uprawnienia. Dodaje tam adres konta serwisowego i wybiera poziom uprawnień.

Tak nadaliśmy dostęp u siebie. Bez ostatniego kroku API nie pokazuje agentowi żadnej usługi.

Według pomocy Search Console użytkownik z ograniczonymi uprawnieniami widzi większość danych, ale nie wyśle mapy strony. Pełny użytkownik widzi wszystkie dane i wysyła mapy, ale nie dodaje innych użytkowników. Właściciel ma pełną kontrolę nad usługą. Konto serwisowe nie potrzebuje roli właściciela do raportów ani do wysyłania map.

Drugą warstwą jest zakres dostępu, o który program prosi przy logowaniu. API ma dwa zakresy: tylko do odczytu oraz do odczytu i zapisu. Nasz skrypt prosi o zapis tylko wtedy, gdy wysyła mapę strony. Wszystkie odczyty idą z zakresem tylko do odczytu.

Co API potrafi

Dokumentacja API wymienia cztery obszary:

• Dane wyszukiwania. Kliknięcia, wyświetlenia, CTR i średnia pozycja, pogrupowane na przykład po frazach albo stronach. Jedno zapytanie zwraca najwyżej 25 000 wierszy. Google zaznacza, że nie gwarantuje wszystkich wierszy, tylko te najważniejsze. Domyślnie dostajesz dane ostateczne, a o najświeższe trzeba poprosić osobno.
• Mapy strony. Lista wysłanych map z ich stanem, wysłanie nowej mapy i usunięcie starej.
• Usługi. Lista usług, do których konto ma dostęp, oraz dodawanie i usuwanie ich z konta.
• Sprawdzanie adresu. Stan adresu w indeksie Google, na przykład to, czy adres jest w indeksie i kiedy robot Google ostatnio go odwiedził.

API sprawdzania adresu pokazuje tylko wersję zapisaną w indeksie i nie przetestuje adresu na żywo.

Dla małej strony limity są wysokie. Sprawdzanie adresów pozwala na 2000 zapytań dziennie i 600 na minutę w jednej usłudze. W sklepie z tysiącami produktów agent musi więc rozłożyć sprawdzanie na kilka dni albo wybrać najważniejsze adresy. Dane wyszukiwania mają osobne limity obciążenia. Najbardziej obciążają je zapytania grupowane jednocześnie po stronie i frazie oraz długie okresy.

U nas wygląda to tak. Przy starcie nowej strony agent sprawdził wszystkie 38 adresów z mapy strony i zapisał punkt odniesienia z danymi wyszukiwania. Ten zapis posłuży do porównania po tygodniu i po 28 dniach. Po każdym wdrożeniu agent wysyła do Google zaktualizowaną mapę strony.

Czego API nie zrobi

• Prośba o zindeksowanie. W API nie ma takiej metody. O zindeksowanie prosisz ręcznie w narzędziu do sprawdzania adresów w Search Console. Google podaje, że może to zrobić właściciel albo pełny użytkownik usługi, a liczba próśb ma limit. Ponowne wysyłanie tego samego adresu nie przyspieszy wizyty robota Google. Przy wielu adresach Google zaleca mapę strony.
• Test na żywo. Narzędzie w panelu pobiera stronę w tej chwili i sprawdza, czy da się ją zindeksować. API tego nie potrafi.
• Indexing API dla zwykłych stron. Google ma osobne Indexing API, ale można go używać tylko dla stron z ofertami pracy i transmisjami na żywo. Każde zgłoszenie przechodzi kontrolę pod kątem spamu, a za nadużycia Google może odebrać dostęp. Do artykułów i stron firmowych się nie nadaje.
• Usuwanie z wyników. Narzędzie do usuwania ukrywa adres w wynikach na około sześć miesięcy. Działa tylko w panelu Search Console, a API nie ma takiej metody.
• Użytkownicy i ustawienia. Dodawanie użytkowników i większość ustawień należą do właściciela. W API takich metod nie ma.

Te kroki robimy ręcznie w panelu. Czasem zgłaszamy w nim nowe i zmienione adresy, czasem zostawiamy to samej mapie strony. Termin wizyty i tak wybiera Google. Według jego dokumentacji trwa to od kilku dni do kilku tygodni i nie ma gwarancji, że adres trafi do wyników.

Zabezpieczenia

• Osobne konto do jednego zadania. Google zaleca osobne konto serwisowe dla każdej aplikacji i tylko te uprawnienia, których ona potrzebuje. W adresie konta nie umieszczaj poufnych informacji. Konto, którego już nie używasz, wyłącz.
• Najniższy wystarczający poziom w Search Console. Zacznij od najniższego poziomu i podnieś go dopiero wtedy, gdy zadanie tego wymaga.
• Klucz poza kodem. Klucz nie trafia do repozytorium, na czat ani do logów. Google przypomina, żeby nie zostawiać kopii w folderze pobranych plików ani w koszu. Jeśli klucz trafi do repozytorium, trzeba go usunąć w Google Cloud, bo samo usunięcie pliku nie wystarczy. Google zaleca też, żeby nie trzymać klucza w pliku na dysku, tylko w magazynie kluczy na komputerze albo w module sprzętowym. Odradza przy tym Secret Manager w Google Cloud.
• Klucz jako wyjątek. Google traktuje klucze jako wyjątek i zaleca bezpieczniejsze sposoby logowania, gdy są dostępne. Jednym z nich jest działanie jako konto serwisowe na własnych danych logowania, które Google nazywa impersonation. Wtedy dziennik pokazuje, która osoba działała jako to konto. Nasz agent korzysta z klucza, więc tym bardziej pilnujemy pozostałych zasad.
• Wymiana i porządek. Google zaleca regularną wymianę kluczy. Dzięki temu łatwiej szybko zareagować, gdy klucz wycieknie. Nieużywany klucz najpierw wyłącz, a potem usuń.
• Agent widzi to samo co skrypt. Agent, który uruchamia skrypt z kluczem, może ten klucz odczytać. Dlatego klucz ma wąskie uprawnienia i można go w każdej chwili usunąć.
• Zgoda na zapis. Agent sam czyta dane. Mapę strony wysyła tylko po wdrożeniu, na które zgodził się właściciel.

Do czego jeszcze się to przyda

Podobnie można podłączyć inne usługi Google, które przyjmują konto serwisowe. Przy samej Search Console da się zbudować na przykład:

• Raport tygodniowy. Agent zbiera frazy i strony z ostatniego tygodnia i pokazuje, co się zmieniło.
• Kontrolę po wdrożeniu. Po każdej zmianie na stronie sprawdza, czy nowe adresy są w indeksie.
• Listę ważnych stron. Pilnuje kluczowych adresów i zgłasza, gdy któryś zniknie z indeksu.
• Połączenie z Twoimi danymi. Zestawia dane z wyszukiwania z zamówieniami albo zapytaniami z formularza, jeśli Twój system ma eksport.

Takie zadanie zaczyna się od samego odczytu. Uprawnienia do zapisu dodaje się później, gdy wynik jest sprawdzony i ktoś w firmie za niego odpowiada.

Opisujemy stan z 7 listopada 2026. Jeśli chcesz, żeby dane z Search Console trafiały do Twoich raportów bez ręcznego kopiowania, napisz nam, co ma się w nich znaleźć.