How to Reorganize the WordPress Admin Menu

Reorganizing the WordPress admin menu can make wp-admin substantially easier to use by placing important screens first, grouping related tools together, removing unnecessary navigation and adapting the menu to the people who actually use the website.

A default WordPress installation starts with a relatively simple sidebar:

Dashboard
Posts
Media
Pages
Comments
Appearance
Plugins
Users
Tools
Settings

Real websites rarely remain that simple.

Plugins can add:

• new top-level menu items;
• new submenus;
• custom post types;
• analytics screens;
• SEO tools;
• forms;
• e-commerce settings;
• security tools;
• marketing integrations;
• backup interfaces;
• developer utilities.

A mature WordPress administration menu can therefore become:

Dashboard
Posts
Media
Pages
Comments
Products
Orders
Marketing
Analytics
Forms
SEO
Security
Backups
Email
Snippets
Custom Fields
Appearance
Plugins
Users
Tools
Settings
Plugin A
Plugin B
Plugin C
...

The problem is not simply that the menu becomes long.

The larger problem is that its structure usually reflects:

WordPress defaults
+
plugin registration order
+
plugin developer decisions

rather than:

the site's actual workflow

This guide explains how WordPress builds the administration menu, how to reorder top-level items, organize submenus, rename labels, hide unnecessary entries, create role-aware navigation, add custom links and avoid the common mistake of treating menu visibility as a replacement for permissions.

Why reorganize the WordPress admin menu?

The WordPress admin menu is navigation.

Its job is to help users answer:

Where do I go
to perform this task?

As the number of available screens increases, finding the right destination takes longer.

A cleaner structure can improve:

• navigation speed;
• client onboarding;
• editorial workflows;
• consistency across teams;
• training;
• administrative clarity;
• support documentation.

For client-oriented wp-admin design, see Reducing WordPress Admin Confusion for Clients.

Admin-menu organization is not only cosmetic

Suppose an editor uses these screens every day:

Posts
Media
Pages
SEO

but the administration menu puts several unrelated plugin tools between them.

The editor repeatedly scans through controls that have nothing to do with their job.

A workflow-oriented version might instead place:

CONTENT

Posts
Pages
Media

OPTIMIZATION

SEO

OPERATIONS

other tools

The available functionality has not changed.

The information architecture has.

Start with the workflow, not the existing menu

Before moving anything, identify what users actually do.

For example, an editorial team may follow:

Create article
↓
upload images
↓
optimize SEO
↓
review
↓
publish

The corresponding menu could prioritize:

Posts
Media
SEO
Editorial tools

rather than keeping every plugin exactly where its developer originally registered it.

Different users may need different menu structures

An administrator may need:

Plugins
Users
Settings
Tools
Security
Backups

An editor may primarily need:

Posts
Media
Pages
SEO

A customer-support user may need:

Orders
Customers
Support
Reports

Trying to make one giant navigation equally suitable for every user usually produces a menu that is ideal for nobody.

For team-wide administration design, see Standardizing the WordPress Admin for Teams.

How WordPress builds the admin menu

WordPress builds the administration menu during the admin request lifecycle.

The primary public hook for menu registration and modification is:

admin_menu

The official admin_menu documentation explains that it fires after the basic administration menu structure is available and is used to add or modify administration menu entries.

Plugins register their own menu pages

A plugin can create a top-level item using:

add_menu_page()

For example:

add_action(
    'admin_menu',
    function () {

        add_menu_page(
            'Reports',
            'Reports',
            'manage_options',
            'project-reports',
            'project_render_reports',
            'dashicons-chart-bar',
            30
        );
    }
);

The official add_menu_page() documentation defines the capability, menu slug, callback, icon and optional position used to create that item.

Plugins can also create submenus

WordPress provides:

add_submenu_page()

for adding a screen below an existing parent.

For example:

add_action(
    'admin_menu',
    function () {

        add_submenu_page(
            'tools.php',
            'Import Reports',
            'Import Reports',
            'manage_options',
            'project-import-reports',
            'project_render_import_reports'
        );
    }
);

The official WordPress Sub-Menus documentation covers this structure.

WordPress stores the generated navigation in menu arrays

During an administration request, WordPress builds global structures including:

$menu
$submenu

Conceptually:

$menu
→ top-level navigation

$submenu
→ child items
   grouped by parent slug

WordPress Core and plugins contribute entries to those structures before the sidebar is rendered.

The default menu uses numeric positions

The official add_menu_page() documentation lists standard positions such as:

2
→ Dashboard

5
→ Posts

10
→ Media

20
→ Pages

25
→ Comments

60
→ Appearance

65
→ Plugins

70
→ Users

75
→ Tools

80
→ Settings

Plugins can request their own menu positions.

Modern WordPress handles position collisions, so developers do not need to invent increasingly strange decimal positions simply to avoid another plugin.

Do not reorganize by editing WordPress Core

Never modify files inside:

