AI-tillgänglighetsgranskning för agentberedskap

AI-system kan inte citera, rekommendera eller agera på innehåll som de inte tillförlitligt kan hämta. Denna fas testar den grunden innan teamet mäter synlighet eller beställer innehåll avsett för svarsmotorer.

Fas: P4, Steg A — Förstå. Tidsram: 3–5 arbetsdagar för en typisk marknadswebbplats; 5–10 för en stor e-handelsplats, marknadsplats eller tungt klientrenderad applikation. Ägare: den tekniska SEO-ansvarige är ansvarig, med utveckling som kör hämtnings- och renderingstester, innehållsansvarig som granskar extraherbarhet och en verksamhets- eller juridisk ägare som beslutar om genomläsarpolicy.

Varför denna fas kommer här

En konventionell teknisk granskning undersöker om sökmotorer kan genomsöka, rendera, indexera och ranka webbplatsen. Denna fas undersöker om AI-genomläsare, upphämtningssystem och uppgiftsorienterade agenter kan nå och tolka samma användbara information. De kan använda olika användaragenter, hämtningsvägar, renderingsförmågor, tidsgränser och extraheringsmetoder. En indexerbar sida kan fortfarande returnera ett tomt skal, samtyckesvägg, botutmaning eller frånkopplade fragment till en AI-klient.

En AI-tillgänglighetsgranskning hör därför hemma tillsammans med den tekniska baslinjegranskningen , inte i slutet av innehållsproduktionen. Klientrendering innebär att JavaScript konstruerar viktigt innehåll efter att den initiala HTML-koden anlänt. Upphämtningssystem kanske inte kör den koden, kan stanna innan den är klar eller extrahera endast det initiala svaret. Om produktnamn, svar, pris, tillgänglighet eller bevis endast finns efter att JavaScript körts, kan senare innehållsoptimering inte reparera åtkomstfelet.

Denna fas använder verifierade konton, analysverktyg, genomläsarloggar, webbplatskartkällor, kritisk URL-uppsättning och ägarskapskarta från fasen åtkomst, spårning och datakällor . Att köra den tidigare gör att teamet inte kan skilja en genuin frånvaro från bristande åtkomst. Att köra den efter baslinjemätning förorenar baslinjen: noll citeringar kan bero på en otillgänglig webbplats, inte svagt innehåll eller låg efterfrågan.

Att hoppa över fasen är bortkastat arbete: skribenter förbättrar passager som en genomläsare aldrig får, utvecklare lägger till schema bakom en utmaning, eller teamet misstar en giltig llms.txt för webbplatsomfattande beredskap. Åtkomst, extrahering, förståelse och handling är separata förmågor.

Indata och utdata

Indata gör testerna reproducerbara. Utdata utgör ett kontrakt med P5: mätning påbörjas först efter att kända åtkomstfel är åtgärdade eller uttryckligen accepterade.

Checklistan

Testa den representativa URL-uppsättningen, inte bara startsidan, och bevara reproducerbara bevis.

1. Beslut om genomläsaråtkomst medvetet

Vad som ska göras: inventera AI-genomläsarregler i robots.txt , CDN-botkontroller, webbapplikationsbrandväggar, samtyckeslager och ursprungskonfiguration. Varför det är viktigt: en robots-tillåtelse är bara en preferens; en edge-tjänst kan fortfarande blockera begäran, medan ett oavsiktligt wildcard-block inte är policy. Hur man gör: jämför live-regler med policymatrisen, hämta representativa URL:er med tillämpliga användaragenter och dokumentera avvägningen. Verktyg: AmICited Robots.txt & Sitemaps, en godkänd begäransklient och CDN/ursprungsloggar. Klart när: varje genomläsarfamilj har ett godkänt tillåt-, block- eller villkorligt beslut och live-beteendet matchar det.

2. Jämför det icke-JavaScript-svaret med den användbara sidan

Vad som ska göras: jämför initial HTML med den normala webbläsarsidan. Varför det är viktigt: en upphämtningsklient kanske inte kör skript som infogar svar, erbjudanden, länkar eller produktdata. Hur man gör: testa varje viktig mall före hydrering, processen som kopplar applikationsbeteende till server-HTML. Verktyg: en skriptlös webbläsare eller HTTP-klient plus den renderade sidan. Klart när: det initiala svaret innehåller titeln, H1, primärt innehåll, kärnfakta och upptäckbara länkar; varje undantag har bevis och en ägare.

