How to Hide Jetpack From Non-Admin Users

Updated November 2026 by Marius: rewritten for current Jetpack and tested with Jetpack 16.3.1 on WordPress 7.1. Originally published by Hardeep Asrani in 2014.

Whether non-admin users see the Jetpack menu mainly depends on whether your site is connected to WordPress.com. I installed Jetpack 16.3.1 on a test WordPress 7.1 site, created one user for each role, and opened the dashboard and every Jetpack screen as each of them. A site on my own computer can’t connect to WordPress.com, so for the connected case I told Jetpack it was connected through its jetpack_is_connection_ready filter. That is the check that gives non-admins the main Jetpack menu. It doesn’t simulate anyone linking a WordPress.com account, so I couldn’t test the screens that only appear after a user does that (Post by Email, Social).

• Site not connected (or in Jetpack’s offline mode): only administrators see the Jetpack menu. Every other role gets a “Sorry, you are not allowed to access this page” error, even on a direct link. You don’t need any code.
• Site connected: editors, authors and contributors get a Jetpack menu with My Jetpack under it, and they can open Jetpack’s Settings page by URL. Jetpack hands its admin pages to anyone who can write posts (the edit_posts capability). With Jetpack Forms active, editors also get Forms, where form responses are read. Subscribers still see nothing.

So on a connected site, everyone who writes for you gets a Jetpack menu. Most of it is for administrators. The parts meant for writers are linking their own WordPress.com account, their Post by Email address, Jetpack Social connections and, for editors, form responses. If nobody on your site uses those, the snippet below removes the menu for everyone except administrators.

Hide Jetpack from everyone except administrators

// Hide the Jetpack menu from everyone who can't manage the site.
// Jetpack adds its menu at priority 998 and its submenus at 1000, so run after that.
add_action( 'admin_menu', 'tp_hide_jetpack_menu', 2001 );
function tp_hide_jetpack_menu() {
	if ( ! current_user_can( 'manage_options' ) ) {
		remove_menu_page( 'jetpack' );
	}
}

// Refuse the Jetpack screens too, so a bookmarked or typed URL doesn't open them.
add_action( 'admin_init', 'tp_block_jetpack_screens' );
function tp_block_jetpack_screens() {
	if ( current_user_can( 'manage_options' ) || empty( $_GET['page'] ) ) {
		return;
	}
	$page = sanitize_key( wp_unslash( $_GET['page'] ) );
	if ( str_contains( $page, 'jetpack' ) ) {
		wp_die( esc_html__( 'Sorry, you are not allowed to access this page.' ), 403 );
	}
}Code language: PHP (php)

The first function removes the Jetpack menu, along with My Jetpack and Settings under it. It runs at priority 2001 because Jetpack adds its menu at 998, fills it at 1000 and removes a duplicate entry at 2000. At the default priority of 10 the menu doesn’t exist yet, so nothing is removed: in my test, editors kept the Jetpack menu, and only the second function stopped its pages from opening.

The second function closes the direct links. Hiding a menu item doesn’t stop anyone from typing the address, so it refuses every admin screen whose page parameter contains “jetpack” (admin.php?page=jetpack, jetpack-settings, my-jetpack and the rest) with a 403 for anyone who can’t manage options. This only hides screens. It doesn’t change what Jetpack’s own permission checks allow, so don’t rely on it as a security measure.

With both in place, an editor, author or contributor on a connected site got no Jetpack menu and a 403 on every Jetpack screen I tried (jetpack, jetpack-settings, my-jetpack, jetpack_modules and Forms). The editor could still open the post list, the block editor and their profile page. The administrator’s Jetpack menu and screens worked as before.

“Except administrators” here means users with the manage_options capability. To let editors keep Jetpack, for example because they read form responses, check edit_others_posts in both places instead. I tested that variant too: editors kept the menu and its pages, while authors and contributors lost them.

What the snippet doesn’t change

• It doesn’t turn off any Jetpack module, but it does take away the per-user screens. Non-admins can no longer link their WordPress.com account, see their Post by Email address or manage Jetpack Social connections, and editors lose Forms. If your writers use any of those, use the edit_others_posts variant or skip the snippet.
• It leaves Jetpack Stats alone: Stats is its own menu, with its own setting for which roles can view it. (If you switched back to the old Stats screen, its link sits under Jetpack and disappears with the menu, but admin.php?page=stats still works.)
• On a site that isn’t connected, it changes nothing that a non-admin can see, because Jetpack already hides itself from them.

In Code Snippets, you can set this snippet to Only run in administration area, since both hooks only run in wp-admin.

Why the 2014 snippet isn’t enough

This is the snippet this post used to recommend:

function hide_jetpack() {
    if (!current_user_can('manage_options')) {
        remove_menu_page( 'jetpack' );
    }
}
add_action('jetpack_admin_menu', 'hide_jetpack');Code language: PHP (php)

It still hides the menu on Jetpack 16.3, because Jetpack still fires its jetpack_admin_menu action. But as the original note said, the pages stay open by direct link. In my test, editors, authors and contributors could still open admin.php?page=jetpack, jetpack-settings and my-jetpack with it active. The new version closes those links, and it doesn’t rely on a Jetpack-specific hook.

Where to add this code

Add the snippet with a code snippets plugin instead of your theme’s functions.php, so it survives theme updates and you can switch it off without FTP. This guide shows how with the free Code Snippets plugin. On my own sites I use WPCodeBox, which keeps snippets in a cloud library so the same snippet can go on several sites. (Marius)

Disclosure: the WPCodeBox link is an affiliate link. If you buy through it, I earn a commission at no extra cost to you.