Model the business before writing schema
A professional-services group has one parent company, two operating businesses and a specialist advisory brand. Its group website calls all four names “the company”. LinkedIn pages use different ownership descriptions. One Google Business Profile combines two customer-facing brands. The footer links every social account through one Organization node.
Each statement looks plausible on its own. Together they leave buyers unsure which business will deliver the work. They also give search systems several incompatible versions of the same relationships.
This is a modelling problem before it's a schema problem. A broad business representation audit can reveal the inconsistency. The next job is to decide which identities are genuinely distinct, where each one lives and how they relate.
Start with operating reality
List the legal entities, registered and trading names, customer-facing brands, public departments, staffed locations, domains and profiles. Record who owns each one and who can approve a change. Check company records and contracts with qualified advisers where ownership or naming rights aren't clear.
The public model should follow verified operations. A logo can distinguish a service line, while a separate company needs evidence in the way it operates. Two subsidiaries remain distinct public identities even when they share an owner. A registered name proves little about the name customers encounter.
This article provides search and content architecture guidance. It doesn't determine corporate, tax, trademark or regulatory status. Those facts need to be settled before a web team encodes them.
Decide what deserves a separate identity
Create a separate Organization when the unit is a real organisation with its own maintained facts and a useful public role. A subsidiary that contracts with clients, employs a team, operates under its own name and maintains its own website or profiles is a strong candidate.
Use LocalBusiness, or an accurate subtype, for an eligible customer-facing business at a real location. A branch of one business usually remains a location of that business. Our LocalBusiness guide for locations and service areas covers that case in detail.
A brand needs a different test. Schema.org defines Brand as a type for a brand or associated identity used by an organisation or business person. A named offer can remain a brand rather than an organisation. A multi-brand consultancy might have one operating company that sells two clearly named service brands. Each brand can have a distinct identity while the company remains the contracting provider.
A department can deserve a distinct customer-facing record when it operates as a recognisable public unit. An internal finance team doesn't become a department entity because it appears on an organisation chart. A legal firm's migration practice may be better represented as a service if clients still engage the same firm through the same contacts and profile.
Use four practical questions for every proposed identity.
- Does it transact, employ, serve or communicate under its own maintained name?
- Do customers need to distinguish it from the parent or sibling entities?
- Does it have its own canonical facts, contacts, profiles or public evidence?
- Can an accountable owner keep those facts accurate?
The answer is a modelling judgement. Document the evidence behind it so a future acquisition or rebrand doesn't reopen the decision from memory.
Give each entity a canonical home
Every approved identity needs one page that states what it is. That page should use its exact public name, explain its role, name its parent or operating company where useful and provide the relevant contact path. The About page entity guide explains how to turn that record into useful buyer-facing content.
The parent may need a concise group page that explains ownership and routes buyers to operating businesses. A subsidiary may need its own About page within the group site. An independent operating brand may justify a separate domain when its audience, proposition and governance are genuinely separate.
Google's crawling and indexing FAQ states that Google has no indexing or ranking preference between subfolders and subdomains. Choose among a folder, subdomain or separate domain based on buyer clarity, publishing ownership, technology and the team's ability to maintain it. Don't justify a fragmented portfolio with a universal SEO claim.
Give each approved entity a stable identifier based on its canonical home. Keep that identifier tied to the entity rather than a template or a temporary campaign URL. A page can explain several relationships, but it shouldn't pretend several businesses are one node.
Map profiles to the entity customers meet
A separate public identity doesn't automatically qualify for a separate Google Business Profile. Google's current guidelines for chains, brands and departments allow separate profiles for independently operating brands at one location and for qualifying public-facing departments. The department needs a distinct name and category, and it typically has its own customer access and hours.
Apply those rules to the business customers can actually visit or contact. Profile names should match real-world brands. A holding company needs an eligible customer-facing operation, and an internal service team needs to qualify as a public department, before either receives a separate profile.
Return to the professional-services group. Its parent company exists to own the operating businesses and doesn't serve clients. It gets a clear group page, but no invented local profile. Each independently operating consultancy maintains the profile that matches its real-world name, contact route and location. The specialist advisory brand remains connected to its provider unless its operations and Google eligibility support a separate profile.
Connect the entities and preserve their identities
Google says Organization structured data can help it understand administrative details and disambiguate an organisation. Google recommends accurate properties that apply to the organisation. It also says structured data doesn't guarantee a search feature.
Once the boundaries are approved, Schema.org provides explicit relationship terms. parentOrganization identifies the larger organisation that contains a sub-organisation. subOrganization expresses the inverse relationship. Use both only for a supported organisational relationship, not for a loose partnership or a service marketed by the parent.
Model a genuine subsidiary as its own Organization with its own stable @id. Point its parentOrganization to the parent's stable identifier. The parent can reference the subsidiary through subOrganization. A commercial brand can remain a Brand node connected to the organisation, service or product it identifies.
Visible content should corroborate these relationships. Structured data can clarify settled facts, but it can't create evidence or force Google or an AI system to accept the model. This is Off Piste's modelling judgement based on the documented vocabulary and platform guidance.
The connected schema graph guide covers stable identifiers and site-wide relationship deployment. The single-organisation schema guide covers the fields for one organisation. After the model is approved, choose a schema implementation route that can preserve it without duplicate nodes.
Check every public source against the model
Turn the approved architecture into a source-of-truth record. For each entity, record its canonical name, page, stable identifier, profiles, relationships, owner and review triggers. Compare the record with website headers and footers, schema, Google Business Profiles, social accounts, major directories, partner pages and credible third-party references.
Repeat the group structure only where it helps the reader, and keep high-value sources consistent. A subsidiary's LinkedIn page can name the parent's domain when it also explains the relationship. A brand page should reserve sameAs for profiles that identify the same brand.
Once the internal model is settled, use the third-party business signals audit to prioritise corrections and record evidence. Without an approved model, a cleanup project can make inconsistent sources consistently wrong.
This control matters because several teams may update the same identity from different systems. Approve the record before distributing implementation work.
Separate steady-state architecture from migration
An approved model describes the intended steady state. Moving from the current estate to that model can become a separate migration project. Renaming a business, consolidating domains, moving subsidiary pages or retiring a brand introduces redirects, canonical changes, profile decisions and continuity risks.
Google's site move guidance calls for URL mapping, permanent server-side redirects, testing and monitoring. It also warns that rankings can fluctuate while Google recrawls and reindexes the moved pages. Use the business rebrand and entity migration guide to sequence that work.
Don't change the entity model and domain estate as an undocumented tidy-up. Record which identities continue, which are new and which genuinely end. That decision determines whether identifiers, profiles and external evidence should remain, move or be retired.
Approve the model before implementation
The finished model should let a new team member identify every public entity, its canonical home, the profiles it owns, its relationships and the person responsible for changes. It should also explain why a service, branch or brand wasn't modelled as a separate organisation.
Approval gives developers a stable graph to build and marketers a consistent set of identities to maintain. It also gives buyers clearer answers about who they're dealing with. Schema can then express the model without being asked to invent it.
Choose website architecture support when the approved structure requires new domains, navigation, pages, templates or CMS records. Choose SEO and entity planning when the main work is diagnosis, profile reconciliation, structured-data requirements or migration sequencing. In either case, settle the operating reality first so implementation reinforces one defensible public model.