GEO- og AEO-beredskapsliste

Denne sjekklisten avgjør om et nettsted er teknisk tilgjengelig, enkelt å hente ut, utvetydig om sine enheter og målbart til stede i AI-svar. Generativ motoroptimalisering (GEO) øker sannsynligheten for at generative systemer henter, bruker og siterer en kilde. Svarmotoroptimalisering (AEO) gjør en side i stand til å levere et direkte svar. Ingen av delene er et løfte om inkludering: beredskap fjerner unngåelige hindringer, mens prompt- og siteringsdata viser hva som faktisk skjedde.

Sjekkliste: GEO- og AEO-beredskap. Tidsramme: 3–5 arbeidsdager for en representativ revisjon og utbedringsplan, etterfulgt av et minimum på 28 dagers målevindu. Eier: SEO-ansvarlig, med engineering ansvarlig for tilgang og gjengivelse, redaksjonell for avsnittskvalitet, og en analytiker for prompt- og siteringsmåling.

Test startsiden, én side fra hver inntektskritiske mal, de ti sidene som er kartlagt til prioriterte prompter, og sider som allerede mottar eller uventet mangler siteringer. Dokumenter hver URL for ny testing.

Hvorfor denne sjekklisten, og hvorfor her

Denne porten forbruker revisjonen av AI-tilgjengelighet og agentberedskap , som identifiserer kravle- og uthentingsbegrensninger; baselinemåling , som fryser tilstanden før endring; og nøkkelord- og prompt-forskning , som definerer de faktiske spørsmålene og motorene som skal testes. Den trenger også den godkjente sideoversikten, enhetsfakta, skjemaeierskap, server- eller CDN-tilgang, og en utgivelseslogg.

Rekkefølgen betyr noe fordi tilgjengelighet, svarkvalitet og synlighet er forskjellige lag. Prompt-sporing før kravlekontroll kan rapportere at en merkevare mangler uten å forklare om årsaken er tilgang, relevans, autoritet eller bare forsinkelse i henting. Omskriving av avsnitt før bekreftelse av forretningspolicy kan eksponere innhold organisasjonen hadde til hensikt å holde tilbake. Legge til skjema før de synlige faktaene og enhetsmodellen er stabile, kan gjøre en selvmotsigelse maskinlesbar i stedet for å rette den.

Hvis denne sjekklisten hoppes over, har team en tendens til å hevde at en side er «AI-optimalisert» fordi den har korte avsnitt, FAQ-skjema eller en llms.txt-fil. Dette er implementeringsfakta, ikke resultater. Kontrakten her er strengere: angi hva kravlere har tilgang til, bevis at representative sider kan hentes og forstås, og sammenlign deretter fullførte prompt-kjøringer og kildesiteringer mot en datert baseline.

Inndata og utdata

Utdatene er kontrakten med publisering, engineering og måling. «Klar» uten et URL-sett, bevis, terskler og observasjonsdatoer kan ikke reproduseres.

Sjekklisten

Hvert element avsluttes med en Ferdig når-betingelse. Vedlegg responsen, gjengitt uttrekk, validatorresultat, skjermbilde eller rapportrad i stedet for å registrere en ubegrunnet grønn hake.

1. Ta en eksplisitt beslutning om kravletilgang

• Hva: Bestem hvilke AI-brukeragenter som får kravle hvilke offentlige stier. En brukeragent er identifikatoren en kravle presenterer i forespørselen; det er et signal, ikke sterk autentisering.
• Hvorfor: Å tillate en kravle kan forbedre oppdagelse, men kan også muliggjøre gjenbruk, øke serverbelastning, komme i konflikt med lisensiering, eller eksponere materiale som bare var offentlig ved et uhell. Blokkering kan være en gyldig kommersiell beslutning, men må ikke forveksles med en SEO-feil.
• Hvordan: List relevante kravlefamilier og grupper dem etter formål: søk- eller svarhenting, modelltrening, og generelle nettarkiver. For hver, dokumenter tillat, blokker eller stibegrenset tilgang; forretningsbegrunnelse; godkjenner; og revisjonsdato. Sammenlign den beslutningen med robots.txt , CDN-regler, brannmurregler for webapplikasjoner, autentisering og opprinnelsesoppførsel.
• Verktøy: Policyregister, robotparser, CDN- og brannmurkonfigurasjon, serverlogger, og juridisk- eller innholdseier-gjennomgang.
• Ferdig når: 100 % av kravlefamiliene i omfang har en eier-godkjent beslutning; hver bevisst blokkering er merket som policy; og ingen aktive regler motsier den registrerte beslutningen på det representative URL-settet.

