Hvordan fungerer den nye google discover assistenten og hvordan optimalisere wordpress for personlige feeder

#Hvordan fungerer den nye google discover assistenten og hvordan optimalisere wordpress for personlige feeder

Google Discover er feeden med artikler og videoer som Google-appen viser på Android og iOS uten at brukeren skriver et søk. I oktober 2026 begynte ordet “concierge” å dukke opp i omtalen av den, så det lønner seg å skille mellom det Google har rullet ut, og det Google først nå ansetter folk for å bygge. 13. oktober 2026 omtalte Search Engine Roundtable en stillingsannonse fra Google for Principal, UX, Search Discover, der det uttalte målet er å gjøre Discover til en proaktiv, hyperpersonlig concierge-opplevelse. Det er en retning i en stillingsbeskrivelse, ikke et lansert produkt. Det som faktisk kom i 2026, er styring av feeden med naturlig språk, kunngjort på Google-bloggen 20. august 2026.

For WordPress-nettsteder og WooCommerce-butikker er den praktiske konsekvensen den samme uansett. Discover velger innhold fra Googles indeks etter interesser, ikke etter søk, og noen få tekniske vilkår avgjør om en side i det hele tatt kan vises med et stort bildekort. Denne guiden skiller bekreftede fakta fra spekulasjon og går deretter gjennom WordPress-siden: robots-direktiver, bilder, feeder og WebSub, hurtigbuffer, entitetsmarkering, strukturerte data i WooCommerce, Core Web Vitals og måling i Search Console.

#Hva er forskjellen mellom google discover concierge og den tradisjonelle nyhetsfeeden

Dagens Discover-feed er en anbefalingsflate. Googles dokumentasjon for Discover beskriver den som innhold som passer til det en person er interessert i, og påpeker at slike interesser endrer seg over tid. Det finnes ikke noe søk og ingen plassering i vanlig forstand: en side blir enten vist til en person med passende interesser, eller ikke.

Betegnelsen concierge kommer fra annonsen på Googles karriereside. Ifølge utdragene som Search Engine Roundtable siterer, skal stillingen lede arbeidet med en “proaktiv, hyperpersonlig concierge-opplevelse”, “balansere KI-funksjoner og samtidig sette menneskelige stemmer og kilder i sentrum” og “videreutvikle feedformater ved å skalere KI-baserte formater” (stillingsannonse fra Google, sitert av Search Engine Roundtable, egen oversettelse). Det beskriver en intensjon og et rekrutteringsoppdrag. Annonsen nevner ingen korttyper, ingen datakilder og ingen lanseringsdato, og Google har ikke publisert noen utviklerdokumentasjon for en concierge-modus. Enhver tekst som forklarer hvordan conciergen rangerer innhold, hvilke signaler fra Kalender eller Maps den leser, eller hvilke kortformater den lager, gjetter.

Den bekreftede endringen er mindre og allerede ute hos brukerne. I et innlegg på Google-bloggen datert 20. august 2026 skrev Mrinalini Loew, General Manager for Google Search Ecosystem, at man “i løpet av de kommende dagene i Google-appen kan trykke på hvilken som helst trepunktsmeny i feeden for å fortelle Google med egne ord nøyaktig hvilke emner eller lenker man vil se mer (eller mindre) av”, og at “feeden tilpasser seg fortløpende og husker ønskene” (Mrinalini Loew, Google, egen oversettelse). Før dette styrte brukerne feeden hovedsakelig med følg-knappen og “ikke interessert”.

For utgivere betyr dette én konkret ting. En leser kan nå beskrive en interesse med vanlige ord, helt ned til et smalt underemne, og feeden skal ta hensyn til det. Innhold som tydelig sier hva det handler om, i tittelen, overskriftene og hovedbildet, er lettere å koble til en slik forespørsel enn en vag eller klikkagn-preget overskrift. Googles retningslinjer for Discover ber allerede om sidetitler og overskrifter som fanger kjernen i innholdet. Styring med naturlig språk gjør det rådet mer konkret, men erstatter det ikke.

