Czaty ChatGPT są indeksowane przez Google

Mniej niż 24 godziny temu sprytni specjaliści SEO podzielili się ciekawym odkryciem: Publiczne /share konwersacje ChatGPT były w pełni indeksowalne, a część z nich już pojawiała się w top 20 Google na długie frazy. To znalezisko brzmiało jak cyfrowa alchemia — natychmiastowy, autorytatywny content, którego nie trzeba było pisać. Na Twitterze pojawiły się zrzuty ekranu, powstały wpisy na blogach, a kilku oportunistów zaczęło nawet scrapować czaty, by tworzyć błyskawiczne strony afiliacyjne.

Wtedy spadł grom.

Do następnego ranka każdy wynik /share zniknął z indeksu Google. Wpisz dziś site:chatgpt.com/share, a zobaczysz zero wyników. OpenAI po cichu wdrożyło trzy zmiany jedna po drugiej — <meta name="robots" content="noindex">, globalny canonical prowadzący do strony głównej oraz (najprawdopodobniej) hurtowe zgłoszenie przez Narzędzie do usuwania adresów URL Google. „ChatGPT share URLs” stało się podręcznym case study błyskawicznej deindeksacji w Google.

Szybka ankieta wśród 225 założycieli uchwyciła zmianę nastrojów:

Stawka nie mogłaby być bardziej oczywista:

• Utracone cytowania: Każdy asystent AI lub serwis newsowy, który cytował Twój czat /share, traci wartość linku, gdy Google usuwa stronę.

• Luka w widoczności AI: LLM-y trenowane na świeżych zrzutach sieci traktują indeks Google jako sygnał zaufania. Brak indeksu — brak cytowania.

• Przepaść w ruchu organicznym: Jeśli Google może zepchnąć Cię z SERP-ów w jednym cyklu crawlu, Twój strumień treści jest tak silny, jak Twoja dyscyplina zgodności.

Wczorajszy „hak” wzrostu stał się dzisiejszą przestrogą — dowód, że gdy polegasz na lukach zamiast na trwałych fundamentach SEO, droga od rankingu do zniknięcia to jeden odświeżenie Google.

Jak strony /share w ogóle trafiły do indeksu

1. Robots.txt zostawił szeroko otwarte drzwi
   Kiedy ChatGPT uruchomił publiczną funkcję „Share”, jego plik robots.txt jawnie zezwalał na crawlowanie /share/ pod User-agent: *. Dla Googlebota to zielone światło, by pobrać, wyrenderować i traktować każdą udostępnioną rozmowę jak zwykłą stronę HTML.

2. Tajny arsenał Google do odkrywania ukrytych URL-i
   Nawet jeśli żadna strona nie linkowała do tych adresów, Google wciąż potrafi je odnaleźć dzięki pasywnym źródłom danych, które społeczność SEO nazywa „side-channelami Google”.

   • Podpowiedzi URL w Chrome — gdy miliony użytkowników wklejają link /share w omnibox lub klikają go wewnątrz ChatGPT, telemetria Chrome przekazuje anonimowe próbki adresów do harmonogramu crawla Google.

   • Android Link Resolver — każde tapnięcie w URL /share w aplikacji na Androidzie generuje intent, który trafia do diagnostyki Play Services.

   • Skanowanie Gmail & Workspace — czaty udostępnione mailowo między współpracownikami są skanowane pod kątem phishingu; bezpieczne URL-e trafiają do kolejki crawla.

   • Heurystyki Public DNS & QUIC — duża liczba zapytań DNS do tego samego katalogu sygnalizuje „ta ścieżka jest ważna”.

   Wniosek: Brak linków wewnętrznych ≠ brak odkrycia. Google nie potrzebuje grafu hyperlinków, gdy sama aktywność użytkowników wskazuje nowe URL-e.

3. Treści generowane przez AI wyglądają na świeże i unikalne
   Każda strona /share zawierała nowy tekst, który nie był zduplikowany w innych miejscach, więc klasyfikator świeżości Google przypisał jej natychmiastową wartość. Połączenie dostępnego crawlowania i unikalnej treści ekspresowo wprowadziło strony do indeksu — niektóre w ciągu kilku godzin od pierwszego udostępnienia.

Szybkie sprzątanie Google: czteropunktowa akcja

Dlaczego Google mogło zareagować w ciągu 24 godzin

• Priorytet dla dużych marek: Domeny o wysokim autorytecie są crawlowane częściej, więc zmiany dyrektyw propagują się szybciej.

• Ręczne popchnięcie: OpenAI niemal na pewno użyło „Pobierz jako Google” w Search Console, by wymusić odświeżenie kluczowych stron po wdrożeniu nowych tagów.

