A managed host for WordPress supplies the infrastructure that makes a website available. It runs the servers, maintains the hosting platform, provides backups, watches its network, and helps recover from infrastructure failures.
A web team operates the website that runs on that infrastructure. It updates WordPress and its extensions, publishes content, investigates application errors, checks forms and integrations, manages releases, and coordinates with the host when the source of a problem is not yet clear.
Both jobs matter, and mixing them up gets expensive during an incident. The host reports that the server is healthy, and you are still looking at a broken form or a page nobody can use.
What an approved host for WordPress should provide
We do not approve a host on its name alone. Plans, account permissions, and support levels differ, so we review the specific setup your website will use.
- SSH and WP-CLI access for controlled maintenance and diagnosis.
- A staging environment where consequential changes can be checked before release.
- Individual delegated accounts, protected by multifactor authentication, instead of shared credentials.
- Automated backups with a restore process that can be used under pressure.
- Continuous infrastructure monitoring and documented crash recovery.
- Technical support available at all hours for infrastructure incidents.
- A current PHP runtime, full-page caching, CDN support, and enough resources for expected traffic.
- An established operating history and a generally strong professional reputation.
Fast is a property of the whole setup
No hosting plan makes every site on it fast. A small brochure site and a membership platform can use the same host and perform very differently.
When we approve a plan as fast, we mean it removes the obvious infrastructure bottlenecks. It runs a current runtime, supports effective caching and content delivery, has room for the site's real traffic, and shows no host-level limits when we measure staging and production.
That still does not guarantee a fast website. Oversized images, unnecessary scripts, inefficient themes, database queries, and third-party integrations can slow down a well-hosted site. Finding and fixing those is the web team's job.
Keep the account in your organization's name
Your organization should own the hosting account and pay the host directly. Staff and vendors should each get their own access, limited to what their work needs.
Hosting is a recurring cost, billed at the host's published rates. It rises with your traffic, and the plan size is your organization's choice.
That way everyone can see who is responsible, and you can remove someone's access promptly. If you change vendors later, nobody ends up arguing over logins or who controls the servers.
It also keeps the business relationship with the host where it belongs, with the organization whose website depends on it.
The question to ask before signing
Don't stop at asking who hosts the website. Ask who runs it after launch.
A complete answer names the host, the account owner, the people with access, the web team, how monitoring works, how backups are restored, how content gets published, and the person who coordinates when something breaks.
If any of those answers is missing, you have bought infrastructure and nobody is running the website.
Leland Fiegel