Raw HTML Block: Quick Wins, Hidden Costs

If you support enough Optimizely CMS and Commerce websites, you will eventually meet one of the most powerful blocks in the system: Raw HTML Block.

It may also be called Plain HTML Block or simply HTML Block. I sometimes call it the emergency exit. It is very useful when you truly need it. It is also a reliable way to create future problems when people start using it as the front door.

This post is not an argument that Raw HTML Block should never exist. It is an argument that it should stay rare, temporary, and carefully controlled. It is also a practical look at why converting most Raw HTML Blocks into proper UI components usually costs less than people expect.

Why customers like it

To be fair, the attraction is obvious.

Raw HTML Block feels:

• Fast.
• Convenient.
• Cheap.
• Independent from the development backlog.

If a team needs to embed a report, add a campaign widget, test a one-off layout, or hotfix something on production, the block looks like the shortest path from idea to live website.

Sometimes, that is true.

When it is actually appropriate

There are a few cases where Raw HTML Block is genuinely useful.

1. Emergency production hotfix

You deploy a feature. It works in development and UAT. Then production traffic, real tracking scripts, a certain browser version, and a very specific device combination decide to form a union against you.

In that situation, a temporary HTML or script patch can be a lifesaver. If the site already has a safe place for a global hotfix, editors can apply a short-term fix while the development team prepares a proper code change, tests it, and deploys it.

That is a good use of Raw HTML Block.

The important detail is this: temporary means temporary.

2. Urgent third-party embed

Marketing buys a service on Tuesday and wants it visible by Wednesday. A third-party vendor provides an embed snippet. There is no existing component for it. The team needs something on the page quickly.

Again, Raw HTML Block can be a practical bridge.

But a bridge is not the same thing as a permanent building.

3. A true one-off experiment

Sometimes a piece of content is genuinely short-lived, narrowly scoped, and unlikely to be reused. In that case, building a polished reusable component may be unnecessary.

Even then, it is still worth asking one uncomfortable question: are we absolutely sure this will stay a one-off?

Website history says the answer is often no.

Where it starts going wrong

Raw HTML Block usually causes trouble not on day one, but six months later, when nobody remembers why it was added and everyone assumes somebody else understands it.

That is when the "quick solution" starts charging interest.

Hidden dependency on production

When a production hotfix works, it often stays there. It is no longer urgent, so it quietly disappears from planning. Over time, the development team may not even know it exists.

Later, new features are built and tested without considering that hidden HTML, CSS, or JavaScript already living on the production site. Then a release goes live and unexpectedly collides with the forgotten snippet.

The result is not always dramatic. Sometimes it is worse: subtle layout issues, broken tracking, inconsistent behaviour, or a bug that only happens on one page that one editor updated three quarters ago.

Those are expensive to investigate.

Design drift

Editors are trying to solve real business needs, so they naturally make local improvements. A blue button becomes a darker blue button. Another page uses green. A campaign page uses a custom font size. A later campaign uses inline spacing that almost matches the design system, which is somehow more dangerous than not matching it at all.

None of those decisions are unreasonable in isolation. Together, they slowly turn a site into a museum of historical opinions.

When the business later wants a redesign or brand refresh, every custom HTML block becomes a manual cleanup task.

Hard to find, harder to retire

A proper block tells you what it is. A YouTubeBlock is clearly a YouTube block. A ReportEmbedBlock is clearly a report embed.

A Raw HTML Block tells you almost nothing.

Is it a video? A tracking script? A pricing table? A temporary campaign widget? A mysterious copy-paste from a vendor PDF at 4:45 PM on a Friday?

When a third-party service is retired, renamed, or no longer paid for, it becomes difficult to find every place where that embed was used. Old snippets remain in forgotten pages, and eventually somebody notices a broken frame or a console error in production.

The person who understood it left

This one happens more often than teams like to admit.

At some point, one editor or one developer knew exactly why a Raw HTML Block was added, what it depended on, and what would happen if it changed.

Then that person changed role, went on leave, or left the company.

Now nobody is fully confident about removing the snippet, nobody is eager to edit it, and nobody can say for sure what it might break. The block becomes a small monument to lost institutional knowledge.

On a long-lived website, that is not an unusual edge case. It is the default direction of travel.

Safety and quality risks

This is the least funny part.

Raw HTML does not only introduce styling risk. It can also introduce:

• Accessibility problems.
• Performance regressions.
• Security concerns.
• Privacy and compliance risks.
• SEO inconsistency.
• Analytics conflicts.

An editor pasting a snippet is not doing anything wrong. They are using the tool available to them. The real issue is that the snippet bypasses the normal engineering checks that would usually protect the site.

That means no typed model, no validation, no code review, no consistent sanitisation rules, no automated tests, and often no clear ownership.

That is a lot of trust to place in a copy-paste operation.

It should also raise different concerns for different stakeholders:

• For content and marketing teams: a quick embed can quietly create brand inconsistency, broken campaigns, or accessibility issues on important pages.
• For technical teams: raw HTML introduces production-only behaviour that is difficult to test, debug, and support.
• For engineering managers: this creates delivery risk, hidden maintenance cost, and knowledge that lives in content instead of the codebase.

CMS upgrades become riskier

This one is easy to overlook.

When the CMS itself is upgraded, proper components go through a structured migration process. Developers can update them systematically and test them as part of the upgrade.

