Google tester venstre sidemeny i PC søk: hvordan optimalisere WordPress for AI Mode

Google tester venstre sidemeny i PC søk: hvordan optimalisere WordPress for AI Mode

Sist verifisert: 16. oktober 2026
15 min lesetid
Guide
Teknisk SEO
500+ WP-prosjekter

#Hva Google tester i sidemenyen i søk på PC

  1. oktober 2026 skrev Barry Schwartz på Search Engine Roundtable at Google ser ut til å teste den venstre vertikale sidemenyen fra AI Mode på den vanlige resultatsiden for nettsøk. Med hans ord: “Dette plasserer den lille super-G-logoen til Google til venstre, sammen med strekene for chatloggen, en måte å starte en chat med AI Mode på og innstillingsikonet, alt på venstre side” (egen oversettelse).

Det var Damien Andell som oppdaget det. Han delte et skjermbilde på X og spurte: “Er sidemenyen nå standard sidemeny hos Google på søkeresultatsider? Jeg vet at den allerede var der når du klikket på AI Mode-knappen på forsiden, men nå er den standard for hvert søk” (egen oversettelse).

Schwartz klarte ikke å gjenskape det: “Jeg har ikke klart å gjenskape dette i noen av nettleserne mine ennå, så jeg mistenker at det er en test” (egen oversettelse). Han la til at en utrulling ville gjøre AI Mode “enda mer tilgjengelig via det vanlige søkegrensesnittet til Google” (egen oversettelse).

Mer offentlig dokumentasjon finnes ikke: ett skjermbilde fra én bruker og én bransjeartikkel. Google har ikke publisert noen kunngjøring, hjelpeside eller blogginnlegg om denne layouten. Omtalen viser ingen emnefiltre, formatvelgere eller hopplenker til seksjoner i sidemenyen, så en beskrivelse som tar dem med, går lenger enn bevisene.

+-----------------------------------------------------------------------------+
| Resultatside på PC slik omtalen beskriver den (ubekreftet test)             |
| +---------------------+  +------------------------------------------------+ |
| | VENSTRE SIDEMENY    |  | HOVEDOMRÅDE FOR RESULTATER                     | |
| | - Googles "G"-logo  |  | Uendret, så langt omtalen sier                 | |
| | - Chatlogg          |  |                                                | |
| | - Ny chat i AI Mode |  |                                                | |
| | - Innstillinger     |  |                                                | |
| +---------------------+  +------------------------------------------------+ |
+-----------------------------------------------------------------------------+

#Har Google bekreftet testen av sidemenyen i AI Mode

Nei. Per 16. oktober 2026 er de eneste kildene skjermbildet på X og omtalen hos Search Engine Roundtable. Omtalen fikk to oppdateringer samme dag. Marie Haynes skrev først at hun så samtalene sine fra Gemini-appen i sidemenyen når hun gikk rett til AI Mode. Deretter rettet hun seg selv: samtalene kom fra Gemini-overlegget på Android-telefonen hennes, ikke fra Gemini-appen, og hun kalte det “kanskje ikke like interessant som at Gemini-appen smelter sammen med AI Mode” (egen oversettelse).

For en nettstedseier betyr dette tre ting:

  • Det finnes ingen data om layouten ennå. Ingen har publisert målinger av hvordan sidemenyen påvirker klikk på organiske treff.
  • Sidemenyen er navigasjon i Googles eget produkt. Den leder brukeren til chatter i AI Mode og loggen deres. Ingenting i omtalen viser at den lenker til tredjepartssider.
  • Det praktiske spørsmålet gjelder AI Mode selv. Hvis testen rulles ut, er flere søkere ett klikk unna AI Mode. Det som teller, er hvordan AI Mode behandler og rapporterer sidene dine, og det dokumenterer Google.

#Hva Google sier om optimalisering for AI Mode

Googles side AI features and your website er tydelig: “Det finnes ingen ekstra krav for å vises i AI Overviews eller AI Mode, og heller ingen andre spesielle optimaliseringer som er nødvendige” (egen oversettelse). En side må være indeksert og kvalifisert for å vise et utdrag i søk.

