Kan søge- og AI-systemer læse jeres indhold?

Et adgangstjek undersøger, om et bestemt søge- eller AI-produkt kan hente det indhold, I ønsker offentligt. Det skal omfatte den faktiske side, robotsregler, adgangskontrol, firewall og læsbart hovedindhold. Et vellykket tjek beviser tilgængelighed, ikke indeksering eller kildehenvisning.

Fastlæg først formålet med adgangen

Skeln mellem automatisk søgeopdagelse, en hentning udløst af en bruger og indsamling til modeltræning. Disse formål har forskellige agenter og kontrolmuligheder. Et ønske om at kunne findes i søgning kræver ikke, at virksomheden uden videre godkender alle andre anvendelser.

OpenAI beskriver rollerne og de separate kontroller. Perplexity beskriver egne crawlere, herunder brugerhentning. Kontrollér leverandørens oplysninger, før I ændrer en regel. En user-agent kan efterlignes; navnet i en log er ikke alene identitetsbevis.

Gennemgå en repræsentativ offentlig side

1. Åbn den tiltænkte URL uden login, og notér destination og svarstatus.
2. Kontrollér, om den egentlige forklaring er tilgængelig som tekst.
3. Undersøg sidens canonical og relevante indekserings- og snippetdirektiver.
4. Følg et almindeligt internt link til siden.
5. Undersøg robotsregler for den konkrete agent og sti.
6. Kontrollér, om CDN eller firewall behandler legitime forespørgsler anderledes.

Test både en vigtig ydelsesside og en guide, hvis de bruger forskellige skabeloner. En fungerende forside siger ikke, om en underside rammes af en forkert regel. Bevar forskellen mellem et faktisk HTTP-svar og en side, der visuelt ligner en fejl, men returnerer en successtatus.

Dokumentér observation og årsag hver for sig

»En offentlig guide viser en udfordringsside« er en observation. »Alle AI-systemer er blokeret« er en langt bredere konklusion, som kræver yderligere belæg. Gem URL, tidspunkt, testform og relevant konfiguration uden cookies, kontodata eller adgangstokens.

Hvis virksomheden har autoriseret adgang til serverlogs, kan verificerede crawlerforespørgsler hjælpe. Bevar kun de nødvendige felter. Et logbesøg dokumenterer en anmodning og dens svar; det viser ikke, om indholdet senere blev valgt som kilde i et svar.

Ret mindst muligt og kontrollér igen

En for bred robotsregel kan ramme en relevant offentlig mappe. En forkert noindex kan komme fra en skabelon. En firewall kan udfordre en legitim crawler. Find den konkrete årsag, få ændringen godkendt og gentag testen på de berørte eksempler. Deaktivér ikke sikkerhed for hele hjemmesiden for at få én test til at virke.

En robotsfil er ikke en sikkerhedsgrænse for fortroligt indhold. Private arbejdsområder skal fortsat kræve adgang. Ingen indholdsanbefaling om synlighed bør føre til offentliggørelse af kundedata eller interne dokumenter.

Et tænkt fejlforløb

En guide kan læses af en almindelig besøgende, men en bekræftet søgecrawler får en udfordring fra et nyligt CDN-filter. Teamet knytter fundet til filteret og ændrer kun den relevante regel efter sikkerhedsvurdering. Efter kontrollen kan rapporten sige, at den testede adgang nu fungerer. Den skal stadig ikke kalde siden indekseret eller citeret uden ny evidens.

Overdrag et adgangsnotat, som andre kan gentage

Notér produkt, agentrolle, URL, regler, observation, ændring og kontrol efter ændringen. Brug den tekniske gennemgang til den bredere fejlprioritering. Brug ChatGPT-kildegennemgangen og Perplexity-metoden til at undersøge faktiske svar bagefter. Adgang er et nødvendigt undersøgelsespunkt, ikke en færdig synlighedsstrategi.

Brug en kontrolmatrix frem for ét grønt resultat

Registrér hver test som kombinationen af side, produktformål og kontrol. En offentlig HTML-side kan bestå, mens et tilknyttet dokument kræver login. En forside kan fungere, mens en produktsti rammes af en anden regel. Ét positivt resultat bør derfor ikke farve hele domænet grønt.

For hvert fund skal rapporten have en præcis tilstand: tilgængelig i testen, blokeret i testen eller ikke afklaret. Den sidste er relevant, hvis systemets identitet ikke kunne verificeres, hvis testen fik et midlertidigt svar, eller hvis nødvendige konfigurationsoplysninger mangler.

Hvis et testværktøj skifter user-agent for at simulere en crawler, skal det beskrives som simulation. Det er ikke bevis på, at en virkelig leverandør har hentet siden. Brug simulation til at finde mulige regler og verificeret leverandørevidens til at understøtte en stærkere konklusion, når den er tilgængelig.

Skeln forskellige fejlkilder i overdragelsen

En redirect til login peger på adgangsforløbet. Et svar uden hovedindhold kan pege på rendering eller template. En fejlagtig canonical kan pege på sideidentiteten. En udfordringsside kan pege på CDN-behandling. Disse observationer kan ligne hinanden i et generelt »kan ikke læse«-resultat, men kræver forskellige rettelser.

Et godt teknisk notat indeholder derfor et eksempel, forventet adfærd, faktisk adfærd og den næste nødvendige undersøgelse. Den relevante ejer kan derefter finde årsagen uden at ændre hele sikkerhedsopsætningen. Hold kundeoplysninger, cookies og adgangstokens ude af de delte eksempler.

Kontrollér grænsen mellem offentlig og privat efter en rettelse

En ændring for offentlige guides skal ikke åbne private arbejdsområder. Medtag derfor et passende negativt kontrolpunkt: et område, som fortsat skal kræve autorisation, må ikke være blevet offentligt. Gennemfør kun kontrollen inden for aftalt adgang og uden at hente uvedkommende persondata.

Gem både den positive og den beskyttende kontrol. Det gør det muligt at sige, at synligheden er forbedret for de relevante offentlige sider, samtidig med at den tiltænkte adgangsgrænse er bevaret. En stærk audit viser begge hensyn frem for kun at tælle flere tilladte agenter.

Redaktionelt gennemgået 3. november 2026. Arbejdsmodeller og mærkede eksempler er vejledning; de dokumenterer ikke kunderesultater eller en platforms godkendelse.