Hosting Guide

Why Support Doesn't Fix Everything

Even strong hosting support has a scope boundary. Problems that originate outside that boundary — in the application, the credentials, or the domain — are the user's to resolve regardless of support quality.

Overview

A site is compromised. The user contacts hosting support. The support team confirms the server is clean — no malware at the infrastructure level, no suspicious processes, no unusual network activity. The problem is in the WordPress application: an outdated plugin, a weak admin password, a theme with injected code. This is outside the hosting support scope. The team provided accurate information; they can't fix an application-layer problem at the hosting layer.

How to think about it

Hosting support is responsible for what the host controls. This includes the server infrastructure, the managed services the host provides, the network layer, and the hosting account configuration. It excludes the user's application code, plugin selection and configuration, theme code, DNS configuration (unless DNS is hosted with the same provider), and anything the user installed or configured.

Even managed WordPress platforms — which take responsibility for a broader scope — have a boundary. A managed WordPress platform that handles automatic updates is responsible for update failures at the platform layer. It is not responsible for custom code the user installed that breaks after an update, or a plugin conflict the user introduced by installing an incompatible plugin.

The practical consequence: resolving a hosting incident requires identifying where the problem originates. Problems above the support scope boundary require user action. Problems below it require host action. Misidentifying the boundary wastes time.

How it works

Application code: custom WordPress themes, plugins, and code the user installed or wrote. If a custom theme has a bug, hosting support can't fix it. They can confirm the server is working; they can't debug PHP code they didn't write.

Credential security: if an admin password is compromised through phishing, password reuse, or data breach exposure, hosting support can help reset access — but the security vulnerability is in the credential management, not the hosting. The same credentials on a different host would produce the same outcome.

Third-party service configuration: email deliverability problems caused by SPF/DKIM misconfiguration, SSL issues caused by improperly installed certificates from a third-party CA, CDN configuration errors — these are at the boundary and often partly in scope depending on the host.

Where it breaks

The most frustrating support limitation is when the host and user disagree about where the boundary is. The user believes the host is responsible for the incident; the host believes the user is. This produces a cycle of escalation that doesn't resolve the problem.

Some managed hosts take a broader approach — treating the resolution of user-caused incidents as a service even when strictly outside scope. This reduces the boundary friction but creates a different expectation mismatch when the broader approach has limits. The best resolution is clear expectations about scope before an incident occurs.

In context

Budget shared hosting support: infrastructure and hosting account scope. WordPress application incidents are explicitly the user's responsibility.

Managed WordPress support: extends to WordPress application layer within the platform's managed scope. Custom code, non-platform plugins, and user-installed components may still be outside scope.

Dedicated business hosting support: broader scope approach, willing to diagnose and guide resolution for application-layer incidents even when strictly outside infrastructure responsibility. The scope boundary is softer.