AI-tilgjengelighetsrevisjon for Agentberedskap

AI-systemer kan ikke sitere, anbefale eller handle på innhold de ikke pålitelig kan hente. Denne fasen tester det grunnleggende før teamet måler synlighet eller bestiller innhold beregnet for svarmotorer.

Fase: P4, Trinn A — Forstå. Tidsramme: 3–5 arbeidsdager for et typisk markedsnettsted; 5–10 for en stor e-handel, markedsplass eller tungt klient-rendret applikasjon. Eier: den tekniske SEO-lederen er ansvarlig, med utvikling som kjører hente- og renderingstester, innholdsansvarlig som vurderer uthentingsbarhet, og en forretnings- eller juridisk ansvarlig som bestemmer kravlerpolitikk.

Hvorfor denne fasen kommer her

En konvensjonell teknisk revisjon spør om søkemotorer kan kravle, rendere, indeksere og rangere nettstedet. Denne fasen spør om AI-kravlere, gjenfinningssystemer og oppgaveorienterte agenter kan nå og tolke den samme nyttige informasjonen. De kan bruke ulike brukeragenter, hentestier, renderingskapabiliteter, tidsavbrudd og uthentingsmetoder. En indekserbar side kan fortsatt returnere et tomt skall, samtykkevegg, bot-utfordring eller frakoblede fragmenter til en AI-klient.

En AI-tilgjengelighetsrevisjon hører derfor hjemme ved siden av den tekniske grunnlinjerevisjonen , ikke på slutten av innholdsproduksjonen. Klient-side-rendering betyr at JavaScript konstruerer viktig innhold etter at den opprinnelige HTML-en ankommer. Gjenfinningssystemer utfører kanskje ikke den koden, stopper før den er fullført, eller henter kun det første svaret. Hvis produktnavnet, svaret, prisen, tilgjengeligheten eller beviset kun eksisterer etter at JavaScript kjører, kan senere innholdsoptimalisering ikke reparere tilgangssvikten.

Denne fasen bruker de verifiserte kontoene, analysene, kravlerlogger, sidekartkilder, kritiske URL-settet og eierskapskartet fra fasen for tilgang, sporing og datakilder . Å kjøre den tidligere gjør at teamet ikke kan skille et reelt fravær fra manglende tilgang. Å kjøre den etter grunnlinjemåling forurenser grunnlinjen: null-siteringer kan reflektere et utilgjengelig nettsted, ikke svakt innhold eller etterspørsel.

Å hoppe over fasen er bortkastet arbeid: skribenter forbedrer avsnitt en kravler aldri mottar, utviklere legger til skjema bak en utfordring, eller teamet forveksler en gyldig llms.txt med gjennomgående beredskap. Tilgang, uthenting, forståelse og handling er separate kapabiliteter.

Inndata og utdata

Inndataene gjør tester reproduserbare. Utdatene danner en kontrakt med P5: måling begynner først etter at kjente tilgangsfeil er fikset eller eksplisitt akseptert.

Sjekklisten

Test det representative URL-settet, ikke bare startsiden, og ta vare på reproduserbare bevis.

1. Bestem kravlertilgang bevisst

Hva du skal gjøre: kartlegg AI-kravlerregler i robots.txt , CDN-botkontroller, webapplikasjonsbrannmurer, samtykkelag og opprinnelseskonfigurasjon. Hvorfor det betyr noe: en robots-tillatelse er bare en preferanse; en kanttjeneste kan fortsatt blokkere forespørselen, mens en utilsiktet jokertegnblokkering ikke er politikk. Slik gjør du det: sammenlign levende regler med politikkmatrisen, hent representative URL-er med aktuelle brukeragenter, og registrer avveiningen. Verktøy: AmICited Robots.txt & Sitemaps, en godkjent forespørselsklient og CDN-/opprinnelseslogger. Ferdig når: hver kravlerfamilie har en godkjent tillatelse, blokkering eller betinget beslutning, og levende atferd samsvarer med den.

2. Sammenlign ikke-JavaScript-svaret med den nyttige siden

Hva du skal gjøre: sammenlign innledende HTML med den vanlige nettlesersiden. Hvorfor det betyr noe: en gjenfinningsklient kjører kanskje ikke skript som setter inn svar, tilbud, lenker eller produktdata. Slik gjør du det: test hver viktige mal før hydrering, prosessen som fester applikasjonsatferd til server-HTML. Verktøy: en nettleser uten skript eller HTTP-klient pluss den rendrede siden. Ferdig når: det innledende svaret inneholder tittelen, H1, primært innhold, kjernedata og oppdagelseslenker; ethvert unntak har bevis og en eier.

