Starting a website?

Purpose-Built Templates

ZU2B Blueprints

Business in a Box

Reference

ZU2B Pulse™

See what visitors experience before they leave — paste any public URL and get a plain-English performance report in seconds.

Scan Your URL Free
FAQ • Support

When the Site Editor Says “Full Width” But the Live Page Disagrees

Field Note #125
🔬 Generalized 🔴 Advanced ⏱ 30 Minutes ✓ Observation from Experience
You inspect a container in DevTools, add a bright outline to see its true boundaries, and it stretches edge to edge. Confirmed: full width. Except the actual public page — the one your visitors see — still shows that same container sitting narrow and off-center.
You didn’t imagine the full-width outline. It was real. It just wasn’t measuring the thing you thought it was measuring.

What’s actually happening
If you ran that inspection test inside wp-admin, in the Site Editor’s own preview canvas, you were looking at the editor’s rendering of the block — not the theme’s actual front-end CSS. The Site Editor applies its own layout-assist styling to make editing easier, and that styling doesn’t always reproduce a block’s real behavior once it’s rendered by your theme on the public page.
The specific trap: a Group or Row block’s Width setting in the block panel can be set to “Fit” (fit contents) instead of “Grow” (fill available space). In the Site Editor, that block can still visually appear to span the full canvas. On the live front end, “Fit” is respected literally — the container only takes up as much horizontal space as its content needs, which is often much narrower than the viewport, and then sits wherever its parent’s alignment puts it (frequently left-anchored, not centered).

How to tell the difference
Don’t trust an inspection done inside wp-admin/the Site Editor as proof of front-end behavior. Open the actual public URL in a separate tab, inspect there, and compare. If the “full width, centered” result only shows up in the editor and disappears on the real page, the block’s own Width setting — not your CSS — is the thing to check next.
While you’re in there: select the container block in question and look at its Block settings → Dimensions → Width control. Fit, Grow, and Fixed produce meaningfully different real-world results, and the difference is invisible in the editor canvas far more often than it should be.

The fix
Either:
Change the block’s Width setting from Fit to Grow, if you want it to genuinely fill its parent — the simplest fix, but double-check it doesn’t change desktop layout in a way you didn’t intend.
Or, if you only want the behavior different on mobile/narrow screens, leave the block setting alone and force it with a scoped CSS override instead:
@media (max-width: 600px) { .wp-block-group.is-layout-constrained:has(.my-target-content) { width: 100% !important; max-width: 100% !important; } }
Using :has() to target the container by what it contains (rather than WordPress’s auto-generated wp-container-core-group-is-layout-XXXXXXXX hash class) keeps the rule working even if the block gets re-saved and WordPress regenerates that hash.

How to avoid it next time
Any time a layout looks right in the block editor and wrong on the live site, assume the editor’s canvas is the unreliable witness, not your CSS. Reproduce the problem on the actual public URL before writing a single line of override code.

Tagged in :

More from the field