Er det trygt å koble AI-agenter til Google Search Console?

Spørsmålet er ikke bare «Er MCP trygt?»

Når du bruker en AI-assistent til å gå gjennom ytelsen til nettstedet ditt, gir du et annet system tilgang til informasjon fra en Google-konto. Det kan være nyttig og helt legitimt. Men det innebærer valg du bør forstå før du klikker på Authorize.

De viktigste risikoene er bredere tilgang enn arbeidsflyten trenger, lekket legitimasjon, unødvendig deling av søkedata, automatiserte handlinger uten tilstrekkelig kontroll, og en assistent som forveksler innhold den ikke kan stole på, med instruksjoner.

Model Context Protocol, eller MCP, definerer hvordan klienter og verktøy kommuniserer. Det gjør ikke en enkelt server pålitelig av seg selv. Du må fortsatt vurdere hvem som driver serveren, hvilke tillatelser den ber om, og hva som skjer med informasjonen din.

Det positive er at en SEO-rapporteringsarbeidsflyt som regel kan bygges rundt skrivebeskyttet tilgang og verktøykall som kan følges. Det er et mye tryggere utgangspunkt enn å la en autonom agent endre innstillinger på nettstedet.

Hvilken informasjon deler du?

Google Search Console gir informasjon om eiendommene kontoen din har tilgang til: sider, søkeord, visninger, klikk, gjennomsnittlig posisjon, indekseringsstatus og data om områdekart. Ingen av disse rapportene inneholder Google-passordet ditt, og en riktig implementert OAuth-flyt skal ikke be deg skrive passordet inn i chattevinduet til en connector.

Rapportene fortjener likevel varsomhet. En liste over søkeord kan avsløre navnet på en funksjon som ikke er kunngjort. En liste over eiendommer kan vise hvem du har kunderelasjoner til. Indekseringsinformasjon kan avsløre URL-mønstre som ser interne ut. Byråer kan ha avtalefestede forpliktelser knyttet til kundedata, selv når selve sidene er offentlige.

Skill mellom to spørsmål: Kan connectoren hente denne informasjonen? og Har assistenten lov til å dele eller oppsummere den i akkurat dette arbeidsområdet? En teknisk vellykket tilkobling svarer ikke på det andre spørsmålet.

Før du kobler til, bestemmer du hvilken organisasjon, Google-konto og eiendom agenten skal bruke. Unngå bred tilgang på tvers av kunder når oppgaven bare gjelder ett nettsted.

Forstå OAuth-omfangene hos Google

OAuth er autorisasjonssystemet som lar en applikasjon be om begrenset tilgang uten å spørre etter Google-passordet ditt. Samtykkeskjermen hos Google skal vise hvilken tjeneste det gjelder, og hvilke tillatelser den ber om.

Google dokumenterer omfanget https://www.googleapis.com/auth/webmasters.readonly for skrivebeskyttet tilgang til Search Console og https://www.googleapis.com/auth/webmasters for bredere tilgang. Search Analytics API lister disse støttede autorisasjonsomfangene.

Til en oppgave som «vis hvilke sider som mistet klikk» bør lesetilgang som regel være nok. Å sende inn eller fjerne områdekart, endre eiendommer eller bruke andre skriveoperasjoner krever en annen vurdering.

Ikke bedøm sikkerheten bare ut fra den første samtykkeskjermen. Noen applikasjoner ber om flere tillatelser senere, når en funksjon aktiveres. Gå gjennom alle ekstra samtykkeforespørsler fra Google, særlig når du slår på administrative funksjoner.

Hvis en connector også tilbyr GA4, Google Tag Manager eller Bing, kan den ha egne kilder og tillatelser. Å koble dem til bør være et bevisst valg, ikke en antakelse om at «Google-tilgang» betyr at alle data er tilgjengelige.

Forskjellen mellom skrivebeskyttede verktøy og skriveverktøy

Skrivebeskyttede verktøy ber om data. Eksempler er å liste opp eiendommer, spørre etter ytelse og inspisere informasjon om indekserte versjoner av URL-er. De kan fortsatt eksponere sensitive rapporter, men de skal ikke endre innstillinger i Search Console.

Skriveverktøy utfører en handling. Eksempler kan være å sende inn et områdekart, fjerne en eiendom eller varsle en søkemotor om endrede URL-er. Slike handlinger kan få praktiske konsekvenser, selv når API-et melder om suksess.

En sikker arbeidsflyt gjør skriving til et unntak. Krev et konkret formål, begrens hvilke verktøy som er tilgjengelige, gå gjennom de foreslåtte parameterne og før logg over hva som skjedde. For en autonom agent bør du vurdere å holde skrivebeskyttet legitimasjon adskilt fra legitimasjonen som brukes til å utføre godkjente endringer.

Gjeldende dokumentasjon for GSC Magic beskriver skrivebeskyttede tilgangstokener og en valgfri skrivemodus på planer som kvalifiserer. Det er den typen kontroll du bør lete etter hos enhver leverandør. Gå likevel gjennom de faktiske samtykkeforespørslene fra leverandøren og kravene i organisasjonen din før du stoler på en markedsføringspåstand.

