The site went down on a Monday. The developer said it was a hosting problem. The host said the server was fine and it must be something in WordPress. You were in the middle, forwarding emails between two people who each thought the other should fix it, while customers saw an error page.
That argument happens because nobody wrote down who is responsible for website maintenance before something broke. Several parties touch a business website, and each assumes a boundary that the others may not share. This post sets out who those parties are, what each one normally looks after by default, where the gaps fall, and how to write a single page that settles it before the next Monday.
Who is responsible for website maintenance: the parties involved
Even a small business site usually involves more people and companies than the owner realises:
- You, the owner. The business the site belongs to, and whoever on your staff edits it.
- The developer or agency that built it. Possibly still around, possibly long gone.
- The hosting company. Runs the server the site lives on.
- The domain registrar. Holds the registration of your domain name. Sometimes the same company as the host, often not.
- A maintenance provider, if you have one.
- Third-party services. Plugin and theme authors, the email provider, the payment gateway, the form or booking service.
Each of these has a sensible area of responsibility. The trouble is that the areas do not join up neatly, and the joins are where problems fall through.
What each party is normally responsible for
The hosting company
The host is responsible for the server: that it is running, that the hardware works, that the network connection is up, and that the server software is patched. Many hosts also provide backups and basic security filtering, but what those include varies a great deal between plans. Hosts are generally not responsible for the code your site runs on top of their server, which in a WordPress site means WordPress itself, the theme and every plugin. The line between the two is examined in detail in the post on where hosting stops and maintenance starts.
The developer who built the site
Their responsibility normally ends when the project ends, apart from any fault-fixing period written into the agreement. They are responsible for the site working as agreed at handover. They are not, by default, responsible for keeping it updated afterwards, for problems caused by later updates, or for anything someone else changes. Many owners assume the developer is still looking after things. Unless there is an ongoing agreement, they are not.
The domain registrar
The registrar keeps your domain registered for as long as you pay for it, and lets you control where it points. Renewing on time is your job, though most registrars offer automatic renewal.
A maintenance provider
If you hire one, they take on whatever the agreement lists: typically updates, backups, security monitoring and some fixes. The key word is “lists”. A maintenance provider is responsible for what is written down, not for everything that could be called maintenance.
Third parties
A plugin author is responsible for their plugin’s code, but not for how it interacts with the other plugins on your site. Your email provider is responsible for delivering mail, but not for a form on your site that sends from a misconfigured address. Each third party is responsible for its own piece, and nobody is responsible for how the pieces fit together unless you make it someone’s job.
You, the owner
Here is the uncomfortable part. Anything not clearly assigned to someone else falls to you by default. That includes the content, the legal pages, renewing accounts, deciding who has access, and, if no maintenance arrangement exists, the updates and backups too.
A responsibility map for the common tasks
This table shows who usually handles each task when nothing else has been agreed, and what is worth writing down to avoid confusion.
| Task | Usually falls to | Worth writing down |
|---|---|---|
| Domain renewal | Owner | Whose card pays, and whose email gets the reminders |
| Hosting renewal and plan | Owner | Who decides when the plan needs upgrading |
| Server uptime | Host | Who contacts the host when the site is down |
| Security certificate | Host, often automatic | Who checks it renewed |
| WordPress, theme and plugin updates | Owner, unless a provider is hired | Who applies them, and who tests after |
| Backups | Varies. Host backups may exist but may not be enough | Where copies are kept, for how long, and who has tested a restore |
| Premium plugin licences | Owner | Whose account holds them, and the renewal dates |
| Text, images and prices | Owner | Who is allowed to edit, and who approves |
| Privacy policy and legal pages | Owner | Who keeps them current when the site changes |
| Contact form delivery | Gap: often nobody | Who tests it, and how often |
| Business email | Email provider for the service, owner for the accounts | Who manages mailboxes and passwords |
| Analytics and Search Console | Gap: often the original developer’s account | Which business account owns them |
Notice the two rows marked as gaps. Form delivery and tracking are the tasks that most often have no owner at all, which is how a business can go months before noticing that its form was not sending or its analytics had stopped recording.
Developer or hosting responsibility: the grey areas
Some problems genuinely sit between parties, and it helps to know the usual answer before the argument starts.
The site is slow
Could be the server, could be the site. A slow admin and a slow homepage on a quiet night suggest the site itself. Everything slowing down together at busy times suggests the server or plan. Ask the host for resource usage figures before deciding.
The site was hacked
The common ways into a WordPress site are outdated or vulnerable plugins and themes and weak passwords, all of which sit on the site side of the line. Hosts can still bear some responsibility, for instance on poorly separated shared servers. The post on whether a host is to blame for a hacked site works through how to tell.
An update broke the site
If a maintenance provider applied the update, fixing it is normally their job. If an automatic update ran with nobody watching, it is yours. If the developer’s custom code broke because of a plugin update a year after handover, that is not a fault in their original work, though they may be the quickest person to fix it.
Business email has stopped working
If your mailboxes are with a separate provider such as Google Workspace or Microsoft 365, the provider runs the service, but the DNS records that route mail to it sit at your registrar or host. A website change that touches DNS, such as a move to new hosting, can break email without anyone touching the mailboxes. Whoever changes DNS records should check mail still flows afterwards, and that is worth writing into the sheet.
A premium plugin licence lapsed
When a paid licence expires, the plugin usually keeps working but stops receiving updates, including security fixes. Renewing is normally the owner’s job unless a provider has agreed to manage licences. If the licence sits in the old developer’s account, nobody may even receive the reminder.
The legal pages are out of date
Almost always the owner’s responsibility. A developer or maintainer can publish what you give them, but deciding what your privacy policy says is a business decision. This is general information, not legal advice, and the post on keeping a privacy policy current covers the practical side.
Writing a one-page responsibility sheet
The fix for all of this is short and unglamorous. Write a single page, share it with everyone involved, and keep it with your account records.
- List every account: domain, hosting, WordPress admin, email, analytics, Search Console, payment gateway, premium plugins. Next to each, write who owns it and who has access.
- Take the table above and fill in a name, not a company type, against each task. “Priya in the office”, “the host’s support desk”, “our maintenance provider”.
- Add a line for emergencies: the first person to ring if the homepage shows an error, and the person who decides whether it goes to the host or the developer.
- Date it, and review it whenever anyone joins, leaves or changes role.
The best moment to write this is right after a new site goes live, while the developer is still engaged. The post on the first months after a site launches covers that window in full.
Handing the technical rows to someone
Many owners fill in the sheet and realise their own name is next to most of the technical rows. That is the honest starting point for deciding whether to keep them or hand them over. A website maintenance agency can take the updates, backups, monitoring and fixes, but the sheet still matters, because it tells everyone exactly where the provider’s job ends and yours continues.
Seeing who covers what
If you want to know which of those rows we would take on and which would stay with you, the full list of our services sets out the scope of each one, so you can fill in your sheet before talking to anyone.
Next in this series: What Counts as a Website Content Update?
