Zacznij od zdefiniowania, co właściwie mierzysz

Zanim otworzę jakikolwiek raport, ustalam definicję opóźnienia, bo redakcja i dział techniczny zwykle mierzą dwie różne rzeczy pod tą samą nazwą.

Rozdzielam trzy momenty: publikację w systemie redakcyjnym, pierwsze pobranie adresu przez robota i moment, w którym materiał daje się znaleźć w wyszukiwarce. Między pierwszym i drugim leży odpowiedzialność architektury serwisu. Między drugim i trzecim — jakość i kwalifikacja treści, na którą audyt techniczny wpływa tylko pośrednio. Potrzebuję do tego znacznika czasu z systemu redakcyjnego, wpisów z logów serwera i stanu w narzędziu kontroli adresu URL w Search Console. Bez logów zostaje domysł, więc dostęp do nich jest warunkiem sensownego audytu, a nie miłym dodatkiem.

Wynik zapisuję jako rozkład, nie średnią. Średni czas indeksowania jest wskaźnikiem bezużytecznym, bo w portalu współistnieją materiały odwiedzane w kilkadziesiąt sekund i takie, o które robot nie zahacza przez pół dnia. Interesuje mnie, czym te grupy się różnią: działem, szablonem, sposobem linkowania, autorem, godziną publikacji.

Budżet indeksowania w serwisie, który publikuje bez przerwy

Przy kilkuset stronach pojęcie budżetu indeksowania jest ciekawostką. Przy kilku milionach staje się realnym ograniczeniem, którym trzeba zarządzać.

Robot ma dla danego hosta pewną pulę żądań, wynikającą z tego, jak szybko serwer odpowiada i ile treści warto w tym serwisie odwiedzać. Kiedy pula idzie na adresy bez wartości, nowe materiały czekają w kolejce. Dlatego liczę proporcję: ile pobrań dotyczy treści redakcyjnych, a ile wszystkiego pozostałego. W dużych portalach wygląda ona zwykle źle, a przyczyny powtarzają się między serwisami:

• Nieskończone przestrzenie adresowe — filtry, sortowania, kalendarze archiwum, parametry sesji i identyfikatory kampanii doklejane do linków wewnętrznych. Każda kombinacja to osobny adres, który robot musi sprawdzić, żeby dowiedzieć się, że nic tam nie ma.

• Strony tagów mnożone automatycznie — redaktor może dodać dowolny tag, więc po latach serwis ma dziesiątki tysięcy takich stron, w większości z jednym materiałem.

• Głęboka paginacja archiwum i wersje techniczne — listingi ciągnące się przez tysiące stron, adresy do druku, galerie rozbite na podstrony, warianty z ukośnikiem i bez.

Nie zamykam tego odruchowo w pliku robots.txt, bo zablokowanie adresu nie usuwa go z indeksu i potrafi zerwać przepływ sygnałów wewnątrz serwisu. Rozdzielam decyzje: przestrzenie generowane parametrami odcinam u źródła, przestając je linkować, a to, co musi zostać dostępne dla ludzi, oznaczam tak, żeby nie było kandydatem do indeksowania.

Logi serwera i statystyki indeksowania

To jedyne miejsce, w którym widzę zachowanie robota, a nie własne wyobrażenie o nim.

Z logów wyciągam trzy przekroje. Rozkład pobrań na katalogi i typy szablonów pokazuje, gdzie idzie pula. Rozkład kodów odpowiedzi pokazuje, ile żądań kończy się przekierowaniem lub błędem — a każde przekierowanie to żądanie zużyte na dowiedzenie się, gdzie treść naprawdę jest. Rozkład w czasie pokazuje, czy robot zwalnia w godzinach szczytu, co jest sygnałem, że problemem jest wydajność, nie architektura.

Osobno patrzę na czas odpowiedzi widziany przez robota, nie przez narzędzia pomiaru z przeglądarki. Te dwie liczby często się rozjeżdżają, bo robot trafia w cache inaczej niż użytkownik i częściej dostaje odpowiedź generowaną od zera.

Raport statystyk indeksowania w Search Console traktuję jako uzupełnienie i szybki test hipotez — jest zagregowany, więc nie odpowie na pytanie o konkretny materiał, ale dobrze pokazuje trendy.

Architektura linkowania: gdzie nowy materiał pojawia się jako pierwszy

