Jak działa nowy asystent w google discover i jak optymalizować wordpressa pod spersonalizowany feed

#Jak działa nowy asystent w google discover i jak optymalizować wordpressa pod spersonalizowany feed

Google Discover to feed artykułów i filmów, który aplikacja Google pokazuje na Androidzie i iOS bez wpisywania zapytania. W październiku 2026 roku zaczęło się o nim mówić w kontekście słowa “concierge”, więc warto oddzielić to, co Google wdrożył, od tego, do czego dopiero zatrudnia ludzi. 13 października 2026 roku serwis Search Engine Roundtable opisał ogłoszenie o pracę Google na stanowisko Principal, UX, Search Discover, którego deklarowanym celem jest przekształcenie Discover w proaktywnego, hiperpersonalnego asystenta. To kierunek zapisany w opisie stanowiska, a nie uruchomiony produkt. W 2026 roku faktycznie weszło dostrajanie feedu językiem naturalnym, ogłoszone na blogu Google 20 sierpnia 2026 roku.

Dla stron na WordPressie i sklepów WooCommerce praktyczny wniosek jest w obu przypadkach ten sam. Discover wybiera treści z indeksu Google według zainteresowań, a nie zapytań, a kilka warunków technicznych decyduje, czy strona w ogóle może się pojawić z dużą kartą obrazu. Ten poradnik oddziela potwierdzone fakty od spekulacji, a potem omawia stronę WordPressa: dyrektywy robots, obrazy, kanały i WebSub, cache, znaczniki encji, dane strukturalne WooCommerce, Core Web Vitals i pomiar w Search Console.

#Czym różni się asystent google discover od tradycyjnego feedu wiadomości

Obecny feed Discover to powierzchnia rekomendacji. Dokumentacja Discover od Google opisuje go jako treści dopasowane do tego, czym ktoś się interesuje, i zaznacza, że te zainteresowania z czasem się zmieniają. Nie ma tu zapytania ani pozycji w zwykłym sensie: strona albo zostaje pokazana osobie o pasujących zainteresowaniach, albo nie.

Etykieta concierge pochodzi z ogłoszenia na stronie kariery Google. Według fragmentów cytowanych przez Search Engine Roundtable osoba na tym stanowisku ma prowadzić prace nad “proaktywnym, hiperpersonalnym doświadczeniem typu concierge”, “równoważyć możliwości AI, stawiając w centrum ludzkie głosy i źródła” oraz “rozwijać formaty feedu przez skalowanie formatów opartych na AI” (ogłoszenie Google cytowane przez Search Engine Roundtable, tłumaczenie własne). To opis zamiarów i zakresu rekrutacji. Nie wymienia typów kart, źródeł danych ani daty startu, a Google nie opublikował żadnej dokumentacji dla deweloperów dotyczącej trybu concierge. Każdy tekst, który wyjaśnia, jak concierge układa treści, jakie sygnały z Kalendarza czy Map odczytuje albo jakie formaty kart generuje, zgaduje.

Potwierdzona zmiana jest mniejsza i już trafiła do użytkowników. We wpisie na blogu Google z 20 sierpnia 2026 roku Mrinalini Loew, General Manager Google Search Ecosystem, napisała, że “w najbliższych dniach w aplikacji Google będzie można stuknąć dowolne menu z trzema kropkami w feedzie i własnymi słowami powiedzieć Google, jakich tematów lub linków chce się widzieć więcej (albo mniej)” oraz że “feed dostosuje się na bieżąco i zapamięta te prośby” (Mrinalini Loew, Google, tłumaczenie własne). Wcześniej użytkownicy sterowali feedem głównie przyciskiem obserwowania i opcją “nie interesuje mnie to”.

Dla wydawców ma to jedno konkretne znaczenie. Czytelnik może teraz opisać zainteresowanie zwykłymi słowami, aż do wąskiego podtematu, a feed ma to uwzględnić. Treść, która jasno mówi, czego dotyczy, w tytule, nagłówkach i głównym obrazie, łatwiej dopasować do takiej prośby niż mglisty albo clickbaitowy nagłówek. Wytyczne Google dla Discover już wcześniej prosiły o tytuły i nagłówki, które oddają istotę treści. Sterowanie językiem naturalnym czyni tę radę bardziej konkretną, ale jej nie zastępuje.

