How to Disable Core Blocks in WordPress?

The WordPress Block Editor (Gutenberg) comes packed with dozens of core blocks from Paragraphs and Images to Tables and Buttons. While this flexibility is great for many users, it can also create clutter, or confusion for end client, if certain blocks are not needed for your site.

Disabling unused or unnecessary core blocks:

• Improves block editor performance
• Reduces cognitive load for content editors
• Prevents design inconsistencies
• Can even reduce potential security risks

Whether you’re building a client site or developing a tightly-controlled publishing platform, customizing the available block set is a smart move.

Let me walk through exactly how to remove or disable core blocks in WordPress with a step-by-step code and best practices.

Benefits of Disabling Core Blocks in WordPress

Disabling core blocks isn’t about limiting creativity, it’s about enhancing focus, performance, and control. Whether you’re building a sleek client site, managing an editorial team, or developing a highly optimized theme, limiting unnecessary blocks can be a game-changer.

Let’s explore the key benefits in more detail:

1. Cleaner and Simpler Editor Experience

The WordPress block editor is designed to be flexible, but flexibility without boundaries can lead to chaos. By default, Gutenberg gives you access to dozens of blocks like paragraphs, images, embeds, cover blocks, buttons, widgets, galleries, and more.

If you’re handing a site off to a client or content team, this wide-open interface can become overwhelming. They might not know which blocks to use, which to avoid, or how to maintain a consistent layout.

By disabling unused blocks, you simplify the content creation experience. Editors focus only on what matters like paragraph, heading, image, or custom CTA blocks built for specific purposes, leading to fewer mistakes and faster publishing.

For Example: A real estate agency only needs text, image, and property listing blocks. Disabling all layout and embed blocks keeps the workflow distraction-free.

2. Improved Editor and Site Performance

Each block in WordPress comes with its own scripts, styles, and initialization logic. Even if a block is never used, it still adds weight to the editor by slowing things down and consuming browser memory.

This is especially noticeable when:

• You use block-heavy plugins (Stackable, Spectra, Kadence, etc.)
• You have a slower device or network connection
• Your site has hundreds of pages and custom post types

By disabling blocks you never use, you reduce the load on the block editor, making it faster to open, use, and preview. This leads to happier content editors and smoother admin performance.

For Example: A site running 5 block plugins may register 100+ blocks. Disabling 70% of unused blocks can cut editor load times significantly.

3. Enforced Branding and Design Consistency

Every client project or theme has design guidelines such as specific fonts, colors, spacing, and layout rules. Allowing editors access to blocks like “Columns,” “Cover,” or “Media & Text” without constraints can lead to inconsistent or even broken layouts.

By disabling such blocks and offering curated replacements or patterns, you control the design system. This ensures brand consistency across all pages without needing a designer to approve every post.

For Example: A startup wants all buttons to match its brand color. You disable the default core/button block and provide a custom Brand Button block with locked styles.

4. Reduced Security and Maintenance Risks

Some blocks interact with external services, dynamic data, or shortcodes. Examples include:

• The Embed block for social content
• The Shortcode block (which can run PHP)
• The RSS and Custom HTML blocks

Leaving such blocks available on a live site could pose security or data leakage risks, especially when multiple users have editor access. Disabling these blocks reduces the attack surface and avoids accidental misuse.

For Example: On a membership site, you disable the Custom HTML block to prevent editors from accidentally inserting unsafe scripts.

5. Better Focus and Editorial Workflow

Too many options can lead to decision fatigue. When an editor sees 60+ block choices, it slows down writing, causes hesitation, and increases the likelihood of layout issues.

When you trim the block list to only what’s necessary, you streamline the editorial process. Writers and editors know exactly what to use and when, leading to higher productivity and fewer support requests.

For Example: On a news publishing site, you allow only paragraph, heading, image, and quote blocks. The team can now publish articles in half the time, with zero layout inconsistencies.

6. Smaller CSS/JS Footprint on the Frontend

Some blocks enqueue frontend styles even when not used in content. This bloats your site’s CSS and slows down page loads affecting your Core Web Vitals and overall performance score.

By unregistering or disabling such blocks, especially media-heavy or interactive ones, you keep your site’s output clean and optimized.

For Example: You disable the Gallery and File blocks on a blog that doesn’t use them. This prevents WordPress from loading unnecessary styles on every page.

