How to validate structured data on a HubSpot website

https://superschema.ai/hubspot-aeo/schema-validation

To validate structured data on a HubSpot website, check the JSON syntax, the Schema.org description, any applicable Google feature requirements, and the markup delivered by the live page. Then compare every material claim with the visible content, because a validator cannot confirm that a price, provider or service area is true.

These checks answer different questions. Treating one green result as approval for the whole implementation can leave you with valid code on the wrong page, unsupported rich-result expectations or stale business information.

Which schema validator should you use?

Google distinguishes two testing tools (https://developers.google.com/search/docs/appearance/structured-data): the Schema Markup Validator for general Schema.org markup, and the Rich Results Test for supported Google search features. Add a content review and a live delivery check to cover the gaps between them.

Check: Question it answers: What it cannot establish
JSON parser: Is the script valid JSON?: Whether the properties describe the right entity
Schema Markup Validator: Can the Schema.org entities and properties be interpreted?: Google feature eligibility or factual accuracy
Rich Results Test: Which supported Google items are detected, with which issues?: Guaranteed appearance in search
Live page inspection: Is the intended code delivered on the published URL?: Whether every crawler will behave identically
Editorial comparison: Does the markup match the current page and business?: Ranking or citation outcomes

Save results with the page URL, test date and approved version of the markup. That record makes a later disagreement easier to investigate: was the code wrong, the page changed or the test looking at an older version?

Four separate implementation checks: code syntax, supported facts, intended page placement and live published output.

Syntax, facts, placement and live verification are separate checks. A syntax pass does not complete implementation review.

Step 1: Confirm the JSON-LD syntax

Copy the contents of the JSON-LD script, without the opening and closing HTML tags, into a JSON parser. Double quotes, commas and closing brackets matter. Remove comments and trailing commas.

For a browser-level check, open the published page and run this in its developer console:

const blocks = [...document.querySelectorAll(
  'script[type="application/ld+json"]'
)];
console.log(`Found ${blocks.length} JSON-LD script blocks`);
blocks.forEach((block, index) => {
  try {
    const data = JSON.parse(block.textContent);
    console.log(`Block ${index + 1}: valid JSON`, data);
  } catch (error) {
    console.error(`Block ${index + 1}: invalid JSON`, error.message);
  }
});

This checks the scripts in the current browser document. It is useful for locating a malformed block, but it does not validate Schema.org vocabulary or show what the server originally sent before JavaScript ran.

If a template inserts text dynamically, test punctuation as well as plain names. A quotation mark in a service title should remain part of the title, not terminate the JSON string. Fix serialization in the template instead of manually stripping legitimate punctuation from your content.

Step 2: Inspect the Schema.org model

Open the Schema Markup Validator (https://validator.schema.org/). Test the complete script as a code snippet, then examine the detected entities and relationships.

For a Service page, expect the named service and its provider. If you use @id references, check that they point to the intended organization and offering. A company name appearing somewhere in the graph is not enough if the service points to a different identifier.

This fictional diagnostic example describes a service offered by Northline Consulting:

{
  "@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",
  "provider": {
    "@type": "Organization",
    "@id": "https://example.com/#organization",
    "name": "Northline Consulting",
    "url": "https://example.com/"
  }
}

It is deliberately small. You should be able to explain each property and point to the corresponding fact on the hypothetical page. In your implementation, replace all fictional details and use the Service schema guide (https://superschema.ai/schema-markup/service-schema) to review scope, geography and offers.

Step 3: Check applicable Google rich results

Run Google's Rich Results Test (https://search.google.com/test/rich-results) in code mode before publishing. After publication, use URL mode. Expand each detected supported item and read its issues rather than judging only the summary.

Google's test documentation (https://support.google.com/webmasters/answer/7445569?hl=en) explains that code mode accepts snippets, while URL tests need publicly accessible resources. A password-protected preview is therefore a different test from the public page.

As of September 29, 2026, a dedicated Service rich result is absent from Google's feature gallery (https://developers.google.com/search/docs/appearance/structured-data/search-gallery). The Service example above can be valid Schema.org markup while producing no supported rich-result item. Use the general validator to assess it.

For a supported feature, fix blocking errors against that feature's documentation. Review warnings to determine which additional facts you can truthfully provide. Do not invent an image, rating or price to remove a warning. Google's policies (https://developers.google.com/search/docs/appearance/structured-data/sd-policies) also make clear that correct markup does not guarantee a rich result.

Step 4: Inspect what the live URL delivers

Publish or update the HubSpot page, then open its public URL in a fresh tab. Use View Source and search for application/ld+json. Confirm the expected block appears on that page with the final URLs and current facts. Follow the HubSpot placement guide (https://superschema.ai/hubspot-aeo/structured-data-on-hubspot) if it is missing.

For a server-response check, fetch a URL you own:

curl -L --fail --silent --show-error \
  -A "GPTBot" \
  "https://example.com/services/hubspot-cms" \
  -o page.html

Replace the example URL with your page, then inspect page.html for the correct title, heading, meaningful content and JSON-LD. Setting a user-agent string is a diagnostic request; it does not authenticate as a real crawler or prove how an engine will index the page.

If the script is visible only after client-side JavaScript runs, record that difference. Google's structured data introduction (https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data) documents that Google can process dynamically injected JSON-LD, but that does not establish the behavior of every other crawler. For a simple HubSpot implementation, emitting the script with the page HTML makes the delivery easier to inspect.

Step 5: Compare the markup with visible facts

Read the live page alongside its parsed data. Check the provider, service name, geographic coverage, offer scope, price and currency. Check that an old domain or copied service identifier has not survived a page duplication.

Review all contributing scripts, not just the block you added. A domain header and page-specific module may both describe the organization. Consistent references can be useful; contradictory names or commercial terms need an owner and a fix.

Ask a content owner to approve the factual description. A syntactically valid GBP 4,000 offer is still wrong if the page now sells a different package.

Step 6: Monitor the published version

In Search Console, inspect the page and compare indexed information with a live test. Google's URL Inspection documentation (https://support.google.com/webmasters/answer/9012289?hl=en) distinguishes the last indexed version from the current page. A live test can help verify a fix without implying that the index has already refreshed.

Repeat the relevant checks after a template change, domain migration or material service update. Record what changed and which URLs were retested. Use the HubSpot AEO guide (https://superschema.ai/hubspot-aeo/guide) to connect these technical checks with broader content and measurement work.

Take the next step on your HubSpot site

Connect your validation findings to the implementation work your website needs.

See how SuperSchema helps HubSpot websites (https://superschema.ai/hubspot-aeo)

Sources

Primary sources reviewed September 29, 2026.

- Google: Structured data testing tools (https://developers.google.com/search/docs/appearance/structured-data)
- Google: Rich Results Test documentation (https://support.google.com/webmasters/answer/7445569?hl=en)
- Google: Supported structured data features (https://developers.google.com/search/docs/appearance/structured-data/search-gallery)
- Google: General structured data guidelines (https://developers.google.com/search/docs/appearance/structured-data/sd-policies)
- Google: Introduction to structured data (https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data)
- Google: URL Inspection tool (https://support.google.com/webmasters/answer/9012289?hl=en)
- Schema.org: Service (https://schema.org/Service)