#Jakie wymagania techniczne musi spełniać strona aby trafić do google discover

Do Discover nie ma rejestracji. Dokumentacja Google mówi, że treść jest automatycznie kwalifikowana do Discover, jeśli jest zaindeksowana przez Google i spełnia zasady treści Discover, że nie są potrzebne żadne specjalne tagi ani dane strukturalne oraz że kwalifikacja nie gwarantuje wyświetlenia. Pierwszym wymaganiem jest więc zwykła indeksowalność: strona zwraca 200, nie jest zablokowana w robots.txt, nie ma noindex i ma kanoniczny adres wskazujący na siebie albo na wersję, którą chcesz indeksować.

Drugie wymaganie dotyczy dużych podglądów obrazów. Google wskazuje ustawienie robots max-image-preview:large albo AMP jako warunek dużych obrazów w Discover. Bez niego strona nadal może się pojawić, ale tylko z małą miniaturą. Dyrektywa wygląda tak:

<!-- Poprawna konfiguracja naglowka robots dla Google Discover w sekcji head -->
<meta name="robots" content="index, follow, max-image-preview:large, max-snippet:-1, max-video-preview:-1" />

Rdzeń WordPressa domyślnie wypisuje tę dyrektywę od wersji 5.7 przez funkcję wp_robots_max_image_preview_large(), ale tylko wtedy, gdy opcja blog_public jest włączona, czyli gdy strona nie prosi wyszukiwarek o pomijanie. Najpierw sprawdź wyrenderowany znacznik <meta name="robots">. Jeśli motyw, wtyczka SEO albo pozostałość po stagingu usuwa lub nadpisuje tę wartość, filtr na wp_robots w functions.php motywu potomnego przywraca ją z późnym priorytetem:

<?php
/**
 * Wymuszenie pelnych dyrektyw robotow pod Google Discover
 */
function wppoland_discover_robots_directives($robots) {
    $robots['max-image-preview'] = 'large';
    $robots['max-snippet'] = -1;
    $robots['max-video-preview'] = -1;
    return $robots;
}
add_filter('wp_robots', 'wppoland_discover_robots_directives', 99);

Trzecie wymaganie to sam obraz. Google zaleca użycie znaczników schema.org albo meta tagu og:image do wskazania dużego obrazu, który jest trafny i reprezentatywny dla strony, bo to może wpłynąć na wybór obrazu. Zepsuty albo malutki og:image sam w sobie nie wyklucza strony z Discover, ale odbiera kontrolę nad tym, który obraz wybierze Google. Google nie dokumentuje, jakie pola Open Graph poza obrazem czyta Discover, więc poprawne muszą być też znacznik <title> i widoczny nagłówek, a nie tylko tagi Open Graph.

#Jakie treści google discover odfiltrowuje i kiedy pojawiają się ręczne działania

Discover ma własne zasady treści, które obowiązują obok ogólnych zasad wyszukiwarki Google. Dokumentacja wymienia formaty, których Discover może unikać: formularze aplikacyjne o pracę, petycje, formularze, repozytoria kodu i satyrę bez kontekstu. Filtruje też treści, które mogą wydać się szokujące lub nieoczekiwane komuś, kto ich nie szukał. Strona na WordPressie, która publikuje fragmenty kodu jako repozytorium albo landingi będące głównie formularzami, nie powinna oczekiwać tych adresów w Discover, niezależnie od ich jakości.

Wytyczne dotyczące prezentacji są konkretne. Google prosi, by unikać clickbaitu polegającego na używaniu mylących lub przesadzonych szczegółów w podglądzie (tytule, opisie lub obrazach) dla zwiększenia atrakcyjności albo na ukrywaniu kluczowych informacji potrzebnych do zrozumienia, czego dotyczy treść. Prosi też o unikanie sensacji grającej na chorobliwej ciekawości, podnieceniu lub oburzeniu. Zamiast tego oczekuje treści aktualnych wobec bieżących zainteresowań, dobrze opowiedzianych albo wnoszących unikalne spostrzeżenia.