3. Testa extraherbarhet från renderad DOM

Vad som ska göras: extrahera huvudinnehåll från den renderade Document Object Model (DOM), webbläsarens strukturerade sidrepresentation, utan navigering, samtyckestext eller dolda varianter. Varför det är viktigt: att ta emot text är inte samma sak som att identifiera rätt text; mallbrus kan förstöra upphämtning. Hur man gör: jämför extraherad titel, svar, utgivare, datum, fakta och länkar med den synliga källan över långa, glesa och kommersiella sidor. Verktyg: webbläsarinspektion, textextrahering och sidkälla. Klart när: posten bevarar primär innebörd och fakta utan visuell position eller odokumenterade selektorer.

4. Inspektera tillgänglighetsträdet

Vad som ska göras: granska tillgänglighetsträdet: roller, namn, tillstånd, rubriker, landmärken och kontroller. Varför det är viktigt: semantik skiljer rubriker från dekoration, knappar från ikoner och primärt innehåll från navigering. Hur man gör: testa kritiska mallar för en H1, ordnade rubriker, namngivna kontroller, landmärken, beskrivande länkar och meningsfulla bildalternativ. Verktyg: AmICited tillgänglighetsträdkontroll och webbläsarinspektion. Klart när: poängen når tröskelvärdet, ingen kritisk kontroll saknar ett namn, och huvudregionen samt nästa åtgärd är identifierbara.

5. Validera strukturerad datatäckning och sanningshalt

Vad som ska göras: jämför synliga fakta med strukturerad data , standardiserad märkning såsom Schema.org JSON-LD. Varför det är viktigt: märkning förtydligar entiteter, erbjudanden, författarskap och datum, men felaktig märkning förmedlar fel fakta. Hur man gör: validera tillämpliga scheman och stäm av namn, URL:er, priser, valuta, tillgänglighet, datum, betyg och identifierare med källsystem. Verktyg: validator, renderad HTML och källposter. Klart när: kritiska mallar har giltig tillämplig märkning, värden matchar synliga fakta och varje väsentlig varning är löst eller förklarad.

6. Granska llms.txt som en guide, inte en grind

Vad som ska göras: kontrollera om /llms.txt korrekt sammanfattar organisationen och länkar till kanoniska offentliga resurser. Det är en föreslagen klartextguide, inte åtkomstkontroll eller en garanterad rankningssignal. Varför det är viktigt: en koncis karta minskar tvetydighet; en inaktuell leder agenter fel. Hur man gör: verifiera status, Markdown-struktur, beskrivning, destinationer, kanoniska URL:er och ägare. Verktyg: AmICited llms.txt-granskning och direkt hämtning. Klart när: filen, om den används, inte har trasiga/privata länkar och en underhållsägare; frånvaro är ett förbättringsfynd, inte bevis på osynlighet.

7. Sampla fristående passager

Vad som ska göras: granska självständigt hämtade definitioner, svar, fakta, jämförelser, steg och begränsningar. Varför det är viktigt: upphämtning kan separera ett stycke från dess rubrik; “det fungerar bättre för dem” förlorar då sitt ämne och sin jämförelse. Hur man gör: läs minst 20 passager utan deras titel eller föregående stycke. Verktyg: extraheringsutdata och redaktionell granskning. Klart när: varje passage namnger sitt ämne, besvarar en identifierbar fråga, bevarar villkor eller enheter och undviker oupplösta referenser.

8. Bekräfta kanonisk entitetstyclighet

Vad som ska göras: verifiera att webbplatsen anger vem organisationen är, vad den erbjuder och hur dess varumärken, produkter, personer, platser och profiler förhåller sig till varandra. En kanonisk entitet är den primära verklighetssak som ett namn refererar till. Varför det är viktigt: inkonsekventa namn, gamla logotyper, motsägande beskrivningar och frånkopplade profil-URL:er gör det lätt att slå samman två entiteter eller dela en entitet i flera. Hur man gör: jämför startsidan, Om-sidan, kontaktuppgifter, strukturerad data, sociala profiler, författarsidor, juridiskt namn och viktiga tredjepartsprofiler. Verktyg: entitetsfaktablad, renderade sidor och strukturerad datautdata. Klart när: ett godkänt faktablad löser officiellt namn, alias, kanonisk URL, logotyp, beskrivning, ägarskap, primära erbjudanden och samma-entitetsprofiler, med konflikter loggade för korrigering.

