WordPress per-post vs. site-wide Comment Settings

The WordPress Dashboard is designed to provide a quick overview of a website.

On a fresh installation, that can be useful.

On a production website with several plugins installed, however, the Dashboard can gradually become filled with:

• WordPress Core widgets;
• SEO reports;
• security summaries;
• backup notices;
• analytics panels;
• plugin promotions;
• news feeds;
• license information;
• custom widgets.

For administrators responsible for the entire website, some of this information may be valuable.

For editors, authors, marketing teams or clients, much of it may simply make the interface harder to use.

WordPress provides a native way to remove Dashboard widgets programmatically:

remove_meta_box()

Combined with the:

wp_dashboard_setup

hook, it allows developers to create a cleaner Dashboard without modifying WordPress Core.

This guide explains how to remove WordPress Dashboard widgets safely, how to identify Core and plugin widget IDs, how the Welcome panel differs from normal Dashboard widgets, how to remove widgets selectively by capability and how permanent removal differs from simply hiding widgets through Screen Options.

What are WordPress Dashboard widgets?

Dashboard widgets are the panels displayed on:

/wp-admin/index.php

They provide summaries, shortcuts or information relevant to the current user.

WordPress uses its meta-box infrastructure to manage most Dashboard widgets.

The official WordPress Dashboard Widgets API documents how these components are registered and managed.

Current WordPress Core Dashboard widgets

Current WordPress Core can register several standard Dashboard widgets.

These include:

• At a Glance;
• Activity;
• Site Health Status;
• Quick Draft;
• WordPress Events and News.

Which widgets actually appear depends on:

• the current administration context;
• user capabilities;
• Multisite configuration;
• WordPress version;
• installed plugins;
• custom code.

The main Core Dashboard widget IDs

The current Dashboard Widgets API documents these Core IDs:

dashboard_right_now
→ At a Glance

dashboard_activity
→ Activity

dashboard_site_health
→ Site Health Status

dashboard_quick_press
→ Quick Draft

dashboard_primary
→ WordPress Events and News

Those IDs are what you pass to remove_meta_box().

WordPress does not register every widget for every user

Current Core already performs capability-aware registration.

For example, At a Glance is registered when the current user can edit posts, while Quick Draft depends on whether the user can create posts.

This means Dashboard output is already partly personalized by permissions before you add any custom cleanup. The current wp_dashboard_setup() implementation shows these capability checks directly.

Use wp_dashboard_setup to customize Dashboard widgets

WordPress provides the action:

wp_dashboard_setup

The official wp_dashboard_setup documentation states that it fires after Core Dashboard widgets have been registered.

This makes it the appropriate point to:

• add Dashboard widgets;
• remove Dashboard widgets;
• reorganize Dashboard components.

The basic removal pattern

To remove one widget:

add_action(
    'wp_dashboard_setup',
    function () {
        remove_meta_box(
            'dashboard_primary',
            'dashboard',
            'side'
        );
    }
);

This removes the WordPress Events and News widget.

How remove_meta_box() works

The official remove_meta_box() documentation defines the function as:

remove_meta_box(
    $id,
    $screen,
    $context
);

For Dashboard widgets, the three important values are:

$id
→ widget ID

$screen
→ dashboard

$context
→ normal or side

The context must match

This is easy to overlook.

For example:

dashboard_quick_press
→ side

dashboard_primary
→ side

dashboard_right_now
→ normal

dashboard_activity
→ normal

dashboard_site_health
→ normal

If you use the wrong context, the widget may remain visible.

Remove WordPress Events and News

This is one of the most common widgets removed from managed WordPress installations.

add_action(
    'wp_dashboard_setup',
    function () {
        remove_meta_box(
            'dashboard_primary',
            'dashboard',
            'side'
        );
    }
);

This can be useful on client or editorial dashboards where WordPress community events and news are unrelated to the user’s normal workflow.

Remove Quick Draft

Use:

add_action(
    'wp_dashboard_setup',
    function () {
        remove_meta_box(
            'dashboard_quick_press',
            'dashboard',
            'side'
        );
    }
);

This removes the Quick Draft widget.

That can make sense for users who create content through:

Posts
→ Add New

and never use the Dashboard shortcut.

Remove At a Glance

Use:

add_action(
    'wp_dashboard_setup',
    function () {
        remove_meta_box(
            'dashboard_right_now',
            'dashboard',
            'normal'
        );
    }
);

