Google tester et felt til den officielle side i AI-svar. Det går til siden, hvor opgaven løses

Hvad Google faktisk har annonceret

Den 15. oktober 2026 skrev Hema Budaraju, VP of Product Management i Google Search, et indlæg om fem ændringer i AI Mode og AI-oversigter. Fire af dem handler om links, der allerede findes: flere inline-links, og højere oppe i svaret; miniaturebilleder på linkene i bunden af svaret; nyhedskaruseller med brugerens Preferred Sources rulles ud til flere lande og sprog (brugen af Preferred Sources er vokset mere end 7 gange siden årets start); og klikbare navne på skabere og udgivere i videoresultater, som en test.

Den femte er ny. Google tester et særskilt felt øverst i svaret, der fremhæver den eller de to officielle sider, hvor man kan løse en bestemt opgave eller få præcis den oplysning, man leder efter. Hvert link får en note om, hvorfor det er nyttigt. Ifølge Google bygger det videre på det, søgningen allerede gør, når nogen leder efter et bestemt site.

Det er alt. Indlægget har ingen eksempler, ingen kriterier for, hvad der tæller som officielt, og ingen lande. Kun karrusellerne nævnes med geografi. Testen kan altså køre i USA i dag og aldrig komme til Danmark.

Feltet går til siden, hvor opgaven løses

De første gennemgange af ændringen fra SEO-bureauer giver det samme råd: gør jeres ydelsessider tydelige, hold Google Business-profilen opdateret, og vent. Det er ikke forkert, men det rammer den forkerte side.

Læs Googles ordvalg igen: den officielle side, hvor man løser en opgave. For en mellemstor virksomhed er det sjældent en side i CMS'et. Det er bookingflowet, kundelogin, ordrestatus, returformularen, prisberegneren, API-dokumentationen eller driftsstatus. De sider er bygget af udviklere, ligger i en anden kodebase end hjemmesiden og bliver ikke set af den, der laver SEO. Når nogen skriver "book service [jeres firmanavn]" eller "returnér ordre [jeres firmanavn]", er det dem, der er det rigtige svar.

Min vurdering er derfor, at testen først og fremmest er et spørgsmål om infrastruktur, ikke om indhold. Feltet kan kun vise en side, Google kender, må indeksere og kan forstå formålet med. Hvis jeres opgaveside ikke er det, er den næstbedste kandidat en anden: en forhandler, en bookingplatform, en tråd på et forum eller en gammel PDF.

Hvor de officielle sider typisk forsvinder

Det er de samme fejl, jeg møder, hver gang jeg overtager et system, der er vokset ved siden af hjemmesiden:

• Noindex fra lanceringen. App'en på app.firma.dk blev sat til noindex eller fik en robots.txt med Disallow: /, for at staging ikke skulle i Google. Ingen fjernede det igen.
• Opgaven bag en omdirigering. /book eller /returnering sender alle uden en session videre til /login. Google ser kun login-siden og har ingen grund til at tro, at bookingen sker her.
• En tom skal. En single-page-app med titlen "App" eller "Dashboard" og en h1, der først dukker op efter rendering. Google kan rendere JavaScript, men siden siger stadig ikke, hvad man kan gøre der, eller hvem der står bag.
• Opgaven ligger på et andet domæne. Bookingen kører hos en SaaS-leverandør på deres domæne. Så er det deres side, der er kandidaten, ikke jeres.
• Ingen links ind. Hjemmesiden linker ikke til opgavesiden, eller linket er en knap uden href. Så hænger opgavesiden ikke sammen med virksomheden.

Ingen af dem er nye problemer. De har kostet klik på klassiske søgninger på brandnavn i årevis. Det nye er, at Google nu tester et felt, der lægger sig over alle de andre resultater og vælger én eller to vindere.

Rækkefølgen for at tjekke jeres egne opgavesider

Det her er en eftermiddags arbejde for en udvikler og den, der har adgang til Search Console. Rækkefølgen er vigtig, for hvert trin bygger på det forrige.

1. List de opgaver, kunderne søger efter

Start i Search Console, ikke i et søgeordsværktøj. Filtrér forespørgsler på jeres brandnavn og kig efter verber: login, book, bestil, spor, returnér, faktura, support, status. Det er opgavesøgningerne, og de er tit flere, end marketing tror, fordi de aldrig har været en del af en kampagne.

2. Find den URL, hvor opgaven faktisk afsluttes

Ikke siden, der beskriver bookingen, men siden, hvor man booker. Skriv domænet ned. Ligger den hos en leverandør, er det en beslutning værd at tage bevidst: kan flowet køre på jeres eget subdomæne?

3. Kør URL-inspektion på hver af dem

Er siden indekseret, og hvilken kanonisk URL har Google valgt? Her dukker noindex, blokeringer i robots.txt og omdirigeringer til login op. Ret dem i den rækkefølge: en side, Google ikke må hente, hjælper ingen af de næste trin.

4. Læs den HTML, Google får uden login

Hent siden uden session og læs titel, h1 og første afsnit. Står der, hvad man kan gøre her, og hvem der står bag? "Log ind" er ikke nok. "Log ind og se dine ordrer hos [firma]" er. Det er den tekst, Google kan bruge til noten om, hvorfor linket er nyttigt.

5. Bind siden sammen med virksomheden

Link til opgavesiderne fra hjemmesidens navigation eller sidefod med rigtige <a href>-links, og brug det samme firmanavn og det samme domæne overalt. Det er det, Google har at gå efter, når det skal afgøre, om en side er jeres officielle.

Det, du ikke kan måle

Search Console vil ikke vise jer feltet. Ifølge Googles hjælpeside om Performance-rapporten tæller et klik på et eksternt link i AI Mode og i AI-oversigter som et almindeligt klik, visninger følger de normale regler, og en AI-oversigt fylder én position. Siden beskriver ikke noget filter, der skiller AI-svar ud. Og data fra Search Labs-eksperimenter er helt udeladt. Hvis testen kører som et Labs-eksperiment, når den kommer til Danmark, kommer den slet ikke med i tallene.

Det bedste, I kan gøre, er at følge klik og visninger på opgavesøgningerne fra trin 1 til de URL'er, I fandt i trin 2, før og efter jeres rettelser. Det er støjende data og ikke bevis for feltet. Men det fortæller jer, om opgavesiderne vinder deres egne søgninger, og det er det, der betyder noget, uanset om testen bliver til noget. Betal ikke for nogen, der lover jer en plads i feltet. Google har ikke offentliggjort, hvad der giver adgang.