Site Health provides a structured overview of WordPress configuration and diagnostic checks. Use it to collect evidence about a problem, then interpret each recommendation in the context of the actual service and application.
IN THIS ARTICLE
01 Start with the observed symptom
Record the affected page or task, when it fails and what changed recently. Site Health is useful context, but a recommendation shown there is not automatically the cause of every problem. A healthy status also does not prove that checkout, forms or custom integrations work correctly.
02 Collect the relevant information
- Open Tools > Site Health with an authorised account and wait for the status checks to finish.
- Expand the critical or recommended items related to the symptom, and record their exact wording.
- Open the Info tab and inspect relevant sections such as WordPress, active theme, plugins, server, database and media handling.
- Use the copy-information control only when needed, and review the copied text before sharing it.
- Repeat a relevant check after a targeted correction and compare the result.
03 Share a useful, sanitised report
Include the domain, symptom, reproduction steps and the diagnostic sections that explain the environment. Remove unnecessary filesystem paths, private addresses or other details that do not help the support task. Never append passwords, API keys or authentication cookies.
Plugin versions and the selected PHP version can be useful for compatibility checks. A complete plugin list can also reveal overlapping cache or security components, but it should be shared through the approved support channel rather than posted publicly by default.
Does every Site Health warning require an immediate change?
A failed loopback test can affect scheduled events; a REST test can relate to editor saves; a writable configuration or public debug setting can expose information. Investigate the specific check and its supporting error before disabling protections or changing several settings together.
Some recommendations depend on plan capabilities and workload. For example, a persistent object cache is not something to enable by entering an arbitrary server address. Ask us which supported options apply to the service.
04 Verify the original task
After a fix, rerun the diagnostic and reproduce the customer-facing workflow. A disappearing warning is useful evidence but does not replace a form submission, scheduled-post check or payment test relevant to the actual incident.
If Site Health itself cannot load, record the error and use the hosting logs or an authorised command-line check. Do not install multiple diagnostic plugins on a failing live site without a recovery plan. A concise report connecting the symptom to the relevant environment details is more actionable than an unreviewed dump of every setting.