Rozmowy z ChatGPT trafiły do indeksu Google

TL;DR: Udostępnione rozmowy z ChatGPT pojawiły się w wynikach Google, a potem zniknęły w mniej niż 24 godziny. Poniżej pokazuję, co dokładnie się wydarzyło, co to oznacza dla SEO i co widzieliśmy w danych, które sami monitorowaliśmy, gdy wszystko działo się na żywo.

Mniej niż 24 godziny temu osoby z branży SEO, które szybko to wychwyciły, zaczęły podawać dalej całkiem sprytne odkrycie: publiczne rozmowy ChatGPT pod adresem /share dało się normalnie indeksować, a część z nich już pojawiała się w top 20 Google na długie, precyzyjne zapytania. To wyglądało jak cyfrowa alchemia — natychmiastowa, wiarygodna treść, której nie musiałeś nawet sam pisać. Screeny trafiły na Twittera, zaczęły wyskakiwać wpisy na blogach, a kilku oportunistów zdążyło nawet zeskrobywać te rozmowy pod szybkie strony afiliacyjne.

A potem Google ucięło temat.

Następnego ranka każdy wynik /share zniknął z indeksu Google. Jeśli dziś wpiszesz site:chatgpt.com/share, zobaczysz zero wyników. OpenAI po cichu wdrożyło trzy zmiany jedna po drugiej — <meta name="robots" content="noindex">, canonical dla całego serwisu wskazujący stronę główną i, najpewniej, zbiorcze zgłoszenie przez Narzędzie do usuwania adresów URL Google. Adresy „ChatGPT share URLs” stały się żywym przykładem błyskawicznego wyindeksowania w Google.

Co zobaczyliśmy w naszych danych

Monitorowaliśmy to w czasie rzeczywistym w SEOJuice. Gdy pierwsze sygnały pojawiły się na Twitterze, szybko sprawdziłem strony naszych klientów, żeby zobaczyć, czy jakieś adresy /share pokazują się jako konkurencyjne wyniki. Oto co znaleźliśmy:

• 3 domeny naszych klientów miały strony ChatGPT /share pojawiające się w tych samych SERP-ach dla długich zapytań. W jednym przypadku udostępniona rozmowa ChatGPT o „best CRM for real estate agents” zajmowała 14. pozycję dla zapytania, przy którym wpis blogowy naszego klienta był na 11. miejscu. To już wystarczająco blisko, żeby robiło się nieprzyjemnie.
• Jakość treści była bardzo nierówna. Niektóre udostępnione rozmowy były naprawdę solidne (użytkownik zadawał ChatGPT szczegółowe pytania uzupełniające, a cały wątek czytało się jak dobrze ułożony artykuł). Inne były bełkotliwymi pół-rozmowami, które nie powinny rankować na nic.
• Po usunięciu z indeksu: te trzy konkurencyjne strony /share zniknęły, ale pozycje naszych klientów nie poprawiły się od razu. SERP przetasowywał się przez kolejne 48 godzin, a wolne miejsca zajęły inne strony. To dobre przypomnienie, że usunięcie konkurenta z SERP-a nie oznacza automatycznego awansu dla ciebie — Google po prostu ocenia wszystkich kandydatów od nowa.

Cały epizod trwał zbyt krótko, żeby ktoś poniósł trwałe szkody. Ale zostawił po sobie pytanie, do którego ciągle wracam: co się stanie, gdy następna firma AI nie zareaguje tak szybko jak OpenAI?

Szybka ankieta wśród 225 założycieli firm dobrze oddała ten zwrot nastrojów:

Tu stawka nie mogłaby być bardziej oczywista:

• Utracone cytowania: Każdy asystent AI albo redakcja, która cytowała twój czat /share, traci wartość linka, gdy Google wymazuje tę stronę z indeksu.

• Luka w widoczności AI: LLM-y trenowane na świeżych migawkach sieci traktują indeks Google jako sygnał zaufania. Nie ma indeksu, nie ma cytowania.

• Urwisko ruchu organicznego: Jeśli Google może wyłączyć cię z SERP-a w jednym cyklu crawlowania, to twój system publikacji treści jest tak mocny, jak konsekwentnie pilnujesz zgodności z wytycznymi.

Wczorajszy „hack wzrostu” stał się dzisiejszą przestrogą — dowodem na to, że kiedy opierasz się na lukach zamiast na trwałych fundamentach SEO, od rankowania do zniknięcia dzieli cię czasem jedno odświeżenie Google.

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