Gdy strona narusza któreś z tych zasad, Google podaje, że w Search Console w sekcji Bezpieczeństwo i ręczne działania mogą pojawić się ręczne działania dotyczące Discover. To pierwsze miejsce do sprawdzenia, jeśli ruch z Discover całkowicie znika, a ruch z wyszukiwarki pozostaje stabilny. Ręczne działanie dotyczące Discover nie widać jako spadku w raporcie Skuteczność dla wyszukiwarki, więc strona może wyglądać zdrowo w jednym raporcie i być wykluczona w drugim.

W redakcji na WordPressie przekłada się to na trzy kontrole przed publikacją: nagłówek mówi, na jakie pytanie odpowiada artykuł, obraz wyróżniający pokazuje temat zamiast logo albo banera z tekstem, a pierwszy akapit spełnia obietnicę nagłówka.

#Dlaczego duże zdjęcia powyżej 1200px i dyrektywa max image preview large są obowiązkowe

Discover to feed wizualny, a obraz decyduje o tym, ile miejsca zajmuje karta. Dokumentacja Google podaje specyfikację dużych obrazów:

• Szerokość: co najmniej 1200 px.
• Rozdzielczość: ponad 300 000 pikseli łącznie.
• Proporcje: 16x9.
• Ustawienie robots: włączone przez max-image-preview:large albo przez AMP.

Google dodaje dwa ostrzeżenia, które łatwo przeoczyć w motywach WordPressa. Nie należy używać ogólnych obrazów, na przykład logo strony, w znacznikach schema.org ani w og:image, a właśnie na logo wiele motywów i wtyczek SEO przełącza się, gdy wpis nie ma obrazu wyróżniającego. Najlepsze wyniki daje też unikanie w tych polach obrazów z dużą ilością tekstu, co wyklucza karty tytułowe z nagłówkiem dużą czcionką.

Osobny rozmiar obrazu sprawia, że regułę 1200 px da się egzekwować, zamiast polegać na tym, co wgra każdy redaktor. Poniższy kod rejestruje przycięcie 1344 na 768, bliskie 16:9 i mające około 1,03 miliona pikseli, i wypisuje tagi obrazu Open Graph tylko wtedy, gdy wygenerowany plik naprawdę ma 1200 px:

<?php
/**
 * Rejestracja dedykowanego formatu miniatury pod Google Discover
 */
function wppoland_setup_discover_thumbnails() {
    add_image_size('discover-large', 1344, 768, true);
}
add_action('after_setup_theme', 'wppoland_setup_discover_thumbnails');

/**
 * Podpiecie dedykowanego obrazu do tagow Open Graph
 */
function wppoland_inject_discover_og_image() {
    if (is_singular('post')) {
        global $post;
        if (has_post_thumbnail($post->ID)) {
            $image_data = wp_get_attachment_image_src(get_post_thumbnail_id($post->ID), 'discover-large');
            if ($image_data && $image_data[1] >= 1200) {
                echo '<meta property="og:image" content="' . esc_url($image_data[0]) . '" />' . "\n";
                echo '<meta property="og:image:width" content="' . esc_attr($image_data[1]) . '" />' . "\n";
                echo '<meta property="og:image:height" content="' . esc_attr($image_data[2]) . '" />' . "\n";
                echo '<meta property="og:image:type" content="image/avif" />' . "\n";
            }
        }
    }
}
add_action('wp_head', 'wppoland_inject_discover_og_image', 5);

Dwie uwagi praktyczne. Przycięcie powstaje tylko dla obrazów wgranych po zarejestrowaniu rozmiaru, więc starsze wpisy wymagają regeneracji miniatur, na przykład poleceniem wp media regenerate w WP-CLI. WordPress nie powiększa też obrazu źródłowego mniejszego niż przycięcie, dlatego kod sprawdza rzeczywistą szerokość przed wypisaniem tagów. Jeśli obrazy nie są w AVIF, zmień wartość og:image:type na faktyczny typ pliku.

#Jak wdrożyć protokół websub w wordpressie aby skrócić czas indeksacji do kilku sekund

Świeżość ma w Discover znaczenie, bo wytyczne Google mówią o treściach aktualnych wobec bieżących zainteresowań. Im szybciej Google dowie się o nowym adresie, tym szybciej może go wziąć pod uwagę. Mapy witryny działają, ale Google pobiera je według własnego harmonogramu. WebSub to mechanizm typu push: wydawca informuje hub, że kanał się zmienił, a hub powiadamia subskrybentów.