7. Easier Client Training and Handover

Clients and content creators usually aren’t developers. If they see blocks like Group, Cover, or Media & Text with layered settings and alignment options, they might get confused or make layout-breaking mistakes.

Disabling complex or advanced blocks makes training easier and reduces ongoing support needs.

For Example: Instead of teaching a client how to “nest” blocks properly using Groups, you provide a pre-designed pattern and disable everything else.

Pro Tip: Disabling core blocks in WordPress is one of those small developer decisions that brings massive long-term benefits for performance, usability, branding, and even SEO.

Understanding How WordPress Loads Core Blocks

To truly customize or disable WordPress blocks, it helps to first understand how they’re loaded under the hood. The block editor (also known as Gutenberg) is a dynamic system built primarily with JavaScript and React. Each block, whether it’s a paragraph, image, button, or a fancy pricing table, is a registered component that WordPress loads into the editor environment.

Let’s break down the process:

What Are Core Blocks?

Core blocks are the default set of blocks that ship with WordPress out of the box. These include:

• core/paragraph
• core/heading
• core/image
• core/button
• core/gallery
• core/columns, and many others.

They’re designed to cover most content needs and are part of the @wordpress/block-library package. These blocks are maintained by the WordPress core team and get loaded automatically every time you open the block editor.

You can see them listed inside src directory in the codebase under packages/block-library.

How Are Core Blocks Registered?

Behind the scenes, WordPress uses the JavaScript function registerBlockType() to register every block. These registrations happen during the block editor’s initialization process when you open a post, page, or custom post type in the WordPress admin.

Here’s a simplified flow:

1. PHP Enqueues Scripts
   The WordPress admin loads necessary block scripts like wp-block-library and editor assets when editing content.
2. JavaScript Loads Block Types
   The @wordpress/block-library module runs, and each block is registered using registerBlockType.
3. Block Inserter Is Populated
   Once all block types are registered, they’re displayed in the block inserter panel inside the editor (what you see when clicking the “+” button).
4. Plugins Register Their Own Blocks
   Any active plugin that adds custom blocks (e.g., Kadence, Stackable, ACF Blocks) will register additional blocks using the same method, often under their own namespace.

Understanding Block Namespaces

Every block is identified by a unique name, which follows the format:

namespace/block-name

• Core blocks use the core namespace. Example: core/paragraph
• Plugin blocks use their own namespace. Example: kadence/rowlayout, stackable/imagebox

Knowing this format is important because it’s what you’ll use to disable or unregister specific blocks in your code.

When Are Blocks Loaded?

Blocks are only loaded in the block editor environment, meaning:

• When editing a post/page/CPT that supports the block editor.
• When using full site editing (FSE) in block themes.
• They’re not loaded on the frontend unless a block is actually used in a post (with exceptions for styles/scripts).

Bonus tip: Some blocks enqueue styles on all frontend pages unless optimized via theme settings or plugins.

How Third-Party Plugins Add to the Load

Many popular plugins register dozens of additional blocks, like:

• Spectra – counters, sliders, infoboxes
• Kadence Blocks – rows, tabs, testimonials
• Stackable – pricing tables, cards, image boxes
• Otter Blocks, CoBlocks, etc.

Each plugin follows the same registerBlockType() pattern, meaning more blocks = more editor load time, more memory usage, and more potential confusion for end users.

It’s not uncommon for a WordPress site to have 80–120 total blocks once multiple plugins are installed.

Why This Matters for Disabling Blocks

Knowing how blocks are registered and loaded helps you:

• Target the exact block you want to disable (core/embed, kadence/accordion, etc.)
• Choose whether to block it via PHP (before it’s even loaded) or via JS (after it’s registered)
• Prevent unnecessary assets from being loaded, improving performance
• Create a cleaner, more streamlined editor experience

The WordPress block editor loads core and plugin blocks dynamically via JavaScript using a consistent and extensible system. Once you understand this process, disabling or customizing blocks becomes far more predictable and reliable.

How to Disable Core Blocks Safely Without Breaking Content

Disabling core blocks in WordPress is a smart way to streamline your editor, boost performance, and maintain consistency. But if done carelessly, it can result in broken layouts, frustrated editors, or even lost content.

The good news? WordPress makes it easy to disable blocks safely, without removing any saved content or interfering with how existing pages look on the frontend.

What Happens When You Disable a Block?

