The Shelbourne genom AI-ögon: 82/100

Två poäng, ett hotell, tjugo poängs skillnad

Skanning #65 gav theshelbourne.com en totalpoäng på 82. Över tio moduler producerade den 19 godkända, 3 varningar, 0 fel och 5 informationsnotiser. Samma vecka kom en annan Baseline-revision av samma domän tillbaka med 62 av 100. De två revisionerna ställer olika frågor, och en poäng betyder bara något i förhållande till det den mätte.

Ingen anlitade oss för detta

The Shelbourne är inte en Baseline-kund. Det finns ingen relation, ingen brief och ingen NDA. Vi valde en välkänd irländsk webbplats, körde den vanliga skanningen och publicerar vad som kom tillbaka. Allt som skanningen berörde är offentligt: sidorna, robots-filen, sitemapen, JSON-LD i sidkällan. Vem som helst med en webbläsare och tjugo minuter kan hämta det vi hämtade. Körningen var den 30 juli 2026, standarddjup, 50 sidor genomsökta, tio moduler, med Claude och ChatGPT direktfrågade som en del av perceptionskontrollerna. Vi hämtade startsidan och llms.txt-filen igen den 3 augusti; båda var oförändrade i de detaljer som denna artikel bygger på.

Hur en AI-läsbar webbplats ser ut

Sju av de tio modulerna fick 100 poäng. Sex av dem förtjänade det. Botåtkomst är öppen: GPTBot, PerplexityBot, ClaudeBot, anthropic-ai, CCBot och Applebot är alla tillåtna i robots.txt, utan tysta blockeringar och ingen noindex någonstans. Det finns en llms.txt-fil i roten, 6 841 byte prosa skrivna för maskiner. Var och en av de 50 genomsökta sidorna innehåller strukturerad data, över sju distinkta schematyper. Artikel- eller BlogPosting-markering visas på 35 sidor, och alla 35 har både en författare och ett dateModified. BreadcrumbList finns på alla 48 sidor som inte är startsidan. Webbplatskartan finns och är färsk. Båda språkmodellerna kände igen domänen. Den sjunde modulen som fick 100 poäng behandlas nedan.

Vart de 18 poängen tog vägen

Varje modul får poäng som godkända dividerat med godkända plus varningar plus misslyckanden, gånger 100. Varje modul har en vikt. Tre moduler förlorade poäng, och summan är exakt:

• Konkurrenskraftig positionering fick 0,0 med vikt 0,100. Förlorade: 10,00 poäng.
• Enhetsauktoritet fick 66,7 med vikt 0,160. Förlorade: 5,33 poäng.
• Innehållsklarhet fick 50,0 med vikt 0,056. Förlorade: 2,80 poäng.

10,00 + 5,33 + 2,80 = 18,13. Det lämnar 81,87, vilket avrundas till 82. Bakom siffrorna finns tre varningar. Den första är entitetsupplösning: två olika @id värden visas över organisation- och personblocken, en hashad person-URI och en vanlig #organization ankartext. Använd samma @id URI på varje sida så får en assistent som sammanfogar webbplatsen en entitet istället för två. Den andra är innehållsklarhet: tre duplicerade metabeskrivningar spridda över åtta sidor, inklusive en rad om bröllop och evenemang som upprepas fyra gånger. Den tredje varningen är vår.

Tio av de 18 förlorade poängen kom från vår skanner

Konkurrenskraftig positionering fick noll eftersom alla tio positioneringsfrågor misslyckades eller tog för lång tid. Fältet för bevis läser {"n": 10, "errors": 10}. Inte en enda fråga returnerades. Hotellet gjorde inget för att förtjäna det, och det är det enskilt största avdraget i rapporten. Modulen innehåller en informationsnot som förklarar dess metod, och det är viktigt innan någon behandlar siffran som sanning: positioneringskontroller använder engångs-API-anrop mot varje motors träningskunskap snarare än live-konsumentsessioner.

Det finns också ett fel i den andra riktningen. Citeringskvalitet är viktad 0,100 och fick 100 poäng, och den mätte ingenting alls. Dess egen informationssökning säger så: kontrollen kräver att Perplexity eller AI Mode är aktiverat, inget av dem var konfigurerat för denna mall, så den hoppades över. En överhoppad modul får full poäng som standard. Det gav webbplatsen tio rena poäng som ingen tittade på.

Så en trasig modul tog bort tio poäng och en okörd modul gav tio poäng tillbaka. De tar ungefär ut varandra, vilket är tur snarare än design. Anledningen till att skriva ut båda är enkel: en poäng som döljer sina egna luckor säljer en säkerhet den inte har. Om vi bara berättade om modulen som misslyckades, skulle du tro att webbplatsen var värd 92. Om vi bara berättade om modulen som hoppades över, skulle du tro att den var värd 72. Inget är ett bättre svar än att visa hur det fungerar.

100 % strukturerad täckning, och inte ett enda hotell

