Grokopedia, spadki CTR i Google-CWS – Newsy SEO – #1 – Listopad 2025

Kiedy Elon Musk wchodzi do nowej gry, internet robi popcorn. Tym razem padło na encyklopedię.  W dużym skrócie: Grokopedia to odpowiedź Muska na Wikipedię. Z tą różnicą, że zamiast armii wolontariuszy mamy algorytmy i model Grok. Platforma ruszyła z wersją 0.1 i pakietem treści generowanych automatycznie.

Na dzień dobry dorzuciła do sieci prawie 900 tysięcy stron. To tempo, przy którym nawet najbardziej zapracowany copywriter zaczyna szukać nowej kariery. Choć projekt działa dopiero chwilę, wyszukiwarki już go zauważyły.

Grokopedia to bezpośrednie rzucenie rękawicy Wikipedii, ale przede wszystkim – największy na żywo test polityki Google i Bing wobec treści generowanych maszynowo. Według dostępnych analiz Google i Bing zaczęły indeksować strony Grokipedii niemal od pierwszego tygodnia działania serwisu. W Google jest to ok. 1400 stron, z kolei w Bing już 35 tysięcy! Czy to dużo? Dla projektu, który dopiero wyszedł z pieca – zdecydowanie tak.

Pamiętajmy: to, że strona jest w indeksie, nie oznacza, że generuje ruch. Pierwsze raporty z narzędzia Ahrefs są dla Grokipedii bezlitose. Mimo setek tysięcy opublikowanych artykułów, narzędzie to zidentyfikowało zaledwie:

• Około 70 stron posiadających jakikolwiek ranking w Google.
• Łącznie 250 fraz kluczowych, na które serwis jest widoczny.
• Zaledwie dwie (2) frazy w TOP 20 wyników wyszukiwania.

Większość witryn hostuje dziś swoje zasoby medialne – obrazy, pliki wideo czy skrypty – u zewnętrznych dostawców, takich jak Amazon S3, Google Cloud Storage czy Microsoft Azure. To standardowa praktyka. Jednak John Mueller z Google przypomniał o fundamentalnym błędzie, który popełnia przy tym wielu administratorów: rezygnacja z analityki i kontroli nad tymi zasobami.

Jeśli Twoje obrazy wyświetlają się pod domyślnym adresem URL dostawcy chmury, z perspektywy Google Search Console są one “niewidzialne”. W efekcie możesz nie widzieć błędów indeksacji, ostrzeżeń związanych z bezpieczeństwem czy statystyk wyszukiwania dotyczących grafik i multimediów.

A wystarczy przypiąć własną subdomenę, typu media.twojadomena.com, skierować ją rekordem CNAME na zasób w chmurze, a następnie zweryfikować w Search Console. W praktyce oznacza to lepszy wgląd w to, jak Google widzi Twoje treści, plus mniej niespodzianek w stylu „czemu spadł ruch z grafik?”.

Co nam to daje?

1. podgląd błędów indeksowania plików
2. wykrywanie problemów z bezpieczeństwem (Safe Browsing)
3. statystyki widoczności multimediów w Google
4. łatwiejszą migrację między dostawcami chmury w przyszłości

Od miesięcy branża SEO skupiała swoją uwagę na AI Overviews (AIO), traktując je jako głównego “złodzieja kliknięć” na stronach wyników wyszukiwania. Logika wydawała się prosta: jeśli Google samo odpowiada na pytanie, użytkownik nie musi klikać linku. Najnowsze badanie od Seer Interactive pokazuje jednak, że problem jest znacznie głębszy i bardziej systemowy.

Najbardziej alarmującym sygnałem nie są spadki na zapytaniach z AIO. Prawdziwy wstrząs wywołują dane dotyczące tradycyjnych wyników: organiczny współczynnik klikalności (CTR) spada drastycznie, nawet gdy na stronie wyników (SERP) nie ma żadnego bloku AI.