Let’s first clarify what “disabling” a block really means:

• It does not delete the block from saved posts or pages.
• It does not affect the frontend rendering of already used blocks.
• It hides the block from the inserter, so users can no longer add it in new content.
• It prevents accidental use of unwanted or unsupported blocks going forward.

In short: Disabling blocks makes them unavailable to insert but doesn’t touch existing content.

Method 1: Disable Blocks via allowed_block_types_all (PHP)

This is the safest and most scalable method, and it’s fully supported by WordPress core. It allows you to create a whitelist of block types that should be available in the editor.

Don’t know what are action and filter hooks in WordPress? Learn more

Basic Example: Allow Only Paragraph and Heading Blocks

add_filter( 'allowed_block_types_all', function( $allowed_blocks, $editor_context ) {
	if ( ! empty( $editor_context->post ) ) {
		return [
			'core/paragraph',
			'core/heading',
		];
	}
	return $allowed_blocks;
}, 10, 2 );

Explanation:

• The filter allowed_block_types_all is triggered every time a post loads in the editor.
• $editor_context->post gives you access to the current post object (useful for scoping).
• You return an array of block names you do want and all others will be hidden.

Conditional Example: Only Disable Gallery Block on Blog Posts

add_filter( 'allowed_block_types_all', function( $allowed_blocks, $editor_context ) {
	if ( $editor_context->post && $editor_context->post->post_type === 'post' ) {
		return array_filter( $allowed_blocks, function( $block ) {
			return $block !== 'core/gallery';
		});
	}
	return $allowed_blocks;
}, 10, 2 );

Use this method when:

• You want a reliable, backend-controlled block whitelist.
• You need to scope allowed blocks per post type, template, or user role.
• You want maximum safety combined with no JS or plugin dependencies.

Method 2: Unregister Core Blocks Using JavaScript (unregisterBlockType)

If you want to dynamically hide blocks on the frontend (e.g. based on user role or screen), you can unregister blocks via JavaScript.

Basic Example: Unregister Quote and Pullquote Blocks

wp.domReady(() => {
	wp.blocks.unregisterBlockType('core/quote');
	wp.blocks.unregisterBlockType('core/pullquote');
});

Add this in a JS file and enqueue it using:

function disable_core_blocks_with_js() {
	wp_enqueue_script(
		'disable-core-blocks',
		get_template_directory_uri() . '/assets/js/disable-blocks.js',
		[ 'wp-blocks', 'wp-dom' ],
		null,
		true
	);
}
add_action( 'enqueue_block_editor_assets', 'disable_core_blocks_with_js' );

✅ Advanced Example: Hide Blocks Only for Non-Admins

wp.domReady(() => {
	if (window.wp?.data?.select('core').getCurrentUser()?.roles?.includes('administrator') === false) {
		wp.blocks.unregisterBlockType('core/embed');
		wp.blocks.unregisterBlockType('core/file');
	}
});

Important Notes:

• unregisterBlockType() only works after blocks are registered, so always wrap in wp.domReady().
• This method doesn’t affect saved content.
• It’s slightly less “strict” than the PHP method since it only hides blocks client-side.

Use this method when:

• You need dynamic behavior based on user roles or editor context.
• You’re working in a theme or plugin with custom admin scripts.
• You want a flexible approach but don’t need strict block enforcement.

Method 3: Use WordPress Plugins to Disable Core Blocks

For those who prefer a no-code approach, there are excellent plugins that give you point-and-click control over block visibility.

1. Block Manager (Built into WordPress Core)

Block Manager is a simple tool available in the block editor itself. You can follow the steps below to access:

• Go to any post/page editor
• Click the three-dot options menu (top-right)
• Click Block Manager
• Uncheck blocks you don’t want available

2. EditorsKit

EditorsKit is a powerful plugin that extends the block editor with advanced visibility settings. You can control block access by user role, device type, or even post condition by making it perfect for complex editorial workflows or multisite setups.

• Advanced control over block visibility, alignment, styling
• Role-based and screen-based rules

🟢 Use this method when:

• You need a quick solution without writing code
• You’re managing a client site with limited technical access
• You want per-user or per-role control without editing functions.php

---

Disable Common Core Blocks (Use Case-Based)

While Gutenberg’s flexibility is a major strength, not all websites need access to all core blocks. In fact, many blocks serve highly specific purposes and can lead to unnecessary clutter or even confusion for editors if they aren’t relevant to the site’s goals.

