A country subsidiary usually gets its own website by requesting it through the group digital or brand function, which decides what is fixed across the group and what the market can determine. The practical first step is settling that boundary in writing, because it governs the platform, the URL structure, the budget and the timeline more than the design does.
In industrial groups the request is normally driven by something concrete: a distributor network that needs local support material, certification or product availability that differs from the group site, a language the group site does not carry, or search demand in the market going to competitors. Stating that reason in those terms is what moves the request.
Most industrial groups have some form of digital governance, even where it is informal, and a new local site routes through it. Establish what it requires in practice as against what people assume it requires, since the two often differ by a wide margin.
Ask specifically about the platform, the template library, the domain policy and who holds the accounts. Those four answers shape most of what follows.
A request framed as local preference tends to stall. One framed around distributor support, a market where certification or availability differs from the group position, an unserved language, or search demand the group site does not reach is assessed on its merits.
Bring evidence: search volume in the local language, the enquiries currently going unanswered, and what the distributor network is asking for.
Write down what is fixed across the group, typically brand system, platform, template library, legal framework and the source of product data, and what the market determines, typically distributor and contact details, local references, events, recruitment and terminology.
Certification scope and availability need their own rule, since a statement accurate at group level may not hold locally. See local market websites for industrial groups.
A section of the group domain draws on an established domain and is simpler to govern and patch. A separate local domain gives the market more independence and can suit a distinct local brand or a very different commercial model, and it starts without the group domain’s history.
Either can work. What causes difficulty is choosing without recording why, and then revisiting it a year later.
The largest ongoing cost in a local site is usually keeping the product information current. Where the catalogue is fed from a group PIM or ERP, the local site should consume the same source with market-specific fields for availability and certification.
Product data retyped locally diverges from the group position within a year. See PIM and product data.
Record who holds the domain registration, the hosting account, the analytics property and the search console access, who applies security updates, and who may publish without review. Ownership left unstated becomes an access problem when staff or agencies change.
See who owns an industrial website for what the record should contain.
By requesting it through the group digital or brand function, which sets what is fixed across the group and what the market decides. Settle that boundary in writing first, since it determines the platform, the URL structure and the timeline. A request supported by distributor need, local search demand or a market difference in certification or availability progresses more readily.
The project can proceed, provided the boundary is documented rather than assumed. Write down what the local market is deciding and what it is treating as fixed, and have the group function acknowledge it. That record is what prevents rework when the group later formalises a policy, and it often becomes the basis of that policy.
Sometimes, though a shared platform is usually preferable for security patching, cost and consistency across markets. A local exception is easier to justify where the commercial model differs substantially, for example a market operating a distributor portal the group does not run. See multi-brand consolidation for the wider question.
A section of the group domain draws on established domain history and is simpler to govern and patch. A separate domain gives more independence and suits a distinct local brand or a materially different commercial model, starting without that history. Both are workable; recording the reason for the choice matters more than which one is taken.
Agree it before launch and put it in the project scope. Depending on the group, it may sit with the local organisation, with central IT, or with an agency partner, and any of those can work provided it is recorded with named contacts. Left unstated, it becomes an access problem at the point staff or agencies change.
The build is rarely the constraint. Settling the boundary with the group, agreeing the product data source and completing translation into the market language usually take longer than design and development. Once the boundary is settled, a local site generally moves faster than a first group build, since the templates and platform decisions already exist.
Tell us where things stand with the group and we will set out how we would approach the build.