Badanie przeprowadzone przez Seer Interactive (analizujące 25,1 miliona organicznych wyświetleń dla ponad 3100 zapytań informacyjnych w okresie czerwiec 2024 – wrzesień 2025) pokazuje, że:

• na zapytaniach bez obecności AI Overviews, organiczny CTR spadł o 41% rok do roku, osiągając we wrześniu 2025 poziom zaledwie 1,62%.
• na zapytaniach, gdzie AIO się pojawiło, katastrofa jest jeszcze większa (spadek o 61%, do poziomu 0,61% CTR), ale to dane z “czystych” SERP-ów powinny niepokoić najbardziej.

Źródło: https://www.seerinteractive.com/insights/aio-impact-on-google-ctr-september-2025-update

Okazuje się, że nawet jeśli uda Ci się wywalczyć wysoką pozycję, a Google łaskawie nie wyświetli odpowiedzi AI, użytkownik i tak jest znacznie mniej skłonny do kliknięcia Twojego linku niż jeszcze rok temu.

Dlaczego użytkownicy przestali klikać?

To kolejne badanie, które udowadnia zmiany w zachowaniach użytkowników. Problem przestał być związany z konkretnym elementem SERP; stał się problemem behawioralnym.

Google, poprzez agresywne wdrażanie AIO i rozbudowanych “featured snippets”, skutecznie “przeszkoliło” użytkowników. Nauczyliśmy się, że odpowiedź najprawdopodobniej znajduje się już na stronie Google. Użytkownicy skanują wyniki, nie znajdując natychmiastowej odpowiedzi (bo AIO nie ma), ale stracili już odruch klikania “w ciemno” w organiczne linki.

Z drugiej strony coraz większy odsetek zapytań (szczególnie informacyjnych) jest przejmowany przez alternatywne platformy. Użytkownicy wolą zapytać ChatGPT lub szukają odpowiedzi na TikTok i Reddit. Do Google trafiają już rzadziej, a gdy już tam są, ich intencja klikania jest mniejsza. Dlatego firmy, które myślą przyszłościowo, już dostosowują strategie i rozwijają kompetencje w obszarze AISO.

Jeśli wnikliwie analizujesz logi swojego serwera, być może zauważyłeś niedawno nowego gościa. Google-CWS to tak zwany “user-triggered fetcher”, czyli moduł pobierania uruchamiany przez działanie użytkownika. Jego zadaniem jest wyłącznie weryfikacja zasobów, które deweloperzy podają w panelu administracyjnym sklepu Chrome.

O jakie dane (i adresy URL) chodzi?

Kiedy programista zgłasza nowe rozszerzenie lub motyw do Chrome Web Store, musi wypełnić szereg pól w metadanych. Google-CWS jest narzędziem, które automatycznie “odwiedza” i sprawdza te adresy URL. Chodzi przede wszystkim o:

• Adresy URL Polityki Prywatności (kluczowe dla weryfikacji zgodności).
• Linki do strony domowej projektu lub dewelopera.
• Adresy URL prowadzące do wsparcia technicznego lub dokumentacji.
• Inne linki podane w manifeście lub opisie rozszerzenia.

Celem Google jest tutaj weryfikacja, czy podane linki są aktywne, czy nie prowadzą do stron wyłudzających dane (phishing) lub serwujących złośliwe oprogramowanie (malware). Jest to więc działanie administracyjne i zabezpieczające ekosystem CWS.

Najważniejszą techniczną implikacją dla specjalistów SEO i administratorów jest fakt, że Google-CWS, podobnie jak inne moduły “uruchamiane przez użytkownika” (np. Google Site Verifier), zazwyczaj ignoruje dyrektywy zawarte w pliku robots.txt. 

Jeśli deweloper świadomie podał adres URL swojej polityki prywatności, Google zakłada, że intencją dewelopera jest, aby Google mogło ten adres sprawdzić. Blokowanie tego adresu w robots.txt byłoby sprzeczne z działaniem podjętym przez samego dewelopera w sklepie Chrome.