Here’s a breakdown of commonly disabled blocks based on the type of website you’re building. Use this as a guide but always review project requirements, match the design system, and consider the client’s editorial needs before disabling blocks.

1. Business or Corporate Sites

Corporate websites typically rely on polished, static content: service pages, contact forms, about pages, and testimonials. User-generated content like comments or blog-centric features are often disabled altogether.

Common Blocks to Disable:

• core/comments – Not needed if comments are turned off site-wide.
• core/tag-cloud – Rarely useful for corporate structures and may confuse editors.
• core/rss – Adds unnecessary technical complexity for non-blog sites.
• core/verse – Designed for poetry formatting; irrelevant to most business use cases.

Why disable? These blocks clutter the editor and may confuse non-technical teams, especially when the site is designed to be simple and on-brand.

2. Page Builder-Driven Themes (Custom Headers & Layouts)

Many modern themes and agencies use custom page builders (like Elementor, Divi, Bricks) or even full block-based FSE themes with custom headers and layouts.

In such cases, certain core site-related blocks may conflict with the theme’s architecture and are better removed.

Common Blocks to Disable:

• core/site-title – If the site title is hard-coded in the header or managed via theme settings.
• core/site-logo – If the logo is managed globally, especially through Customizer or theme.json.
• core/navigation – Can conflict with hardcoded or template-based menus, especially in custom-built themes.

Why disable? These blocks often duplicate logic already handled by the theme’s PHP or FSE structure, and may confuse editors who assume dragging a “site title” block will change global settings.

eCommerce Sites

eCommerce websites prioritize conversion flow and product presentation. Most of the site is dynamically generated by WooCommerce templates, not Gutenberg.

Common Blocks to Disable:

• core/archives – Woo templates already manage category views.
• core/latest-posts – Not helpful on product pages unless you also run a blog.
• core/calendar – Rarely adds value on a product-focused storefront.

Why disable? Keeps the focus on products, cart flows, and checkout optimization. Avoids confusion with content elements that don’t belong in a product-centric UI.

Blog-Only or Content-Heavy Sites

If you’re building a blog or magazine, most core blocks are useful, but not all.

Occasionally Disabled Blocks:

• core/button – Replaced by branded/custom call-to-action blocks.
• core/group / core/columns – Can be replaced with locked block patterns for design consistency.
• core/cover – Resource-heavy and often unnecessary unless you use hero sections.

Why disable? Helps maintain consistent layouts and prevent content editors from “designing” their own pages, which may violate branding guidelines.

Mobile-First, Minimalist, or Accessibility-Focused Sites

Some sites focus on performance, speed, and accessibility along with stripping the editor to its essentials is part of that.

Common Blocks to Disable:

• core/media-text – Can be tricky to make responsive and accessible.
• core/embed – External embeds can introduce bloat and privacy concerns.
• core/file – Downloads often better handled via custom fields or plugins.

Why disable? Keeps the frontend clean, fast, and WCAG-compliant. Fewer blocks = fewer chances for layout-breaking mistakes.

Pro Tip: Always Research Before Disabling Blocks

Every website is unique. Before removing blocks:

• Review the site’s content strategy: Does the client blog? Will they need embeds or files?
• Understand your client’s team: Are they technical editors or casual contributors?
• Match the design system: If you use locked patterns or FSE templates, remove conflicting layout blocks.
• Don’t disable blocks mid-build: Make these decisions early, ideally before content creation or content migration starts.

A safe strategy is to test block disabling on staging, watch how editors work, and adjust based on real feedback.

Best Practices for Managing Available Blocks

Disabling unused core blocks is a great way to improve usability, performance, and content quality in WordPress. But doing it without a strategy can backfire especially if it breaks existing layouts or limits content flexibility for editors.

To help you avoid common mistakes, here are the most important best practices to follow when managing the blocks available in the WordPress editor:

1. Start with a Block Audit Before You Disable Anything

Before making changes, audit your site’s existing content and ask these questions:

• Which blocks are used frequently?
• Which blocks are rarely or never used?
• Are any blocks causing design inconsistencies or layout issues?
• Do different post types (e.g., blog posts vs. landing pages) need different sets of blocks?

Use a plugin like Block Catalog or run a script to gather block usage statistics across your site.

