Somewhere in a post you've already published, there's probably a chart no crawler has ever read. Your readers see the number every day. Search engines index an empty frame where it sits. Which of those two outcomes you shipped was settled the moment you pasted the embed code, and almost nobody picks that snippet on purpose.
Which embed method to use is a choice between three ways of putting the same live chart on a page. A raw iframe drops the chart into a separate document nested inside yours. An inline script loader runs on your page and builds the embed there. oEmbed lets you paste a bare URL and have the platform expand it. All three produce the same pixels, and they part ways on a single axis: whether the host page ends up holding the chart's numbers as text it owns.
What the Embed Method Decides
Every method on the list gives the reader an interactive chart. Tooltips, hover states, live data, all of it works whichever snippet you paste. So the visible result tells you nothing about which method you chose, and that's exactly why the choice goes unmade. The feedback loop ends at "it renders."
The consequential differences sit below the render. Four things vary by method: whether your page gains crawlable text for the number, what happens when the embed breaks, how much setup the method demands, and which platforms accept it at all. The first carries the most weight, because search engines and AI models read pages as text. The other three decide when a method that loses on the first axis is still the right call.
Iframe SEO Impact
Are iframes bad for SEO? For a chart whose number you want found, yes: a raw iframe walls the number inside a child document, the host page contributes no text where the chart sits, and a crawler indexing your post reads the wall.
MDN describes an iframe as a way to "embed an entire web document inside another one," and that sentence contains the whole problem. The framed document is a complete second page. Your post carries its weight without owning a word of it, so whatever credit that number could earn lands on the framed page instead of yours.
Performance is the older complaint. MDN calls page load time "an important SEO metric" and recommends setting the iframe's source with JavaScript only after the main content has loaded, purely to keep the frame from dragging on that metric. Even the reference documentation treats the iframe as something to defer.
The cost compounds once answer engines enter the picture. A model assembling an answer works from the text of the page it fetched, and an iframe hands it a sealed box. That mechanism explains a lot of why AI cites third-party sources over the site that produced the data, and it makes the embed snippet an unlisted input to answer engine optimization. A number the model can't read is a number it will never attribute to you.
Where the Raw Iframe Wins
Isolation is a real feature when isolation is what you want. Nothing on the host page can reach into the frame and break the chart: no stylesheet collision, no script conflict, no loader behavior to keep up with. The contract has been stable in browsers for decades, so you paste it once and forget it exists. When the embedded content was never supposed to count as the host page's own words, on a partner's site, inside a dashboard, anywhere durability matters more than indexing, the raw iframe is the honest pick, and it's the one method I made sure we kept when we built all three. Publishers just tend to reach for it by reflex in the two situations it serves worst: data they want crawled, and data they want an answer engine to cite.
The Inline Script Embed
Order of operations is the whole trick. The loader runs on your page, immediately fetches a content fragment, and writes the chart's key facts into your markup as ordinary text. It also injects the chart's structured data into your page's own <head> as JSON-LD. The interactive frame comes last, loaded lazily when the reader scrolls the chart into view. By the time anything visual happens, the crawlable version of the number already exists in your document.
A crawler that never renders a thing still reads the figure. A reader who scrolls to the chart still gets the live version. Neither waits on the other.
Failure handling is what earns this method the recommendation. The frame boots invisibly behind the painted text, and the swap happens only on the first signal that the frame actually rendered. If the frame never comes up, the text stays where it is: readable, indexed, on your page. Your published number survives a total embed outage. That behavior is what it means to treat embeds as part of your living content infrastructure, and it's the constructive half of how to get cited by AI search: the figure inside your post becomes text your page earns credit for.
What Renders as Text and What Stays a Frame
The loader treats asset types differently, and the difference decides what gets indexed. Living Content blocks, claim pages, and experiments arrive as text and stay text, fully indexable. Polls and charts get a two-layer treatment: the facts paint as crawlable text while the chart itself remains an interactive frame the reader can touch. For a chart, the text layer is what your page gets indexed for, and it's real markup you can see in the page source.
Iframe vs oEmbed
oEmbed wins on friction, and on some surfaces it wins outright. Paste a LiquiChart URL on its own line in WordPress, Medium, Notion, Slack, or Discord, and the platform calls the oEmbed endpoint and expands the link into the live chart on its own. No snippet. No script tag. One URL.
What comes back from that endpoint is worth reading once. The response is JSON with type:"rich", and its html field contains an iframe. The platform renders that iframe. So everything a raw iframe does to your page's crawlability, oEmbed does too, one layer of convenience later: sealed child document, no text on the host page, no credit for the number.
The inheritance narrows where oEmbed belongs without disqualifying it. On a platform where you can't run scripts anyway, the inline loader was never available, and oEmbed against a hand-pasted iframe is a wash for crawlability and a clear win on effort. Pick it there, with open eyes about what the response contains.
One Chart Three Ways
This page embeds one real published chart with all three methods at once. The asset is identical in each spot: a chart measuring how much of a post's data has gone out of date at each post age. The only variable is the snippet.
The inline script version comes first. The chart below is live and interactive, and its facts were written into this page as text before the frame ever loaded:
View this page's source and the chart's numbers are sitting in the markup, with the structured data injected into the head. A crawler reads them without rendering anything.
Next, the raw iframe snippet, exactly what you'd paste by hand. It draws an identical chart and adds nothing this page can be indexed for, because every word and number inside it belongs to the framed document:
<iframe
src="https://www.liquichart.com/embed/chart/aged-data-curve-by-post-age-VuPJVmYm"
style="width: 100%; height: 550px; border: none; border-radius: 8px;"
title="The Older the Post, the More of Its Data Is Out of Date"
loading="lazy"
referrerpolicy="origin"
allow="fullscreen"
></iframe>
Last, the paste-a-URL path. This is the actual JSON the oEmbed endpoint returns when a platform expands this chart's URL:
{
"type": "rich",
"version": "1.0",
"title": "The Older the Post, the More of Its Data Is Out of Date",
"provider_name": "LiquiChart",
"provider_url": "https://www.liquichart.com",
"width": 600,
"height": 550,
"html": "<iframe src=\"https://www.liquichart.com/embed/chart/aged-data-curve-by-post-age-VuPJVmYm\" style=\"width:100%;height:550px;border:none;border-radius:8px;\" title=\"The Older the Post, the More of Its Data Is Out of Date\" loading=\"lazy\" referrerpolicy=\"origin\" allow=\"fullscreen\"></iframe>",
"cache_age": 3600,
"thumbnail_url": "https://www.liquichart.com/chart/aged-data-curve-by-post-age-VuPJVmYm/opengraph-image",
"thumbnail_width": 1200,
"thumbnail_height": 630
}
The html field is the tell. The easiest method resolves to the same sealed frame as the manual paste. The chart rendered three times on this page, and this page can take credit for exactly one of those renders.
Which Embed Method to Use
Match the method to where the content has to count. The inline script loader is the default for any published number you want crawled and cited, which for most publishers covers most of what they embed. The raw iframe fits embeds that need isolation and zero maintenance, on surfaces where indexing was never the goal. oEmbed earns its place on platforms that support it and offer nothing better, taken with full knowledge of what its response carries.
If the question underneath yours is how to get the interactive layer onto your posts at all without touching code, making blog posts interactive covers that on its own. The method question sits underneath whichever path you take.
You've now watched all three run on one page. Before the results below show you what your peers paste, which snippet do you actually reach for?
Every method on the list renders the chart, which is why the choice can feel finished the moment the picture appears. As readers weigh in above, the difference that never shows up on screen, the one that only surfaces when something tries to read the page later, will come into focus.
However the results settle, the habit answer and the deliberate answer produce identical-looking pages, and only the page source tells them apart.
The Snippet Is the Decision
You didn't come here worried about whether the chart would render. All three methods handle that, and the platform-by-platform setup is a solved problem with its own walkthrough in how to embed a live chart. What you were choosing, the whole time, was whether the number inside the chart exists on your page as text a crawler and an answer engine can hold you credited for.
The shortest snippet is the one I trust least for data I want found.
A chart a crawler can read is a claim your page gets to make. A chart it can't read is only a picture.