The Site Health screen has shipped with WordPress since version 5.2. It grades your site, flags warnings, and lists dozens of technical details. That is useful for a developer. It is often confusing for a client who just wants to write a blog post.<\/p>\n
A yellow “Should be improved” notice can spark a panic email. Worse, the Info tab exposes your PHP version, database size, server software, and full plugin list to anyone who can reach that page. Many site owners would rather that screen was not there at all.<\/p>\n
This guide shows you exactly how to hide or remove Site Health. You will get working code for each method, the file to put it in, and the trade-offs of each choice. Every snippet below works on current WordPress releases in 2026.<\/p>\n
Before you remove anything, you need to know what you are removing. Site Health is not one thing. It is three separate pieces, and each one needs its own fix.<\/p>\n
The first piece is the Site Health Status widget<\/strong>. It sits on your main dashboard at Dashboard \u2192 Home<\/em>. It shows a coloured circle and a short summary of passed and failed tests. Its internal ID is The second piece is the Site Health page<\/strong> itself. You reach it at Tools \u2192 Site Health<\/em>. The file behind it is The third piece is the set of tests<\/strong> that produce the score. WordPress runs some tests instantly and others in the background over AJAX. Plugins can add their own tests to this list too.<\/p>\n You can remove any one of these on its own. Hiding the widget does not hide the page. Hiding the page does not stop the tests from running. Decide which piece is actually causing the problem, then pick the matching method below.<\/p>\n This is the change most people actually want. It clears the coloured warning box off the main dashboard without touching anything else. The Site Health page stays available to you under Tools.<\/p>\n WordPress registers the widget during the The priority of Reload the dashboard once the code is saved. The box should be gone for every user. If it is gone for you but still visible for someone else, they may have dragged it into a different column. Change One warning. Do not try to hide the widget with CSS such as Sometimes the widget is fine but the menu item is the problem. A client clicks Tools, sees Site Health, opens it, and then asks why their site “has errors”. Taking the link out of the menu solves that.<\/p>\n The Site Health page is registered as a submenu of Tools. You remove the link with Use a high priority such as 999 here. Plugins add and reorder menu items on this same hook. Running last means your removal is not undone by something else.<\/p>\n Be clear about what this does. It only hides the link. The page still exists. Anyone who types If you need the page genuinely blocked, use Method 3 instead. Hiding a menu item is a cosmetic change, not a security control. The same logic applies to any admin menu you trim, which is why it helps to understand how to limit dashboard access in WordPress<\/a> properly.<\/p>\n This is the strongest and cleanest option. WordPress gates the whole Site Health feature behind a single meta capability called Filter The You can flip this rule around just as easily. To hide Site Health from every user including yourself, delete the role check and always append Because this method works through the capability system, it behaves predictably with editors, authors, and any custom roles you have created. If you are unsure which role a user holds, our guide to WordPress user roles and permissions<\/a> walks through each level.<\/p>\n Removing the whole screen is a blunt fix. Often only one or two warnings are the real annoyance, and the rest of the report is worth keeping. In that case, remove just the tests you do not need.<\/p>\n WordPress passes the full test list through the To find the right key, open the Status tab and expand the warning. The test slug usually matches the wording of the heading. Common keys include Choose carefully here. A warning about an outdated PHP version is worth acting on rather than hiding, since it affects both speed and security. Check where you stand first with our short guide on how to check your WordPress PHP version<\/a>.<\/p>\n Site Health also caches its result for a short period. After you remove a test, the score may not update straight away. Reload the Status tab once or twice and the stale entry will clear.<\/p>\n Your snippet has to live somewhere that a theme or core update will not overwrite. There are three sensible homes, and one of them is a mistake many people make.<\/p>\n The mistake is editing the The better option is a must-use plugin. Create a folder called A normal plugin also works well if you want an on and off switch. Create Whichever route you pick, edit the file over SFTP or through your host’s file manager. Avoid the built-in theme and plugin editors. A typo there can lock you out of the admin area entirely.<\/p>\n Hiding a warning does not fix the problem behind it. That is worth saying plainly before you paste any of this code. Site Health exists because those checks catch real issues, and some of them matter a great deal.<\/p>\n There is a strong case for hiding it on client sites. A non-technical owner cannot act on a loopback request failure. All the warning does is create worry and a support ticket. Removing it from their view while you monitor it yourself is a reasonable and common practice.<\/p>\n There is a weaker case for hiding it on your own site. If the score is orange, something on the site genuinely needs attention. A missing scheduled event can stop backups, and a failed REST route can break your editor. Those are worth an hour of your time.<\/p>\n A middle path often works best. Use Method 3 to restrict the screen to administrators, and keep checking it yourself on a set schedule. Pair it with a broader performance review, since several Site Health flags overlap with the causes covered in our guide to fixing a slow WordPress admin dashboard<\/a>.<\/p>\n Every method here is fully reversible. Delete the snippet, save the file, and reload the admin area. The widget, the menu item, and the tests all come straight back. Nothing is written to the database, so there is nothing to clean up afterwards.<\/p>\ndashboard_site_health<\/code>.<\/p>\nsite-health.php<\/code>. It has two tabs: Status and Info. The Info tab is the one that lists your server details.<\/p>\nMethod 1: Remove the Site Health Widget From the Dashboard<\/h2>\n
wp_dashboard_setup<\/code> action. You remove it with remove_meta_box()<\/code>. Add this snippet to your theme’s functions.php<\/code> file or to a small plugin:<\/p>\nadd_action( 'wp_dashboard_setup', 'wps_remove_site_health_widget', 20 );\r\nfunction wps_remove_site_health_widget() {\r\n remove_meta_box( 'dashboard_site_health', 'dashboard', 'normal' );\r\n}<\/code><\/pre>\n20<\/code> matters. WordPress adds the widget at the default priority of 10. Your code has to run after that, or there is nothing there to remove yet. If the widget still shows up, raise the number to 99 and try again.<\/p>\n'normal'<\/code> to 'side'<\/code> and add a second remove_meta_box()<\/code> call to cover both.<\/p>\n#dashboard_site_health { display: none; }<\/code>. The widget still loads, the tests still run, and anyone can reveal it with browser tools. Removing it in PHP is faster and actually works.<\/p>\nMethod 2: Remove the Tools \u2192 Site Health Menu Item<\/h2>\n
remove_submenu_page()<\/code> on the admin_menu<\/code> hook:<\/p>\nadd_action( 'admin_menu', 'wps_remove_site_health_page', 999 );\r\nfunction wps_remove_site_health_page() {\r\n remove_submenu_page( 'tools.php', 'site-health.php' );\r\n}<\/code><\/pre>\n\/wp-admin\/site-health.php<\/code> into the address bar will still load it. That is fine if you are only tidying the menu for convenience.<\/p>\nMethod 3: Block Site Health by Capability for Non-Admins<\/h2>\n
view_site_health_checks<\/code>. Take that capability away and the widget, the menu item, and direct URL access all disappear together.<\/p>\nmap_meta_cap<\/code> and deny the capability to anyone who is not an administrator:<\/p>\nadd_filter( 'map_meta_cap', 'wps_restrict_site_health', 10, 4 );\r\nfunction wps_restrict_site_health( $caps, $cap, $user_id, $args ) {\r\n if ( 'view_site_health_checks' === $cap ) {\r\n $user = get_userdata( $user_id );\r\n if ( ! $user || ! in_array( 'administrator', (array) $user->roles, true ) ) {\r\n $caps[] = 'do_not_allow';\r\n }\r\n }\r\n return $caps;\r\n}<\/code><\/pre>\ndo_not_allow<\/code> value is a real WordPress convention. No role holds it, so adding it to the required list makes the check fail. A blocked user who visits the URL directly gets a permission error instead of the page.<\/p>\ndo_not_allow<\/code>. To allow one specific person, compare $user_id<\/code> against their ID before denying.<\/p>\nMethod 4: Silence Individual Tests Instead of Hiding Everything<\/h2>\n
site_status_tests<\/code> filter. The list is an array with two keys: direct<\/code> for instant tests and async<\/code> for background ones. Unset the entries you want gone:<\/p>\nadd_filter( 'site_status_tests', 'wps_trim_site_health_tests' );\r\nfunction wps_trim_site_health_tests( $tests ) {\r\n unset( $tests['direct']['plugin_theme_auto_updates'] );\r\n unset( $tests['async']['background_updates'] );\r\n return $tests;\r\n}<\/code><\/pre>\nphp_version<\/code>, https_status<\/code>, scheduled_events<\/code>, and rest_availability<\/code>.<\/p>\nWhere to Put the Code So It Survives Updates<\/h2>\n
functions.php<\/code> file of a parent theme. The next theme update wipes it. If you want to use a theme file, use a child theme instead, which keeps your code separate and safe. Our explainer on what a WordPress child theme is<\/a> covers the setup in a few minutes.<\/p>\nmu-plugins<\/code> inside wp-content<\/code> if it does not already exist. Add a file named site-health-tweaks.php<\/code>, open it with <?php<\/code>, and paste your snippet below. WordPress loads every file in that folder automatically. There is nothing to activate and nobody can deactivate it by accident.<\/p>\nwp-content\/plugins\/site-health-tweaks\/site-health-tweaks.php<\/code>, add a plugin header comment with a name, then activate it from the Plugins screen. Turning the feature back on later is then a single click.<\/p>\nShould You Hide Site Health at All?<\/h2>\n
Restoring Site Health and Fixing Common Problems<\/h2>\n