Robot nie dowiaduje się o nowym tekście z powietrza. Musi go zobaczyć w linku na stronie, którą odwiedza często.

Sprawdzam więc, na jakich stronach nowy materiał ląduje w pierwszej minucie po publikacji i jak szybko te strony są odświeżane po stronie serwera. W portalach, w których strona główna jest w całości składana po stronie przeglądarki, a nowe wpisy dochodzą asynchronicznie, robot widzi listing z opóźnieniem albo nie widzi go wcale. To jedna z najczęstszych przyczyn, dla których materiał czeka.

Druga to głębokość. Liczę, ile kliknięć od strony głównej dzieli świeżo opublikowany tekst i porównuję to między działami. Dział bez własnego linku w nawigacji, dostępny tylko z listingu kategorii trzeciego poziomu, będzie systematycznie indeksowany później. To nie jest kwestia jakości tekstów, tylko topologii serwisu.

Trzecia rzecz to linkowanie z materiałów o dużym ruchu do świeżych publikacji. Sekcje z powiązanymi tekstami generowane statycznie raz na dobę nie pomagają w niczym; te aktualizowane przy każdym żądaniu bywają najskuteczniejszym kanałem odkrywania w całym serwisie.

Sygnały, po których robot decyduje, że warto wrócić

Szybkość indeksowania nowej treści zależy też od tego, czy serwis jest wiarygodny w kwestii tego, co się w nim zmieniło.

Mapy witryny dla dużego portalu powinny być podzielone. Osobno bieżące materiały, osobno archiwum, osobno działy — i wszystkie z uczciwym znacznikiem daty modyfikacji. Uczciwym, czyli zmieniającym się wtedy, gdy treść faktycznie się zmieniła. Serwisy, w których codzienny proces przestawia datę modyfikacji na wszystkich stu tysiącach adresów, same uczą Google, że tej informacji nie warto brać poważnie.

Do tego dochodzą nagłówki odpowiedzi. Poprawnie obsłużone zapytania warunkowe i odpowiedź o braku zmian dla archiwum zwalniają pulę żądań na treści nowe. To nudna warstwa, o której zwykle nikt nie pamięta, a w serwisie z milionem adresów przekłada się na wymierną różnicę.

Sprawdzam też spójność sygnałów: adres w mapie witryny, adres kanoniczny w kodzie, adres w linkach wewnętrznych i cel przekierowania muszą być tym samym adresem. Rozjazd choćby w ukośniku oznacza, że robot za każdym razem rozstrzyga, która wersja jest właściwa.

Osobna sprawa to zachowanie serwisu przy nagłym skoku ruchu, bo materiały wchodzą do indeksu najgorzej dokładnie wtedy, kiedy dzieje się coś ważnego. Serwer, który pod obciążeniem odpowiada wolniej albo odrzuca żądania, zostanie odwiedzany rzadziej i wróci do normalnego tempa z opóźnieniem liczonym w dniach.

Kolejność wdrożeń i pułapka szybkich zysków

Z takiego audytu wychodzi zwykle kilkadziesiąt punktów i tu popełnia się ostatni błąd — wszystkie wdraża się naraz, w jednym wydaniu, po czym nie da się powiedzieć, co zadziałało.

Zaczynam od odcięcia marnowanych żądań, bo to zmiany o najmniejszym ryzyku dla ruchu: parametry w linkach wewnętrznych, głęboka paginacja, adresy techniczne. Potem biorę się za odkrywanie: listingi renderowane po stronie serwera, linki do świeżych materiałów w miejscach odwiedzanych najczęściej, podział map witryny. Na końcu wchodzą zmiany wydajnościowe, bo wymagają wydań po stronie zespołu produktowego i najdłużej się je negocjuje.

Efekt oceniam po tym samym rozkładzie czasów i na tej samej próbce działów. Bez punktu odniesienia poprawę przypisze sobie ten, kto pierwszy pokaże wykres — a w dużym serwisie zawsze trwa równolegle kilka innych projektów.

Jedna rzecz na koniec, którą mówię każdej redakcji: audyt architektoniczny skraca drogę materiału do wyszukiwarki, ale nie sprawia, że wyszukiwarka uzna go za wart pokazania. To dwa różne problemy i warto ich nie mieszać w jednym raporcie.