At a Glance provides basic site-content information.

Before removing it, consider whether users benefit from seeing counts for:

• posts;
• pages;
• comments;
• other supported content information.

Remove Activity

Use:

add_action(
    'wp_dashboard_setup',
    function () {
        remove_meta_box(
            'dashboard_activity',
            'dashboard',
            'normal'
        );
    }
);

The Activity widget can provide recent publishing and comment information.

It may be useful for editorial teams even when other Dashboard widgets are unnecessary.

Remove Site Health Status

Use:

add_action(
    'wp_dashboard_setup',
    function () {
        remove_meta_box(
            'dashboard_site_health',
            'dashboard',
            'normal'
        );
    }
);

This removes the Dashboard summary only.

It does not necessarily remove access to the complete Site Health screen.

Dashboard widget removal is not feature removal

This distinction matters.

If you remove:

dashboard_site_health

you remove:

Dashboard widget

not:

WordPress Site Health functionality

Similarly, removing Quick Draft does not disable post creation.

Remove several Core widgets at once

A simple focused Dashboard could use:

add_action(
    'wp_dashboard_setup',
    function () {
        remove_meta_box(
            'dashboard_primary',
            'dashboard',
            'side'
        );

        remove_meta_box(
            'dashboard_quick_press',
            'dashboard',
            'side'
        );

        remove_meta_box(
            'dashboard_site_health',
            'dashboard',
            'normal'
        );
    }
);

This preserves:

At a Glance
Activity

while removing three other standard panels.

Remove all standard Core Dashboard widgets

The WordPress Dashboard Widgets API currently documents the following pattern for removing the principal Core widgets:

add_action(
    'wp_dashboard_setup',
    function () {
        remove_meta_box(
            'dashboard_primary',
            'dashboard',
            'side'
        );

        remove_meta_box(
            'dashboard_quick_press',
            'dashboard',
            'side'
        );

        remove_meta_box(
            'dashboard_site_health',
            'dashboard',
            'normal'
        );

        remove_meta_box(
            'dashboard_right_now',
            'dashboard',
            'normal'
        );

        remove_meta_box(
            'dashboard_activity',
            'dashboard',
            'normal'
        );
    }
);

The Welcome panel is different

The WordPress Welcome panel is not removed with the same remove_meta_box() call used for normal Dashboard widgets.

WordPress renders it through:

wp_welcome_panel()

attached to:

welcome_panel

The official wp_welcome_panel() documentation identifies it as the function responsible for rendering the Welcome panel.

Remove the Welcome panel

Use:

remove_action(
    'welcome_panel',
    'wp_welcome_panel'
);

Complete example: remove the Welcome panel and Core widgets

add_action(
    'wp_dashboard_setup',
    function () {
        remove_action(
            'welcome_panel',
            'wp_welcome_panel'
        );

        remove_meta_box(
            'dashboard_primary',
            'dashboard',
            'side'
        );

        remove_meta_box(
            'dashboard_quick_press',
            'dashboard',
            'side'
        );

        remove_meta_box(
            'dashboard_site_health',
            'dashboard',
            'normal'
        );

        remove_meta_box(
            'dashboard_right_now',
            'dashboard',
            'normal'
        );

        remove_meta_box(
            'dashboard_activity',
            'dashboard',
            'normal'
        );
    }
);

Do not automatically remove everything

A completely empty Dashboard is not necessarily a better Dashboard.

A useful administration screen might contain only:

• recent activity;
• important workflow information;
• editorial instructions;
• custom shortcuts.

The objective should be:

relevant information

not:

zero information

For a broader workflow-oriented approach, see Building a Focused WordPress Dashboard for Teams.

Remove widgets selectively by capability

Different users may need different Dashboard information.

For example:

Administrator
→ Site Health useful

Editor
→ Site Health unnecessary

You can use:

current_user_can()

to customize the Dashboard according to permissions.

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

Example: preserve operational widgets for administrators

add_action(
    'wp_dashboard_setup',
    function () {
        if ( current_user_can( 'manage_options' ) ) {
            return;
        }

        remove_meta_box(
            'dashboard_site_health',
            'dashboard',
            'normal'
        );

        remove_meta_box(
            'dashboard_primary',
            'dashboard',
            'side'
        );
    }
);

Users with the selected capability keep the widgets.

Other affected users do not.

