---
title: "Duplicate Schema Markup in HubSpot"
description: "Find competing schema sources on a HubSpot website, resolve conflicting facts, choose ownership and verify the repaired live pages."
url: https://superschema.ai/hubspot-aeo/duplicate-schema-markup-in-hubspot
author: "Clint Johnson"
date_published: 2026-10-20
---

# Duplicate Schema Markup in HubSpot

**How do you find and fix duplicate schema in HubSpot?**


To fix conflicting schema on a HubSpot website, identify every source of markup, decide which source owns each entity, and correct the conflicting facts before removing code. Multiple JSON-LD blocks are not automatically a defect. The important questions are whether they describe the right things, agree with the page and use identities consistently.

This guide is for an existing implementation where a theme, module, page-level script or integration may emit overlapping descriptions. If you are starting from scratch, use the [HubSpot structured-data guide](https://superschema.ai/hubspot-aeo/structured-data-on-hubspot) first.

## Identify what is duplicated

A page can legitimately describe an article, its publisher and a breadcrumb trail. Those are different things. Two scripts may also describe the same organization without contradicting one another, although multiple sources can make maintenance harder.

Separate these cases before changing anything:

| Observed markup | Interpretation | First action |
|---|---|---|
| Article and Organization nodes | Different entities with a possible relationship | Check publisher identity and page relevance |
| Repeated organization facts that agree | Redundant descriptions | Find ownership and assess maintenance risk |
| One company with two different phone numbers | Possible factual conflict | Confirm contact roles and approved numbers |
| One identifier used for two different services | Identity collision | Assign distinct service identities |
| Page and service share a name but have distinct IDs | Potentially valid modeling | Check whether each node represents the intended thing |

Do not remove markup solely to reduce the script count. Google's [structured-data guidelines](https://developers.google.com/search/docs/appearance/structured-data/sd-policies) allow multiple relevant items and describe linking related items with `@id`.

## Capture the live output and its sources

Save the page URL and the markup currently delivered. Search the initial HTML for JSON-LD scripts and inspect the rendered page for additional output. Also look for microdata or RDFa if the site uses them. Record the method so a later check compares the same thing.

For each description, note its type, identifier, key facts and suspected source. In HubSpot, inspect page-level code, domain-level code, template files and custom modules as applicable. Ask whoever manages integrations whether another system publishes markup. The generated script may not reveal its owner, so use the CMS configuration rather than guessing.

HubSpot's [code-snippet guidance](https://knowledge.hubspot.com/website-and-landing-pages/use-code-snippets-with-hubspot-content) explains page and shared code locations. Editing permissions and available controls depend on the account and content type. Keep the current configuration or version so a failed change can be reversed.

## Resolve the business fact before editing the code

Suppose a fictional consultancy has a shared Organization block using an old office address and a page-level block using a new address. A validator may accept both. It cannot tell you whether the business moved, added an office or accidentally published the wrong address.

Ask the business owner to confirm the relationship. If there are two real locations, model them intentionally. If the old office closed, update the source that still emits it. The [locations guide](https://superschema.ai/schema-markup/location-schema-vs-service-area-schema) explains why an office, service area and legal entity are not interchangeable.

Apply the same rule to price, service scope and contact details. A support number and a sales number may both be correct when their roles are clear. Two conflicting prices for the same current offer require a commercial decision, not an arbitrary merge.

## Choose one maintained source for each fact

Create a small ownership map. For example, approved company identity might come from a shared organization record, while service descriptions come from the relevant page fields. The implementation can use one script or several; the facts should have a clear maintenance path.

Keep stable identifiers for the same entity. Do not change an established organization ID merely to make it look cleaner without checking where it is referenced. If the current model is wrong, document the replacement and update dependent references in the same release.

When consolidating repeated markup, verify that accurate fields and relationships survive. Removing an entire theme block to eliminate a duplicate company name could also remove valid article or breadcrumb information. Scope the change to the actual conflict.

## A worked repair: keep the identity, correct the source

Consider **Northbridge Operations, a fictional company**. Its owner confirms that the Toronto office closed and the business now operates from Ottawa. The contact page has already been corrected. Two sources still emit different values for the same organization.

| Source found in the fictional implementation | Owner | Output before repair | Action |
|---|---|---|---|
| Shared theme module `company-schema` | CMS developer | Toronto address | Change the maintained company record to Ottawa |
| Contact page header snippet | Page editor | Ottawa address | Remove its redundant Organization node after the shared fix is verified |
| Article and breadcrumb template | CMS developer | Article publisher and navigation | Preserve these nodes and their relationships |

Those names describe this example's source inventory, not standard files that every HubSpot site contains. Inspect your own configuration to find the equivalent sources.

**Before: excerpts from two separate scripts.** Both identify the same company, but disagree about its current location. These intentionally minimal objects show the conflict; they are not a complete business profile.

```json
[
  {
    "@context": "https://schema.org",
    "@type": "Organization",
    "@id": "https://example.com/#organization",
    "name": "Northbridge Operations",
    "address": {"@type": "PostalAddress", "addressLocality": "Toronto", "addressCountry": "CA"}
  },
  {
    "@context": "https://schema.org",
    "@type": "Organization",
    "@id": "https://example.com/#organization",
    "name": "Northbridge Operations",
    "address": {"@type": "PostalAddress", "addressLocality": "Ottawa", "addressCountry": "CA"}
  }
]
```

**After: the corrected shared Organization output.** The identifier stays unchanged because this is the same company after a move. Retain any other accurate fields from the maintained record; do not replace a complete profile with this abbreviated teaching example.

```json
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Northbridge Operations",
  "address": {"@type": "PostalAddress", "addressLocality": "Ottawa", "addressCountry": "CA"}
}
```

An existing Article's `publisher` reference to `https://example.com/#organization` continues to identify the same company. Its headline, author and dates do not need changing because the office moved. Keep its BreadcrumbList too. If the old page snippet contains several nodes, remove only the redundant Organization node, not the entire script.

Verify the contact page and a representative article after publishing: Ottawa appears in the approved contact information and current Organization output; the obsolete Toronto claim is absent; the publisher reference still resolves to the intended organization; and Article and BreadcrumbList output remains intact. Recheck after the integration's next update if another system can recreate the old snippet. Save the previous template version for rollback.

Keep these fictional snippets as visible example code. Do not deploy Northbridge's identity as your own active schema.

## Test the change across affected page types

A shared-template edit has a larger reach than one page-level edit. Review a representative page from each affected template, including a page with missing optional fields and text containing quotation marks. A reusable implementation must serialize those values correctly.

Run syntax and vocabulary checks, then compare the live facts with the approved record. Check applicable Google feature requirements separately. The [validation workflow](https://superschema.ai/hubspot-aeo/schema-validation) explains why one successful tool result is insufficient.

Confirm that the old conflicting output is gone and the intended entities remain. Test public URLs after publication, not only CMS previews. If the integration recreates removed markup on its next update, the source-ownership problem has not been solved.

## Record the fix so it stays fixed

Retain the affected URLs, old and new descriptions, source locations, approver and verification date. Add the maintenance trigger: theme replacement, integration change, service revision or business relocation.

The intended outcome is an accurate description that the team can maintain. A lower script count is not proof of better rankings or AI visibility. Use the [business graph guide](https://superschema.ai/hubspot-aeo/business-knowledge-graph-for-hubspot) to document relationships, then the [maintenance checklist](https://superschema.ai/hubspot-aeo/hubspot-schema-maintenance) to keep them current.

[Explore SuperSchema implementation support](https://superschema.ai/managed).

## Sources

Reviewed October 20, 2026. The diagnostic workflow and fictional example are editorial recommendations.

- [Google: General structured data guidelines](https://developers.google.com/search/docs/appearance/structured-data/sd-policies)
- [HubSpot: Use code snippets with HubSpot content](https://knowledge.hubspot.com/website-and-landing-pages/use-code-snippets-with-hubspot-content)