Google Search URL-parametrar: Vad som fortfarande fungerar 2026

Någon gång runt september 2025 började flera SEO-verktyg och egna skript tyst gå sönder. Orsaken? Google slutade pålitligt följa parametern num=100, som avancerade användare hade lutat sig mot i åratal för att hämta 100 resultat per sida. Det kom inget formellt avvecklingsmeddelande — bara en uttalande till Search Engine Land där en talesperson sa att parametern "inte formellt stöds". Ungefär samtidigt introducerade Google fler udm-lägen vid sidan av äldre tbm-vertikaler, meddelade att landsdomäner successivt skulle börja omdirigeras till google.com, och rapporterade att AI Overviews nådde över 2,5 miljarder användare per månad.

Om du har byggt sök-URL:er, följt rankingar eller automatiserat research med Googles URL-parametrar finns det stor risk att vissa av dina flöden just nu fungerar sämre utan att du märker det. På Thunderbit gick vi igenom aktuell Google-dokumentation, nya förändringsmeddelanden, omvändt härledda referenser och livekontroller för att skilja stabila reglage från kontextberoende sådana. Resultatet är en tidsatt referens du bör testköra innan du använder den, för de Google Search URL-parametrar som spelar roll 2026 — inklusive tbm/udm-mappningar, uule-kodning för geografisk inriktning på stadsnivå och parameterkonflikter som kan spara timmar av felsökning.

Vad är Google Search URL-parametrar?

Google Search URL-parametrar är nyckel-värde-par som kommer efter ? i en Google-sök-URL. De styr allt från vad du söker efter, till vilket lands resultat du ser, till om du får bilder, nyheter eller de klassiska blå länkarna.

En typisk Google-sök-URL kan delas upp så här:

https://www.google.com/search?q=best+crm+software&hl=en&gl=us&tbs=qdr:m

• Bas-URL: https://www.google.com/search
• ? startar frågesträngen
• q=best+crm+software är sökfrågan (mellanslag kodas som +)
• & skiljer varje parameter åt
• hl=en sätter gränssnittsspråket till engelska
• gl=us säger åt Google att visa resultat som om du befann dig i USA
• tbs=qdr:m filtrerar fram resultat från den senaste månaden

En viktig skillnad: sökoperators som site:, filetype: och intitle: skrivs inuti värdet för q=. De är en del av din sökfråga. URL-parametrar som gl, hl och tbs är separata nycklar i URL:en som styr hur Google bearbetar och visar resultaten. Båda är viktiga och de samverkar — men de är inte samma sak.

Google har aldrig publicerat en enda versionerad specifikation för dessa parametrar. Vissa kommer från Advanced Search-formuläret, vissa från Custom Search API och vissa är omvändt härledda genom att observera Googles egna URL:er. Det betyder att artikeln du läser bygger på live-testning och dokumenterat beteende, inte på ett officiellt API-avtal.

Varför Google Search URL-parametrar är viktiga 2026

URL-parametrar är inte bara en utvecklarfråga. Alla inom SEO, marknadsföring, försäljning, drift eller produkt som behöver förstå vad Google visar för en viss sökfråga, på en viss marknad, vid en viss tidpunkt — för dem är dessa parametrar ett verktygslådeset.

Här är en snabb genomgång av vem som gynnas och hur:

Användningsfall	Vem gynnas	Viktiga parametrar
Rank tracking för SEO i flera länder	SEO- och marknadsteam	gl, hl, uule, pws
Konkurrentbevakning per datum	Strategi- och driftsteam	tbs, q med site:
Annonsbevakning i specifika marknader	Betalda medieteam	gl, hl, udm
Lokala SEO-revisioner (på stadsnivå)	Lokala företagare	uule, gl
Innehållsresearch / trendbevakning	Content-team	tbs (datumfilter), lr
Mata sökdata in i AI-/LLM-appar	Produkt- och datateam	Flera parametrar + strukturerad extraktion

Tre stora förändringar gör 2026 tydligt annorlunda:

1. num=100 går inte längre att lita på. Det gamla knepet för fler resultat per sida slutade fungera tillförlitligt i september 2025. Google avvecklade det inte formellt; en talesperson sa bara att det aldrig hade varit formellt stödjt.
2. Omdirigeringar från ccTLD är en migration, inte ett färdigt skifte. Google meddelade i april 2025 att landsdomäner (google.co.uk, google.de osv.) gradvis skulle omdirigeras till google.com. Google har inte publicerat något besked om att migreringen är helt klar, så anta inte att alla lokala varianter beter sig identiskt ännu.
3. AI Overviews förändrade SERP:en. Google rapporterar att AI Overviews nått över 2,5 miljarder användare per månad och 200+ länder och territorier. Omvändt härledda udm-lägen kan ändra resultatsidan i vissa sammanhang, men de är inte en garanterad strömbrytare för AI Overviews.