3. Test uthentingsbarhet av rendret DOM

Hva du skal gjøre: uthent hovedinnhold fra den rendrede dokumentobjektmodellen (DOM), nettleserens strukturerte siderepresentasjon, uten navigasjon, samtykketekst eller skjulte varianter. Hvorfor det betyr noe: å motta tekst er ikke det samme som å identifisere riktig tekst; malstøy kan ødelegge gjenfinning. Slik gjør du det: sammenlign uthentet tittel, svar, utgiver, datoer, fakta og lenker med den synlige kilden på tvers av lange, korte og kommersielle sider. Verktøy: nettleserinspeksjon, tekstuthenting og sidekilde. Ferdig når: posten bevarer primær betydning og fakta uten visuell plassering eller udokumenterte selektorer.

4. Inspiser tilgjengelighetstreet

Hva du skal gjøre: gå gjennom tilgjengelighetstreet: roller, navn, tilstander, overskrifter, landemerker og kontroller. Hvorfor det betyr noe: semantikk skiller overskrifter fra dekorasjon, knapper fra ikoner og primært innhold fra navigasjon. Slik gjør du det: test kritiske maler for én H1, ordnede overskrifter, navngitte kontroller, landemerker, beskrivende lenker og meningsfulle bildealternativer. Verktøy: AmICited Accessibility Tree-sjekker og nettleserinspeksjon. Ferdig når: skåren oppfyller terskelen, ingen kritisk kontroll mangler et navn, og hovedområdet og neste handling er identifiserbare.

5. Valider strukturerte datadekning og sannferdighet

Hva du skal gjøre: sammenlign synlige fakta med strukturerte data , standardisert markering som Schema.org JSON-LD. Hvorfor det betyr noe: markering tydeliggjør entiteter, tilbud, forfatterskap og datoer, men unøyaktig markering formidler feil fakta. Slik gjør du det: valider aktuelle skjemaer og avstem navn, URL-er, priser, valuta, tilgjengelighet, datoer, vurderinger og identifikatorer med kildesystemer. Verktøy: validator, rendret HTML og kildeposter. Ferdig når: kritiske maler har gyldig aktuell markering, verdier samsvarer med synlige fakta, og hver vesentlig advarsel er løst eller forklart.

6. Gå gjennom llms.txt som en veiledning, ikke en portvakt

Hva du skal gjøre: sjekk om /llms.txt nøyaktig oppsummerer organisasjonen og lenker til kanoniske offentlige ressurser. Det er en foreslått ren-tekst-veiledning, ikke tilgangskontroll eller et garantert rangeringssignal. Hvorfor det betyr noe: et konsist kart reduserer tvetydighet; et utdatert villeder agenter. Slik gjør du det: verifiser status, Markdown-struktur, beskrivelse, destinasjoner, kanoniske URL-er og eier. Verktøy: AmICited llms.txt-gjennomgang og direkte henting. Ferdig når: filen, hvis den brukes, har ingen ødelagte/personlige lenker og en vedlikeholdseier; fravær er et forbedringsfunn, ikke bevis på usynlighet.

7. Sample selvstendige avsnitt

Hva du skal gjøre: gå gjennom uavhengig hentede definisjoner, svar, fakta, sammenligninger, trinn og begrensninger. Hvorfor det betyr noe: gjenfinning kan skille et avsnitt fra overskriften; «det fungerer bedre for dem» mister da subjektet og sammenligningen. Slik gjør du det: les minst 20 avsnitt uten tittel eller forrige avsnitt. Verktøy: uthentingsresultat og redaksjonell gjennomgang. Ferdig når: hvert navngir sitt subjekt, svarer på et identifiserbart spørsmål, bevarer betingelser eller enheter, og unngår uløste referanser.

8. Bekreft kanonisk entitetstydeighet