Why capabilities are better than role names

You could theoretically write:

if ( in_array(
    'editor',
    wp_get_current_user()->roles,
    true
) ) {
    // Remove widgets.
}

But that ties the behavior to a specific role label.

A capability check asks the more useful question:

What is this user
actually allowed to do?

For the wider permission model, see WordPress User Roles and Capabilities, Explained.

Dashboard cleanup does not change capabilities

If you remove a widget that links to a privileged feature, that does not revoke the underlying permission.

The relationship is:

Dashboard widget
→ interface

capability
→ authorization

Those must remain separate.

Removing a widget is not a security mechanism

Suppose a widget provides a shortcut to a settings page.

Removing the widget means:

shortcut disappears

It does not mean:

settings access disappears

If users should not access a feature, configure capabilities appropriately.

Screen Options can hide widgets without removing them

WordPress users can normally open:

Screen Options

and choose which Dashboard widgets to display.

That produces a different result from remove_meta_box().

For the full distinction, see WordPress Screen Options vs. Permanent Widget Removal.

Screen Options are usually user-specific

WordPress can store hidden meta-box preferences for individual users.

Current get_hidden_meta_boxes() retrieves a user option based on the current screen ID.

The model is:

User A
→ hides Activity

User B
→ keeps Activity visible

Permanent removal is different

If your code executes:

remove_meta_box(
    'dashboard_activity',
    'dashboard',
    'normal'
);

the widget is removed from the Dashboard structure for users affected by that code.

They cannot simply restore it through Screen Options.

Choose Screen Options for preferences

Screen Options are appropriate when:

• the widget remains useful;
• different users have different preferences;
• individual personalization is desirable.

Choose removal for structural cleanup

Programmatic removal is appropriate when:

• the widget is irrelevant to a workflow;
• you want a consistent team dashboard;
• users should not need to configure the interface manually;
• a plugin widget is unnecessary for an entire group.

Plugins can add Dashboard widgets too

The same Dashboard API is available to plugin developers.

A plugin may add panels for:

• SEO;
• analytics;
• forms;
• security;
• backups;
• e-commerce;
• marketing;
• license status.

Plugin widgets can often be removed with the same function

If the plugin uses the normal Dashboard widget or meta-box APIs:

remove_meta_box(
    'plugin_widget_id',
    'dashboard',
    'normal'
);

or:

remove_meta_box(
    'plugin_widget_id',
    'dashboard',
    'side'
);

may be sufficient.

You need the actual widget ID

The visible title is not necessarily the ID.

A widget titled:

SEO Overview

could internally use:

plugin_dashboard_summary

or any other identifier chosen by its developer.

Search plugin source code

A useful first step is to search the plugin for:

wp_add_dashboard_widget(

The official wp_add_dashboard_widget() documentation shows that the first parameter is the widget ID.

For example:

wp_add_dashboard_widget(
    'example_dashboard_widget',
    'Example Dashboard Widget',
    'example_render_widget'
);

The removable ID is:

example_dashboard_widget

Inspect the Dashboard registry when the ID is unclear

Dashboard meta boxes are stored in the global:

$wp_meta_boxes

During development, you can temporarily inspect the Dashboard structure:

add_action(
    'wp_dashboard_setup',
    function () {
        global $wp_meta_boxes;

        error_log(
            print_r(
                $wp_meta_boxes['dashboard'] ?? array(),
                true
            )
        );
    },
    999
);

This can help identify:

• widget IDs;
• contexts;
• priorities.

Do not leave diagnostic logging enabled

Remove temporary logging after the audit.

Dumping large administration structures into production logs indefinitely provides little benefit and can make useful debugging information harder to find.

Timing matters for plugin widgets

Consider:

your removal
→ priority 10

plugin registration
→ priority 20

Your code runs first.

The widget does not exist yet.

Then the plugin registers it afterward.

The final result:

widget remains visible

Use a later priority when required

For example:

add_action(
    'wp_dashboard_setup',
    function () {
        remove_meta_box(
            'plugin_widget_id',
            'dashboard',
            'normal'
        );
    },
    100
);

This allows common earlier registrations to happen before removal.

Priority 100 is not universally correct

The number simply controls ordering.

If the plugin registers its widget later, you need to understand its actual hook priority.

Do not solve every timing issue by adding another zero to the number.

Some plugin Dashboard interfaces may not use meta boxes

Not every component that visually resembles a Dashboard widget necessarily uses:

wp_add_dashboard_widget()

A plugin may render custom markup through another hook or JavaScript application.

In that case, remove_meta_box() may not affect it.

Find how the plugin actually renders the component

Search for:

• wp_add_dashboard_widget();
• add_meta_box();
• wp_dashboard_setup;
• Dashboard-specific hooks;
• custom admin JavaScript.

Then remove the component using the corresponding architecture.

Do not hide widgets with CSS when an API exists

A tempting shortcut is:

#dashboard_primary {
    display: none;
}

