Recently I worked on adding structured data to a corporate homepage on a Sitecore XP project. The site belongs to a brand with one corporate site and a long list of location sites, in this case hospitals. The homepage was the easy part. The real question was how to do this well across hundreds of locations.
While working on it, I realized structured data is one of those topics everyone has heard of but few teams fully understand. So I am starting a short series. I will keep it simple, start from the basics, and build up to a real Sitecore implementation.
Here is the plan for the series:
- What is structured data? (this post)
- Modelling a multi-location brand: corporate site and location sites
- Implementing structured data on the corporate homepage in Sitecore
- Describing a membership program with
MemberProgram - Generating structured data for hundreds of location pages
- Validating, deploying and monitoring your schema
- Measuring the impact: what you can and cannot expect
What is structured data?
Structured data is a small block of code on your page that tells search engines exactly what the page is about. It does not change what visitors see. It is written for machines.
Think of it this way. A person reading your homepage can tell that "Shine Hospitals" is a company, that the number in the footer is a phone number, and that the logo is a logo. A search engine has to guess. Structured data removes the guessing by labelling each piece of information.
Three terms you will see again and again:
- Schema.org is the shared vocabulary. It defines types like
Organization,LocalBusinessandEvent, and properties likename,addressandtelephone. Google, Bing and others all use it. - JSON-LD is the format Google recommends for writing it. It sits in a
<script type="application/ld+json">tag, separate from your HTML markup. That makes it much easier to manage from a CMS like Sitecore. - Microdata and RDFa are older formats that add attributes directly to your HTML. They still work, but I will use JSON-LD throughout this series.
A simple example
Here is a simplified version of what a corporate homepage schema looks like in practice. I have used a made-up brand, Shine Hospitals, but the structure mirrors a real production implementation.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "WebSite",
"@id": "https://www.shinehospitals.com/#website",
"url": "https://www.shinehospitals.com/",
"name": "Shine Hospitals",
"publisher": { "@id": "https://www.shinehospitals.com/#organization" }
},
{
"@type": "WebPage",
"@id": "https://www.shinehospitals.com/#webpage",
"url": "https://www.shinehospitals.com/",
"name": "Animal Hospitals & Emergency Vets | Shine Hospitals",
"isPartOf": { "@id": "https://www.shinehospitals.com/#website" },
"mainEntity": { "@id": "https://www.shinehospitals.com/#organization" }
},
{
"@type": "Corporation",
"@id": "https://www.shinehospitals.com/#organization",
"name": "Shine Hospitals",
"url": "https://www.shinehospitals.com/",
"logo": "https://www.shinehospitals.com/images/logo.png",
"contactPoint": {
"@type": "ContactPoint",
"telephone": "+1-800-555-0100",
"contactType": "customer service"
},
"sameAs": [
"https://www.facebook.com/shinehospitals",
"https://www.linkedin.com/company/shinehospitals"
],
"hasMemberProgram": {
"@type": "MemberProgram",
"@id": "https://www.shinehospitals.com/careplus#memberprogram",
"name": "Shine CarePlus",
"url": "https://www.shinehospitals.com/careplus"
}
}
]
}
</script>
This looks like a lot, but it is just three things described together:
@graphholds several entities in one script block instead of writing three separate scripts.WebSitedescribes the site as a whole.WebPagedescribes this specific page, and says its main topic is the organization.Corporation(a more specific type ofOrganization) describes the company: name, logo, contact details and official social profiles insameAs.hasMemberProgramdescribes the brand's membership or wellness plan program using theMemberProgramtype. More on this in its own post.
The important part is @id. Each entity gets a unique identifier, and the entities refer to each other by it instead of repeating details. The website is published by the organization, the page is part of the website, and the page is about the organization. Later, every location page will point back to the same organization @id.
No visitor ever sees this. But a search engine now knows exactly who the company is, what the site is, and how they relate.
Why does it matter?
Structured data helps search engines understand your content with confidence. That understanding shows up in a few ways:
- Rich results. Some schema types can make your listing stand out in search, for example with ratings, hours or breadcrumbs.
- Knowledge panel and brand identity.
Organizationschema helps Google connect your logo, website and social profiles as one entity. - Local search. For businesses with physical locations, accurate address, hours and phone details support map and local results.
- AI-powered search. Search features and AI assistants that answer questions directly rely on clear, machine-readable facts. Structured data is one of the cleanest ways to provide them.
It is also important to be honest about what it does not do:
- It is not a direct ranking boost. Adding schema will not move you from page five to page one.
- Valid markup does not guarantee a rich result. Google decides when to show them.
- Google has reduced or retired some rich result types over the years, like FAQ and HowTo. Always check Google's current list of supported types before promising a specific result to stakeholders.
So I see structured data as hygiene: low effort, low risk, and it makes everything else in SEO work a little better.
Corporate site vs location sites
This is where it gets interesting for multi-location brands. Think of a veterinary or healthcare network: one corporate site, plus a page or microsite for every hospital.
Each level describes a different thing:
- The corporate homepage describes the brand itself, using
Organization. - Each location page describes one physical place people visit, using
LocalBusinessor a more specific type likeVeterinaryCareorMedicalClinic. It carries the address, opening hours, phone number and map coordinates for that location.
The key is to link them. Each location points back to the brand using parentOrganization and the brand's @id. Search engines then see one company with many branches, not hundreds of unrelated businesses.
The corporate schema is written once. The location schema has to work for hundreds of pages, so it should come from content rather than being typed by hand. That difference shapes the whole Sitecore implementation, which I will cover in parts 3 and 5.
Wrapping up
To summarize:
- Structured data labels your content so search engines don't have to guess.
- Use schema.org types, written as JSON-LD.
- It supports rich results, brand identity, local search and AI-powered answers, but it is not a ranking shortcut.
- Multi-location brands need two levels:
Organizationfor the brand, andLocalBusiness(or a subtype) for each location, linked together.
In the next post, I will go deeper into modelling a multi-location brand: which properties matter for the corporate site and for each location, and how to connect them properly.
If you are working on something similar, I would love to hear how you approached it. Feel free to reach out.