wp-admin/

to rearrange menu items.

Core modifications:

• disappear during updates;
• complicate maintenance;
• make debugging harder;
• can create security-update problems;
• hide the source of the customization.

WordPress already exposes the menu lifecycle through hooks and filters.

Method 1: reorder menu items with menu_order

WordPress provides two filters specifically for custom menu ordering:

custom_menu_order
menu_order

The first enables custom ordering.

The second supplies the new order.

The official custom_menu_order documentation explains that it must return a truthy value before the menu_order filter is used.

Basic reorder example

add_filter(
    'custom_menu_order',
    '__return_true'
);

add_filter(
    'menu_order',
    function ( $menu_order ) {

        return array(
            'index.php',
            'edit.php',
            'edit.php?post_type=page',
            'upload.php',
            'edit-comments.php',
        );
    }
);

This prioritizes:

Dashboard
Posts
Pages
Media
Comments

What happens to items you do not include?

The official menu_order documentation explains that menu items omitted from the supplied ordering array are placed after the explicitly mentioned items while retaining their relative order.

This means you can prioritize important items without manually listing every menu added by every plugin.

A safer partial-order strategy

For example:

add_filter(
    'custom_menu_order',
    '__return_true'
);

add_filter(
    'menu_order',
    function ( $menu_order ) {

        return array(
            'index.php',
            'edit.php',
            'upload.php',
            'edit.php?post_type=page',
        );
    }
);

WordPress can then place other registered menu items after those entries.

This is often easier to maintain than hardcoding a complete list that becomes obsolete whenever another plugin is installed.

Identify the correct menu slug

Built-in menu slugs commonly include:

Dashboard
→ index.php

Posts
→ edit.php

Media
→ upload.php

Pages
→ edit.php?post_type=page

Comments
→ edit-comments.php

Appearance
→ themes.php

Plugins
→ plugins.php

Users
→ users.php

Tools
→ tools.php

Settings
→ options-general.php

Custom post types commonly use:

edit.php?post_type=book

where:

book

is the registered post-type slug.

Plugin menu slugs are not always obvious

A plugin may register:

seo-dashboard

while another uses:

admin.php?page=plugin-name

or a file-based slug.

Do not guess the slug from the visible label.

Labels and slugs are different things

This menu:

Visible label:
Analytics

Slug:
project-analytics

can later be renamed:

Reports

without changing the underlying slug.

Stable menu organization should identify entries by their actual internal identifiers rather than only their visible text.

Method 2: remove unnecessary top-level menu items

WordPress provides:

remove_menu_page()

for removing a top-level entry from the generated navigation.

For example:

add_action(
    'admin_menu',
    function () {

        remove_menu_page(
            'edit-comments.php'
        );

        remove_menu_page(
            'tools.php'
        );
    },
    999
);

The official remove_menu_page() documentation recommends calling it from the admin_menu hook.

Why use a later priority?

Another plugin may register its menu item later than your callback.

Consider:

Your callback
priority 10
↓
tries to remove plugin menu

Plugin callback
priority 50
↓
adds menu afterward

The item appears because it did not exist when your removal code ran.

A later priority such as:

99
999

can be appropriate when you need to modify entries after plugins have registered them.

Do not use an arbitrary late priority for everything

Priority should solve an actual registration-order problem.

If the target entry already exists at the normal priority, there is no benefit in making every menu callback run at an absurdly large number merely because another tutorial did.

Method 3: remove a submenu

WordPress provides:

remove_submenu_page()

For example:

add_action(
    'admin_menu',
    function () {

        remove_submenu_page(
            'tools.php',
            'import.php'
        );
    },
    999
);

The official remove_submenu_page() documentation requires:

parent menu slug
+
submenu slug

Removing a menu item does not automatically secure the page

This is a critical WordPress distinction.

The official documentation for remove_submenu_page() explicitly warns that removing an item from the navigation may not prevent direct access to the underlying administration screen.

The same general principle applies to menu hiding:

Menu visibility
≠
authorization

Navigation and permissions are separate systems

Suppose you remove:

Tools

from the sidebar.

A user might still know or receive a direct URL to a screen beneath Tools.

If that page’s capability permits access, hiding the navigation item alone should not be treated as the security boundary.

Use capabilities for authorization

WordPress exposes:

current_user_can()

for capability checks.

The official current_user_can() documentation recommends checking capabilities rather than relying on role names for authorization logic.

For example:

if (
    ! current_user_can(
        'manage_options'
    )
) {
    wp_die(
        esc_html__(
            'You are not allowed to access this page.',
            'project'
        )
    );
}

Menu hiding should improve UX

Capabilities should determine whether an operation is permitted.

The administration menu should help users discover the operations relevant to them.

The useful model is:

Capability
→ Can this user perform the action?

Menu visibility
→ Should this navigation entry
be shown to this user?

For the complete role-based visibility topic, see How to Hide WordPress Admin Menu Items by Role.

