AI Ready: Our Structured Data Plugin Now Talks Directly to AI Agents

1. A Name That No Longer Told the Whole Story

For several years, we have run an internal WordPress plugin on nearly every hotel and restaurant website we build and manage. It was called Mixit7 Structured Data, and its job was simple to describe: driven by ACF fields, it generates the property's JSON-LD schema markup — Hotel type, Restaurant type, reviews and aggregate ratings via AggregateRating, business information via LocalBusiness, plus custom schema types when a property needs to describe something the standard types don't cover well. All of it with full multilingual support through WPML, because a schema that only exists in one language on a bilingual site is a schema that's only half done.

That name faithfully described what the plugin did in 2024. It no longer quite describes what it does today. We renamed it Mixit7 AI Ready, with a new description in its header: "Schema markup, Agent Readiness and AI discoverability for hotel and restaurant websites." This is not a marketing refresh chasing a trend. The plugin gained a genuinely new capability, and the name needed to catch up to that reality rather than the other way around.

2. What It Already Did, and Still Does

The rename took nothing away. Everything Mixit7 Structured Data did, Mixit7 AI Ready still does, and it remains the bulk of its day-to-day work. Full Hotel schema — address, GPS coordinates, star rating, amenities, check-in and check-out times. Restaurant schema — cuisine type, opening hours, price range. Reviews and aggregate ratings, properly structured as AggregateRating rather than only displayed as page text. Business information via LocalBusiness for properties that need it alongside the rest. And for the cases that don't fit neatly into any of those, the ability to define custom schema types directly from the WordPress admin, without touching code.

We still consider this the correct foundation. JSON-LD schema is a sidecar: a block of data next to the page that tells a search engine or AI system verifiable facts about the property, without the machine having to guess those facts from the rendered visual page. We've written elsewhere on this blog about how decisive this layer is for AI visibility. Nothing that follows replaces it. What follows sits on top of it.

3. The Real Shift: Content Negotiation

Here is what actually changed. When a page on one of our hotel sites is requested, the plugin now looks at who is asking. If the request's HTTP Accept header indicates that an AI agent or crawler prefers a lightweight text representation over a full HTML page, the plugin can respond with clean Markdown instead of the usual HTML. We also added a URL parameter, ?_m7md=1, that forces this Markdown response regardless of the header sent — useful for checking, at any time, exactly what an agent would receive if it requested the page right now.

This is content negotiation: the same URL, the same page, but two possible representations depending on who is asking and how. A human browser always gets the full HTML page, with its layout, images, JavaScript, and booking experience. An agent that sends the right signal gets a stripped-down version of the same content, without the visual scaffolding it has no use for and would likely misread or ignore anyway.

At the top of every Markdown response, a YAML front matter block carries the page's structured metadata — the content type, the property identifier, and depending on the case, other fields relevant to what the page represents. A simplified example for a room-type page:

---
type: room
hotel: "Le Grand Palais Hotel"
room_type: "Deluxe Garden View Suite"
capacity: 2
price_from: "290 EUR"
lang: en
---

# Deluxe Garden View Suite

45 sqm, king-size bed, garden views...

JSON-LD schema tells an AI: here are the facts about this page, in a standard vocabulary it already knows. Markdown-on-request goes further: it hands the agent the content itself, in the cleanest form possible, with less token waste and far less risk that it misreads HTML dressed up in CSS and JavaScript that was never meant to be read by a machine.

4. Markdown That Understands What It Describes

The easiest temptation, building a feature like this, would have been to write a generic converter: take the rendered HTML, strip the tags, flatten the result into text, and call it Markdown. We deliberately avoided that approach, because it produces text that is technically clean but semantically thin — an agent reading the result knows there is text, but not what that text represents.

Instead, the plugin has dedicated entity handlers, each one knowing how to represent a specific content type correctly rather than treating it as generic text. A room page goes through the rooms handler, which knows how to extract and present square footage, capacity, starting price, and room amenities — not just the descriptive paragraphs, but the underlying structure those paragraphs describe in human language. A restaurant page goes through its own handler, which knows to surface opening hours, cuisine type, and the reservation link distinctly from the page's generic content. FAQ content goes through a handler that preserves the question/answer structure rather than diluting it into one continuous block of text. Business and contact information — address, phone, hours — goes through its own handler, which knows what each of those fields means rather than treating them as just more lines of text.

That distinction matters. An agent that needs to answer "does this hotel have a room for two with a garden view under 300 euros a night" does considerably better with Markdown that preserved the price / capacity / features structure than with a paragraph of touristic prose mechanically converted to plain text. WPML support carries over here too: the Markdown version respects the language of the page requested, exactly as the JSON-LD schema already does.

5. The Details That Make the Difference

Several practical cleanups came bundled into this shift, each modest on its own but real in its cumulative effect.

• Booking-link cleanup in the Markdown output, so an agent receives a clean, working booking URL rather than a link loaded with tracking parameters that mean nothing outside the context of a browser session.
• E.164 international phone number formatting (+33...), so an agent — or a future system capable of dialling a number — doesn't have to guess the country code from a number written in local notation.
• GDS distribution code support, for properties that want to expose their Sabre, Amadeus, or equivalent identifiers to systems that make use of them.
• A new admin page, "Agent Readiness," that shows exactly what is being exposed to AI agents for each page — not an abstract estimate, but an actual preview of the Markdown output and front matter as an agent would receive them today.

That last admin page matters more than it sounds. A site's invisible layer is only useful if someone can check its state without guessing. Before, the only way to know what an AI agent might extract from a page was to read the rendered HTML and imagine how a machine would interpret it. Now, you can simply look at the actual output.

6. Why This Layer Matters

We see this feature as a concrete, already-working example of what some call the agentic web — a web where machines increasingly no longer just index pages built for humans, but request and receive a lightweight representation built specifically for them. This isn't an abstract prediction. It's behaviour you can observe today, sitting right there in the request's Accept header.

This layer adds to what we have argued for consistently on this blog; it does not replace it. robots.txt determines whether an agent can access the site at all. JSON-LD schema tells it structured facts about what it finds. llms.txt tells it how to work with the site's content as a whole. Markdown-on-request goes one step further: it hands the agent the content itself, stripped of everything that was only ever meant for human eyes and a browser. Each of these layers answers a different question. None of them makes the others optional.

This is what we built for the sites we manage, and it is what runs today, quietly, every time a properly identified AI agent requests a page on one of them.