#Hvilke tekniske krav må et wordpress nettsted oppfylle for å vises i google discover

Det finnes ingen registrering for Discover. Googles dokumentasjon sier at innhold automatisk er kvalifisert for Discover hvis det er indeksert av Google og oppfyller innholdsreglene for Discover, at det ikke trengs spesielle tagger eller strukturerte data, og at kvalifisering ikke er noen garanti for visning. Det første kravet er derfor vanlig indekserbarhet: siden svarer med 200, er ikke blokkert i robots.txt, har ikke noindex og har en kanonisk adresse som peker på seg selv eller på versjonen du vil ha indeksert.

Det andre kravet gjelder store forhåndsvisninger av bilder. Google nevner robots-innstillingen max-image-preview:large, eller AMP, som vilkåret for store bilder i Discover. Uten den kan en side fortsatt vises, men bare med et lite miniatyrbilde. Direktivet ser slik ut:

<!-- Korrekt robots-konfigurasjon for Google Discover i HTML-head -->
<meta name="robots" content="index, follow, max-image-preview:large, max-snippet:-1, max-video-preview:-1" />

WordPress-kjernen har skrevet ut dette direktivet som standard siden versjon 5.7 via funksjonen wp_robots_max_image_preview_large(), men bare når alternativet blog_public er på, altså når nettstedet ikke ber søkemotorer om å la være å indeksere. Sjekk først den gjengitte taggen <meta name="robots">. Hvis et tema, en SEO-utvidelse eller en rest fra staging fjerner eller overstyrer verdien, gjenoppretter et filter på wp_robots i functions.php i undertemaet den med sen prioritet:

<?php
/**
 * Haandhev robots-direktiver for Google Discover i WordPress
 */
function wppoland_discover_robots_nb($robots) {
    $robots['max-image-preview'] = 'large';
    $robots['max-snippet'] = -1;
    $robots['max-video-preview'] = -1;
    return $robots;
}
add_filter('wp_robots', 'wppoland_discover_robots_nb', 99);

Det tredje kravet er selve bildet. Google anbefaler å bruke schema.org-markering eller metataggen og:image for å angi et stort bilde som er relevant og representativt for siden, fordi dette kan påvirke hvilket bilde som velges. En ødelagt eller bitteliten og:image stenger ikke i seg selv siden ute fra Discover, men den tar fra deg kontrollen over hvilket bilde Google velger. Google dokumenterer ikke hvilke Open Graph-felt utover bildet Discover leser, så HTML-taggen <title> og den synlige overskriften må også være riktige, ikke bare Open Graph-taggene.

#Hvilket innhold filtrerer google discover bort og når kommer manuelle tiltak

Discover har egne innholdsregler i tillegg til de generelle reglene for Google Søk. Dokumentasjonen lister opp formater som Discover kan unngå å vise: jobbsøknader, opprop, skjemaer, kodelagre og satire uten kontekst. Discover filtrerer også innhold som kan virke sjokkerende eller uventet for noen som ikke har søkt etter det. Et WordPress-nettsted som publiserer kodesnutter som et kodelager, eller landingssider som i hovedsak er skjemaer, bør ikke forvente å se de adressene i Discover, uansett kvalitet.

Rådene om presentasjon er konkrete. Google ber utgivere unngå klikkagn, altså villedende eller overdrevne detaljer i forhåndsvisningen (tittel, utdrag eller bilder) for å øke appellen, eller å holde tilbake avgjørende informasjon som trengs for å forstå hva innholdet handler om. Google ber også om å unngå sensasjonalisme som spiller på sykelig nysgjerrighet, pirring eller harme. I stedet etterspør Google innhold som er aktuelt for dagens interesser, forteller en historie godt eller gir unik innsikt.

