Skip to content
Site Pulse - Public audit

A five-star hotel with a 62/100 website

The Shelbourne has stood on St Stephen's Green since 1824, and by its own account Michael Collins drafted the Irish Constitution inside it in 1922. It is, by most measures, the most famous hotel in the country. We pointed Site Pulse at theshelbourne.com, crawled 50 pages, and it came back at 62 out of 100. Nobody there is asleep at the wheel. The site does several modern things better than most of its competitors. But the boring layer underneath has been quietly leaking for years, and nobody gets a bonus for fixing it.

George, the Baseline Labs mascot, holding a clipboard

Nobody hired us to do this

This is a public-data audit. We have no relationship with The Shelbourne, no client engagement, and no inside access. Every finding below comes from fetching pages that anyone with a browser can fetch, using the same crawler any search engine or AI assistant would use. We picked the site precisely because it is a strong brand with a competent web presence: if the pattern shows up here, it shows up everywhere.

The scan ran on 30 July 2026 at standard depth - 50 pages, 22 modules, 1,912 individual findings. You can open the full run yourself: the complete Site Pulse report is public, every check and every page.

62
Overall Site Pulse score out of 100
1,148
Checks passed across 50 pages
50
Outright failures - all of them the same check

They did the new thing right

Start with what most audits would bury. The Shelbourne scores 100 on AI access, 100 on crawlability and indexing, 100 on security scanning, and 100 on llms.txt. That last one is unusual. A real /llms.txt sits at the root of the domain: one H1, seven H2 sections covering the hotel, rooms, dining and the rest, twenty-nine links, and every link we sampled resolved. Someone deliberately built that file. Most five-star hotels have not.

The AI crawler picture is equally clean. We ran live probes rather than trusting robots.txt, and GPTBot, ClaudeBot, PerplexityBot and Google-Extended all received HTTP 200. No CDN silently turning them away, no blanket disallow. That matters more than it sounds - blocking every AI bot is a costly reflex, and plenty of hotel groups have done it by accident through a security plugin.

Be clear about what llms.txt actually buys, though: no major search engine consumes it. It is a bet on where retrieval is heading, and it does nothing for rankings today. The Shelbourne placed that bet. Good. The trouble is what the assistants find when they follow it.

The author is called originate_admin

Then we got to the story pages. The declared author on all of them is the CMS account the web agency built the site with:

<meta name="author" content="originate_admin">

That would be forgivable as a stray meta tag. It also sits in the structured data, where the hotel tells machines in schema.org's own vocabulary who wrote its content: "author": {"name": "originate_admin"}. That is the string a knowledge graph ingests, and what an assistant reads when it works out whether this page has an authority behind it.

Site Pulse flagged the consequence under entity consistency: two distinct entity names across the crawled pages. The main site pages say The Shelbourne Dublin. The story pages say originate_admin. To a model trying to reconcile a business into one entity, that is noise where there should be a signal. The hotel scores 80 on entity consistency, and the twenty points it drops are entirely this.

The same module found no Wikidata entity match for "The Shelbourne Dublin" at all, and a sameAs block listing Facebook, X, Instagram and YouTube but no Wikidata, LinkedIn, Crunchbase or G2. A 200-year-old landmark that has hosted heads of state has a weaker machine-readable identity than a two-year-old SaaS startup.

URLs still carrying the placeholder text

When an agency builds a site, it seeds the CMS with dummy posts so the templates have something to render. Those posts are supposed to be deleted. Here, they were edited instead - real content poured into the placeholder shells - and the URLs never changed. All three of these are live right now, returning HTTP 200:

URLWhat the page actually isDeclared words
/story/lorem-ipsum-dolor-adipiscing-elit/Slaney Farms, a producer feature2
/story/producer-1-lorem-ipsum-dolor-adipiscing-elit/Rye River Brewing Company4
/story/a-blog-post/A guide to the hotel's gift vouchers15

The third column comes from the site itself. It is the wordCount published in its own structured data. The hotel is telling every machine that reads it that its gift voucher guide is fifteen words long, and that its producer feature is two.

A URL is one of the stronger signals a retrieval system has about what a page contains. It survives redesigns, it appears in citations, and it is often the only context a model sees before deciding whether to fetch. A page about an Irish brewery living at a path that says lorem ipsum dolor adipiscing elit is throwing that away. So is a page about gift vouchers at /story/a-blog-post/.

The same pattern produces a near-duplicate pair next door. Two URLs both read /story/discover-5-star-luxury-in-dublins-historic-shelbourne-hotel/, one with the -2 suffix WordPress appends when a slug is already taken. The first serves the 5-star luxury piece its URL promises. The second serves an article titled "Why The Shelbourne Hotel is Perfect for Special Occasions". Both are indexable, and their text is more than 90% identical, so an assistant choosing between them is picking at random between a page whose URL matches its content and one whose URL describes something else entirely.

Fifty failures, one mistake

Every single hard failure in the scan is the same check firing on every page: two form inputs with no accessible label. It is the site-wide search or newsletter box in the template, and because it is in the template it is wrong 50 times out of 50. Accessibility comes out at 38.5, the lowest score on the board. The skip-navigation link is missing on all 50 pages too.