This hides the panel visually.

It does not remove the widget from WordPress’s Dashboard structure.

CSS hiding is weaker than actual removal

With CSS:

widget registered
+
possibly rendered
+
hidden visually

With remove_meta_box():

widget removed
from Dashboard structure

Use the native API when it matches the requirement.

JavaScript hiding has the same problem

This:

document
    .querySelector( '#dashboard_primary' )
    ?.remove();

removes the element from the browser DOM after the page has already been generated.

It does not prevent WordPress from registering the widget server-side.

Remove widgets server-side when possible

This keeps the administration architecture clearer and easier to maintain.

Removing a widget may not eliminate all of its runtime cost

This point requires nuance.

Suppose a plugin performs:

remote API request
↓
process statistics
↓
register Dashboard widget

If your code removes the widget afterward, the earlier API request may already have happened.

Interface removal and performance optimization are separate problems

A removed widget:

does not automatically mean
its plugin performed zero work

If Dashboard performance is poor, inspect the plugin’s execution path as well.

Some Dashboard widgets can contribute significant work

Widgets may perform:

• database queries;
• remote API calls;
• statistics aggregation;
• filesystem checks;
• license checks;
• background calculations.

If a widget is both unnecessary and expensive, removing or preventing its underlying work can improve administration performance.

Do not remove Site Health solely for performance

Site Health provides useful diagnostic information for people maintaining the website.

If the widget itself is irrelevant to content editors, removing it from their Dashboard can improve clarity.

That is a workflow decision, not an argument for eliminating WordPress diagnostics globally.

Use the current screen when building more advanced admin logic

WordPress exposes:

get_current_screen()

The official get_current_screen() documentation returns the current WP_Screen object once the administration screen has been established.

For example:

$screen = get_current_screen();

if (
    $screen
    &&
    'dashboard' === $screen->id
) {
    // Dashboard-specific logic.
}

You usually do not need get_current_screen() for basic Dashboard removal

If your function already runs on:

wp_dashboard_setup

and removes:

screen = dashboard

the context is already explicit.

Use additional screen checks when they solve a real ambiguity.

WordPress Multisite has separate Dashboard contexts

On Multisite installations, WordPress also provides:

wp_network_dashboard_setup

for the Network Admin Dashboard.

The WordPress Dashboard Widgets API specifically distinguishes this from the standard site Dashboard.

Removing a site Dashboard widget does not necessarily remove a Network Dashboard widget

The screen IDs differ.

For Network Admin, the screen may use:

dashboard-network

rather than:

dashboard

Audit Multisite interfaces independently.

Do not use a global unset unless you genuinely want everything gone

Developers sometimes manipulate:

$wp_meta_boxes['dashboard']

directly.

That can remove large portions of the Dashboard registry.

For ordinary cleanup, explicit remove_meta_box() calls are easier to understand and maintain.

Explicit removal documents intent

Compare:

unset(
    $wp_meta_boxes['dashboard']
);

with:

remove_meta_box(
    'dashboard_primary',
    'dashboard',
    'side'
);

remove_meta_box(
    'dashboard_quick_press',
    'dashboard',
    'side'
);

The second version tells the next developer exactly which components were intentionally removed.

Keep a custom Dashboard useful

After removing unnecessary widgets, you can add a focused replacement.

WordPress provides:

wp_add_dashboard_widget()

For example:

add_action(
    'wp_dashboard_setup',
    function () {
        wp_add_dashboard_widget(
            'team_resources',
            'Team Resources',
            function () {
                echo '<p>';
                echo 'Useful links for your editorial workflow.';
                echo '</p>';
            }
        );
    }
);

Custom widgets should solve actual tasks

Useful custom content might include:

• editorial guidelines;
• support contacts;
• content shortcuts;
• publishing instructions;
• launch procedures;
• links to documentation.