Når et nettsted bryter disse reglene, kan det ifølge Google dukke opp manuelle tiltak for Discover i Search Console under Sikkerhet og manuelle tiltak. Det er første sted å sjekke hvis Discover-trafikken forsvinner helt mens søketrafikken holder seg stabil. Et manuelt tiltak for Discover vises ikke som et fall i resultatrapporten for nettsøk, så et nettsted kan se friskt ut i én rapport og være utestengt i den andre.

I en redaksjon på WordPress gir dette tre kontroller før publisering: overskriften sier hvilket spørsmål artikkelen besvarer, fremhevet bilde viser emnet i stedet for en logo eller et tekstbanner, og første avsnitt leverer det overskriften lover.

#Hvorfor er store bilder over 1200px og max image preview large obligatorisk

Discover er en visuell feed, og bildet avgjør hvor stor plass et kort får. Googles dokumentasjon oppgir kravene til store bilder:

• Bredde: minst 1200 px.
• Oppløsning: over 300 000 piksler totalt.
• Sideforhold: 16x9.
• Robots-innstilling: aktivert med max-image-preview:large eller med AMP.

Google legger til to advarsler som er lette å overse i WordPress-temaer. Unngå generiske bilder, for eksempel nettstedets logo, i schema.org-markering eller og:image, og det er nettopp logoen mange temaer og SEO-utvidelser faller tilbake på når et innlegg mangler fremhevet bilde. I tillegg gir det best resultat å unngå teksttunge bilder i disse feltene, noe som utelukker tittelkort med overskriften satt i stor skrift.

En egen bildestørrelse gjør 1200 px-regelen håndhevbar i stedet for å avhenge av hva hver redaktør laster opp. Snutten under registrerer en beskjæring på 1344 ganger 768, nær 16:9 og rundt 1,03 millioner piksler, og skriver bare ut Open Graph-bildetaggene når den genererte filen faktisk når 1200 px:

<?php
/**
 * Registrer dedikert bildestoerrelse for Google Discover
 */
function wppoland_setup_discover_bilder_nb() {
    add_image_size('discover-hero-nb', 1344, 768, true);
}
add_action('after_setup_theme', 'wppoland_setup_discover_bilder_nb');

/**
 * Legg til Open Graph-bilde med eksplisitte dimensjoner i head
 */
function wppoland_inject_discover_og_bilde_nb() {
    if (is_singular('post')) {
        global $post;
        if (has_post_thumbnail($post->ID)) {
            $bilde = wp_get_attachment_image_src(get_post_thumbnail_id($post->ID), 'discover-hero-nb');
            if ($bilde && $bilde[1] >= 1200) {
                echo '<meta property="og:image" content="' . esc_url($bilde[0]) . '" />' . "\n";
                echo '<meta property="og:image:width" content="' . esc_attr($bilde[1]) . '" />' . "\n";
                echo '<meta property="og:image:height" content="' . esc_attr($bilde[2]) . '" />' . "\n";
                echo '<meta property="og:image:type" content="image/avif" />' . "\n";
            }
        }
    }
}
add_action('wp_head', 'wppoland_inject_discover_og_bilde_nb', 5);

To praktiske merknader. Beskjæringen lages bare for bilder som lastes opp etter at størrelsen er registrert, så eldre innlegg trenger nye miniatyrbilder, for eksempel med wp media regenerate i WP-CLI. WordPress forstørrer heller ikke et kildebilde som er mindre enn beskjæringen, og derfor sjekker snutten den faktiske bredden før taggene skrives ut. Hvis bildene dine ikke er AVIF, endre verdien i og:image:type til den faktiske filtypen.

#Hvordan implementere websub i wordpress for indeksering på få sekunder

Ferskhet betyr noe i Discover fordi Googles retningslinjer ber om innhold som er aktuelt for dagens interesser. Jo før Google får vite om en ny adresse, desto før kan den vurderes. Nettstedskart fungerer, men Google henter dem etter egen timeplan. WebSub er en push-mekanisme: utgiveren forteller en hub at en feed er endret, og huben varsler abonnentene.

