A WordPress Site Health audit is a practical way to review a website before installing or updating a plugin, theme or WordPress itself. It helps you identify configuration problems, collect technical context and document the current state of the site before making a change. This is useful for website owners, freelancers, web designers, agencies and WooCommerce store teams that need a repeatable maintenance process.
Open the screen in the WordPress dashboard through Tools > Site Health. Begin with the warnings that may affect updates or normal operation, then review the technical information behind them. Site Health is a diagnostic and inventory tool, not a complete security audit. It does not prove that a particular plugin is secure, compatible with your website or suitable for your environment, so product-specific checks and controlled testing may still be necessary.
What a WordPress Site Health Audit Covers
The Site Health screen has two main tabs: Status and Info. Status presents findings that need interpretation and action. Info provides a more detailed technical view of the website and includes an option to export the information. Together, these tabs help create a before-and-after record when a new product is installed or an existing one is updated.
Status groups findings into critical issues, recommended improvements and passed tests. Critical issues deserve priority because they may indicate potential security vulnerabilities or serious performance problems. A recommended improvement may not stop a website from working, but it still indicates a condition worth reviewing. Passed tests provide useful confirmation of the areas that did not report a problem at the time of the check.
Status First, Info Second
A practical sequence is simple: review Status first, record unresolved findings, and then use Info to understand the environment. Do not treat every message as equally urgent, but do not dismiss a critical issue merely because the website currently appears to work. Interpret the result in relation to the hosting environment, recent changes, the importance of the website and the product you plan to change.
Review Critical Issues Before Installing or Updating
Before installing or updating a plugin, check whether Site Health reports problems connected with updates, communication or the execution of scheduled tasks. These warnings can point to an environment that is not ready for a change, even when the visible front end still loads.
Look for pending plugin or theme updates and for problems with background updates. A disabled or malfunctioning background-update mechanism is relevant to maintenance planning. Also check whether WordPress can communicate with WordPress.org. This communication is used to fetch updates from the WordPress.org network. If the website cannot reach WordPress.org, it may be unable to check for or install updates to WordPress, themes or plugins.
Connectivity and Background Updates
A failed communication test should not immediately be interpreted as evidence that a particular plugin is defective. Network restrictions, hosting configuration and security controls may also be involved. Record the warning before changing products and investigate its cause. If the problem remains unresolved, consider involving the hosting provider or a qualified administrator rather than proceeding without understanding the risk.
Blocked HTTP requests are another relevant finding. They can indicate that the website cannot make a request expected by WordPress or by a product. The practical impact depends on the request, the server and the change being made, so the warning requires investigation rather than an automatic diagnosis.
Loopback and Blocked HTTP Requests
Site Health also checks loopback requests. WordPress uses them for scheduled events and built-in theme and plugin editors to verify code stability. A failed loopback test therefore deserves attention before an update or installation. It does not prove that every update will fail, but it can identify a condition that should be understood first.
When HTTP or loopback tests fail, compare the result with recent hosting, firewall or configuration changes. Avoid assuming that the product being installed caused the problem. Document the message, identify whether requests are blocked by the network or hosting environment, and escalate server-level changes when you do not have the required access or expertise.
Check PHP, HTTPS and Server Conditions
Site Health includes information about the server, database and media handling, as well as checks related to PHP and HTTPS. These details provide context for decisions about plugins and themes. They are especially useful when a new product has particular environmental requirements that must be compared with the current website configuration.
Review any warning about an outdated PHP version, but do not assume there is one universal target version for every WordPress product or hosting setup. Newer PHP versions are created with performance in mind, yet the correct change must be assessed in relation to the website, hosting environment and products in use.
PHP and Required Modules
Check whether Site Health identifies missing required PHP modules or an invalid PHP timezone setting. These are environmental conditions that may interfere with normal operation or with a product that expects a particular server capability. Relate the result to the specific plugin or theme you are considering instead of treating the Site Health message as a complete compatibility verdict.
Changing PHP or installing modules may require hosting access. If the change is managed outside the WordPress dashboard, ask the hosting provider or a qualified administrator to review it. Do not change server settings blindly, and do not promise a specific performance improvement from a PHP change without evidence for that particular environment.
HTTPS and Hosting Context
Review the HTTPS status shown by Site Health. HTTPS is a relevant website-health item and is recommended for improved website security. Also record the server and database context before a major product change. This baseline can make it easier to describe the environment if an update produces an unexpected result.
HTTPS configuration can involve the hosting environment and site configuration. If correcting it requires server-level work, treat it as an administrative or hosting task. Site Health reports the condition; it does not by itself configure HTTPS or confirm that every aspect of the website’s security has been reviewed.
Inspect Plugins, Themes and Auto-Update Settings
The Info tab can show the active theme, inactive themes, active plugins and inactive plugins. For these products, the information may include names, versions, authors and auto-update settings. It can also show server, database, media-handling and filesystem-permission information.
Use this view to create an inventory before installing, replacing or updating a product. An inventory helps you understand what is already present and gives you a reference point for later comparison. It can reveal whether a planned change affects an active component or a product that is currently inactive.
Build a Baseline Before Adding a Plugin
Before adding a plugin, save the current list of products and versions, note which are active, and record the auto-update settings. After the change, this baseline can help you identify what changed if the website behaves differently. It does not confirm the security, quality or compatibility of the new plugin. Those questions require the product’s own documentation, review of its requirements and appropriate testing.
Do not remove an inactive plugin or theme automatically. First confirm that it is not needed for the website, a maintenance process or a planned configuration. Site Health supplies inventory information, while the decision about removal belongs to the administrator responsible for the site.
Verify Filesystem Permissions and Update Readiness
WordPress must be able to write to important locations, including wp-content, uploads, plugins and themes. Site Health can identify filesystem locations that are not writable. This matters before updates because one-click updates may fail when filesystem permissions prevent WordPress from writing the required files.
Record any write or permission warning before starting an update. A permission problem is an environmental obstacle, not proof that the plugin or theme is defective. It may result from hosting configuration or the way files are managed on the server.
Why One-Click Updates Can Fail
If an update fails because WordPress cannot write to the relevant directories, avoid making random permission changes. Incorrect changes may create additional administration or security concerns. Ask the hosting provider or a qualified administrator to review the filesystem configuration when the required access is not available to you.
Update readiness therefore includes more than seeing an available product update. It also includes checking that WordPress can communicate with required services and write to the locations used during the update. Resolve or document important warnings before proceeding.
Create and Check a Backup Before Updates
WordPress documentation recommends making a backup before updating so that the website can be restored if the update causes problems. This applies to a plugin, theme or WordPress update. A backup is not a prediction that something will fail; it is preparation for recovery if the result is different from what you expected.
A typical complete backup requires both the WordPress files and the database. A database export alone does not represent the complete website, and a copy of the WordPress directory alone does not include the separate database component. Before updating, confirm that both parts are available and that restoration is feasible.
A Usable Backup Has Two Main Components
Think of the backup as two connected but distinct elements: site files and database content. Check where the backup is stored, whether it can be accessed and whether the restoration process is understood. An unverified copy should not be treated as proof that recovery will be possible.
The reviewed documentation does not establish that a particular backup plugin or hosting service is suitable. Choose and verify the method according to the website’s environment, while keeping the essential requirement in view: both files and database must be included for a typical full restoration.
A Practical Pre-Update Checklist
Use the following sequence before installing or updating a plugin, theme or WordPress:
- Open Tools > Site Health and review the Status tab.
- Record critical issues, recommended improvements and passed tests.
- Check background updates, WordPress.org communication, blocked HTTP requests and loopback requests.
- Review PHP status, required modules, the PHP timezone setting and HTTPS.
- Inspect server, database, media-handling and filesystem information.
- Export or record the active and inactive plugins and themes, including versions and auto-update settings.
- Confirm that relevant filesystem locations are writable before using one-click updates.
- Create and verify a restorable backup containing both files and the database.
- Perform the change in a controlled way and check the website afterwards.
Before, During and After the Change
Before the change, document the baseline and investigate important warnings. During the change, avoid combining unrelated modifications, so that a later problem is easier to associate with the correct action. Afterward, check the website and compare it with the previous state. Keep the backup available in case restoration is needed.
Debugging configuration can also appear in the technical context. If debugging or error logging is used during investigation, do not leave potentially public error output enabled on a production website. Error messages may expose sensitive information. Site Health and debugging information should support diagnosis, not become a source of disclosure.
A checklist improves consistency, but it is not a complete security audit, vulnerability review or compatibility test. It also does not guarantee that an update will be trouble-free. Treat each result as evidence about the current configuration and combine it with the requirements of the product and the business impact of the website.
WordPress Site Health helps organize a technical review before a plugin or theme change. Its Status tab highlights critical issues, recommended improvements and passed tests, while Info creates a useful inventory of the site’s environment and installed products. Communication, loopback, HTTP, PHP, HTTPS and filesystem checks can reveal obstacles that deserve attention before an update. The inventory can also provide a clear baseline before adding a new plugin.
Remember that warnings must be interpreted in the context of hosting, recent changes and the product being considered. Site Health does not replace security monitoring, access-control review, malware scanning, compatibility testing or product-specific evaluation. Before updates, keep a restorable backup of both WordPress files and the database. Explore our WordPress plugins, WooCommerce extensions, themes and membership plans to find the right tools for your website.