How to Set a Fixed Dashboard Layout in WordPress

Setting a fixed Dashboard layout in WordPress means making the main wp-admin Dashboard use the same column structure for every user instead of allowing each account to end up with a different arrangement.

This is particularly useful on:

• agency-managed websites;
• client installations;
• editorial teams;
• membership platforms;
• WooCommerce stores;
• sites with custom Dashboard widgets;
• WordPress installations used as an internal application.

By default, the WordPress Dashboard is designed as a personal workspace.

Users can hide widgets through Screen Options, move widgets by dragging them and maintain their own administration preferences.

The official WordPress Dashboard documentation explains that Dashboard widgets can be shown or hidden through Screen Options and rearranged through drag and drop.

That flexibility is useful for individual users.

It becomes less useful when an organization wants:

same site
+
same role
+
same training
+
same dashboard structure

but different users see different layouts.

This guide explains how the WordPress Dashboard layout works, why layouts can differ between accounts, how WordPress stores Dashboard preferences, how to enforce a fixed number of columns, how widgets interact with the layout and when a site-wide configuration is preferable to normal Screen Options.

What does a fixed WordPress Dashboard layout mean?

A fixed Dashboard layout usually means choosing a consistent number of columns for the main:

Dashboard → Home

screen.

For example:

1 column

or:

2 columns

for every user.

A broader Dashboard standard may also define:

• which widgets exist;
• which widgets are removed;
• which custom widgets are added;
• which information appears first;
• which roles see particular widgets.

Those are separate controls.

A useful distinction is:

Column count
→ Dashboard layout

Widget availability
→ Dashboard content

Widget order
→ Dashboard arrangement

Capabilities
→ authorization

The WordPress Dashboard is built from widgets

WordPress calls the information blocks on the main Dashboard screen widgets.

Core widgets can include areas such as:

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

Plugins can register additional widgets.

The official wp_dashboard_setup hook documentation explains that the hook fires after Core Dashboard widgets have been registered and can be used to add or remove Dashboard widgets.

Widgets and columns solve different problems

Suppose a Dashboard contains:

At a Glance
Activity
Quick Draft
SEO Overview
Store Overview
Security Status

You can decide:

which widgets exist

separately from:

how many columns contain them

A fixed two-column Dashboard does not automatically remove unnecessary widgets.

Likewise, removing widgets does not automatically establish a consistent column layout.

Why Dashboard layouts can differ between users

WordPress stores many administration preferences at the user level.

The official get_user_option() documentation describes the API WordPress uses to retrieve options associated with individual users.

The Dashboard layout participates in this system.

Conceptually:

User Alice
→ Dashboard preference A

User Marco
→ Dashboard preference B

User Sarah
→ Dashboard preference C

They are using the same WordPress installation, but their administration preferences do not necessarily have to match.

WordPress uses screen-specific layout preferences

The current WP_Screen implementation can retrieve a user preference with a name based on:

screen_layout_{screen_id}

For the Dashboard, the relevant screen ID is:

dashboard

so the corresponding user option is conceptually:

screen_layout_dashboard

This is a user preference, not a site-wide setting

That distinction explains why changing one account does not necessarily standardize another account.

If the layout is stored as a user preference, then:

configure Alice's Dashboard
≠
configure every Dashboard

This is the same broader behavior discussed in WordPress Screen Options, Explained.

Screen Options and fixed layouts serve different goals

Screen Options are appropriate when users should personalize their own administration experience.

A fixed layout is appropriate when the organization wants:

• consistent onboarding;
• matching screenshots;
• repeatable support instructions;
• a predictable custom Dashboard;
• the same widget structure across accounts.

The distinction is:

Screen Options
→ user preference

Fixed Dashboard layout
→ site policy

Why teams benefit from a fixed layout

Imagine an internal guide that says:

Check the Store Overview
widget in the right column.

If one employee sees:

2 columns

and another sees:

a different layout

the instruction immediately becomes less reliable.

Consistency becomes especially valuable when WordPress is used by people who are not expected to understand wp-admin configuration itself.

See Standardizing the WordPress Admin for Teams for the broader administration strategy.

There are three different levels of Dashboard control

