Illustration af en delt side i et browservindue, hvor en låge stopper søgemaskinens lup, mens linket stadig åbner siden

Kort fortalt

Google opdaterede 26. oktober 2026 sin guide mod brugergenereret spam med et nyt afsnit: sider lavet til deling, samarbejde eller værktøjsbrug skal som standard holdes ude af indekset med noindex (meta-tag eller X-Robots-Tag) eller en blokering i robots.txt. Guiden sidestiller de to, men Googles egen noindex-dokumentation siger, at noindex ikke virker på en side, der er blokeret i robots.txt, og at en blokeret side stadig kan vises i søgeresultater, hvis andre sider linker til den. Guiden giver ingen tærskler, nævner ingen sanktioner og siger intet om, hvordan en delt side senere gøres offentlig. Den kom to uger efter, at september-spam-updaten sluttede 8. oktober.

Hvis din software laver delelinks — tilbud, rapporter, dashboards, AI-genererede svar — skal de svare med X-Robots-Tag: noindex og være tilladt i robots.txt, ikke blokeret. Et delelink ender før eller siden et offentligt sted, og en URL, Google ikke må hente, kan stadig blive indekseret, uden at Google nogensinde ser dit noindex.

Hvad Google tilføjede 26. oktober

Googles changelog for Search-dokumentationen har en linje for 26. oktober 2026: guiden om brugergenereret spam er udvidet med råd om at blokere indeksering af link-delt indhold og om at overvåge misbrug i Search Console. Begrundelsen er at hjælpe platforme med at holde brugerskabte sider, der ikke er ment til Search, ude af indekset og opdage spam tidligere.

Selve guiden er ikke længere kun for kommentarfelter og fora. Den nævner nu tjenester, der lader brugere lave delte sider, genereret indhold eller web-apps. Det nye afsnit stiller ét spørgsmål: skal indholdet findes via søgemaskiner, eller kun åbnes af folk med linket? Er siden lavet til deling, samarbejde eller værktøjsbrug, anbefaler Google som standard en noindex-regel via robots-meta-tag eller X-Robots-Tag-header — eller en blokering af crawling i robots.txt.

Timingen er ikke tilfældig. Septembers spam-update startede 24. september og sluttede 8. oktober, den fjerde spam-update i 2026 ifølge PPC Lands gennemgang. Og 7. oktober skrev DuckDuckGo ved lanceringen af delte chats i Duck.ai, at delte samtaler fra ChatGPT og Claude var dukket op i søgeresultater, nogle gange med brugernes navne.

Robots.txt og noindex er ikke to udgaver af det samme

Guiden stiller de to løsninger op som ligeværdige og siger ikke, hvilken man skal vælge. Googles egen side om at blokere indeksering med noindex siger to ting, der afgør det. Noindex virker kun, hvis siden ikke er blokeret i robots.txt, for ellers ser Googlebot aldrig reglen. Og en side, crawleren ikke må hente, kan stadig optræde i søgeresultater, hvis andre sider linker til den.

Det sidste er hele problemet med delelinks. Et delelink er per definition noget, der bliver sendt videre. Det ender i en mail, der bliver videresendt, i en Slack-kanal med gæster, i et forum, hvor nogen beder om hjælp, eller i et offentligt Notion-dokument. Fra det øjeblik kender Google URL'en. Er den blokeret i robots.txt, kan URL'en blive indekseret uden indhold, og den noindex-header, du har sat på siden, bliver aldrig læst.

To veje for et delelink, der ender et offentligt sted Til venstre er delelinket blokeret i robots.txt: Googlebot må ikke hente siden, noindex bliver aldrig læst, og URL'en kan indekseres uden indhold. Til højre er siden tilladt i robots.txt og svarer med X-Robots-Tag noindex: Googlebot henter siden, læser noindex og holder den ude af indekset. Blokeret i robots.txt Tilladt + X-Robots-Tag: noindex Linket deles et offentligt sted Googlebot må ikke hente siden Noindex bliver aldrig læst URL'en kan indekseres uden indhold, via links udefra Linket deles et offentligt sted Googlebot henter siden Svaret siger noindex Siden holdes ude af indekset linket virker stadig for modtageren Kilde: Google Search Central, "Block Search indexing with noindex" og "Prevent user-generated spam" (opdateret 26.10.2026)