Why this matters: Disabling a block that’s actively used in 100+ posts can create confusion or increase content maintenance tasks later.

2. Disable Early in the Project (Ideally During Theme Setup)

The best time to disable blocks is before editors start adding content. If you’re building a new site or redesigning an old one, decide on your allowed block list as part of your design system.

Lock in which blocks:

• Are always allowed (e.g., core/paragraph, core/heading)
• Are allowed only in certain templates or post types
• Are always restricted

Why this matters: This prevents editors from adding blocks that will later be removed, avoiding broken layouts or migration headaches.

3. Use allowed_block_types_all to Whitelist by Context

When you need full control over available blocks, use the allowed_block_types_all PHP filter to return an exact list of blocks.

You can even dynamically change block access based on:

• Post type
• Post template
• Current user role
• Editor screen (e.g., block editor vs. site editor)

Example:

if ( $editor_context->post->post_type === 'product' ) {
    return ['core/paragraph', 'core/image'];
}

Why this matters: It allows granular control and only show blocks where they make sense.

4. Consider the Role and Skill Level of Your Editors

The block editor can be powerful, but it also assumes users have a basic understanding of layout and design. If your users are clients, volunteers, or non-technical editors, simplify their environment.

• Disable layout-heavy blocks like core/group, core/columns, or core/cover
• Replace them with locked block patterns or reusable components
• Use plugins like EditorsKit for role-based block access

Why this matters: A simplified editor helps reduce training time, mistakes, and support requests.

5. Document Your Block Policy for Clients and Teams

If you’re working with a team or delivering a site to a client, don’t just disable blocks silently. Document which blocks are available and why — ideally in a handoff doc, onboarding guide, or the admin dashboard.

Include:

• A list of available blocks
• Why certain blocks are removed
• Examples of how to achieve common layouts using approved blocks

Why this matters: Documentation helps build trust, reduce friction, and ensure everyone on the team uses the editor the right way.

6. Use Locked Patterns to Replace Disabled Blocks

Instead of giving editors full access to every block, provide locked block patterns that use only allowed blocks and enforce consistent design.

For example:

• Instead of letting users build their own pricing tables using columns and buttons, give them a ready-made pricing table pattern using allowed blocks.
• Disable blocks like media-text or cover, and provide visual alternatives using safer combinations.

Why this matters: You maintain design control while still giving users creative flexibility.

---

7. Avoid Disabling Blocks That Are Used in Theme Templates or Patterns

Be careful not to disable blocks that are part of your:

• Header/footer block templates
• Theme.json default templates
• Navigation menus
• Global styles (e.g., site-title, site-logo)

If you do, you might break theme rendering or confuse users who can’t edit global site elements.

Why this matters: Some blocks are essential for FSE themes or dynamic templates.

8. Test Editor Experience on Multiple Roles and Post Types

Once you’ve disabled blocks, log in as:

• Administrator
• Editor
• Contributor, and others

Also test across post types (e.g., pages, posts, custom types) to ensure no essential blocks are missing.

Why this matters: You’ll catch edge cases early and prevent “Why can’t I find the Image block?” support questions.

9. Revisit Block Settings Periodically

As WordPress evolves and new core blocks are added, revisit your block management decisions periodically especially after:

• A major WordPress update (e.g., 6.5, 6.6)
• A plugin update that adds new blocks
• A redesign or content strategy shift

Update your allowed_block_types_all list or JavaScript logic accordingly.

Why this matters: Keeping your editor clean is a continuous process, not a one-time task.

Final Tip: Don’t Blindly Copy-Paste Disable Lists

There are dozens of tutorials listing “blocks you should disable,” but every website is different. A marketing site has different needs than a membership portal or a non-profit blog.

Match your block strategy to:

• Content structure
• Branding goals
• Editor skills
• Site performance needs
• And most importantly: your client’s or team’s real-world workflows

Frequently Asked Questions (FAQs)

Conclusion

Building a WordPress site is easy, but ignoring best practices can quickly lead to a cluttered editor, inconsistent designs, and performance issues that cost time and money.

Disabling unnecessary core blocks is a simple yet powerful way to streamline the editing experience, improve speed, and maintain branding consistency. Whether you’re working with clients or managing a large team, start by disabling what you don’t need, test thoroughly, and tailor the editor to your actual use case.

A cleaner block editor leads to faster content creation, fewer mistakes, and a better website overall.