Optimalisering for stemmesøk: Schema for å ligge i forkant i 2026

Stemmesøk har gått fra å være en teknisk kuriositet på smarttelefoner til å bli enda en inngang til informasjon: taleassistenter i bilen, smarthøyttalere på hjemmekontoret og hodetelefoner koblet til telefonen. Brukeren stiller et spørsmål og hører et svar, uten en liste med lenker.

For eiere av WordPress-nettsteder betyr dette en grunnleggende forskyvning: Det holder ikke lenger bare å vinne de ti blå lenkene på en skjerm. Målet blir det korte svaret en assistent kan lese høyt. Det målet har konkrete grenser, dokumentert av Google, Apple og Amazon, og denne guiden skiller mellom det plattformene lover skriftlig og det som bare er god redaksjonell praksis.

Utforsk våre spesialiserte tjenester innen SEO og GEO-optimalisering for AI-drevne søkemotorer og stemmeagenter.

#Hvordan AI-agenter har endret stemmesøk

De tidlige taleassistentene nøyde seg med å lese opp det øverste søkeresultatet. I dag bruker assistenter som Gemini, Siri og ChatGPT språkmodeller som sammenstiller svar:

• Sammenstilling i stedet for opplesning: Assistenten leser ikke hele avsnitt, men trekker ut det korteste svaret den kan etterprøve.
• Kildehenvisning: I det eneste tilfellet Google dokumenterer (Speakable for nyheter), oppgir assistenten kilden når den leser utdraget og sender hele artikkel-URL-en til brukerens telefon. Utenfor dette tilfellet lover ingen plattform at merkevaren din nevnes muntlig.
• Skjermfrie miljøer: Brukere som kjører bil eller utfører fysisk arbeid kan ikke bla gjennom søkeresultater. Svaret må være presist og forståelig uten grafisk støtte.
• Sammenhengende dialog: Assistenten håndterer oppfølgingsspørsmål, så et godt strukturert første svar gjør det lettere å følge opp.

#Hvorfor du ikke lenger kan bygge din egen Google Assistant-handling

I noen år var en Conversational Action veien inn i Google Assistant: en taleapp med intents, scener og webhooks. Den veien er stengt. Googles utviklerdokumentasjon sier at Conversational Actions ble avviklet 13. juni 2023. En artikkel som fortsatt anbefaler å bygge en talehandling for Assistant, er utdatert.

For et WordPress-nettsted gjenstår tre veier: å være en kilde som søkesystemer kan gjennomsøke og sitere, å merke utdrag med Speakable der Google støtter det, og å publisere innhold i formater en assistent henter direkte, som Alexas flash briefing-feed beskrevet lenger ned. Et eget REST-endepunkt “for taleagenter” har i dag ingen dokumentert mottaker, så jeg har fjernet det tidligere kodeeksempelet for dette fra artikkelen.

#Hva Google faktisk lover med Speakable

Egenskapen speakable er den mest siterte delen av guider om stemmesøk, og også den oftest feilbeskrevne. Den offisielle siden Speakable (Article, WebPage) structured data er kort og tydelig:

• Den er i beta. Google advarer om at krav og retningslinjer kan endres.
• Den virker i ett marked. Ifølge dokumentasjonen fungerer egenskapen for brukere i USA med Google Home-enheter satt til engelsk, og for utgivere som publiserer på engelsk.
• Den gjelder nyheter. Google Assistant bruker Speakable til å svare på spørsmål om aktuelle nyheter på smarthøyttalere, og returnerer opptil tre artikler fra ulike publikasjoner.
• Den oppgir kilden og sender videre. Når Assistant leser en merket del, oppgir den kilden og sender hele artikkel-URL-en til brukerens telefon via Google Assistant-appen.

“For en optimal lydopplevelse anbefaler vi rundt 20 til 30 sekunder innhold per seksjon med speakable-data, eller omtrent to til tre setninger.”

Google Search Central, Speakable-dokumentasjonen (egen oversettelse)

De tekniske retningslinjene har detaljer nesten ingen veiledninger nevner. Ikke merk stedsangivelser (hvor saken ble skrevet), bildetekster eller kildehenvisninger, fordi de høres forvirrende ut i lyd. Bruk cssSelector eller xPath, aldri begge i samme spesifikasjon. Og som for alle strukturerte data garanterer ikke Google at funksjonen vises.

