A WordPress site can be simple for visitors while still being frustrating for the people who update it. If your team needs to exclude posts from Gutenberg editor, the goal is usually practical: keep a familiar Classic Editor screen for a particular type of content, reduce accidental layout changes, or protect a publishing workflow that staff already understand.
For a disability support provider, website updates may include service notices, community updates, recruitment posts or information for participants and families. These updates need to be clear, accurate and easy to publish. Changing the editing experience without a plan can create avoidable confusion. The right approach depends on which content needs the older editor, who creates it and whether the site uses block-based layouts elsewhere.
What it means to exclude posts from Gutenberg editor
Gutenberg is WordPress’s block editor. It lets users build content from separate blocks for paragraphs, headings, images, buttons, columns and other elements. It is useful when a page needs a flexible layout, but it can feel different from the traditional editor and may not work neatly with older themes, custom fields or established publishing processes.
Excluding posts from Gutenberg means telling WordPress to use the Classic Editor for a selected post type, rather than for the entire website. A post type is a category of content managed separately in WordPress. Standard examples include posts and pages. A website may also use custom post types for staff profiles, events, resources, testimonials or service locations.
This distinction matters. Turning off Gutenberg everywhere may solve one issue while removing useful editing options from pages that rely on blocks. In most cases, it is better to make a narrow change first.
Check which content actually needs the Classic Editor
Before changing any settings, identify the affected content. Ask whether the problem occurs with ordinary blog posts, pages, or a custom post type. Also check whether the issue is a preference, a training gap or a genuine compatibility problem.
For example, a staff member may prefer the Classic Editor because they only need headings, text and an image. That may be solved with a short internal guide or a reusable block pattern. On the other hand, an older custom field setup may stop displaying properly in Gutenberg. That is a stronger reason to exclude that specific post type.
Avoid making changes directly on a live site without testing. If your website includes forms, referral information, participant resources or service updates, an editing change should not interfere with existing content or publishing access. Create a backup first and, where possible, test on a staging copy of the site.
Option 1: Use the Classic Editor plugin settings
The simplest method for many organisations is the Classic Editor plugin. Once installed and activated by an authorised WordPress administrator, it can restore the older editing screen and provide settings for how editors choose between Classic Editor and Gutenberg.
In the WordPress dashboard, go to Settings, then Writing. Depending on the plugin version and site configuration, you can select a default editor and allow users to switch editors for individual pieces of content.
This is a good choice when your team needs flexibility. An administrator can keep Gutenberg available for modern landing pages or visual content, while staff can use the Classic Editor for straightforward news posts. Just activate, configure the preferred editor and test it with a draft post.
The trade-off is that editor choice can create inconsistency. Two people may format similar posts differently, which can make the website harder to maintain. If consistency is more important than flexibility, set one clear internal rule about which editor should be used for each content type.
When this option is the right fit
Use plugin settings when non-technical staff need an easy way to move between editors, or when the site is managed by several people with different confidence levels. It is also helpful when you are transitioning gradually from older content to a block-based workflow.
Keep the plugin and WordPress core updated. Older plugins can create security or compatibility concerns, especially on sites that collect enquiries or display important public information.
Option 2: Disable Gutenberg for one post type with code
If you only want to exclude a particular post type, a small code snippet offers more control. This is often the cleanest choice for websites with custom post types, because it does not force the Classic Editor across every part of the dashboard.
A developer can add the following filter to a child theme’s functions file or, preferably, to a small site-specific plugin:
“`php add_filter( ‘use_block_editor_for_post_type’, function( $use_block_editor, $post_type ) { if ( ‘post’ === $post_type ) { return false; }
return $use_block_editor; }, 10, 2 ); “`
This example disables Gutenberg for standard WordPress posts only. To target a custom post type, replace `’post’` with its registered name, such as `’events’` or `’resources’`. The registered name is not always the same as the label seen in the dashboard, so confirm it before changing the code.
Do not paste this snippet into a theme file unless you understand the update process. Theme updates can overwrite custom changes. A site-specific plugin keeps the functionality separate from the design and is usually easier to maintain.
Test the result before staff use it
After adding the code, create a draft in the selected post type. Confirm that the Classic Editor opens, saved content displays correctly on the front end, featured images still work and any required fields remain available. Then edit an existing item in that post type, but do not change the content until you have confirmed the editor has loaded as expected.
Also check other content types. The point of a targeted filter is that pages and unrelated custom post types should remain unchanged. If Gutenberg disappears everywhere, the condition or code placement may need review.
Option 3: Use a compatibility plugin only when needed
Some websites use plugins designed to disable Gutenberg completely or manage editor behaviour per post type. These can be useful where there is no developer available and the site has a straightforward setup.
However, more plugins are not automatically better. Every plugin should have a clear purpose, be actively maintained and be checked after WordPress updates. Installing multiple editor-management plugins can lead to conflicting settings and confusing results for staff.
Choose one method. If the Classic Editor plugin already provides the control you need, a second plugin is unlikely to improve the setup.
Protect content quality, privacy and publishing access
The editor is only one part of a safe content process. Anyone who publishes information on behalf of a care organisation should understand what can be shared publicly. Participant names, images, personal stories and health-related details require informed permission and careful handling. Changing WordPress editor settings does not change those responsibilities.
Set appropriate user roles as well. Contributors can draft content without publishing it, while editors can review and publish approved updates. This extra review step is valuable for service information, availability notices and community announcements. It helps ensure language remains respectful, accessible and correct before it reaches participants, families and referrers.
A simple publishing checklist can support consistency: use clear headings, check contact details, add alternative text to meaningful images, avoid unnecessary jargon and preview the post on mobile before publishing. These habits matter whether the content is built with blocks or the Classic Editor.
Common issues after excluding Gutenberg
If the Classic Editor does not appear, first clear any website and browser cache, then check for conflicting editor plugins. If custom fields are missing, review the post type registration and the field plugin settings. If an existing post opens with unusual formatting, do not immediately reformat it. Compare the front-end display first, because the editor may be showing legacy HTML that still works correctly for visitors.
When Gutenberg is disabled for a post type, newer block-only features may no longer be available there. That can include block patterns, advanced layouts and certain embedded content options. This is not necessarily a problem. It simply means the Classic Editor should be chosen because it supports a real operational need, not because it is familiar by default.
For many teams, the best setup is not all-or-nothing: use the Classic Editor where stability and a simple workflow matter most, and keep Gutenberg where flexible page design genuinely improves the information people need to find.