WebSub, wcześniej PubSubHubbub, ma status rekomendacji W3C. Specyfikacja określa, jak wydawca ogłasza swój hub: nagłówkami HTTP Link albo elementami <link>, z rel="hub" dla hubu i rel="self" dla własnego adresu kanału. Celowo pozostawia otwartą kwestię, jak wydawca powiadamia hub. Specyfikacja nazywa ten mechanizm nieokreślonym, a wiele hubów, w tym publiczny hub Google pod adresem https://pubsubhubbub.appspot.com/, przyjmuje żądanie POST z hub.mode=publish i hub.url wskazującym kanał. Google nie dokumentuje, że ping do jego hubu przyspiesza wejście strony do Discover, więc WebSub traktuj jako sposób na szybsze wykrycie kanału, a nie przełącznik Discover.

Poniższy kod wysyła ping przy publikacji i dodaje linki wykrywania do kanału Atom bez dodatkowej wtyczki:

<?php
/**
 * Implementacja automatycznych powiadomien WebSub dla huba Google
 */
function wppoland_publish_to_websub_hub($post_id, $post) {
    // Ignoruj wersje robocze, rewizje i automatyczne zapisy
    if (wp_is_post_revision($post_id) || wp_is_post_autosave($post_id)) {
        return;
    }
    
    // Publikuj tylko publiczne posty
    if ($post->post_status !== 'publish' || $post->post_type !== 'post') {
        return;
    }

    $hub_url = 'https://pubsubhubbub.appspot.com/';
    $feed_url = get_feed_link('atom');

    $response = wp_remote_post($hub_url, [
        'method'      => 'POST',
        'timeout'     => 5,
        'redirection' => 2,
        'httpversion' => '1.1',
        'blocking'    => false, // Asynchroniczne wywolanie nie blokuje zapisu w panelu
        'headers'     => [
            'Content-Type' => 'application/x-www-form-urlencoded; charset=utf-8',
        ],
        'body'        => [
            'hub.mode' => 'publish',
            'hub.url'  => $feed_url,
        ],
    ]);
}
add_action('publish_post', 'wppoland_publish_to_websub_hub', 10, 2);

/**
 * Dodanie linkow do huba w naglowkach feedu Atom
 */
function wppoland_add_websub_headers() {
    $hub_url = 'https://pubsubhubbub.appspot.com/';
    echo '<link rel="hub" href="' . esc_url($hub_url) . '" />' . "\n";
    echo '<link rel="self" href="' . esc_url(get_feed_link('atom')) . '" />' . "\n";
}
add_action('atom_head', 'wppoland_add_websub_headers');

Jeśli wolisz utrzymywaną wtyczkę, katalog WordPress.org zawiera WebSub (FKA. PubSubHubbub), która ogłasza huby w kanałach i wysyła ping publikacji. Nie uruchamiaj wtyczki i kodu jednocześnie, bo każda publikacja wyśle dwa pingi.

Kanał powinien zawierać pełną treść wpisu, a nie tylko zajawkę. W WordPressie steruje tym opcja rss_use_excerpt w ustawieniach czytania: przy wartości 0 kanał Atom wypisuje pełny tekst w elemencie <content>, a kanał RSS 2.0 używa <content:encoded>.

#Jak skonfigurować nagłówki cache control i cache na brzegu cloudflare dla kanałów rss i atom

Gdy huby i roboty pobierają kanały po każdej publikacji, każde niezbuforowane żądanie uruchamia cały stos PHP WordPressa. Krótki współdzielony cache utrzymuje świeżość kanału i chroni serwer źródłowy. W Nginx:

# Short shared cache for WordPress feeds
location ~* /feed/ {
    add_header Cache-Control "public, max-age=300, stale-while-revalidate=600";
    expires 5m;
}

Ten sam nagłówek można ustawić z poziomu WordPressa:

<?php
/**
 * Cache-Control header for RSS and Atom feeds
 */
function wppoland_feed_cache_headers() {
    if (is_feed()) {
        header_remove('Pragma');
        header('Cache-Control: public, max-age=300, stale-while-revalidate=600');
    }
}
add_action('template_redirect', 'wppoland_feed_cache_headers', 1);

