The business should own the domain, the code, the content, the product data, the hosting accounts and administrator access, with one named person accountable for the website as a whole. Delivery partners build and support it; they should not hold the assets it depends on.
Ownership splits in practice, and that is where the difficulty starts. Marketing typically drives content, IT holds infrastructure and security, and engineering or product signs off technical claims. None of them owns the site end to end unless somebody says so, and after a reorganisation or an agency change the gap usually appears in the accounts that were never transferred.
These are two different questions and conflating them causes most of the confusion. Asset ownership covers the domain registration, DNS, source code and its repository, hosting and CDN accounts, the CMS licence, analytics properties, SSL and the content and product data. All of those should sit with the business.
Decision ownership covers who sets the roadmap, who approves spend, who signs off technical claims and who can publish. Those can be distributed, provided they are written down.
Check the registrant on the domain rather than the administrative contact, since domains registered by a former agency or a departed employee are common and only surface at renewal. Confirm the repository is on an account the business controls and that the licence terms permit another supplier to work on the code.
Confirm the same for hosting, DNS, analytics, search console, the CDN and the email or transactional sending service.
Marketing usually drives content strategy and day-to-day publishing. IT frequently owns infrastructure, security and integration. Engineering, product or quality functions own the accuracy of specifications, performance claims and certification statements.
The gaps appear between them. The redirect map, the accessibility statement, the consent configuration, the plugin inventory and the decision to retire an old microsite are owned by none of the three. Those are the items that go unmaintained for years.
Where distributors or regional offices publish local content, ownership divides between a central team setting standards, structure and brand, and local teams managing market-specific material. Friction concentrates on who can change a product specification and who arbitrates when local and central content disagree.
Resolve it by making the central team the owner of the product data and structure, and the local team the owner of market context and commercial content, with the boundary written down before access is granted.
During a build, a project team or agency usually holds day-to-day decision-making. Once live, responsibility should move to an internal owner covering content updates, maintenance, monitoring and roadmap. Where that handover is assumed rather than defined, a period follows with no active owner.
Define the transfer before launch: what moves, to whom, on what date, and what the ongoing support arrangement covers.
A short governance record naming the owner of each asset and each decision type, per property, is what resolves this permanently. It should include the renewal dates that cause outages when missed and the offboarding steps for departing staff and suppliers.
Review it annually and after any reorganisation, acquisition or supplier change. Where the current position is unclear, an inventory of properties and access is the practical starting point, which is part of our website support engagement.
The business should own the domain, code, content, product data, hosting accounts and administrator access, with one named person accountable for the site overall. Delivery partners build and maintain it without holding the assets. Decision ownership can be distributed across marketing, IT and engineering provided the split is documented rather than assumed.
The domain registration, checking the registrant rather than the administrative contact; DNS control; the source code repository on a business-controlled account with licence terms allowing another supplier to work on it; hosting and CDN accounts; the CMS licence; analytics and search console properties; SSL; and the content, product data and media library.
It is more common than it appears, particularly after reorganisations or agency transitions where responsibility shifted without documentation. An inventory is the practical starting point: what properties exist, who holds each account, who has administrator access and who is making decisions today. That gives a factual basis for assigning ownership going forward.
It usually splits between a central team owning product data, structure, brand and standards, and local teams owning market context and commercial content. Friction concentrates on who may change a specification and who arbitrates disagreement. Define that boundary and the associated permissions before access is granted rather than after the first conflict.
Usually. During a build the project team or agency holds day-to-day decision-making; once live it should move to an internal owner covering content, maintenance, monitoring and roadmap. Define what transfers, to whom and on what date before launch, since an assumed handover leaves a period without an active owner for the site.
They are separate. Content sign-off is a workflow question, with engineering or product approving specifications and technical claims, and marketing owning presentation and publishing. Site ownership is a single accountable role covering roadmap, budget and operating condition. Documenting both, per property, is what keeps the two from being confused.
Tell us your structure and we will help you define clear, current ownership.