Slik bør legitimasjon håndteres

Tokener er hemmeligheter. De hører hjemme i en lagring for autentisering, i miljøvariabler eller i en klientkonfigurasjon som er laget for hemmeligheter, ikke i en bloggkommentar, en README-fil eller en chatlogg.

Med MCP-klienter som støtter OAuth kan en autorisasjonsflyt i nettleseren gjøre det unødvendig å lime tokener inn i konfigurasjonsfiler. For klienter som krever et bearer-token oppretter du et token med snevert omfang, gir det en fornuftig utløpstid og trekker det tilbake når det ikke lenger trengs.

Legger du et token i en lokal konfigurasjonsfil, må du kontrollere at filen ikke sjekkes inn i Git eller synkroniseres automatisk inn i et delt prosjekt. Et skjermbilde av innstillinger kan lekke et token like lett som en commit.

Del aldri et ekte token med en AI-assistent for å «feilsøke». Du kan vise strukturen med en plassholder som gsm_YOUR_TOKEN og holde tilbake den faktiske verdien.

Hvis et token er eksponert, trekker du det tilbake og utsteder et nytt. Det er ikke nok å redigere meldingen som lekket det.

Slik ser prompt injection ut i en SEO-arbeidsflyt

En AI-assistent kan lese tekst fra sider, logger, snippeter i søk eller resultater fra verktøy. Det materialet kan inneholde ondsinnede instruksjoner skrevet av noen andre. En nettside kan for eksempel inneholde en linje som ber en agent se bort fra den opprinnelige oppgaven og sende analysedata et annet sted.

Den linjen er innhold på et nettsted, ikke en instruksjon fra brukeren. En trygg agent bør behandle den som data den ikke kan stole på, og fortsette å følge den faktiske brukerens forespørsel og tillatelsene til verktøyene.

Radene fra Search Console er strukturerte, men de kan likevel inneholde tekststrenger som brukere kontrollerer, som søketekst eller URL-er. Et søk som ligner en kommando, er fortsatt bare et søk. En robust arbeidsflyt bør unngå å utføre instruksjoner som står i hentede data.

Det sterkeste forsvaret er ikke én magisk prompt. Bruk verktøy med minst mulig tilgang, hold lese- og skrivearbeidsflyter adskilt, begrens tilgangen til nettverk og filsystem der det er hensiktsmessig, og ha et godkjenningstrinn før handlinger utad.

En sikkerhetssjekkliste før du kobler til

1. Bekreft hvem som eier serveren. Bruk den leverandøren du mener, og kontroller endepunktet mot den offisielle dokumentasjonen.
2. Se på autorisasjonsforespørselen. Vit hvilken Google-konto, hvilke eiendommer og hvilke omfang det gjelder.
3. Velg skrivebeskyttet som standard. Unngå brede skrivetillatelser til rutinemessig rapportering.
4. Sjekk databehandlingen. Gå gjennom lagringstid, underdatabehandlere, logging, vilkårene hos modelleverandøren og muligheter for sletting.
5. Unngå delte hemmeligheter. Hold tokener utenfor chattemeldinger, innsjekkede filer og skjermbilder.
6. Begrens hva agenten kan. En rapporteringsoppgave trenger ikke utrulling, vilkårlig kjøring av shell-kommandoer eller ukontrollert tilgang til nettleseren.
7. Verifiser resultatene. Krev nøyaktige eiendomsidentifikatorer, datointervaller og rapporterte tall.
8. Vit hvordan du trekker tilbake tilgang. Test veien for å koble fra før det haster.
9. Hold kunder adskilt. Behold kundedata og legitimasjon i riktig arbeidsområde.
10. Gå gjennom all skriving. En innsendt forespørsel og en riktig handling er ikke nødvendigvis det samme.

Dette kan høres mye ut for å lese et enkelt diagram, men det meste er oppsett som gjøres én gang. Når tillatelsene først er godt utformet, bør en vanlig ukerapport være kjedelig, på en god måte.

Slik trekker du tilbake tilgang på en trygg måte

Hvis du slutter å bruke en MCP-integrasjon, fjerner eller deaktiverer du den i AI-klienten og trekker tilbake tokenet eller tilgangen til den tilkoblede kontoen i dashbordet hos MCP-leverandøren. Hvis du ga tilgang via Google OAuth, går du gjennom tredjepartsapplikasjonene som er koblet til Google-kontoen din, og trekker tilbake alle tillatelser du ikke lenger vil ha.

Dette er ulike kontroller. Å fjerne en server fra klienten gjør ikke nødvendigvis et token ugyldig hvis det er utstedt av en annen leverandør. På samme måte sletter ikke frakobling av en Google-kilde nødvendigvis data som tidligere er eksportert inn i en AI-samtale.

Når en kunde avsluttes, dokumenterer du hvilken tjeneste som hadde tilgang og når den ble trukket tilbake. Spør leverandøren om sletting eller lagringstid hvis avtaler krever det.

Får en MCP-server Google-passordet ditt?