2. Test tilgjengelighet som kravleren, ikke som en nettleserøkt

• Hva: Verifiser at tillatte kravlere mottar det kanoniske innholdet med en vellykket respons og uten utfordring, innlogging, samtykkevegg eller tom klient-side-skal.
• Hvorfor: En tillatende robotregel beviser ikke levering. En CDN kan returnere 403, 429, en CAPTCHA eller annen HTML til en ikke-nettleser-forespørsel mens en innlogget ansatt ser en normal side.
• Hvordan: Hent hver representativ URL med den relevante brukeragentstrengen fra en ren forespørsel. Dokumenter status, omdirigeringer, responstid, innholdstype, kanonisk, indeksdirektiver, endelig brødtekststørrelse, og om hovedsvaret vises i den returnerte eller gjengitte HTML-en. Sammenlign bot- og vanlig nettleser-respons for vesentlige forskjeller.
• Verktøy: AI-tilgjengelighet og agentberedskap i AmICited, respons- og header-inspeksjon, serverlogger, og en gjengitt HTML-sammenligning.
• Ferdig når: Hver bevisst tillatt test returnerer forventet kanonisk side med 200-status; omdirigeringskjeder inneholder maksimalt ett hopp; ingen tillatt forespørsel mottar 401, 403, 429, utfordrings-HTML eller et tomt hovedområde; og forskjeller har en dokumentert, ikke-villedende årsak.

3. Revider llms.txt som et kart, ikke en magisk bryter

• Hva: Gå gjennom /llms.txt, en fremvoksende frivillig tekstfil ment å peke språkmodellverktøy mot nyttige nettstedsressurser. Behandle det som veiledning, ikke som tilgangskontroll eller garantert rangering signal.
• Hvorfor: Et konsist kart kan hjelpe en agent med å finne kanonisk dokumentasjon, men en utdatert fil kan sende den til omdirigeringer, duplikatsider eller utgåtte påstander. Dens tilstedeværelse kan ikke kompensere for blokkert kravling eller svakt innhold.
• Hvordan: Hvis bedriften tar i bruk filen, hold tittel og beskrivelse tydelige, len kun til kanoniske offentlige URL-er, grupper ressurser etter reelle brukerformål, og foretrekk holdbare sider fremfor en dump av hele sitemapet. Test hver oppførte URL. Hvis bedriften velger å ikke publisere den, dokumenter den beslutningen uten å stryke hele beredskapsporten.
• Verktøy: AmICited llms.txt-sjekk, lenkesjekker, URL-oversikt, og innholdseier-gjennomgang.
• Ferdig når: Beslutningen om å publisere eller utelate er dokumentert; hvis til stede, returnerer filen 200 som ren tekst, inneholder null ødelagte, omdirigerte, blokkerte, dupliserte eller ikke-kanoniske lenker, og har en navngitt eier og revisjonsdato.

4. Gjør prioriterte avsnitt selvstendige og fremtunge

• Hva: Gi hvert prioriterte spørsmål et selvstendig avsnitt: en seksjon som angir svaret tidlig og inkluderer nok substantiver, omfang, betingelser og bevis til å forbli nøyaktig når det hentes ut fra omkringliggende tekst.
• Hvorfor: Uthentingssystemer velger ofte et avsnitt snarere enn hele siden. «Det kommer an på» eller «denne metoden» mister mening når det løsrives fra overskriften; et forsinket svar tvinger systemet til å sette sammen fakta fra flere seksjoner og øker sjansen for utelatelse eller forvrengning.
• Hvordan: Plasser det direkte svaret i de første én eller to setningene under den samsvarende overskriften. Navngi enheten og emnet i stedet for å stole på pronomen. Følg opp med kvalifikasjoner, bevis, eksempler og unntak. Hold nødvendig kontekst sammen med påstanden; ikke reduser komplekse juridiske, medisinske, finansielle eller sikkerhetsråd til et ubetinget utdrag.
• Verktøy: Prompt-til-seksjon-kart, redaksjonell uttrekkstest, ren-tekst-leser, og fagfellevurdering.
• Ferdig når: Hver av de ti prioriterte promptene kartlegger til én kanonisk side og én svarseksjon; svaret vises innen de første 80 ordene i den seksjonen; og en anmelder kan kopiere avsnittet alene uten å miste emnet, omfanget, betingelsen eller beviskilden.

5. Bruk uttrekkbare formater for oppgaven

