Er det sikkert at forbinde AI-agenter med Google Search Console?

Det egentlige spørgsmål er ikke bare “Er MCP sikkert?”

Når du bruger en AI-assistent til at gennemgå dit websteds performance, giver du et andet system adgang til oplysninger fra en Google-konto. Det kan være nyttigt og helt legitimt. Det skaber også valg, du bør forstå, før du klikker på Authorize.

De vigtigste risici er mere adgang, end arbejdsgangen har brug for, lækkede legitimationsoplysninger, unødvendig deling af data om søgeforespørgsler, automatiske handlinger uden tilstrækkelig gennemgang og en assistent, der forveksler upålideligt indhold med instruktioner.

Model Context Protocol, eller MCP, fastlægger, hvordan klienter og værktøjer kommunikerer. Det gør ikke i sig selv den enkelte server troværdig. Du skal stadig vurdere, hvem der driver serveren, hvilke tilladelser den beder om, og hvad der sker med dine oplysninger.

Den gode nyhed er, at et workflow til SEO-rapportering som regel kan bygges op om skrivebeskyttet adgang og værktøjskald, du kan følge med i. Det er et langt sikrere udgangspunkt end at lade en autonom agent ændre indstillinger på webstedet.

Hvilke oplysninger deler du?

Google Search Console indeholder oplysninger om de ejendomme, din konto har adgang til: sider, søgeforespørgsler, eksponeringer, klik, gennemsnitlige placeringer, indekseringsstatus og sitemapdata. Ingen af de rapporter indeholder din Google-adgangskode, og et korrekt implementeret OAuth-flow bør ikke bede dig skrive din adgangskode i en connectors chatvindue.

Alligevel fortjener rapporterne omtanke. En liste over søgeforespørgsler kan afsløre navnet på en funktion, der endnu ikke er annonceret. En liste over ejendomme kan afsløre kunderelationer. Indekseringsoplysninger kan blotlægge URL-mønstre, der ser interne ud. Bureauer kan have kontraktlige forpligtelser omkring kundedata, selv når siderne i sig selv er offentlige.

Hold to spørgsmål adskilt: Kan connectoren hente disse oplysninger? og Må assistenten dele eller opsummere dem i det konkrete workspace? En teknisk vellykket forbindelse besvarer ikke det andet spørgsmål.

Før du forbinder, så beslut, hvilken organisation, hvilken Google-konto og hvilken ejendom agenten skal bruge. Undgå bred adgang på tværs af kunder, når opgaven kun handler om ét websted.

Forstå Googles OAuth-scopes

OAuth er det autorisationssystem, der lader et program bede om begrænset adgang uden at spørge efter din Google-adgangskode. Googles samtykkeskærm bør angive tjenesten og de ønskede tilladelser.

Google dokumenterer scopet https://www.googleapis.com/auth/webmasters.readonly til skrivebeskyttet adgang til Search Console og https://www.googleapis.com/auth/webmasters til bredere adgang. Search Analytics API’et opregner disse understøttede autorisationsscopes.

Til en opgave som “vis, hvilke sider der mistede klik” bør læseadgang som regel være nok. Når du indsender eller fjerner sitemaps, ændrer ejendomme eller bruger andre skriveoperationer, kræver det en anden grad af omtanke.

Vurdér ikke sikkerheden alene ud fra den første samtykkeskærm. Nogle programmer beder om flere tilladelser senere, når en funktion aktiveres. Gennemgå enhver ekstra anmodning om samtykke fra Google, især når du slår administrative funktioner til.

Hvis en connector også tilbyder GA4, Google Tag Manager eller Bing, kan de have separate kilder og tilladelser. Det bør være et bevidst valg at forbinde dem, ikke noget, du tager for givet, bare fordi “adgang til Google” skulle betyde, at alle data er tilgængelige.

Forskellen på skrivebeskyttede værktøjer og skriveværktøjer

Skrivebeskyttede værktøjer beder om data. Eksempler er at liste ejendomme, forespørge performance og inspicere oplysninger om URL’ers indekserede version. De kan stadig afsløre følsomme rapporter, men de bør ikke ændre indstillinger i Search Console.

Skriveværktøjer udfører en handling. Eksempler kan være at indsende et sitemap, fjerne en ejendom eller give en søgemaskine besked om ændrede URL’er. Den slags handlinger kan have driftsmæssige konsekvenser, selv når API’et melder succes.

Et sikkert workflow gør skrivning til undtagelsen. Kræv et konkret formål, begræns de tilgængelige værktøjer, gennemgå de foreslåede parametre, og før logbog over, hvad der skete. For en autonom agent kan du overveje at holde skrivebeskyttede legitimationsoplysninger adskilt fra dem, der bruges til godkendte ændringer.

GSC Magics aktuelle dokumentation beskriver skrivebeskyttede adgangstokens og en valgfri skrivetilstand for kvalificerede planer. Den slags kontrol bør du lede efter hos enhver udbyder. Gennemgå alligevel udbyderens faktiske anmodninger om samtykke og din organisations krav, før du stoler på en markedsføringspåstand.