Przy max-age=300 CDN taki jak Cloudflare może serwować kanał przez maksymalnie pięć minut, a stale-while-revalidate=600 pozwala mu podawać poprzednią kopię w czasie pobierania nowej. Trzymaj krótki TTL. Kanał buforowany godzinami niweczy sens pingu WebSub, bo hub pobierze nieaktualną wersję. Jeśli buforujesz kanały na brzegu dłużej, czyść adres kanału przy publikacji.

#Jak budować topical authority i powiązania encji z wikidata pod profil użytkownika

Discover dopasowuje treści do zainteresowań, a Google opisuje te zainteresowania w kategoriach tematów, nie słów kluczowych. Google nie publikuje, jak Discover przypisuje strony do tematów, więc realistycznym celem jest jednoznaczność tematu każdej strony: czytelne nagłówki, spójna terminologia i dane strukturalne nazywające główne encje.

Na stronie z WordPressem oznacza to trzy rzeczy:

1. JSON-LD z about i mentions: powiąż główne tematy ze stałymi identyfikatorami, takimi jak adresy Wikidata lub Wikipedii, żeby “Discover” czy “WebSub” nie dało się pomylić z niezwiązanym pojęciem.
2. Autorzy jako encje Person: połącz profile autorów z profilami, które autor faktycznie prowadzi, takimi jak LinkedIn czy GitHub, żeby czytelnicy i roboty widzieli, kto napisał treść.
3. Klastry tematyczne: publikuj powiązane artykuły o jednym temacie i linkuj je między sobą, żeby głębokość pokrycia była widoczna.

Przykładowy graf:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "TechArticle",
      "@id": "https://wppoland.com/blog/jak-dziala-nowy-asystent-w-google-discover/#article",
      "isPartOf": {
        "@id": "https://wppoland.com/#website"
      },
      "headline": "Jak dziala nowy asystent w google discover i jak optymalizowac wordpressa pod spersonalizowany feed",
      "description": "Szczegolowy przewodnik po architekturze asystenta Google Discover i optymalizacji serwisow WordPress.",
      "inLanguage": "pl-PL",
      "mainEntityOfPage": "https://wppoland.com/blog/jak-dziala-nowy-asystent-w-google-discover/",
      "datePublished": "2026-10-14T08:00:00+02:00",
      "dateModified": "2026-10-14T10:30:00+02:00",
      "image": {
        "@type": "ImageObject",
        "@id": "https://wppoland.com/blog/jak-dziala-nowy-asystent-w-google-discover/#primaryimage",
        "url": "https://wppoland.com/images/digital-experience-platforms-dxp-vs-wordpress.avif",
        "width": 1344,
        "height": 768,
        "caption": "Optymalizacja WordPress pod asystenta Google Discover"
      },
      "author": {
        "@type": "Person",
        "name": "Mariusz Szatkowski",
        "url": "https://wppoland.com/author/mariusz-szatkowski/",
        "jobTitle": "Lead WordPress Architect",
        "sameAs": [
          "https://www.linkedin.com/in/mariuszszatkowski",
          "https://github.com/wppoland"
        ]
      },
      "publisher": {
        "@type": "Organization",
        "name": "WPPoland",
        "url": "https://wppoland.com",
        "logo": {
          "@type": "ImageObject",
          "url": "https://wppoland.com/logo.png",
          "width": 512,
          "height": 512
        }
      },
      "about": [
        {
          "@type": "Thing",
          "name": "Google Discover",
          "sameAs": "https://en.wikipedia.org/wiki/Google_Discover"
        },
        {
          "@type": "SoftwareApplication",
          "name": "WordPress",
          "sameAs": "https://www.wikidata.org/wiki/Q13166"
        }
      ],
      "mentions": [
        {
          "@type": "Thing",
          "name": "Core Web Vitals",
          "sameAs": "https://en.wikipedia.org/wiki/Core_Web_Vitals"
        },
        {
          "@type": "Thing",
          "name": "WebSub",
          "sameAs": "https://en.wikipedia.org/wiki/WebSub"
        }
      ]
    }
  ]
}
</script>

Dane strukturalne nie są wymogiem Discover; Google podaje, że specjalne tagi nie są potrzebne. Ich wartość polega tu na usunięciu niejednoznaczności co do tematu strony i jej autora.

