Block themes and what hosts see in tickets

Full site editing and block themes have changed how many WordPress sites are built. The ticket patterns have changed with them.

New ticket types

• Layout shifts or missing styles after a theme or WordPress update.
• Confusion between theme.json settings and custom CSS.
• Performance issues caused by loading large numbers of block styles.
• Caching plugins that need different exclusions for block-based templates.

Classic themes produced a familiar set of problems. Block themes produce a different familiar set. Neither is inherently harder; the knowledge required of support staff simply shifted.

What still helps

• A caching layer that understands WordPress (LiteSpeed Cache remains effective when configured for the site).
• Staging so that theme and core updates can be tested.
• Avoiding the temptation to install every block library that looks useful.

Customers who treat the site editor as a design tool and keep the plugin list intentional open fewer emergency tickets. Customers who mix multiple page builders, block libraries, and custom code on top of a block theme tend to open more.

Host perspective

We see both classic and block themes daily. The successful sites in either model share the same traits: limited plugin surface, tested updates, and caching that matches the stack. The theme architecture matters less than those operational habits.

---