Add Organization schema to a HubSpot website by gathering approved business facts, expressing them as JSON-LD, and publishing the code through a controlled page or template change. Check the published markup against the website's visible information before treating the work as complete.
Organization schema describes the business behind a website. Google's Organization guidance explains how it can clarify administrative details and help distinguish one organization from another. It does not guarantee a search feature or an AI citation.
This is one part of making a HubSpot website ready for AI. The useful starting point is an accurate business identity, followed by the services, locations and policies a buyer needs to understand.
What business information should you collect first?
Create a short fact sheet before opening a generator. Give each fact a public source, an owner and an approval date. The source might be the About page, a service page or a published policy. An internal sales slide is a reason to ask a question, rather than permission to publish a claim.
| Information | Question to settle | Public evidence to check |
|---|---|---|
| Business identity | What name does the business trade under? | Homepage and About page |
| Legal identity | Is the registered name different? | Approved company information |
| Contact methods | Where should enquiries and support go? | Contact and support pages |
| Services | What does the business actually deliver? | Current service descriptions |
| Offers | What is included, excluded and available now? | Published offer terms |
| Locations | Where is the business based and where does it serve? | Location and coverage pages |
| Policies | What must buyers know before committing? | Relevant terms, cancellation or return policies |
| External profiles | Which profiles identify this same business? | Official profiles checked by the owner |
Not all this information belongs inside an Organization object. Keep the fact sheet broader than the markup so it can guide the visible pages and related structured data too.
For example, a remote consultancy can have an office address and a national service area. Those facts mean different things. Do not invent branch locations to describe coverage, or turn an aspirational service into an available offer.
If two pages disagree about a service, contact address or policy, resolve the disagreement first. Adding a third version in JSON-LD makes the maintenance problem harder.
Which Organization properties should you use?
Schema.org's Organization definition provides the vocabulary. Start with the fields your business can support:
| Property | Purpose | Practical check |
|---|---|---|
name | Public business name | Matches the name visitors see |
legalName | Registered name, where relevant | Approved and distinct from the brand if needed |
url | Business website | Uses the preferred public URL |
logo | Representative logo | Points to the correct accessible image |
description | Description of the organization | States its actual work without unsupported claims |
address | Physical or mailing address | Uses appropriate public address details |
contactPoint | Contact methods and their purpose | Routes visitors to a working channel |
sameAs | Other pages identifying the organization | Identifies the same entity |
Google's guide has no required Organization properties and recommends relevant details. It also recommends the most specific applicable subtype. A physical local business may need a LocalBusiness subtype and the separate requirements for that feature. Choose the type from the business model, not from the search appearance you hope to obtain.
Use sameAs selectively. A company profile can identify your organization; an article mentioning your company is not necessarily an identity profile. Your own service pages should have their own relationships rather than being listed as external equivalents of the business.
What does an Organization JSON-LD example look like?
The following example is fictional. Northbridge Operations is an invented consultancy, and every URL and business detail is illustrative. Replace the example with facts approved for your website.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://northbridge.example/#organization",
"name": "Northbridge Operations",
"legalName": "Northbridge Operations Ltd",
"url": "https://northbridge.example/",
"logo": "https://northbridge.example/images/logo.png",
"description": "Northbridge Operations provides operations consulting for manufacturing businesses.",
"contactPoint": {
"@type": "ContactPoint",
"contactType": "sales",
"email": "[email protected]"
}
}
</script>
The @id gives this organization a consistent identifier. In this recommended implementation pattern, a service page can reference https://northbridge.example/#organization as its provider. Keep that identifier stable when a page's wording changes.
The description deliberately avoids claims such as "the leading consultancy." The business does not become a leader because the phrase appears in markup. An accurate, specific explanation is more useful.
This example omits addresses and external profiles because the fictional scenario has not supplied them. Missing information should trigger a fact check, not a guess. The Service schema guide explains how to describe an individual service and connect it to its provider.
Where should Organization schema go in HubSpot?
Choose a clear page that identifies the business, such as its About page or homepage. Before adding code, inspect existing markup from the theme, modules and integrations. Decide who owns the Organization definition and which implementation will maintain it.
For HubSpot, use the structured data implementation guide to choose between page-level placement and a maintained template or module. The right method depends on permissions, the theme and how broadly the information should appear.
Avoid pasting slightly different copies into many pages. A template change can spread an error just as easily as it can spread a correction. If several pages reference the same organization, use the same approved facts and identifier, and review the final combined markup on each affected page type.
Record the placement, responsible editor and affected pages. That small handoff makes the next rebrand or domain migration easier to manage.
How do you validate the published business identity?
Check syntax, meaning and delivery separately:
- Confirm the JSON-LD parses and the properties fit the chosen types.
- Compare every asserted fact with the current public website and approved fact sheet.
- Check that the logo and linked profiles are accessible and identify the correct business.
- Inspect the live HTML to confirm the intended code was published.
- Review other markup on the page for conflicting identity information.
- Save the tested URL, date and findings for the next review.
The schema validation guide covers the distinction between Schema.org validation and Google's feature-specific tests. A successful test establishes a narrower result than "AI-ready": the page still needs accurate, useful content and working access.
Google's AI features guidance says there is no special schema required for AI Overviews or AI Mode. Keep expectations tied to documented benefits and measured observations.
Repeat the fact review after changes to business names, services, contact details, locations or policies. The aim is a website that explains the business consistently wherever someone encounters it.