If your website is not loading, make 3 observations before changing settings: the exact failure, whether another device or connection reproduces it, and which pages or customer tasks are affected. Preserve the evidence. A browser error, a missing page and a server failure need different investigations; a rushed repair can remove useful clues.
This guide gives a website owner a safe diagnostic route and a useful escalation record. It is not permission to change production infrastructure. For a business in Zambia, include which connection was used and write the observation time with its timezone. That helps distinguish a problem seen by one visitor from a broader incident without guessing at its reach.
What can an owner establish before changing the website?
Copy the full affected URL, including whether it uses the main domain or a subdomain. Note what appears: a browser warning, an error page, a blank page, a redirect loop or a page that loads without working features. Capture the visible wording and a screenshot. Do not reduce every symptom to “the server is down”; that conclusion may be wrong and can misdirect the response.
Open a known page from the same website as well as the failing one. If the homepage works but a particular service page does not, record that contrast. If the page displays but a form fails, separate the form failure from page availability. A website can return content while a critical business function remains unusable.
If an HTTP status is available, preserve it. Mozilla’s HTTP response reference explains that a missing resource, refused access, gateway failure and unavailable service have different meanings. The status is a clue about the response, not a complete diagnosis. A page displaying an error message may also return an unexpected status, so retain the message as well.
| Observation | What it supports | What it does not establish | Useful next evidence |
|---|---|---|---|
| HTTP 404 | Requested resource was not found | Entire site is offline | Exact path and working comparison page |
| HTTP 403 | Access to the content was refused | Account was necessarily hacked | Public versus signed-in behaviour |
| HTTP 502 | Gateway received an invalid response | Specific plugin caused it | Gateway and application logs |
| HTTP 503 | Server was not ready to handle the request | A permanent outage | Host status and incident context |
| HTTP 504 | Gateway did not receive a timely response | A particular connection is too slow | Upstream response evidence |
| Browser warning without page content | Visit failed before normal page display | WordPress is the faulty component | Exact warning and affected hostname |
The table is an original escalation aid derived from documented status meanings. It does not translate a code into an automatic fix. Avoid instructions that tell you to disable security checks or ignore certificate warnings simply to make a page appear.
Use this diagnostic fork before escalating. Mozilla’s connection troubleshooting starts by comparing another browser; its security-warning guide distinguishes certificate failures from ordinary page responses.
| Failure branch | Reversible owner check | Appropriate handoff |
|---|---|---|
| Browser-local | Try the same URL in another browser; retain original settings | Device support if only one browser fails |
| Name resolution or Server Not Found | Check the typed hostname, a known website and another connection | Network support or domain/DNS operator with comparison results |
| TLS or certificate warning | Check device date/time and record the exact warning; stop before entering data | Website/hosting operator, or network support if specific to that network |
| HTTP access refusal | Compare a public visit with the expected signed-in route | Website access administrator; do not bypass restrictions |
| Server or gateway response | Compare another page and connection, preserving the status | Hosting/application operator with the incident card |
A different-browser success narrows the investigation without proving the specific local cause. For certificate warnings, ask the responsible operator to correct the problem; do not add a security exception or switch off verification. Leave advanced browser, DNS and live-server changes to the appropriate operator.
Check your own change record next. Was a page moved, a plugin updated, a domain setting edited or a hosting account changed? Record the event and who performed it. A change occurring near the failure is a lead to investigate, not proof of causation. Also note when no recent change is known, because an investigator should not assume a release happened.
Establish which business actions are affected. Can visitors read the contact details? Can an enquiry be submitted? Is the customer-facing booking or purchase route usable? Keep test submissions clearly identifiable and avoid repeating financial actions just to see whether the site responds. Technical availability and the ability to complete a customer task should both appear in the incident record.
What should you send to the person investigating the fault?
Send a compact evidence card: affected URL, first observed time, last known working observation, exact message, comparison results, business impact and recent changes. Identify the person responsible for keeping the record current. Do not send passwords, private configuration files or a complete database through an ordinary enquiry channel.
Here is a copyable structure: “At [time and timezone], [public URL] showed [exact symptom] on [device and connection]. [Comparison URL] showed [result]. A separate visit on [other connection] showed [result or not tested]. The affected customer task is [task]. The last known change was [event or unknown]. Evidence attached: [redacted screenshot or reference].” Replace the brackets with observations, not assumptions.
For WordPress faults, ask the investigator to use staging or an appropriate backup before modifications. The official WordPress debugging guide explicitly gives that preparation advice. Do not start by editing configuration because a search result includes a plausible-looking snippet. A site with live enquiries or orders needs a recovery route before experiments begin.
WordPress supplies debug controls, but the documentation says they are intended for local testing and staging rather than live sites. It describes logging errors and independently controlling whether they appear in page HTML. Those distinctions matter: showing debugging output to visitors is not the same as collecting evidence privately. The owner’s role is to request a safe investigation, not to expose diagnostics publicly.
If logs are collected, retain only what is needed for the investigation and keep access restricted. Ask for the relevant event around the observation time, not an unfiltered dump into a group chat. Paths, account identifiers and personal information can appear in technical records. Redaction should preserve the error meaning while removing material that does not help explain the failure.
Agree the next reversible step and how its outcome will be judged. An investigator might compare a staging copy, inspect a failing request or review a recent change. Record the result before moving to another hypothesis. Changing several components together makes it harder to know which action helped and can introduce another fault before the original one is understood.
After recovery, repeat the customer task that failed. A homepage screenshot is insufficient if enquiries were the problem. Record the public URL, observed result and any remaining limitation. Keep the incident open where a temporary workaround restores access but leaves the cause unexplained; describe that state accurately rather than claiming a permanent repair.
For the surrounding website service, see Spout’s WordPress page. If you need to explain an issue, get started with the redacted evidence card. Clear observations make the first discussion more useful and help establish the scope of any investigation without implying a guaranteed repair or response time.
By Spout Team. AI-assisted drafting by Codex, grounded in the linked primary documentation.