How does the new google discover concierge work and how to optimize wordpress for personalized feeds

#How does the new google discover concierge work and how to optimize wordpress for personalized feeds

Google Discover is the feed of articles and videos that the Google app shows on Android and iOS without the user typing a query. In October 2026 the word “concierge” started to circulate in connection with it, so it is worth separating what Google has shipped from what it is hiring people to build. On 13 October 2026 Search Engine Roundtable reported a Google job listing for a Principal, UX, Search Discover whose stated goal is to turn Discover into a proactive, hyper-personalized concierge experience. That is a direction in a job description, not a launched product. What did ship in 2026 is natural-language tuning of the feed, announced on the Google blog on 20 August 2026.

For WordPress sites and WooCommerce stores the practical consequence is the same either way. Discover picks content from the Google index by interest, not by query, and a handful of technical conditions decide whether a page can appear with a large image card at all. This guide separates the confirmed facts from the speculation, then walks through the WordPress side: robots directives, images, feeds and WebSub, caching, entity markup, WooCommerce structured data, Core Web Vitals and measurement in Search Console.

#What is the difference between google discover concierge and traditional content feeds

The current Discover feed is a recommendation surface. Google’s Discover documentation describes it as content aligned with what someone is interested in, and notes that those interests change over time. There is no query and no ranking position in the usual sense: a page is either shown to a person whose interests match, or it is not.

The concierge label comes from the job listing on Google’s careers site. According to the excerpts quoted by Search Engine Roundtable, the role should lead the work on a “proactive, hyper-personalized concierge experience”, “balance AI capabilities while centering human voices and sources” and “evolve feed formats by scaling AI enabled formats”. That describes intent and a hiring brief. It names no card types, no data sources and no launch date, and Google has published no developer documentation for a concierge mode. Any article that explains how the concierge ranks content, which Calendar or Maps signals it reads or which card formats it produces is guessing.

The confirmed change is smaller and already in users’ hands. In a Google blog post dated 20 August 2026, Mrinalini Loew, General Manager of the Google Search Ecosystem, wrote that “in the coming days in the Google app, you’ll be able to tap any three-dot menu in your feed to tell Google the exact topics or links you want to see more (or less) of, in your words”, and that “your feed will adjust on the fly, and remember your requests”. Before that, users steered the feed mainly with the follow and “not interested” controls.

For publishers this matters in one specific way. A reader can now describe an interest in plain words, down to a narrow sub-topic, and the feed is expected to honour it. Content that states clearly what it is about, in its title, its headings and its main image, is easier to match against such a request than a vague or clickbait headline. Google’s Discover guidance already asks for “page titles and headlines that capture the essence of the content”. The natural-language controls make that advice more concrete; they do not replace it.

#What technical requirements must a wordpress site meet to appear in google discover

There is no registration for Discover. Google’s documentation states that content “is automatically eligible to appear in Discover if it is indexed by Google and meets Discover’s content policies”, that “no special tags or structured data are required”, and that being eligible “is not a guarantee of appearing”. The first requirement is therefore ordinary indexability: the page returns 200, is not blocked in robots.txt, carries no noindex and has a canonical that points to itself or to the version you want indexed.

The second requirement concerns large image previews. Google names the max-image-preview:large robots setting, or AMP, as the condition for large images in Discover. Without it a page can still appear, but only with a small thumbnail. The directive looks like this:

<!-- Required robots directive for Google Discover in the HTML head -->
<meta name="robots" content="index, follow, max-image-preview:large, max-snippet:-1, max-video-preview:-1" />

WordPress core has printed this directive by default since version 5.7, through the function wp_robots_max_image_preview_large(), but only when the blog_public option is on, that is, when the site is not set to discourage search engines. Check the rendered <meta name="robots"> tag first. If a theme, an SEO plugin or a staging leftover removes or overrides the value, a filter on wp_robots in the child theme’s functions.php restores it with a late priority:

<?php
/**
 * Enforce Google Discover robots directives in WordPress
 */
function wppoland_enforce_discover_robots($robots) {
    $robots['max-image-preview'] = 'large';
    $robots['max-snippet'] = -1;
    $robots['max-video-preview'] = -1;
    return $robots;
}
add_filter('wp_robots', 'wppoland_enforce_discover_robots', 99);

The third requirement is the image itself. Google says to use “either schema.org markup or the og:image meta tag to specify a large image” that is relevant and representative of the page, because this “can influence which image is chosen”. A broken or tiny og:image does not by itself keep a page out of Discover, but it takes away your control over which image Google picks. Google does not document which Open Graph fields other than the image Discover reads, so the HTML <title> and the visible headline should be correct too, not only the Open Graph tags.

#Which content google discover filters out and when manual actions apply

