Purpose-Built Templates

ZU2B Blueprints

Business in a Box

  • Purpose-built launch kits for local service businesses — website, copy, prompts, SEO, and more.
  • Local Launch Kits →

Website Widgets

  • Working features you install once and own outright — no plugin, no subscription.
  • Chat Widget — Coming Soon

Reference

ZU2B Pulse™

See what visitors experience before they leave — paste any public URL and get a plain-English performance report in seconds.

Scan Your URL Free

Why Adding a Custom Code Block Can Change the Look of Your Entire Site

Field Note #146
🔬 Generalized 🟡 Intermediate ⏱ 30 Minutes ✓ Observation from Experience
You paste a chunk of code — maybe a form, a widget, or a design template someone gave you — onto one new page. Suddenly your fonts look different, your colors have shifted, or your spacing feels off, but on pages you never touched.
This isn’t your imagination, and it isn’t a WordPress bug. It’s almost always a CSS scoping problem hiding inside the code you just added.

What’s actually happening
Every page on your site shares the same real <body> tag, even though the content inside it changes from page to page. If a piece of code you paste into a Custom HTML block includes a CSS rule like body { font-family: …; background: …; }, that rule doesn’t just style the block you added — it styles the entire page’s real body element, on every single page site-wide, because there’s only one body tag for your whole site to share.
The same problem happens on a smaller scale with plain class names. Code written to be a complete, standalone page (rather than a fragment meant to live inside a bigger page) often uses short, generic class names like .hero or .button without expecting them to collide with anything else. Paste that code into a WordPress block, and if your theme — or some other plugin — happens to use a class with that same name, the two start fighting over the same styling.

How to tell the difference
Open your browser’s dev tools (right-click → Inspect) on an element elsewhere on your site that looks different than it used to, and check its computed styles. If you see a font, color, or spacing value that traces back to the CSS you just added — not your theme’s own styling — that confirms it’s a scoping leak, not a coincidence.
You can also just look at the pasted code directly: search it for the word body followed by a {, or scan for short, generic class names with no unique prefix. Either is a strong warning sign before you even publish.

The fix
Wrap the actual visible content of the pasted code in one container <div> with a unique class name of your own choosing (something unlikely to exist anywhere else, like .acme-promo-wrap).
Go through every selector in that code’s CSS and prefix it with your new wrapper class — turn body { … } into .acme-promo-wrap { … }, and turn .hero { … } into .acme-promo-wrap .hero { … }.
Republish and check both the new page and a few unrelated pages to confirm nothing site-wide changed.

How to avoid it next time
Before pasting any code from an outside source — a downloaded template, something an AI generated for you, code copied from another website’s page — take a moment to check whether its CSS is properly scoped. If it references body directly, or uses short, generic class names with nothing unique about them, scope it to a wrapper first. It’s a five-minute check that avoids a confusing, site-wide mystery later.

Tagged in :

More from the field