Samme side lister opp praksisene Google sier fortsatt gjelder:

  • gjennomsøking tillatt i robots.txt og av CDN og hostinglag,
  • innhold som kan finnes via interne lenker,
  • en god sideopplevelse,
  • viktig innhold tilgjengelig som tekst,
  • bilder og video som støtter teksten der det passer,
  • strukturerte data som samsvarer med den synlige teksten,
  • oppdaterte data i Merchant Center og Bedriftsprofil.

Google beskriver query fan-out, teknikken bak begge funksjonene, som å “sende flere relaterte søk på tvers av underemner og datakilder” (egen oversettelse) for å bygge et svar. Hva det betyr for oppbyggingen av seksjoner, går vi gjennom i query fan-out og siterbare seksjoner i AI-søk.

Om forskjellen mellom funksjonene skriver Google at AI Mode “er særlig nyttig for søk der det trengs videre utforskning, resonnering eller komplekse sammenligninger” (egen oversettelse), og at de to “kan bruke ulike modeller og teknikker, så svarene og lenkene de viser, vil variere” (egen oversettelse). Google hevder også at klikk fra resultatsider med AI Overviews “er av høyere kvalitet (det vil si at brukerne oftere bruker mer tid på nettstedet)” (egen oversettelse). Det er Googles påstand; selskapet publiserer ingen tall bak den.

På et WordPress-nettsted er det første punktet på listen det som oftest svikter i praksis. Sikkerhetsutvidelser og CDN-regler for roboter som stopper ukjente brukeragenter, kan også blokkere Googlebot. Kontroll av robots.txt og brannmurloggene for forespørsler fra Googlebot er en del av vår sikkerhetsrevisjon av WordPress.


#Hvordan klikk og visninger fra AI Mode vises i Search Console

Trafikk fra AI Mode har ingen egen rapport. Googles side om AI-funksjoner sier at den rapporteres i Resultater-rapporten under søketypen “Web”. Hjelpeartikkelen om visninger, posisjon og klikk definerer tellingen:

ElementKlikkVisningPosisjon
AI ModeEt klikk på en lenke til en ekstern side tellerVanlige regler for visningerSamme metode som på en vanlig resultatside
AI OverviewEt klikk på en lenke til en ekstern side tellerVanlige regler for visningerHele oversikten har én posisjon, som alle lenkene i den deler

To regler til er viktige når du leser dataene. Et oppfølgingsspørsmål i AI Mode behandles som et nytt søk, så visningene og klikkene havner på det søket og ikke på det første. Og data fra Search Labs-eksperimenter er ikke med i det hele tatt. Hvis sidemenyen fortsatt er en test, kan visninger i den mangle i rapporten din.

Search Console knytter dessuten dataene til den kanoniske URL-en Google velger, ikke til den nøyaktige adressen den besøkende klikket på. En lenke til /guide/#steg-3 rapporteres under /guide/. Fragmentet når heller ikke serveren, fordi nettlesere ikke sender det med forespørselen. Det eneste stedet du kan se hvilken seksjon en besøkende kom til, er JavaScript på klientsiden som leser location.hash ved innlasting og sender det til analyseverktøyet ditt.


#Hvordan Google lenker til en bestemt seksjon på en side

Mekanismen Google dokumenterer, er “Read more”-dyplenken. Dokumentasjonen om utdrag definerer den som “en lenke i et utdrag som leder brukerne til en bestemt seksjon på siden” (egen oversettelse). Google nevner tre praksiser som gjør slike lenker mer sannsynlige:

  1. Innholdet må være umiddelbart synlig for et menneske, “og ikke skjult bak en sammenleggbar seksjon eller et fanegrensesnitt” (egen oversettelse).
  2. Unngå JavaScript som styrer rulleposisjonen ved innlasting, for eksempel ved å tvinge brukeren til toppen av siden.
  3. Hvis siden kaller History API eller endrer window.location.hash ved innlasting, må den ikke fjerne hash-fragmentet fra URL-en, “siden det ødelegger dyplenkingen” (egen oversettelse).

