How to Publish an Interactive Story on a CMS (October 2026)

To publish an interactive story on a CMS, you build the interactive in an interactive-capable editor, store it in the CMS as a dedicated content type, then deliver it to the page through an iframe, a lightweight script loader, or a native CMS block. The CMS handles the headline, metadata, workflow and distribution; the interactive renders inside your site’s template while staying separately managed.

The part that trips people up is not the embed code. It is deciding early which of four publishing routes to take, because a quiz and a scrollytelling explainer want very different setups. Get that wrong and you are still fixing layout shift on mobile a week after launch.

This guide walks through the whole route: what you need before you start, the eight steps from format decision to monitoring, the platform specifics for WordPress and Drupal, and the failure modes that show up in week two. It is written for journalists, editors and newsroom developers who need a repeatable workflow rather than a one-off demo.

What You Need

Six things have to be in place before you write a single line of embed code. Checking them early is the difference between a story that ships in a day and one that stalls in someone’s ticket queue.

• CMS capability. You need to know whether your CMS lets an editor create a custom content type, drop in a repeatable block or field, and host media with predictable URLs. WordPress and Drupal both do this. A limited CMS that only accepts article body text will force you into an iframe, which works but hands you fewer styling and analytics options.
• Editorial inputs. Headline, standfirst, section, tags, publish date, author and social image. Gathering these first means the story can move from draft to scheduled without a second pass.
• The interactive asset. A visualization, map, timeline, calculator, quiz, branching narrative or data story, already built and tested on a phone. If it only works on a desktop browser at full width, it is not ready.
• Developer time, in hours. Even an iframe needs someone to add it to a template, set a sensible height, and confirm nothing above it shifts when it loads. Budget a few hours the first time and close to zero after that.
• Analytics and consent handling. Decide whether engagement events go into your existing analytics, a separate cookieless tracker, or both, and confirm your consent banner covers any third-party script.
• A hosting decision. Does the interactive live on your own domain, on a vendor’s CDN, or on a subdomain? Each option changes how you handle updates, cookies and what happens if the vendor changes something.

Accessibility requirements are worth adding to that list before you start, not after. If your story needs captions, a text alternative or keyboard access, that decision shapes the build in step two rather than creating a rewrite later.

Step-by-Step: How to Publish an Interactive Story on a CMS

1. Define the story format and publishing goal

Start with the reader’s action, not the technology. A reader choosing an answer, scrolling through a narrative, tapping a map pin or watching a liveblog update are four different products with four different technical needs.

Then pick the delivery route. Four options cover almost everything newsrooms do:

• Native custom post type or content type. You build it into the CMS. Most control, cleanest URLs, best SEO, highest upfront development cost.
• Plugin or module. Someone has already built the block. Fastest route, but you inherit whatever quality the plugin maintains, and conflicts with other plugins are common.
• Headless build. The CMS stores structured content and a separate front end renders it. Best performance and design flexibility, weakest WYSIWYG preview for editors who write in a visual editor.
• Third-party interactive platform. Shorthand, Timepath and similar tools let a reporter assemble the story in a visual editor and publish to your domain or embed it. Fastest time to first publish, and the strongest lock-in.

Your editorial team’s appetite for developer time is the tiebreaker. If you can get roughly a week of developer attention per quarter, native or headless is worth it. If every story waits on a backlog, buy the time back.

2. Prepare the interactive asset

Build or commission the interactive as a standalone piece first, with its own stable URL. Publishing it live on its own address before it goes into your CMS template gives you something to test against and something to link to if the embed fails.

Three requirements matter more than anything else in this step. The interactive must be responsive from about 320 pixels wide upward, must have a useful non-interactive fallback so a reader with JavaScript blocked still gets the point, and must declare its own height or use an auto-resize message so the page below it does not jump.

For a code-based build, reserve a fixed or calculated height rather than relying on the default 150-pixel iframe. A reservation of 480 pixels for a scrollytelling block and 640 pixels for a full-bleed map will save you a layout shift every time.

Keep the asset portable. If the whole thing is one JavaScript bundle with a hard-coded domain inside it, you have locked yourself into whatever the current platform is. Storing story data as JSON or a structured export is what lets you migrate later.

3. Create the CMS story and define its metadata

Create the story page and select the template designed for interactive content, not the standard article template. Fill in the headline, standfirst, author, section and tags, and set the publication date.

Metadata is where most of the SEO value sits, and it is the part that is easiest to skip. Write a real description rather than leaving the excerpt blank, because a search result with no snippet underperforms one with a plain summary of the story. Add structured data for the content type you used: Article for a data story, Quiz for a quiz, LiveBlogPosting for live coverage.

Set a canonical URL on the page. Without one, a story that also exists on a vendor domain can split your ranking signals across two pages instead of consolidating them.

4. Add the interactive block or embed

Place the interactive below the standfirst and above the supporting text, so a reader knows what they are looking at before the page starts moving. Enter the embed code into the block that handles raw HTML, and keep your explanatory paragraphs outside it.

There are three embed levels, and they are worth understanding even if you only use one.

An iframe embed is one line and works nearly everywhere:

<iframe src="https://interactive.example.com/story/harbour-survey" width="100%" height="640" style="border:0" title="Harbour survey interactive" loading="lazy"></iframe>