Om dina flöden inte uppdaterats för de här förändringarna får du sannolikt försämrade eller missvisande resultat utan att inse det.

Snabbguide till Google Search URL-parametrar (2026)

Innan vi går djupare: tabellen nedan är den mest aktuella översikten jag kunnat sätta ihop. Spara den gärna.

Parameter	Vad den gör	Exempelvärde	Status
q	Sökfråga (stödjer operators inuti)	q=best+crm+software	✅ Aktiv
hl	Gränssnittsspråk	hl=en, hl=ja	✅ Aktiv
gl	Lands-/marknadskontext	gl=us, gl=jp	✅ Aktiv
lr	Begränsar resultat till ett innehållsspråk	lr=lang_en	✅ Aktiv
cr	Begränsar resultat till ett värdland	cr=countryUS	✅ Aktiv
start	Sidnumreringens offset	start=10 (sida 2)	✅ Aktiv
num	Antal resultat per sida (tidigare)	num=100	⚠️ Inte formellt stödjt; opålitligt sedan sept 2025
udm	Kontextuellt innehållsläge	udm=14 (klassisk web)	⚠️ Omvändt härledd; varierar beroende på kontext
tbm	Sökspecifik vertikal	tbm=isch (bilder)	⚠️ Observeras fortfarande; testa tillsammans med udm
tbs	Tidsfilter, sortering, verbatim	tbs=qdr:w	✅ Aktiv
safe	SafeSearch-kontroll	safe=active	✅ Aktiv
filter	Filtrering av dubbletter	filter=0	✅ Aktiv (observerad)
nfpr	Stänger av automatisk korrigering	nfpr=1	✅ Aktiv (observerad)
pws	Stänger av personalisering	pws=0	✅ Aktiv
uule	Geoinriktning på stad-/DMA-nivå	uule=w+CAIQICI...	✅ Aktiv (omvändt härledd)
as_q, as_epq, as_eq, etc.	Fält i Advanced Search-formuläret	Varierar	✅ Aktiv
as_sitesearch	Begränsar till en domän (Advanced Search)	as_sitesearch=example.com	✅ Aktiv
as_filetype	Begränsar till filtyp (Advanced Search)	as_filetype=pdf	✅ Aktiv
ie, oe	In-/utkodning	ie=UTF-8	✅ Aktiv (sällan behövd)
kgmid, si, ibp	Knowledge Graph-entitet / vy-funktion	Varierar	⚠️ Kontextuellt (inte för allmän användning)
ei, ved, sxsrf, sclient	Session/spårning/telemetri	Varierar	🔒 Internt (ignorera)
gbv	Enkel HTML-vy (tidigare)	gbv=1	❌ Opålitlig 2026

Ta bort ei, ved, sxsrf och sclient från alla URL:er du sparar eller delar. De är sessions- och telemetristatus som Google lägger till automatiskt — irrelevanta för att bygga sök-URL:er.

Centrala Google Search URL-parametrar som fortfarande fungerar

Jag har testat varje parameter live i mitten av 2026. Det här är de du oftast kommer att använda.

q — Din sökfråga

Parametern q innehåller dina söktermer. Mellanslag kodas som + eller %20. Det är här Googles dokumenterade sökoperators hör hemma — de ska in i q-värdet, inte som egna URL-parametrar.

Några exempel:

• Exakt fras: q=%22google+search+url+parameters%22
• Begränsad till webbplats: q=site%3Aexample.com+pricing
• Filtyp: q=filetype%3Apdf+annual+report+2026
• Kombinerad: q=site%3Acompetitor.com+intitle%3Apricing+after%3A2026%2F01%2F01

URL-koda alltid hela sökfrågan. Citationstecken, kolon och snedstreck måste kodas korrekt för att inte förstöra URL:en.

hl — Gränssnittsspråk

hl styr språket i Googles gränssnitt (knappar, etiketter, rubrikerna för "People also ask") och påverkar vilka resultat Google prioriterar. Den använder ISO 639-1-koder som en, fr, de, ja eller BCP 47-taggar som en-gb eller pt-br.

hl tvingar inte alla resultatsidor att vara på det språket. Det är en stark signal, men Google kan ändå visa resultat på andra språk om de är mycket relevanta. För att begränsa innehållsspråket använder du lr i stället.

gl — Land / geolokalisering