• Automatyczne unikanie kary: Systemy anty-spamowe Google karzą cienkie lub niekontrolowanie skalowane treści generowane przez użytkowników; OpenAI miało silny motyw, by zneutralizować ryzyko, zanim rozległaby się czarnohatowa degradacja ogólnosetowa.

Gdy wszystkie cztery dźwignie zostaną pociągnięte, adresy /share stają się niewidoczne dla wyszukujących i niewykorzystywalne jako cytaty w SERP-ach. Lekcja dla SEO jest jasna: jeśli ścieżka o dużym ruchu nagle niesie ryzyko dla marki lub zgodności, noindex + canonical + usunięcie URL to najszybsze potrójne zagranie, aby ją ukryć — zanim algorytmy karne Google zrobią to za Ciebie.

Milionowy kac Binga

Plan sprzątania OpenAI zatrzymał się na Google Search Console. W rezultacie Bing wciąż pokazuje ~1 milion /share stron w wynikach — cyfrowe miasto duchów rozmów ChatGPT, które w Google są już niewidoczne. Ta rozbieżność podkreśla trzy strukturalne różnice między silnikami:

1. Opóźnienie od crawla do indeksu – Googlebot odwiedza domeny o wysokim autorytecie co kilka godzin; Bingbot potrzebuje często dni. Gdy OpenAI dodało noindex i canonicale, Google szybko je odczytał i zastosował. Bing po prostu nie przerobił jeszcze swojego backlogu.

2. Brak interwencji w BWT – Narzędzia do usuwania URL-i i przyspieszania recrawla Binga znajdują się w Bing Webmaster Tools. Wszystko wskazuje, że OpenAI pominęło ten panel, więc Bingbot nadal stosuje pierwotną dyrektywę „Allowed”, dopóki naturalny cykl nie przetworzy zmian.

3. Historyczny wzorzec opóźnień – To nic nowego. W 2021 r. Bing nadal serwował favicony WordPressa tygodnie po ich usunięciu z Google, a w zeszłym roku zindeksował wycieknięty katalog font-CSS, który Google zignorował. Mniejsza flota botów i ostrożne okna wdrożeń sprawiają, że Bing ma skłonność do kaców indeksacyjnych, gdy znana witryna gwałtownie zmienia dyrektywy.

Wniosek dla SEO: Jeśli polegasz na ruchu z Binga — lub na cytatach ChatGPT wspieranych indeksem Binga — pracuj na dwóch panelach. Składaj prośby o usunięcie lub ponowny crawl zarówno w Search Console, jak i w Bing Webmaster Tools, albo przygotuj się na dłuższy czyściec, w którym dwa silniki pokazują dwie różne rzeczywistości.

Dlaczego w Bing dominują nieanglojęzyczne wyniki /share

Ciekawym efektem opóźnienia Binga jest to, że ocalałe strony /share to w przytłaczającej większości nieanglojęzyczne, nielatyniczne wyniki — japońskie, rosyjskie, arabskie, tajskie. Wyjaśniają to trzy czynniki:

1. Regionalne fragmenty indeksu aktualizują się wolniej – Bing dzieli indeks według lokalizacji. Najszybciej odświeża się ruchliwy US-EN; poboczne języki mogą czekać tydzień lub dłużej, zanim noindex zostanie przeprocesowany.

2. Priorytetyzacja klastrów duplikatów – Algorytm deduplikacji Binga utrzymuje jeden URL na klaster kanoniczny. Gdy angielskie wersje zniknęły z Google i straciły link equity, Bing zwiększył wagę unikalnych wariantów nieanglojęzycznych, które wciąż miały sygnały zaangażowania użytkowników.

3. Różnica między serwowaniem a indeksowaniem – Bing może oznaczyć URL jako „deindeksowany” wewnętrznie, ale nadal serwować go w lokalizacjach o małej konkurencji do czasu kolejnego pełnego cyklu wdrożeniowego. Ta luka tłumaczy, dlaczego zapytania w języku arabskim wciąż wyświetlają strony /share, nawet gdy licznik w indeksie Binga zaczyna spadać.

Wskazówka optymalizacyjna: Monitorowanie, które języki znikają jako pierwsze, to lekcja na żywo o budżecie crawlowania i modelu zaufania każdego silnika. Dla witryn wielojęzycznych stopniowe wdrażanie dyrektyw (np. najpierw EN, potem JP) może tworzyć niezamierzone okna z duplikatami. Bezpieczniejsza taktyka SEO to wdrożyć aktualizacje noindex i canonical globalnie, a następnie potwierdzić ich skuteczność w każdym centrum danych, korzystając z VPN-ów do sprawdzania SERP-ów.