A useful architecture is:

Level 1
User preference
→ Screen Options

Level 2
Site-wide interface policy
→ fixed layout and widget configuration

Level 3
Authorization
→ roles and capabilities

Do not use a fixed Dashboard layout as a security mechanism.

A user who does not see a Dashboard widget may still have access to the underlying feature through another administration screen.

Do not rely on CSS alone to fix the Dashboard

It is possible to make the Dashboard visually appear to use a certain structure with custom CSS.

For example, developers sometimes try to manipulate:

#dashboard-widgets
.postbox-container

directly.

That may change the visual presentation, but it does not necessarily change WordPress’s underlying screen-layout preference.

Why CSS-only solutions are fragile

A CSS-only implementation may conflict with:

• WordPress responsive behavior;
• saved user preferences;
• plugin Dashboard widgets;
• future Core markup changes;
• drag-and-drop behavior;
• different viewport widths.

If WordPress already has an administration preference representing the layout, controlling that preference is generally cleaner than fighting the rendered interface afterward.

Use the WordPress Screen API instead

WordPress administration screens are represented by:

WP_Screen

The official WP_Screen reference shows that screen layout columns are represented through the:

layout_columns

screen option.

The Screen API can then read the corresponding user’s layout preference.

add_screen_option() registers screen-level options

WordPress provides:

add_screen_option()

for configuring options associated with the current administration screen.

The official add_screen_option() documentation explains that the function registers an option with the current WP_Screen object.

A basic fixed Dashboard column implementation

A custom plugin can establish a Dashboard column count by registering the Dashboard layout option and overriding the user preference.

For example:

function myplugin_fixed_dashboard_layout() {

    add_screen_option(
        'layout_columns',
        array(
            'max'     => 2,
            'default' => 2,
        )
    );
}

add_action(
    'load-index.php',
    'myplugin_fixed_dashboard_layout'
);

This establishes the layout capability on the Dashboard screen.

However, registering a default alone is not the same as overriding every user’s existing preference.

Existing user preferences can still matter

A user may already have a stored:

screen_layout_dashboard

value.

WordPress can retrieve that value instead of relying exclusively on the default you registered.

If the objective is:

every user
must receive
the same Dashboard layout

then the user-specific value also needs to be controlled.

WordPress exposes dynamic user-option filters

The get_user_option() API applies a dynamic filter based on the requested option name.

For the Dashboard layout, that produces:

get_user_option_screen_layout_dashboard

This makes it possible to override the retrieved Dashboard column preference without directly rewriting every user’s stored metadata.

Example: force two Dashboard columns for every user

function myplugin_fixed_dashboard_layout() {

    add_screen_option(
        'layout_columns',
        array(
            'max'     => 2,
            'default' => 2,
        )
    );
}

function myplugin_force_dashboard_columns(
    $value
) {
    return 2;
}

add_action(
    'load-index.php',
    'myplugin_fixed_dashboard_layout'
);

add_filter(
    'get_user_option_screen_layout_dashboard',
    'myplugin_force_dashboard_columns'
);

The result is conceptually:

User preference says 1
→ return 2

User preference says 3
→ return 2

No preference exists
→ return 2

Why filtering is cleaner than rewriting every account

An alternative would be to loop through users and permanently update their stored preference.

That creates additional problems:

• new users would still need initialization;
• old values remain part of the site’s data model;
• the operation must be repeated when the desired layout changes;
• removing the customization does not automatically restore previous preferences.

A runtime filter expresses the site policy directly:

While this policy is active,
the Dashboard uses two columns.

Scope the customization to the Dashboard

The main WordPress Dashboard is loaded through:

index.php

inside wp-admin.

WordPress exposes the:

load-index.php

hook for that administration screen.

Using a screen-specific hook is preferable to running Dashboard logic on every wp-admin request.

Do not modify unrelated admin screens

A fixed Dashboard layout should not accidentally affect:

• Posts;
• Pages;
• Users;
• Media;
• plugin administration screens;
• custom post type lists.

Those screens have their own Screen Options and layouts.

Choose the number of columns based on actual content

The technically possible layout is not necessarily the useful layout.

Consider how many Dashboard widgets remain active.

