---
title: "Business Knowledge Graph for HubSpot"
description: "Connect your company, services and pages with stable identities and JSON-LD. Includes a fictional graph example and practical verification steps."
url: https://superschema.ai/hubspot-aeo/business-knowledge-graph-for-hubspot
author: "Clint Johnson"
date_published: 2026-10-20
---

# Business Knowledge Graph for HubSpot

**How do you build a business knowledge graph for a HubSpot website?**


A business knowledge graph connects the things your website describes: the company, its services, relevant locations and available offers. Start with approved facts, give distinct entities stable identifiers, and express the relationships on the pages that explain them. You do not need a graph database to begin.

For a HubSpot website, this can start as a short entity map and a controlled JSON-LD implementation. It is your website's model of the business, not a claim that Google has accepted you into its Knowledge Graph or will show a knowledge panel.

## Model things and relationships before writing JSON-LD

Choose one service and ask a few ordinary questions. Who provides it? Which page explains it? Where is it available? Is there a specific offer with approved terms? Which evidence supports those answers?

| Thing | What it represents | Relationship |
|---|---|---|
| Organization | The provider | A Service identifies its provider |
| Service | Work the provider performs | An Offer can identify the service being offered |
| Place | A real location | An Organization can identify a location |
| Offer | Commercial availability or terms | The offer identifies what is offered and who sells it |
| WebPage | A document about these things | Its main entity can identify the principal subject |

Do not force every business into all five types. A remotely delivered service does not need an invented local office. A custom quote does not require an invented price. Add detail when it describes something real and relevant.

## Give each entity a stable identity

In JSON-LD, `@id` identifies a node. A page URL with a fragment, such as `https://example.com/#organization`, is a practical convention for identifying the company separately from its homepage. It is a convention, not a requirement to use that exact fragment.

Use the same identifier when referring to the same organization across pages. Give separate services different identifiers. The `url` property points to a page someone can visit; it need not perform the same role as the entity identifier.

Document the convention before scaling. Otherwise each new page can introduce a slightly different company identity or reuse the same service identity for unrelated work. The [Organization guide](https://superschema.ai/hubspot-aeo/organization-schema) covers the provider record; the [Service guide](https://superschema.ai/schema-markup/service-schema) covers individual offerings.

## Connect a provider to a service and its page

This fictional example describes Northbridge Operations and a remote onboarding service. Assume the visible service page states the provider, scope and Canadian delivery area shown here. The example is intentionally small and contains no customer result or price.

```json
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Northbridge Operations",
      "url": "https://example.com/"
    },
    {
      "@type": "Service",
      "@id": "https://example.com/services/onboarding#service",
      "name": "Remote HubSpot onboarding",
      "url": "https://example.com/services/onboarding",
      "description": "Remote HubSpot onboarding for Canadian B2B teams. Data migration is quoted separately.",
      "provider": {"@id": "https://example.com/#organization"},
      "areaServed": {"@type": "Country", "name": "Canada"}
    },
    {
      "@type": "WebPage",
      "@id": "https://example.com/services/onboarding#webpage",
      "url": "https://example.com/services/onboarding",
      "name": "Remote HubSpot onboarding",
      "mainEntity": {"@id": "https://example.com/services/onboarding#service"}
    }
  ]
}
```

The service points to the organization, and the page points to the service. `@graph` groups the nodes in this document. It is not a separate ranking feature. The same relationship model can be expressed through nested objects where appropriate.

Replace the example domain and every fictional fact before using the pattern. Keep the example as visible code in an educational article; do not deploy it as the article's own active business markup.

## Trace each property to an approved fact

Before adding fields, map the graph back to the content that supports it. For the fictional example above:

| Approved source fact | Graph property | Check before publishing |
|---|---|---|
| The provider is Northbridge Operations | Organization `name`; Service `provider` references its `@id` | The visible provider name and identity agree |
| The page describes remote HubSpot onboarding | Service `name`, `description` and `url` | The service scope is stated on that page |
| This service is available to Canadian businesses | Service `areaServed` → Country | Eligibility applies to this service, not just the company generally |
| The page's principal subject is that service | WebPage `mainEntity` → Service `@id` | The page actually explains the service identified |
| Migration is quoted separately | Service `description` and visible scope | No other description says migration is included |

![The service points to its provider organization, and the web page identifies the service as its main entity.](https://superschema.ai/articles/18-entity-graph.webp)

The arrows express relationships, not a sequence of implementation steps. The identifiers keep these three things distinct even when the page and service have the same name. This is a small website graph, not evidence that an external search engine has adopted its facts.

## Add locations and offers only when they clarify the model

An organization's office and a service's delivery area answer different questions. A company may have an office in one city and deliver remotely across a country. Use the [locations and service-area guide](https://superschema.ai/schema-markup/location-schema-vs-service-area-schema) before copying an address into every service.

When a real offer is published, connect it to the relevant service and preserve the conditions a buyer needs. Do not create a zero-price offer for work that requires a quote. The [pricing-page guide](https://superschema.ai/hubspot-aeo/hubspot-pricing-page-content-template) explains how visible terms and structured data should agree.

## Map the graph to a maintainable HubSpot implementation

Assign each fact to an owner and source. Shared business facts may belong in maintained shared fields; service-specific facts belong with the relevant service content. Choose the actual implementation after inspecting the site's templates and existing code.

Avoid pasting a growing copy of the whole graph onto every page. Include the entities and relationships relevant to the page, keeping shared identities consistent. If multiple systems emit markup, resolve ownership using the [duplicate-schema workflow](https://superschema.ai/hubspot-aeo/duplicate-schema-markup-in-hubspot).

## Verify the graph as both code and business information

Parse the JSON, inspect the types and references, and compare each claim with visible content. Confirm that referenced identities represent the intended entities and that no example values remain. Test the published output using the [validation workflow](https://superschema.ai/hubspot-aeo/schema-validation).

Then ask whether the connected pages answer the original buyer question. A technically coherent graph cannot compensate for an unexplained service or unsupported claim. Keep the entity map and change record with the [maintenance plan](https://superschema.ai/hubspot-aeo/hubspot-schema-maintenance).

[See SuperSchema for HubSpot](https://superschema.ai/hubspot-aeo).

## Sources

Reviewed October 20, 2026. The modeling workflow and fictional graph are editorial examples.

- [W3C: JSON-LD 1.1](https://www.w3.org/TR/json-ld11/)
- [Schema.org: Service](https://schema.org/Service)
- [Schema.org: WebPage](https://schema.org/WebPage)
- [Schema.org: Offer](https://schema.org/Offer)