En legitim OAuth-flyt hos Google sender deg til Googles autorisasjonsside i stedet for å be deg oppgi passordet til connectoren. Tjenesten du kobler til, får autorisasjonstillatelser eller tokener, ikke passordet ditt. Det betyr ikke at den ikke har sensitiv tilgang: OAuth-tokener kan være kraftige og må beskyttes.

Hvis en påstått Search Console-integrasjon ber deg lime inn Google-passordet i et vanlig skjema eller en chat, stopper du og kontrollerer den uavhengig.

Kan en agent komme til å få et nettsted fjernet fra indeksen?

En skrivebeskyttet Search Console-integrasjon skal ikke kunne sende inn destruktive administrative handlinger gjennom Search Console. En agent som kan redigere og rulle ut filene på nettstedet, kan derimot innføre en noindex, en omdirigering eller et problem i robots.txt via separate tillatelser til koden.

Derfor må sikkerhetsgrensen omfatte AI-klienten, ikke bare MCP-serveren. Hold rapporteringstilkoblingen skrivebeskyttet, og gå gjennom kodeendringer før utrulling.

Husk at Search Console selv ikke avgjør alle utfall for indeksering. Googles URL Inspection API rapporterer status for den indekserte versjonen. Det fungerer ikke som en knapp for live indeksering.

Hva med Google Indexing API?

Noen verktøy markedsfører at de kan «indeksere sider automatisk». Det fortjener ekstra gransking. Googles dokumentasjon for Indexing API begrenser støttet bruk til sider med den angitte markeringen for JobPosting eller BroadcastEvent for direktesendinger. Det er ikke en generell løsning for vanlige landingssider for SaaS og blogginnlegg.

Et verktøy som hevder at det kan tvinge Googles indeks til å godta en hvilken som helst side, lover mer enn det offisielle API-et gjør. Å sende inn et områdekart er også bare et hint om oppdagelse, ikke en garanti.

Du kan automatisere kontroller og varsler innenfor det som støttes. Ikke forveksle et vellykket API-svar med vellykket synlighet i søk.

Slik tester du en ny connector med minst mulig risiko

Begynn med et lite, skrivebeskyttet eksperiment. Etter at du har godkjent tilkoblingen, ber du AI-klienten liste opp Search Console-eiendommene den har tilgang til, og venter på at du velger. Be deretter om totalt antall klikk og visninger for en hel periode på sju dager.

Sammenlign resultatet med grensesnittet i Google Search Console, med samme eiendom, søketype og datointervall. Hvis du ser en forskjell, undersøker du parameterne i forespørselen i stedet for å anta at en av tjenestene lyver. Search Console-data kan aggregeres ulikt per eiendom og per side.

Be deretter agenten finne siden med størst tap, men instruer den om å ikke redigere noe innhold eller noen innstillinger. Først når rapporten gir mening, bør du vurdere bredere arbeidsflyter.

Oversikten vår over Google Search Console MCP forklarer hvordan forespørslene går og hvilke verktøy som er vanlige.

Spørsmål folk stiller om AI-tilgang

Er en selvhostet MCP-server alltid mer privat?

Ikke automatisk. Den kan gi deg større kontroll, men bare hvis hosting, lagring av legitimasjon, logging og oppdateringer håndteres riktig. En selvhostet server uten vedlikehold kan være mindre sikker enn en hostet server som drives nøye.

Viser Google Search Console hvilke AI-prompter som har hentet dataene mine?

Ikke som en vanlig ytelsesrapport i Search Console. MCP-leverandøren eller klienten din kan tilby logger over verktøykall. Sjekk de funksjonene i stedet for å anta at Google fører et revisjonsspor for agenter som du kan se.

Kan jeg begrense tilgangen til én eiendom?

Tillatelsene på Google-kontoen din for Search Console-eiendommer er en viktig grense. Noen leverandører kan i tillegg tilby begrensninger per arbeidsområde eller nettsted. Sjekk hvordan verktøyene faktisk oppfører seg og hvilke kontroller organisasjonen har, før du antar at tilgangen er isolert i detalj.

Er Search Console-rapporter offentlige fordi Google-søkeresultater er offentlige?

Nei. Google-søkeresultater er offentlige, men aggregerte rapporter på kontonivå og informasjon om tilgang til eiendommer er private tjenestedata.

Er skrivebeskyttet tilgang helt uten risiko?

Nei. Den reduserer risikoen for uønskede endringer, men konfidensiell informasjon kan fortsatt bli avslørt, lagret eller brukt i et uegnet arbeidsområde.

Den tryggeste måten å komme i gang på

Bruk én eiendom du har bestemt deg for, minst mulig tilgang og en skrivebeskyttet spørring du kan krysssjekke. Hold endringer i implementeringen i en egen gjennomgangsprosess. Da får du fordelene av AI-støttet søkeanalyse uten å gi fra deg unødvendig kontroll.

Dokumentasjonen til GSC Magic beskriver gjeldende alternativer for tilgangstokener og skrivemodus. Du kan sammenligne disse kontrollene med kravene over før du avgjør om en hostet connector passer til arbeidsflyten din.