Hva du skal gjøre: verifiser at nettstedet oppgir hvem organisasjonen er, hva den tilbyr, og hvordan dens merkevarer, produkter, personer, steder og profiler henger sammen. En kanonisk entitet er den primære virkelige tingen et navn refererer til. Hvorfor det betyr noe: inkonsistente navn, gamle logoer, motstridende beskrivelser og frakoblede profil-URL-er gjør det lett å slå sammen to entiteter eller splitte én entitet i flere. Slik gjør du det: sammenlign startsiden, Om-oss-siden, kontaktdetaljer, strukturerte data, sosiale profiler, forfattersider, juridisk navn og viktige tredjepartsprofiler. Verktøy: entitetsfaktaark, rendrede sider og strukturerte data-utdata. Ferdig når: ett godkjent faktaark løser offisielt navn, aliaser, kanonisk URL, logo, beskrivelse, eierskap, primære tilbud og samme-entitetsprofiler, med konflikter loggført for korrigering.

9. Test responstid og hentepålitelighet

Hva du skal gjøre: mål status, Time to First Byte (TTFB), omdirigeringer, tidsavbrudd og responskonsistens under normale og relevante kravlerbrukeragenter. TTFB er intervallet fra forespørselen starter til den første responsbyten ankommer. Hvorfor det betyr noe: intermitterende 403-, 429-, 5xx-svar, lange omdirigeringskjeder eller trege opprinnelser gjør innhold upålitelig selv når et enkelt nettleserbesøk lykkes. Slik gjør du det: kjør det repeterbare utvalget definert i terskeltabellen fra mer enn ett nettverkssted når geografi spiller en rolle, avstem deretter feil med logger og Core Web Vitals. Verktøy: forespørselsmonitor, CDN-/opprinnelseslogger og AmICited Web Vitals. Ferdig når: kritiske URL-er oppfyller pålitelighets- og latenstersklene eller har en alvorlighetsgrad, årsak, eier og ny testdato.

10. Vurder WebMCP og handelsprotokoller der de skaper verdi

Hva du skal gjøre: test WebMCP og handelsberedskap kun der forretningsmodellen støtter agenthandlinger. WebMCP er en fremvoksende måte for et nettsted å eksponere kallbare verktøy, som søk, bestilling eller å legge til en vare i handlekurven. Agentisk handel dekker agent-assistert produktoppdagelse og transaksjoner, inkludert protokoller som ACP eller UCP. Hvorfor det betyr noe: lesbart innhold støtter svar; eksplisitte verktøy og handelsdata støtter pålitelig handling uten skjermskraping. Slik gjør du det: kartlegg verdifulle brukeroppgaver, inspiser deklarerte verktøy eller protokoller, valider inn- og utdatabeskrivelser, og verifiser bekreftelse, autentisering, tillatelse, pris, lagerbeholdning og feilatferd. Verktøy: AmICited WebMCP og Agentic Commerce-sjekker pluss et kontrollert testmiljø. Ferdig når: aktuelle kapabiliteter er oppdaget og sikkert testbare, eller sjekken er merket som ikke relevant med en godkjent forretningsmodellbegrunnelse og vurderingsutløser.

Verktøy i AmICited

Åpne https://app.amicited.com/accessibility for den samlede revisjonen og AI-tilgjengelighet og agentberedskap -funksjonsforklaringen. Produktet rapporterer uavhengige avlesninger heller enn å skjule ulike feiltyper innenfor én blandet skår.

1. Bruk sammendraget til å sjekke agenttilgjengelighetsskåren og registrer hver komponent, ikke bare overskriftsstatusen.
2. Bruk Robots.txt & Sitemaps til å sjekke robots.txt- og sidekartdekning , sammenlign deretter den angitte regelen med en levende kravlerstil-henting.
3. Bruk filgjennomgangen til å gå gjennom llms.txt og åpne hver opplistede destinasjon.
4. Bruk sidesjekkeren til å inspisere en sides tilgjengelighetstre for hver kritisk mal.
5. Bruk beredskapssjekkene til å sjekke WebMCP-beredskap og sjekke agentisk handelsberedskap når disse kapabilitetene gjelder.
6. Åpne https://app.amicited.com/audit/web-vitals for å sjekke Core Web Vitals og koble feltytelse med kravlerbetingede forespørselstester.

Beslutningsregler

Dette er operasjonelle akseptterskler, ikke påstander om rangeringsalgoritmer. Stram dem inn for inntektskritiske reiser eller regulert innhold, og registrer eventuelle alternativer før testing slik at resultatet ikke justeres i etterkant.

Skårer overstyrer aldri konkrete bevis. En tilgjengelighetsskår på 85 fraskriver ikke en umerket betalingsknapp, og en robots-tillatelse oppveier ikke en utfordringsside returnert til den virkelige forespørselen. «Ikke sjekket» er ukjent, ikke et godkjent og ikke et null.

