Multisite Architecture for Holdings and Group Companies: Manage Every Subsidiary from One Panel

As holdings and multi-brand organisations grow, their web ecosystems tend to become more complex. The corporate holding website, subsidiary sites, regional companies, product brands and language versions can gradually turn into disconnected platforms. When each site has its own administration panel, infrastructure, agency relationship and publishing process, the result is often inconsistent branding, duplicated development costs, security gaps and slow content operations.

A multisite architecture brings these separate properties together through a shared technical foundation and a centralised management model. The objective, however, is not to make every subsidiary look and behave exactly the same. A well-designed system centralises the standards that must be governed at group level while allowing each company to respond to its own sector, audience and content requirements.

This balance matters to corporate communications, marketing and IT teams. They need to collaborate within the same digital ecosystem without losing clear ownership boundaries. The right architecture can give the holding greater control, make local publishing more efficient and create a sustainable foundation for adding new brands, languages and integrations.

What is multisite architecture, and what does it offer holdings?

Multisite architecture is an approach in which multiple websites share selected content-management capabilities, design components, user infrastructure and technical services. The sites may operate on different domains and retain their own navigation, pages, languages and editorial teams. At the same time, security updates, reusable components, user policies and integration standards can be managed centrally.

One of its main advantages is scalability. When a new subsidiary website is needed, the organisation can start with approved templates, content models and components instead of building the entire infrastructure again. Changes that apply across the group do not have to be implemented manually on every site. An updated brand colour, accessibility rule, privacy notice or legal component can be distributed to the relevant properties through a controlled process.

Centralisation also improves visibility. Teams can see which websites are current, which content is awaiting approval, who has access to each area and whether integrations are operating correctly. This creates a clearer governance model for an ecosystem that might otherwise depend on informal knowledge and separate supplier relationships.

Multisite is not automatically the right choice for every group. If subsidiaries have radically different regulatory, operational or technology requirements, forcing them into one application may introduce risk and unnecessary complexity. In those cases, a hybrid model—separate applications connected through shared services, standards and a common design system—may provide a better balance.

How should the right architecture be determined through needs analysis?

The discovery process must examine more than the current number of websites. For every subsidiary or brand, the organisation should document audiences, content types, languages, domains, visitor transactions, regulatory obligations, editorial owners and technical connections. This inventory may also uncover inactive microsites, duplicate content and properties that could be consolidated.

The next step is to define the boundary between central and local decisions. The holding may own global navigation rules, footer structures, corporate policies, design tokens, accessibility standards and security controls. Subsidiary teams may own news, products, projects, careers, local contact details and market-specific campaigns. Without this distinction, the platform can become either excessively centralised and slow or fragmented and difficult to govern.

Technical architecture should follow these organisational needs. A single application and database can be efficient where sites share a high proportion of content and functionality. Separate applications supported by a shared design system and central services can offer more operational independence. A hybrid architecture can isolate critical or regulated websites while keeping standard subsidiary sites on a common platform.

The decision should therefore account for long-term maintenance, release management, data separation, expected growth and failure impact—not only initial development cost. A representative pilot can validate assumptions before the model is extended across the entire group.

How should information architecture and a shared design system be structured?

A holding website and a subsidiary website usually answer different visitor questions. The group website may communicate scale, governance and strategic direction to investors, partners, media and potential employees. A subsidiary site may focus on products, services, technical expertise or customer enquiries. Applying one identical menu to every property rarely serves these different journeys well.

Instead, the organisation should establish shared content models alongside information architectures tailored to each site type. Common page categories might include corporate profile, management, policies, careers and news. Sector-specific templates can then support product families, technical documents, financial reports, case studies, dealer information or application forms.

A shared design system goes beyond colours, typefaces and buttons. It can include navigation patterns, cards, forms, notices, media galleries, management profiles, financial-document lists and sustainability indicators. Each component should have documented usage rules, responsive behaviour, accessibility requirements and permitted variants.

This approach keeps the brand family recognisable without erasing the identity of individual companies. A subsidiary may use an approved theme, selected layout variants and its own content hierarchy while still benefiting from centrally maintained components. Kumsal Agency’s corporate web design and custom web development approach treats brand expression, real user needs and manageable software infrastructure as connected parts of the same system.

How should roles, permissions and publishing workflows be modelled?

A single administration panel should not mean that every user can modify every website. Roles can be organised around responsibilities such as group administrator, central editor, subsidiary manager, local editor, translator, legal approver and technical administrator. Permissions should be defined by site, language, content type and action.

For example, a local editor may draft and update news for one company without being able to change global navigation or access another subsidiary’s content. A translator may work only on assigned languages, while legal or brand reviewers may approve selected page types without receiving broad administrative privileges.

The principle of least privilege gives users only the access required to perform their responsibilities. The OWASP Authorization Cheat Sheet recommends modelling permissions around users, resources and actions, validating authorisation on every request and reviewing permissions over time. Applied to a multisite platform, these practices help reduce both horizontal and vertical access violations.

