Most HubSpot sites we open have good content on them and nothing labeling it. Schema markup is the label: JSON-LD inside a require_head block, templated so it stays correct as pages change. It makes your content legible to search and answer engines. What it does not do, and we have the numbers on this, is decide whether they cite you.
Picture a warehouse where every box is sealed and unlabeled. The contents are fine. Somebody still has to open all of them to find the one thing they need.
That is a page without structured data. The words are there. Nothing tells a machine which words are the author, which are the publish date, which are the question and which are the answer.
Schema is the label on the outside of the box. It says: this is an article, this person wrote it, it went up on this date. A labeled box is one a machine can sort without opening.
Now the part most agencies skip. A label does not make anyone pick your box. It makes it possible to pick your box knowingly. And a label that says the wrong thing is worse than no label at all, because now the sorting is confidently wrong.
HubSpot puts it plainly in its own AEO documentation: add schemas to your pages to provide structured data. Worth noticing what that sentence is not. It is not "HubSpot adds schemas to your pages." The tool grades your content and hands you recommendations. Writing the markup is still yours.
On its own, mostly not, and we would rather say that than sell you a two-week markup project.
Ahrefs ran the cleanest test we have seen on this. They took 1,885 pages that added JSON-LD and compared them against 4,000 matched control pages that did not, measuring citations 30 days either side. Adding schema produced no meaningful lift anywhere: 2.4% on Google AI Mode, 2.2% on ChatGPT, and a 4.6% decline on AI Overviews.
Read the fine print, though, because it changes the conclusion. Every page in that study was already earning at least 100 AI citations. So the finding is narrower than the headline: schema will not lift a page that engines already quote happily. It says nothing about a page they cannot parse in the first place. Those are different problems, and most of the HubSpot sites we get called into have the second one.
Our own numbers land in the same place. In a July 2026 snapshot of 175 non-branded buyer questions across ChatGPT, Google AI Mode, Gemini, and Perplexity, HubBase was cited in 52 and ranked first among cited sources in 21. In that same sample we did not appear in Perplexity's results a single time. Our markup is identical across all four engines, so markup is not what separates them. The Perplexity results we tracked leaned harder on third-party sources: review sites, community threads, roundups. Treat that as a finding from our sample, not a law of the platform.
So the honest version. Schema is legibility work, not endorsement. It is the floor, not the lever. Authority, freshness, and whether anyone else on the internet mentions you decide the rest. That is exactly why you do not skip it: nothing else you try can work through a page an engine cannot read properly.
In the head, inside a HubL tag. HubSpot's developer documentation is specific: wrap your JSON-LD in require_head and end_require_head tags so it lands in the <head> element where engines expect to find it.
From there you have two places to put it, and the choice matters more than it looks.
In the template. Best when every page of a type needs the same schema. Every blog post is an Article. Every service page is a Service. You write it once and 400 pages inherit it.
In a custom module. Best when the schema type changes page to page, or when an editor needs to pick one from a dropdown.
We reach for the template first and the module only when we have to. Every module is one more thing a person can drag into the wrong place.
Here is where the real value is, and it has nothing to do with AI.
You can hand-paste JSON-LD into a page. It works on day one. It also means every future page depends on somebody remembering to do it and updating the date when the post is refreshed. That is a hand-written shipping label, and hand-written labels drift out of sync with what is in the box.
The alternative is to put the label on at the packing station. HubSpot exposes the content object as HubL variables, so the markup reads the page instead of repeating it: the title, the publish date run through a datetime filter, the author's full name. Write it once, and the schema is still accurate on the post you publish in March 2027 that nobody has thought of yet.
{% require_head %}
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "{{ content.title }}",
"datePublished": "{{ content.publish_date|datetimeformat('%Y-%m-%dT%H:%M:%S') }}",
"author": {
"@type": "Person",
"name": "{{ content.blog_post_author.full_name }}"
}
}
</script>
{% end_require_head %}
Article and NewsArticle are walked through in HubSpot's structured data guide; Organization and FAQPage are not, so those get written by hand and templated the same way.
This is the failure we see most, and no tool will tell you it happened.
The schema was hand-pasted into a rich text module by whoever built the page. Six months later somebody updates the copy, deletes what looks like a stray block of code, and republishes. The page looks identical. The label is gone. Nobody notices for a year, because nothing on the page turns red.
The subtler version is worse. The markup survives but the page changes around it, so your structured data now describes an article that no longer exists.
Three habits prevent both, and none of them are technical:
require_head block.The pattern underneath all three: markup a person has to maintain by hand will eventually stop being maintained.
In the order we ship them, with honest expectations attached:
Ship one and two before you touch anything else. The rest is a good afternoon.
No. HubSpot's AEO tools grade your content and surface recommendations, and its own documentation tells you to add schemas to your pages. Generating and maintaining that markup is still your job, whether that means your developer or a partner.
Schema is not a paid add-on. What you need is the ability to edit the theme, template, or custom module where the markup lives, which comes down to your subscription and your user permissions. Check what your portal actually lets you edit before scoping the work. HubSpot's AEO tooling is separate and does require a Marketing Hub Professional or Enterprise subscription, or a standalone HubSpot AEO subscription.
Inside a require_head and end_require_head block, which places it in the page's <head>. Put that block in a template so every page of that type inherits it, or inside a custom module when the schema type needs to change from page to page.
No. HubSpot's own guidance is blunt that adding the code is not a guarantee a search engine will display the data, and the largest study we have seen found no meaningful citation lift from adding JSON-LD to pages engines already cite. Schema makes your content easier to interpret correctly. It does not decide who gets quoted.
After every theme change, redesign, or template edit, not only at launch. The most common failure we see is markup that was correct on launch day and quietly vanished during a redesign, because nothing on the page looks wrong when it goes.
They should not have to. If keeping schema alive depends on someone remembering to paste code, it will decay. Template it so it populates from content fields, and your team can edit pages freely without ever touching it. That templating is the kind of work a HubSpot developer does once and you stop thinking about it.
Schema sits on top of whether your HubSpot site works for the people using it every day. Our Free Website Assessment is a CMS health check: whether your site is genuinely easy for your team to update, whether loading speed can be improved, and whether you are getting the benefit of drag and drop. No pitch, just the findings.
If structured data is specifically what you are trying to fix, that lives in our AI and AEO optimization work, and it runs as a standing part of the Website Growth Retainer rather than a one-time project, because markup drifts the moment people start editing pages.