AI-tilgængelighedsrevision til agent-parathed

AI-systemer kan ikke citere, anbefale eller handle på indhold, de ikke pålideligt kan hente. Denne fase tester det fundament, før teamet måler synlighed eller bestiller indhold beregnet til svar-motorer.

Fase: P4, Trin A — Forstå. Tidsramme: 3–5 arbejdsdage for et typisk marketingwebsted; 5–10 for en stor e-handel, markedsplads eller stærkt client-renderet applikation. Ejer: den tekniske SEO-ansvarlige er ansvarlig, med teknik til at køre hente- og renderingstest, indholdsansvarlig til at gennemgå ekstraherbarhed og en forretnings- eller juridisk ansvarlig til at beslutte crawlerpolitik.

Hvorfor denne fase kommer her

En konventionel teknisk revision spørger, om søgemaskiner kan crawle, gengive, indeksere og rangere webstedet. Denne fase spørger, om AI-crawlere, genfindingssystemer og opgaveorienterede agenser kan nå og fortolke den samme nyttige information. De kan bruge forskellige brugeragenter, hentesti, gengivelsesevner, timeouts og ekstraktionsmetoder. En indekserbar side kan stadig returnere en tom skal, samtykkevæg, bot-udfordring eller usammenhængende fragmenter til en AI-klient.

En AI-tilgængelighedsrevision hører derfor sammen med den tekniske baselinerevision , ikke i slutningen af indholdsproduktionen. Client-side-rendering betyder, at JavaScript konstruerer vigtigt indhold efter den indledende HTML ankommer. Genfindingssystemer udfører muligvis ikke den kode, stopper før den er færdig, eller ekstraherer kun det indledende svar. Hvis produktnavnet, svaret, prisen, tilgængeligheden eller dokumentationen kun eksisterer efter JavaScript kører, kan senere indholdsoptimering ikke reparere adgangssvigtet.

Denne fase forbruger de verificerede konti, analyser, crawler-logfiler, sitemap-kilder, kritiske URL-sæt og ejerskabskort fra adgangs-, sporings- og datakilde-fasen . At køre den tidligere efterlader teamet ude af stand til at skelne et ægte fravær fra manglende adgang. At køre den efter baselinemåling forurener baselinen: nul citationer kan skyldes et utilgængeligt websted, ikke svagt indhold eller svag efterspørgsel.

At springe fasen over spilder arbejde: skribenter forbedrer passager en crawler aldrig modtager, udviklere tilføjer skema bag en udfordring, eller teamet forveksler en gyldig llms.txt med bred parathed. Adgang, ekstraktion, forståelse og handling er separate kapaciteter.

Inputs og outputs

Inputs gør test reproducerbare. Outputs danner en kontrakt med P5: måling begynder først, efter kendte adgangssvigt er rettet eller eksplicit accepteret.

Tjeklisten

Test det repræsentative URL-sæt, ikke kun startsiden, og bevar reproducerbar dokumentation.

1. Træf bevidst beslutning om crawler-adgang

Hvad skal gøres: kortlæg AI-crawlerregler i robots.txt , CDN-botkontroller, webapplikationsfirewalls, samtykkelag og oprindelseskonfiguration. Hvorfor det betyder noget: en robots-tilladelse er kun en præference; en edge-tjeneste kan stadig blokere forespørgslen, mens en utilsigtet wildcard-blokering ikke er politik. Sådan gøres det: sammenlign live-regler med politikmatrixen, hent repræsentative URL’er med relevante brugeragenter, og registrér afvejningen. Værktøj: AmICited Robots.txt & Sitemaps, en godkendt forespørgselsklient og CDN/origin-logfiler. Udført når: hver crawlerfamilie har en godkendt tilladelse, blokering eller betinget beslutning, og live-adfærd matcher den.

2. Sammenlign svaret uden JavaScript med den nyttige side

Hvad skal gøres: sammenlign indledende HTML med den normale browserside. Hvorfor det betyder noget: en genfindingsklient kører muligvis ikke scripts, der indsætter svar, tilbud, links eller produktdata. Sådan gøres det: test hver vigtig skabelon før hydrering, processen der tilknytter applikationsadfærd til server-HTML. Værktøj: en scriptløs browser eller HTTP-klient plus den gengivne side. Udført når: det indledende svar indeholder titlen, H1, primært indhold, kerne fakta og opdagelige links; enhver undtagelse har dokumentation og en ejer.