9. Testa svarstid och hämtningstillförlitlighet

Vad som ska göras: mät status, Time to First Byte (TTFB), omdirigeringar, tidsgränser och svarskonsistens under normala och relevanta genomläsaranvändaragenter. TTFB är intervallet från begäran start tills den första svarsbyten anländer. Varför det är viktigt: intermittent 403, 429, 5xx-svar, långa omdirigeringskedjor eller långsamma ursprung gör innehåll opålitligt även när ett enskilt webbläsarbesök lyckas. Hur man gör: kör det repeterbara urvalet som definieras i tröskelvärdestabellen från mer än en nätverksplats när geografi har betydelse, stäm sedan av misslyckanden med loggar och Core Web Vitals. Verktyg: begäransmonitor, CDN/ursprungsloggar och AmICited Web Vitals. Klart när: kritiska URL:er uppfyller tillförlitlighets- och latenströskelvärdena eller har en allvarlighetsgrad, orsak, ägare och omtestningsdatum.

10. Utvärdera WebMCP och e-handelsprotokoll där de skapar värde

Vad som ska göras: testa WebMCP och e-handelsberedskap endast där affärsmodellen stöder agentåtgärder. WebMCP är ett framväxande sätt för en webbplats att exponera anropsbara verktyg, såsom sökning, bokning eller att lägga en artikel i en varukorg. Agentisk e-handel omfattar agentassisterad produktupptäckt och transaktioner, inklusive protokoll som ACP eller UCP. Varför det är viktigt: läsbart innehåll stöder svar; explicita verktyg och e-handelsdata stöder tillförlitlig handling utan skärmskrapning. Hur man gör: kartlägg värdefulla användaruppgifter, inspektera deklarerade verktyg eller protokoll, validera in- och utdatabeskrivningar, och verifiera bekräftelse, autentisering, behörighet, pris, lager och felbeteende. Verktyg: AmICited WebMCP och agentisk e-handelskontroll plus en kontrollerad testmiljö. Klart när: tillämpliga förmågor upptäcks och är säkert testbara, eller kontrollen markeras som ej tillämplig med en godkänd affärsmodellsmotivering och granskningsutlösare.

Verktyg i AmICited

Öppna https://app.amicited.com/accessibility för den konsoliderade granskningen och AI-tillgänglighet och agentberedskap -funktionsförklaringen. Produkten rapporterar oberoende avläsningar snarare än att dölja olika feltyper i en sammanblandad poäng.

1. Använd sammanfattningen för att kontrollera agenttillgänglighetspoängen och dokumentera varje komponent, inte bara rubriktillståndet.
2. Använd Robots.txt & Sitemaps för att kontrollera robots.txt- och webbplatskartetäckning , jämför sedan den angivna regeln med en live-genomläsarstyle-hämtning.
3. Använd filgranskningen för att granska llms.txt och öppna varje listad destination.
4. Använd sidkontrollen för att inspektera en sidas tillgänglighetsträd för varje kritisk mall.
5. Använd beredskapskontrollerna för att kontrollera WebMCP-beredskap och kontrollera agentisk e-handelsberedskap när dessa förmågor är tillämpliga.
6. Öppna https://app.amicited.com/audit/web-vitals för att kontrollera Core Web Vitals och koppla fältprestanda med begärantester under genomläsarförhållanden.

Beslutsregler

Dessa är operativa acceptanströskelvärden, inte påståenden om rankningsalgoritmer. Skärp dem för intäktskritiska resor eller reglerat innehåll, och dokumentera eventuella alternativ före testning så att resultatet inte justeras i efterhand.

Poäng åsidosätter aldrig konkreta bevis. En tillgänglighetspoäng på 85 ursäktar inte en oetiketterad utcheckningsknapp, och en robots-tillåtelse uppväger inte en utmaningssida som returneras till den verkliga förfrågan. “Ej kontrollerat” är okänt, varken godkänt eller noll.

Leverans: registret över agentberedskapsfynd

Lämna över ett register över fynd, inte en presentation och en separat AI-backlog. Lägg till varje fynd i P2 prioriteringslistan med dessa fält:

ID och titel:
Berörda URL:er/mallar:
Kontroll och observerat tillstånd:
Förväntat tillstånd/tröskelvärde:
Bevis: tidsstämpel, användaragent, status, skärmdump eller loggreferens
Affärskonsekvens:
Allvarlighetsgrad: Kritisk | Allvarlig | Rådgivande
Rekommenderad åtgärd:
Ägare och godkännare:
Insats och beroende:
Slutdatum och omtestningsdatum:
Policydokumentation, om relevant:
P5 mätningspåverkan:
Status: Öppen | Accepterad risk | Åtgärdad | Verifierad

Kritisk innebär att felet förhindrar tillförlitlig åtkomst, väsentligt ändrar extraherad innebörd eller tillåter en osäker handling. Allvarlig innebär att åtkomst eller förståelse är försämrad men en representativ klient fortfarande kan hämta huvudinnehållet. Rådgivande innebär en användbar förbättring som saknar bevis för nuvarande fel. Accepterad risk kräver namngiven verksamhetsägare, motivering, påverkat omfång, utgångs- eller granskningsdatum och ett sätt att upptäcka ändrade förhållanden.

Deduplicera efter grundorsak: en CDN-utmaning som påverkar konventionella och AI-genomläsare är en post med flera bevisposter.

Vad kan gå fel

Att behandla fasen som valfri. Spårning av prompts och innehållsomskrivningar kan inte kompensera för misslyckad upphämtning. Gör P4 till ett ingångsvillkor för en tolkningsbar baslinje.

Att blockera som standard och retroaktivt kalla det policy. En regel utan beslutsägare, motivering eller granskningsdatum är konfiguration, inte policy. Presentera avvägningen mellan upptäckbarhet och kontroll och erhåll ett explicit beslut.

Att lägga till llms.txt och förklara sig färdig. Filen kan inte åsidosätta robots-regler, CDN-block, tom initial HTML, vilseledande märkning, svaga passager eller tidsgränser. Behandla den som en guide inom det bredare bevisunderlaget.

Att endast testa en välvillig användaragent eller startsidan. Edge-kontroller varierar beroende på sökväg, geografi, takt och identitet. Testa varje högvärdig mall och användaragent i policymatrisen.

Att förväxla utseende med extraherbarhet. En polerad sida kan exponera dolda dubbletter, meningslösa kontrollnamn eller ett blankt skriptlöst svar. Bevara källa, DOM, tillgänglighetsträd och extraherad text separat.

Att behandla okänt som misslyckande eller framgång. Testa om tidsgränser och okontrollerade genomläsare; omvandla aldrig saknade bevis till en bekväm poäng.

Att installera experimentella agentförmågor utan användningsfall. WebMCP eller e-handelsprotokoll bör exponera värdefulla, behörighetsstyrda handlingar. Att lansera en osäker eller felaktig handling är värre än att markera förmågan som ej tillämplig.

Överlämning till baslinjemätning

Baslinjemätningsfasen tar emot den sammanslagna prioriteringslistan, testbevispaketet, genomläsarpolicyposten, den representativa URL-uppsättningen och beredskapsanteckningen. P4-ägaren måste identifiera alla begränsningar som ändrar tolkningen: blockerade genomläsarfamiljer, otillgängliga mallar, intermittenta regioner, saknade passager eller en nyligen genomförd åtgärd vars effekt inte har spridits.

P5 får fortsätta när kritiska URL:er är avsiktligt tillgängliga för de genomläsarfamiljer som ingår i mätningen, giltigt primärt innehåll är extraherbart och inget olöst kritiskt fynd skulle göra en noll- eller lågpoäng otolkbar. Det får fortsätta med kommentarer när ett medvetet block utesluter en känd genomläsare eller ett allvarligt problem påverkar en avgränsad mall. Det bör vänta när åtkomstavsikten är okänd, kritiska sidor misslyckas med hämtning, eller extraherat innehåll väsentligt motsäger den synliga källan.

Överlämningen är fullständig när P5-ägaren kan svara på tre frågor utan att öppna granskningen igen: vilka agenter som var avsedda att ha åtkomst, vilka sidor och fakta de tillförlitligt kunde hämta, och vilka kända begränsningar som måste visas tillsammans med baslinjen.

FAQ

Vanliga frågor