Modelowane listy odbiorców nie zawierają konkretnych osób, tylko prawdopodobieństwa. Wyjaśniam, jak powstają, gdzie ich szukać w panelu i jak czytać ich raporty.
Ta zmiana zasługuje na osobne opisanie z dwóch powodów. Pierwszy: skala była naprawdę duża i mało kto ze specjalistów, z którymi rozmawiam, nie zobaczył jej u siebie. Drugi, ciekawszy: przebieg ostatnich sześciu tygodni pokazał, że Google reaguje na dobrze udokumentowane obserwacje społeczności, jeśli tylko ktoś potrafi je zebrać.
Chcę tu zostawić kalendarium, bo za pół roku nikt nie będzie pamiętał, co dokładnie i kiedy się stało, a to jest wiedza użyteczna przy każdej kolejnej zmianie tego typu. Do tego dokładam plan naprawczy, który stosuję u siebie — nie listę porad, a kolejność działań z priorytetami.
Piszę to z perspektywy końca września, czyli po korekcie, którą Google wprowadziło w połowie miesiąca. Obraz jest już spokojniejszy niż trzy tygodnie temu.
Warto mieć daty w jednym miejscu.
To ostatnie jest najważniejszym wnioskiem dla planowania pracy: nie warto było reagować gwałtownie w pierwszym tygodniu. Kto przebudował znaczniki w całym serwisie na przełomie sierpnia i września, ten robił to na podstawie stanu, który już nie obowiązuje.
Z publikowanych analiz i z tego, co widzę na kontach, wyłania się dość wyraźny obraz.
Serwisy, które ucierpiały najbardziej, mają jedną cechę wspólną: szablonowo generowane znaczniki. Sklepy z tysiącami kart produktów, w których znacznik składa się z nazwy produktu, nazwy kategorii, symbolu i nazwy sklepu. Serwisy ogłoszeniowe. Katalogi firm. Wszędzie tam, gdzie znacznik powstawał z automatycznego łączenia pól bazy danych.
Najmniej zmian widziałem w serwisach z ręcznie pisanymi znacznikami na kilkudziesięciu podstronach usługowych oraz w blogach, w których znacznik jest zwykle po prostu tytułem wpisu i nikt go nie kombinował.
Osobna grupa to strony lokalne z nazwą miasta dopisywaną do każdego znacznika. Tu mechanizm często usuwał to dopisanie, co bywało bolesne, bo lokalizacja w nagłówku ma dla użytkownika realne znaczenie.
Nie podam procentów, bo dostępne badania różnią się między sobą w zależności od próbki i sposobu pomiaru. Rzędy wielkości, o których mówiono w sierpniu, były wysokie; po korekcie z połowy września są wyraźnie niższe.
Zasada, którą przyjmuję: nie naprawiam wszystkiego, naprawiam to, co się liczy.
Krok pierwszy to wybór dwudziestu do pięćdziesięciu adresów, które generują najwięcej wyświetleń i kliknięć. Dla nich zamiana nagłówka ma wymierny skutek finansowy. Dla podstrony z trzema wyświetleniami miesięcznie nie ma żadnego.
Krok drugi to zestawienie dla tych adresów trzech rzeczy w jednej tabeli: znacznika z kodu, nagłówka pokazywanego w wynikach i głównego nagłówka na stronie. Bez tej tabeli działa się na wyczucie.
Krok trzeci to klasyfikacja. Dzielę przypadki na trzy grupy: zamiana uzasadniona (mój znacznik był słaby), zamiana neutralna (oba warianty są w porządku) i zamiana szkodliwa (nagłówek w wynikach jest wyraźnie gorszy albo mylący). Poprawiam tylko trzecią grupę i przy okazji pierwszą, bo to zwykłe zaległości do nadrobienia.
Krok czwarty to zmiana wprowadzana partiami po kilkanaście adresów, z odstępem, żeby dało się przypisać skutki.
Wzorce, które przy tej zmianie sprawdzają się najlepiej, są nudne i to jest dobra wiadomość.
Krótko. Mieszczące się w dostępnej szerokości bez obcinania. Jeśli musisz coś wyrzucić, wyrzuć nazwę firmy — Google i tak dopisuje ją, kiedy uzna to za potrzebne.
Jedna myśl, nie trzy. Znacznik odpowiadający na jedno zapytanie działa lepiej niż próbujący objąć cztery warianty frazy.
Bez powtarzalnych ozdobników. Ciągi typu „sklep internetowy, najlepsze ceny, wysyłka 24h” dopisywane do każdego znacznika są usuwane jako szum.
Zgodnie z nagłówkiem na stronie. Nie identycznie, ale bez sprzeczności. Jeśli oba mówią to samo, mechanizm nie ma czego wybierać i zostawia Twoją wersję.
Z zachowaniem tego, co odróżnia. W sklepie: nazwa produktu i cecha odróżniająca warianty. W serwisie lokalnym: usługa i miejsce. Na blogu: konkretne pytanie, na które odpowiada wpis.
Przy szablonach w sklepie warto zejść o poziom niżej i przygotować osobne wzorce dla kategorii, podkategorii, karty produktu i strony marki, zamiast jednego wzorca dla wszystkiego. To praca na jeden dzień z programistą, a rozwiązuje problem systemowo.
Ta zmiana nie będzie ostatnia i najlepszą inwestycją jest przygotowanie się na następną.
Prowadzę prosty arkusz z dwudziestoma najważniejszymi adresami, w którym raz w miesiącu zapisuję znacznik z kodu i nagłówek widoczny w wynikach. Zajmuje to kwadrans i daje coś, czego nie kupisz w żadnym narzędziu: historię własnego serwisu z datami.
Do tego obserwuję współczynnik kliknięć na poziomie adresu w Search Console, porównując okresy o zbliżonej sezonowości. Spadek współczynnika przy niezmienionej pozycji to sygnał, że warto sprawdzić nagłówek — pod warunkiem, że pamiętam o kontekście, bo zmiany w wyglądzie wyników wyszukiwania wpływają na ten wskaźnik równie mocno.
Trzeci element to alert na sytuację odwrotną: podstrony, które nagle zaczęły dostawać więcej kliknięć. Bywa, że zamiana nagłówka pomogła, i to też jest informacja — czasem Google podpowiada w ten sposób lepszy sposób opisania strony, niż wymyśliłem sam.
Uczciwe zamknięcie tematu wymaga powiedzenia, że w wielu przypadkach najlepszą reakcją jest brak reakcji.
Jeśli podstrona generuje kilka wyświetleń miesięcznie, nie ma sensu poświęcać jej uwagi niezależnie od tego, co pokazuje się w wynikach. Jeśli zamieniony nagłówek jest po prostu inny, ale równie dobry, zostawiam. Jeśli mechanizm wybrał nagłówek ze strony, który jest lepszy od mojego znacznika, to informacja o tym, że znacznik był słaby — poprawiam go, ale bez poczucia krzywdy.
Nie mam też złudzeń co do kontroli: nie da się wymusić dokładnej treści nagłówka w wynikach i żadna sztuczka tego nie zmieni. Można za to sprawić, żeby własna wersja była najlepszym dostępnym materiałem, po który mechanizm sięgnie.
Z perspektywy tych sześciu tygodni najbardziej praktyczny wniosek jest jednak inny i dotyczy sposobu pracy, nie znaczników. Przy każdej nowej zmianie w wyszukiwarce pierwsze dwa tygodnie służą do obserwacji i dokumentowania, nie do działania. Ten, kto poczekał, zaoszczędził sobie w tym przypadku kilkudziesięciu godzin niepotrzebnej pracy.
Używamy plików cookies, aby ułatwić Ci nawigację oraz wykonywanie określonych funkcji. Szczegółowe informacje o wszystkich plikach cookies znajdziesz w każdej kategorii zgody poniżej.
Pliki cookies oznaczone jako "Niezbędne" są przechowywane w Twojej przeglądarce, ponieważ są one kluczowe dla zapewnienia podstawowych funkcji strony.
Używamy również plików cookies firm trzecich, które pomagają nam analizować, w jaki sposób korzystasz z tej strony, zapamiętują Twoje preferencje oraz dostarczają treści i reklamy odpowiednie dla Ciebie. Te pliki cookies będą przechowywane w Twojej przeglądarce tylko za Twoją uprzednią zgodą.
Możesz zdecydować, czy chcesz włączyć lub wyłączyć niektóre bądź wszystkie te pliki cookies, jednak wyłączenie niektórych z nich może wpłynąć na Twoje doświadczenia podczas przeglądania strony.
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __cf_bm | 13 minutes | Cloudflare bot management — distinguishes humans from bots. |
| rc::* | Persistent | Google reCAPTCHA — localStorage holding anti-bot challenge state. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| wpEmojiSettingsSupports | Session | WordPress — sessionStorage flag caching whether the browser can render emoji (feature detection). |
| ytidb* | Persistent | YouTube — IndexedDB storing playback/search state for embedded videos. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| _ga_* | 400 days | Google Analytics 4 — persists session state per property. |
| _ga | 400 days | Google Analytics — distinguishes unique users via a client id. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| NID | 183 days | Google — stores preferences for personalized ads. |
| fr | 90 days | Meta — encrypted Facebook id and browser id for ads. |
| _gcl_au | 90 days | Google AdSense/Ads — experiments with advertising efficiency (conversion linker). |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __Secure-YNID | 180 days | |
| YSC | Session | |
| __Secure-ROLLOUT_TOKEN | 180 days | |
| VISITOR_INFO1_LIVE | 180 days | |
| VISITOR_PRIVACY_METADATA | 180 days | |
| datr | 400 days | |
| sb | 400 days | |
| wd | 7 days |