gl simulerar vilket land du söker från, med ISO 3166-1 alpha-2-koder (us, gb, jp, de). Med ccTLD:er som gradvis omdirigeras till google.com är gl nu det främsta sättet att få landspecifika resultat.

Samma sökfråga med olika gl-värden kan ge helt olika resultat, featured snippets och lokala paket. Till exempel kommer q=best+bank&gl=us och q=best+bank&gl=jp att visa mycket olika banker.

Proffstips: para alltid ihop gl med hl för korrekta lokaliserade resultat. gl=jp tillsammans med hl=en ger resultat för den japanska marknaden i ett engelskt gränssnitt — användbart för internationella SEO-revisioner.

lr och cr — Språkbegränsning och landsbegränsning

De här två blandas ihop hela tiden. Skillnaden spelar roll:

• lr=lang_en begränsar resultaten till sidor skrivna på engelska (innehållsspråk)
• cr=countryUS begränsar resultaten till sidor som är hostade i USA (serverplats / landskoppling)
• gl=us simulerar att du söker från USA (påverkar ranking, lokala resultat, annonser)

Både lr och cr finns i Googles Advanced Search-formulär. Var försiktig när du kombinerar dem — lr=lang_en + cr=countryJP betyder "endast engelskspråkiga sidor hostade i Japan", vilket är en mycket snäv mängd. Mer om detta i avsnittet om konflikter.

start — Sidnumrering

start=10 begär resultat från position 11 och framåt (sida 2), start=20 för sida 3 och så vidare. Eftersom num=100 inte längre är pålitligt är det säkrare att öka start med 10 — men Google kan fortfarande skriva om eller begränsa sidnumreringen.

Det gamla knepet num=100&start=0 för att hämta en hel sida med 100 resultat fungerar inte längre. Om dina skript fortfarande innehåller num, ta bort det — det ignoreras tyst.

pws — Stäng av personalisering

pws=0 ber Google att stänga av kontobaserad personalisering. Det här är avgörande för rank tracking inom SEO, där du vill ha resultat som inte snedvrids av din sökhistorik, klickade resultat eller kontoinställningar.

En viktig brasklapp: pws=0 minskar personaliseringen men tar inte bort alla kontextuella faktorer. Google säger att resultat fortfarande kan variera beroende på tid, plats, språk och enhet. Det finns ingen helt "neutral" Google-SERP.

safe och filter — SafeSearch och filtrering av dubbletter

• safe=active aktiverar SafeSearch; safe=off stänger av det. Observera att kontoinställningar, administrationspolicyer, nätverkskonfigurationer eller regional lagstiftning kan åsidosätta parametern.
• filter=0 stänger av Googles filtrering av dubbletter. Användbart när du vill se varje resultat Google har, inklusive nästan-dubbletter som normalt skulle slås ihop.

nfpr — Stäng av automatisk korrigering

nfpr=1 förhindrar att Google med tvång skriver om din sökfråga när det tror att du stavat fel. Det här är användbart för att följa varumärkesord med ovanlig stavning, teknisk jargong eller avsiktligt felstavade sökningar som konkurrenter riktar in sig på.

Observera att nfpr=1 bara stoppar den tvingade omskrivningen. För bredare kontroll — att stänga av synonymutvidgning, stavningsändringar och andra automatiska modifieringar — använd tbs=li:1 (verbatim-läge), som jag tar upp längre ned i avsnittet om tbs.

tbm till udm: vad som ändrats och vad du bör använda nu

Det här är en av de största parameterförändringarna på senare år — och en av de enklaste att överdriva.

tbm har i över ett decennium varit ett vanligt sätt att växla mellan Googles sökvertikaler — bilder, nyheter, video, shopping. Google har också infört ett numeriskt udm-system med överlappande och ytterligare lägen. Eftersom Google inte har publicerat ett stabilt konsumentregister bör detta betraktas som en kontextuell mappning, inte som en ren, färdig ersättning.

Fullständig mappning från tbm till udm

Mappningen nedan kombinerar observerat gränssnitts-beteende och livekontroller daterade 12 augusti 2026. Flera värden ströks eller skrevs om i anonyma förfrågningar, så varje rad bör testas i det konto, den region och den klient där den ska användas:

Gammal parameter	Gammalt värde	Ny parameter	Nytt värde	Status
tbm=lcl	Platser / lokalt	udm=1	Platser / lokalt	⚠️ Kontextuellt
tbm=isch	Bilder	udm=2	Bilder	⚠️ Kontextuellt
tbm=vid	Videor	udm=7	Videor	⚠️ Kontextuellt
tbm=nws	Nyheter	udm=12	Nyheter	⚠️ Kontextuellt
—	—	udm=14	Klassisk web (utan AI Overviews)	🆕 Nytt, ingen tbm-motsvarighet
—	—	udm=18	Forum	🆕 Nytt, ingen tbm-motsvarighet
tbm=shop	Shopping	udm=28	Shopping	⚠️ Kontextuellt
tbm=bks	Böcker	udm=36	Böcker	⚠️ Kontextuellt
—	—	udm=39	Korta videor	🆕 Nytt, ingen tbm-motsvarighet
—	—	udm=50	AI Overview-läge	🆕 Nytt, ingen tbm-motsvarighet

Google har inte publicerat ett stabilt udm-register — det är en viktig reservation. Dessa värden är omvändt härledda utifrån Googles egna UI-beteenden. Godkännandet av URL:er varierar beroende på konto, region, klient, cookies och experimentgrupp. I mina tester ströks vissa udm-värden i anonyma HTTP-förfrågningar men fungerade fint i interaktiva webbläsarsessioner. Utgå inte från att varje värde fungerar överallt.

Vad udm=14 gör (och varför SEO:are gillar det)

udm=14 har blivit något av en favorit i SEO-kretsar. Android Central beskrev det som ett sätt att be om en klassisk resultatsida utan AI Overviews. I många sessioner ger det en traditionell SERP med blå länkar, men det är inte en officiell eller universell garanti.

Varför spelar det roll? Om du gör rank tracking eller SEO-revisioner kan AI Overviews trycka ned organiska resultat under folden och göra det svårare att bedöma placeringar. udm=14 kan ge en renare vy när Google faktiskt respekterar det.

Med det sagt är udm=14 inte garanterat att fungera i varje sammanhang. Vid livekontroller den 12 augusti 2026 tog Google ibland bort eller skrev om udm-värden beroende på förfrågans kontext. Resultatet kan därför variera med session, konto, region, klient och experimentgrupp.

udm=50 har observerats i AI Mode-/AI-resultatkontexter, men det bör inte beskrivas som ett garanterat sätt att tvinga fram en AI Overview för en godtycklig sökfråga.

Vad du bör göra: uppdatera dina flöden från tbm till udm

Min rekommendation:

• Nya implementationer: Behandla udm som en experimentell/kontextuell signal och bygg in reservlösningar.
• Befintliga flöden: Stöd och testa både tbm och udm där det är relevant, i stället för att anta att migreringen är helt färdig.
• Kombinera aldrig båda: När både tbm och udm finns i samma URL blir beteendet oförutsägbart. I mina tester tog Google ibland bort båda och returnerade en vanlig sökfråga. Mer om detta i avsnittet om konflikter.

Fullständig tbs-syntax: egna datumintervall, sortering efter datum och verbatim

tbs är en av de mest kraftfulla parametrarna i Google Search-verktygslådan, och de flesta guider snuddar bara vid ytan. Den hanterar tidsfiltrering, datumsortering, verbatim-läge och mer — allt paketerat i ett enda kommaseparerat värde.

Standardiserade tidsfilter

tbs-värde	Betydelse	Exempel på URL-del
qdr:h	Senaste timmen	&tbs=qdr:h
qdr:d	Senaste 24 timmarna	&tbs=qdr:d
qdr:w	Senaste veckan	&tbs=qdr:w
qdr:m	Senaste månaden	&tbs=qdr:m
qdr:y	Senaste året	&tbs=qdr:y

Det här är grunderna som de flesta guider täcker. Men tbs kan göra mycket mer.

Egna datumintervall

Behöver du resultat från ett specifikt tidsfönster? Använd syntaxen cdr:1,cd_min:MM/DD/YYYY,cd_max:MM/DD/YYYY:

&tbs=cdr:1,cd_min:01/01/2026,cd_max:06/01/2026

Det här filtrerar fram resultat som Google kopplar till datum mellan 1 januari och 1 juni 2026. Det är ovärderligt för konkurrensanalys — till exempel: "Vad publicerade konkurrenterna om prissättning under Q1 2026?" Glöm bara inte att URL-koda hela värdet, eftersom kolon och snedstreck måste kodas.

En praktisk notis: Googles datumkoppling är inte alltid korrekt. Datumet som visas i sökresultaten är Googles bästa gissning, inte nödvändigtvis det faktiska publiceringsdatumet. Verifiera alltid datum på målsidan.

Sortera efter datum och verbatim-läge

Här går guiden in på sådant som ingen konkurrerande artikel riktigt täcker.

sbd:1 sorterar resultaten efter datum (nyast först). Det i sig är användbart men inte särskilt ovanligt. Tricket är att du kan kombinera det med tidsintervallfilter i ett enda tbs-värde:

&tbs=qdr:m,sbd:1

Det här ger resultat från den senaste månaden, sorterade efter datum — nyast först. Det är det snabbaste sättet att hitta vad som precis publicerats om ett ämne. Jag använder den kombinationen konstant när jag bevakar konkurrenters innehåll.

li:1 aktiverar verbatim-läge — motsvarigheten i URL-form till att klicka på Googles verktyg "Verbatim" i sökgränssnittet. Verbatim-läget stänger av automatisk korrigering, synonymexpansion, stavningsändringar och andra automatiska modifieringar av sökfrågan.

Skillnaden mellan li:1 och nfpr=1 handlar om omfattning:

• nfpr=1: Stoppar bara tvingad stavnings-/frågeomskrivning (t.ex. hindrar Google från att ändra "teh" till "the")
• tbs=li:1: Stänger av alla automatiska modifieringar — stavning, synonymer, relaterade termer och personaliseringsjusteringar

Du kan till och med stapla flera tbs-värden. Till exempel ger tbs=qdr:m,sbd:1,li:1 resultat från den senaste månaden, sorterade efter datum, med verbatim-matchning. I mina tester fungerar den kombinationen, men jag rekommenderar att du verifierar den med just dina sökfrågor eftersom tbs är en odokumenterad syntax.

Så bygger du en uule-kod för geoinriktning på stadsnivå

Om gl är ett landbaserat zoomobjektiv är uule ett mikroskop för stadsnivå. För lokal SEO — när du vill se hur ditt företag rankar i Denver jämfört med Dallas, eller vad en sökare i Tokyos stadsdel Shibuya ser — räcker gl inte till.

Ingen artikel i toppresultaten förklarar faktiskt hur man konstruerar en uule-kod — de nämner att parametern finns och går sedan vidare. Här kommer hela genomgången.

När ska du använda gl vs. uule vs. cr?

Parameter	Nivå av detaljer	Typiskt användningsfall	Kräver kodning?
gl=us	Landsnivå	Snabb simulering av ett land	Nej
cr=countryUS	Landsnivå (restriktion)	Filtrera efter värdland	Nej
uule=w+CAIQICI...	Stads-/DMA-nivå	Kontroll av lokal SEO-rankning	Ja

uule-kodningens algoritm (steg för steg)

Parametern uule använder en kodad signal för namngiven plats. Konstruktionen är omvändt härledd, inte officiellt dokumenterad av Google, men har validerats brett inom SEO-communityn.

Det säkrare sättet är att koda en liten Protocol Buffers-payload i stället för att förlita sig på den ofta kopierade genvägen (som kan fallera med tecken utanför ASCII). Så här gör du:

1. Hämta det kanoniska Google-platsnamnet. Google publicerar geografiska mål med kanoniska namn via Google Ads API:s geografiska inriktningsdata. Exempel: New York,New York,United States
2. Koda namnet som UTF-8-bytes.
3. Bygg en liten protobuf-payload med namnet och dess byte-längd.
4. Base64url-koda payloaden och lägg till prefixet w+.

Här är ett Python-exempel som gör detta:

import base64

def encode_varint(value: int) -> bytes:
    out = bytearray()
    while True:
        byte = value & 0x7F
        value >>= 7
        if value:
            out.append(byte | 0x80)
        else:
            out.append(byte)
            return bytes(out)

def build_uule(canonical_name: str) -> str:
    name = canonical_name.encode("utf-8")
    payload = b"\x08\x02\x10\x20\x12" + encode_varint(len(name)) + name
    encoded = base64.urlsafe_b64encode(payload).decode().rstrip("=")
    return "w+" + encoded

# Exempel
print(build_uule("New York,New York,United States"))
# Output: w+CAIQICIeTmV3IFlvcmssTmV3IFlvcmssVW5pdGVkIFN0YXRlcw

När du använder detta i en URL, se till att det bokstavliga + i w+ kodas korrekt som %2B av ditt URL-bibliotek. De flesta URLSearchParams- eller urllib.parse.urlencode-implementationer hanterar detta automatiskt.

En korrekt byggd uule är fortfarande bara en av flera plats-signaler. Den åsidosätter inte IP-adress, kontoinställningar, enhet eller experimentgrupp. Använd den som en riktad kontroll för lokal SEO — inte som garanti för exakta rankningar på stadsnivå.

När Google Search URL-parametrar tyst krockar

Kombinationer av parametrar kan misslyckas tyst: Google kan ignorera en inmatning, skriva om URL:en eller visa en annan resultatyta. Konfliktkontrollerna nedan är värda att lägga in i varje arbetsflöde som bygger söklänkar.