Sådan bør legitimationsoplysninger håndteres

Tokens er hemmeligheder. De hører hjemme i et autentificeringslager, et miljø eller en klientkonfiguration, der er designet til hemmeligheder, ikke i en blogkommentar, en README i et repository eller en chattranskription.

Med OAuth-kompatible MCP-klienter kan et godkendelsesflow i browseren gøre det unødvendigt at indsætte tokens i konfigurationsfiler. Til klienter, der kræver et bearer-token, skal du oprette et snævert afgrænset token, give det et fornuftigt udløb og tilbagekalde det, når det ikke længere er nødvendigt.

Lægger du et token i en lokal konfigurationsfil, så kontrollér, at filen ikke bliver committet til Git eller automatisk synkroniseret til et delt projekt. Et skærmbillede af indstillinger kan lække et token lige så let som et commit.

Del aldrig et rigtigt token med en AI-assistent for at “få hjælp til fejlfinding”. Du kan vise strukturen med en pladsholder som gsm_YOUR_TOKEN og holde den faktiske værdi tilbage.

Er et token blevet afsløret, så tilbagekald det, og udsted et nyt. Det er ikke nok at redigere den besked, der lækkede det.

Sådan ser prompt injection ud i et SEO-workflow

En AI-assistent kan læse tekst fra sider, logfiler, søgesnippets eller værktøjers svar. Det materiale kan indeholde ondsindede instruktioner, skrevet af en anden. En webside kan for eksempel indeholde en linje, der beder en agent ignorere sin oprindelige opgave og sende analysedata et andet sted hen.

Den linje er indhold på et websted, ikke en brugerinstruktion. En sikker agent bør behandle den som upålidelige data og fortsætte med at følge den faktiske brugers anmodning og værktøjstilladelser.

Rækkerne fra Search Console er strukturerede, men de kan stadig indeholde tekststrenge, som brugere kan styre, såsom teksten i en søgeforespørgsel eller URL’er. En søgeforespørgsel, der ligner en kommando, er stadig bare en søgeforespørgsel. Et robust workflow bør undgå at udføre instruktioner, der står i hentede data.

Det stærkeste forsvar er ikke én magisk prompt. Brug værktøjer med mindst mulige rettigheder, hold læse- og skriveworkflows adskilt, begræns netværks- og filsystemadgang, hvor det er relevant, og behold et godkendelsestrin før eksterne handlinger.

En sikkerhedstjekliste, før du forbinder

1. Bekræft serverens ejer. Brug den tiltænkte udbyder, og kontrollér endpointet mod dens officielle dokumentation.
2. Gennemgå autorisationsanmodningen. Vid, hvilken Google-konto, hvilke ejendomme og hvilke scopes der er tale om.
3. Vælg skrivebeskyttet som standard. Undgå brede skriverettigheder til almindelig rapportering.
4. Tjek databehandlingen. Gennemgå opbevaring, underdatabehandlere, logning, modeludbyderens vilkår og muligheder for sletning.
5. Undgå delte hemmeligheder. Hold tokens ude af chatbeskeder, committede filer og skærmbilleder.
6. Begræns agentens muligheder. En rapporteringsopgave har ikke brug for udrulning, vilkårlig shell-udførelse eller ukontrolleret browseradgang.
7. Kontrollér svarene. Kræv de præcise ejendomsidentifikatorer, datointervaller og rapporterede tal.
8. Vid, hvordan du tilbagekalder adgang. Test vejen til at afbryde forbindelsen, før det bliver presserende.
9. Hold kunder adskilt. Hold kundedata og legitimationsoplysninger i det rette workspace.
10. Gennemgå alle skrivninger. En indsendt anmodning og en korrekt handling er ikke nødvendigvis det samme.

Det lyder måske som meget for at læse et simpelt diagram, men det meste er engangsopsætning. Når tilladelserne er godt designet, bør en almindelig ugentlig rapport være kedelig – på den gode måde.

Sådan tilbagekalder du adgang på en sikker måde

Hvis du holder op med at bruge en MCP-integration, så fjern eller deaktivér den i AI-klienten, og tilbagekald dens token eller adgangen til den tilsluttede konto i MCP-udbyderens dashboard. Hvis der er givet Google OAuth-adgang, så gennemgå tredjepartsforbindelserne på din Google-konto, og tilbagekald de tilladelser, du ikke længere vil opretholde.

Det er forskellige kontroller. At fjerne en server fra klienten gør ikke nødvendigvis et token ugyldigt, hvis det er udstedt af en separat udbyder. Og at afbryde en Google-kilde sletter ikke nødvendigvis data, der tidligere er eksporteret til en AI-samtale.

Ved afslutning af et kundeforhold bør du dokumentere, hvilken tjeneste der havde adgang, og hvornår den blev tilbagekaldt. Spørg udbyderen om sletning eller opbevaring, hvis kontrakter kræver det.

Får en MCP-server min Google-adgangskode?

