Multiple websites, one team: how to keep hosting under control
How a business that runs several websites keeps domains, hosting, access and maintenance from sprawling across providers and people.
The short answer
Businesses rarely plan to run many websites; they accumulate them. A campaign site for a launch, a separate brand, a site for a second country, a portal, an old site nobody switched off. Each arrives with its own provider, its own account, its own person, and two years later nobody holds the full list, renewals lapse, a former supplier still has access to something, and each site is maintained differently or not at all. Control comes from two things: a register of every site with its domain, hosting, repository, owner and renewal dates, and consolidation onto as few providers and patterns as possible. Shared foundations, one platform, one component library, one pipeline pattern and one monitoring view, make five sites cost little more than two to run. Access is granted per person through organisation accounts, never shared, and reviewed whenever people change.
The register
| Column | Why it is there |
|---|---|
| Site and purpose | What it is for and whether it is still needed |
| Domain, registrar, renewal date | Domains lapse silently; the register prevents it |
| Hosting provider and account | Where it runs and in whose name |
| Repository | Where the code and content live |
| Internal owner | Who answers for its content |
| Built and maintained by | Who to call |
| Monitoring | Whether anyone would know if it went down |
| Last significant update | Whether it is drifting |
| Integrations | Forms, analytics, third parties it depends on |
| Decision | Keep, consolidate, redirect or retire |
Getting control
- Build the register from invoices, DNS records, browser bookmarks and asking everyone. Expect surprises.
- Retire or redirect sites that no longer serve a purpose; redirect their domains to the relevant page.
- Move domains into one registrar account in the business’s name with auto-renewal and two-factor authentication.
- Pick the platform and move each remaining site onto it when it is next touched, not all at once.
- Share foundations: one component library with themes, one pipeline pattern, one form and email setup, one analytics approach.
- One monitoring view for every site, with alerts to the same place.
- Access through organisation accounts per person; remove the shared logins; review quarterly and on every departure.
- Assign a portfolio owner who keeps the register alive.
What shared foundations buy
A security update applied once. A design improvement that reaches every site. A new campaign site set up in days from a working base instead of weeks from nothing. One team that can work on any site because they all work the same way. One monthly report covering the portfolio. And a business that can change partners and hand over one register and one pattern rather than six histories.
What this means for you
Keep a register of every site, retire the ones that no longer serve a purpose, consolidate domains into one account in your name, move sites onto one platform with shared foundations as each is next touched, monitor them in one view, grant access per person and name a portfolio owner. Several sites run by one team on one pattern are manageable; several sites run six different ways are a liability waiting for a Monday.
Frequently asked questions
We have six websites on four providers. Where do we start?
With the register: one page listing every site, its domain and registrar, its hosting, its repository if any, who owns it internally, who built it, and every renewal date. The list turns up sites and domains nobody remembered. Then consolidate in order of risk: domains into one registrar account in your name, hosting onto one platform as each site is next touched, access into organisation accounts.
Should every site use the same design and code?
They should share foundations even when they look different: the same platform, the same component library with different themes, the same pipeline and monitoring. That way one team can maintain all of them, an improvement or a security update made once applies everywhere, and a new site starts from a working base rather than from nothing.
Who should own the sites internally?
One named person for the portfolio as a whole, with a named owner for each site's content. The portfolio owner keeps the register, holds the relationship with the partner, approves changes to shared foundations and reviews access. Without that role, each site drifts back to whoever built it.