Ingen konkurrerande artikel täcker hur parametrar samverkar. Men om du bygger sök-URL:er med flera parametrar — och det gör du sannolikt — behöver du veta vilka kombinationer som fungerar bra och vilka som motarbetar varandra.

gl + uule: vilken vinner?

När båda finns med ger uule en mer specifik platsignal än gl. Om du sätter gl=uk och en uule som pekar mot Tokyo får du resultat som påverkas av Tokyo, inte brittiska resultat.

Rekommendation: Om du använder uule, utelämna antingen gl helt eller sätt gl till det land som innehåller din uule-stad. Skicka inte motstridiga signaler.

tbm + udm: använd inte båda

I mina tester händer det att Google ibland tar bort både tbm och udm när båda finns i samma URL och istället returnerar en vanlig webbsökning. Beteendet är inkonsekvent mellan sessioner och konton.

Rekommendation: Använd bara udm i nya implementationer. Om du måste stödja äldre flöden, välj det ena eller det andra — aldrig båda.

lr + cr: dubbel filtrering kan ge noll resultat

Det här är en subtil fälla. lr=lang_en begränsar till engelskspråkigt innehåll. cr=countryJP begränsar till sidor hostade i Japan. Kombinera dem och du ber om "engelskspråkiga sidor hostade i Japan" — vilket är en mycket liten del av webben.

Rekommendation: Använd bara det ena om du inte specifikt behöver snittmängden. Om du kombinerar dem, räkna med betydligt färre resultat.

num + start: trasig sidnumrering

Gamla skript som använder num=100&start=0 returnerar nu tyst bara cirka 10 resultat. Parametern num respekteras inte längre, men den ger inget fel — den ignoreras bara.

Rekommendation: Ta bort num från alla URL:er. Paginera med start i steg om 10 och deduplicera resultaten mellan sidorna.

Snabbreferens för konflikter

Kombination	Vad som händer	Rekommendation
gl + uule	uule ger starkare och mer specifik signal	Matcha land och stad, eller utelämna gl
tbm + udm	Oförutsägbart — båda kan tas bort	Använd bara udm
lr + cr	Mycket snäv filtrering, ofta nästan inga resultat	Använd det ena eller det andra
num + start	num ignoreras, bara ~10 resultat returneras	Ta bort num, paginera med start
nfpr=1 + tbs=li:1	Relaterade men inte identiska kontroller	Testa din specifika sökfråga
hl + lr	Gränssnittsspråk ≠ begränsning av innehållsspråk	Använd medvetet; hl är inte ett innehållsfilter

Från Google Search URL-parametrar till strukturerad dataextraktion

Vid det här laget har du en exakt Google-sök-URL — rätt fråga, rätt land, rätt datumintervall, klassiska webresultat. Nästa steg är att få ut strukturerad data ur resultaten.

Oavsett om du bygger en rank tracker, bevakar konkurrenter eller matar sökdata in i ett researchflöde räcker det bara halvvägs att se rätt resultat. Du behöver titlar, URL:er, snippets, positioner och datum i ett kalkylblad eller en databas.

Bygga en riktad Google-sök-URL (allt-i-ett)

Här är ett komplett exempel med flera parametrar kombinerade:

https://www.google.com/search?q=site%3Acompetitor.com+intitle%3Apricing&hl=en&gl=us&tbs=qdr:m,sbd:1&udm=14&pws=0

Så här bryts det ned:

• q=site%3Acompetitor.com+intitle%3Apricing — sidor på competitor.com med "pricing" i titeln
• hl=en — engelskt gränssnitt
• gl=us — kontext för den amerikanska marknaden
• tbs=qdr:m,sbd:1 — senaste månaden, sorterat efter datum
• udm=14 — klassiska webresultat (utan AI Overviews)
• pws=0 — personalisering avstängd

Du kan bygga detta programmatiskt med curl:

curl -L -G 'https://www.google.com/search' \
  --data-urlencode 'q=site:competitor.com intitle:pricing' \
  --data-urlencode 'hl=en' \
  --data-urlencode 'gl=us' \
  --data-urlencode 'tbs=qdr:m,sbd:1' \
  --data-urlencode 'udm=14' \
  --data-urlencode 'pws=0' \
  -H 'User-Agent: Mozilla/5.0'

Eller med Python:

import requests

params = {
    "q": "site:competitor.com intitle:pricing",
    "hl": "en",
    "gl": "us",
    "tbs": "qdr:m,sbd:1",
    "udm": "14",
    "pws": "0",
}