To akurat uważam za najciekawszą część z perspektywy technicznego SEO, bo pokazuje, jak Google odkrywa i indeksuje treści nawet bez klasycznych sygnałów linkowych:

1. Robots.txt zostawił drzwi szeroko otwarte
   Gdy ChatGPT uruchomił publiczną funkcję „Share”, jego plik robots.txt wprost zezwalał na crawlowanie /share/ w sekcji User-agent: *. Dla Googlebota to zielone światło, żeby pobrać, wyrenderować i potraktować każdą udostępnioną rozmowę jak zwykłą stronę HTML. To raczej wygląda na przeoczenie niż świadomą decyzję — OpenAI skupiało się na samej funkcji udostępniania, a nie na jej konsekwencjach dla SEO. (Sam robiłem podobne błędy. Nasze środowisko stagingowe było indeksowalne przez trzy tygodnie, zanim ktoś to zauważył. Zdarza się.)

2. Ukryty arsenał Google do odkrywania adresów URL
   Nawet jeśli żadna strona nie linkowała do tych adresów, Google i tak mogło je znaleźć przez pasywne kanały danych, które społeczność SEO nazywa czasem „Google side-channels”.

   • Podpowiedzi adresów URL z Chrome — gdy miliony użytkowników wklejają link /share do paska adresu albo klikają go wewnątrz ChatGPT, telemetria Chrome dostarcza zanonimizowane próbki URL-i do systemu planującego crawl Google.

   • Android Link Resolver — każde stuknięcie linku /share wewnątrz aplikacji na Androidzie wywołuje intent rejestrowany przez diagnostykę Play Services.

   • Skanowanie Gmail & Workspace — udostępnione czaty wysyłane mailem między współpracownikami są skanowane pod kątem phishingu; adresy URL uznane za bezpieczne trafiają potem do kolejki crawlowania.

   • Heurystyki Public DNS & QUIC — duża liczba zapytań DNS dla tego samego podkatalogu sygnalizuje, że „ta ścieżka ma znaczenie”.

   Wniosek jest prosty: brak linków wewnętrznych nie oznacza braku odkrycia. Google nie potrzebuje klasycznego grafu linków, jeśli zachowanie użytkowników samo wskazuje nowe adresy URL. I to ma znaczenie nie tylko dla ChatGPT — jeśli masz na stronie publicznie dostępne treści tworzone przez użytkowników, Google prawdopodobnie znajduje je kanałami, których nawet nie bierzesz pod uwagę.

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 gdzie indziej, więc klasyfikator świeżości Google przypisał jej natychmiastową wartość. Połączenie dozwolonego crawlowania i unikalnej treści przyspieszyło wejście tych stron do aktywnego indeksu — część z nich w ciągu zaledwie kilku godzin od pierwszego udostępnienia.

Szybkie sprzątanie Google: naprawa w czterech ruchach

To, co czyni ten epizod pouczającym dla każdego, kto zarządza dużym serwisem, to szybkość i precyzja reakcji. Oto techniczny schemat działania, którego użyło OpenAI:

Ten czteroelementowy schemat — noindex + canonical + usunięcie adresów URL + robots.txt — naprawdę warto sobie zapisać. Jeśli kiedykolwiek będziesz musiał szybko usunąć z indeksu dużą sekcję serwisu (po wycieku środowiska stagingowego, przypadkowej publikacji albo eksplozji treści tworzonych przez użytkowników), to jest najszybsze dostępne podejście. Używaliśmy bardzo podobnego schematu przy trzech kryzysowych sytuacjach u klientów w ostatnim roku i konsekwentnie czyścił zaindeksowane adresy URL w 24-48 godzin.

Dlaczego Google mogło zareagować w mniej niż 24 godziny

• Priorytet dla dużych marek: Domeny z wysokim autorytetem są crawlowane częściej, więc zmiany dyrektyw rozchodzą się szybciej. Gdy chatgpt.com coś komunikuje Google, Google słucha szybko.

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

• Unikanie automatycznych kar: Systemy antyspamowe Google karzą thin content albo treści generowane przez użytkowników, jeśli skalują się bez kontroli; OpenAI miało mocną motywację, żeby zneutralizować ryzyko, zanim uruchomi się site-wide demotion.

Milion adresów URL kaca w Bing

