How Should a Corporate Web Design Company Build Shared Publishing Infrastructure for Group Companies?

How should group companies structure shared web infrastructure?

Enterprise web infrastructure for group companies should be structured to balance central standards with local publishing autonomy within the same system. The parent company can manage technology, security, the design system, and shared data standards, while subsidiaries work within defined permissions for their own content areas. This allows a new brand or subsidiary to extend the existing publishing core instead of starting a website project from scratch.

Start with a site inventory and shared-requirements map

The project should begin with a site inventory before design screens are produced. Record each site’s page types, languages, forms, integrations, user roles, analytics needs, and existing technical debt. The approach to building a multi-brand and multilingual web ecosystem provides a useful framework for identifying which layers can be shared. This inventory helps the corporate web design company prepare its proposal around the real operating scope of the platform rather than simply the number of screens.

• Inventory of existing sites and domains
• Shared and distinct page types
• Language and regional content needs
• Forms, CRM, and other integrations
• User roles and approval workflows

The Web is more a social creation than a technical one. - Tim Berners-Lee

Which design and software components should be shared?

The components that should be shared are the layers that protect brand consistency and technical sustainability without unnecessarily limiting subsidiary content autonomy. Navigation logic, accessibility rules, form infrastructure, core page templates, analytics tagging, security layers, and reusable interface components can all be managed in a central library.

Separate the shared core from brand-level variations

Instead of forcing every brand into the same visual identity, define design-system variables, theme options, and permitted component variations. The approach to scaling custom web design with shared components across multi-brand organizations makes this distinction concrete. Headers, footers, forms, cards, lists, media areas, and calls to action can come from a shared codebase, while color, typography, visual language, or selected campaign modules vary by brand. This allows a security or accessibility correction to be made once in the core and distributed in a controlled way to all relevant sites.

• Shared design system and component library
• Central form and data-validation infrastructure
• Standard analytics and tagging structure
• Shared accessibility and performance rules
• Brand-specific theme and content variations

How should publishing permissions for subsidiaries be separated?

Publishing permissions for subsidiary teams should be separated by role, content type, site, and action. An editor may be allowed to manage only the news for their own subsidiary, while the corporate communications team controls group-wide policies or mandatory announcements. Using approval workflows instead of direct publishing on critical pages creates a measurable balance between central control and operational speed.

Align CMS permissions with the organization structure

When planning multi-brand corporate content management, broad roles such as “admin” and “editor” are rarely sufficient. Responsibilities can be separated into group administrator, brand manager, content editor, legal or compliance approver, and technical administrator. The system should record which sites a user can access, which content they can save as draft, what they can publish, and whether they may change shared components. Defining the permission model during the proposal stage reduces the operational burden that would otherwise grow through manual user management later.

• Group-wide administrator role
• Subsidiary or brand manager
• Content editor and author roles
• Approver and compliance roles
• Technical administrator with limited system permissions

How should shared content changes be distributed across sites?

Shared content changes should be distributed through automatic, approval-based, or local-copy models according to content ownership and risk. Central content such as group policies, legal text, or shared career principles can be updated from one source, while local campaigns, service descriptions, or regional announcements remain under subsidiary control. For every content type, define who owns the source, which sites receive it, and whether local approval is required.

Do not confuse single-source publishing with local independence

Central web management does not mean that every piece of content must be written by one headquarters team. The system can distribute some content to all sites in a locked form, allow subsidiaries to adapt other content, and leave certain areas entirely local. Version history and publishing records are especially important for shared contact information, privacy notices, investor content, or group policies. This model makes it visible when and where a change was propagated and reduces inconsistencies caused by multiple teams updating the same text separately.

• Central shared content that cannot be changed locally
• Shared content distributed with local approval
• Content subsidiaries may adapt
• Fully local content areas
• Version and publishing history records

How should existing site content and URL structures be migrated?

Existing site content and URL structures should be migrated as a dedicated transition project with a content inventory and redirect plan, not as a bulk copy operation. Every URL should be assigned a decision to keep, merge, rewrite, or remove it; correct redirects should be prepared from old addresses to new ones; and the migration should be validated before launch.

Treat migration as a separate work package from design delivery