A site containing:

At a Glance
Activity
Quick Draft

may work comfortably with:

1 or 2 columns

A custom internal portal with:

Sales Overview
Open Tasks
Recent Orders
Support Activity
Content Queue
System Status

may benefit from a denser layout on wide screens.

More columns reduce individual widget width

Increasing column count means each widget has less horizontal space.

This can affect:

• tables;
• long labels;
• charts;
• custom buttons;
• plugin widgets;
• responsive components.

Test the actual widgets rather than choosing a column count solely because more columns are available.

A fixed desktop layout still needs responsive behavior

Fixed does not mean:

physically force four columns
onto a 390px-wide phone

The administration interface still needs to respond to available space.

A good implementation establishes the intended Dashboard layout while allowing WordPress and the browser to adapt appropriately on smaller viewports.

Test several viewport widths

At minimum, test:

• large desktop;
• standard laptop;
• tablet-width administration;
• mobile administration.

Check whether:

• widget text remains readable;
• tables remain usable;
• controls remain accessible;
• horizontal overflow appears;
• custom widget CSS behaves correctly.

A fixed column count does not fix widget order

This distinction is important.

Setting:

2 columns

does not necessarily mean every account will have:

Column 1:
At a Glance
Activity

Column 2:
Quick Draft
Store Overview

WordPress Dashboard widgets can be rearranged.

The official Dashboard documentation explains that users can drag and drop widgets to change their position.

Widget order is another user preference

If exact widget placement matters, that must be treated separately from the number of columns.

Think of the Dashboard as two configuration layers:

Layout
→ number of columns

Arrangement
→ where widgets sit inside those columns

Do not promise exact positions unless you control them

If your internal documentation says:

The sales widget is always
the first widget in column two.

then merely fixing the column count may not be enough.

You must also decide whether users are allowed to rearrange widgets and whether their stored widget order should be preserved.

A fixed layout works best with a curated widget set

The layout becomes much easier to manage when unnecessary widgets have already been removed.

Consider:

12 widgets
+
2 columns

versus:

4 relevant widgets
+
2 columns

The second environment is easier to keep predictable.

See Decluttering the WordPress Admin Dashboard for the wider cleanup process.

Remove Dashboard widgets through WordPress hooks

The official wp_dashboard_setup hook is the standard place to customize registered Dashboard widgets.

WordPress also provides:

remove_meta_box()

for removing registered boxes from administration screens.

The official remove_meta_box() documentation covers the required parameters.

Example: remove a Dashboard widget