Page visibility and permission are not synonyms

A more detailed discussion is available in Controlling WordPress Admin Page Visibility by Role.

This distinction becomes especially important on client websites where the objective is often:

simplify navigation

rather than:

invent a new authorization model

Reorganize by task frequency

Frequently used destinations normally deserve easier access.

For example:

Editor workflow

Posts
Media
Pages
SEO
Comments

may be more useful than:

Dashboard
Plugin Settings
Analytics
Marketing
Posts
Security
Media
Tools
Pages
...

Do not simply alphabetize everything

Alphabetical organization appears tidy, but it ignores task frequency and relationships.

For example:

Media
Pages
Posts

may be alphabetically convenient.

But:

Posts
Media
SEO

may better match an editorial workflow.

Group related functions

A useful administration architecture can group tools conceptually.

For example:

CONTENT

Posts
Pages
Media
Comments


COMMERCE

Orders
Products
Customers


MARKETING

SEO
Analytics
Forms


SYSTEM

Users
Plugins
Tools
Settings
Backups

The specific groups should reflect the site rather than this exact example.

Separators can improve scanning

WordPress itself uses separators in the default administration menu.

Custom interfaces can extend that idea with additional visual groups.

A separator is useful when it communicates:

new functional section begins here

rather than merely adding decoration.

Too many separators create another form of clutter

This structure:

CONTENT
Posts

MEDIA
Media

PAGES
Pages

COMMENTS
Comments

adds more labels than useful organization.

Use groups only when several related items actually form a meaningful category.

Rename unclear plugin labels

Plugin developers sometimes use menu titles that make sense inside the plugin’s own product vocabulary but are unclear to clients.

For example:

Original:
XYZ Suite

Client-facing:
Marketing Reports

or:

Original:
Entries

Client-facing:
Form Submissions

Renaming should clarify, not disguise

A renamed label should still describe the destination accurately.

A user who clicks:

Reports

should not unexpectedly land inside an unrelated security settings page.

WordPress has no dedicated universal rename_menu_page() API

Developers can modify the generated menu structures during admin_menu, but that requires understanding:

$menu
$submenu

and identifying the correct entry.

Because those arrays are runtime structures rather than a purpose-built high-level renaming API, direct manipulation should be implemented carefully.

Example of a simple label change

add_action(
    'admin_menu',
    function () {

        global $menu;

        foreach (
            $menu as $index => $item
        ) {
            if (
                isset( $item[2] )
                &&
                'edit.php'
                === $item[2]
            ) {
                $menu[ $index ][0]
                    = 'Articles';

                break;
            }
        }
    },
    999
);

This changes the visible label for Posts to:

Articles

without changing the underlying destination:

edit.php

Do not identify menu items only by their numeric array index

This would be fragile:

$menu[5][0] = 'Articles';

because another plugin or WordPress configuration may alter the final structure.

Identify the entry using its stable slug where possible.

Renaming Posts does not rename every related interface

Changing the menu label:

Posts
→ Articles

does not automatically rename:

• the post-type object;
• editor headings;
• REST API routes;
• database values;
• URLs;
• capabilities.

Menu labeling is only one interface layer.

Move a submenu item to the top level

There are cases where an important submenu deserves direct access.

For example:

WooCommerce
    Orders

↓ reorganize

Orders
WooCommerce

The goal is to reduce one navigation step for a frequently used destination.

Moving menu hierarchy is more complex than simple reordering

A submenu contains information such as:

• menu title;
• required capability;
• page slug;
• parent relationship;
• screen callback registration.

Moving it carelessly can break:

• current-menu highlighting;
• permissions;
• plugin assumptions;
• submenu state;
• screen loading.

Prefer preserving the original target

If you expose an existing plugin screen somewhere else in the menu, preserve:

same destination
+
same capability requirements

instead of recreating an unrelated duplicate screen.

Move top-level tools into submenus when appropriate

The opposite can also improve organization.

Suppose several plugins create:

SEO Audit
Redirects
Schema
Keyword Reports

as separate top-level entries.

A custom administration architecture might conceptually group them under:

SEO
    Audit
    Redirects
    Schema
    Keyword Reports

Whether this is safe depends on how those plugins register and reference their pages.

Test plugin pages after changing hierarchy

After moving an existing screen, test:

• page access;
• active-menu highlighting;
• submenu highlighting;
• permissions;
• form submissions;
• AJAX actions;
• return links;
• plugin notices.

Custom menu items can provide useful shortcuts

Sometimes the ideal administration menu needs destinations that WordPress does not create automatically.

Examples include:

• internal documentation;
• support portal;
• analytics dashboard;
• brand guidelines;
• content calendar;
• external CRM;
• company knowledge base.

For the broader implementation topic, see How to Add Custom Admin Menu Items in WordPress.

Add a custom WordPress admin page

For an actual WordPress administration screen, use:

add_menu_page()

or:

add_submenu_page()