Planning content and URL migration for an enterprise website requires a repeatable site-by-site method for a group of companies. Quality review of legacy content, media transfer, metadata mapping, redirect lists, and broken-link checks should all appear in the delivery scope. The plan should also define which content will move automatically, which items require editorial revision, and which subsidiary team performs the final review. This turns the migration method developed for the first site into a standard onboarding process for later subsidiaries.

• Content and URL inventory
• Keep, merge, and removal decisions
• 301 redirect mapping
• Media and metadata transfer
• Pre-launch broken-link verification

Who should own centralized security and maintenance?

Centralized security and maintenance should be explicitly assigned to the technical team that operates the infrastructure or to the contracted web provider, not to subsidiary editors. The CMS core, plugins, dependencies, server components, security patches, backups, and monitoring should be managed at the shared platform level. Subsidiary teams should remain responsible for content quality and their own publishing processes.

Build the maintenance contract around the full network lifecycle

Comparing source code, security testing, and maintenance contracts is especially important in multi-site management. The contract should state who tests a security update, in what order it is deployed across sites, who manages the rollback plan, and how notification works during critical incidents. When sites share a codebase, one update may affect the entire network, so a test environment, staged deployment, and rollback procedure should be treated as standard elements of the maintenance service.

• CMS and dependency updates
• Security patching and vulnerability tracking
• Backup and restoration procedures
• Test environment and staged deployment
• Incident notification and technical response

How should adding a new subsidiary website be priced?

The price of adding a new subsidiary website should not simply repeat the cost of the initial platform build. It should separate work reused from the shared infrastructure from work unique to the new brand. A new theme variation, content migration, additional languages, custom integrations, new page types, and local approval workflows increase scope, while reuse of existing shared components can reduce development effort.

Separate the first-site delivery from later site rollouts

Corporate website pricing for multi-brand architecture and centralized management is a useful reference for separating proposal layers. Ask the provider to show the platform core, first reference site, additional subsidiary setup, data migration, custom integration, and ongoing maintenance as separate items. This makes the cost drivers clearer when a new company joins the group and prevents a multi-site management proposal from being evaluated only on the first launch budget.

• Shared platform and core development
• Setup of the first reference website
• Rollout for each additional subsidiary
• Brand-specific design or integration work
• Ongoing maintenance and support service

What should a corporate web design company proposal include?

A corporate web design company proposal should describe the publishing architecture, role model, migration, shared components, integrations, security, testing, and maintenance responsibilities as separate deliverables alongside design and development. In a high-scope group project, a line such as “X websites” is not enough to distinguish the reusable platform investment from the unique work required for each subsidiary.

Compare providers using the same delivery breakdown

When comparing proposals, ask which work makes the first site the platform reference, under what assumptions later sites are launched, and whether changes to shared components are included in maintenance. Test environments, access permissions, analytics setup, documentation, training, and handover should also be visible in scope. The provider’s ability to describe a technical and operational model that can sustainably run multi-brand digital infrastructure becomes as important as visual design capability in the purchasing decision. The proposal should also define on which site acceptance tests will be performed and which tests will be repeated for later subsidiaries.

• Platform architecture and technical scope
• Design system and shared components
• Migration and rollout deliverables
• Permissions, testing, and documentation
• Maintenance, SLA, and change management

How should the shared publishing infrastructure operating model work?

The operating model for shared publishing infrastructure should define responsibility distribution as clearly as the technology itself. The central team manages platform standards, security, and shared components; subsidiary teams own their content calendars and local publishing; and the web provider performs the technical maintenance, development, monitoring, and support duties defined in the contract. This replaces person-dependent decisions with a clear governance model as the system grows.

Measure success by scalable operations, not the first launch

Project acceptance should not be limited to successfully launching the first site. Acceptance criteria should also cover whether a new subsidiary site can be opened through defined steps, user permissions can be managed centrally, shared changes can be distributed in a controlled way, and security updates can be monitored across the network. The real value being purchased is not a single corporate website, but a publishing system that remains reusable and manageable as new brands, teams, and content needs are added.

• Central platform owner
• Subsidiary content owners
• Technical provider and maintenance team
• Change and approval procedures
• Performance, security, and publishing reports