Google: strony udostępniane przez link powinny mieć noindex. Nowa sekcja w przewodniku o spamie

Google dopisał do swojego przewodnika o spamie generowanym przez użytkowników nową sekcję: „Indeksuj tylko treści przeznaczone dla wyszukiwarki”. Zmiana z 26 października 2026 roku jest skierowana do platform, na których użytkownicy tworzą linki do udostępniania, wygenerowane wyniki, strony współpracy i mini aplikacje. Rekomendacja jest prosta: takie strony domyślnie powinny dostać noindex albo blokadę w robots.txt.

Na pierwszy rzut oka to kosmetyczna poprawka w dokumentacji Search Central. W praktyce Google po raz pierwszy wprost nazywa problem, który od dwóch lat narasta razem z popularnością czatbotów, generatorów stron i narzędzi typu „zbuduj aplikację w przeglądarce”: miliony adresów URL tworzonych przez użytkowników, które nigdy nie miały trafić do wyników wyszukiwania, a mimo to są indeksowane, rankują i bywają wykorzystywane przez spamerów.

Kontekst: przewodnik, który dotąd mówił o forach i komentarzach

Dokument „Prevent User-Generated Spam on Your Site” to jeden z najstarszych tekstów pomocy Google dotyczących nadużyć. Przez lata koncentrował się na klasycznych źródłach śmieciowych treści: komentarzach pod wpisami, profilach na forach, księgach gości i kontach zakładanych masowo przez boty. Zalecenia były znane każdemu administratorowi: moderacja, CAPTCHA, listy blokad, atrybuty rel=”ugc” i rel=”nofollow” na linkach użytkowników.

Poprzednia duża aktualizacja tego dokumentu, z 10 grudnia 2025 roku, dodała sugestię, by posty nowych użytkowników oznaczać jako noindex, dopóki konto nie zbuduje reputacji. Ta rada pozostaje bez zmian. Nowością jest to, że Google wyszedł poza model „forum plus komentarze” i opisał zupełnie inną klasę stron: treści, które użytkownik tworzy nie po to, żeby ktoś je wyszukał, tylko po to, żeby wysłać komuś link.

Zmieniło się też zdanie otwierające przewodnik. Wcześniej mówiło o spamerach zakładających wiele witryn. Teraz wymienia wprost „narzędzia, które pozwalają użytkownikom publikować udostępniane strony, wygenerowane treści lub aplikacje webowe”, a o spamerach pisze, że mogą tworzyć wiele „stron lub witryn”. W dzienniku zmian Search Central aktualizacja opisana jest jako dotycząca „blokowania indeksowania treści udostępnianych przez link”.

Kluczowe fakty: co dokładnie napisał Google

Nowa sekcja jest krótka, ale sformułowana jednoznacznie. Google zaczyna od pytania kontrolnego: jeśli Twoja usługa pozwala użytkownikom tworzyć udostępniane strony, wygenerowane wyniki albo interaktywne narzędzia, zastanów się, czy te treści mają być znajdowane przez wyszukiwarki, czy tylko otwierane bezpośrednio przez osoby, które dostały link.

Dalej pada właściwa rekomendacja. Gdy strony powstają z myślą o bezpośrednim udostępnianiu, współpracy lub użyteczności, a nie o publicznym odkrywaniu w wyszukiwarce, należy zastosować regułę noindex (przez metatag robots lub nagłówek HTTP X-Robots-Tag) albo domyślnie zablokować ich crawlowanie w robots.txt.

Nowe zalecenia dotyczące monitoringu

Druga część aktualizacji rozbudowuje sekcję o monitorowaniu nadużyć. Google zaleca:

• zweryfikowanie witryny lub subdomeny w Search Console, żeby otrzymywać e-maile o działaniach ręcznych i problemach z bezpieczeństwem,
• regularne sprawdzanie raportu indeksowania stron i raportu skuteczności pod kątem nieoczekiwanych skoków liczby zaindeksowanych stron, wyświetleń lub zapytań, które nie pasują do charakteru platformy,
• śledzenie metryk tworzenia i indeksowania na poziomie całej platformy oraz ustawienie alertów na anomalie, na przykład nagły wzrost liczby nowych publicznych stron albo sytuację, w której niewielka grupa użytkowników generuje dużą część indeksowalnych adresów.

Ten ostatni punkt jest szczególnie wymowny. Google opisuje tu wprost wzorzec typowy dla nadużyć: kilka kont, które produkują tysiące stron z linkami, przekierowaniami lub treściami pod frazy hazardowe czy farmaceutyczne. Platforma, która nie widzi tego w swoich własnych danych, zwykle dowiaduje się o problemie dopiero z powiadomienia o działaniu ręcznym.

Dlaczego właśnie teraz: lekcja z udostępnianych rozmów z AI