rather than manually injecting arbitrary HTML into the sidebar.

Example custom support screen

add_action(
    'admin_menu',
    function () {

        add_menu_page(
            'Team Support',
            'Support',
            'edit_posts',
            'team-support',
            'project_render_support_page',
            'dashicons-sos',
            81
        );
    }
);

function project_render_support_page() {

    if (
        ! current_user_can(
            'edit_posts'
        )
    ) {
        return;
    }

    echo '<div class="wrap">';
    echo '<h1>Team Support</h1>';
    echo '<p>Internal support resources.</p>';
    echo '</div>';
}

The callback must also enforce capability requirements

The official add_menu_page() documentation explicitly states that the page callback should verify the required capability.

Do not rely exclusively on the menu registration argument.

Custom external links require a different approach

A menu item that links to:

https://support.example.com/

is not the same as a WordPress admin page callback.

When implementing external navigation, validate and escape the URL and clearly communicate that the user is leaving wp-admin.

Do not turn wp-admin into a bookmark collection

A few relevant external shortcuts can improve workflows.

Twenty-seven corporate links produce a new navigation problem while technically solving the old one.

Use role-aware visibility

A good administration structure may look different for different groups.

Administrator

Dashboard
Content
Commerce
Marketing
Users
Appearance
Plugins
Tools
Settings
Security
Backups

Editor

Dashboard
Posts
Pages
Media
Comments
SEO

Author

Dashboard
Posts
Media

This reduces visual noise without necessarily altering the underlying capability architecture.

Prefer capabilities when making security decisions

WordPress users may receive:

• custom roles;
• multiple roles through plugins;
• direct capability modifications;
• mapped meta capabilities.

For security-sensitive access decisions, use capabilities rather than assuming:

role name
=
permission state

Role-specific menu visibility is still useful for UX

Role-based organization is reasonable when the objective is simply:

Editors should not see
hosting-oriented tools

or:

Authors should only see
content tools

Just keep that interface rule conceptually separate from authorization.

Admin Menu Organizer and direct-access protection

TheOneWP Admin Menu Organizer goes beyond merely removing a hidden item from the sidebar.

For pages configured as hidden, the current module also evaluates direct administration requests and blocks matching access according to its visibility rules.

This matters because Core functions such as:

remove_menu_page()
remove_submenu_page()

primarily manipulate navigation.

Do not generalize that behavior to normal WordPress removal functions

This distinction is important:

Core remove_menu_page()
→ removes navigation entry

TheOneWP configured hidden page
→ removes navigation entry
+
applies its own direct-access rule

Those are not equivalent implementations.

TheOneWP supports drag-and-drop menu reordering

The current Admin Menu Organizer interface provides visual reordering for both:

• top-level menu items;
• submenu items.

The saved order is then applied after WordPress and active plugins have registered their administration pages.

Internally, reordering integrates with WordPress’s:

custom_menu_order
menu_order

filters rather than modifying WordPress Core.

Submenu order is stored independently by parent

A structure such as:

Posts
    All Posts
    Add New
    Categories
    Tags

can therefore have its own ordering separate from:

Pages
    All Pages
    Add New

This is useful because submenu priorities rarely need to mirror top-level navigation priorities.

TheOneWP can rename existing items

The module stores the original menu label separately from a custom label.

This allows an administrator to change:

Posts
→ Articles

and later restore the original label without reconstructing it manually.

TheOneWP can restructure menu hierarchy

The current implementation supports:

submenu
→ promote to top level

and:

top-level item
→ move beneath another parent

while preserving the original target information used by the menu entry.

TheOneWP can add custom menu entries

Administrators can add custom:

• top-level links;
• submenu links;
• labels;
• URLs;
• Dashicons for supported top-level entries;
• positions.

TheOneWP can create visual separators

Custom separators can divide the sidebar into functional groups.

The current module supports separator configuration including:

• optional labels;
• line visibility;
• line color;
• border color;
• text color;
• background color.

The objective should remain navigational clarity rather than decorative complexity.

Admin Menu Organizer stores configuration separately

The current module stores its menu-organization configuration separately from the plugin’s general settings.

This makes the organizer’s state a dedicated configuration layer rather than changing:

• WordPress Core files;
• plugin files;
• theme files.

Resetting should restore the generated WordPress menu

The module includes a reset workflow that removes its custom:

• ordering;
• visibility rules;
• renamed labels;
• custom items;
• separators.

The resulting menu is again generated from WordPress Core and the active plugins.

Design the menu before touching it

A practical audit starts by recording the current sidebar.

For example:

Dashboard
Posts
Media
Pages
Comments
WooCommerce
Products
Analytics
SEO
Forms
Appearance
Plugins
Users
Tools
Settings
Security
Backups

Then classify each entry.

Classify by functional area

For example:

CONTENT
Posts
Media
Pages
Comments

COMMERCE
WooCommerce
Products

MARKETING
Analytics
SEO
Forms