Hver regel svarer til noe som er vanlig på WordPress-nettsteder:

  • Trekkspill og faner. FAQ-blokker, fanemoduler fra sidebyggere og “vis mer”-beholdere skjuler tekst ved innlasting. Innhold Google kan ønske å dyplenke til, bør ligge i den vanlige flyten på siden.
  • Rulleskript. Noen temaer og utvidelser for myk rulling kaller window.scrollTo(0, 0) ved innlasting eller animerer siden til toppen. Det overstyrer nettleserens hopp til målet.
  • Opprydding i hash. Ensidetemaer og enkelte informasjonskapselbannere skriver om URL-en med history.replaceState() for å fjerne #seksjon. Det er nettopp dette Google sier ødelegger dyplenking.

En rask test: åpne et langt innlegg med #en-overskrift lagt til, last siden på nytt og sjekk at nettleseren blir stående ved overskriften og at hashen fortsatt står i adressefeltet.


#Hvordan legge til ID-er på overskrifter i WordPress automatisk

Blokkredigeringen har innebygd støtte. En blokk som erklærer anchor: true i sine supports, får et felt for en ID, og referansen for block supports sier det kort: “Ankere lar deg lenke direkte til en bestemt blokk på en side” (egen oversettelse). Kjerneblokken Overskrift har dette under Avansert > HTML-anker. Redaktører fyller det sjelden ut, så lange arkiver ender opp med overskrifter det ikke går an å lenke til.

Filteret under legger til en renset id på hver H2 og H3 som mangler det, ved visning og uten å endre lagret innhold:

add_filter('the_content', function ($content) {
    if (!is_singular('post')) {
        return $content;
    }

    return preg_replace_callback('/<h([2-3])(.*?)>(.*?)<\/h\1>/i', function ($matches) {
        $tag_level = $matches[1];
        $attributes = $matches[2];
        $heading_text = $matches[3];

        // Behold ID-er som er satt manuelt
        if (preg_match('/id=[\'"][^\'"]+[\'"]/i', $attributes)) {
            return $matches[0];
        }

        // Fjern HTML-tagger for å få en ren ankerslug
        $plain_text = wp_strip_all_tags($heading_text);
        $slug = sanitize_title($plain_text);

        if (empty($slug)) {
            return $matches[0];
        }

        return sprintf('<h%d%s id="%s">%s</h%d>', $tag_level, $attributes, esc_attr($slug), $heading_text, $tag_level);
    }, $content);
}, 20);

Hver overskrift har nå en stabil fragment-URL, for eksempel #konfigurasjon-av-databasebuffer. To begrensninger gjelder. To overskrifter med samme tekst får samme ID, så et innlegg med gjentatte overskrifter trenger en teller lagt til. Og endrer du ordlyden i en overskrift, endres ID-en, noe som bryter alle lenker til den gamle; sett et manuelt HTML-anker på overskrifter andre sider lenker til.

Ankerne hjelper lesere, innholdsfortegnelser og lenker fra andre nettsteder. Google sier ikke at “Read more”-dyplenker krever ID-er, så se på dem som god struktur, ikke som en rangeringsbryter.


#Hvordan lenker med tekstfragment oppfører seg på en WordPress-side

Lenker fra søkeresultater til et avsnitt bruker ofte et tekstfragment i stedet for en ID. MDN dokumenterer syntaksen som #:~:text=[prefix-,]textStart[,textEnd][,-suffix]. Nettleseren leter etter teksten på siden, ruller til den og uthever den. Du trenger ingen ID på din side.