Google nie podaje w dokumentacji konkretnego powodu zmiany, ale tło jest dobrze znane branży. W ostatnich latach kilka razy wybuchały afery wokół udostępnianych rozmów z czatbotami, które trafiały do indeksu wyszukiwarki. Użytkownicy klikali „udostępnij”, przekonani, że link zobaczy tylko adresat, a po kilku dniach treść rozmowy, czasem z danymi osobowymi czy szczegółami zawodowymi, dało się znaleźć zwykłym zapytaniem z operatorem site:. Najgłośniejsze przypadki dotyczyły ChatGPT i Groka, a po fali krytyki dostawcy wycofywali opcje „wykrywalności” i dokładali blokady indeksowania.

Ten sam mechanizm działa w narzędziach do generowania stron, prezentacji, quizów, kalkulatorów czy aplikacji webowych tworzonych promptem. Każde kliknięcie „opublikuj” tworzy nowy publiczny URL na domenie dostawcy, często z wysokim autorytetem. Dla spamera to idealne środowisko: nie trzeba kupować domeny ani budować jej historii, wystarczy założyć konto i wygenerować setki stron, które dziedziczą zaufanie całej platformy. To bliski krewny zjawiska znanego jako site reputation abuse, z tą różnicą, że tu nie ma nawet umowy partnerskiej: wystarczy darmowe konto.

Warto zauważyć, że aktualizacja przyszła kilka tygodni po zakończeniu wrześniowego spam update’u Google, przy którym raportowano wzrost liczby ręcznych kar. Google konsekwentnie przesuwa odpowiedzialność za jakość indeksu na właścicieli platform, które ten indeks zasilają.

Noindex czy robots.txt? Tu jest haczyk

Najciekawszym technicznie elementem nowej sekcji jest to, że Google stawia obie metody obok siebie, jakby były równoważne. Tymczasem jego własna dokumentacja mówi coś innego, na co zwrócił uwagę Matt G. Southern w analizie opublikowanej przez Search Engine Journal.

Po pierwsze, strona pomocy o regule noindex wyjaśnia, że działa ona tylko wtedy, gdy robots.txt nie blokuje danego adresu. Jeśli crawl jest zablokowany, Googlebot nigdy nie zobaczy metatagu ani nagłówka, więc reguła noindex zostaje zignorowana. Po drugie, wprowadzenie do robots.txt przypomina, że zablokowana strona nadal może zostać zaindeksowana, jeśli prowadzą do niej linki z innych witryn. Wtedy w wynikach pojawia się sam adres URL, czasem z tekstem anchora, ale bez opisu.

Dla platform udostępniania to nie jest teoretyczny problem. Linki do udostępnionych treści trafiają na fora, do mediów społecznościowych, agregatorów i komunikatorów z publicznymi podglądami. Blokada w robots.txt nie powstrzyma więc indeksowania samego adresu, a w niektórych przypadkach sam adres i anchor mówią wystarczająco dużo.

Google sam to potwierdza na zaktualizowanej 21 października stronie „Control what you share”, gdzie robots.txt opisano jako skuteczne dla obrazów i wideo, a noindex jako metodę dla wszystkich typów treści. Jeśli w raporcie indeksowania pojawia się status „Zaindeksowana, mimo blokady w pliku robots.txt”, pomoc Google zaleca zdjęcie blokady i zastosowanie noindex.

Southern przytacza też własny test z lipca: ścieżka udostępniania w Claude była zablokowana w robots.txt dyrektywą Disallow, a jednocześnie strony udostępniania zwracały nagłówek X-Robots-Tag z wartością „none”, którą Google traktuje jak noindex plus nofollow. To klasyczne zabezpieczenie „pas i szelki”, ale z perspektywy Googlebota nagłówek jest niewidoczny, dopóki obowiązuje blokada crawla. Autor przyznaje, że nie był w stanie ustalić, co Google zobaczył przy pierwszym odkryciu tych linków.

Praktyczna reguła

Dla stron, które mają na pewno nie trafić do wyników, bezpieczniejsza kolejność jest odwrotna niż intuicyjna: najpierw noindex (najlepiej nagłówkiem X-Robots-Tag, bo działa także dla plików PDF i odpowiedzi, które nie są HTML), a crawl pozostaje otwarty, żeby Googlebot mógł regułę odczytać. Robots.txt warto rozważyć dopiero wtedy, gdy adresy już wypadły z indeksu, a celem jest oszczędzanie zasobów crawla. Ten sam dylemat znają sklepy internetowe, które od lat zmagają się z filtrami i nawigacją fasetową.

Co to znaczy dla SEO i AIO

Dla właścicieli platform SaaS i narzędzi AI

Jeśli Twój produkt ma funkcję „udostępnij link”, „opublikuj wynik” albo „wygeneruj stronę”, ta aktualizacja jest de facto checklistą wdrożeniową. Domyślne ustawienie powinno chronić przed indeksacją, a wyjątkiem ma być świadoma decyzja użytkownika o publicznym, wyszukiwalnym profilu czy portfolio. Platformy, które tego nie zrobią, ryzykują nie tylko spam pod własną domeną, ale też utratę zaufania algorytmów do całej witryny, łącznie z jej marketingowymi podstronami.

Osobna kwestia to prywatność. W Polsce i całej Unii indeksacja treści, które użytkownik uważał za prywatne, to potencjalny problem z RODO, a nie tylko z SEO. Dokumentacja Google daje teraz zespołom produktowym mocny argument, by blokadę indeksowania traktować jako wymóg, a nie „miły dodatek”.