response = requests.get(
    "https://www.google.com/search",
    params=params,
    headers={"User-Agent": "Mozilla/5.0"},
    timeout=20,
)
print(response.url)

Anonyma HTTP-förfrågningar till Google ger ofta JavaScript-skal utan serverrenderade resultat, eller varningar om ovanlig trafik — vilket är precis där webbläsarbaserad extraktion har sin styrka.

Extrahera SERP-data utan att skriva en parser

Att tolka Googles HTML är bräckligt arbete. DOM-strukturen ändras ofta, klassnamnen är fördunklade och det du ser i webbläsaren är inte alltid det du får i ett rått HTTP-svar.

Ett enklare angreppssätt för icke-utvecklare: öppna din noggrant byggda sök-URL i Chrome och använd ett webbläsarbaserat extraktionsverktyg för att hämta strukturerad data från den synliga sidan. På Thunderbit byggde vi vår Chrome-tillägg för just den här typen av flöde — du kan använda AI Suggest Fields för att identifiera kolumner som resultatets titel, mål-URL, snippet-text och synlig position, och sedan extrahera dem till ett kalkylblad utan att skriva en parser.

Det här är inte enda vägen. Kodbaserade metoder fungerar också, särskilt om du behöver hantera storskalig eller upprepad extraktion. Men för ad hoc-research, revisioner och enstaka konkurrensanalyser slipper du helt bräcklig HTML-parsing med webbläsarbaserad extraktion.

När du i stället bör använda ett officiellt API

Här kommer en viktig ansvarsnotis — och den spelar roll.

Googles användarvillkor förbjuder automatiserad åtkomst som kringgår skyddsåtgärder, och Google Search Help klassar uttryckligen sök-scrapers och programvara som skickar automatiska förfrågningar för att fastställa ranking som automatiserad trafik. Att köra en Google-scraper i produktionsskala innebär risk för IP-blockeringar, CAPTCHA och potentiella juridiska problem.

För behov av sökdata i produktionsskala och hög volym är den bättre vägen ett officiellt API. Googles Custom Search JSON API stängs för nya kunder — befintliga användare har fram till 1 januari 2027 att migrera, med 100 gratisfrågor per dag och $5 per 1 000 frågor därefter. Google rekommenderar Vertex AI Search för kontrollerad sökning på egna webbplatser framöver.

För webbplatser du själv äger är Search Console Search Analytics API förstahandskällan för klick, visningar, CTR och genomsnittlig position — utan scraping.

Se kunskap om URL-parametrar som ett diagnostiskt och forskningsinriktat verktyg: utmärkt för att bygga precisa söklänkar, köra manuella revisioner och förstå vad Google visar. Inte en ersättning för officiella API:er i stor skala.

Google Search Operators: parametrarna inne i din sökfråga

Search operators finns inuti q=-parametern, men de är viktiga följeslagare till URL-parametrarna. Tabellen nedan täcker de som Google för närvarande dokumenterar plus några som fortfarande fungerar i praktiken:

Operator	Vad den gör	Exempel
site:	Begränsar till en domän	q=site:example.com+SEO
filetype:	Begränsar till filtyp	q=filetype:pdf+annual+report
intitle:	Ordet måste finnas i titeln	q=intitle:pricing+SaaS
inurl:	Ordet måste finnas i URL:en	q=inurl:blog+marketing
-	Exkluderar ett ord	q=apple+-fruit
""	Exakt frasmatchning	q=%22google+search+url+parameters%22
OR	Antingen term	q=scraping+OR+crawling
before:	Resultat före ett datum	q=AI+before:2026-01-01
after:	Resultat efter ett datum	q=AI+after:2025-06-01
related:	Liknande webbplatser	q=related:hubspot.com

Den verkliga styrkan kommer när du kombinerar operators inuti q med URL-parametrar utanför:

q=site:competitor.com+intitle:pricing+after:2026/01/01&tbs=sbd:1&gl=us&udm=14

Det här hittar sidor på competitor.com med "pricing" i titeln, publicerade efter januari 2026, sorterade efter datum, på den amerikanska marknaden, med klassiska webresultat. Det är en mycket precis konkurrensanalytisk sökfråga byggd helt med URL-parametrar och operators.

Google säger att site:-resultat inte är garanterat fullständiga — behandla alltså inte en site:-sökning som en komplett inventering av indexerade sidor.

Ansvarsfull användning: Googles villkor och frekvensgränser

Kort men viktig kontext.

Googles användarvillkor förbjuder missbrukande åtkomst och kringgående av skyddsåtgärder. Google Search Help lyfter specifikt fram sök-scrapers och automatiserad rankningsmjukvara som exempel på automatiserad trafik. Brott mot dessa villkor kan leda till IP-blockeringar, CAPTCHA, kontobegränsningar och potentiellt rättsliga åtgärder.