A script loader injects the interactive into a container and auto-resizes as the content grows. It gives you tighter styling control and better Core Web Vitals than a fixed iframe, at the cost of the vendor’s script running on your page:

<div data-interactive-id="harbour-survey" data-interactive-host="https://interactive.example.com"></div>
<script async src="https://interactive.example.com/loader.js" data-interactive-id="harbour-survey"></script>

A native component is a block built into your own front end. It is the fastest for readers and the hardest for your team to maintain, because someone owns that component forever.

5. Write the editorial context around the interaction

An interactive with no framing confuses people. Tell the reader what they are meant to do, why it matters, and what they should take away.

Most teams use a short paragraph before the block, a methodology note after it, and a source line. Something like: “Tap a pin to see what each sampling site recorded. Scroll to move through the year.” Then below, say where the data came from and when it was last updated.

Write that surrounding text so the page still makes sense if the interactive never loads. It is insurance against a broken third-party script, and it also gives search engines something to index.

6. Test the experience across devices and browsers

Testing is where most interactive stories lose their polish. Run through this list before anyone hits publish, and do it on a real phone rather than a browser’s device emulator, which hides touch and performance problems.

• Layout at 320, 375, 768 and 1280 pixel widths, with no horizontal scrolling.
• Touch targets large enough to hit with a thumb, and no gesture that conflicts with normal page scrolling.
• Loading speed on a mid-range Android device over mobile data, not office wifi.
• Images sized correctly, video using captions, and any chart readable without relying on colour alone.
• The interactive still appears when third-party scripts are blocked.
• Page layout below the embed does not shift once the interactive loads.

Check Safari as well as Chrome. Custom elements and viewport behaviour differ enough that iOS is where a good number of these problems surface first.

7. Review accessibility, privacy, and security

Keyboard access is the first thing to test and the most commonly missed. If a quiz cannot be completed with a keyboard alone, or a scrollytelling piece hides content from focus order, it is not ready for a public-sector or accessibility-regulated audience.

Provide a text alternative that carries the same information as the interaction, a transcript for video and audio, and captions on everything with speech. Screen reader users need a label on the embed container that says what it is, which comes from the title attribute in the iframe or an aria-label on the wrapper.

On privacy, check what cookies and local storage the third-party script sets, and confirm your consent banner actually covers it. A tracker loading before consent is a compliance problem, not a preference.

On security, restrict which HTML tags and attributes the embed field accepts. An unfiltered field on your CMS is an injection point, and newsroom sites are attractive targets because they sit behind a login sometimes and take contributions from many people.

8. Publish, distribute, and monitor the story

Send the story through preview approval, then publish immediately or schedule it. Confirm the live URL loads the interactive correctly in a hard refresh, since cached pages sometimes serve an older template.

Distribute it where the story belongs: your homepage or section front, newsletters, social, and any internal channel where a related piece lives. Interactive formats usually earn a longer dwell time than text, so the newsletter summary should earn its click rather than trying to do the story’s job.

Set up tracking before you publish, not after. You want story start, interaction start, interaction complete, and return-to-article events, and you want to know which one your audience actually reaches.

Then plan the update path. Someone should own the story after launch, with a documented way to revise the copy, swap an asset, correct a fact, and unpublish. Live coverage in particular needs an owner before it starts, not after it ends.

Common Mistakes

Most of these are not exotic failures. They are the same five or six problems, repeating, and each has a straight fix.

The embed breaks after a theme or plugin update. A new plugin version changes the container markup, or a theme update changes the container width, and the story silently renders at 300 pixels in the corner. Pin the versions you depend on, and add a scheduled check on any high-traffic interactive rather than assuming it still works.

Layout shift from the embed. If the iframe has no reserved height, everything below it jumps once the script loads. Reserve the height, use lazy loading on stories below the fold, and keep the reserved value close to the real height.

The story is only readable with JavaScript. If the page says “tap here to explore” and nothing happens for a reader with scripts blocked, you have published an empty article. Write the core finding into the surrounding text and offer a link to the standalone version.

Interactive work becomes uneditable. If the story lives only inside a vendor’s editor and nobody at the newsroom owns the account, you cannot correct a fact quickly. Assign ownership, keep an export of the source data, and document the login location somewhere other than one person’s inbox.

The CMS holds a copy nobody maintains. Teams often build the interactive, publish it once, and never return. Put interactive content on the same review cycle as your other journalism, with a last-checked date in your CMS.

Performance budget ignored. A 3MB bundle and four trackers will show up in your field data within days. Load third-party scripts asynchronously, cut what you do not need, and check the real numbers after 48 hours rather than trusting a lab test.

Headings and links inside the embed are invisible to search. Text inside a cross-origin iframe is not indexed like page content. Your headline, summary and methodology have to carry the SEO weight, which is a good reason to write them well in step five.

Frequently Asked Questions

Conclusion

Pick the publishing route first, build the interactive as a standalone piece second, and do not send it live until someone has clicked through it on a phone and finished it with a keyboard.

If you want a starter checklist: confirm your CMS supports a custom content type or an HTML field, register the interactive with a stable URL, reserve the embed height in your template, write the summary and methodology into the page, run the device and keyboard test, then schedule the publish and assign an owner. That sequence takes about half a day for a plugin-based story once the pattern exists, and it is the part of the workflow that stops breaking at 2am.