Do not recreate the entire admin menu inside the Dashboard

If the user can already click:

Posts
Media
Pages

in the left navigation, reproducing all three in several giant Dashboard cards may not improve anything.

The Dashboard should provide orientation, not duplicate every wp-admin screen.

Combine widget cleanup with admin menu organization carefully

A cleaner Dashboard is only one layer of administration UX.

The left-side menu may still contain many irrelevant destinations.

TheOneWP Admin Menu Organizer can apply role-aware navigation rules to wp-admin.

Dashboard widgets and admin menus solve different problems

The distinction is:

Dashboard widget
→ information and shortcuts

Admin menu
→ navigation

Capabilities
→ authorization

Do not use one as a substitute for another.

Build different Dashboards for different teams when necessary

A useful configuration might be:

Authors

Activity
Editorial Guidelines

Editors

At a Glance
Activity
Editorial Resources

Administrators

At a Glance
Activity
Site Health
operational widgets

This approach is covered more broadly in Building a Focused WordPress Dashboard for Teams.

Do not create separate dashboards without a workflow reason

Different interfaces are useful when responsibilities genuinely differ.

They become difficult to maintain when every individual employee receives a custom configuration.

Design around stable groups and capabilities.

Where should Dashboard cleanup code live?

Suitable locations can include:

• a site-specific plugin;
• a must-use plugin;
• a maintained snippets system;
• a child theme when the behavior is specifically tied to that theme.

Site-level administration behavior often belongs outside the theme

If changing the visual theme should not restore:

five unwanted Dashboard widgets

then storing the cleanup in a site-specific plugin or equivalent configuration may be more appropriate.

Do not modify WordPress Core

Never edit Core Dashboard files just to remove widgets.

WordPress already provides:

wp_dashboard_setup
remove_meta_box()
remove_action()

for these changes.

Core modifications create unnecessary maintenance problems

They can:

• be overwritten during updates;
• make debugging harder;
• complicate security updates;
• hide the source of customization.

Test Dashboard cleanup on staging

Dashboard changes are usually lower-risk than frontend template modifications, but role-dependent behavior can still cause confusion.

Test first on staging.

See WordPress Staging Site Best Practices.

Create representative test users

Do not test only as Administrator.

Create accounts matching actual workflows:

author-test
editor-test
marketing-test
administrator-test

Check each Dashboard separately

For each role:

1. Log in.
2. Open Dashboard.
3. Confirm intended widgets are present.
4. Confirm unwanted widgets are absent.
5. Open Screen Options.
6. Check which remaining widgets are configurable.
7. Test normal navigation.
8. Confirm required information remains available elsewhere.

Test plugin updates

A plugin update may:

• change a widget ID;
• change its context;
• change its registration priority;
• replace a meta-box widget with a custom interface;
• introduce another Dashboard widget.

Re-test your Dashboard customization after major plugin changes.

Test WordPress updates

Core Dashboard architecture is stable, but individual widgets and conditions can evolve.

After major WordPress updates, verify that your removal rules still target current components rather than historical IDs copied from an old tutorial.

Document every structural removal

Record:

• widget name;
• widget ID;
• context;
• affected users;
• reason for removal;
• code or module responsible.

This prevents future debugging problems

Otherwise a future administrator may install a plugin, read its documentation and wonder why its Dashboard widget apparently vanished.

The answer should be documented rather than archaeological.

A practical focused Dashboard example

The following example:

• keeps all widgets for administrators with manage_options;
• removes Site Health;
• removes WordPress Events and News;
• removes Quick Draft;
• keeps At a Glance and Activity for other users.

add_action(
    'wp_dashboard_setup',
    function () {
        if ( current_user_can( 'manage_options' ) ) {
            return;
        }

        remove_meta_box(
            'dashboard_site_health',
            'dashboard',
            'normal'
        );

        remove_meta_box(
            'dashboard_primary',
            'dashboard',
            'side'
        );

        remove_meta_box(
            'dashboard_quick_press',
            'dashboard',
            'side'
        );
    },
    100
);

A fully minimal client Dashboard example

If a particular group genuinely does not need any standard Core Dashboard widgets:

