You implemented a single LocalBusiness schema block for your medical campus that houses a primary care clinic, a dental office, an imaging center, and a pharmacy, each with its own phone number, hours, and GBP listing. You expected Google to understand the multi-department structure from your combined schema. Instead, Google’s Knowledge Graph conflated the entities, displaying the wrong phone number for the dental office and showing the pharmacy’s hours on the primary care Knowledge Panel. The error traces to an implementation that failed to use schema’s department nesting structure, which is the mechanism Google uses to distinguish co-located but operationally distinct business entities.
How Google’s Entity Model Distinguishes Parent Organizations From Departments at a Single Address
Google’s Knowledge Graph supports hierarchical entity relationships where a parent organization can contain department entities that share an address but maintain independent attributes. This hierarchy mirrors real-world organizational structures where a hospital contains a cardiology department, a pharmacy, and an emergency room, each functioning as a distinct service entity within a single physical location.
The schema mechanism for expressing this hierarchy is the department property on the parent LocalBusiness type. The parent entity represents the overarching organization (the medical campus, the automotive dealership, the university), and each department is defined as its own LocalBusiness entity nested within the parent through the department property.
Google processes this hierarchy by creating separate entity records for each department while maintaining the organizational relationship. Each department can have its own Knowledge Panel, its own search result display, and its own GBP listing. The parent-department relationship tells Google that these entities are organizationally connected but operationally distinct, which is the information needed to prevent attribute conflation.
Without the department nesting, Google encounters multiple sets of conflicting data (different phone numbers, different hours) associated with the same address and business name. The entity reconciliation system, designed to merge duplicate data about the same entity, may incorrectly treat the departments as conflicting data about a single entity rather than accurate data about distinct entities. The result is the Knowledge Graph errors described in the opening scenario.
The Schema Nesting Pattern for Multi-Department Locations That Prevents Entity Conflation
The correct implementation uses a parent-child structure where the parent LocalBusiness contains department properties pointing to child LocalBusiness entities.
{
"@context": "https://schema.org",
"@type": "MedicalBusiness",
"@id": "https://example.com/#medicalcampus",
"name": "Springfield Medical Campus",
"address": {
"@type": "PostalAddress",
"streetAddress": "500 Health Drive",
"addressLocality": "Springfield",
"addressRegion": "IL",
"postalCode": "62701"
},
"telephone": "+1-217-555-0000",
"department": [
{
"@type": "Dentist",
"@id": "https://example.com/dental/#dentist",
"name": "Springfield Dental Care",
"telephone": "+1-217-555-0101",
"url": "https://example.com/dental/",
"openingHoursSpecification": [...]
},
{
"@type": "Pharmacy",
"@id": "https://example.com/pharmacy/#pharmacy",
"name": "Springfield Campus Pharmacy",
"telephone": "+1-217-555-0102",
"url": "https://example.com/pharmacy/",
"openingHoursSpecification": [...]
}
]
}Each child entity must have a unique @id value that distinguishes it from the parent and from other departments. The @id should be a URL that corresponds to the department’s dedicated page on the website, appended with a fragment identifier. This unique identifier prevents Google’s parser from merging department data.
Child entities inherit the parent’s address property by default when no separate address is specified. This inheritance is correct for departments at the same location. All other properties, including name, telephone, openingHoursSpecification, url, and @type, must be specified explicitly for each department because these values differ between departments.
Department Type Specificity and URL Alignment With GBP Listings
The @type for each department should be the most specific applicable Schema.org type. Using Dentist rather than generic LocalBusiness for the dental office, Pharmacy for the pharmacy, and DiagnosticLab or MedicalClinic for the imaging center provides Google with precise semantic context for each department’s function.
The url for each department must point to that department’s dedicated page on the website. This URL should match the URL linked from the department’s GBP listing. This URL alignment creates a three-way connection: GBP listing, schema markup, and dedicated webpage all point to and reference the same department entity.
When to Use Separate Schema Blocks Versus Nested Departments Based on Entity Independence
Not all co-located businesses should use the department nesting pattern. The decision depends on whether an organizational relationship exists between the entities.
Use nested departments when the businesses are organizationally related: departments within a hospital, service divisions within a dealership, departments within a university, or shops within a corporate-owned retail complex. The parent-department relationship communicates that these entities are part of a single organization.
Use separate, unrelated schema blocks when the businesses are independently owned and operated, even if they share a physical address. A law firm and an accounting firm occupying the same office building are not departments of each other. They should each have an independent LocalBusiness schema block with no relationship property connecting them. Similarly, businesses in a strip mall or shared office building that have no organizational relationship should implement entirely separate schema.
The distinguishing criterion is organizational control. If one entity has management authority over the others (a hospital system managing its departments, a franchise managing its co-located brands), the department nesting is appropriate. If the co-located businesses operate independently with no shared management, separate schema blocks are correct.
Incorrect nesting, using the department pattern for unrelated businesses, can confuse Google’s entity model by suggesting an organizational relationship that does not exist. This may cause Google to display one business’s information on another’s Knowledge Panel or to suggest that the businesses are related when they are not.
Incorrect separation, using independent schema blocks for genuine departments, creates the entity conflation risk described in the opening. Google encounters multiple LocalBusiness entities at the same address with no relationship property and may attempt to merge them as suspected duplicates.
Aligning Multi-Department Schema With Multi-Listing GBP Structures
Each department defined in schema should correspond to a verified GBP listing with matching attributes. The schema serves as the website-side confirmation of the GBP-side entity data, and alignment between the two sources reinforces entity confidence for each department independently.
The alignment requirements map property by property. The schema name for each department must exactly match the GBP listing name. The schema telephone must match the GBP primary phone number. The schema openingHoursSpecification must reflect the same hours shown on the GBP listing. The schema url must point to the same page that the GBP listing links to as its website URL.
When a department has its own GBP listing (which is appropriate for departments that function as distinct businesses with separate customer interactions), the GBP listing URL should point to the department’s dedicated page, and the schema on that page should describe that specific department. Placing a single combined schema block on the homepage while individual department GBP listings point to department subpages creates a structural misalignment where the schema describes the parent entity but the GBP listing references a child entity.
The recommended implementation places department-specific schema on each department’s dedicated page, with the parent organization schema on the homepage or a dedicated “about” page. Each department page’s schema includes only that department’s data (not the full parent-department hierarchy), while the homepage schema includes the complete hierarchy with department references.
This distributed implementation ensures that each GBP listing points to a page where the schema data matches the GBP data exactly, creating the three-way alignment (GBP, schema, page content) that maximizes entity confidence per department.
Common Implementation Errors That Cause Google to Merge or Confuse Department Entities
Several frequent implementation mistakes undermine the department schema pattern and cause entity confusion.
Omitting the department relationship. Placing multiple top-level LocalBusiness blocks for the same address without connecting them through the department property leaves Google to interpret the blocks as either duplicates or conflicting data about a single entity. Always connect co-located departments through the explicit department property on the parent entity.
Missing unique @id values. Each entity in the schema, parent and all departments, must have a globally unique @id. Without unique identifiers, Google’s structured data parser may treat separate department blocks as repeated descriptions of the same entity, merging their attributes and producing the conflated Knowledge Graph display.
Using identical names across departments. Department names must be distinguishable. “Springfield Medical” for both the primary care clinic and the dental office creates a name similarity signal that entity deduplication may interpret as a merge candidate. Each department name should include a functional descriptor: “Springfield Medical – Primary Care,” “Springfield Medical – Dental Office.”
Failing to specify the most precise @type. Using the generic LocalBusiness type for all departments wastes an opportunity to provide semantic differentiation. Google treats type differences as entity differentiation signals. A Dentist and a Pharmacy at the same address are clearly different entities. Two LocalBusiness entries at the same address may be treated as duplicates.
Inconsistent data between schema and GBP. Any discrepancy between department schema data and the corresponding GBP listing introduces entity confidence problems. The most common inconsistency is phone number formatting (schema shows “+1-217-555-0101” while GBP shows “(217) 555-0101”). Use identical formatting across both sources.
Validate the implementation by testing each department page’s schema separately in Google’s Rich Results Test. Confirm that each test returns a distinct LocalBusiness entity with correct department-specific attributes and no data inherited from other departments.
Is there a maximum number of departments that can be nested under a single parent LocalBusiness entity in schema?
Schema.org does not impose a maximum on the number of department properties. Google’s structured data parser can handle any reasonable number of nested departments. Practically, most multi-department locations have between 2 and 10 distinct departments. If the nesting exceeds 15 to 20 entities, evaluate whether all listed entities are genuinely distinct departments or whether some are service categories that should be represented through the hasOfferCatalog property instead of as separate business entities.
Should franchise locations that share a brand but have independent owners use the department pattern or separate schema blocks?
Independently owned franchise locations should use separate, unrelated LocalBusiness schema blocks, not the department pattern. The department property implies organizational control by the parent entity, which does not apply to independently owned franchises. Each franchise location should implement its own standalone LocalBusiness schema with a unique @id, matching its individual GBP listing data. The franchise brand relationship can be expressed through the parentOrganization property without implying departmental subordination.
Can department schema help a business that has one GBP listing but operates multiple service lines from the same address?
Department schema is appropriate only when each service line operates as a functionally distinct entity with its own phone number, hours, or customer-facing identity. A plumbing company offering residential and commercial services from one address does not qualify for department nesting because both services share the same contact information and hours. Use the hasOfferCatalog or makesOffer properties to describe service lines within a single LocalBusiness entity instead. Reserve department nesting for entities that genuinely have separate GBP listings or could legitimately qualify for them.