SYSTEM
Appearance
Plugins
Users
Tools
Settings
Security
Backups

Then classify by user group

Example:

Menu area	Administrator	Editor	Author
Posts	Useful	Useful	Useful
Media	Useful	Useful	Useful
Pages	Useful	Useful	Maybe not
SEO	Useful	Useful	Maybe not
Plugins	Useful	Not needed	Not needed
Settings	Useful	Usually not needed	Not needed

The exact answers depend on the site.

Do not reorganize menus based only on personal preference

If only one administrator uses the site, personal organization may be sufficient.

If twenty people use wp-admin, gather information about:

• common tasks;
• frequent mistakes;
• screens users struggle to find;
• tools that nobody uses;
• permissions by role;
• support requests.

The menu should solve observed workflow problems.

Keep frequently used items near the top

A simple priority model is:

Daily tasks
→ top

Weekly tasks
→ middle

Rare administration tasks
→ lower

Technical configuration
→ administrator-only area

Do not put Settings first merely because it is important

Importance and frequency are not identical.

A system setting can be extremely important while still being opened twice per year.

Daily editorial tasks normally deserve faster access.

Keep dangerous actions away from everyday navigation

Editors normally do not need prominent shortcuts to:

• plugins;
• theme configuration;
• database tools;
• security configuration;
• site-wide settings.

If their capabilities already prevent those operations, hiding the irrelevant navigation makes the interface clearer.

Do not remove useful context from administrators

Cleaning the menu should not mean hiding every technical tool.

An administrator responsible for maintaining the site may genuinely need:

• Plugins;
• Users;
• Tools;
• Settings;
• security controls;
• backup tools;
• system diagnostics.

Optimize each workflow separately.

Reorganization and branding work well together

A custom WordPress backend can combine:

• clear navigation;
• appropriate menu labels;
• custom logo;
• admin color scheme;
• footer information;
• focused Dashboard content;
• support links.

See How to Brand the WordPress Admin Dashboard for the broader administration-branding layer.

Navigation should remain recognizable

Branding should not rename familiar actions into vague marketing language.

For example:

Posts
→ Content

may remain understandable.

But:

Posts
→ Inspiration Engine

forces users to learn an unnecessary internal vocabulary.

Labels should reduce cognitive effort.

Admin menu organization and Dashboard cleanup are different

The left sidebar controls navigation.

The Dashboard controls the content shown after opening:

/wp-admin/

A site can have:

clean Dashboard
+
chaotic menu

or:

organized menu
+
cluttered Dashboard

For the Dashboard layer, see Decluttering the WordPress Admin Dashboard.

Admin menu and Admin Bar are also different

The left-side navigation menu and the top WordPress Toolbar are separate systems.

Admin Menu
→ left navigation inside wp-admin

Admin Bar / Toolbar
→ top horizontal navigation

Removing a sidebar entry does not automatically remove the corresponding Toolbar shortcut.

See How to Remove Items from the WordPress Admin Bar.

Keep responsive behavior in mind

The WordPress admin menu changes significantly at narrower viewport widths.

Desktop navigation can display:

• icons;
• full text labels;
• submenu flyouts;
• expanded sections.

Smaller screens use a more compact and collapsible interface.

See WordPress Admin Menu Responsive Breakpoints, Explained.

Test long custom labels on small screens

A renamed menu item such as:

Customer Relationship Management System

may technically fit into your desktop customization but become awkward at narrower widths.

Prefer concise labels.

Test submenu depth

WordPress administration navigation is fundamentally designed around:

top-level item
→ submenu

Do not attempt to create elaborate four-level navigation trees through CSS and JavaScript unless the benefit clearly justifies departing from normal wp-admin behavior.

Keep icons meaningful

Custom top-level pages can use Dashicons.

The official add_menu_page() API accepts a Dashicons class such as:

dashicons-chart-pie
dashicons-admin-tools
dashicons-media-document

Icons should help users identify the section rather than introducing a second decorative language beside the labels.

Do not use icons as the only information

The menu label remains important for:

• clarity;
• accessibility;
• discoverability;
• collapsed-state understanding.

Custom separators should remain accessible

If a separator includes a label such as:

Marketing

ensure sufficient:

• text contrast;
• background contrast;
• spacing;
• legibility.

Do not create faint decorative labels that users can barely read.

Do not reorganize with CSS order alone

It may be tempting to manipulate sidebar items using:

display: flex;
order: ...;

or JavaScript DOM movement.

This changes the rendered appearance without properly changing WordPress’s server-generated navigation structure.

Potential problems include:

• flash before scripts execute;
• incorrect active-menu state;
• accessibility order differences;
• responsive inconsistencies;
• plugin conflicts.

Prefer WordPress menu APIs and filters

Use server-side menu configuration for structural changes.

CSS should style the resulting navigation rather than act as the primary information architecture.

Do not hide menus with display:none as a security measure

This:

#menu-plugins {
    display: none;
}

only hides the visible element.

It does not change:

• capabilities;
• page registration;
• direct URL access;
• server-side authorization.

Do not remove capability checks because the menu is hidden

A custom page must still enforce its required capability.

This remains true even when:

no ordinary user
can see its menu item

Plugins can recreate menu entries after updates

An update can change:

• menu slug;
• parent menu;
• registration priority;
• screen architecture;
• labels.

Review customized administration navigation after major plugin changes.

A plugin changing its slug is particularly important

If your organizer identifies:

old-plugin-slug

but the updated plugin registers:

new-plugin-slug

your saved rule may no longer match.

Prefer stable identifiers over visible labels

Labels are especially likely to change because of:

• translation;
• branding;
• plugin updates;
• manual renaming.

Use the underlying menu target when matching existing items.

Translated WordPress installations need testing

The menu structure may contain translated visible labels.

If your code searches for:

Posts

rather than:

edit.php

it can fail on a site where the visible label is:

Articoli

or another translation.

Use slugs for identification, labels for presentation

The useful separation is:

slug
→ identify destination

label
→ communicate destination

Multisite has a separate Network Admin menu

WordPress Multisite includes a Network Admin environment with a different menu structure.

The official add_menu_page() documentation lists different default positions for Network Admin.

WordPress also provides:

network_admin_menu

for Network Admin navigation.

Do not assume admin_menu controls Network Admin

A menu customization designed for an individual site may not apply to:

Network Admin

and often should not.

Test:

• Site Admin;
• Network Admin;
• Super Admin behavior;

separately.

User Admin is another context

WordPress also exposes:

user_admin_menu

for the User Admin environment.

Do not assume every administration context uses the same menu hooks or menu structure.

Where should custom admin-menu code live?

Suitable locations include:

• a site-specific plugin;
• a must-use plugin;
• a maintained snippets system;
• a dedicated administration plugin.

A theme is often not the ideal place

If switching the frontend theme should not restore the old wp-admin navigation, then administration-menu architecture is probably site functionality rather than theme presentation.

A site-specific plugin or equivalent configuration is usually easier to reason about.

Do not put critical menu logic into a parent theme

A theme update can overwrite modifications.

If theme-based code is truly appropriate, use a maintained child theme.

Use version control for custom implementations

Admin-menu customizations affect daily site operation.

Store custom code in version control so changes can be:

• reviewed;
• tracked;
• reverted;
• deployed consistently.

Test on staging first

A menu change is less dramatic than deleting a database, but it can still leave users unable to locate important workflows.

Test on a representative staging environment.

See WordPress Staging Site Best Practices.

Create representative test users

Do not test only with Administrator.

Create users representing:

Administrator
Editor
Author
Customer-support role
Custom role

where those roles exist.

Test every important menu destination

After reorganizing, click:

• every moved top-level item;
• every moved submenu;
• renamed entries;
• custom links;
• role-specific items;
• plugin settings pages.

Test direct URLs too

For hidden items, manually visit the original page URL.

This reveals whether the implementation is:

navigation-only

or:

navigation
+
direct-access enforcement

Do not assume one behavior from the other.

Test form submissions

A plugin screen may load correctly after being moved while a form posts back to a URL that assumes the old parent structure.

Test:

• save buttons;
• AJAX operations;
• bulk actions;
• import/export;
• redirects after saving.

Test active-menu highlighting

When visiting a moved screen, check whether the correct parent appears active.

A broken active state can make users think they opened the wrong part of the administration panel.

Test collapsed admin menu

WordPress allows users to collapse the sidebar.

Check:

• custom icons;
• submenu flyouts;
• separator behavior;
• active states.

Test responsive wp-admin

Verify common widths including:

desktop
tablet
mobile

especially when the customization adds:

• long labels;
• custom separators;
• custom styling;
• new icons.

Test after plugin activation

A newly installed plugin may register:

new top-level menu
+
several submenus

Review whether it belongs in the existing structure.

Do not automatically hide every new plugin menu

First determine:

• who needs it;
• how often;
• whether it has important notices;
• whether it contains operational tools.

Test after plugin deactivation

An organizer should handle the disappearance of previously configured items gracefully.

A stored rule referring to a removed plugin should not break the entire admin menu.

Graceful handling matters for dynamic menus

WordPress menus are generated from the current environment.

That environment changes when:

• plugins activate;
• plugins deactivate;
• roles change;
• post types change;
• Multisite state changes.

Menu configuration should tolerate missing items.

Client-site organization example

A small business website might use:

Dashboard

CONTENT
Pages
Posts
Media

LEADS
Forms
Form Submissions

MARKETING
SEO
Analytics

SYSTEM
Users
Appearance
Plugins
Tools
Settings

Editors could see only:

Dashboard

CONTENT
Pages
Posts
Media

LEADS
Forms

MARKETING
SEO

WooCommerce organization example