Discover has its own content policies on top of the general Google Search policies. Google’s documentation lists formats that Discover may avoid showing: job applications, petitions, forms, code repositories and satirical content without context. It also filters content that might seem shocking or unexpected to someone who did not search for it. A WordPress site that publishes snippets as a code repository, or landing pages that are mainly forms, should not expect those URLs in Discover, whatever their quality.

The guidance on presentation is concrete. Google asks publishers to avoid clickbait “by using misleading or exaggerated details in preview content (title, snippets, or images) to increase appeal” or by “withholding crucial information required to understand what the content is about”, and to avoid sensationalism that plays on “morbid curiosity, titillation, or outrage”. Instead it asks for content that is timely for current interests, tells a story well or provides unique insights.

When a site violates one of these policies, Google states that Discover manual actions may appear in Search Console under Security and Manual actions. That is the first place to look if Discover traffic stops completely while web search traffic stays steady. A manual action that applies to Discover does not show up as a drop in the web search Performance report, so a site can look healthy in one report and be excluded in the other.

In a WordPress editorial workflow this turns into three checks an editor can run before publishing: the headline says what the article answers, the featured image shows the subject instead of a logo or a text banner, and the first paragraph delivers what the headline promises.

#Why large images over 1200px and the max image preview large tag are mandatory

Discover is a visual feed, and the image decides how much space a card takes. Google’s documentation gives the specification for large images:

• Width: at least 1200 px.
• Resolution: more than 300,000 total pixels.
• Aspect ratio: 16x9.
• Robots setting: enabled by max-image-preview:large, or by using AMP.

Google adds two warnings that are easy to miss in WordPress themes. Avoid generic images, for example the site logo, in schema.org markup or og:image, which is exactly what many themes and SEO plugins fall back to when a post has no featured image. And “for best results, avoid using text-heavy images” in those fields, which rules out title cards with the headline set in large type.

A dedicated image size makes the 1200 px rule enforceable instead of depending on what each editor uploads. The snippet below registers a 1344 by 768 crop, close to 16:9 and about 1.03 million pixels, and prints the Open Graph image tags only when the generated file really reaches 1200 px:

<?php
/**
 * Register dedicated 1344x768 image size for Google Discover
 */
function wppoland_register_discover_image_size() {
    add_image_size('discover-hero', 1344, 768, true);
}
add_action('after_setup_theme', 'wppoland_register_discover_image_size');

/**
 * Output dedicated Open Graph image tags with explicit dimensions
 */
function wppoland_render_discover_og_meta() {
    if (is_singular('post')) {
        global $post;
        if (has_post_thumbnail($post->ID)) {
            $image_info = wp_get_attachment_image_src(get_post_thumbnail_id($post->ID), 'discover-hero');
            if ($image_info && $image_info[1] >= 1200) {
                echo '<meta property="og:image" content="' . esc_url($image_info[0]) . '" />' . "\n";
                echo '<meta property="og:image:width" content="' . esc_attr($image_info[1]) . '" />' . "\n";
                echo '<meta property="og:image:height" content="' . esc_attr($image_info[2]) . '" />' . "\n";
                echo '<meta property="og:image:type" content="image/avif" />' . "\n";
            }
        }
    }
}
add_action('wp_head', 'wppoland_render_discover_og_meta', 5);

Two practical notes. The crop exists only for images uploaded after the size is registered, so older posts need their thumbnails regenerated, for example with wp media regenerate in WP-CLI. And WordPress does not upscale a source image smaller than the crop, which is why the snippet checks the real width before printing the tags. If your images are not AVIF, change the og:image:type value to match the actual file type.

#How to implement websub in wordpress to index new articles in seconds

Freshness matters in Discover because Google’s guidance asks for content that is “timely for current interests”. The sooner Google learns that a new URL exists, the sooner it can be considered. Sitemaps work, but Google fetches them on its own schedule. WebSub is a push mechanism: the publisher tells a hub that a feed has changed, and the hub notifies its subscribers.

WebSub, formerly PubSubHubbub, is a W3C Recommendation. The specification defines how a publisher advertises its hub: with HTTP Link headers or with <link> elements, rel="hub" for the hub and rel="self" for the feed’s own URL. It deliberately leaves open how the publisher informs the hub. The spec calls that mechanism unspecified, and many hubs, including Google’s public hub at https://pubsubhubbub.appspot.com/, accept a POST with hub.mode=publish and hub.url set to the feed. Google does not document that pinging its hub changes how quickly a page enters Discover, so treat WebSub as a way to shorten feed discovery, not as a Discover switch.

The snippet below sends the ping on publication and adds the discovery links to the Atom feed, without an extra plugin:

<?php
/**
 * Send WebSub publish ping to Google hub on post publication
 */