Et legitimt Google OAuth-flow sender dig til Googles autorisationsside i stedet for at bede dig oplyse din adgangskode til connectoren. Den tilsluttede tjeneste modtager autorisationstilladelser eller tokens, ikke din adgangskode. Det betyder ikke, at den ikke har følsom adgang: OAuth-tokens kan være kraftfulde og skal beskyttes.

Hvis en angivelig Search Console-integration beder dig indsætte din Google-adgangskode i en almindelig formular eller chat, så stop, og kontrollér den uafhængigt.

Kan en agent ved et uheld få et websted fjernet fra Googles indeks?

En skrivebeskyttet Search Console-integration bør ikke kunne indsende destruktive administrative handlinger gennem Search Console. En agent, der kan redigere og udrulle dit websteds filer, kunne dog introducere et noindex, en omdirigering eller et problem med robots.txt via separate kodetilladelser.

Derfor skal sikkerhedsgrænsen omfatte AI-klienten, ikke kun MCP-serveren. Hold rapporteringsforbindelsen skrivebeskyttet, og gennemgå kodeændringer før udrulning.

Husk, at Search Console ikke i sig selv afgør alle udfald af indekseringen. Googles URL Inspection API rapporterer status for den indekserede version; det fungerer ikke som en live indekseringsknap.

Hvad med Google Indexing API?

Nogle værktøjer reklamerer med, at de kan “indeksere sider automatisk”. Det fortjener særlig skepsis. Googles dokumentation til Indexing API’et begrænser den understøttede brug til sider med den angivne markup for JobPosting eller BroadcastEvent til livestreams. Det er ikke en generel løsning til almindelige SaaS-landingssider og blogindlæg.

Et værktøj, der hævder at kunne tvinge Googles indeks til at acceptere en vilkårlig side, overdriver, hvad det officielle API lover. En indsendelse af et sitemap er også et hint om opdagelse, ikke en garanti.

Du kan automatisere tjek og notifikationer inden for de understøttede rammer. Forveksl ikke et vellykket API-svar med vellykket synlighed i søgning.

Sådan tester du en ny connector med mindst mulig risiko

Start med et lille skrivebeskyttet forsøg. Når du har godkendt forbindelsen, så bed AI-klienten om at liste de Search Console-ejendomme, den har adgang til, og vent på dit valg. Bed derefter om de samlede klik og eksponeringer for en fuld periode på syv dage.

Sammenlign resultatet med Google Search Console-brugerfladen med samme ejendom, søgetype og datointerval. Hvis du ser en forskel, så undersøg forespørgslens parametre i stedet for at gå ud fra, at den ene tjeneste lyver. Data i Search Console kan aggregeres forskelligt efter ejendom og efter side.

Bed derefter agenten om at finde den side, der har tabt mest – men giv den besked på ikke at redigere noget indhold eller nogen indstillinger. Først når rapporten giver mening, bør du overveje bredere workflows.

Vores oversigt over Google Search Console MCP forklarer forløbet i en forespørgsel og de almindelige værktøjer.

Spørgsmål om AI-adgang, som folk stiller

Er en selvhostet MCP-server altid mere privat?

Ikke automatisk. Den kan give dig mere kontrol, men kun hvis hosting, opbevaring af legitimationsoplysninger, logning og opdateringer er ordentligt håndteret. En selvhostet server uden vedligeholdelse kan være mindre sikker end en omhyggeligt drevet hostet tjeneste.

Viser Google Search Console, hvilke AI-prompts der har tilgået mine data?

Ikke som en standardrapport om performance i Search Console. Din MCP-udbyder eller klient tilbyder måske logfiler over værktøjskald; kontrollér de funktioner i stedet for at antage, at Google fører et revisionsspor over agenters adgang for dig.

Kan jeg begrænse adgangen til én ejendom?

Tilladelserne på din Google-kontos Search Console-ejendomme er en vigtig grænse. Nogle udbydere tilbyder måske også begrænsninger pr. workspace eller websted. Tjek værktøjernes faktiske adfærd og organisationens kontroller, før du går ud fra detaljeret isolering.

Er Search Console-rapporter offentlige, fordi Googles søgeresultater er offentlige?

Nej. Googles søgeresultater er offentlige, men dine samlede rapporter på kontoniveau og oplysninger om adgang til ejendomme er private tjenestedata.

Er skrivebeskyttet adgang helt uden risiko?

Nej. Det mindsker risikoen for uønskede ændringer, men fortrolige oplysninger kan stadig blive afsløret, opbevaret eller brugt i et uhensigtsmæssigt workspace.

Den sikreste måde at komme i gang på

Brug én tiltænkt ejendom, de mindst nødvendige rettigheder og en skrivebeskyttet forespørgsel, du kan krydstjekke. Hold ændringer i implementeringen i en separat gennemgangsproces. Så får du gavn af AI-understøttet søgeanalyse uden at give mere kontrol end nødvendigt.

Dokumentationen til GSC Magic beskriver de aktuelle muligheder for adgangstokens og skrivetilstand i detaljer. Du kan holde de kontroller op imod kravene ovenfor, før du beslutter, om en hostet connector passer til dit workflow.