WebSub, tidligere PubSubHubbub, er en W3C-anbefaling. Spesifikasjonen fastsetter hvordan en utgiver annonserer huben sin: med HTTP-Link-hoder eller med <link>-elementer, rel="hub" for huben og rel="self" for feedens egen adresse. Den lar bevisst stå åpent hvordan utgiveren varsler huben. Spesifikasjonen kaller denne mekanismen uspesifisert, og mange huber, også Googles offentlige hub på https://pubsubhubbub.appspot.com/, godtar en POST med hub.mode=publish og hub.url satt til feeden. Google dokumenterer ikke at et ping til huben deres gjør at en side kommer raskere inn i Discover, så se på WebSub som en måte å korte ned oppdagelsen av feeden på, ikke som en Discover-bryter.

Snutten under sender pinget ved publisering og legger til oppdagelseslenkene i Atom-feeden uten ekstra utvidelse:

<?php
/**
 * Send WebSub-varsel til Googles hub ved publisering av artikkel
 */
function wppoland_ping_websub_hub_nb($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, // Asynkron sending hindrer forsinkelse i editoren
        '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_nb', 10, 2);

/**
 * Legg til hub- og self-lenker i Atom-feed
 */
function wppoland_add_atom_links_nb() {
    $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_links_nb');

Foretrekker du en vedlikeholdt utvidelse, finnes WebSub (FKA. PubSubHubbub) i katalogen på WordPress.org. Den annonserer huber i feedene og sender publiseringspinget. Ikke kjør utvidelsen og snutten samtidig, ellers sender hver publisering to ping.

Feeden bør inneholde hele teksten i hvert innlegg, ikke bare et utdrag. I WordPress styres dette av alternativet rss_use_excerpt i leseinnstillingene: med verdien 0 skriver Atom-feeden ut hele teksten i elementet <content>, og RSS 2.0-feeden bruker <content:encoded>.

#Hvordan konfigurere cache kontroll og cloudflare edge caching for rss og atom feeder

Når huber og roboter henter feeder etter hver publisering, kjører hver forespørsel uten hurtigbuffer hele PHP-stakken i WordPress. En kort delt hurtigbuffer holder feeden fersk og beskytter opprinnelsesserveren. I Nginx:

# Nginx-oppsett for lynraske WordPress-feeder
location ~* /feed/ {
    add_header Cache-Control "public, max-age=300, stale-while-revalidate=600";
    expires 5m;
}

Samme hode kan settes fra WordPress:

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

Med max-age=300 kan et CDN som Cloudflare levere feeden i opptil fem minutter, og stale-while-revalidate=600 lar det levere forrige kopi mens det henter en ny. Hold TTL kort. En feed som bufres i timevis, gjør WebSub-pinget meningsløst, fordi huben henter den utdaterte versjonen. Hvis du bufrer feeder lenger på kanten, tøm feedadressen ved hver publisering.

#Hvordan bygge topisk autoritet og koble entiteter mot wikidata for personlige feeder

Discover kobler innhold til interesser, og Google beskriver disse interessene i form av emner, ikke søkeord. Google publiserer ikke hvordan Discover knytter sider til emner, så det realistiske målet er å gjøre emnet for hver side entydig: tydelige overskrifter, konsekvent terminologi og strukturerte data som navngir de viktigste entitetene.

På et WordPress-nettsted betyr det tre ting:

1. JSON-LD med about og mentions: koble hovedemnene til stabile identifikatorer som Wikidata- eller Wikipedia-adresser, slik at “Discover” eller “WebSub” ikke kan forveksles med et annet begrep.
2. Forfattere som Person-entiteter: koble forfatterprofiler til profiler forfatteren faktisk holder ved like, for eksempel LinkedIn eller GitHub, slik at lesere og roboter ser hvem som skrev innholdet.
3. Emneklynger: publiser sammenhengende artikler om ett emne og lenk dem til hverandre, slik at dybden i dekningen blir synlig.

Et eksempel på en graf:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "TechArticle",
      "@id": "https://wppoland.com/blog/hvordan-fungerer-den-nye-google-discover-assistenten/#article",
      "isPartOf": {
        "@id": "https://wppoland.com/#website"
      },
      "headline": "Hvordan fungerer den nye google discover assistenten og hvordan optimalisere wordpress for personlige feeder",
      "description": "Omfattende teknisk guide om arkitekturen bak Google Discover AI-assistenten og WordPress-optimalisering.",
      "inLanguage": "nb-NO",
      "mainEntityOfPage": "https://wppoland.com/blog/hvordan-fungerer-den-nye-google-discover-assistenten/",
      "datePublished": "2026-10-14T08:00:00+02:00",
      "dateModified": "2026-10-14T10:30:00+02:00",
      "image": {
        "@type": "ImageObject",
        "@id": "https://wppoland.com/blog/hvordan-fungerer-den-nye-google-discover-assistenten/#primaryimage",
        "url": "https://wppoland.com/images/digital-experience-platforms-dxp-vs-wordpress.avif",
        "width": 1344,
        "height": 768,
        "caption": "Optimalisering av WordPress for 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>

Strukturerte data er ikke et krav for Discover; Google skriver at det ikke trengs spesielle tagger. Verdien her er at de fjerner tvetydighet om hva siden handler om og hvem som skrev den.

#Hvordan optimalisere woocommerce nettbutikker for proaktiv oppdagelse i google discover

Dokumentasjonen for Discover beskriver verken produktkort eller noen WooCommerce-spesifikk funksjon. Det en butikk kontrollerer, er kvaliteten på produktdataene i Google Søk generelt og hvilken type innhold Discover faktisk viser: redaksjonelle artikler som er aktuelle og nyttige.

Tre steg holder produktdataene konsistente:

1. Pris og tilgjengelighet i skjemaet: WooCommerce skriver ut strukturerte data av typen Product; sjekk at price, priceCurrency og availability stemmer med det siden viser.
2. GTIN: WooCommerce har siden versjon 9.1 et felt for GTIN, UPC, EAN eller ISBN på produktet, og klassen for strukturerte data skriver ut egenskapen gtin når verdien er gyldig. Googles dokumentasjon for selgeroppføringer regner gtin blant produktidentifikatorene den leser, så det er bedre å fylle ut dette feltet enn å lagre koden i et eget metafelt.
3. Redaksjonelt innhold rundt produktene: kjøpeguider, sammenligninger og testomtaler passer til Discover-retningslinjene om aktuelt og innsiktsfullt innhold. Produktlister og kategorisider gjør det sjelden.

Returdata legges inn i tilbudet via filteret woocommerce_structured_data_product_offer. WooCommerce lagrer tilbud som en liste inne i produktmarkeringen, så dette filteret er det ryddige stedet for hasMerchantReturnPolicy, en egenskap Googles dokumentasjon for selgeroppføringer støtter:

<?php
/**
 * Legg til returvilkår i tilbudsskjemaet til WooCommerce.
 * WooCommerce 9.1+ skriver allerede ut gtin fra produktets GTIN-felt.
 */
function wppoland_discover_return_policy($markup_offer, $product) {
    $markup_offer['hasMerchantReturnPolicy'] = [
        '@type' => 'MerchantReturnPolicy',
        'applicableCountry' => 'NO',
        '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);

Sett land, antall dager og gebyrer etter butikkens faktiske vilkår. Strukturerte data som motsier de synlige returvilkårene, er verre enn ingen.

#Hvilken innvirkning har core web vitals og inp under 200ms på synlighet i discover

Discover-retningslinjene ber utgivere om å gi en god sideopplevelse totalt sett. Discover-besøk skjer på telefoner, ofte over mobilnett, så mobile feltdata betyr mest. Tersklene for Core Web Vitals publisert på web.dev er:

• LCP: 2,5 sekunder eller mindre.
• INP: 200 millisekunder eller mindre. INP erstattet FID som Core Web Vital i mars 2024.
• CLS: 0,1 eller mindre.

web.dev anbefaler å måle dem ved 75. persentil av sidevisningene, delt opp etter mobil og datamaskin.

I en Discover-artikkel er LCP-elementet som regel det fremhevede bildet, det samme store bildet som kortet viser. Siden WordPress 6.3 legger kjernen til fetchpriority="high" på bildet den regner som mest sannsynlig LCP-element, og slutter å lat-laste bilder over løkken, slik notatene om bildeytelse i WordPress 6.3 beskriver. I eldre versjoner, eller med temaer som skriver ut det fremhevede bildet utenfor standardfunksjonene, setter snutten under attributtene eksplisitt:

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

I WordPress 6.3 og nyere bør du sjekke gjengitt HTML før du legger den til: hvis kjernen allerede merker bildet, er filteret overflødig. For INP er de vanlige årsakene i WordPress tunge tredjepartsskript, glidere og samtykkebannere som blokkerer hovedtråden under de første interaksjonene.

#Hvorfor faller trafikken fra google discover plutselig og hvordan bevare jevn synlighet

Discover-trafikk kommer gjerne i bølger: en artikkel vises bredt en kort stund og ebber så ut. Googles dokumentasjon sier rett ut at trafikk fra Discover er mindre forutsigbar og pålitelig enn besøk fra søkeordbasert søk, og at utgivere bør se på den som et supplement til søketrafikken.

Google nevner årsakene til at trafikken endrer seg:

• Endrede interesser: Discover viser innhold som passer til det en person er interessert i, og interesser flytter seg.
• Innholdstyper: Discover har justert og fortsetter å justere hvilke typer innhold som kan vises i feeden.
• Oppdateringer av søket: Discover er en utvidelse av søket, så oppdateringer av søket kan endre Discover-trafikken.
• Produktendringer: Google sier at arbeidet med Discover kan gi trafikkendringer som ikke har noe med kvaliteten eller publiseringsfrekvensen til innholdet å gjøre.

Det siste punktet korrigerer en utbredt antakelse. Å publisere flere artikler per uke er ikke en dokumentert spak for Discover. Det som forblir i utgiverens hånd, er det Googles retningslinjer lister opp: aktuelt innhold, tydelige titler, gode store bilder og en god sideopplevelse. Å oppdatere en eviggrønn artikkel med ny informasjon og en ekte dateModified er greit når innholdet faktisk er endret; å bare endre datoen er det ikke.

I planleggingen bør en Discover-topp behandles som en bonus på toppen av søketrafikken, ikke som et grunnlag for budsjettet.

#Hvordan spore resultater i google search console og analysere konverteringer fra discover

Search Console har en egen Discover-rapport under Resultater. Google oppgir at den viser visninger, klikk og CTR for innhold som har vært vist i Discover de siste 16 månedene, så lenge dataene når en minsteterskel for visninger. Google publiserer ikke terskelen. Rapporten inkluderer trafikk fra Chrome og dekker ifølge dokumentasjonen et nettsteds Discover-trafikk på alle flater der folk bruker Discover.

Hva du bør se etter i rapporten:

• Sider med visninger, men lav CTR: sammenlign bildene og titlene med rådene over; en logo eller et teksttungt bilde er første mistenkte.
• Fordeling på land: på flerspråklige nettsteder bør du sjekke at hreflang sender hver leser til riktig språkversjon.
• Plutselig fall til null: sjekk Sikkerhet og manuelle tiltak for et manuelt tiltak for Discover før du endrer noe på nettstedet.

Google Analytics 4 har ingen standardkanal for Discover, så Search Console er fortsatt referansen for klikk fra Discover. For å se om Discover-lesere abonnerer på et nyhetsbrev eller legger inn bestillinger i WooCommerce, tar du landingssidene fra Discover-rapporten og sammenligner konverteringene deres i GA4 for samme periode. Trenger du hjelp med oppsettet, snakk med en WordPress-spesialist.