Changing Crowns

Why Gutenberg Columns Disappear: The Real Cause Is Missing Block CSS

Why Gutenberg Columns Disappear: The Real Cause Is Missing Block CSS

Gutenberg columns collapsing even though your CSS looks fine

If your WordPress Gutenberg columns suddenly start stacking vertically and the layout looks broken, even though your theme CSS has not changed, you are not dealing with a flexbox bug or a theme regression. You are seeing a specific failure mode: Gutenberg block CSS is not loading. On my own site, the HTML was correct, the templates were unchanged, caching was behaving, and yet the columns were gone because wp-block-library CSS was missing.

The symptom: Gutenberg columns stacking vertically overnight

This was the pattern on my production site:

When I inspected the markup, the HTML looked exactly like every “how to use Gutenberg columns” example:

<div class="wp-block-columns is-layout-flex">
    <div class="wp-block-column">...</div>
    <div class="wp-block-column">...</div>
</div>

The class names were right. The structure was right. There were no overrides in the parent theme or child theme. Yet the columns refused to behave like columns.

What I ruled out first

Before blaming WordPress or Gutenberg, I went through the usual debugging checklist developers use when WordPress Gutenberg columns are not working:

None of that made a difference. The markup stayed correct, the layout stayed broken, and the columns stayed stacked vertically.

Where Gutenberg block CSS actually comes from

This is the part that many “Gutenberg columns not displaying correctly” posts skip. When you use block markup like wp-block-columns, you are taking a dependency on a specific CSS file that lives in core:

/wp-includes/css/dist/block-library/style.css

Inside that file is the rule that makes your columns behave like columns:

.wp-block-columns {
    display: flex;
    ...
}

If that CSS does not load, the browser does exactly what you are seeing: it renders the HTML as plain block elements stacked vertically. The HTML is fine, but the layout logic is missing.

Why it worked before and then broke “for no reason”

For a long time, WordPress covered this dependency for you. If you used Gutenberg blocks, one of three things usually happened automatically:

That is why a layout built months ago with Gutenberg column blocks could “just work” without you ever explicitly enqueueing wp-block-library. Somewhere between core updates, performance plugins, and full-page caching, that implicit behavior stopped. The result was simple: WordPress block library CSS stopped being delivered, but your templates kept outputting block markup.

The two remaining root causes once HTML is correct

Once you have confirmed that the HTML is correct and your theme CSS is not fighting you, there are really only two realistic causes left when Gutenberg columns stack vertically:

  1. Block CSS is never being enqueued.
    Something in your stack prevents wp-block-library from registering or outputting. That might be a misconfiguration, an aggressive optimization, or a change in how block assets are detected.
  2. Block CSS is enqueued but stripped after the fact.
    A full-page cache, CDN, or HTML minifier removes the block styles from the final HTML before the browser sees it.

The symptoms are identical in both cases: the browser never receives block-library/style.css, and .wp-block-columns never gets display: flex. Either way, you fix it by treating block CSS as an explicit dependency instead of a side effect.

The deterministic fix: explicitly enqueue Gutenberg block CSS

The cleanest way to stop guessing is to force-load the CSS that Gutenberg columns require. In my case, I added exactly one action at the very top of functions.php, immediately after the opening <?php tag:

add_action( 'wp_enqueue_scripts', function () {
    wp_enqueue_style(
        'cc-force-block-library',
        includes_url( 'css/dist/block-library/style.min.css' ),
        [],
        null
    );
}, 0 );

This single hook does a lot of work:

This is not a hack. It is a deliberate decision to make an implicit dependency explicit so your layout survives core changes, caching, and future optimization passes.

What should happen immediately after you add the enqueue

After deploying the enqueue and clearing caches, the verification steps are straightforward:

If the file does not appear in the Network tab, something upstream is still blocking or stripping it. In that case, you know the problem is in the HTML output or optimization path, not in your theme CSS or templates.

Why this is not a “bad cache” or “broken theme” problem

It is easy to blame caching when a WordPress Gutenberg layout breaks after enabling full-page cache. In my case, caching did not corrupt HTML, rewrite CSS, or change any flexbox rules. It simply made the output deterministic enough that the absence of block CSS became obvious.

Classic stale HTML issues look like this:

That is not what was happening here. The HTML was already correct. The problem was that the browser never received the CSS that makes block layouts behave. Once I explicitly enqueued block-library/style.min.css, the columns started working again without touching the cache configuration.

A concise debugging checklist for broken Gutenberg columns

If you are staring at WordPress Gutenberg columns not working, here is the short checklist I wish I had at the beginning:

  1. View source and confirm that your columns use wp-block-columns and wp-block-column with the expected structure.
  2. Search your theme for any custom rules that directly target those classes and temporarily remove or comment them out.
  3. Open DevTools → Network → CSS and look specifically for block-library/style.css or block-library/style.min.css.
  4. If that file is missing, add the explicit wp_enqueue_style hook shown above and redeploy.

By the time you finish that list, you will know whether you have a missing dependency or a deeper platform problem. In most real-world cases, the missing dependency is the entire story.

Takeaways for engineers building cached WordPress sites

The deeper lesson from this case study is simple: if you use Gutenberg block markup outside the editor, especially inside custom PHP templates on a heavily cached site, treat Gutenberg block CSS not loading as a first-class dependency risk. Do not assume WordPress will always inject wp-block-library for you.

Making that dependency explicit with a small, well-scoped enqueue gives you:

Once I stopped treating the block library as “magic CSS” and started treating it like any other required asset, the mystery of disappearing Gutenberg columns disappeared with it. The fix was a single enqueue, and the real win was understanding why the layout failed so that assumption never quietly breaks production again.