Dla specjalistów SEO

Warto przejrzeć serwisy klientów pod kątem sekcji tworzonych przez użytkowników: koszyki z możliwością udostępnienia, listy życzeń, konfiguratory produktów, raporty generowane w panelu, kalkulatory z zapisanym wynikiem. Każdy z tych elementów może produkować unikalne adresy URL, które zaśmiecają indeks, rozpraszają budżet crawlowania i obniżają ocenę jakości całej domeny. Jeśli w Search Console widać nagły wzrost liczby stron w stanie „Zaindeksowana”, który nie odpowiada publikacjom redakcyjnym, to pierwszy sygnał, by sprawdzić te mechanizmy. Pomocna bywa tu lista kontrolna z tekstu o przyczynach problemów z indeksowaniem, czytana w odwrotną stronę: co jest w indeksie, choć nie powinno.

Dla widoczności w AI

Wątek AIO jest mniej oczywisty, ale istotny. Systemy odpowiedzi AI, w tym AI Overviews i AI Mode, korzystają z indeksu wyszukiwarki jako podstawy groundingu. Strony udostępniania, które trafiają do indeksu, mogą być cytowane jako źródła, nawet jeśli zawierają przypadkową rozmowę z czatbotem lub wygenerowany tekst bez weryfikacji. Ograniczenie ich indeksacji to więc także sposób na ograniczenie „echa”, w którym modele cytują treści wygenerowane przez inne modele. Z drugiej strony dostawcy, którzy chcą, by publiczne wyniki ich narzędzi budowały rozpoznawalność marki w odpowiedziach AI, muszą teraz bardziej świadomie wybierać, które strony otwierają dla robotów.

Reakcje branży

Pierwsze komentarze w środowisku SEO skupiają się na dwóch wątkach. Pierwszy to wspomniana niespójność między zaleceniem „noindex albo robots.txt” a resztą dokumentacji Google. Według analizy Search Engine Journal wiele platform stosuje obie metody jednocześnie, co w praktyce może osłabiać skuteczność noindex, bo Googlebot nie ma jak go odczytać. Specjaliści techniczni sugerują, by w audytach traktować taką kombinację jako błąd konfiguracji, a nie podwójne zabezpieczenie.

Drugi wątek dotyczy odpowiedzialności. Część branży odczytuje aktualizację jako sygnał, że Google nie zamierza sam filtrować ogromnej liczby stron generowanych przez użytkowników, tylko oczekuje, że platformy zrobią to u źródła. To spójne z kierunkiem widocznym od dłuższego czasu: wytyczne dotyczące nadużyć reputacji witryny, ręczne działania wobec sekcji partnerskich na dużych portalach i coraz bardziej szczegółowe wymagania wobec treści generowanych przez AI.

Pojawiają się też głosy sceptyczne. Rekomendacja ma formę „rozważ” i „zastosuj”, a nie twardej zasady z wytycznych dotyczących spamu, więc nie wiadomo, czy platformy, które jej nie wdrożą, faktycznie poniosą konsekwencje. Z drugiej strony przewodnik o spamie użytkowników od lat działa jako zaplecze argumentacyjne przy działaniach ręcznych: jeśli Google nałoży karę na platformę zalaną spamem, nowa sekcja będzie pierwszym dokumentem, do którego się odwoła.

Co dalej

W najbliższych tygodniach warto obserwować trzy rzeczy. Po pierwsze, czy duże platformy AI i narzędzia no-code zmienią domyślne ustawienia stron udostępniania, na przykład przechodząc z blokady w robots.txt na samo X-Robots-Tag. Po drugie, czy Google doprecyzuje sprzeczność między nową sekcją a dokumentacją noindex, co zdarzało się już przy wcześniejszych aktualizacjach Search Central. Po trzecie, czy w raportach Search Console pojawią się nowe sygnały lub powiadomienia związane z masowym tworzeniem stron przez użytkowników.

Dla właścicieli serwisów lista działań na teraz jest krótka:

• zinwentaryzować wszystkie mechanizmy, które tworzą publiczne adresy URL z inicjatywy użytkownika,
• ustawić dla nich domyślnie noindex przez nagłówek X-Robots-Tag lub metatag robots i nie blokować ich jednocześnie w robots.txt,
• sprawdzić w raporcie indeksowania status „Zaindeksowana, mimo blokady w pliku robots.txt” i naprawić konfigurację tam, gdzie się pojawia,
• wdrożyć alerty na poziomie platformy: dzienna liczba nowych publicznych stron, udział top 1% kont w liczbie indeksowalnych URL-i,
• zweryfikować w Search Console każdą subdomenę, na której użytkownicy mogą publikować.

Zmiana w przewodniku nie jest aktualizacją algorytmu i nie wpłynie z dnia na dzień na pozycje. To jednak jasny sygnał, gdzie Google widzi kolejne źródło spamu i kto ma za nie odpowiadać. Platformy, które potraktują to poważnie teraz, unikną nerwowego sprzątania indeksu po pierwszym powiadomieniu o działaniu ręcznym.

FAQ