Kunskap om URL-parametrar används bäst för: att manuellt bygga precisa sök-URL:er, skapa bokmärkesvänliga söklänkar för ditt team, köra småskaliga revisioner i webbläsaren och förstå hur Googles sökgränssnitt fungerar. För automatiserat arbete i produktionsskala bör du använda Googles officiella API:er — eller en licensierad tredjepartsleverantör av sökdata som Brave Search API.

På Thunderbit är vår webbläsartillägg byggt för användarinitierad extraktion från synliga sidor — inte för högvolym-automatisk Google-frågeställning. Det är en viktig skillnad.

Viktiga slutsatser: din verktygslåda för Google Search URL-parametrar 2026

Den korta versionen:

• Använd gl + hl för lokaliseringssignaler och lita inte bara på ccTLD:er under Googles omdirigeringsmigration
• Testa både udm och tbm där det är relevant — ingen av dem är ett stabilt, versionerat konsument-API
• udm=14 kan be om klassiska webresultat utan AI Overviews, men Google kan ta bort eller skriva om det
• Använd uule för geoinriktning på stadsnivå med protobuf-kodningen ovan
• Bemästra tbs för exakt datumfiltrering (cdr:1,cd_min:...,cd_max:...), datumsortering (sbd:1) och verbatim-sökning (li:1)
• Se upp för parameterkonflikter: gl kontra uule, tbm kontra udm, lr kontra cr
• num=100 är opålitlig och stöddes aldrig formellt — använd start i steg om 10 som ett säkrare standardval
• För strukturerad SERP-data, använd webbläsarbaserade verktyg som Thunderbit för ad hoc-arbete, eller officiella API:er för produktion
• Respektera Googles användarvillkor — URL-parametrar är ett forskningsverktyg, inte en scraping-licens

Google fortsätter att ändra parametrar utan förvarning. Jag håller referensen uppdaterad när läget förändras — spara den och kom tillbaka.

Läs mer

• 9 bästa SEO-API:er för 2026 (med verkliga kostnad-per-förfrågan-data)
• Så bemästrar du sökmotorscraping: en komplett guide
• Topp 27 verktyg för att analysera och övervaka webbplatsrankningar
• Så använder du sidnumrering i Web Scraper för effektiv extraktion
• Vad är sökautomation? Fördelar, verktyg och strategier

Vanliga frågor

Vad gör udm=14 i en Google-sök-URL?

udm=14 kan be om en klassisk resultatsida utan AI Overviews, vilket är anledningen till att den är populär bland SEO-utövare. Den är omvändt härledd, inte ett officiellt dokumenterat Google-avtal, och Google kan ta bort eller skriva om den beroende på session, konto, region, klient och experimentgrupp.

Fungerar num-parametern fortfarande 2026?

Lita inte på den. Google slutade tillförlitligt följa num=100 i september 2025, och en talesperson sa att parametern aldrig formellt stöddes. Använd start i steg om 10 som ett säkrare standardval för sidnumrering, och verifiera hur många resultat som faktiskt returneras eftersom Google fortfarande kan skriva om eller begränsa svaret.

Hur simulerar jag en Google-sökning från en specifik stad?

Använd parametern uule med ett kodat stadsnamn. Kodeavsnittet ovan innehåller den protobuf-baserade algoritmen och ett Python-exempel. Du behöver det kanoniska Google-platsnamnet (finns via Google Ads geografiska inriktningsdata), som du kodar till ett uule-värde som uule=w+CAIQICIeNew+York,New+York,United+States.

Vad är skillnaden mellan gl, lr och cr?

De här tre parametrarna styr olika delar av geografisk och språklig inriktning. gl simulerar din sökplats på landsnivå (påverkar ranking och lokala resultat). lr begränsar resultat till sidor skrivna på ett visst innehållsspråk. cr begränsar resultat till sidor hostade i ett visst land. De kan kombineras, men motstridiga kombinationer (som lr=lang_en + cr=countryJP) kommer att minska resultaten kraftigt.

Kan jag kombinera flera tbs-värden i en URL?

Ja — separera dem med kommatecken i en enda tbs-parameter. Till exempel filtrerar tbs=qdr:m,sbd:1 till den senaste månaden och sorterar efter datum (nyast först). Du kan också lägga till li:1 för verbatim-läge: tbs=qdr:m,sbd:1,li:1. Syntaxen för tbs är odokumenterad, så testa dina specifika kombinationer för att bekräfta att de fungerar som förväntat.