Noen detaljer fra MDN som påvirker WordPress-nettsteder:

  • Delen :~: er fragmentdirektivet. Nettlesere fjerner det fra URL-en under innlasting, “slik at forfatterens skript ikke kan samhandle direkte med det” (egen oversettelse). Analyseverktøyet ditt ser det ikke i location.hash.
  • Tekstfragmenter “aktiveres bare ved navigering som brukeren selv starter” (egen oversettelse), og bare i hovedrammen, aldri inne i en <iframe>.
  • Hvis teksten ikke treffer noe på siden, ignoreres fragmentet og siden åpnes på toppen. Tekst som skiller seg mellom indeksert og gjeldende versjon, for eksempel etter en redigering eller på grunn av personlig tilpasset innhold, bryter lenken uten at noen merker det.
  • Uthevingen kan styles med pseudoelementet ::target-text, og document.fragmentDirective finnes bare i nettlesere som støtter funksjonen.
  • Chromium-nettlesere respekterer headeren Document-Policy: force-load-at-top, som slår av rulling til fragmenter. Ikke sett den på innholdssider med mindre det er det du vil.

Tekstfragmenter er enda en grunn til å levere avsnitt som ekte tekst i HTML. Et avsnitt som tegnes av JavaScript etter innlasting, eller som en sidebygger deler opp i inline-elementer, treffer kanskje ikke.


#Hvordan optimalisere Core Web Vitals for besøkende via ankerlenker

Når en besøkende følger en fragmentlenke, ruller nettleseren rett til målelementet. Det hoppet utsetter siden for Cumulative Layout Shift (CLS).

Hvis elementer over målet lastes uten reserverte dimensjoner:

  • bannerplasser uten min-height,
  • bilder uten width- og height-attributter,
  • innebygde skript fra tredjeparter og mediespillere,

tegnes de sent og skyver dokumentet nedover. En besøkende som har begynt å lese det aktuelle avsnittet, mister plassen sin.

#CSS-oppsett for stabil rulling til ankere

html {
  /* Myke overganger til fragmentankere */
  scroll-behavior: smooth;
}

/* Toppmarg så en fast toppmeny ikke dekker målet */
[id] {
  scroll-margin-top: 5rem;
}

/* Reserver minimumshøyde for medier og bannere øverst på siden */
.ad-slot-header {
  min-height: 250px;
  contain: layout;
}

img {
  max-width: 100%;
  height: auto;
  display: block;
}

scroll-margin-top setter toppmargen for rulleområdet, slik at nettleseren stopper over overskriften i stedet for å gjemme den under en fast toppmeny. Tilpass verdien til den faktiske høyden på toppmenyen, inkludert adminlinjen for innloggede brukere.

På serveren (Nginx eller Cloudflare) sørger lange hurtigbuffertider for fonter og stilark for at layouten ikke endres mens hoppet skjer:

# Lang hurtigbuffertid for statiske ressurser så hoppet tegnes med endelige stiler
location ~* \.(woff2|ttf|svg|css|js)$ {
    expires 1y;
    add_header Cache-Control "public, no-transform, immutable";
    access_log off;
}

immutable er bare trygt når adressen til ressursen endres ved hver utgivelse. WordPress legger til en ?ver=-parameter på filer som lastes via køen, så dette holder så lenge temaet eller utvidelsen øker versjonsnummeret.


#Hvordan ta i bruk haspart-strukturen fra schema org

Schema.org definerer hasPart for å angi delene av et verk. I JSON-LD kan den erklære seksjonene i en artikkel som WebPageElement, hver med sin egen fragment-URL:

add_action('wp_head', function () {
    if (!is_singular('post')) {
        return;
    }

    global $post;
    $permalink = get_permalink($post->ID);

    // Sentrale seksjoner i artikkelen
    $sections = [
        [
            'name' => 'Tekniske krav til ERP-integrasjon',
            'anchor' => 'tekniske-krav-til-erp-integrasjon',
            'description' => 'Båndbredde, JSON-dataformat og OAuth2-autentisering.'
        ],
        [
            'name' => 'Unngå vranglåser i databasen',
            'anchor' => 'unnga-vranglaser-i-databasen',
            'description' => 'HPOS-tabeller og justering av asynkrone køer i Action Scheduler.'
        ]
    ];

    $parts = [];
    foreach ($sections as $sec) {
        $parts[] = [
            '@type' => 'WebPageElement',
            'name' => $sec['name'],
            'url' => $permalink . '#' . $sec['anchor'],
            'description' => $sec['description']
        ];
    }

    $schema = [
        '@context' => 'https://schema.org',
        '@type' => 'TechArticle',
        '@id' => $permalink . '#article',
        'headline' => get_the_title($post->ID),
        'inLanguage' => 'nb-NO',
        'mainEntityOfPage' => $permalink,
        'hasPart' => $parts
    ];

    echo "\n" . '<script type="application/ld+json">' . "\n";
    echo wp_json_encode($schema, JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE | JSON_PRETTY_PRINT);
    echo "\n" . '</script>' . "\n";
}, 25);

