Two anonymised Stewart Media incidents shaped the original article. In one, a hosting failure left a business without a usable website. In another, the available backups sat inside the same compromised server boundary as the live site.
These historical examples do not identify a current provider. Their practical lesson is to prove recovery and ownership before an outage, migration or supplier handover.
Ask for a recovery demonstration
A backup is useful only if someone can restore it. Know what is backed up, how often, where the copies are stored, and who can recover them. Keep a recovery copy outside the failure boundary of the live server. Test restoration into an isolated environment rather than relying on a reassuring dashboard label.
Record who controls each part
Keep an owner-accessible record of the domain registrar, DNS, hosting, CMS, certificates and support contacts. Record who handles renewal, software updates and incidents. The business should not have to reconstruct that information during an outage or an agency handover.
Use individual accounts and appropriate permissions. When a supplier leaves, review access deliberately. Do not remove a dependency before its replacement works.
Check the public site and staging
A staging copy should not accidentally become a competing public destination. Protect it appropriately and verify that launch settings do not leave production blocked from search. Test speed and availability using the actual site and customer journey, not a hosting plan’s marketing claims.
Shared IP addresses and a protocol version alone do not prove good or bad hosting. Check resource limits, observed performance, support and recovery instead.
See our domain migration guide, website outage checks and SEO service.