add_action(
    'wp_dashboard_setup',
    function () {
        if ( current_user_can( 'manage_options' ) ) {
            return;
        }

        remove_action(
            'welcome_panel',
            'wp_welcome_panel'
        );

        remove_meta_box(
            'dashboard_primary',
            'dashboard',
            'side'
        );

        remove_meta_box(
            'dashboard_quick_press',
            'dashboard',
            'side'
        );

        remove_meta_box(
            'dashboard_site_health',
            'dashboard',
            'normal'
        );

        remove_meta_box(
            'dashboard_right_now',
            'dashboard',
            'normal'
        );

        remove_meta_box(
            'dashboard_activity',
            'dashboard',
            'normal'
        );
    },
    100
);

Do not use this merely because it looks clean

A Dashboard should serve the user.

If Activity helps an editor understand recent changes, keep it.

If Site Health helps an administrator spot configuration problems, keep it.

Remove components because they are irrelevant to the workflow, not because blank space is fashionable.

Dashboard widget removal checklist

• Identify which users actually use the Dashboard.
• List all current Core Dashboard widgets.
• List plugin-added Dashboard widgets.
• Determine which widgets are useful to each workflow.
• Use wp_dashboard_setup for standard Dashboard customization.
• Use remove_meta_box() for normal Dashboard widgets.
• Use the correct widget ID.
• Use the correct screen ID.
• Use the correct normal or side context.
• Remove the Welcome panel separately with remove_action().
• Prefer explicit removal over CSS hiding.
• Prefer explicit removal over JavaScript DOM manipulation.
• Use capability checks for role-aware behavior.
• Do not treat widget visibility as authorization.
• Do not revoke useful operational information from administrators unnecessarily.
• Distinguish Screen Options from structural removal.
• Search plugin code for wp_add_dashboard_widget() when IDs are unknown.
• Inspect $wp_meta_boxes temporarily when necessary.
• Remove debugging output after use.
• Check hook priority when plugin widgets survive removal.
• Do not assume every plugin panel uses the Dashboard Widgets API.
• Audit Dashboard performance separately from visual clutter.
• Do not assume removing a widget prevents all plugin processing.
• Test WordPress Multisite Dashboard contexts separately.
• Avoid modifying WordPress Core.
• Use a site-specific implementation for site-level behavior where appropriate.
• Test each important user role.
• Test Screen Options after removal.
• Test after major plugin updates.
• Test after major WordPress updates.
• Document permanent Dashboard changes.

How Dashboard cleanup fits with TheOneWP

Removing Dashboard widgets is one part of building a more focused WordPress administration experience.

TheOneWP Admin Menu Organizer addresses the separate problem of wp-admin navigation and can apply role-aware menu organization.

TheOneWP Role Manager addresses the underlying role and capability model.

Disable Admin Notifications by Role can reduce irrelevant administrative notices for selected user groups.

Those layers should remain conceptually separate:

Role Manager
→ what users may do

Admin Menu Organizer
→ where users navigate

Dashboard widget removal
→ what appears on Dashboard

Screen Options
→ what available components users personalize

Notification controls
→ which administrative messages users see

A focused administration interface works best when each system has one clear responsibility.

Related guides

• WordPress Screen Options vs. Permanent Widget Removal
• Building a Focused WordPress Dashboard for Teams
• WordPress Screen Options, Explained
• Reducing WordPress Admin Confusion for Clients
• WordPress User Roles and Capabilities, Explained
• How to Audit User Roles on a WordPress Site

Final recommendation

Removing unnecessary WordPress Dashboard widgets is a straightforward way to create a cleaner administration experience, but the implementation should reflect actual user responsibilities.

The basic architecture is:

WordPress registers widget
↓
wp_dashboard_setup fires
↓
remove_meta_box() removes
unwanted widget

Use the documented Core widget IDs rather than copying identifiers from old tutorials.

Remember that the Welcome panel is separate and must be removed from the welcome_panel action rather than through remove_meta_box().

Use capability-aware conditions when administrators and editorial users need different Dashboard configurations.

Do not use widget removal as a substitute for proper permissions.

Do not hide widgets with CSS when WordPress already provides a server-side removal API.

Do not assume removing a plugin widget automatically eliminates all database or remote API work associated with that plugin.

And do not remove every widget merely to produce an empty screen.

The useful decision process is:

identify user workflow
↓
identify useful widgets
↓
remove irrelevant widgets
↓
preserve required permissions
↓
test each user type
↓
review after updates

A good WordPress Dashboard is not the one with the fewest boxes.

It is the one where every remaining box has a clear reason to exist.