function myplugin_remove_dashboard_widgets() {

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

add_action(
    'wp_dashboard_setup',
    'myplugin_remove_dashboard_widgets'
);

This is fundamentally different from asking each user to hide the widget through Screen Options.

Permanent removal versus Screen Options

Compare:

Screen Options
→ User A hides widget
→ User B still sees it
→ new users may still see it

with:

remove_meta_box()
→ widget removed from the Dashboard
→ applies as configured by the site

For the dedicated comparison, see WordPress Screen Options vs. Permanent Widget Removal.

Adding custom widgets can make a fixed layout more valuable

A fixed Dashboard becomes especially useful when the Dashboard is intentionally designed around the organization.

WordPress provides:

wp_add_dashboard_widget()

for registering custom Dashboard widgets.

The Dashboard setup hook explicitly supports adding custom widgets through this API.

Example: add a team information widget

function myplugin_register_dashboard_widget() {

    wp_add_dashboard_widget(
        'myplugin_team_status',
        'Team Status',
        'myplugin_render_team_status'
    );
}

function myplugin_render_team_status() {

    echo '<p>Current editorial information.</p>';
}

add_action(
    'wp_dashboard_setup',
    'myplugin_register_dashboard_widget'
);

A fixed layout then lets the organization design a predictable Dashboard around these widgets.

Do not put expensive operations inside Dashboard widgets

Remember that the Dashboard may be one of the first screens users load after logging in.

A custom widget that performs:

• slow remote API calls;
• large database queries;
• multiple uncached aggregate calculations;
• expensive filesystem scans;

can make the entire login experience feel slow.

Only load Dashboard-specific assets on the Dashboard

If a custom widget needs CSS or JavaScript, do not enqueue those assets across every wp-admin screen.

The official admin_enqueue_scripts documentation explains that the hook provides the current admin page suffix so assets can be scoped appropriately.

For example:

function myplugin_dashboard_assets(
    $hook_suffix
) {

    if ( 'index.php' !== $hook_suffix ) {
        return;
    }

    wp_enqueue_style(
        'myplugin-dashboard',
        plugins_url(
            'dashboard.css',
            __FILE__
        )
    );
}

add_action(
    'admin_enqueue_scripts',
    'myplugin_dashboard_assets'
);

Do not confuse Dashboard layout with capabilities

Suppose a Dashboard widget links to:

plugin settings

Removing that widget does not necessarily remove access to:

wp-admin/admin.php?page=plugin-settings

Likewise, fixing a Dashboard layout does not affect:

• roles;
• capabilities;
• direct administration URLs;
• plugin permissions.

Authorization must remain separate.

Check capabilities inside custom widgets

If a widget exposes privileged information or actions, check the appropriate capability.

For example:

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

The official current_user_can() documentation describes capability-based authorization.

Different roles may still need different widgets

A fixed column layout does not require identical content for every role.

You might use:

2 columns
for everyone

while displaying:

Editors
→ editorial widgets

Shop Managers
→ ecommerce widgets

Administrators
→ maintenance widgets

This creates structural consistency without pretending every user has the same job.

Fixed layout and role-aware widgets work well together

A useful architecture might be:

Dashboard
→ fixed 2-column structure

Editor
→ editorial widgets

Shop Manager
→ store widgets

Administrator
→ system widgets

The frame stays predictable while the information remains relevant.

Use TheOneWP Dashboard Columns for a site-wide layout

TheOneWP Dashboard Columns provides a site-wide Dashboard column setting.

The verified implementation supports:

• one to four columns;
• a single configured value for the site;
• an override of individual Dashboard layout preferences;
• Dashboard-only scope;
• integration with the native WordPress Screen Options system.

The implementation runs when the Dashboard loads, registers the:

layout_columns

screen option and filters:

get_user_option_screen_layout_dashboard

so the configured column count takes precedence over each user’s stored preference.

Why this is preferable to editing user metadata

The module expresses the requirement directly:

Dashboard layout policy
=
2 columns

rather than:

find every existing user
↓
change metadata
↓
remember to change new users
↓
repeat when policy changes

The configuration only affects the Dashboard

The Dashboard Columns module is scoped to:

Dashboard → Home

It does not change Screen Options on:

• Posts;
• Pages;
• Users;
• Comments;
• Media;
• other administration screens.

Combine Dashboard Columns with widget cleanup

A consistent Dashboard normally benefits from both:

fixed layout
+
curated widgets

TheOneWP Disable Dashboard Widgets can remove selected WordPress and plugin Dashboard widgets for every user.

This differs from Screen Options because the disabled widget is removed from the Dashboard configuration rather than merely hidden for one account.

A practical team configuration

For example:

Dashboard Columns
→ 2

Widgets retained:
→ At a Glance
→ Activity
→ Editorial Queue
→ Store Summary

Widgets removed:
→ Quick Draft
→ WordPress Events and News
→ unused plugin promotions

This gives users a more predictable first screen without completely rebuilding wp-admin.

For a broader team-focused approach, see Building a Focused WordPress Dashboard for Teams.

Do not remove useful operational information

Dashboard cleanup can become counterproductive when administrators remove information simply because it looks busy.

Before removing a widget, determine:

• who uses it;
• what information it contains;
• whether that information exists elsewhere;
• whether it represents an important warning;
• whether a specific role should retain it.

Test the layout after plugin changes

Plugins can add Dashboard widgets during activation.

A previously balanced layout such as:

4 widgets
+
2 columns

can become:

9 widgets
+
2 columns

after installing several plugins.

Review the Dashboard when its widget inventory changes substantially.

Test as different users

Do not verify a fixed layout only as the main Administrator account.

Test:

• an Administrator;
• an Editor;
• an Author;
• important custom roles;
• a newly created account.

Confirm that the intended column count remains consistent.

Test accounts with existing Dashboard preferences

This is especially important.

Use one account that previously preferred:

1 column

and another that previously used a different Dashboard preference.

A genuine fixed-layout implementation should override both while active.

Test new users too

A site-wide policy should not depend on whether the account existed when the configuration was created.

Create a test user after enabling the fixed layout and verify that the Dashboard still follows the configured structure.

Test what happens when the fixed layout is disabled

A well-scoped runtime override can allow WordPress to return to normal preference handling once the customization is removed.

That is another advantage over destructive bulk rewriting of user metadata.

Do not assume exact visual widths

A two-column Dashboard does not necessarily guarantee:

exactly 50% + 50%

under every viewport and WordPress version.

Responsive CSS, Core behavior and the available administration width still influence the rendered result.

The configuration should describe:

layout intent

rather than treating wp-admin as a rigid pixel grid.

Fixed Dashboard layout checklist

• Decide whether the site really needs a shared Dashboard layout.
• Choose the number of columns based on actual widget content.
• Do not rely only on CSS to enforce the layout.
• Use WordPress Screen APIs where possible.
• Understand that Dashboard layout preferences can be user-specific.
• Use screen_layout_dashboard only with an understanding of the user-option system.
• Use a filter when a site-wide policy must override personal preferences.
• Scope Dashboard code to the Dashboard screen.
• Keep unrelated wp-admin screens untouched.
• Remember that column count and widget order are different settings.
• Remove unnecessary widgets separately.
• Do not confuse hidden widgets with restricted access.
• Use capability checks for privileged widget content.
• Keep custom widgets lightweight.
• Load custom Dashboard assets only where required.
• Test large and small viewports.
• Test multiple roles.
• Test users with existing preferences.
• Test newly created users.
• Review the layout after installing plugins that add Dashboard widgets.
• Document the chosen layout for team onboarding.

When should you keep the default WordPress behavior?

A fixed layout is not necessary for every site.

Keep normal user personalization when:

• only one person uses wp-admin;
• users genuinely benefit from different Dashboard arrangements;
• the Dashboard contains few widgets;
• there is no shared training or documentation requirement;
• the administration environment is intentionally personal.

When is a fixed layout useful?

A fixed layout becomes more valuable when:

• multiple people perform the same role;
• training material refers to widget positions;
• clients need a predictable administration experience;
• the Dashboard contains custom business information;
• new users should receive a ready-to-use workspace;
• the organization wants a controlled WordPress backend.

A complete Dashboard standard has several layers

For a managed WordPress installation, think beyond only the column count.

A complete strategy can be:

1. Choose useful widgets

2. Remove unnecessary widgets

3. Set a consistent column count

4. Decide whether widget order may vary

5. Apply role-aware content where required

6. Test responsive behavior

7. Document the final layout

Related guides

• WordPress Screen Options, Explained
• WordPress Screen Options vs. Permanent Widget Removal
• How to Remove Widgets from the WordPress Dashboard
• Decluttering the WordPress Admin Dashboard
• Building a Focused WordPress Dashboard for Teams
• Standardizing the WordPress Admin for Teams

Final recommendation

A fixed WordPress Dashboard layout is most useful when the Dashboard is treated as a shared operational interface rather than a personal collection of widgets.

The key distinction is:

Screen Options
→ individual preference

Fixed column layout
→ site-wide interface policy

Widget removal
→ Dashboard content policy

Capabilities
→ authorization

If all users should receive the same column structure, control the Dashboard’s layout preference through WordPress’s own screen and user-option APIs rather than relying on CSS or manually rewriting every account.

Then treat widget selection and widget order as separate concerns. Remove components nobody needs, preserve useful information, use capability checks for privileged content and test the final Dashboard with multiple users and viewport sizes.

TheOneWP Dashboard Columns implements this approach by setting a site-wide column count from one to four and overriding individual Dashboard column preferences, while Disable Dashboard Widgets can handle the separate problem of removing unnecessary widgets for every account.

The result should not merely be a Dashboard that looks identical. It should be a Dashboard whose structure is predictable because the organization has deliberately decided what belongs there and how users are expected to work with it.