The Shelbourne through AI eyes: 82/100

Two scores, one hotel, twenty points apart

Scan #65 gave theshelbourne.com an overall 82. Across ten modules it produced 19 passes, 3 warnings, 0 failures and 5 informational notes. The same week, a different Baseline audit of the same domain came back at 62 out of 100. The two audits ask different questions, and a score only means something relative to the thing it measured.

Nobody hired us for this

The Shelbourne is not a Baseline customer. There is no relationship, no brief and no NDA. We picked a well-known Irish site, ran the standard scan, and are publishing what came back. Everything the scan touched is public: the pages, the robots file, the sitemap, the JSON-LD in the page source. Anyone with a browser and twenty minutes can fetch what we fetched. The run was 30 July 2026, standard depth, 50 pages crawled, ten modules, with Claude and ChatGPT queried directly as part of the perception checks. We re-fetched the homepage and the llms.txt file on 3 August; both were unchanged in the details this piece rests on.

What an AI-legible site looks like

Seven of the ten modules scored 100. Six of them earned it. Bot access is open: GPTBot, PerplexityBot, ClaudeBot, anthropic-ai, CCBot and Applebot are all allowed in robots.txt, with no quiet blocks and no noindex anywhere. There is an llms.txt file at the root, 6,841 bytes of prose written for machines. Every one of the 50 crawled pages carries structured data, across seven distinct schema types. Article or BlogPosting markup appears on 35 pages, and all 35 carry both an author and a dateModified. BreadcrumbList is present on all 48 non-homepage pages. The sitemap is present and fresh. Both language models recognised the domain. The seventh module that scored 100 is dealt with below.

Where the 18 points went

Each module scores as passes divided by passes plus warnings plus failures, times 100. Each module carries a weight. Three modules lost points, and the sum is exact:

• Competitive positioning scored 0.0 at weight 0.100. Lost: 10.00 points.
• Entity authority scored 66.7 at weight 0.160. Lost: 5.33 points.
• Content clarity scored 50.0 at weight 0.056. Lost: 2.80 points.

10.00 + 5.33 + 2.80 = 18.13. That leaves 81.87, which rounds to 82. Behind the numbers sit three warnings. The first is entity resolution: two different @id values appear across the Organization and Person blocks, one a hashed person URI and one a plain #organization anchor. Use the same @id URI on every page and an assistant stitching the site together gets one entity instead of two. The second is content clarity: three duplicated meta descriptions spread across eight pages, including a weddings-and-events line repeated four times. The third warning is ours.

Ten of the 18 lost points came from our scanner

Competitive positioning scored zero because all ten positioning queries failed or timed out. The evidence field reads {"n": 10, "errors": 10}. Not one query returned. The hotel did nothing to earn that, and it is the single largest deduction on the report. The module carries an informational note explaining its method, and it matters before anyone treats the number as gospel: positioning checks use single-shot API calls against each engine's training knowledge rather than live consumer sessions.

There is an error in the other direction too. Citation quality is weighted 0.100 and scored 100, and it measured nothing at all. Its own info finding says so: the check requires Perplexity or AI Mode to be enabled, neither was configured for this template, so it was skipped. A skipped module scores full marks by default. That handed the site a clean ten points nobody looked at.

So one broken module took ten points away and one unrun module gave ten points back. They roughly cancel, which is luck rather than design. The reason to print both is simple: a score that hides its own gaps is selling a certainty it does not have. If we only told you about the module that failed, you would think the site was worth 92. If we only told you about the module that was skipped, you would think it was worth 72. Neither is a better answer than showing the working.

100% structured coverage, and not one Hotel

Structured coverage scored a flat 100. Every page carries markup and seven types are in play. What the module cannot ask is whether any of that markup says the site belongs to a hotel. The scan's own entity card lists the types found across the crawl as Article, BreadcrumbList, SiteNavigationElement, WebPage, WebSite, plus Organization and Person. No Hotel. No LodgingBusiness. The homepage carries exactly one ld+json block, and its graph contains WebPage, BreadcrumbList, WebSite and Organization with a nested image. That is what a publisher's markup looks like. Nothing in it says hotel.

The Organization block's full property list is seven items: @id, @type, image, logo, name, sameAs, url. No address. No telephone. No description. No founding date. No price range. No star rating. Google documents that Organization has no required properties at all, so a block like that is perfectly valid and sails through every generic validator. The moment you use the type that actually fits, the bar moves: LocalBusiness requires name and address, and Google states plainly that you must include the required properties for content to be eligible as a rich result, with telephone and priceRange recommended on top.

The hotel's own llms.txt states its street address at 27 St Stephen's Green, its phone number, its 1824 founding year and its place in Marriott's Autograph Collection. In prose. In a text file. It states none of those four in its structured data. The site tells assistants in plain English what it declines to tell them in a format machines can parse without inference. Hotel is a documented subtype of LodgingBusiness, inheriting through both the Organization and Place branches, and it carries fields built for exactly this: address, telephone, priceRange, starRating, amenityFeature and checkinTime, with checkoutTime and numberOfRooms on the parent type. schema.org's own hotel markup guide spells out the shape: a lodging business, an accommodation, and an offer, with rooms linked to the hotel by containsPlace and containedInPlace, and rates modelled as offers because things do not have prices, only offers on things do.

Coverage measures whether pages have markup. It does not measure whether the markup describes the business. A score of 82 cannot see that gap, and we would fix it before anything the score did flag.

What Claude and ChatGPT said when asked

Claude, self-reported confidence 72 out of 100, described a historic luxury hotel on St Stephen's Green with heritage dating back to the 18th century. Its own key-facts list, in the same response, said "Founded in 1824, making it one of Dublin's oldest hotels". 1824 is the 19th century. The hotel was founded in 1824 by Martin Burke, a native of County Tipperary, and Irish national press marked 2024 as the 200th anniversary. The fact list was right and the prose was a century out, in one answer.

ChatGPT, self-reported confidence 85, gave a shorter answer and got more of it right: established 1824, part of the Autograph Collection by Marriott, located in Dublin city centre. The rebrand checks out. The hotel joined Marriott's Autograph Collection in 2019 after a $40 million refurbishment, and it is owned by Archer Hotel Capital and operated by Marriott International under that brand. On this pair of answers the more confident model was the more accurate one. Treat that as one data point about two responses. It says nothing about how either model is calibrated in general.

Read the whole exchange as a snapshot. Each engine got one single-shot API call against its training knowledge, and a second run could easily land differently. The gaps the models named travel further. Claude asked for clear information about current ownership and management. The hotel states that in the opening paragraph of the file it published for machines to read. Claude also asked for schema.org structured data about amenities, room types and services, arriving independently at the ceiling described above. Both models separately asked for accessibility information. Two engines naming the same gap is a thin sample, but it is the one item on this report we would act on first.

In priority order

If this were our site, the order would be:

• Publish accessibility information. Two independent engines named it. It serves real guests before it serves any crawler, and nothing else on this list has that dual return.
• Add a Hotel or LodgingBusiness block with address, telephone, starRating and priceRange. The facts are already written down in llms.txt. This is transcription work; the research is done. Give the rooms their own Accommodation objects and rates as Offers.
• Collapse the two @id values into one canonical URI used on every page. Cheap, mechanical, and it stops assistants resolving one hotel into two entities.
• Rewrite the three duplicated meta descriptions so the eight affected pages describe themselves rather than the brand.
• Ignore the competitive positioning score until the module runs cleanly. A zero from a timeout tells you nothing.

The obvious follow-ups