function wppoland_ping_websub_hub($post_id, $post) {
    if (wp_is_post_revision($post_id) || wp_is_post_autosave($post_id)) {
        return;
    }
    
    if ($post->post_status !== 'publish' || $post->post_type !== 'post') {
        return;
    }

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

    wp_remote_post($hub_url, [
        'method'      => 'POST',
        'timeout'     => 5,
        'redirection' => 2,
        'httpversion' => '1.1',
        'blocking'    => false, // Non-blocking async call prevents editor lag
        'headers'     => [
            'Content-Type' => 'application/x-www-form-urlencoded; charset=utf-8',
        ],
        'body'        => [
            'hub.mode' => 'publish',
            'hub.url'  => $feed_url,
        ],
    ]);
}
add_action('publish_post', 'wppoland_ping_websub_hub', 10, 2);

/**
 * Declare hub and self discovery links in Atom feed header
 */
function wppoland_add_atom_hub_links() {
    $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_atom_hub_links');

If you prefer a maintained plugin, the WordPress.org directory lists WebSub (FKA. PubSubHubbub), which advertises hubs in the feeds and sends the publish ping. Do not run the plugin and the snippet together, or every publication sends two pings.

The feed should carry the full text of each post, not only an excerpt. In WordPress that is controlled by the rss_use_excerpt option in the reading settings: with the value 0 the Atom feed prints the full text in its <content> element, and the RSS 2.0 feed uses <content:encoded>.

#How to configure cache control headers and cloudflare edge caching for rss and atom feeds

When hubs and crawlers fetch feeds after each publication, every uncached request runs the full WordPress PHP stack. A short shared cache keeps the feed fresh and protects the origin server. In Nginx:

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

The same header can be set from WordPress itself:

<?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);

With max-age=300 a CDN such as Cloudflare may serve the feed for up to five minutes, and stale-while-revalidate=600 lets it serve the previous copy while it fetches a new one. Keep the TTL short. A feed cached for hours would defeat the WebSub ping, because the hub would fetch the stale version. If you cache feeds at the edge for longer, purge the feed URL on publication.

#How to build topical authority and wikidata entity mapping for discover personalization

Discover matches content to interests, and Google describes those interests in terms of topics rather than keywords. Google does not publish how Discover maps pages to topics, so the realistic goal is to make the subject of each page unambiguous: clear headings, consistent terminology and structured data that names the main entities.

On a WordPress site that means three things:

1. JSON-LD with about and mentions: link the main subjects to stable identifiers such as Wikidata or Wikipedia URLs, so that “Discover” or “WebSub” cannot be confused with an unrelated term.
2. Authors as Person entities: link author profiles to the profiles the author actually maintains, such as LinkedIn or GitHub, so readers and crawlers can see who wrote the content.
3. Topic clusters: publish connected articles on one subject and link them to each other, so the depth of coverage is visible.

An example graph:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "TechArticle",
      "@id": "https://wppoland.com/blog/how-does-the-new-google-discover-concierge-work/#article",
      "isPartOf": {
        "@id": "https://wppoland.com/#website"
      },
      "headline": "How does the new google discover concierge work and how to optimize wordpress for personalized feeds",
      "description": "Comprehensive engineering guide to the Google Discover AI concierge architecture and WordPress optimization.",
      "inLanguage": "en-US",
      "mainEntityOfPage": "https://wppoland.com/blog/how-does-the-new-google-discover-concierge-work/",
      "datePublished": "2026-10-14T08:00:00+02:00",
      "dateModified": "2026-10-14T10:30:00+02:00",
      "image": {
        "@type": "ImageObject",
        "@id": "https://wppoland.com/blog/how-does-the-new-google-discover-concierge-work/#primaryimage",
        "url": "https://wppoland.com/images/digital-experience-platforms-dxp-vs-wordpress.avif",
        "width": 1344,
        "height": 768,
        "caption": "Optimizing WordPress for Google Discover feeds"
      },
      "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>

Structured data is not a Discover requirement; Google states that no special tags are needed. Its value here is that it removes ambiguity about what the page is about and who wrote it.

#How to optimize woocommerce products for proactive discovery in google feeds

Google’s Discover documentation does not describe product cards or any WooCommerce-specific feature. What a store controls is the quality of its product data in Google Search in general, and the kind of content that Discover does show: editorial articles that are timely and useful.

Three steps keep product data consistent:

1. Price and availability in schema: WooCommerce prints Product structured data; check that price, priceCurrency and availability match what the page shows.
2. GTIN: WooCommerce 9.1 and later has a GTIN, UPC, EAN or ISBN field on the product, and its structured data class outputs a gtin property when the value is valid. Google’s merchant listing documentation lists gtin among the product identifiers it reads, so filling that field beats storing the code in a custom meta key.
3. Editorial content around products: buying guides, comparisons and test write-ups fit the Discover guidance on timely, insightful content. Product listings and category pages rarely do.

