The Shelbourne gjennom AI-øyne: 82/100

To resultater, ett hotell, tjue poeng fra hverandre

Skanning #65 ga theshelbourne.com en totalscore på 82. Over ti moduler produserte den 19 bestått, 3 advarsler, 0 feil og 5 informasjonsnotater. Samme uke kom en annen Baseline-revisjon av samme domene tilbake med 62 av 100. De to revisjonene stiller forskjellige spørsmål, og en score betyr bare noe i forhold til det den målte.

Ingen ansatte oss for dette

The Shelbourne er ikke en Baseline-kunde. Det er ingen relasjon, ingen brief og ingen NDA. Vi valgte et velkjent irsk nettsted, kjørte standard skanning, og publiserer det som kom tilbake. Alt skanningen berørte er offentlig: sidene, robots-filen, sitemap-en, JSON-LD i sidekilden. Alle med en nettleser og tjue minutter kan hente det vi hentet. Kjøringen var 30. juli 2026, standard dybde, 50 sider gjennomsøkt, ti moduler, med Claude og ChatGPT direkte spurt som en del av persepsjonskontrollene. Vi hentet hjemmesiden og llms.txt-filen på nytt 3. august; begge var uendret i detaljene dette stykket bygger på.

Slik ser et AI-lesbart nettsted ut

Syv av de ti modulene scoret 100. Seks av dem fortjente det. Bot-tilgang er åpen: GPTBot, PerplexityBot, ClaudeBot, anthropic-ai, CCBot og Applebot er alle tillatt i robots.txt, uten stille blokkeringer og ingen noindex noe sted. Det er en llms.txt-fil i roten, 6 841 byte med prosa skrevet for maskiner. Hver av de 50 gjennomsøkte sidene inneholder strukturerte data, på tvers av syv forskjellige skjematyper. Artikkel- eller BlogPosting-markering vises på 35 sider, og alle 35 har både en forfatter og en dateModified. BreadcrumbList er til stede på alle 48 sider som ikke er hjemmesiden. Sitemap-en er til stede og fersk. Begge språkmodellene gjenkjente domenet. Den syvende modulen som scoret 100 er behandlet nedenfor.

Hvor de 18 poengene forsvant

Hver modul scorer som bestått delt på bestått pluss advarsler pluss feil, ganger 100. Hver modul har en vekt. Tre moduler mistet poeng, og summen er nøyaktig:

• Konkurranseposisjonering scoret 0,0 med vekt 0,100. Tapt: 10,00 poeng.
• Enhetsautoritet scoret 66,7 med vekt 0,160. Tapt: 5,33 poeng.
• Innholdsklarhet scoret 50,0 med vekt 0,056. Tapt: 2,80 poeng.

10,00 + 5,33 + 2,80 = 18,13. Det etterlater 81,87, som rundes til 82. Bak tallene sitter tre advarsler. Den første er enhetsoppløsning: to forskjellige @id verdier vises på tvers av organisasjons- og personblokkene, den ene en hashet person-URI og den andre et vanlig #organization anker. Bruk den samme @id URI-en på hver side, og en assistent som syr sammen nettstedet, får én enhet i stedet for to. Den andre er innholdsklarhet: tre dupliserte metabeskrivelser spredt over åtte sider, inkludert en linje om bryllup og arrangementer gjentatt fire ganger. Den tredje advarselen er vår.

Ti av de 18 tapte poengene kom fra vår skanner

Konkurranseposisjonering scoret null fordi alle ti posisjoneringsspørringene mislyktes eller timede ut. Bevisfeltet leser {"n": 10, "errors": 10}. Ikke en eneste spørring returnerte. Hotellet gjorde ingenting for å fortjene det, og det er det største enkeltfradraget på rapporten. Modulen inneholder en informasjonsnotat som forklarer metoden, og det er viktig før noen behandler tallet som evangelium: posisjoneringskontroller bruker engangs-API-kall mot hver motors treningskunnskap i stedet for live forbrukerøkter.

Det er også en feil i den andre retningen. Sitasjonskvalitet er vektet 0,100 og scoret 100, og den målte ingenting i det hele tatt. Dens egen informasjonsfunn sier det: sjekken krever at Perplexity eller AI-modus er aktivert, ingen av dem var konfigurert for denne malen, så den ble hoppet over. En hoppet over modul scorer fullt ut som standard. Det ga nettstedet ti rene poeng som ingen så på.

Så en ødelagt modul tok ti poeng bort, og en ufullført modul ga ti poeng tilbake. De kansellerer omtrent, noe som er flaks snarere enn design. Grunnen til å skrive ut begge er enkel: en score som skjuler sine egne mangler, selger en sikkerhet den ikke har. Hvis vi bare fortalte deg om modulen som mislyktes, ville du trodd nettstedet var verdt 92. Hvis vi bare fortalte deg om modulen som ble hoppet over, ville du trodd det var verdt 72. Ingen av delene er et bedre svar enn å vise arbeidet.

100 % strukturert dekning, og ikke ett hotell

Strukturert dekning scoret flate 100. Hver side har markering, og syv typer er i spill. Det modulen ikke kan spørre om, er om noe av den markeringen sier at nettstedet tilhører et hotell. Skanningens egen enhetskort viser typene som ble funnet under gjennomgangen som Article, BreadcrumbList, SiteNavigationElement, WebPage, WebSite, pluss Organization og Person. Ikke noe hotell. Ikke noe LodgingBusiness. Hjemmesiden har nøyaktig én ld+json-blokk, og grafen inneholder WebPage, BreadcrumbList, WebSite og Organization med et nestet bilde. Slik ser en utgivers markering ut. Ingenting i den sier hotell.