• Hva: Fremstill sekvenser som nummererte trinn, alternativer som sammenligningstabeller, spesifikasjoner som merkede verdier, og korte sett som lister. Hold de samme faktaene tilgjengelige i meningsfull HTML, ikke bare i bilder, video, lerret eller interaksjons-avhengige faner.
• Hvorfor: Format koder relasjoner. Et prosa-avsnitt kan skjule hvilken verdi som tilhører hvilket produkt, mens en tabell eksponerer sammenligningen. Innhold som bare finnes etter et klikk eller inne i et bilde kan bli oversett eller løsrevet fra sine etiketter.
• Hvordan: Inspiser dokumentdisposisjonen og rå-HTML-en. Gi tabeller overskrifter, lister én idé per element, figurer bildetekster, bilder nyttig alternativ tekst, og interaktivt innhold et server-gjengitt sammendrag. Sørg for at skjulte faner ikke inneholder den eneste kopien av et kritisk svar.
• Verktøy: Tilgjengelighetstre, HTML-kildeinspeksjon, tastatur-only-gjennomgang, og en JavaScript-deaktivert eller ren-tekst-gjengivelse.
• Ferdig når: 100 % av kritiske fakta forblir tilgjengelige og korrekt merket uten interaksjon; hver sammenligning har eksplisitte rad- og kolonneetiketter; hver sekvens har ordnede trinn; og intet prioritert svar finnes kun i media eller en klient-rendret widget.

6. Juster synlige fakta, enheter og strukturerte data

• Hva: Avklar personene, organisasjonene, produktene, stedene og relasjonene på siden, uttrykk deretter understøttede fakta gjennom gyldige strukturerte data . En enhet er en distinkt, virkelig ting som kan navngis og skilles fra lignende ting.
• Hvorfor: Tvetydige navn og motstridende identifikatorer gjør attribusjon upålitelig. Skjemamarkering kan redusere tvetydighet, men markering som er bredere, nyere eller mer salgsfremmende enn den synlige siden skaper konflikt snarere enn tillit.
• Hvordan: Bruk ett kanonisk navn, URL, logo og stabilt identifikatorsett for organisasjonen. Koble forfattere og anmeldere til ekte profilsider. Velg den mest spesifikke anvendelige skjematypen, inkluder kun synlige og verifiserte fakta, og koble relaterte noder med konsistente identifikatorer. Valider syntaks og sammenlign hver vesentlig egenskap med den gjengitte siden.
• Verktøy: Enhetsregister, JSON-LD-inspeksjon, Schema.org-validator, rich-result-testing der det er aktuelt, og mal-nivå QA.
• Ferdig når: Hver representative side har én utvetydig primærenhet; null vesentlige skjemaegenskaper motsier eller overskrider synlige påstander; null syntaksfeil gjenstår; og hver inntektskritiske mal har en godkjent skjemaeier og testoppsett.

7. Beskytt siteringskvalitet med kilder og ferskhet

• Hva: Underbygg påstander som krever bevis med identifiserbare primære eller autoritative kilder, og vis når siden ble vesentlig gjennomgått.
• Hvorfor: Uttrekkbarhet uten bevis kan gjøre en uunderbygget påstand lettere å gjenta. Utdaterte priser, retningslinjer, benchmarks og produktkapasiteter er spesielt risikable fordi et flytende avsnitt fortsatt kan se oppdatert ut.
• Hvordan: Spor beslutningsrelevante påstander til kilder, plasser siteringer nær påstanden, bruk beskrivende ankertekst, og oppgi den relevante måle- eller ikrafttredelsesdatoen. Fjern dødt bevis eller omskriv påstanden. Endre en «oppdatert»-dato kun etter at en reell gjennomgang endrer eller revaliderer innholdet.
• Verktøy: Påstands-kilde-register, lenkesjekker, innholdsoversikt, og fagområde-godkjenning.
• Ferdig når: 100 % av høyrisiko- og beslutningsrelevante påstander har en aktuell kilde eller navngitt ansvarlig eier; null siteringer fører til døde eller urelaterte sider; og den viste revisjonsdatoen samsvarer med den registrerte revisjonen.

8. Frys et representativt promptsett før utgivelse