The content lifecycle may include drafting, editorial review, legal or brand approval, scheduled publishing and archiving. High-risk pages can require two approvals, while urgent announcements can follow a documented accelerated workflow. Version histories and audit logs should record what changed, who changed it and when. Offboarding and periodic role reviews are equally important, particularly when employees move between companies within the group.

Managing multilingual and shared content

Multilingual management involves more than duplicating text fields. Each site needs defined active languages, a default language, translation owners, publication rules and behaviour for missing translations. When a source-language page changes, the panel should mark its linked translations as potentially outdated. Publication can also be blocked until required fields and approvals are complete.

Some information—such as the group profile, ethical principles, data policies or leadership information—may be supplied centrally. Yet local regulations, contact details and legal wording may require subsidiary-level adaptation. It is useful to classify content as fully shared, centrally derived but locally editable, or exclusively owned by a subsidiary.

Search visibility must be considered within the same model. Consistent URL structures, redirects, canonical decisions, hreflang annotations and translatable metadata should be planned for each language and region. XML sitemaps should reflect actual publication status, while drafts, closed pages and unnecessary duplicates should remain outside the index.

Integrations and data ownership

A multisite platform may connect to CRM, HR, ERP, investor-relations, email, analytics or document-management systems. Before building an integration, teams should identify the authoritative source for each dataset. If vacancies are governed in the HR platform, creating a second manually maintained copy in the website panel increases inconsistency. A secure integration should publish the approved source data instead.

Form routing may change according to company, country, language, subject or product. Field mappings, consent records, duplicate-handling rules, failure queues and retry scenarios must therefore be documented. The existing guide on planning website–CRM integration from form submission to sales follow-up provides a relevant framework for defining ownership and exception handling.

Integrations should use documented APIs, restricted service accounts and traceable error records rather than uncontrolled database access. Teams should also determine what visitors see when an external system is temporarily unavailable, how failed transactions are retried and which operational team receives the alert.

Performance, security and GDPR compliance

A platform-level performance issue can affect several brands simultaneously. Image optimisation, caching, CDN strategy, code splitting and third-party script policies should therefore be governed across the platform. Measurement must still remain site-specific: a fast holding homepage should not conceal a slow subsidiary website. Google’s Web Vitals guidance provides metrics for monitoring loading performance, responsiveness and visual stability from the user’s perspective.

Security controls may include central authentication, strong password policies, multi-factor authentication where appropriate, session controls and recurring access reviews. Subsidiary data should be logically separated, and uploads, API requests and administration actions must be validated. Backups are not sufficient on their own; restoration procedures should be tested, and isolation measures should limit the spread of a failure or compromise from one site to others.

GDPR compliance cannot be reduced to adding a cookie banner. Forms and integrations must account for purpose, legal basis, retention, recipients and data-subject rights. The European Commission’s explanation of the principles of the GDPR covers purpose limitation, data minimisation, storage limitation, accuracy, integrity, confidentiality and accountability. Cookie and analytics choices should also be recorded and managed according to the relevant brand and country requirements.

How should testing and launch be managed?

Testing should not be limited to one demonstration website. Acceptance scenarios are needed for each site type, role, language, template and integration. Teams should jointly verify mobile layouts, keyboard access, form validation, links, metadata, redirects, permission boundaries, performance and security. Automated regression tests are especially valuable when a shared component change could affect many subsidiaries.

Launch can be organised in controlled waves rather than as one large migration. A representative pilot subsidiary allows teams to validate content migration, editor training and support processes under real conditions. Lessons from that launch can then be incorporated into templates, workflows and documentation before the next group of sites moves.

Redirects from legacy URLs, analytics tags, search-engine access, DNS changes and rollback procedures should be prepared for every wave. After launch, platform ownership must be explicit: one team may maintain the technical foundation, another may govern content quality, while a defined owner handles user provisioning and removal.

When the processes for adding a subsidiary, creating a theme variation and requesting an integration are standardised, the multisite platform becomes a sustainable corporate product rather than a one-off website project.

How does Kumsal Agency approach a multisite project?

Kumsal Agency combines corporate web design and project-specific web development as two parts of one solution. The process begins with needs analysis, stakeholder interviews and an inventory of existing digital properties. This informs the information architecture, shared design system, subsidiary templates, content models, role matrix and integration map.

An Art Director-led creative approach balances the holding’s corporate identity with the need for subsidiaries to remain distinctive. The software architecture is designed around manageability, performance, data security and scalability. Multilingual requirements, approvals, integrations, GDPR obligations, test coverage and phased deployment are defined early so design decisions remain connected to day-to-day operations.

A successful multisite investment does more than place several websites inside one panel. It makes the organisation’s digital governance model visible, enforceable and easier to improve. To plan a multisite architecture around your holding’s subsidiaries, brands, languages, user roles and integration requirements, contact Kumsal Agency.