How to add structured data to a HubSpot website

https://superschema.ai/hubspot-aeo/structured-data-on-hubspot

To add structured data to a HubSpot website, place a JSON-LD script in the relevant page's Head HTML field, publish the change, and test the live URL. Use domain-level code or a reusable template only when its content and scope fit every affected page.

The task is to make the page's meaning explicit: which organization provides a service, what the service includes, and where it is available. Start with one useful page and one clear description before expanding across your site.

What is HubSpot structured data?

Structured data is a machine-readable description of information on a page. Schema.org supplies the vocabulary; JSON-LD supplies a format for expressing it in a script block. This is website schema markup, distinct from HubSpot CRM object schemas used in application development.

Google recommends JSON-LD (https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data) for supported structured data because it can describe information separately from the surrounding HTML. Your headings, service description and contact information still need to work for readers.

For the wider relationship between content, technical access and measurement, see the HubSpot AEO guide (https://superschema.ai/hubspot-aeo/guide).

Choose the page and check its existing markup

Open the public page and view its source. Search for application/ld+json, then inspect any existing script blocks. A theme, custom module or earlier implementation may already describe the page. Also check for microdata attributes such as itemscope and itemtype.

Write down what is present and where your team maintains it. Two scripts are not automatically a problem, but conflicting descriptions are. If an existing Organization node already has a stable identifier, reuse that identity rather than inventing another organization for the service page.

Choose the schema type from the page's purpose. A company description belongs in Organization markup. A particular consulting or repair offering may use Service. An article about that offering can use Article without turning the article itself into a service. The Organization guide (https://superschema.ai/hubspot-aeo/organization-schema) explains the company-level model.

Should markup live on a page, domain or template?

Decide who owns the facts before deciding where the code lives.

Placement: Suitable use: Main maintenance risk
Individual page Head HTML: A service described on that page: Copied pages retain the old service details
Domain-level header: Shared information that fits the affected content: One change repeats across many pages
Reusable template or module: A maintained model populated from page-specific fields: Blank fields or escaping errors produce bad output

Do not put a single service description in a domain-wide header simply because that is easier. A visitor reading your careers page should not find structured data presenting it as your consulting service.

For a larger implementation, document which fields editors can change and which developer-owned code emits the markup. A reusable template should produce the correct page-specific result and safely serialize text as JSON. Test names containing quotation marks as well as ordinary text.

Add JSON-LD in the HubSpot page editor

The following route follows HubSpot's code snippet instructions (https://knowledge.hubspot.com/website-and-landing-pages/use-code-snippets-with-hubspot-content), checked September 29, 2026. HubSpot notes that editing options vary by subscription and content type. You need the relevant Edit and Publish permissions.

1. Navigate to Content > Website Pages, or Content > Landing Pages for a landing page. Some accounts show these under More.
2. Open the page, then choose Settings > Advanced in the content editor.
3. Find Additional code snippets and paste the complete script into Head HTML.
4. Click Publish or Update when the visible content and markup are ready.

For intentionally shared domain code, use account settings, then Content > Pages, select the domain, and edit Site Header HTML. Check whether that domain overrides defaults before changing it. Domain changes require Website settings permission.

Paste the script as code in the designated field. A normal rich-text content block can display or transform it instead of placing it in the page head.

A fictional service page example

Suppose a fictional company, Northline Consulting, has a page saying: “We provide HubSpot CMS implementation for UK organizations, including page templates, content migration and launch checks.” The page names the provider and links to its homepage. This example describes those facts:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Service",
  "@id": "https://example.com/services/hubspot-cms#service",
  "name": "HubSpot CMS implementation",
  "url": "https://example.com/services/hubspot-cms",
  "description": "Page templates, content migration and launch checks for UK organizations using HubSpot CMS.",
  "serviceType": "HubSpot CMS implementation",
  "provider": {
    "@type": "Organization",
    "@id": "https://example.com/#organization",
    "name": "Northline Consulting",
    "url": "https://example.com/"
  },
  "areaServed": {
    "@type": "Country",
    "name": "United Kingdom"
  }
}
</script>

Replace every fictional value with your own supported facts. The #service and #organization fragments identify different things; the plain url points to a page readers can visit. Keep those identifiers consistent across related pages.

The example deliberately omits prices, ratings and credentials. Missing optional detail is preferable to a claim your page cannot substantiate. For offers and more detailed relationships, use the Service schema guide (https://superschema.ai/schema-markup/service-schema).

Validate the published page, not just the draft

First check the script in the Schema Markup Validator (https://validator.schema.org/). After publication, test the public URL and confirm the expected entity is still present. Then use Google's Rich Results Test (https://search.google.com/test/rich-results) for applicable Google features. Our schema validation workflow (https://superschema.ai/hubspot-aeo/schema-validation) explains how to interpret the two tools.

As of September 29, 2026, Google's supported feature gallery (https://developers.google.com/search/docs/appearance/structured-data/search-gallery) does not list a dedicated Service rich result. A valid Service example can therefore produce no supported rich-result item. That is a feature-coverage issue, not proof that the Service markup is broken.

Finally, compare the live page with the script: correct company, service, URL and geography. Reload the public page after the update rather than relying on a preview. Keep a copy of the approved markup and its publication location so the next editor can trace it.

When a service is renamed, moved, repriced or discontinued, review both its content and its markup together. That small habit is more useful than a large block of JSON-LD nobody owns.

Put the guide into practice

Draft markup for a service page, then check the facts and published output.

Use the Service schema generator (https://superschema.ai/service-schema-generator)

Want implementation help? Explore SuperSchema Managed (https://superschema.ai/managed)

Sources

Primary sources reviewed September 29, 2026.

- HubSpot: Use code snippets with HubSpot content (https://knowledge.hubspot.com/website-and-landing-pages/use-code-snippets-with-hubspot-content)
- Google: Introduction to structured data (https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data)
- Schema.org: Service (https://schema.org/Service)
- Google: Structured data testing tools (https://developers.google.com/search/docs/appearance/structured-data)
- Google: Supported structured data features (https://developers.google.com/search/docs/appearance/structured-data/search-gallery)