Serwis poradnikowy z branży wyposażenia domu miał w raporcie indeksowania Google Search Console około 2000 zaindeksowanych adresów. Ruch organiczny w ciągu dwunastu miesięcy trafiał na 40 z nich. Pozostałe strony nie dawały ani kliknięć, ani konwersji, a mimo to regularnie odwiedzał je Googlebot. Ten opis to index bloat case study: pokazujemy, jak zakwalifikowaliśmy strony do usunięcia, co zrobiliśmy z każdą grupą i jak po dwunastu tygodniach wyglądały dane. Klient prosił o anonimowość, dlatego liczby są zaokrąglone, a nazwy podstron zmienione.
Punkt wyjścia: skąd wzięło się 2000 adresów
Serwis działał od sześciu lat i przeszedł dwie migracje CMS. Żadna z nich nie obejmowała porządków w treści, więc kolejne warstwy adresów nakładały się na siebie. Pierwszy crawl Screaming Frogiem i zestawienie go z sitemapą oraz eksportem z Search Console pokazały pięć głównych źródeł nadmiaru:
- około 620 stron tagów, z których większość zawierała jeden lub dwa wpisy,
- około 340 krótkich newsów z lat 2019–2021 (zapowiedzi targów, promocje partnerów, informacje o zmianach w ofercie),
- około 280 stron paginacji archiwów i kategorii,
- około 210 artykułów pisanych pod bardzo wąskie frazy, często na ten sam temat w kilku wariantach,
- około 150 stron załączników z mediami, które stary motyw wystawiał jako osobne adresy.
Resztę stanowiły strony ofertowe, kategorie i poradniki, które faktycznie zbierały ruch. Problem nie polegał na tym, że Google nie indeksował serwisu. Polegał na tym, że indeksował głównie rzeczy bez wartości, a nowe poradniki potrzebowały coraz więcej czasu, żeby w ogóle zostać pobrane. W raporcie stron pojawiało się też coraz więcej adresów ze statusem opisanym w tekście Wykryto, obecnie nie zaindeksowano, co przy serwisie tej wielkości jest sygnałem, że robot ma kłopot z wyborem, co warto odwiedzić.
Kwalifikacja stron: dane, które zdecydowały
Najważniejsza zasada brzmiała: żadna strona nie wypada z serwisu tylko dlatego, że jest stara albo krótka. Każdy adres dostał wiersz w arkuszu z sześcioma kolumnami danych:
- kliknięcia i wyświetlenia z Search Console za 16 miesięcy (maksymalny zakres w eksporcie przez API),
- sesje z wejść organicznych i nieorganicznych z GA4 za 12 miesięcy,
- liczba linków zewnętrznych i domen odsyłających (Ahrefs),
- liczba linków wewnętrznych prowadzących do strony,
- data ostatniej wizyty Googlebota z logów serwera,
- ocena merytoryczna: czy temat jest aktualny i czy ktoś w serwisie opisał go lepiej.
Na tej podstawie każdy adres trafiał do jednej z czterech grup: zostaje bez zmian, zostaje do odświeżenia, scalamy z mocniejszą stroną, usuwamy. Granica była prosta: strona bez kliknięć, z mniej niż 50 wyświetleniami w 16 miesięcy, bez linków zewnętrznych i bez wartości tematycznej szła do usunięcia. Jeśli miała choćby jedną domenę odsyłającą albo wyświetlenia na frazy, które warto utrzymać, lądowała w grupie do scalenia. Podobną logikę dla pojedynczych artykułów opisujemy w tekście o tym, jak przeprowadzić audyt treści i zdecydować między odświeżeniem a usunięciem.
Osobno sprawdziliśmy strony, do których nie prowadził żaden link wewnętrzny. Było ich około 190 i w większości były to stare newsy dostępne wyłącznie z sitemapy. Metodę łączenia crawla, sitemapy i danych z Search Console opisuje artykuł o tym, jak wykryć strony sieroty. W tym projekcie sieroty okazały się najłatwiejszą grupą: prawie żadna nie miała ruchu ani linków.
Co usunięto, co scalono, a co zostawiono
Po trzech tygodniach pracy nad arkuszem podział wyglądał następująco:
| Grupa | Liczba adresów | Działanie |
|---|---|---|
| Usunięte | ok. 1050 | status 410 lub noindex (paginacja) |
| Scalone | ok. 160 | treść przeniesiona, przekierowanie 301 |
| Do odświeżenia | ok. 90 | aktualizacja treści w kolejnym kwartale |
| Bez zmian | ok. 700 | strony ofertowe, kategorie, mocne poradniki |
Wśród usuniętych znalazły się prawie wszystkie tagi, strony załączników, nieaktualne newsy i większość artykułów pisanych pod warianty jednej frazy. Scalanie dotyczyło głównie poradników, które dzieliły jeden temat na kilka cienkich tekstów, na przykład osobne artykuły o doborze rozmiaru, koloru i materiału tego samego produktu. Zamiast trzech stron po 400 słów powstawała jedna, pełniejsza, a stare adresy przekierowywały na nią. To ten sam mechanizm, który opisywaliśmy przy okazji sklepu odzyskującego ruch po usunięciu kanibalizacji: kilka słabych stron rywalizujących o tę samą intencję przegrywa z jedną mocną.
Paginacji nie usuwaliśmy, bo jest potrzebna do nawigacji. Strony drugiej i dalszych stron archiwów dostały meta robots noindex, follow, a archiwa tagów zniknęły z menu i z szablonu wpisu.
Techniczna strona operacji: 410, przekierowania i sitemapa
Dla adresów bez następcy wybraliśmy status 410 zamiast 404. Według dokumentacji Google oba kody prowadzą do usunięcia strony z indeksu, a Google Search Central opisuje je jako równoważne dla indeksowania. W praktyce 410 dawał nam czytelny podział w logach: od razu było widać, które adresy usunęliśmy świadomie, a które zwracają 404 przez błąd.
Przy przekierowaniach obowiązywała jedna reguła: 301 tylko na stronę, która faktycznie odpowiada na tę samą intencję. Przekierowanie usuniętego newsa na stronę główną albo na kategorię to w oczach Google zwykle soft 404, więc w takich przypadkach woleliśmy 410. Wszystkie przekierowania były jednokrokowe, bez łańcuchów prowadzących przez stare adresy z poprzednich migracji.
Sitemapę wygenerowaliśmy od nowa: zawierała tylko adresy ze statusem 200, indeksowalne i kanoniczne, czyli około 790 pozycji. Przez pierwsze cztery tygodnie utrzymywaliśmy też osobną, tymczasową sitemapę z usuniętymi adresami, żeby Googlebot szybciej je odwiedził i zobaczył nowy status. Po tym czasie została wycofana. Linki wewnętrzne do usuniętych i scalonych stron poprawiliśmy w treści, żeby robot nie trafiał na przekierowania z wnętrza serwisu.
Co działo się z ruchem w kolejnych tygodniach
Pierwsze dwa tygodnie nie przyniosły widocznej zmiany w kliknięciach. Najszybciej zareagowały logi: udział wizyt Googlebota na stronach zwracających 200 i wartych indeksowania wzrósł z około 35% do około 70% w ciągu miesiąca. Liczba zaindeksowanych adresów w Search Console spadała stopniowo i po ośmiu tygodniach zatrzymała się w okolicach 820.
Ruch zmieniał się wolniej. W tygodniach 3–6 kliknięcia na pozostawionych stronach rosły o kilka procent tydzień do tygodnia, przy czym część wzrostu dotyczyła stron, które przejęły treść i przekierowania po scaleniu. Po dwunastu tygodniach suma kliknięć organicznych była o około 30% wyższa niż w analogicznym okresie przed zmianami. Liczba stron, które zebrały co najmniej jedno kliknięcie, wzrosła z 40 do około 110, głównie dzięki poradnikom, które wcześniej czekały w kolejce do pobrania.
Trzeba tu uczciwie zaznaczyć ograniczenia. W okresie pomiaru Google nie ogłosił dużej aktualizacji rdzeniowej, ale sezonowość branży mogła dodać kilka punktów procentowych. Nie mamy też grupy kontrolnej, bo całą operację przeprowadzono na jednym serwisie jednocześnie. Kierunek zmian jest jednak spójny w trzech niezależnych źródłach: w logach, w raporcie indeksowania i w kliknięciach. Google w dokumentacji o zarządzaniu budżetem indeksowania zastrzega, że temat dotyczy głównie dużych serwisów. Ten przypadek pokazuje, że przy 2000 adresach problemem nie był sam budżet, tylko to, na co robot go wydawał.
Czego byśmy nie powtórzyli
Po zamknięciu projektu zostały trzy wnioski, które dziś zmienilibyśmy w procesie.
Po pierwsze, usunęliśmy około 30 newsów, które miały pojedyncze linki zewnętrzne z serwisów branżowych. Arkusz je wychwycił, ale progi uznały je za zbyt słabe. Lepiej byłoby przekierować je na najbliższy tematycznie poradnik, bo koszt takiej decyzji jest zerowy, a link pozostaje w obiegu.
Po drugie, wszystkie usunięcia poszły jednego dnia. Gdyby coś poszło źle, nie dałoby się wskazać, która grupa zaszkodziła. Bezpieczniej jest wdrażać zmiany partiami: najpierw strony załączników i tagi, po dwóch tygodniach newsy, na końcu scalanie poradników. Każda partia daje wtedy osobny punkt pomiaru.
Po trzecie, nie zabezpieczyliśmy się przed powrotem problemu. Pół roku po projekcie redakcja znów zaczęła dodawać tagi do każdego wpisu, a motyw ponownie wystawił ich archiwa. Cięcie treści bez zmiany procesu publikacji daje efekt na kilka kwartałów, a nie na stałe. Dziś do każdego takiego projektu dodajemy regułę w szablonie, która blokuje indeksowanie archiwów z mniej niż pięcioma wpisami, oraz kwartalny przegląd stron bez kliknięć.
FAQ
Czym jest index bloat?
To sytuacja, w której w indeksie wyszukiwarki znajduje się dużo adresów o niskiej wartości: tagi, paginacja, załączniki, duplikaty czy nieaktualne newsy. Takie strony zajmują czas robota i rozmywają sygnały jakości serwisu, a jednocześnie nie przynoszą ruchu.
Czy usuwanie stron może obniżyć ruch?
Tak, jeśli usuniemy strony, które mają kliknięcia, wyświetlenia na wartościowe frazy albo linki zewnętrzne. Dlatego kwalifikacja musi opierać się na danych z Search Console, analityki i narzędzi do analizy linków, a nie na samym wieku czy długości tekstu.
Lepiej użyć 404 czy 410 dla usuniętych stron?
Dla Google oba kody działają podobnie i prowadzą do usunięcia adresu z indeksu. 410 wyraźniej komunikuje, że strona została usunięta celowo, i ułatwia późniejszą analizę logów.
Kiedy scalić treść zamiast ją usuwać?
Gdy kilka stron odpowiada na tę samą intencję albo gdy strona ma linki zewnętrzne lub wyświetlenia, ale jest zbyt cienka, żeby rankować samodzielnie. Treść przenosimy na najmocniejszy adres, a pozostałe przekierowujemy na niego kodem 301.
Po jakim czasie widać efekty cięcia treści?
W tym przypadku zmiany w logach serwera były widoczne po kilku dniach, spadek liczby zaindeksowanych adresów trwał około ośmiu tygodni, a wyraźny wzrost kliknięć pojawił się w okolicach szóstego tygodnia i utrzymał się po dwunastu.