#Jak optymalizować sklep woocommerce pod rekomendacje produktowe w google discover

Dokumentacja Discover nie opisuje kart produktowych ani żadnej funkcji specyficznej dla WooCommerce. Sklep kontroluje jakość danych produktowych w wyszukiwarce Google w ogóle oraz rodzaj treści, które Discover faktycznie pokazuje: artykuły redakcyjne, aktualne i użyteczne.

Trzy kroki utrzymują spójność danych produktowych:

1. Cena i dostępność w schemacie: WooCommerce wypisuje dane strukturalne Product; sprawdź, czy price, priceCurrency i availability zgadzają się z tym, co pokazuje strona.
2. GTIN: WooCommerce od wersji 9.1 ma przy produkcie pole GTIN, UPC, EAN lub ISBN, a jego klasa danych strukturalnych wypisuje właściwość gtin, gdy wartość jest poprawna. Dokumentacja informacji o produktach sprzedawcy Google wymienia gtin wśród odczytywanych identyfikatorów produktu, więc wypełnienie tego pola jest lepsze niż trzymanie kodu we własnym polu meta.
3. Treści redakcyjne wokół produktów: poradniki zakupowe, porównania i opisy testów pasują do wytycznych Discover o aktualnych, wnoszących coś treściach. Listy produktów i strony kategorii rzadko pasują.

Dane o polityce zwrotów trafiają do oferty przez filtr woocommerce_structured_data_product_offer. WooCommerce przechowuje oferty jako listę wewnątrz znaczników produktu, więc ten filtr to właściwe miejsce na hasMerchantReturnPolicy, właściwość obsługiwaną według dokumentacji informacji o produktach Google:

<?php
/**
 * Dodanie polityki zwrotów do schematu oferty WooCommerce.
 * WooCommerce 9.1+ sam wypisuje gtin z pola GTIN produktu.
 */
function wppoland_discover_return_policy($markup_offer, $product) {
    $markup_offer['hasMerchantReturnPolicy'] = [
        '@type' => 'MerchantReturnPolicy',
        'applicableCountry' => 'PL',
        'returnPolicyCategory' => 'https://schema.org/MerchantReturnFiniteReturnWindow',
        'merchantReturnDays' => 30,
        'returnMethod' => 'https://schema.org/ReturnByMail',
        'returnFees' => 'https://schema.org/FreeReturn',
    ];
    return $markup_offer;
}
add_filter('woocommerce_structured_data_product_offer', 'wppoland_discover_return_policy', 10, 2);

Ustaw kraj, liczbę dni i opłaty zgodnie z faktycznym regulaminem sklepu. Dane strukturalne sprzeczne z widoczną polityką zwrotów są gorsze niż ich brak.

#Jaki wpływ mają wskaźniki core web vitals i inp poniżej 200ms na widoczność w discover

Wytyczne Discover proszą wydawców o zapewnienie ogólnie dobrego doświadczenia na stronie. Wizyty z Discover odbywają się na telefonach, często na łączach komórkowych, więc najważniejsze są mobilne dane z terenu. Progi Core Web Vitals opublikowane na web.dev to:

• LCP: 2,5 sekundy lub mniej.
• INP: 200 milisekund lub mniej. INP zastąpił FID jako wskaźnik Core Web Vitals w marcu 2024 roku.
• CLS: 0,1 lub mniej.

web.dev zaleca mierzenie ich na 75. percentylu wczytań stron, osobno dla urządzeń mobilnych i komputerów.

W artykule z Discover elementem LCP jest zwykle obraz wyróżniający, ten sam duży obraz, który pokazuje karta. Od WordPressa 6.3 rdzeń dodaje fetchpriority="high" do obrazu, który uznaje za najbardziej prawdopodobny element LCP, i przestaje leniwie ładować obrazy nad pętlą, co opisują notatki o wydajności obrazów w WordPressie 6.3. W starszych wersjach albo w motywach, które wypisują obraz wyróżniający poza standardowymi funkcjami, poniższy kod ustawia atrybuty jawnie:

<?php
/**
 * Optymalizacja LCP dla glownego obrazu pod katem Google Discover
 */