Strukturerad täckning fick ett platt 100. Varje sida har markup och sju typer används. Vad modulen inte kan fråga är om någon av den markeringen säger att webbplatsen tillhör ett hotell. Skanningens egen entitetskort listar de typer som hittats under genomsökningen som Artikel, BreadcrumbList, SiteNavigationElement, WebPage, WebSite, plus Organization och Person. Inget hotell. Ingen LodgingBusiness. Hemsidan innehåller exakt ett ld+json-block, och dess graf innehåller WebPage, BreadcrumbList, WebSite och Organization med en kapslad bild. Det är så en utgivares markup ser ut. Ingenting i den säger hotell.

Organisationens fullständiga egenskapslista är sju objekt: @id, @type, image, logo, name, sameAs, url. Ingen adress. Inget telefonnummer. Ingen beskrivning. Inget grundläggande datum. Inget prisintervall. Ingen stjärnklassificering. Google dokumenterar att Organization inte har några obligatoriska egenskaper alls, så ett sådant block är helt giltigt och passerar varje generisk validator. I det ögonblick du använder den typ som faktiskt passar, flyttas ribban: LocalBusiness kräver namn och adress, och Google anger tydligt att du måste inkludera de obligatoriska egenskaperna för att innehållet ska vara kvalificerat som ett rikt resultat, med telefon och prisintervall rekommenderas dessutom.

Hotellets egen llms.txt anger sin gatuadress på 27 St Stephen's Green, sitt telefonnummer, sitt grundläggande år 1824 och sin plats i Marriotts Autograph Collection. I prosa. I en textfil. Det anger inget av dessa fyra i sin strukturerade data. Webbplatsen berättar för assistenter på vanlig engelska vad den vägrar att berätta för dem i ett format som maskiner kan tolka utan inferens. Hotel är en dokumenterad undertyp av LodgingBusiness, som ärver genom både Organization- och Place-grenarna, och den innehåller fält byggda för exakt detta: adress, telefon, prisintervall, stjärnklassificering, bekvämlighetsfunktion och incheckningstid, med utcheckningstid och antal rum på föräldratypen. schema.orgs egen hotellmarkeringsguide beskriver formen: ett boendeföretag, ett boende och ett erbjudande, med rum kopplade till hotellet med containsPlace och containedInPlace, och priser modellerade som erbjudanden eftersom saker inte har priser, bara erbjudanden på saker har det.

Täckning mäter om sidor har markup. Den mäter inte om markeringen beskriver verksamheten. En poäng på 82 kan inte se den luckan, och vi skulle åtgärda den innan något som poängen flaggade.

Vad Claude och ChatGPT sa när de fick frågan

Claude, med en självrapporterad konfidens på 72 av 100, beskrev ett historiskt lyxhotell på St Stephen's Green med anor från 1700-talet. Dess egen lista med nyckelfakta, i samma svar, sa "Grundades 1824, vilket gör det till ett av Dublins äldsta hotell". 1824 är 1800-talet. Hotellet grundades 1824 av Martin Burke, en infödd från County Tipperary, och irländsk nationell press markerade 2024 som 200-årsjubileet. Faktalistan var korrekt och prosan var ett sekel fel, i ett svar.

ChatGPT, med en självrapporterad konfidens på 85, gav ett kortare svar och fick mer rätt: etablerat 1824, en del av Autograph Collection by Marriott, beläget i Dublins centrum. Omprofileringen stämmer. Hotellet anslöt sig till Marriotts Autograph Collection 2019 efter en renovering för 40 miljoner dollar, och det ägs av Archer Hotel Capital och drivs av Marriott International under det varumärket. På detta par svar var den mer självsäkra modellen den mer exakta. Betrakta det som en datapunkt om två svar. Det säger inget om hur någon av modellerna är kalibrerade i allmänhet.

Läs hela utbytet som en ögonblicksbild. Varje motor fick ett enda API-anrop mot sin träningskunskap, och en andra körning kunde lätt landa annorlunda. De luckor modellerna nämnde reser längre. Claude bad om tydlig information om nuvarande ägande och förvaltning. Hotellet anger detta i inledningsparagrafen i filen det publicerade för maskiner att läsa. Claude bad också om schema.org strukturerad data om bekvämligheter, rumstyper och tjänster, och kom självständigt fram till det tak som beskrivs ovan. Båda modellerna bad separat om tillgänglighetsinformation. Två motorer som nämner samma lucka är ett tunt urval, men det är den enda punkten i denna rapport som vi skulle agera på först.

I prioritetsordning

Om detta vore vår webbplats, skulle ordningen vara:

• Publicera tillgänglighetsinformation. Två oberoende motorer nämnde det. Det tjänar verkliga gäster innan det tjänar någon crawler, och inget annat på denna lista har den dubbla avkastningen.
• Lägg till ett Hotel- eller LodgingBusiness-block med adress, telefonnummer, starRating och priceRange. Fakta är redan nedskrivna i llms.txt. Detta är transkriptionsarbete; forskningen är klar. Ge rummen egna Accommodation-objekt och priser som Offers.
• Slå samman de två @id värdena till en kanonisk URI som används på varje sida. Billigt, mekaniskt, och det hindrar assistenter från att lösa ett hotell till två entiteter.
• Skriv om de tre duplicerade metabeskrivningarna så att de åtta berörda sidorna beskriver sig själva snarare än varumärket.
• Ignorera poängen för konkurrenskraftig positionering tills modulen körs rent. En nolla från en timeout säger dig ingenting.

De uppenbara följdfrågorna