3. Test ekstraherbarhed fra gengivet DOM

Hvad skal gøres: ekstraher hovedindhold fra den gengivne Document Object Model (DOM), browserens strukturerede siderepræsentation, uden navigation, samtykketekst eller skjulte varianter. Hvorfor det betyder noget: at modtage tekst er ikke det samme som at identificere den korrekte tekst; skabelonstøj kan korrumpere genfinding. Sådan gøres det: sammenlign ekstraheret titel, svar, udgiver, datoer, fakta og links med den synlige kilde på tværs af lange, korte og kommercielle sider. Værktøj: browserinspektion, tekstekstraktion og sidekilde. Udført når: protokollen bevarer primær betydning og fakta uden visuel position eller udokumenterede selektorer.

4. Inspicér tilgængelighedstræet

Hvad skal gøres: gennemgå tilgængelighedstræet: roller, navne, tilstande, overskrifter, landmærker og kontroller. Hvorfor det betyder noget: semantik adskiller overskrifter fra dekoration, knapper fra ikoner og primært indhold fra navigation. Sådan gøres det: test kritiske skabeloner for én H1, ordnede overskrifter, navngivne kontroller, landmærker, beskrivende links og meningsfulde billedalternativer. Værktøj: AmICiteds tilgængelighedstræ-tjekker og browserinspektion. Udført når: scoren når tærsklen, ingen kritisk kontrol mangler et navn, og hovedområdet og næste handling kan identificeres.

5. Valider dækning og sandhed af strukturerede data

Hvad skal gøres: sammenlign synlige fakta med strukturerede data , standardiseret markup såsom Schema.org JSON-LD. Hvorfor det betyder noget: markup tydeliggør enheder, tilbud, forfatterskab og datoer, men unøjagtig markup kommunikerer den forkerte kendsgerning. Sådan gøres det: valider relevante skemaer og afstem navne, URL’er, priser, valuta, tilgængelighed, datoer, bedømmelser og identifikatorer med kildesystemer. Værktøj: validator, gengivet HTML og kildeprotokoller. Udført når: kritiske skabeloner har gyldigt relevant markup, værdier matcher synlige fakta, og enhver væsentlig advarsel er løst eller forklaret.

6. Gennemgå llms.txt som en guide, ikke en port

Hvad skal gøres: kontroller, om /llms.txt præcist opsummerer organisationen og linker til kanoniske offentlige ressourcer. Det er en foreslået almindelig tekst-guide, ikke adgangskontrol eller et garanteret rangeringssignal. Hvorfor det betyder noget: et kortfattet kort reducerer tvetydighed; et forældet vildleder agenser. Sådan gøres det: verificér status, Markdown-struktur, beskrivelse, destinationer, kanoniske URL’er og ejer. Værktøj: AmICiteds llms.txt-gennemgang og direkte hentning. Udført når: filen, hvis den bruges, ikke har nogen ødelagte/private links og har en vedligeholdelsesejer; fravær er et forbedringsfund, ikke et bevis på usynlighed.

7. Stikprøve selvstændige passager

Hvad skal gøres: gennemgå uafhængigt hentede definitioner, svar, fakta, sammenligninger, trin og begrænsninger. Hvorfor det betyder noget: genfinding kan adskille et afsnit fra dets overskrift; “det fungerer bedre for dem” mister da sit emne og sammenligning. Sådan gøres det: læs mindst 20 passager uden deres titel eller forrige afsnit. Værktøj: ekstraktionsoutput og redaktionel gennemgang. Udført når: hver navngiver sit emne, besvarer et identificerbart spørgsmål, bevarer betingelser eller enheder og undgår uløste henvisninger.

8. Bekræft kanonisk enheds klarhed

Hvad skal gøres: verificér, at webstedet angiver, hvem organisationen er, hvad den tilbyder, og hvordan dens mærker, produkter, personer, lokationer og profiler relaterer. En kanonisk enhed er den primære virkelige ting et navn refererer til. Hvorfor det betyder noget: inkonsistente navne, gamle logoer, modstridende beskrivelser og frakoblede profil-URL’er gør det let at flette to enheder eller splitte én enhed i flere. Sådan gøres det: sammenlign startsiden, Om-siden, kontaktoplysninger, strukturerede data, sociale profiler, forfattersider, juridisk navn og vigtige tredjepartsprofiler. Værktøj: enhedsfaktablad, gengivne sider og struktureret data-output. Udført når: ét godkendt faktablad løser officielt navn, aliaser, kanonisk URL, logo, beskrivelse, ejerskab, primære tilbud og samme-enhedsprofiler, med konflikter logget til korrektion.