Return policy data goes into the offer through the woocommerce_structured_data_product_offer filter. WooCommerce stores offers as a list inside the product markup, so this filter is the clean place to add hasMerchantReturnPolicy, a property Google’s merchant listing documentation supports:

<?php
/**
 * Add a return policy to the WooCommerce offer schema.
 * WooCommerce 9.1+ already outputs gtin from the product GTIN field.
 */
function wppoland_discover_return_policy($markup_offer, $product) {
    $markup_offer['hasMerchantReturnPolicy'] = [
        '@type' => 'MerchantReturnPolicy',
        'applicableCountry' => 'US',
        '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);

Set the country, the number of days and the fees to the store’s actual terms. A structured data claim that contradicts the visible return policy is worse than no claim.

#How core web vitals and inp under 200ms affect google discover visibility

Google’s Discover guidance asks publishers to “provide an overall great page experience”. Discover visits happen on phones, often on mobile connections, so mobile field data matters most. The Core Web Vitals thresholds published on web.dev are:

• LCP: 2.5 seconds or less.
• INP: 200 milliseconds or less. INP replaced FID as a Core Web Vital in March 2024.
• CLS: 0.1 or less.

web.dev recommends measuring them at the 75th percentile of page loads, segmented by mobile and desktop.

In a Discover article the LCP element is usually the featured image, the same large image the card shows. Since WordPress 6.3 core adds fetchpriority="high" to the image it judges most likely to be the LCP element and stops lazy-loading images above the loop, as described in the WordPress 6.3 image performance notes. On older versions, or with themes that print the featured image outside the standard functions, the snippet below sets the attributes explicitly:

<?php
/**
 * Prioritize hero image loading to optimize LCP for Discover
 */
function wppoland_optimize_hero_lcp_discover($content) {
    if (is_singular('post')) {
        add_filter('wp_get_attachment_image_attributes', function($attr, $attachment, $size) {
            if ($size === 'discover-hero' || $size === 'post-thumbnail') {
                $attr['loading'] = 'eager';
                $attr['fetchpriority'] = 'high';
                $attr['decoding'] = 'async';
            }
            return $attr;
        }, 10, 3);
    }
    return $content;
}
add_action('wp', 'wppoland_optimize_hero_lcp_discover');

On WordPress 6.3 and later, check the rendered HTML before adding it: if core already marks the image, the filter is redundant. For INP, the usual causes on WordPress are heavy third-party scripts, sliders and consent banners that block the main thread during the first interactions.

#Why does google discover traffic spike and drop suddenly and how to maintain steady visibility

Discover traffic tends to arrive in bursts: an article is shown widely for a short time, then fades. Google’s documentation is explicit that “traffic from Discover is less predictable or dependable when compared to keyword-driven search visits” and that publishers “should consider traffic from Discover as supplemental to your keyword-driven search traffic”.

Google names the reasons traffic changes:

• Changing interests: Discover shows content aligned with what someone is interested in, and interests shift.
• Content types: Discover “has and continues to adjust the types of content that might appear on the feed”.
• Search updates: because Discover is an extension of Search, updates to Search can change Discover traffic.
• Product changes: Google states that its work on the Discover experience means sites may see traffic changes “that are unrelated to the quality or publishing frequency of their content”.

The last point corrects a common belief. Publishing more articles per week is not a documented lever for Discover. What stays under the publisher’s control is what Google’s guidance lists: timely content, clear titles, good large images and a good page experience. Updating an evergreen article with new information and a real dateModified is legitimate when the content actually changed; changing only the date is not.

For planning, treat a Discover peak as a bonus on top of search traffic, not as a baseline to budget against.

#How to track discover performance in google search console and measure conversion rates

Search Console has a separate Discover performance report under Performance. Google states that it shows impressions, clicks and CTR for content that appeared in Discover over the last 16 months, as long as the data reaches a minimum threshold of impressions. Google does not publish that threshold. The report includes traffic from Chrome and, according to the documentation, covers a site’s Discover traffic across all surfaces where people use Discover.

What to read in the report:

• Pages with impressions but low CTR: compare their images and titles with the guidance above; a logo or a text-heavy image is the first suspect.
• Country split: on multilingual sites, check that hreflang sends each reader to the right language version.
• A sudden drop to zero: check Security and Manual actions for a Discover manual action before changing anything on the site.

Google Analytics 4 has no default channel for Discover, so Search Console stays the reference for Discover clicks. To see whether Discover readers subscribe to a newsletter or place WooCommerce orders, take the landing pages from the Discover report and compare their conversions in GA4 over the same period. If you want help setting this up, talk to a WordPress specialist.