Seksjonene i eksempelet er plassholdere fra en artikkel om WooCommerce ERP-integrasjon; i produksjon bør de hentes fra innleggets faktiske overskrifter. Koden er gyldig Schema.org, men Google dokumenterer ingen søkefunksjon som bruker hasPart med WebPageElement til seksjonslenker. Googles dokumenterte bruk av hasPart er merking av seksjoner bak betalingsmur. Regelen fra siden om AI-funksjoner gjelder: strukturerte data må samsvare med den synlige teksten, så hvert navn og anker i listen må finnes på siden.


#Hvordan begrense hva AI Mode kan sitere fra en WordPress-side

Dokumentasjonen for robots-metataggen lister opp kontrollene, og siden om AI-funksjoner nevner de samme for AI Overviews og AI Mode:

  • nosnippet gjelder “alle former for søkeresultater (hos Google: nettsøk, Google Bilder, Discover, AI Overviews, AI Mode)” (egen oversettelse).
  • max-snippet:[number] begrenser lengden på utdraget i tegn og “begrenser også hvor mye av innholdet som kan brukes som direkte input til AI Overviews og AI Mode” (egen oversettelse). 0 tilsvarer nosnippet, -1 lar Google velge.
  • data-nosnippet utelater en del av siden og virker på elementene span, div og section.
  • noindex fjerner siden helt fra søk.

WordPress har laget robots-metataggen gjennom filteret wp_robots siden versjon 5.7. En grense for utdrag på én innleggstype ser slik ut:

add_filter('wp_robots', function ($robots) {
    if (is_singular('product')) {
        $robots['max-snippet'] = '160';
    }
    return $robots;
});

data-nosnippet legges rett i koden, for eksempel i en Egendefinert HTML-blokk: <div data-nosnippet>internt prisnotat</div>. Disse kontrollene reduserer synligheten, ikke bare gjenbruken. En side som blokkerer utdrag, mister tekstutdraget også i vanlige resultater, så bruk dem på bestemte avsnitt, ikke på hele nettstedet.


#Regelen om første avsnitt for utdrag og dyplenker

Ren HTML hjelper ikke hvis teksten gjør det vanskelig å hente ut avsnitt. Utdrag, “Read more”-lenker og AI-svar løfter ut korte avsnitt, og et avsnitt som svarer på overskriften i første setning, gir mening også utenfor sammenhengen.

  1. Første setning under H2: svar direkte på spørsmålet i overskriften. Dropp innledninger som I denne seksjonen skal vi se nærmere på….
  2. Andre setning: tallet, parameteren eller begrensningen som kan etterprøves.
  3. Påfølgende avsnitt: avveininger, kode og tabeller.

Seksjoner bygget slik fungerer også for besøkende som lander midt på siden, og det er nettopp det hver fragmentlenke fører til.


#Hvilke Google-mekanismer lenker til en seksjon på siden din

MekanismeHvem lager lenkenURL-formHva nettstedet styrer
”Read more”-dyplenke i utdragGoogleSide-URL som peker til en seksjonSynlig innhold, ingen tvungen rulling, hashen beholdes
TekstfragmentGoogle eller et hvilket som helst nettsted som lenker#:~:text=...Teksten finnes i HTML og samsvarer med indeksert versjon
OverskriftsankerNettstedet, andre nettsteder, innholdsfortegnelser#overskrift-idStabile ID-er, manuelle ankere på overskrifter det lenkes til
Sitat i AI Mode eller AI OverviewGoogleSide-URL, noen ganger med fragmentIndeksering, kvalifisering for utdrag, kontroller for utdrag