9. Test svartid og hentepålidelighed

Hvad skal gøres: mål status, Time to First Byte (TTFB), omdirigeringer, timeouts og svarkonsistens under normale og relevante crawler-brugeragenter. TTFB er intervallet fra forespørgselsstart til det første svarbyte ankommer. Hvorfor det betyder noget: intermitterende 403’ere, 429’ere, 5xx-svar, lange omdirigeringskæder eller langsomme originer gør indhold upålideligt, selv når et enkelt browserbesøg lykkes. Sådan gøres det: kør den gentagelige stikprøve defineret i tærskeltabellen fra mere end én netværkslokation, når geografi betyder noget, afstem derefter fejl med logfiler og Core Web Vitals. Værktøj: forespørgselsmonitor, CDN/origin-logfiler og AmICited Web Vitals. Udført når: kritiske URL’er opfylder pålideligheds- og latenstærsklerne eller har en alvorlighedsgrad, årsag, ejer og gen testdato.

10. Vurder WebMCP og handelsprotokoller, hvor de skaber værdi

Hvad skal gøres: test WebMCP- og handelsparathed kun, hvor forretningsmodellen understøtter agenthandlinger. WebMCP er en fremvoksende måde for et websted at eksponere kaldbare værktøjer, såsom søgning, booking eller at lægge en vare i indkøbskurven. Agentisk handel dækker agentassisteret produktopdagelse og transaktioner, inklusive protokoller som ACP eller UCP. Hvorfor det betyder noget: læsbart indhold understøtter svar; eksplicitte værktøjer og handelsdata understøtter pålidelig handling uden screen scraping. Sådan gøres det: kortlæg værdifulde brugeropgaver, inspicér deklarerede værktøjer eller protokoller, valider input- og outputbeskrivelser, og verificér bekræftelse, autentificering, tilladelse, pris, lager- og fejlhåndtering. Værktøj: AmICiteds WebMCP- og Agentic Commerce-tjek plus et kontrolleret testmiljø. Udført når: relevante kapaciteter er opdaget og sikkert testbare, eller tjekket er markeret som ikke relevant med en godkendt forretningsmodel-begrundelse og gennemgangsudløser.

Værktøjer i AmICited

Åbn https://app.amicited.com/accessibility for den samlede revision og AI-tilgængelighed og agent-parathed -funktionsforklaringen. Produktet rapporterer uafhængige aflæsninger frem for at skjule forskellige fejltyper i én samlet score.

1. Brug resuméet til at tjekke Agenttilgængelighedsscoren og registrér hver komponent, ikke kun overskriftsstatus.
2. Brug Robots.txt & Sitemaps til at tjekke robots.txt og sitemap-dækning , sammenlign derefter den angivne regel med en live crawler-stil hentning.
3. Brug filgennemgangen til at gennemgå llms.txt og åbn hver listet destination.
4. Brug sidetjekkeren til at inspicere en sides tilgængelighedstræ for hver kritisk skabelon.
5. Brug parathedstjekkene til at tjekke WebMCP-parathed og tjekke agentisk handelsparathed , når disse kapaciteter er relevante.
6. Åbn https://app.amicited.com/audit/web-vitals for at tjekke Core Web Vitals og forbind feltperformance med crawler-betingede forespørgselstest.

Beslutningsregler

Disse er operationelle accepttærskler, ikke påstande om rangeringsalgoritmer. Stram dem for indtægtskritiske forløb eller reguleret indhold, og registrér ethvert alternativ før test, så resultatet ikke justeres bagefter.

Scores tilsidesætter aldrig konkret dokumentation. En tilgængelighedsscore på 85 undskylder ikke en umærket betalingsknap, og en robots-tilladelse opvejer ikke en udfordringsside returneret til den reelle forespørgsel. “Ikke tjekket” er ukendt, ikke en bestået og ikke et nul.

Leverance: agent-paratheds fundregister

Overgiv ét fundregister, ikke en præsentation og en separat AI-backlog. Tilføj hvert fund til P2-prioritetslisten med disse felter:

ID og titel:
Berørte URL'er/skabeloner:
Tjek og observeret tilstand:
Forventet tilstand/tærskel:
Dokumentation: tidsstempel, brugeragent, status, optagelse eller logreference
Forretningsmæssig konsekvens:
Alvorlighedsgrad: Kritisk | Betydelig | Rådgivende
Anbefalet handling:
Ejer og godkender:
Indsats og afhængighed:
Deadline og gen testdato:
Politikbeslutning, hvis relevant:
P5 målingspåvirkning:
Status: Åben | Accepteret risiko | Ret | Verificeret

Kritisk betyder, at fejlen forhindrer pålidelig adgang, væsentligt ændrer ekstraheret betydning eller tillader en usikker handling. Betydelig betyder, at adgang eller forståelse er forringet, men en repræsentativ klient stadig kan genfinde hovedindholdet. Rådgivende betyder, at en nyttig forbedring mangler dokumentation for nuværende fejl. Accepteret risiko kræver den navngivne forretningsejer, begrundelse, berørt omfang, udløbs- eller gennemgangsdato og en måde at opdage ændrede forhold på.

Deduplicér efter rodårsag: én CDN-udfordring, der påvirker konventionelle og AI-crawlere, er ét element med flere dokumentationsprotokoller.

Hvad går galt

At behandle fasen som valgfri. Prompt-sporing og indholdsomskrivninger kan ikke kompensere for mislykket genfinding. Gør P4 til en adgangsbetingelse for en fortolkbar baseline.

At blokere som standard og efterfølgende kalde det politik. En regel uden beslutningsejer, begrundelse eller gennemgangsdato er konfiguration, ikke politik. Præsentér afvejningen mellem opdagelse og kontrol, og opnå en eksplicit beslutning.

At tilføje llms.txt og erklære opgaven fuldført. Filen kan ikke tilsidesætte robots-regler, CDN-blokeringer, tom indledende HTML, vildledende markup, svage passager eller timeouts. Behandl den som én guide inden for det bredere dokumentationssæt.

At teste kun en venlig brugeragent eller startsiden. Edge-kontroller varierer efter sti, geografi, hastighed og identitet. Test hver højværdi-skabelon og brugeragent i politikmatrixen.

At forveksle udseende med ekstraherbarhed. En poleret side kan eksponere skjulte dubletter, meningsløse kontrolnavne eller et blankt script-frit svar. Bevar kilde-, DOM-, tilgængelighedstræ- og ekstraheret tekst-dokumentation separat.

At behandle ukendt som fejl eller succes. Gen test timeouts og ikke-tjekkede crawlere; konverter aldrig manglende dokumentation til en bekvem score.

At installere eksperimentelle agentkapaciteter uden en use case. WebMCP- eller handelsprotokoller bør eksponere værdifulde, tilladelsesgivne handlinger. At levere en usikker eller unøjagtig handling er værre end at markere kapaciteten som ikke relevant.

Overlevering til baselinemåling

Baselinemålingsfasen modtager den flettede prioritetsliste, testdokumentationspakke, crawlerpolitikprotokol, repræsentativt URL-sæt og parathedsnote. P4-ejeren må identificere enhver begrænsning, der ændrer fortolkning: blokerede crawlerfamilier, utilgængelige skabeloner, intermitterende regioner, manglende passager eller en nylig rettelse, hvis effekt ikke har forplantet sig.

P5 kan fortsætte, når kritiske URL’er er bevidst tilgængelige for de crawlerfamilier, der er inkluderet i målingen, gyldigt primært indhold er ekstraherbart, og intet uløst Kritisk fund ville gøre en nul- eller lavscore ufortolkelig. Den kan fortsætte med annotationer, når en bevidst blokering udelukker en kendt crawler, eller et Betydeligt problem påvirker en afgrænset skabelon. Den bør vente, når adgangshensigt er ukendt, kritiske sider mislykkes hentning, eller ekstraheret indhold væsentligt modsiger den synlige kilde.

Overleveringen er fuldført, når P5-ejeren kan besvare tre spørgsmål uden at genåbne revisionen: hvilke agenser der var tiltænkt adgang, hvilke sider og fakta de pålideligt kunne hente, og hvilke kendte begrænsninger der skal fremgå ved siden af baselinen.

FAQ

Ofte stillede spørgsmål