To pursue a “100” result, open Tools > Site Health in your WordPress dashboard, clear every applicable critical issue and recommendation, then run the checks again. WordPress does not document a universal numerical formula or guarantee that every site can display 100, so treat the result as a diagnostic: resolve the findings shown on your installation and verify its current status.
What the WordPress Site Health check actually measures
Site Health is a built-in diagnostic, not a complete security, speed, uptime or accessibility certification. The Status tab reports findings as critical issues, recommended improvements and passed tests. The Info tab provides technical details about the installation and environment; it is informational and does not directly change those settings.
The checks can cover WordPress, plugin and theme versions, PHP and its extensions, database support, HTTPS and SSL, REST API availability, scheduled events, loopback requests, search-engine visibility, communication with WordPress.org, full-page caching and persistent object caching. The exact set can vary by WordPress version, hosting environment, configuration, plugins and themes.
What “100” means—and what it does not
Official WordPress documentation describes individual tests and their statuses, but the reviewed documentation does not define a universal score calculation, a fixed number of tests or a guaranteed recipe for a numerical 100. A site may also have plugin- or theme-provided checks that another site does not.
#1 Best Overall
Use this practical definition instead: a healthy result has no applicable critical issues or recommendations left unexplained, and the checks show the expected passed statuses after you make the underlying changes. A clean screen still does not prove that every vulnerability is fixed, pages load quickly for every visitor, backups can be restored, or the site is accessible to all users.
Run the check and preserve the findings
- Open the diagnostic: sign in to WordPress and go to Tools > Site Health.
- Wait for the checks to finish: review the Status tab rather than relying on a partially loaded screen.
- Record the actual results: expand each critical issue and recommendation, including its explanation and suggested action.
- Collect technical details when needed: open Info and use its export feature to copy the environment details for your developer or hosting provider.
Site Health tests can run directly when the page loads or asynchronously through later JavaScript requests. That design reduces the effect of slower checks on the dashboard, so allow asynchronous results time to appear.
Prioritize findings by severity
| Status | Meaning | How to handle it |
|---|---|---|
| Critical issue | A possible security vulnerability or serious performance concern. | Investigate and address it before routine recommendations. |
| Recommended improvement | A noncritical suggestion that can improve security or performance. | Schedule and resolve it when applicable to your site. |
| Passed test | The check found no reported problem under the current conditions. | Continue normal maintenance and periodic checks. |
Do not assume that every displayed recommendation applies equally to every environment. Read the finding’s own explanation and follow the action it names.
Fix the cause at the layer where it exists
WordPress, plugin and theme updates
Use the normal dashboard update screens to install compatible updates for WordPress core, plugins and themes. Findings may identify an outdated PHP version, an old plugin or theme, or a plugin waiting for an update. Back up before consequential software changes, and check compatibility rather than treating every update as risk-free.
PHP version and missing extensions
A PHP-version warning or missing PHP module is controlled by the server environment, not by the Site Health screen. Check the technical details in Info. If your host manages PHP, request the supported version or required extension through its control panel or support channel. A PHP configuration file can be editable only when the hosting environment permits it.
Background updates and WordPress.org communication
Failed background updates or inaccessible WordPress.org services can prevent maintenance tasks from completing. Read the specific error, then check outbound connections, DNS, firewall rules and host restrictions with your provider or administrator. Do not disable security controls simply to make a test pass.
HTTP requests, REST API and loopbacks
Blocked HTTP requests, an unavailable REST API or failed loopback requests can affect updates, scheduled tasks, editor features and integrations. Review firewall, authentication, URL, SSL and server-access settings. A security plugin, web application firewall or host policy may be responsible; test changes carefully on a staging site when possible.
Database and scheduled events
Database-support or scheduled-event warnings require inspection of the database connection, cron configuration and server logs. A host may need to repair database permissions, resource limits or a system scheduler. Site Health can report the symptom, but it cannot grant server access.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Filesystem permissions and file uploads
If uploads are disabled or WordPress cannot write required files, check filesystem ownership and permissions with your administrator or hosting provider. Never make the entire installation broadly writable as a shortcut; permissions should allow required operations without removing protections.
Publicly displayed errors
A finding about publicly displayed PHP or server errors means visitors may be seeing diagnostic information. Turn off public display of errors in production while retaining secure logging for troubleshooting, following your host’s and application’s configuration guidance.
Search-engine visibility, HTTPS and caching
Review search-engine visibility only in the context of the site’s purpose: a private development site may intentionally discourage indexing. For a public site, verify the intended HTTPS and SSL configuration. Caching findings concern the mechanisms detected on your installation; configure page or object caching only when it suits the site and host.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Use the Info tab without expecting it to repair anything
The Info view exposes details such as server software, PHP values, database information, active themes and plugins, filesystem permissions and other configuration data. It helps you identify which layer owns a problem and gives support staff reproducible details. It does not provide controls for changing PHP, database, server or filesystem settings.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Re-run after each meaningful change
- Make one related change at the layer identified by the finding.
- Return to Tools > Site Health > Status and run the checks again.
- Confirm whether the original finding has cleared, changed severity or produced a more specific message.
- Continue with the next critical issue, then address applicable recommendations.
- Keep a record of changes that affect production so you can reverse a problematic update or configuration change.
A result can change when a plugin or theme adds its own tests, when the hosting environment changes or when WordPress updates its core checks. Verify the current screen rather than comparing an assumed fixed test count.
When to involve your hosting provider
Contact the host when the finding involves PHP versions or modules, server-level HTTP restrictions, cron or loopbacks, database access, SSL installation, resource limits, or filesystem permissions that you cannot edit. Include the exported Info report and the exact Status message. Managed WordPress support can apply these changes, but changing hosts does not guarantee a perfect Site Health result.
Quick Recap
Keep Site Health useful after the screen is clear
- Run the check after major WordPress, PHP, plugin or hosting changes.
- Schedule periodic reviews instead of waiting for a visible failure.
- Maintain tested backups separately from the Site Health workflow.
- Use independent security monitoring, performance testing and accessibility checks for areas Site Health does not certify.
- Review new critical findings promptly, even if the previous run was clean.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