Organisasjonsblokkens fulle egenskapsliste er syv elementer: @id, @type, image, logo, name, sameAs, url. Ingen adresse. Ingen telefon. Ingen beskrivelse. Ingen stiftelsesdato. Ingen prisklasse. Ingen stjernerangering. Google dokumenterer at Organization ikke har noen obligatoriske egenskaper i det hele tatt, så en slik blokk er perfekt gyldig og passerer alle generiske validatorer. I det øyeblikket du bruker typen som faktisk passer, flyttes listen: LocalBusiness krever navn og adresse, og Google sier tydelig at du må inkludere de obligatoriske egenskapene for at innholdet skal være kvalifisert som et rikt resultat, med telefon og prisklasse anbefalt i tillegg.

Hotellets egen llms.txt oppgir gateadressen 27 St Stephen's Green, telefonnummeret, stiftelsesåret 1824 og dets plass i Marriott's Autograph Collection. I prosa. I en tekstfil. Det oppgir ingen av disse fire i sine strukturerte data. Nettstedet forteller assistenter på vanlig engelsk hva det nekter å fortelle dem i et format maskiner kan tolke uten inferens. Hotel er en dokumentert undertype av LodgingBusiness, som arver gjennom både Organization- og Place-grenene, og den inneholder felt bygget for akkurat dette: adresse, telefon, priceRange, starRating, amenityFeature og checkinTime, med checkoutTime og numberOfRooms på overordnet type. schema.orgs egen hotellmarkeringsguide beskriver formen: en overnattingsvirksomhet, en overnatting og et tilbud, med rom knyttet til hotellet av containsPlace og containedInPlace, og priser modellert som tilbud fordi ting ikke har priser, bare tilbud på ting har det.

Dekning måler om sider har markering. Det måler ikke om markeringen beskriver virksomheten. En score på 82 kan ikke se det gapet, og vi ville fikset det før noe scoren flagget.

Hva Claude og ChatGPT sa da de ble spurt

Claude, selvoppgitt selvtillit 72 av 100, beskrev et historisk luksushotell på St Stephen's Green med en arv som dateres tilbake til 1700-tallet. Dens egen nøkkelfaktaliste, i samme svar, sa "Grunnlagt i 1824, noe som gjør det til et av Dublins eldste hoteller". 1824 er det 19. århundre. @idHotellet ble grunnlagt i 1824 av Martin Burke, en innfødt fra County Tipperary#organization, og irsk nasjonalpresse markerte 2024 som @id200-årsjubileet{"n": 10, "errors": 10}. Faktalisten var riktig og prosateksten var et århundre feil, i ett svar.

ChatGPT, selvoppgitt selvtillit 85, ga et kortere svar og fikk mer riktig: etablert 1824, del av Autograph Collection by Marriott, lokalisert i Dublin sentrum. Rebrandingen stemmer. @idHotellet ble med i Marriotts Autograph Collection i 2019 etter en $40 millioner oppussing@type, og imagedet eies av Archer Hotel Capital og drives av Marriott International under det merketlogo. På dette paret av svar var den mer selvsikre modellen den mer nøyaktige. Betrakt det som ett datapunkt om to svar. Det sier ingenting om hvordan noen av modellene er kalibrert generelt.

Les hele utvekslingen som et øyeblikksbilde. Hver motor fikk ett enkelt API-kall mot sin treningskunnskap, og en andre kjøring kunne lett lande annerledes. Hullene modellene navnga reiser lenger. Claude ba om klar informasjon om nåværende eierskap og ledelse. Hotellet oppgir dette i åpningsavsnittet av filen det publiserte for maskiner å lese. Claude ba også om schema.org strukturerte data om fasiliteter, romtyper og tjenester, og kom uavhengig frem til taket beskrevet ovenfor. Begge modellene ba separat om tilgjengelighetsinformasjon. To motorer som navngir det samme gapet er et tynt utvalg, men det er det ene elementet på denne rapporten vi ville handlet på først.

I prioritert rekkefølge

Hvis dette var vår side, ville rekkefølgen vært:

• Publiser tilgjengelighetsinformasjon. To uavhengige motorer nevnte det. Det tjener ekte gjester før det tjener noen crawler, og ingenting annet på denne listen har den doble avkastningen.
• Legg til en Hotel- eller LodgingBusiness-blokk med adresse, telefon, starRating og priceRange. Fakta er allerede skrevet ned i llms.txt. Dette er transkripsjonsarbeid; forskningen er gjort. Gi rommene deres egne Accommodation-objekter og priser som Offers.
• Slå sammen de to @id verdiene til en kanonisk URI som brukes på hver side. Billig, mekanisk, og det hindrer assistenter i å løse ett hotell til to enheter.
• Skriv om de tre dupliserte metabeskrivelsene slik at de åtte berørte sidene beskriver seg selv i stedet for merkevaren.
• Ignorer poengsummen for konkurranseposisjonering til modulen kjører rent. En null fra en tidsavbrudd forteller deg ingenting.

De åpenbare oppfølgingene