Use Wistia LLM Embeds for SEO & AI Visibility

Most crawlers behind AI assistants — ChatGPT, Perplexity, and similar tools — don't run JavaScript when they read a page. Because the standard Wistia player builds itself with JavaScript after the page loads, an AI crawler sees an empty container where your video should be. To that crawler, the video effectively isn't there.

The LLM-friendly embed solves this. It's an inline embed that writes your media's full transcript directly into the page's HTML, so crawlers that don't run JavaScript can still read what your video is about. It also always includes your SEO metadata. Visitors still get the normal, fully interactive Wistia player — the extra content is invisible to them and gets replaced by the player as soon as it loads.

This page explains what the LLM-friendly embed does under the hood, when it helps, and the caveats to plan for when you place it on a site. To copy the embed code itself, see Wistia Large Language Model Embed Codes in the Help Center.

What the LLM-friendly embed adds

A standard inline embed drops a <wistia-player> element on the page and loads player.js, which builds the player with JavaScript. The LLM-friendly embed is the same inline embed with two guarantees baked in:

1. The transcript is written into the HTML. Your media's transcript is server-rendered as plain text inside the <wistia-player> element, so it's present in the raw HTML before any JavaScript runs.
2. SEO metadata is always on. The embed injects Schema.org VideoObject structured data (JSON-LD) — title, description, thumbnail, duration, upload date — every time. Unlike the standard inline embed, there's no toggle to turn it off.

So the LLM-friendly embed is additive: you keep everything the SEO-enabled standard embed gives you, plus a machine-readable transcript for tools that don't execute JavaScript.

The transcript is captured at the moment you copy the embed code — it's baked into the HTML, not fetched live. If you later edit or re-transcribe the media, the embed won't update on its own; you'll need to copy a fresh LLM-friendly embed and replace the old one.

The rendered embed looks roughly like this:

<script src="https://fast.wistia.com/player.js" async></script>
<script src="https://fast.wistia.com/embed/abc123.js" async type="module"></script>
<wistia-player media-id="abc123" aspect="1.7777">
  <div class="wistia_preload_transcript_outer_wrapper">
    <div class="wistia_preload_transcript_inner_wrapper">
      <p class="wistia_preload_transcript_text">Full transcript text renders here…</p>
    </div>
  </div>
</wistia-player>

The transcript <div> lives inside the player element. When player.js loads, it replaces the element's contents with the interactive player, so a human visitor never sees the raw transcript.

Does it keep my SEO metadata?

Yes — always. The LLM-friendly embed includes the standard Schema.org SEO metadata by default and gives no option to turn it off. Choosing it never costs you the SEO data you'd get from a standard SEO-enabled embed; the transcript is added on top.

This addresses a common worry that switching to the "LLM version" trades away SEO for AI-readability. It doesn't — you get both.

What happens when a media has no transcript

The transcript block is only written when the media actually has a transcript. If a media has no transcript, the LLM-friendly embed renders with no injected transcript text — it falls back to a plain inline embed with SEO metadata.

This matters for media with no spoken audio — a screen recording, a silent product demo, an animation with on-screen text only. Wistia transcribes spoken audio, so a media with nothing spoken produces no transcript, and there's nothing for the LLM-friendly embed to inject. Since the whole point of the embed is to give crawlers readable transcript content, it adds little over a standard SEO embed on that kind of media.

If you want AI crawlers to understand a silent video, add a transcript first (you can upload or edit one in Wistia), then use the LLM-friendly embed. Your SEO metadata still injects either way, so there's no harm in using it — just no transcript benefit until a transcript exists.

Placing it on a CMS or page builder

Because the transcript is real HTML sitting inside the player element, two things can happen on some sites before player.js finishes loading and swaps in the player:

• The transcript text can flash briefly. The raw transcript block is styled to be tiny and visually recessed, but it's still in the DOM until the player takes over. On a slow connection or a heavy page, it may be visible for a moment.
• A page builder's CSS can collide with it. WordPress page builders like Elementor apply their own container widths, layout rules, and styles. Those can interact with the transcript wrapper — collapsing the video area, letting surrounding elements run into it, or in some cases interfering with the player mounting at all.

If you hit layout problems or the player doesn't appear inside a page builder:

• Paste the embed into a raw HTML / custom code block, not a rich-text or "video" widget, so the builder doesn't rewrite or wrap the markup.
• Check whether the builder's container has a fixed height or aspect ratio fighting the embed's own sizing.
• If the conflict persists, a standard SEO-enabled inline embed is a reliable fallback — you keep the SEO metadata and avoid the injected-transcript markup that's triggering the conflict.

When to use it

Reach for the LLM-friendly embed when:

• The media has spoken content and therefore a transcript to expose.
• You want AI assistants and crawlers that don't run JavaScript to be able to read and cite the video's content.
• The page renders on a platform where you can drop in a raw HTML block cleanly.

A standard SEO-enabled inline embed is the better choice when the media has no transcript, or when a CMS/page builder mangles the injected-transcript markup and you'd rather keep the layout clean.