Leveranse: agentberedskapsfunnsregisteret

Overlevere ett funnsregister, ikke en presentasjon og en separat AI-backlog. Legg hvert funn til P2-prioritetslisten med disse feltene:

ID og tittel:
Berørte URL-er/maler:
Sjekk og observert tilstand:
Forventet tilstand/terskel:
Bevis: tidsstempel, brukeragent, status, opptak eller loggreferanse
Forretningskonsekvens:
Alvorlighetsgrad: Kritisk | Alvorlig | Rådgivende
Anbefalt handling:
Eier og godkjenner:
Innsats og avhengighet:
Forfallsdato og ny testdato:
Politikkbeslutning, hvis relevant:
P5 målingspåvirkning:
Status: Åpen | Akseptert risiko | Fikset | Verifisert

Kritisk betyr at feilen hindrer pålitelig tilgang, vesentlig endrer uthentet betydning, eller tillater en usikker handling. Alvorlig betyr at tilgang eller forståelse er forringet, men en representativ klient kan fortsatt hente hovedinnholdet. Rådgivende betyr at en nyttig forbedring mangler bevis for nåværende feil. Akseptert risiko krever navngitt forretningseier, begrunnelse, berørt omfang, utløps- eller vurderingsdato, og en måte å oppdage endrede forhold på.

Dedupliser etter rotårsak: én CDN-utfordring som påvirker konvensjonelle og AI-kravlere er ett element med flere bevisposter.

Hva går galt

Å behandle fasen som valgfri. Sporingssporing og innholdsomskrivninger kan ikke kompensere for mislykket gjenfinning. Gjør P4 til et inngangsvilkår for en tolkbar grunnlinje.

Å blokkere som standard og i etterkant kalle det politikk. En regel uten beslutningseier, begrunnelse eller vurderingsdato er konfigurasjon, ikke politikk. Presenter avveiningen mellom oppdagelse og kontroll, og innhent en eksplisitt beslutning.

Å legge til llms.txt og erklære seg ferdig. Filen kan ikke overstyre robots-regler, CDN-blokkeringer, tom innledende HTML, villedende markering, svake avsnitt eller tidsavbrudd. Behandle den som én veiledning innenfor det bredere bevissettet.

Å teste kun en vennlig brukeragent eller startsiden. Kantkontroller varierer etter sti, geografi, frekvens og identitet. Test hver høyverdimal og brukeragent i politikkmatrisen.

Å forveksle utseende med uthentingsbarhet. En polert side kan skjule skjulte duplikater, meningsløse kontrollnavn eller et tomt ikke-skript-svar. Bevar kilde-, DOM-, tilgjengelighetstre- og uthentet tekstbevis separat.

Å behandle ukjent som feil eller suksess. Test tidsavbrudd og usjekkede kravlere på nytt; konverter aldri manglende bevis til en praktisk skår.

Å installere eksperimentelle agentkapabiliteter uten en brukscase. WebMCP eller handelsprotokoller bør eksponere verdifulle, tillatelsesstyrte handlinger. Å levere en usikker eller unøyaktig handling er verre enn å merke kapabiliteten som ikke relevant.

Overlevering til grunnlinjemåling

Grunnlinjemålingsfasen mottar den sammenslåtte prioritetslisten, testbevispakken, kravlerpolitikkposten, det representative URL-settet og beredskapsnotatet. P4-eieren må identifisere enhver begrensning som endrer tolkning: blokkerte kravlerfamilier, utilgjengelige maler, intermitterende regioner, manglende avsnitt eller en nylig fiks hvis effekt ennå ikke har spredd seg.

P5 kan fortsette når kritiske URL-er er bevisst tilgjengelige for kravlerfamiliene som inngår i målingen, gyldig primært innhold er uthentbart, og ingen uløst Kritisk funn vil gjøre en null- eller lavskår utolkbar. Den kan fortsette med merknader når en bevisst blokkering ekskluderer en kjent kravler eller et Alvorlig problem påvirker en avgrenset mal. Den bør vente når tilgangshensikt er ukjent, kritiske sider mislykkes i henting, eller uthentet innhold vesentlig motsier den synlige kilden.

Overleveringen er fullført når P5-eieren kan svare på tre spørsmål uten å gjenåpne revisjonen: hvilke agenter var tiltenkt tilgang, hvilke sider og fakta kunne de pålitelig hente, og hvilke kjente begrensninger må vises ved siden av grunnlinjen.

FAQ

Ofte stilte spørsmål