function wppoland_optimize_hero_for_discover($content) {
    if (is_singular('post')) {
        // Wylaczenie native lazy-loading dla pierwszego obrazu wyrozniajacego
        add_filter('wp_get_attachment_image_attributes', function($attr, $attachment, $size) {
            if ($size === 'discover-large' || $size === 'post-thumbnail') {
                $attr['loading'] = 'eager';
                $attr['fetchpriority'] = 'high';
                $attr['decoding'] = 'async';
            }
            return $attr;
        }, 10, 3);
    }
    return $content;
}
add_action('wp', 'wppoland_optimize_hero_for_discover');

W WordPressie 6.3 i nowszym sprawdź wyrenderowany HTML przed dodaniem kodu: jeśli rdzeń już oznacza obraz, filtr jest zbędny. Przy INP typowymi przyczynami w WordPressie są ciężkie skrypty zewnętrzne, slidery i banery zgód, które blokują główny wątek przy pierwszych interakcjach.

#Dlaczego ruch z google discover drastycznie spada po kilku dniach i jak temu zapobiec

Ruch z Discover zwykle przychodzi falami: artykuł jest szeroko pokazywany przez krótki czas, a potem wygasa. Dokumentacja Google mówi wprost, że ruch z Discover jest mniej przewidywalny i mniej pewny niż wizyty z wyszukiwania opartego na słowach kluczowych i że wydawcy powinni traktować go jako uzupełnienie ruchu z wyszukiwarki.

Google wymienia przyczyny zmian ruchu:

• Zmieniające się zainteresowania: Discover pokazuje treści dopasowane do zainteresowań, a te się przesuwają.
• Typy treści: Discover dostosowywał i nadal dostosowuje rodzaje treści, które mogą pojawić się w feedzie.
• Aktualizacje wyszukiwarki: Discover jest rozszerzeniem wyszukiwarki, więc jej aktualizacje mogą zmieniać ruch z Discover.
• Zmiany produktu: Google podaje, że prace nad Discover mogą powodować zmiany ruchu niezwiązane z jakością ani częstotliwością publikacji treści.

Ostatni punkt koryguje popularne przekonanie. Publikowanie większej liczby artykułów tygodniowo nie jest udokumentowaną dźwignią w Discover. Pod kontrolą wydawcy zostaje to, co wymieniają wytyczne Google: aktualne treści, jasne tytuły, dobre duże obrazy i dobre doświadczenie na stronie. Aktualizacja artykułu evergreen o nowe informacje z prawdziwym dateModified jest w porządku, gdy treść naprawdę się zmieniła; zmiana samej daty nie jest.

W planowaniu traktuj szczyt z Discover jako premię ponad ruch z wyszukiwarki, a nie jako poziom, na którym opiera się budżet.

#Jak monitorować skuteczność w google search console i analizować konwersje z feedu

Search Console ma osobny raport skuteczności Discover w sekcji Skuteczność. Google podaje, że pokazuje on wyświetlenia, kliknięcia i CTR treści, które pojawiły się w Discover w ostatnich 16 miesiącach, o ile dane przekraczają minimalny próg wyświetleń. Google nie publikuje wartości tego progu. Raport obejmuje ruch z Chrome i według dokumentacji pokrywa ruch z Discover ze wszystkich miejsc, w których użytkownicy korzystają z Discover.

Co czytać w raporcie:

• Strony z wyświetleniami, ale niskim CTR: porównaj ich obrazy i tytuły z wytycznymi powyżej; logo albo obraz z dużą ilością tekstu to pierwszy podejrzany.
• Podział na kraje: na stronach wielojęzycznych sprawdź, czy hreflang kieruje każdego czytelnika do właściwej wersji językowej.
• Nagły spadek do zera: przed jakąkolwiek zmianą na stronie sprawdź sekcję Bezpieczeństwo i ręczne działania pod kątem ręcznego działania dotyczącego Discover.

Google Analytics 4 nie ma domyślnego kanału dla Discover, więc punktem odniesienia dla kliknięć z Discover pozostaje Search Console. Aby sprawdzić, czy czytelnicy z Discover zapisują się do newslettera albo składają zamówienia w WooCommerce, weź strony docelowe z raportu Discover i porównaj ich konwersje w GA4 w tym samym okresie. Jeśli potrzebujesz pomocy przy tej konfiguracji, porozmawiaj ze specjalistą WordPress.