How Holding Companies Verify Subsidiary Digital Presence
2026-10-09 · 10 min read
I run three companies. Not through one holding entity, but as separate legal entities with overlapping directorship. From the inside, the relationships between these companies make perfect sense. From the outside, to a verification team that has never heard of any of them, the picture is confusing.
Three domains. Some shared directors. Different industries. Different clients. Some shared address history. To someone doing digital due diligence, this looks like it could be a legitimate multi-company operation or a network of shell companies. The difference between those two conclusions depends entirely on how well the digital presence is structured.
This essay is about how holding companies and multi-entity groups get verified digitally. Not the legal structure. Not the accounting. The digital layer. Because that layer is where modern verification starts, and where most multi-entity businesses fail.
The multi-entity verification problem
Single-entity verification is relatively straightforward. One company, one website, one registration, one set of directors. Cross-reference everything and check for consistency. The full pipeline is documented in how to pass digital due diligence.
Multi-entity verification adds complexity at every step. Which entities are related? Who controls what? Are shared directors a sign of coordination or a sign of something else? Does each entity have independent operations or are they all fronts for the same thing?
These are the questions a verification team asks when they encounter a group structure. And the answers they find depend on what the digital presence shows them.
Engineering"] A --> C["Subsidiary B
Distribution"] A --> D["Subsidiary C
Manufacturing"] B --> E["Website A
Own domain, own content"] C --> F["Website B
Own domain, own content"] D --> G["Website C
Own domain, own content"] E --> H["Schema: parentOrganization → A
sameAs → LinkedIn A"] F --> I["Schema: parentOrganization → A
sameAs → LinkedIn B"] G --> J["Schema: parentOrganization → A
sameAs → LinkedIn C"] H --> K["Verification: Entities are
distinct but connected"] I --> K J --> K style A fill:#222221,stroke:#c8a882,color:#ede9e3 style B fill:#222221,stroke:#6b8f71,color:#ede9e3 style C fill:#222221,stroke:#6b8f71,color:#ede9e3 style D fill:#222221,stroke:#6b8f71,color:#ede9e3 style E fill:#222221,stroke:#c8a882,color:#ede9e3 style F fill:#222221,stroke:#c8a882,color:#ede9e3 style G fill:#222221,stroke:#c8a882,color:#ede9e3 style H fill:#222221,stroke:#6b8f71,color:#ede9e3 style I fill:#222221,stroke:#6b8f71,color:#ede9e3 style J fill:#222221,stroke:#6b8f71,color:#ede9e3 style K fill:#222221,stroke:#6b8f71,color:#ede9e3
What verifiers look for in multi-entity structures
The first thing a verification team does is map the relationships. Who owns what. Who directs what. Where do entities share resources, addresses, or personnel. They build this map from public data, and the quality of that map determines their confidence level.
If the relationships are clearly declared, via website "About" pages, schema.org parentOrganization markup, and consistent corporate structure documentation, the map is clear. If the relationships are hidden or ambiguous, the verifier has to guess. And guessing makes them nervous.
Key verification points for multi-entity groups:
Distinct operations. Each entity should demonstrate independent operational capability. Its own projects, its own client references, its own team beyond the shared directors. An entity that has nothing but a website and a director list looks like a paper company.
Declared relationships. The connection between entities should be stated, not hidden. "PT Alpha is a subsidiary of PT Beta Group" on the About page. parentOrganization in the schema markup. Cross-links between entity websites. This is the closed-loop entity principle applied to a group structure.
Independent verification surfaces. Each entity should exist independently in verification databases. Separate AHU registrations, separate NPWP numbers, separate Google Business Profiles. If all entities share a single digital footprint, verifiers cannot distinguish them from aliases.
Consistent director information. When the same person appears as director of multiple entities, that director's personal digital presence should reflect all roles. LinkedIn should list all board positions. The personal or holding company website should acknowledge the group structure. Hiding multi-entity involvement looks deliberate and raises questions.
The sameAs problem
Schema.org provides the sameAs property specifically to link different representations of the same entity. For multi-entity groups, this becomes critical.
Each entity needs its own sameAs declarations: its website, its LinkedIn, its Google Business Profile, its Wikidata entry if it has one. And these sameAs links should NOT overlap between entities. If Subsidiary A and Subsidiary B both claim the same LinkedIn page as sameAs, you have just told every machine reader that they are the same entity. That is either confusing or suspicious.
This sounds obvious, but I see it constantly. A group has one LinkedIn company page that serves as the face of three entities. One Google Business Profile for the whole group. One website that vaguely covers everything. To humans, this might seem efficient. To verification systems, it makes entity disambiguation impossible.
The shared address question
Multiple entities at the same registered address is common and legitimate. Especially for small groups in Indonesia where the holding operates from one office. But it is also a pattern associated with shell company networks. Verifiers know this.
The mitigation is context. If three entities share an address but each has its own operational content, its own projects, its own team, the shared address is clearly just a shared office. If three entities share an address and none of them show independent operational activity, the shared address becomes a red flag.
Some groups solve this by giving each entity a slightly different floor or unit designation, even within the same building. This is not deception. It is making the physical separation visible in registration data. "Jl. Example No. 15, Lantai 1" versus "Jl. Example No. 15, Lantai 2" versus "Jl. Example No. 15, Lantai 3."
Building multi-entity digital infrastructure
The minimum viable approach for a multi-entity group:
Separate websites for each entity that has client-facing operations. Not subdomains. Not sections on a group website. Separate domains with separate content. Each domain should be able to stand on its own as a complete entity representation.
A group or holding page that maps the relationships. This can be a section on the parent company's website or a standalone corporate page. It should clearly state which entities are in the group, what each one does, and how they relate.
Schema markup on each entity's website declaring the parentOrganization relationship. This makes the structure machine-readable. AI agents can then accurately describe your group structure when asked.
Separate LinkedIn company pages for each entity. Shared directors should be listed on all relevant pages. Employee counts should reflect actual team sizes per entity.
Separate Google Business Profiles where applicable. Especially if entities serve different markets or have different physical locations.
Cross-linking between entity websites. Not hidden in footers. Visible in the About or Corporate Structure section. These links tell both humans and machines that the relationships are acknowledged and transparent.
When less is more
Not every legal entity needs a full digital presence. If you have a holding company that exists purely as a legal vehicle for ownership and does not interact with clients, it probably does not need a website. The operating subsidiaries need websites. The holding needs to be referenced by the subsidiaries, but it does not need to be a standalone digital entity.
Over-building the digital presence of non-operating entities can actually backfire. It creates entities that look like they should have substance but do not. A holding company website with no projects, no team, and no clients raises more questions than no website at all.
Focus digital infrastructure investment on entities that face clients, win contracts, and undergo due diligence. Make sure those entities reference the group structure clearly. That is enough for most multi-entity operations.
For companies navigating this, entity infrastructure services exist specifically because building coherent digital presence across multiple entities is harder than it looks. And the course library covers the technical foundations for teams who want to build it internally.
Common mistakes in multi-entity digital presence
One website for everything. A single site that tries to represent three different companies under one domain. Every verifier will struggle to figure out which entity they are evaluating. Separate domains. Always.
Hiding relationships. Entities that are related but do not acknowledge the relationship digitally. This looks like the group is trying to appear as independent companies. Verifiers will find the connections anyway through director overlap and address matching. Better to declare them upfront.
Inconsistent director bios. The same director described differently on different entity websites. Different titles, different responsibilities, different photos. This creates confusion and raises questions about which version is accurate.
No group structure documentation. None of the entity websites explain how they fit together. The verifier has to piece together the puzzle from fragments. That puzzle-solving process generates friction and suspicion, even when the underlying structure is perfectly clean.
Frequently Asked Questions
Do all subsidiaries need their own website?
Only subsidiaries that face clients, win contracts, or undergo due diligence need standalone websites. A pure holding company or a dormant subsidiary does not need one. But any entity that will be searched by buyers, investors, or procurement teams needs its own digital presence that can stand independently while clearly referencing the group structure.
How do I handle shared directors across entities in schema markup?
Each entity's Organization schema should list its own officers using the employee or member property. A director who appears in multiple entities should have a consistent Person entity across all schemas, with the same name, sameAs links (LinkedIn, etc.), and jobTitle appropriate to each entity. The key is consistency. The same director should not be "Ibrahim Anwar" on one site and "I. Anwar" on another.
Is it suspicious to have multiple companies with overlapping directors?
Not inherently. Overlapping directors are common in group structures worldwide. What makes it suspicious is when the overlap is hidden, when the entities lack independent operational substance, or when the relationship pattern looks like it was designed to obscure ownership rather than organize operations. Declaring the relationships transparently removes the suspicion.
Related notes
The companies that show up in ChatGPT are the ones that bothered to be verifiable.