An e-commerce team could prioritize:

Orders
Products
Customers
Coupons
Reports

while moving technical settings lower in the navigation.

The daily operational workflow comes before infrequently used configuration.

Agency organization example

An agency-managed client site might contain:

Dashboard

CONTENT
Pages
Posts
Media

MARKETING
SEO
Forms

SUPPORT
Documentation
Request Support

SYSTEM
hidden from client roles

This can substantially reduce client support questions without modifying the actual content-management capabilities they need.

Editorial organization example

A publishing site may prioritize:

Posts
Media
Comments
Categories
Editorial Calendar
SEO

while administrators retain:

Plugins
Users
Settings
Security
Backups

lower in the sidebar.

Do not customize each individual employee separately

Per-user menu architecture becomes difficult to maintain quickly.

Prefer stable groups such as:

Administrators
Editors
Authors
Support
Marketing

when workflows genuinely differ.

Document the intended menu structure

A simple configuration document can record:

CONTENT
- Posts
- Pages
- Media

MARKETING
- SEO
- Forms

SYSTEM
- Users
- Plugins
- Settings

This helps future administrators understand whether a menu position is deliberate or accidental.

Document renamed items too

For example:

Original:
Entries

Custom:
Form Submissions

This prevents confusion when comparing your site with plugin documentation that still refers to the original label.

Keep support documentation aligned

If your internal documentation says:

Go to Posts → Add New

but the menu now says:

Articles → New Article

update the documentation.

Navigation customization and training material should tell the same story.

Common mistake: organizing for aesthetics instead of workflow

An evenly spaced menu can still be difficult to use.

Prioritize:

task clarity
before
visual symmetry

Common mistake: hiding pages instead of fixing permissions

If a user must not perform an operation, enforce the appropriate capability.

Do not rely solely on removing its sidebar link.

Common mistake: assuming remove_menu_page() blocks the URL

Core menu removal is navigation manipulation.

Direct access must be considered separately.

Common mistake: using CSS display:none

This hides only the rendered menu item and leaves the server-side navigation and authorization unchanged.

Common mistake: identifying items by translated labels

Use stable slugs rather than:

Posts
Media
Settings

when matching existing items programmatically.

Common mistake: hardcoding menu array positions

Do not assume:

$menu[5]

will forever represent the item you expect after plugins modify the structure.

Common mistake: ordering every plugin manually

A complete hardcoded list requires maintenance every time the plugin stack changes.

Consider prioritizing only the items whose order actually matters.

Common mistake: excessive renaming

Changing every standard WordPress term forces experienced users to relearn familiar navigation.

Rename only when the existing label creates genuine confusion.

Common mistake: moving plugin pages without testing active states

A screen may remain accessible while the sidebar highlights the wrong menu.

Common mistake: ignoring submenu behavior

Reordering only top-level menus can still leave important child screens buried under poorly ordered submenus.

Common mistake: too many separators

Grouping should simplify scanning, not add a heading above every individual item.

Common mistake: too many custom links

The WordPress admin sidebar should remain an administration interface, not a replacement for browser bookmarks.

Common mistake: testing only Administrator

Administrator usually sees more pages than every other role and therefore cannot represent the actual client or editor experience.

Common mistake: forgetting custom roles

Membership, e-commerce, LMS and editorial plugins frequently add their own roles.

Include them in menu testing.

Common mistake: forgetting Multisite

Network Admin uses different hooks and menu positions.

Common mistake: assuming the Admin Bar is part of the sidebar

Toolbar customization requires separate APIs and logic.

Common mistake: ignoring responsive behavior

A beautiful 1920-pixel administration sidebar can become unusable on a tablet if labels, separators or custom styles are poorly designed.

Common mistake: storing customization in WordPress Core

Core updates will eventually remind you why that was a bad idea.

Common mistake: changing plugin files directly

Plugin updates can overwrite the modification and make future support difficult.

Common mistake: no reset path

A visual organizer should provide a way to return to the native WordPress/plugin-generated structure.

Common mistake: no recovery path for administrators

If an administrator accidentally hides the configuration screen used to manage the menu itself, restoring access should not require database archaeology.

The current TheOneWP Admin Menu Organizer includes an administrator safety mechanism for its own configuration pages.

How TheOneWP Admin Menu Organizer approaches the problem

The module treats the WordPress admin menu as a generated structure that can be reorganized at runtime rather than permanently modifying WordPress or plugin code.

The current implementation supports:

• drag-and-drop top-level ordering;
• drag-and-drop submenu ordering;
• custom menu labels;
• global visibility rules;
• role-specific visibility rules;
• promoting submenu entries to top-level items;
• moving top-level entries beneath another parent;
• custom top-level links;
• custom submenu links;
• custom visual separators;
• direct-access handling for configured hidden pages;
• a reset workflow.

Changes are applied after menu registration

The organizer waits for WordPress and active plugins to register their administration pages, then applies the stored configuration to the resulting menu.