Duck.ai er et godt eksempel på den grundige version: ifølge DuckDuckGo sender hver delt chatside noindex både i selve siden og i serverens svar, linkene er lange og tilfældige, og de udløber efter 48 timer som standard. Ingen af delene er robots.txt.

Det er let at læse opdateringen som noget for ChatGPT, Claude og app-byggere som Lovable. Men i de systemer, jeg bygger og driver for mid-market-virksomheder, findes de samme sider overalt, de hedder bare noget andet:

  • Tilbuds- og ordrebekræftelsessider, som sælgeren sender til kunden.
  • Rapporter og dashboards fra en kundeportal, delt med "alle med linket".
  • AI-genererede output — et udkast, en opsummering, en analyse — med en del-knap.
  • PDF'er som fakturaer og kontrakter bag en token-URL. Her kan du ikke sætte et meta-tag, så det skal være headeren; Google nævner selv X-Robots-Tag til netop ikke-HTML-filer.
  • Gamle staging- og preview-links, der aldrig blev slået fra.

Fælles for dem er, at ingen har taget stilling til, om de må indekseres. De arver det, rammeværket gør som standard, og det er som regel ingenting.

Rækkefølgen, når du bygger det ind

Strukturen er den samme, uanset om stakken er Laravel, Next.js eller noget tredje:

  1. Klassificér ruterne. Lav en liste over alle URL-mønstre, der svarer uden login. Hver rute får én af to etiketter: søgning eller link. Alt, der ikke er eksplicit søgning, er link.
  2. Sæt reglen i svarlaget, ikke i skabelonen. En header sat i middleware eller på reverse proxy'en rammer også PDF'er, JSON-svar og de sider, en udvikler bygger om et år uden at kende reglen. Et meta-tag i én skabelon gør ikke.
  3. Lad link-ruterne være tilladt i robots.txt, og hold dem ude af sitemap.xml. Google skal kunne hente siden for at læse noindex.
  4. Gør offentlig til et aktivt valg. Hvis brugere skal kunne udgive noget til søgning, er det en separat handling med sin egen URL, ikke en ændret header på delelinket. Guiden selv siger intet om, hvordan en delt side senere gøres offentlig.
  5. Giv links en udløbsdato. En token, der er død, kan ikke blive indekseret med indhold, uanset hvor den er havnet.
  6. Mål det. Verificér domænet eller subdomænet i Search Console og hold øje med uventede spring i Page Indexing-rapporten og i visninger på søgninger, der ikke passer til produktet — det er de to rapporter, Google selv peger på. Læg en alarm på antallet af nye indekserbare URL'er pr. dag i jeres egne data.

Hvis du allerede har blokeret i robots.txt

Så er rækkefølgen omvendt af, hvad mange gør. Fjern først blokeringen for delelink-mønsteret, så Googlebot kan hente siderne og se noindex. Lad den også være væk bagefter: genindfører du blokeringen, kan nye links udefra få de samme URL'er indekseret igen, nu uden at Google kan se noindex. Står der URL'er med statussen "Indexed, though blocked by robots.txt" i Page Indexing-rapporten, er det præcis denne situation. Fjernelsesværktøjet i Search Console skjuler kun midlertidigt; det erstatter ikke noindex.

Hvad guiden ikke siger

Tre huller er værd at kende, før man læser for meget ind i opdateringen. Der er ingen tærskler for, hvornår et spring i indekserede sider er unormalt. Der står intet om sanktioner over for platforme, der lader delte sider være indekserbare. Og der er ingen kobling til en navngiven spam-politik. Marie Haynes og Lily Ray har spekuleret i, om AI-værktøjer og app-platforme er målet, men Google har ikke bekræftet noget. Det, der er dokumenteret, er rådet og Googles egne regler for, hvordan noindex og robots.txt virker. Det er nok til at handle på.

Standarden er det, der bliver indekseret

Google rammer det ind som spam-forebyggelse, men for de fleste virksomhedssystemer er delelinks et spørgsmål om, hvad kunderne tror er privat. Ingen beslutter aktivt, at et tilbud skal kunne findes på Google. Det sker, fordi ingen besluttede det modsatte.

Sæt reglen én gang i svarlaget, lad crawleren læse den, og gør det offentlige til noget, nogen aktivt vælger. Så er Googles nye afsnit allerede opfyldt, og robots.txt kan gå tilbage til at styre crawl i stedet for at lade som om, den styrer indeks.