#Tiltaksplan for å tilpasse WordPress-nettstedet til den nye resultatsiden

  1. Sjekk tilgangen for gjennomsøking:
    • Bekreft at robots.txt, CDN og sikkerhetsutvidelser slipper Googlebot gjennom.
  2. Test dyplenker på de viktigste sidene:
    • Åpne hver side med #overskrift-id og med et tekstfragment, last på nytt og bekreft at nettleseren blir stående ved målet og beholder hashen.
    • Fjern skript som ruller til toppen eller rydder bort hashen ved innlasting.
  3. Fyll inn overskriftsankere:
    • Legg til ID-filteret, og sett deretter manuelle HTML-ankere på overskrifter andre sider lenker til.
  4. Stabiliser layouten over seksjonene:
    • Reserver dimensjoner for bilder, annonser og innbygginger, og sett scroll-margin-top til høyden på toppmenyen.
  5. Hold strukturerte data i samsvar med innholdet:
    • Hvis du bruker hasPart, generer det fra de faktiske overskriftene.
  6. Mål på riktig sted:
    • Les klikk fra AI Mode i Resultater-rapporten i Search Console under “Web”, og husk at fragmenter ikke rapporteres der.
    • Registrer location.hash ved innlasting i analyseverktøyet ditt for å se hvilke ID-ankere som gir besøkende.
  7. Vent på bekreftelse:
    • Til Google dokumenterer sidemenyen, planlegg for AI Mode slik den finnes i dag, ikke for en ubekreftet layout.
Neste steg

Gjør artikkelen om til faktisk implementering

Denne blokken styrker intern lenking og sender leseren videre til de mest relevante tjenestene og innholdet.

Vil du få dette implementert på nettstedet ditt?

Hvis synlighet i Google og AI-systemer betyr noe, kan jeg bygge innholdsarkitektur, FAQ, schema og intern lenking for SEO, GEO og AEO.

Relevant klynge

Utforsk andre WordPress-tjenester og kunnskapsbase

Styrk virksomheten din med profesjonell teknisk støtte innen kjerneområdene i WordPress-økosystemet.

Hva er den venstre sidemenyen Google angivelig tester i søk på PC#
Det er den vertikale menyen som allerede vises i AI Mode, med Google-logoen, chatlogg, en knapp for å starte en chat i AI Mode og innstillinger. Search Engine Roundtable meldte om den på den vanlige resultatsiden 14. oktober 2026, basert på en brukers skjermbilde. Google har ikke bekreftet testen.
Endrer sidemeny-testen rangeringen av organiske treff#
Ingenting som er publisert, sier det. Omtalen beskriver et navigasjonselement, ikke en rangeringsendring, og Google dokumenterer ingen effekt på posisjoner. Behandle enhver påstand om CTR knyttet til denne testen som spekulasjon til Google eller data fra Search Console viser noe annet.
Hvordan lenker Google til en bestemt seksjon i en artikkel#
Google dokumenterer "Read more"-dyplenker i utdrag som leder til en seksjon på siden. De blir mer sannsynlige når innholdet er synlig, JavaScript ikke tvinger rulleposisjonen ved innlasting, og hash-fragmentet ikke fjernes fra URL-en.
Trenger WordPress en utvidelse for ankere i overskrifter#
Nei. Blokkredigeringen lar redaktører sette et HTML-anker på en overskrift, og et kort the_content-filter lager ID-er for overskrifter som mangler det.
Hvorfor betyr layoutforskyvning noe for besøkende som lander rett i en seksjon#
Nettleseren ruller først til målet. Bilder, annonser eller innbygginger over det som lastes uten reservert plass, skyver seksjonen ned, og leseren mister linjen de kom for. Reserverte dimensjoner og scroll-margin-top hindrer dette.

Trenger du FAQ tilpasset bransje og marked? Vi lager en versjon som støtter dine forretningsmål.

Ta kontakt

Relaterte artikler