A Saudi group rarely has a website problem. It has nine of them: subsidiaries that each bought their own site, from their own vendor, in their own year — different brands, Arabic coverage and patching, and no way for the group to publish news or careers once. The answer is not one giant website, which would flatten subsidiaries facing different customers. It is one of three architectures, chosen by a simple test, and governed once chosen.
The short answer: three architectures, and the test that chooses between them
Option one is a group website with subsidiary sections — one domain, one platform, each business inside it. Option two is one platform running many subsidiary sites — a shared engine, design system and updates, while each subsidiary keeps its own site and its own domain. Option three is separate sites on shared standards — independent builds, but one design system and security standard.
The test is how distinct the subsidiaries are. If they share customers, a brand and a sales conversation, they belong on one website. If they share technology but face different markets under different names, they belong on one platform with many fronts. If they are distinct businesses sharing only an owner, they belong on separate sites, standardised:
| Question | One group website | One platform, many sites | Separate sites, shared standards |
|---|---|---|---|
| Brand | Group brand leads | Subsidiary brands lead | Fully independent |
| Domains | One | One per subsidiary | One per subsidiary |
| Publishing | Central team | Subsidiary editors, shared platform | Each site's own team |
| Updates and security | Once, centrally | Once, on the platform | Per site, to group standard |
| Best when | Subsidiaries sell as one group | Shared needs, distinct markets | Distinct businesses, shared owner |
The estate you actually have: auditing nine sites, five vendors and no centre
Before choosing, audit what exists. For every site record the domain and who owns the registration, the platform and version, the vendor and contract, hosting, analytics access, Arabic coverage, and who can publish. Add the risks: unpatched systems, admin accounts held by departed staff or vendors, domains in an individual's name.
The audit usually changes the conversation: two subsidiaries serving overlapping customers with competing sites, the best-ranking site the one nobody dares touch. Choose against this evidence, not the tidiest diagram. Our guide to web development in Saudi Arabia sets out the delivery landscape.
Option 1 — One group website with subsidiary sections: when unity wins
Choose one website when the subsidiaries are, in the customer's eyes, one group: shared brand family, overlapping customers, cross-selling, and group content — leadership, governance, careers, news — worth more than any subsidiary's pages. Each subsidiary becomes a full section, typically in subfolders, with its own services, leadership and contact routes, under group navigation and search.
The gains: one platform to patch, one design system, one bilingual standard, group news published once. So are the costs. A subsidiary with a strong name gives it up as an address, and its search presence must be migrated into the group domain with the redirect discipline below. If a subsidiary may one day be sold, folding its presence into the group site makes separation harder. Unity wins when the group brand is the asset.
Option 2 — One platform, many subsidiary sites: shared engine, separate fronts
This is the architecture most Saudi groups need. One platform — a multisite CMS setup, in which one installation runs many sites (WordPress's own documentation describes this network model), or a headless platform serving several front ends — powers every subsidiary site. Each subsidiary keeps its domain, brand and editors; the group keeps one codebase, design system, hosting and security standard, and updates applied once for everyone.
It fits groups whose subsidiaries face distinct markets but share publishing needs: services, news, careers, Arabic and English. The risk is coupling: a platform failure or badly tested update touches every site at once, so staging, staged rollouts and per-site rollback are part of the design. Our headless CMS development service is one way this layer is built.
Option 3 — Separate sites on shared standards: when independence is the point
Some subsidiaries should stay separate: a consumer brand and an industrial business under one holding company share nothing a website could express, and a business preparing for sale needs clean separation. Independence is the point — of presence, not of standards.
The group still sets the floor: shared design-system principles and group branding rules, a minimum security and patching standard, hosting and backup requirements, readable group analytics, and domains registered to the group, never to vendors or individuals. It gives up publishing control and shared components; it keeps comparability — every site meets the same baseline, audited annually. This option fails only when "shared standards" is a document nobody enforces.
Domains and SEO: what consolidation does to each subsidiary's rankings
Every subsidiary domain carries its own search history: indexed pages, partner and directory links, brand searches. Consolidating domains is a site move, and Google Search Central's site-move guidance applies — a one-to-one redirect map from every old page to its new home, redirects kept in place as long as possible (Google says generally at least one year), and monitoring while Google reprocesses the move. Budget for that work per domain; it does not shrink because domains share an owner.
Where subsidiaries keep their domains — options two and three — there is no move and no risk, itself an argument for those options when a subsidiary ranks well. On subfolders versus subdomains, treat it as a structure decision, not an SEO shortcut: Google's documentation treats moving content between paths and subdomains as the same site move.
Governance that works: central platform team, subsidiary editors, approval rights
Architecture without governance decays into nine inconsistent sites, just on newer technology. The model that works splits three rights. The central platform team owns the platform: updates, security, templates, design system, hosting and vendors. Subsidiary editors own their content — services, projects, news, hiring — published inside approved templates without asking the centre. Group communications owns the shared surfaces: the group homepage, governance and leadership pages, and anything carrying the group's name to investors or media.
Approval rights follow the same split. Routine content is approved inside the subsidiary. Pages that commit the group — financial information, disclosures, crisis statements — require central approval, enforced by platform roles and workflows, not politeness. Write the model down before building; permissions are easier to design than retrofit.
The shared layer every group needs: design system, careers, newsroom and group disclosures
Whichever architecture wins, four things should be built once. The design system — components, typography, Arabic and English type handling — so every subsidiary looks like family even on separate sites; the design-system approach for multi-branch businesses shows the component discipline involved. A group careers function, so candidates find every vacancy in one place. A group newsroom, publishing announcements once and surfacing them on relevant subsidiary sites. And the group disclosure pages — governance, leadership, legal information — maintained centrally so they never drift into nine versions. Each shared service removes a reason to improvise, which is where inconsistency comes from.
Arabic across the group: one bilingual standard, not nine translations
In most group estates, Arabic is where inconsistency shows first: one subsidiary fully Arabic, one machine-translated, one English-only with an Arabic homepage. Set one standard: every public page in Arabic and English, from one translation workflow with an agreed terminology list for names, sector terms and titles, and templates tested in right-to-left once, centrally, rather than nine times with nine results.
The mechanics of bilingual architecture are covered in our multilingual website architecture guide. The group decision is simpler: Arabic is a publishing requirement enforced by the platform's workflow, not a favour each subsidiary grants.
Migrating the estate without a big-bang launch
Do not relaunch nine sites in one weekend. Migrate in waves: audit first, build the platform and shared layer, then move subsidiaries one or two at a time, starting with the weakest or most at-risk site — unpatched, or its vendor gone — not the flagship. Each wave carries a redirect map if its domain or URLs change, plus a pause to fix what it taught.
Sequence the flagship last, when platform, governance and bilingual workflow are proven on smaller sites. The group's own pages — careers, newsroom, disclosures — can move early, as new shared builds, not migrations. A phased programme takes longer, far less out of the business, and never bets the group's whole presence on one night.
FAQ
Should a holding group put all subsidiaries on one website?
Only when subsidiaries share a brand, customers and a sales conversation. Groups with distinct subsidiary markets usually do better with one platform running separate sites; genuinely distinct businesses can stay separate, held to shared standards.
Will merging subsidiary websites hurt their Google rankings?
Consolidation is a site move for each domain, so rankings are at risk if done casually. A one-to-one redirect map for every old page, kept in place at least a year as Google advises, plus post-move monitoring, protects existing search presence.
Is a subdomain or a subfolder better for a subsidiary?
Neither is an SEO shortcut — Google treats moving content between subfolders and subdomains as the same kind of site move. Use subfolders for sections of one group site, and a subdomain or the subsidiary's own domain where it genuinely stands apart.
Can each subsidiary keep its own brand and domain?
Yes. On a shared platform, each subsidiary keeps its domain, branding and editors while the group runs one codebase, design system and update process underneath. Separate sites keep even the builds independent.
Who should be able to publish on a group website?
Subsidiary editors publish routine content inside approved templates. The central team owns templates, updates and security; group-level pages — governance, financial information, statements — require central approval first.
Get the group estate mapped before you commission anything (CTA)
The expensive mistake is commissioning nine websites — or one — before the architecture is chosen. WebStackRank starts group work with the estate audit and architecture decision, then delivers the platform as a scoped programme: custom work, priced by an itemised proposal within 24 business hours once the estate is mapped, not from a starter package. Start with our web design in Saudi Arabia team and bring your list of sites and vendors.
