I had a client once, let’s call her Sarah, who ran a busy WooCommerce shop. She was always running flash sales, and she hated deleting the promotional content every time a promo ended. All she wanted was to hide WordPress blocks until the next sale cycle. Back then I spent more hours digging through database revisions to restore her “lost” content than I did building anything new.
My first move was a custom CSS class. I told her to add “hidden-section” in the block settings and wrote a quick display: none; into the stylesheet. Visually it did the job, and it was still a lazy fix. The browser kept loading the assets, the images and the scripts for every one of those “hidden” blocks. On a site with 20k products, that adds up.
A better way to hide WordPress blocks
WordPress 6.9 finally shipped a native way to hide WordPress blocks without the performance cost, and it goes deeper than a CSS trick. Hide a block in the editor now and it is left out of the rendered HTML on the front end entirely. No extra DOM elements, and no scripts or styles enqueued for content that is not on the page.
The dev notes at make.wordpress.org/core/2025/12/01/ability-to-hide-blocks/ spell out the implementation, and it is built on the standard Block API rather than bolted on beside it. Select a block, open the ellipsis menu, choose “Hide.” From the keyboard it is Ctrl + Shift + H, or Command on a Mac. Hidden blocks get a “Hidden” icon in the List View, which is how you find them again.
You may not want clients holding that particular lever, though. If one of them hides a critical container block or a structural element, you find out about it when your support inbox fills up on a Saturday morning. Visibility is a standard block support flag, so you can opt individual blocks out of the feature with a filter.
function bbioon_disable_block_visibility_support( $metadata ) {
// Disable visibility support for the core/group block to prevent accidents.
if ( isset( $metadata['name'] ) && 'core/group' === $metadata['name'] ) {
$metadata['supports']['visibility'] = false;
}
return $metadata;
}
add_filter( 'block_type_metadata', 'bbioon_disable_block_visibility_support' );I ran this on a staging site yesterday for a client who kept “disappearing” their header rows, and it behaves the way you would hope: the “Hide” option stops appearing in the menu for that block type. That is the aim with client sites, a setup where the easy path is also the safe one, while the tools they actually need stay where they are.
The performance payoff
Until now, hiding a block hid it from the eye but not from the engine. With the way 6.9 handles asset loading, dormant content in a page costs you nothing: if a block is hidden, its assets stay out of the page load. That is how it should have worked from day one.
It gets complicated fast once you start mixing visibility with conditional logic or a heavy layout. If you would rather not spend your week debugging someone else’s mess, drop my team a line. We have probably seen it before.
So where do you land on this: clients managing their own block visibility, or the structural blocks locked down?