Raw HTML Blocks do not. They sit quietly in content and only reveal problems later, when the upgrade is already live. If the surrounding markup changed, if a CSS class was renamed, or if a JavaScript dependency behaves differently, the raw snippet may silently stop working.

More raw HTML means more risk during every platform upgrade.

A very small CSS example with very large consequences

I have seen cases where an editor only wanted to change the text colour inside an embed, so they added this:

p {
  color: crimson;
}

At first, nothing dramatic happened.

Why? Because the page already had a more specific rule elsewhere, something like this:

main p {
  color: var(--black);
}

So the new rule did not seem to break anything. In a strange way, the site was protected by accident.

Then came the next step. The editor knew enough CSS to know that !important could force the change, but not enough about CSS specificity and priority to realise that this was the point where a local tweak could turn into a page-wide problem. So the CSS was updated to this:

p {
  color: crimson !important;
}

And there it was: the universal emergency wrench, applied directly to the plumbing.

That was the moment the damage began, because the rule was no longer politely ignored. It started overriding paragraph styling far beyond the original embed.

In this particular case, the issue was visible and quickly reverted. That is the lucky version. The unlucky version is broken spacing, hidden buttons, inaccessible contrast, tracking problems, or JavaScript side effects that nobody notices until customers do.

The most common incorrect assumption

The most common assumption is that keeping Raw HTML Block is cheaper than converting it into a proper component.

Short term, sometimes yes.

Overall, usually no.

Why? Because the cost is not mainly in creating the first version. The real cost shows up later in support, debugging, regression testing, content inconsistency, production surprises, and manual cleanup.

What looks like saving one small development task can easily become several larger support tasks spread across multiple teams.

That is not cost reduction. That is cost relocation.

And because those later costs are usually paid in production incidents, emergency investigations, and unplanned manual work, they are often paid by the most expensive people in the room.

Converting to a proper component is often cheaper than it sounds

Customers sometimes hear "UI component" and imagine a full design exercise, complex backend logic, database work, performance reviews, and a large QA effort.

In many cases, that is not what this work looks like at all.

If the Raw HTML Block already proves what the rendered output should be, then the development task is often quite small: capture the meaningful inputs, validate them, and render the same markup in a controlled way.

For example, suppose the current Raw HTML Block embeds a YouTube video:

<iframe
    width="560"
    height="315"
    src="https://www.youtube.com/watch?v=dQw4w9WgXcQ"
    frameborder="0"
    allowfullscreen>
</iframe>

The proper block model may be as simple as this:

public class YouTubeBlock
{
    public string VideoId { get; set; }
}

And the view may be just as small:

<iframe
    width="560"
    height="315"
    src="https://www.youtube.com/watch?v=@Model.VideoId"
    frameborder="0"
    allowfullscreen>
</iframe>

That is not a huge reinvention effort. It is mostly packaging an existing idea into something safer and easier to maintain.

Once that is done, the benefits are immediate:

• Editors can use it safely without touching raw markup.
• Validation can reject bad input before it reaches production.
• The design stays consistent across every instance.
• Future styling changes happen in one place instead of ten.
• Usage can be tracked much more easily.
• The development team can test and support it properly.
• CMS upgrades become safer because the component lives in the codebase.

Most importantly, the business gets speed and stability instead of being forced to choose between them.

What about editor experience?

This point is easy to miss but matters a lot in practice.

When editors use Raw HTML Block, they are effectively working in a tiny code editor. They need to understand, or at least avoid breaking, HTML syntax, CSS specificity, and JavaScript embedding.

When editors use a proper component, they get a cleaner editing experience: a text field for a video ID, a dropdown for a report type, or a date picker for a campaign expiry. The CMS handles the rendering. The editor focuses on content, not markup.

If the goal is to help editors move quickly and independently, proper components usually achieve that better than a blank HTML textarea.

A practical rule of thumb

If the content is any of the following, it probably deserves a proper component:

• Reused more than once.
• Expected to live longer than a short campaign.
• Important to branding.
• Important to accessibility or compliance.
• Powered by third-party scripts.
• Likely to be edited by multiple people over time.
• Expected to survive a CMS upgrade or platform migration.

If it is truly temporary, then treat it like temporary work:

• Record why it was added.
• Record where it is used.
• Add an owner.
• Add a review date.
• Remove it when the proper component is ready.

Without that discipline, temporary content has a remarkable talent for becoming permanent.

What we recommend

This does not need to become a dramatic cleanup program.

A practical approach is usually enough:

1. Audit the existing Raw HTML Blocks and identify what each one does.
2. Classify them into still needed, outdated, duplicate, or already replaceable.
3. Prioritise the highest-risk and most-reused ones for conversion first.
4. Agree a simple governance rule for future use: when it is allowed, who approves it, and when it must be reviewed for retirement.

Even converting a handful of common Raw HTML Blocks can improve site stability, editor confidence, and long-term maintainability.

Final thought

Raw HTML Block is not evil. It is just dangerously good at saying yes.

And on a busy project, a tool that always says yes can become very expensive.

Used sparingly, it is helpful. Used casually, it becomes a source of hidden risk, inconsistent experiences, and avoidable maintenance cost.

So if a customer asks whether they can keep using Raw HTML Block because it is quicker, more convenient, and cheaper, my answer is gentle but consistent:

Yes, it is quick.

Yes, it is convenient.

No, it is usually not cheaper once the full lifetime cost of the website is included.

For anything that matters, and on a business website most things matter, a proper component is almost always the better bargain.