Den praktiske konsekvensen for et norsk nettsted: Speakable gir i dag ikke noe dokumentert stemmeresultat for sider på norsk eller for brukere i Norge. Merkingen skader ikke, men den er ingen bryter for “stemme-SEO”, og ingen bør love en kunde stemmeresultater basert på den. Det som kan overføres til andre markeder og assistenter, er den redaksjonelle disiplinen Google ber om: korte sammendrag, selvstendige setninger, ingenting som trenger et bilde for å gi mening.

#Slik legger du til Speakable Schema i WordPress

Google dokumenterer speakable som strukturerte data for Article og WebPage. Egenskapen peker med CSS-selektorer (eller XPath) på utdrag som kan leses opp. Referansedefinisjonen finnes på schema.org/SpeakableSpecification.

#Når Speakable lønner seg og når det ikke gjør det

• Nyttig på engelskspråklige nyhetsartikler eller guider med et kort, saklig og stabilt sammendrag med en unik ID.
• Lite nyttig hvis du merker hele siden, lange blokker, salgsknapper eller tekst som endres ved hver utrulling.
• Begrenset av marked og språk: utenfor USA og engelsk har merkingen ingen dokumentert effekt.
• Et tillegg, ikke en erstatning: kvaliteten på svaret under H2 betyr mer enn JSON-LD alene.

#JSON-LD-eksempel for SpeakableSpecification

Egenskapen legges inn i sidens eksisterende Article- eller TechArticle-skjema og peker på unike CSS-selektorer i HTML-koden:

<!-- Eksempel: Strukturert JSON-LD for opplesbart innhold -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "Optimalisering for stemmesøk: Schema for å ligge i forkant i 2026",
  "url": "https://wppoland.com/nb/voice-search-seo-wordpress-guide-2026-nb/",
  "inLanguage": "nb-NO",
  "speakable": {
    "@type": "SpeakableSpecification",
    "cssSelector": [
      "#introduksjon",
      ".opplest-sammendrag"
    ]
  },
  "author": {
    "@type": "Organization",
    "name": "WPPoland",
    "url": "https://wppoland.com"
  }
}
</script>

#Speakable-markering via functions.php uten utvidelse

I stedet for å belaste WordPress med tunge utvidelser kan du legge inn Speakable-oppmerkingen med en lettvektsfunksjon på wp_head-kroken:

add_action('wp_head', 'legg_til_speakable_schema_nb');

