The Problem With “Just Write It In the Box”
Most CMS content architectures for tourism websites share a common design flaw: they rely on rich text fields to store information that should be structured.
A partner listing in a typical legacy CMS has a few fixed fields — business name, category, phone number, address — and then a large “description” text area where all other information lives. The hours of operation are somewhere in that description. The amenities are mentioned in a paragraph. The price range is embedded in a sentence. The accessibility information, if it exists, is buried in the last paragraph.
This design is easy to build and easy for staff to fill in. It is very difficult for machines to read. When an AI retrieval system queries your partner database looking for “pet-friendly accommodations with a pool under $200 per night,” it cannot reliably extract that information from unstructured description text. The amenity is there, in words — but it is not structured as a queryable, filterable attribute. The machine cannot parse it with confidence.
Semantic content modeling is the discipline of designing CMS content types so that every piece of meaningful information is stored as a discrete, explicitly typed field — not buried in prose. The result is content that is equally readable by humans and machines.
What Semantic Content Modeling Means in Practice
A semantically modeled content type for a lodging partner listing might look like this:
| Field | Field Type | Maps To |
| Property Name | Text | Schema: name |
| Street Address | Text | Schema: streetAddress |
| City | Text | Schema: addressLocality |
| State | Text | Schema: addressRegion |
| Zip Code | Text | Schema: postalCode |
| Geographic Coordinates | Lat/Long | Schema: geo |
| Category | Select (Hotel / Motel / B&B / Vacation Rental / Campground) | Schema: @type |
| Star Rating | Number (1–5) | Schema: starRating |
| Price Range | Select ($ / $$ / $$$ / $$$$) | Schema: priceRange |
| Amenities | Multi-select taxonomy | Schema: amenityFeature |
| Pet Policy | Select (Yes / No / On Request) | Schema: petsAllowed |
| Accessibility Features | Multi-select taxonomy | Schema: amenityFeature (accessibility) |
| Phone Number | Phone | Schema: telephone |
| Website URL | URL | Schema: url |
| Booking URL | URL | Used by attribution engine |
| Hours of Operation | Structured hours (by day) | Schema: openingHours |
| Short Description | Text (160 char limit) | Used as meta description |
| Full Description | Rich Text | Used for editorial content |
| Featured Image | Media | Schema: image |
| Gallery Images | Media (multiple) | Schema: image array |
Every field is discrete. Every field maps to a Schema.org property. Every field is queryable, filterable, and exportable in a structured format. And because the field types enforce consistent data entry — a select field can only contain predefined values; a phone field validates phone number format — the data is clean and reliable across all records.
Compare this to a description field that says: “The Oceanview Inn is a charming boutique hotel on the waterfront. We offer ocean-view rooms with private balconies, a heated outdoor pool (open April–October), complimentary breakfast, and a pet-friendly policy for dogs under 25 lbs. Rates starting at $149/night. ADA accessible rooms available. Call us at (555) 123-4567.”
A human can read that and extract every relevant attribute. An AI retrieval system querying for “pet-friendly hotels with a pool under $200” can attempt to parse it — but must infer, and inference fails at scale.
The Content Types a DMO Needs to Model
A complete semantic content model for a Tourism Development Authority typically includes these primary content types, each with its own field schema:
Lodging Listing — Hotels, motels, B&Bs, vacation rentals, campgrounds. Fields: all attributes above.
Dining Listing — Restaurants, cafes, bars, food trucks. Fields: cuisine type, meal periods served, price range, reservation required, outdoor seating, dietary options (vegan, gluten-free), hours.
Attraction Listing — Museums, parks, landmarks, beaches, historic sites. Fields: attraction type, admission price, hours, accessibility, family-suitability, seasonal availability, estimated visit duration.
Tour and Experience — Guided tours, water sports, adventure activities, culinary experiences. Fields: activity type, duration, group size, price per person, booking URL, physical demand level, age restrictions.
Event — See AI-Ready Event Data Architecture for full field schema.
Itinerary — Multi-day trip itineraries. Fields: trip duration, traveler type (families, couples, adventure, cultural), geographic area, featured listings (linked entity references to Lodging, Dining, Attraction records).
Blog Post / Article — Editorial content. Fields: title, author, publication date, category, tags, featured image, estimated reading time, related listings (linked entity references).
Entity Relationships: The Knowledge Graph Layer
Semantic content modeling is most powerful when content types are linked to each other through explicit entity relationships — not just through internal hyperlinks in prose, but through structured data relationships in the CMS.
An itinerary content type that links to specific lodging, dining, and attraction records (rather than just mentioning their names in text) creates a structured relationship that AI retrieval systems can traverse. When a visitor (or an AI assistant) asks “What hotels are near [Attraction]?” the answer can be derived from structured proximity relationships in the data — not from a staff member having thought to mention it in a description.
Similarly, event records that link to their host venue record, which links to its geographic location and nearby lodging options, create a navigable knowledge graph that enables AI-accurate trip planning recommendations.
Building these entity relationships requires intentional CMS design: linked entity reference fields, not just text mentions. In a headless WordPress environment, this is implemented through custom post type relationships — ACF (Advanced Custom Fields) Pro’s relationship field, or WPGraphQL’s relationship queries — that create genuine data connections between content records.
The Maintenance Discipline: Keeping Structured Data Clean
Structured content models are only as valuable as the discipline applied to maintaining them. A semantic content model with 50% field completion rates is significantly less useful than a simpler content model with 95% completion rates.
Effective governance for structured content includes:
- Required fields enforced at the CMS level (some fields cannot be left blank)
- Data quality dashboards that surface incomplete records for staff review
- Partner self-service extranet design that guides partners through completing all relevant fields
- Annual content audits that identify and remediate stale or incomplete records
Consistency and completeness are what make structured data genuinely machine-readable at scale.
This article is part of the SimplicityCMO DMO Digital Ecosystem series. Return to the pillar article for the complete ecosystem framework.
Ready to redesign your content architecture for AI readiness? Request a digital ecosystem audit— we assess content modeling maturity as part of our five-dimension evaluation.