• Hva: Etabler et gjentakbart sett med kjøperspørsmål som brukes til å måle omtaler, siteringsrangering, siterte URL-er og leverandørforskjeller før og etter endringer.
• Hvorfor: Å endre prompter etter distribusjon kan skape tilsynelatende forbedring. Ett håndplukket svar er en anekdote fordi generative responser og kildevalg kan variere mellom kjøringer og leverandører.
• Hvordan: Velg minst 20 prompter på tvers av oppdagelse, sammenligning, evaluering og merkevarespesifikk intensjon. Inkluder prompter der merkevaren for øyeblikket siteres, nevnes uten sitering, og mangler. Fiks ordlyd, land, språk, leverandør, tagger og tidsplan; dokumenter den kartlagte destinasjonen og forretningsprioriteten.
• Verktøy: Prompt-sporing og -administrasjon i AmICited og det godkjente prompt-til-side-kartet.
• Ferdig når: Minst 20 prompter har én eller flere fullførte baseline-kjøringer; 100 % beholder fiksert ordlyd og innstillinger i observasjonsvinduet; hver har en tiltenkt side og intensjon; og mislykkede eller ventende kjøringer ekskluderes fra utfallsrater i stedet for å telles som manglende.

9. Mål siteringer på domene-, URL-, prompt- og leverandørnivå

• Hva: Spor om merkevaren er nevnt, om dens domene er sitert, hvilken nøyaktig URL som siteres, dens posisjon, og hvilke andre kilder som vinner for samme prompt.
• Hvorfor: En domenetotal kan skjule at feil side tjener siteringer. En omtale kan stige mens eide kildesiteringer faller, noe som betyr at motorer kjenner merkevaren, men stoler på en annen kilde for svaret.
• Hvordan: Ta vare på eksporten før endring, annoter utgivelsen, og sammenlign tilsvarende fullførte kjøringer over det avtalte 28-dagers vinduet. Segmenter etter leverandør og prompt-intensjon. Gå gjennom fullstendige svar for viktige bevegelser og separer eide siteringer fra tredjepartssiteringer som nevner merkevaren.
• Verktøy: Kilde- og siteringsinnsikt i AmICited, prompt-historikk, og utgivelsesannoteringen.
• Ferdig når: Hver prioriterte prompt har en fullført baseline før endring og observasjonspost etter endring; siterte domener og eksakte URL-er er lagret; leverandørforskjeller er synlige; og hver påstått forbedring kan reproduseres fra samme promptsett og datovindu.

10. Test feil på nytt og signer beredskapsbeslutningen

• Hva: Konsolider tekniske, redaksjonelle, skjema- og måleresultater til bestått, betinget bestått, bevisst blokkering eller ikke bestått.
• Hvorfor: En gjennomsnittsscore kan skjule en kritisk tilgangsfeil. Beredskap tilhører eksakte URL-er og maler under en registrert policy, ikke nettstedet som en ubegrunnet etikett.
• Hvordan: Test hvert korrigerte element på nytt fra en ren forespørsel. Hold bevisste policyblokkeringer atskilt fra feil. En betinget bestått må navngi unntaket, berørte URL-er, risiko, godkjenner, korrigeringseier og utløpsdato. Ta vare på rå bevis og malen eller distribusjonsversjonen.
• Verktøy: Beredskapstestmatrise, problemsporer, utgivelsespost og eiersignering.
• Ferdig når: Null kritiske feil gjenstår på bevisst tillatte prioriterte URL-er; hver annen feil har en eier og forfallsdato; hvert unntak har en utløpsdato; og de ansvarlige SEO-, engineering- og innholdseierne signerer den samme daterte posten.

Verktøy i AmICited

Bruk produktkontroller som bevis inne i matrisen, ikke som en erstatning for forretningspolicy eller redaksjonell vurdering.

1. Åpne Agent-tilgjengelighetsrevisjonen for å inspisere llms.txt, tilgjengelighetsstruktur, sitemap-dekning og de separate faktaene bak kravletilgang. Dokumenter en robot-tillatelse, en aktiv CCBot-stil-forespørsel og bekreftet Common Crawl-tilstedeværelse uavhengig; et ukjent resultat er verken bestått eller ikke bestått.

2. Åpne Prompt-sporing for å importere eller opprette det frosne promptsettet, velge leverandører, land, tagger og frekvens, og ta vare på fullførte baseline-kjøringer. Køede, under behandling og mislykkede kjøringer er operasjonelle tilstander, ikke «manglende sitering»-utfall.

3. Åpne Kilder for å bevege seg fra domenetotaler til eksakte siterte sider og promptene hver side vinner. Sammenlign eide sider med tredjepartskilder i stedet for å anta at en merkevareomtale kom fra merkevarens nettsted.

Beslutningsregler: hvordan dårlig ser ut

Dette er operasjonelle porter, ikke påstander om hvordan en motor rangerer sider. Stram dem inn for regulert, sikkerhetskritisk eller høyverdig innhold.

Ikke bland radene til én poengsum. Én blokkert inntektskritisk mal nulles ikke ut av ni velskrevne artikler. Omvendt er en bevisst, godkjent treningskravle-blokkering ikke en teknisk feil hvis hentingskravlere som trengs for den valgte strategien fortsatt kan nå godkjent innhold.