function legg_til_speakable_schema_nb() {
    if (!is_singular('post')) {
        return;
    }

    $post_id = get_the_ID();
    $permalink = get_permalink($post_id);
    $tittel = get_the_title($post_id);

    $schema = [
        '@context'    => 'https://schema.org',
        '@type'       => 'Article',
        'headline'    => esc_html($tittel),
        'url'         => esc_url($permalink),
        'inLanguage'  => 'nb-NO',
        'speakable'   => [
            '@type'       => 'SpeakableSpecification',
            'cssSelector' => ['#introduksjon', '.stemmesvar-direkte'],
        ],
    ];

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

Praktiske merknader: sørg for at selektorene finnes i den ferdige HTML-en (Gutenberg, synkroniserte mønstre eller temaet), og escape alltid utdata. Googles test for rike resultater lister ikke Speakable blant typene den rapporterer, så kontroller syntaksen i Schema Markup Validator. Hvis en SEO-utvidelse allerede skriver ut Article, legg speakable inn i den noden i stedet for å lage en ekstra Article på samme side.

#Hvilke søkeintensjoner ligger bak stemmesøk

Den avgjørende forskjellen er ikke mikrofonen, men intensjonen. Den som skriver “wordpress redis cache” utforsker. Den som sier “hvordan setter jeg opp Redis object cache i WordPress uten å dele økter mellom butikker” vil ha en fremgangsmåte nå.

Tre muntlige mønstre trenger ulik redaksjonell behandling:

1. Fremgangsmåte (“hvordan…”, “hvilke steg…”): en kort svarblokk og synlige nummererte steg.
2. Definisjon eller sammenligning (“hva er…”, “hva er forskjellen på…”): ett saklig avsnitt på to eller tre setninger, uten innledning.
3. Lokalt eller praktisk (“i nærheten”, “i Bergen”, “i dag”): avhenger av konsistente NAP-data og LocalBusiness-skjema, ikke av en lang artikkel.

I Google Search Console kan du filtrere søk som begynner med “hvordan”, “hva”, “hvilken”, “hvor” og “når”. Disse seriene ligger nærmere talespråket enn en liste med stikkord på to ord. Skriv deretter H2 og H3 om til det faktiske spørsmålet og legg det nyttige svaret i første setning.

#Hva som endret seg for FAQ- og HowTo-resultater i 2023

FAQ og fremgangsmåter er fortsatt naturlige formater for muntlige spørsmål i sideteksten, men Googles visuelle resultater er endret. 8. august 2023 kunngjorde Google på Search Central-bloggen endringer i HowTo- og FAQ-resultater:

• FAQ: rike resultater fra FAQPage vises bare for kjente, autoritative nettsteder fra myndigheter og helsesektoren. For alle andre nettsteder vises de ikke lenger regelmessig.
• HowTo: først begrenset til datamaskin; fra 13. september 2023 sluttet Google å vise dem der også og erklærte typen avviklet.
• Eksisterende oppmerking: Google sier at den ikke må fjernes, fordi ubrukte strukturerte data ikke skaper problemer, men de har heller ingen synlig effekt i søket.

Det trygge kriteriet blir dermed redaksjonelt: spørsmål og steg hører hjemme i sideteksten fordi de svarer leseren og assistenten som henter ut tekst, ikke fordi man venter en visuell utvidelse. Beholder du FAQ- eller HowTo-JSON-LD, må den speile det synlige innholdet nøyaktig.

#Hvordan strukturere innhold for stemmesøk

AI-assistenter som leser opp tekst krever en stram oppbygning. Er svaret begravd i bakgrunnsstoff, velger systemet en mer konsis kilde. Det samme mønsteret betjener Googles utvalgte utdrag, som viser utdraget først og lenken etterpå. Det finnes ingen oppmerking som ber om et utvalgt utdrag; Google velger det fra teksten.

#1. Skriv overskrifter som spørsmål

Bruk H2- og H3-overskrifter som speiler hvordan brukere faktisk formulerer seg muntlig:

• “Hvordan tømmer man transients i WordPress-databasen”
• “Hva er forskjellen mellom Redis og Memcached for WooCommerce”

#2. Svarblokk på 40 til 60 ord under overskriften

Plasser et konsist og fullstendig svar rett under overskriften. Teksten må stå på egne ben uten avhengighet til andre avsnitt.

• Godt eksempel: “Utløpte transients i WordPress fjernes med WP-CLI-kommandoen ‘wp transient delete —expired’. Kommandoen sletter bare utløpte hurtigbufferdata i databasen og lar permanente innstillinger og innlegg være i fred.”
• Uegnet eksempel: “I denne delen skal vi se nærmere på det interessante temaet om transients og hvorfor mange opplever utfordringer med databaseytelse over tid.”

#3. Tekniske detaljer med tabeller og kode

Etter svarblokken følger forklaringer, trinnvise instruksjoner og kode. I Speakable-tilfellet sender Google artikkel-URL-en til telefonen; i andre tilfeller åpner brukeren siden senere. Begge veier må resten av artikkelen gi den faglige dybden.

#Hvordan skrive norsk tekst for opplesning

Norsk har to offisielle skriftspråk og mange dialekter, men talesyntesen leser det som står skrevet:

• Bruk et klart og normert bokmål i svarblokkene: Talesyntese leser normerte konstruksjoner tydeligere enn dialektnære skrivemåter.
• Unngå forkortelser i opplest tekst: Skriv “for eksempel” i stedet for “f.eks.” og “klokken” i stedet for “kl.”. Talesyntese kan uttale forkortelser bokstav for bokstav.
• Merkenavn med spesiell uttale: Schema.org har typen PronounceableText med egenskapen phoneticText. Den er en del av vokabularet, men verken Google, Apple eller Amazon dokumenterer at de bruker den for nettsider, så den beste løsningen er en skrivemåte som leses riktig uten hjelp.

#Hvordan styre hva assistenter kan sitere

En del av optimaliseringen er å bestemme hva som ikke skal leses opp. Googles dokumentasjon om robots-metataggen og data-nosnippet beskriver tre kontroller som også når tale- og AI-flater:

• nosnippet hindrer ethvert tekstutdrag fra siden. Ifølge Google gjelder dette websøk, Bilder, Discover, AI Overviews og AI Mode, og innholdet brukes ikke som direkte inndata for AI Overviews og AI Mode.
• max-snippet:[antall] begrenser utdraget til et antall tegn. Listen over berørte flater nevner også Assistant, og grensen begrenser direkte inndata for AI Overviews og AI Mode.
• data-nosnippet er et HTML-attributt for span-, div- og section-elementer som holder bestemte deler av siden utenfor utdrag.

På et WordPress-nettsted løser dette reelle tilfeller. En vilkårstabell som endres hver uke, en juridisk merknad eller et bevisst feil eksempel (“ikke gjør slik”) kan ligge i data-nosnippet, mens svaravsnittet forblir tilgjengelig. Merk rekkefølgen: har siden både nosnippet og data-nosnippet, vinner nosnippet, og det vises ikke noe utdrag. En svært lav max-snippet holder dessuten siden utenfor utvalgte utdrag.

#Hvordan Siri finner innhold på nettet

Apple publiserer ikke noe motstykke til Speakable. Det som er dokumentert, er søkeroboten. Ifølge støttesiden About Applebot brukes data fra Applebot i flere Apple-funksjoner, blant annet Siri, Spotlight og Safari. For WordPress gir det fire regler du kan kontrollere:

1. Ikke blokker Applebot ved et uhell. Applebot følger robots.txt-regler rettet mot den. Har filen ingen regler for Applebot, men regler for Googlebot, følger Applebot Googlebot-reglene. En sperre ment bare for Google kan ta nettstedet ut av Siri.
2. Crawl-delay virker ikke for Applebot. Belastning begrenses på serveren eller i CDN-et.
3. Applebot-Extended er ingen søkerobot. Den avgjør bare om innhold Applebot har hentet kan brukes til å trene Apples grunnmodeller. Sider som sperrer Applebot-Extended kan fortsatt vises i søkeresultater, og Apple sier at disse reglene ikke påvirker rangeringen.
4. Å reservere seg mot trening fjerner deg ikke fra Siri. Selv med Applebot-Extended sperret og nosnippet aktivert er innholdet ifølge Apple fortsatt synlig gjennom Spotlight, Siri og Safari.

Kontroller den robots.txt-filen som faktisk serveres i produksjon etter hver endring i en SEO-utvidelse, ikke bare innstillingssiden.

#Hvordan publisere en Alexa flash briefing fra WordPress

Amazon tilbyr en vei som ikke avhenger av rangering: Flash Briefing Skill API. Ifølge Amazons dokumentasjon leverer en flash briefing overskrifter og annet kort innhold til Alexa-kunder, som tekst eller lyd, fra en HTTPS-feed i RSS eller JSON. Innholdet kan oppdateres så ofte som hvert 15. minutt og må oppdateres minst én gang i døgnet.

Feed-referansen setter regler en WordPress-utgiver må følge:

• Tekst lest med talesyntese: feltet mainText (eller description i RSS) er teksten Alexa leser for kunden.
• Under 4500 tegn per element: lengre tekst kuttes ved nærmeste setning under grensen.
• Bare ren tekst: ingen SSML, HTML eller XML. Innleggsinnhold må gjennom wp_strip_all_tags().
• Tegnsetting styrer pausene: komma og semikolon gir korte pauser, punktum, spørsmålstegn og utropstegn lengre. Amazon fraråder ikke-standard tegnsetting.
• Ferskhet: Alexa ignorerer elementer eldre enn 7 dager, og rekkefølgen skal gå fra nyeste til eldste.
• “Read More”-lenke: redirectionUrl peker til artikkelen i Alexa-appen.

Et minimalt REST-endepunkt som bygger JSON-feeden fra nylige innlegg:

add_action('rest_api_init', function () {
    register_rest_route('briefing/v1', '/feed', [
        'methods'             => 'GET',
        'callback'            => 'wppoland_alexa_briefing_feed',
        'permission_callback' => '__return_true',
    ]);
});

function wppoland_alexa_briefing_feed() {
    $items = [];
    foreach (get_posts(['numberposts' => 5, 'date_query' => [['after' => '7 days ago']]]) as $post) {
        $items[] = [
            'uid'            => 'urn:wp:post:' . $post->ID,
            'updateDate'     => get_post_modified_time('Y-m-d\TH:i:s\Z', true, $post),
            'titleText'      => get_the_title($post),
            'mainText'       => mb_substr(wp_strip_all_tags(get_the_excerpt($post)), 0, 4400),
            'redirectionUrl' => get_permalink($post),
        ];
    }
    return rest_ensure_response($items);
}

Det manuelle utdraget for hvert innlegg blir den talte teksten, så skriv det som en Speakable-seksjon: to eller tre selvstendige setninger uten forkortelser.

#Hvilken TTFB trenger et nettsted for stemmesøk

I en talesamtale merkes stillhet raskere enn i en nettleser med lasteindikator, og en treg side forsinker også brukeren som åpner URL-en på telefonen etter svaret. Ingen taleplattform publiserer en TTFB-grense for valg av kilder. Bruk i stedet den offentlige referansen: web.dev-artikkelen om Time to First Byte sier, som en grov rettesnor, at en god TTFB er 0,8 sekunder eller mindre, og at verdier over 1,8 sekunder er dårlige. Samme artikkel påpeker at TTFB ikke er en Core Web Vitals-måling.

1. Edge-hurtigbuffer i Norden: bruk et innholdsdistribusjonsnettverk med noder nær brukerne, slik at stabil offentlig HTML besvares fra nettverkskanten. WordPress-dokumentasjonen om ytelse beskriver hurtigbuffer og object cache.
2. Object cache (Redis eller Memcached) for gjentatte spørringer; isoler WooCommerce-økter.
3. Lettvekts DOM-struktur: ren semantikk gjør det enklere for AI-søkeroboter å tolke innholdet.
4. Måling: WebPageTest eller CrUX-data for TTFB per region, sammenlignet med konkurrenter som allerede brukes som svar i din nisje.

#Hvordan optimalisere for lokalt stemmesøk i Norge

En betydelig del av stemmesøk handler om lokale behov (“hvor finner jeg WordPress-utvikler i Oslo”, “åpningstider for teknisk support i Bergen”):

• NAP-harmoni: sørg for at firmanavn, adresse og telefonnummer er identisk formatert på nettstedet, i Google Business Profile og kataloger og på Apple Maps.
• Strukturerte åpningstider: bruk LocalBusiness-skjema med presise tider for ordinære dager og norske helligdager.
• Rute- og transportdetaljer: beskriv beliggenheten i forhold til kjente kollektivknutepunkter, slik at bilassistenter kan gi veibeskrivelse, uten å finne opp avdelinger.

#Hvordan måle resultater av stemmesøk

Stemmesøk dukker nesten aldri opp som en ren kanal i analyseverktøy. Nyttige mål:

• Synlighet i svarmotorer (AEO): test jevnlig hvordan Perplexity, ChatGPT og Gemini besvarer kjernespørsmål i bransjen din, og noter om merkevaren nevnes som kilde.
• Google Search Console: utvalgte utdrag og spørsmålsformede søk i resultatrapporten.
• Forespørsler til flash briefing-feeden i serverloggene, hvis du publiserer en.
• Direktesøk etter merkevaren: koble økninger til kampanjedatoer, uten å påstå en årsak du ikke kan vise.

#Oppsummering

Direkte svar, ærlig skjema (Speakable bare der Google støtter det, FAQ og fremgangsmåter som speiler DOM-en), kontroll over utdrag og målt TTFB gjør en WordPress-installasjon klar til å bli sitert, på skjerm og i lyd. Start med noen få ankersider, kontroller selektorene, test målspørsmålene med stemmen på en ekte telefon, og rull først deretter mønsteret ut på resten av nettstedet.