This is the shape of nearly every technical problem on a large site: one problem in one template, multiplied by the page count. That cuts both ways. It looks catastrophic in a report, and it is usually an afternoon's work to fix.

ModuleWhat it measuresScore
llms.txtAI-readable site summary100
AI accessCrawler reachability, live-probed100
Crawl & indexCanonicals, sitemaps, status codes100
ContentHeadings, word counts, structure95.3
MetadataTitles, descriptions, Open Graph87.1
Entity consistencyOne business, one name80.0
PerformanceResource hints, payload66.9
MobileLayout on small screens63.1
LLM viewWhat a model can actually read50.0
ReachabilitySecurity headers, response health42.9
AccessibilityLabels, hierarchy, navigation38.5

1.2% of the page is words

The LLM view module strips a page down to what a language model would actually ingest - no scripts, no styles, no navigation furniture - and measures what is left. On theshelbourne.com the content-to-markup ratio came out at 1.2%, on every page we crawled.

On a typical story page, the crawler stripped 51 noise elements before it found anything to read: 14,310 characters of inline CSS, 7,955 of script, 1,895 of navigation. What survived was around 1,700 characters, an estimated 290 to 430 tokens. The page is mostly scaffolding.

The site is still perfectly visible. But the hotel is spending its retrieval budget on furniture, and the substance an assistant could quote is thin relative to how much it has to download to find it. Elsewhere we've written about how a site can rank first on Google and still be invisible to AI; this is one of the mechanisms behind it. The same dynamic keeps seven in ten Italian hotels out of assistant shortlists.

Two smaller metadata problems compound it. Open Graph images are missing sitewide, so every share of a five-star hotel renders as a blank card. And there are four duplicate titles across eight pages, plus three duplicate descriptions - the classic sign of pages generated from a template that nobody revisited.

Two things our scanner got wrong

We sell this tool, so we should say where it misfired on this run. Three modules scored zero, and two of those zeros are our fault rather than the hotel's.

The junk module flagged keyword stuffing because the word the makes up around 9% of the body text. That is a stopword counter that should be excluding stopwords, and it is going to fire on any business whose name begins with "The". It is a bug, and it is now on our list.

The near-duplicate module scored zero partly because it treated theshelbourne.com and theshelbourne.com/ as two pages that are 100% identical to each other. They are the same page. Our crawler double-counted it. The -2 duplicate pair in that module is real; the homepage cluster is an artefact.

The third zero, tracking, is a judgement call rather than a bug: the site loads Google Tag Manager with no consent management platform detected. Whether that is a finding depends on what GTM is firing, which we cannot see from outside.

Treat a score as a prompt to go and look. Any audit tool that never admits a false positive is selling certainty it does not have.

What this costs, and what to do about it

Check who your site says wrote it. View source on a content page and search for "author". If it returns a CMS username, a plugin default, or an agency account, you are handing that string to every knowledge graph that reads you. Fixing it is a settings change, not a rebuild.

Audit your slugs once. Pull your sitemap, read the URLs as a stranger would, and look for the ones that describe the build rather than the content. Then 301 them to a real slug. Deleting them just turns an ugly URL into a dead one.

Treat template failures as one bug. Fifty failures on fifty pages is one unlabelled input in one header. Fix the template and the report changes overnight.

Don't let the modern layer paper over the old one. The Shelbourne has an llms.txt and open doors for every AI crawler, which puts it ahead of most of its competitors. It also tells those crawlers that its content was written by originate_admin. The new work only pays off if what the crawlers reach is coherent.

Run Site Pulse on your own site

Questions this usually raises

Is 62 a bad score?
It is middling, and it is normal for a large site built by an agency a few years ago and maintained lightly since. The number matters less than its shape: The Shelbourne's losses are concentrated in accessibility, security headers and machine-readability, all of which are template-level and fixable, rather than spread thinly across content quality, which is not.
Does an author name really affect whether AI recommends a hotel?
Not on its own. It matters as part of entity resolution - the process by which a model decides that the thing on this page is the same thing it has read about elsewhere. Consistent naming, a claimed Wikidata entry and sameAs links to real profiles all feed that. A CMS username in the author field is a small contradiction in a picture that should have none.
Why does having an llms.txt not lift the score more?
Because llms.txt only points. It tells an assistant which pages matter, and the assistant then goes and fetches them. If those pages are 1.2% text with a contradictory author, the signpost has pointed straight at the problem. Have an llms.txt by all means, but write it last, once the pages it points at are worth reaching.
Can I see the full scan?
Yes. The report is public - all 22 modules, all 50 pages, every pass, warning and failure, including the two checks we've flagged above as our own false positives.

Method: Baseline Labs Site Pulse scan #223, theshelbourne.com, standard depth, 50 pages, 30 July 2026. All figures are drawn from that scan and were re-verified against the live site on 1 August 2026. No relationship exists between Baseline Labs and The Shelbourne; this audit uses only publicly accessible pages.

See how AI search sees your site

Free AI visibility check in under a minute

Check my site
George
Online
0%