Leveranse

Overlevere en versjonert tabell pluss en bevis-mappe. Påkrevde felt er: revisjons-ID, URL, mal, mål-prompt, leverandør, kravlefamilie, policybeslutning, hentingsresultat, uttrekkbarhetsresultat, skjemaresultat, llms.txt-inkludering, baseline-omtale og -sitering, distribusjonsdato, resultat etter endring, alvorlighetsgrad, eier, forfallsdato, ny testdato, bevislenke, unntak, utløpsdato og endelig beslutning.

Inkluder kravleregisteret, frossen prompt-eksport, enhets- og påstands-kilde-post, og utgivelsesannotering. Lagre rå responser eller gjengitte uttrekk sammen med skjermbilder slik at anmeldere kan verifisere hva maskinen mottok.

Den ansvarlige eieren signerer ett av fire utfall:

• Bestått: alle bevisst tillatte prioriterte URL-er passerer kritiske porter for tilgang, uttrekk, enhet og bevis.
• Betinget bestått: ingen kritisk feil gjenstår, men tidsbegrensede ikke-kritiske unntak er akseptert av navngitte eiere.
• Bevisst blokkering: en kravle eller sti er utilgjengelig etter godkjent policy og forventet synlighetsavveining er dokumentert.
• Ikke bestått: en kritisk mal er utilgjengelig, misvisende, motstridende eller umålbar; utgivelse eller promotering stoppes inntil ny testing.

Hva går galt

Robotpolitikk behandles som bevis på tilgang. Filen sier «tillat», men CDN-en utfordrer forespørselen. Rette dette ved å lagre både policy og et reelt hentingsresultat.

Hver kravle er tillatt uten en forretningseier. SEO-teamet optimaliserer for oppdagelse mens juridiske- eller innholdseiere hadde til hensikt å begrense gjenbruk til trening. Skill kravleformål og få en eksplisitt beslutning i stedet for å lage én generell regel.

llms.txt blir et andre sitemap. Hundrevis av uprioriterte URL-er skaper støy, utdaterte lenker og konkurrerende kanoniske valg. Hold det kuratert og nyttig, eller utelat det bevisst.

Teksten forkortes til den blir feil. Fremtunge svar mister kvalifikasjoner, datoer eller målgruppebegrensninger i jakten på et utdrag. Hold det direkte svaret tidlig, inkluder deretter betingelsene som kreves for at det skal kunne stå alene nøyaktig.

FAQ-skjema legges til usynlige eller uunderbygde svar. Gyldig syntaks gjør ikke fabrikkerte eller skjulte påstander pålitelige. Juster markering med synlig innhold og fjern egenskaper siden ikke kan bevise.

En startsidetest generaliseres til hele nettstedet. Dokumentasjons-, produkt-, kategori- og JavaScript-tunge maler kan oppføre seg forskjellig under samme domene. Revider representative maler og prioriterte destinasjoner.

Én gunstig AI-respons blir suksesshistorien. Teamet kjører på nytt eller omformulerer til merkevaren vises, og rapporterer deretter skjermbildet. Frys prompter først og sammenlign tilsvarende fullførte kjøringer på tvers av observasjonsvinduet.

Omtaleandel forveksles med siteringsandel. Motoren nevner merkevaren, men siterer en anmeldelsesside eller konkurrent. Rapporter merkevaretilstedeværelse og eid kildesitering separat, og inspiser deretter den eksakte siterte URL-en.

Neste fase

Neste er kontinuerlig oppdatering og iterasjon . Den trenger beredskapsmatrisen, kravleregisteret, frosne prompter, siterte URL-er, distribusjonsannotering, unntak og revisjonsdatoer.

Ikke omskriv en side gjentatte ganger bare fordi en sitering ikke har dukket opp. Sjekk først tilgang, prompt-gyldighet, endringer i siterte kilder og fullførte kjøringsvolum. Velg deretter den minste bevisbaserte intervensjonen: teknisk reparasjon, tydeligere avsnitt, sterkere enhetsstøtte, ferskere bevis, eller ingen endring.

Klar til å verifisere GEO- og AEO-beredskap?

Start med SEO-prosessen , kjør deretter Agent-tilgjengelighetsrevisjonen og legg ved bevisene til sjekklisten. Beredskap er fullført først når tilgangsbeslutningen er eksplisitt, representative sider passerer uttrekks- og enhetskontroller, og prompt- og siteringsrapportering kan verifisere resultatet.