

When we measured 36 Dominican hotel websites earlier this year, we were looking at speed. The structured data came along for the ride — we fetched every homepage and recorded what markup it carried — and then sat unused because the speed story was stronger.
It deserves its own look, because what it shows is stranger than "most hotels don't bother." Most of them do bother. The problem is what they're bothering with.
Of 36 hotel websites in Punta Cana, Bávaro, BayahÃbe and La Romana:
• 86% (31 of 36) ship JSON-LD structured data. That's high — higher than we expected, and far higher than the Dominican restaurant sector manages.
• 81% carry Hotel markup and 83% carry a postal address. The fundamentals are widely done.
• 42% (15 of 36) still ship FAQPage markup, which Google retired in 2026. It produces no search feature at all.
• Only 14% mark up a hotel room. Only 14% mark up an offer or a price.
• Only 6% mark up their restaurant, in a sector where almost every property has one.
So the sector has adopted structured data, and then stopped at the front door. Nearly every hotel tells Google that it is a hotel and where it is. Almost none tells Google what it sells or what it costs.
Fifteen of thirty-six hotels are shipping FAQPage, Question and Answer markup that does nothing. Not penalised, not harmful — simply inert. The rich result it was built for no longer exists.
That's not costing anyone rankings, and we'd be overstating it to call it a problem. What it is, is a dating tool. Markup for a retired feature is a fossil layer: it tells you the site was configured once, correctly, by somebody who knew what they were doing — and then never revisited.
The distribution supports that reading. Among the large resorts, 13 of 22 carry it. Among the four small independents, none do. The dead markup lives precisely where there was once a budget for an agency and no ongoing relationship afterwards.
Here's the result that stopped us, and it needs care rather than a headline.
Hotels with structured data averaged a PageSpeed score of 29.8. Hotels without any averaged 53.4. The two fastest sites in the entire study carry no structured data at all, and the single best performer — Hotel Villa Iguana in BayahÃbe, which scored 84 — has none.
Structured data does not make a website slow. That would be an absurd reading and we're not making it. What's actually happening is that both are symptoms of the same thing: a large, professionally-managed site built on a heavy platform, with an agency-installed SEO layer and years of accumulated scripts. The markup and the slowness arrive in the same box.
The small independent with a fast site has neither. Which means the honest summary isn't "schema is bad" — it's that structured data marks a site as professionally managed, and in this sample professionally managed also meant slow. Two different problems, one common cause.
Working from what's there, the gaps are specific and fixable:
Rooms and rates. Five of 36 hotels mark up a room type; five mark up an offer. Room and price data is exactly what an AI assistant or a rich result would want to surface, and it's the thing hotels most want surfaced. The sector has told Google it exists but not what it sells.
Restaurants. Two of 36. Nearly every resort in the sample has multiple restaurants — several are destinations in their own right — and almost none are described in a way a machine can read.
Reviews. 44% carry AggregateRating. The rest are leaving a visible, well-established search feature on the table.
The five with nothing. Club Med, VIK Arena Blanca, Puntacana Resort and Club, Eden Roc Cap Cana and Hotel Villa Iguana ship no structured data whatsoever. Two of those are among the fastest and best-built sites we measured — they simply never added it. For them it's a genuine, cheap opportunity rather than a problem.
Worth putting side by side, because the contrast is sharp and it explains something about both sectors.
In our separate study of 64 Dominican restaurants, 47% had a website of any kind and only 16% published a menu as readable text. Here, 86% of hotels ship structured data — a considerably more advanced technical step than simply having a page.
The difference isn't that hoteliers are more sophisticated than restaurateurs. It's that hotels sell a product that has to be bookable from another country, months in advance, by someone who will never phone ahead. That forces a web presence, and a web presence built by professionals arrives with the markup already in it. A restaurant's customer is standing in the same town and can walk in.
Which means the hotel sector's problem is maintenance, and the restaurant sector's problem is existence. Those need completely different advice, and lumping them together as "Dominican businesses need better websites" helps neither.
In order:
Audit what you're already shipping. Run your homepage through Google's Rich Results Test. You may find markup you didn't know was there, for features that no longer exist. Removing it costs nothing and is a reasonable spring clean.
Add rooms and rates. This is the real gap in the sector, and it's the markup that describes the thing you sell. It only works if the room and price information exists as text on the page first — you cannot mark up a PDF rate sheet.
Don't confuse it with a ranking strategy. Structured data doesn't lift you in results; it makes an already-competitive page eligible for a more prominent, more clickable one. Our data makes that point unusually plainly: the hotel with the best-performing website in the whole study has no structured data at all, and the hotels carrying the most of it are the slowest in the sample. Fix speed first. We looked at what's actually worth marking up here.
Then keep it accurate. Markup that says something different from your page is worse than no markup, and the fifteen FAQPage sites show how long stale configuration survives when nobody's job is to look at it.
It's worth ending the findings on what's working, because 86% adoption is genuinely good and it didn't happen by accident.
Structured data is invisible. No customer has ever complimented a hotel on its JSON-LD. It exists only because somebody, at some point, treated the website as infrastructure rather than as a brochure — specified it, built it properly, and shipped it. Whatever else our speed measurements found about this sector, that decision was made correctly across five sixths of it.
The failure isn't in the building. It's in the years afterwards, when nobody owned the site, Google retired a feature, and the markup for it sat there regardless. That's the same conclusion our performance data reached by a different route: these are competently built websites that nobody has looked at since.
Every figure here comes from a direct HTTP fetch of each hotel's homepage with a mobile user-agent on 6 September 2026, parsing the JSON-LD actually served. Performance figures come from Google's PageSpeed Insights API on the same day.
Three honest limits. We read homepages only — a hotel might carry rich room markup on its room pages that we never saw, and given the gap we found, that's a real possibility worth testing. The sample is 36 properties weighted toward large resorts, in the southeast, and is not nationally representative. And the performance correlation above is observational: we have not shown that either factor causes the other, and we don't believe it does.
The method is trivially repeatable and the tool is free, which is rather the point.
At DR Web Studio we generate structured data from a site's real content, so it stays accurate when prices and rooms change — and we build the page fast first, because markup on a slow site is decoration. If you'd like to know what your hotel is currently shipping, contact us for a free consultation and we'll test it and tell you what's working, what's retired and what's missing.