Playbook sprzątania OpenAI zatrzymał się na Google Search Console. W efekcie Bing nadal pokazuje ~1 million /share pages w wynikach — cyfrowe miasto duchów z rozmowami ChatGPT, które są już niewidoczne w Google.

Tu historia robi się ciekawa z perspektywy SEO dla wielu wyszukiwarek. Sprawdziliśmy te same trzy zapytania klientów, dla których konkurencyjne strony /share pojawiały się w Google, i okazało się, że w Bing te strony wciąż rankowały jeszcze pełny tydzień później. Ta rozbieżność pokazuje trzy strukturalne różnice między silnikami:

1. Opóźnienie crawl-to-index — Googlebot wraca do domen o wysokim autorytecie w ciągu godzin; Bingbot często potrzebuje dni. Gdy OpenAI wdrożyło noindex i tagi kanoniczne, Google szybko przeszło ponowny crawl i zastosowało się do dyrektyw. Bing po prostu jeszcze nie przerobił swojego backlogu.

2. Brak interwencji w BWT — wszystko wskazuje na to, że OpenAI pominęło Bing Webmaster Tools, więc Bingbot nadal podążał za pierwotną dyrektywą „Allowed”, dopóki jego naturalny rytm nie wychwycił zmian.

3. Historyczny wzorzec opóźnień — to nic nowego. W 2021 Bing nadal pokazywał adresy URL favicon WordPressa tygodnie po tym, jak zostały usunięte z Google, a w zeszłym roku zaindeksował wyciekły katalog font-CSS, który Google zignorowało. Mniejsza flota botów Bing i bardziej zachowawcze okno aktualizacji sprawiają, że wyszukiwarka ma skłonność do kaca po indeksacji, gdy duży serwis nagle zmienia dyrektywy.

Praktyczny wniosek: Jeśli polegasz na ruchu z Bing — albo na cytowaniach w ChatGPT, które opierają się na indeksie Bing — prowadź podwójne dashboardy. Wysyłaj prośby o usunięcie lub ponowny crawl zarówno w Search Console, jak i w Bing Webmaster Tools. Po tym incydencie dodaliśmy to jako standardowy krok w naszym playbooku awaryjnego usuwania z indeksu, bo nauczył nas (trochę boleśnie), że „naprawione w Google” nie znaczy „naprawione wszędzie”.

Dlaczego nieangielskie wyniki /share dominują w Bing

Dziwny efekt uboczny opóźnienia Bing: ocalałe strony /share to w ogromnej większości wyniki nieangielskie i zapisane alfabetami innymi niż łaciński — japońskie, rosyjskie, arabskie, tajskie. Zauważyliśmy to, bo jeden z naszych klientów ma subdomenę w języku japońskim i widział więcej konkurencyjnych stron /share w Bing JP niż w Bing US. Tę przewagę da się wyjaśnić trzema czynnikami:

1. Regionalne wycinki indeksu aktualizują się wolniej — Bing dzieli indeks według lokalizacji. Najszybciej odświeżają się wycinki US-EN o dużym ruchu; peryferyjne segmenty językowe mogą czekać tydzień lub dłużej, zanim usuną strony z noindex.

2. Priorytetyzacja klastrów duplikatów — algorytm deduplikacji Bing zostawia jeden adres URL w klastrze kanonicznym. Gdy angielskie wersje zniknęły z Google i straciły część wartości linkowania wewnętrznego, Bing przesunął wagę na unikalne warianty nieangielskie, które nadal miały sygnały zaangażowania użytkowników.

3. Rozjazd między wyświetlaniem a indeksacją — Bing może oznaczyć adres URL jako „usunięty z indeksu” wewnętrznie, ale nadal pokazywać go w lokalizacjach o niskiej konkurencji aż do kolejnego pełnego cyklu wdrożeniowego.

Wniosek optymalizacyjny: W przypadku stron wielojęzycznych etapowe wdrażanie dyrektyw (np. najpierw EN, potem JP) może tworzyć niezamierzone okna zduplikowanej treści. Bezpieczniejsze podejście to wdrożenie noindex i aktualizacji tagów kanonicznych globalnie, a potem weryfikacja usunięcia w każdym lokalnym data center za pomocą kontroli SERP-ów przez VPN. Dodaliśmy to do naszej listy kontrolnej po wdrożeniu.

Powiązane materiały:

• Jak sprawić, żeby twoja marka pojawiała się w ChatGPT
• Dane i badania SEOJuice
• AI Visibility Checker