This is important because the menu is dynamic.

The sequence is effectively:

WordPress creates Core menu
↓
plugins register their pages
↓
Admin Menu Organizer
applies saved structure
↓
final menu rendered

Reordering uses native WordPress menu filters

The current implementation integrates menu ordering with:

custom_menu_order
menu_order

rather than creating a separate fake sidebar.

Visibility and direct access are handled separately

The module does not treat:

hidden from sidebar

as automatically equivalent to:

direct URL should be available

Configured hidden pages receive additional request handling according to the saved visibility rules.

Saving organizer settings is an administrative operation

The current module requires:

manage_options

for its management interface and protected save requests.

Submitted configuration is validated and sanitized before storage.

Menu organization should remain reversible

This principle applies whether you use custom code or a visual organizer.

A clean workflow is:

record current structure
↓
reorganize
↓
test
↓
deploy
↓
review
↓
reset or adjust if needed

WordPress admin-menu reorganization checklist

• Inventory the current top-level menu.
• Inventory all important submenus.
• Identify which plugins create each custom item.
• Identify the actual menu slugs.
• Do not rely only on visible labels.
• Classify menu items by functional area.
• Classify items by user workflow.
• Identify daily, weekly and rare tasks.
• Place frequent tasks earlier.
• Group related tools where appropriate.
• Keep separators meaningful.
• Rename only genuinely confusing labels.
• Keep renamed labels concise.
• Preserve familiar WordPress terminology where it remains useful.
• Use admin_menu for normal menu modifications.
• Use custom_menu_order to enable custom ordering.
• Use menu_order to define top-level order.
• Use remove_menu_page() for top-level navigation removal.
• Use remove_submenu_page() for submenu removal.
• Remember that navigation removal is not authorization.
• Use capabilities for security decisions.
• Use current_user_can() where appropriate.
• Test direct access to hidden screens.
• Use add_menu_page() for custom administration pages.
• Use add_submenu_page() for custom submenu pages.
• Verify capabilities inside custom page callbacks.
• Validate external custom-link URLs.
• Do not overload wp-admin with external shortcuts.
• Use role-aware visibility when workflows differ.
• Test custom roles.
• Test users with multiple roles where supported.
• Test moved top-level items.
• Test moved submenu items.
• Test active-menu highlighting.
• Test forms on moved plugin pages.
• Test AJAX actions.
• Test collapsed-menu behavior.
• Test responsive wp-admin.
• Test long labels at narrow widths.
• Test after plugin activation.
• Test after plugin deactivation.
• Test after major plugin updates.
• Test after major WordPress updates.
• Keep Site Admin and Network Admin logic separate.
• Do not modify WordPress Core.
• Do not modify third-party plugin files.
• Prefer a site-specific plugin or maintained configuration layer.
• Use version control for custom code.
• Document custom labels.
• Document group structure.
• Update client documentation after navigation changes.
• Provide a reset or recovery path.

Related guides

• How to Hide WordPress Admin Menu Items by Role
• How to Add Custom Admin Menu Items in WordPress
• Reducing WordPress Admin Confusion for Clients
• Standardizing the WordPress Admin for Teams
• Decluttering the WordPress Admin Dashboard
• WordPress Admin Menu Responsive Breakpoints, Explained

Final recommendation

Reorganizing the WordPress admin menu works best when the objective is not simply to make the sidebar shorter.

The goal is to make navigation correspond to real work.

Start with:

Who uses wp-admin?
↓
What do they do most often?
↓
Which screens support those tasks?
↓
Which screens are irrelevant?
↓
Which items belong together?

Then reorganize the navigation accordingly.

Use WordPress’s native:

admin_menu
custom_menu_order
menu_order
remove_menu_page()
remove_submenu_page()
add_menu_page()
add_submenu_page()

APIs and hooks when building a custom implementation.

Keep one distinction especially clear:

menu visibility
≠
permission

Hiding a menu item can make wp-admin substantially easier to navigate, but Core menu-removal functions do not automatically replace capability checks or direct-access controls.

For client and team sites, organize around stable workflows rather than individual preferences. Keep everyday content tools easy to find, place infrequently used system administration lower in the hierarchy and hide irrelevant navigation from users who do not need it.

A strong administration architecture might therefore become:

CONTENT
→ Posts
→ Pages
→ Media

MARKETING
→ SEO
→ Forms
→ Analytics

OPERATIONS
→ Orders
→ Customers

SYSTEM
→ Users
→ Plugins
→ Tools
→ Settings

with visibility adapted appropriately for each user group.

TheOneWP Admin Menu Organizer provides a visual layer for this process with top-level and submenu reordering, renaming, hierarchy changes, role-aware visibility, custom links, separators, direct-access handling for configured hidden pages and a reset workflow.

The result should not feel like a completely different CMS. It should feel like WordPress with the irrelevant parts moved out of the user’s way and the important tasks placed where they are easiest to find.