Page builders earned their place for a reason: they let small teams ship pages without writing code. But the bill arrives later. Markup three times heavier than it needs to be, accessibility quirks you can’t reach, licence dependencies, and an editing experience that drifts further from WordPress core with every release.
The cost shows up in three places
- Performance. Builder pages routinely carry hundreds of kilobytes of CSS and JavaScript the page never uses. Core Web Vitals notice, and so do users on hall Wi-Fi.
- Accessibility. When the markup is generated by a third party, fixing a contrast issue or a focus trap means fighting the tool rather than editing the page.
- Continuity. Staff change. A site only the original builder-owner understands is a risk every research office recognises.
What conversion actually looks like
A page-builder-to-Gutenberg conversion is not a redesign. The content, structure, and design language stay; the implementation changes underneath. Each template is rebuilt from native blocks — groups, columns, headings, queries — so the site edits in the standard WordPress editor with nothing extra installed.
The result is a lighter site that any future member of staff can edit on day one, and that upgrades with WordPress itself rather than against it. That is the property universities should be optimising for: not how quickly the site was assembled, but how long it stays editable.
A conversion, step by step
A typical university conversion runs in five stages. First, an inventory: every template, every one-off layout, every shortcode the builder injected — most estates are smaller than they look once duplicates are counted. Second, a pattern library: the recurring sections (hero, card grid, people list, accordion, call-to-action) rebuilt once as native block patterns, reviewed against the brand. Third, template migration: page by page, content is moved into the new patterns — usually mechanical, occasionally an opportunity to retire pages nobody can defend. Fourth, a parallel-running period where editors work in the new system on a staging copy and the rough edges get filed. Fifth, cutover with redirects, and the builder licence quietly lapses.
Timescales depend on template count rather than page count. A departmental site with eight templates converts in weeks; a central site with sixty takes a term. Either way the work is front-loaded: once the pattern library exists, each further template gets cheaper.
What to check before you commit
- Export a representative page and look at the markup. If you can’t read it, neither can a screen reader.
- Run your five most-visited pages through PageSpeed Insights and keep the report — it makes a satisfying before/after.
- List every builder add-on in use. Each one needs a native equivalent, a replacement, or an honest decision to drop it.
- Ask who edits the site today and watch them work for twenty minutes. The new system has to beat that experience, not just match it.
The end state is worth restating: a faster site, an editor any new colleague already knows, and one fewer subscription standing between your institution and its own website.
