You built the page in an afternoon. Schema validated clean in the sandbox. You shipped it and moved on to the next campaign. Three weeks later your rich results have vanished from search, your ad platform is flagging landing page experience, and nobody on the team can work out why. Nothing changed, as far as anyone can tell. Except something did. HubSpot changed it the moment you hit save.
This is the single most common mistake in rapid HubSpot landing page builds, and it's almost never caught until the numbers start moving the wrong way.
First, where it goes wrongTwo places for custom code, one of them lies
HubSpot gives you two places to put custom code, and they behave completely differently.
Head HTML
Your schema markup, tracking snippets and meta tags belong in the page editor's gear icon, then Settings, then Advanced, then the "Additional <head> HTML" field. This is set per page. HubSpot leaves it alone.
Body HTML
This is where the trap sits. Drop your structured code into a Rich Text module and HubSpot will "help." It reformats on save, strips attributes it doesn't recognise, closes tags it thinks you left open. Do this once on one page and you might not notice. Do it across a set of campaign or competitor landing pages, which is exactly when you're moving fast and reusing a template, and you've just broken schema markup and scripts across every page without touching a single line of code yourself.
The page still looks fine. It's the markup underneath that's quietly gone.Second, the actual fix
Use the Custom HTML module, always
Use the Custom HTML module for any body content that needs to render exactly as written. It preserves markup byte for byte. No silent reformatting, no stripped attributes. It's a five-second swap in the module picker, and it's non-negotiable the moment you're deploying the same structure across more than one page.
If you're already deep into a Rich Text build, don't just move the module. Validate afterward. Re-run your schema through a testing tool and check the rendered HTML, not just the editor view. Rich Text damage is easy to miss because the page still looks fine to a visitor. It's the markup underneath that's the problem.
Why this matters beyond the markup
Broken schema costs you rich snippets. But the same instinct that causes this mistake, moving fast, templating it, deploying it everywhere, is also what makes rapid landing page builds effective for paid campaigns, when it's done properly. Get the anatomy of the page itself wrong and no amount of clean markup saves it. Get the markup wrong and no amount of good design saves your page speed either. They're both part of the same discipline.
In one recent build I ran, rapid HubSpot landing pages for a B2B SaaS company, standing up dedicated experiences instead of routing every campaign to one generic page, that discipline delivered a 50% drop in CPC and a meaningfully lower CPA on existing ad spend. Same platform, same audience, same offer.
The only thing that changed was building pages that did their job properly instead of leaning on a template and hoping. That's the real cost of the mistake above. It isn't just a lost rich result. A landing page that's technically compromised, slow, badly structured, mismatched to the ad, is a landing page quietly taxing every click you're paying for.
Check the module before you scale the template.
If you're deploying landing pages at any kind of pace in HubSpot, competitor pages, campaign variants, seasonal offers, check which module your body content is sitting in before you copy it again. It's a two-minute check that avoids a multi-week debugging session, and it's the difference between pages that convert the traffic you're paying for and pages that quietly leak it.
