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.
Pytanie o czas dotarcia do bloku wiadomości dostaję zwykle w dwóch wersjach. Pierwsza brzmi: co mamy dopisać do kodu, żeby było szybciej. Druga: który przycisk w Google to przyspiesza. Obie zakładają, że istnieje pojedyncza dźwignia, którą można pociągnąć.
Takiej dźwigni nie ma, ale są rzeczy, które faktycznie przesuwają moment pojawienia się materiału — tylko leżą w innym miejscu, niż większość osób szuka. Częściej w decyzjach redakcyjnych i w spójności serwisu niż w pojedynczym znaczniku.
Piszę o tym z perspektywy kogoś, kto na co dzień zajmuje się kampaniami i analityką, a do wydawców trafia wtedy, gdy trzeba pogodzić ruch płatny z organicznym. Ten dystans pomaga, bo widzę, ile energii idzie w tym obszarze na rzeczy bez wpływu na wynik.
Pierwsza rzecz, którą warto sobie przyswoić: żeby materiał znalazł się w bloku wiadomości, muszą zajść trzy niezależne warunki, a nie jeden.
Adres musi zostać odkryty i pobrany. Treść musi zostać uznana za materiał informacyjny na temat, który w danej chwili jest wydarzeniem. I dopiero wtedy Google decyduje, czyj materiał w tym zestawieniu pokazać. Opóźnienie może wynikać z każdego z tych etapów, a działania naprawcze są dla nich zupełnie różne.
Najczęstszy błąd diagnostyczny polega na leczeniu trzeciego etapu narzędziami z pierwszego. Redakcja przebudowuje mapy witryny i przyspiesza serwer, choć problem polega na tym, że jej materiał o wydarzeniu jest dziesiąty w kolejności i nie wnosi nic, czego nie ma w dziewięciu wcześniejszych. Wtedy nawet natychmiastowe pobranie nie zmieni wyniku.
Dlatego zawsze zaczynam od rozstrzygnięcia, na którym etapie tracimy czas. Pomaga proste porównanie: czy materiały tej redakcji na tematy niekonkurencyjne pojawiają się szybko. Jeśli tak, warstwa techniczna działa, a rozmowa powinna dotyczyć doboru tematów i unikalności ujęcia.
Wciąż spotykam przekonanie, że do Google News trzeba się zgłosić i że zgłoszenie coś przyspiesza.
Serwisy informacyjne są brane pod uwagę automatycznie — decyduje o tym charakter treści, nie formularz. Centrum wydawców służy do czegoś innego: do zarządzania publikacją, logotypem, sekcjami i tym, jak marka jest przedstawiana w produktach informacyjnych Google. To ma znaczenie dla rozpoznawalności i porządku, ale nie jest kanałem zgłaszania pojedynczych artykułów.
Warto tam natomiast zajrzeć po to, żeby sprawdzić rzeczy, które potrafią blokować cały serwis: czy publikacja jest poprawnie skonfigurowana, czy nie zgłoszono do niej zastrzeżeń i czy dane wydawcy są aktualne. To nie skróci minut, ale usuwa ryzyko, że problem jest na poziomie całej domeny, a nie konkretnego tekstu.
Odradzam też liczenie na jakikolwiek sposób ręcznego zgłaszania treści z zewnątrz. Interfejs programistyczny do indeksowania obsługuje wyłącznie ogłoszenia o pracę i transmisje wideo. Wysyłanie do niego artykułów nie działa i widziałem serwisy, które wdrożyły to jako priorytet, nie sprawdzając dokumentacji.
Skoro nie da się zgłosić materiału, całe znaczenie ma to, co robot znajdzie w nim przy pierwszym pobraniu.
Nie traktuję tego jako listy do odhaczenia raz. W dużych redakcjach te sygnały psują się przy każdej zmianie szablonu, więc warto mieć prosty test, który po wdrożeniu sprawdza kilka losowych materiałów.
Przy relacjach na bieżąco to decyzja o największych konsekwencjach, a podejmowana jest zwykle bez świadomości, że jakąkolwiek się podejmuje.
Redakcja ma dwie możliwości. Może rozwijać jeden materiał, dopisując kolejne ustalenia i rzetelnie oznaczając moment modyfikacji, albo publikować serię krótkich tekstów pod nowymi adresami. Pierwsze podejście kumuluje sygnały: adres jest już znany, odwiedzany i ma historię. Drugie startuje za każdym razem od zera.
Wybieram pierwsze wszędzie, gdzie temat ma ciągłość, i pilnuję dwóch rzeczy: żeby data modyfikacji zmieniała się tylko przy faktycznej zmianie treści oraz żeby zmiana nie polegała na dopisaniu jednego zdania. Serwis, który co dwadzieścia minut odświeża znacznik bez nowej informacji, uczy Google, że jego sygnały nie znaczą nic.
Drugie podejście ma sens wtedy, gdy powstaje osobna historia, a nie kolejny akapit tej samej. Granica jest nieostra i to jest właśnie decyzja redakcyjna, której nie zastąpi żadne ustawienie.
Ta część rozmowy najczęściej wypada z technicznych audytów, a w praktyce potrafi zmienić więcej niż warstwa kodu.
Blok wiadomości pokazuje ograniczoną liczbę źródeł. Jeśli redakcja publikuje o tym samym co wszyscy, ale trzy godziny później i bez własnych ustaleń, jej materiał konkuruje z tekstami, które zdążyły zebrać sygnały zainteresowania. Szybkość ma tu wartość, ale nie sama z siebie — liczy się jako pierwszeństwo albo jako wyraźnie inne ujęcie.
Dlatego z redakcjami rozmawiam o dwóch rzeczach naraz: jak skrócić drogę techniczną i gdzie mają realną przewagę tematyczną. Dział, w którym redakcja ma własne źródła, dostaje priorytet w kolejce wydawniczej. Tematy przepisywane z agencji nie zyskają na tym, że serwer odpowie o sto milisekund szybciej.
Warto też sprawdzić, jak rozkładają się publikacje w ciągu doby. W wielu redakcjach większość materiałów wychodzi w dwóch wąskich okienkach, bo tak ułożone są zmiany zespołu. To bywa niezamierzoną decyzją o tym, w jakich godzinach serwis jest w ogóle obecny w blokach.
Na koniec sprawa, która sprowadza dyskusję na ziemię: bez pomiaru każda zmiana będzie oceniana anegdotą.
Podstawą jest własna rejestracja czasów — moment publikacji z systemu redakcyjnego zestawiony z pierwszym pobraniem z logów i ze stanem w narzędziu kontroli adresu URL. Do tego raport skuteczności w Search Console z filtrem na wyszukiwanie w Google News, który pokazuje, czy widoczność faktycznie rośnie, a nie tylko czy materiał jest znany.
Trzeba mieć przy tym świadomość ograniczeń dzisiejszych narzędzi. Wyświetlenia i kliknięcia z trybu AI są w raporcie skuteczności wliczone do sumy i nie da się ich wydzielić — Google nie udostępnia dla nich osobnego raportu, choć od pojawienia się tego trybu w polskich wynikach wydawcy proszą o to konsekwentnie. Wnioski o wpływie funkcji generatywnych na ruch z wiadomości są więc w tej chwili wnioskami z danych zagregowanych i tak trzeba je opisywać w raportach dla zarządu.
Mój wniosek po kilku takich projektach jest niewygodny: czas do bloku wiadomości skraca się skokowo, kiedy naprawi się warstwę techniczną, a potem przestaje. Dalsza poprawa jest już kwestią tego, o czym i kiedy redakcja decyduje się pisać.
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 |