A website does not open
Resolve the domain publicly and compare its A and AAAA answers with the hosting destination. If DNS is correct, test HTTPS and HTTP separately. A certificate warning is a TLS coverage problem; a connection timeout points to reachability; a hosting error page usually means the hostname mapping or document root; an application error means the request reached the site and failed later.
A site is slow
Test from another network and an uncached browser, then compare three requests: a small static file, a minimal PHP script and a normal application page. If only the application is slow, inspect database queries, plugins, remote API calls and application caching. If PHP and static files are also slow, compare traffic, response time and resource-limit events and check for current maintenance or a recent deployment.
A database-backed page fails
Confirm the database hostname resolves from the hosting service and verify database name, username and password together. Distinguish unknown host, access denied, too many connections and read-only errors because each has a different remedy. Check storage usage and active connection behaviour before resetting a password that other application instances still use.
A deployment or installation fails
Read the first concrete error, not only the final failed state. A non-empty destination requires choosing another root or deliberately removing the old files. An unknown database host indicates an invalid or not-yet-ready database dependency. Preserve partial files and the database until the cause is understood; repeated submissions can create competing background work.
Visitors see old content
First bypass the browser cache and confirm the file in the document root is the expected version. Then clear the application cache. If a CDN or hosting cache is active, purge the narrowest affected path. A cache purge never uploads new source files, so do not use it to hide an incomplete deployment.
Website email fails
Test mailbox SMTP separately from PHP or application mail. Review the envelope sender, authenticated account, recipient, bounce text and domain authentication. A blocked script-mail path, invalid SMTP password, full mailbox and rejected SPF or DKIM signature are different failures and should not be retried as one undiagnosed problem.
Recover from suspected compromise
Take the affected site offline or restrict access, preserve logs and a copy for investigation, rotate application and file credentials, and identify the vulnerable component before restoring. Restoring an old snapshot without removing the vulnerability only recreates a temporarily clean but still exploitable site. Update the application and extensions before returning it to service.
Evidence for a support request
Provide the affected hostname, exact URL or operation, timestamp with timezone, steps to reproduce, HTTP or application error text and the last known working time. State whether a static file, minimal PHP page and database-backed page succeed. Never include mailbox, database, SFTP or application passwords.
