WPBakery Page Builder stores its layouts inside post_content as shortcodes, with auxiliary state in the _wpb_vc_js_status meta key. The default WordPress Pages screen does not distinguish WPBakery pages from any other page, which is fine on a small site and a real navigation problem on a site with several hundred pages, of which two hundred use WPBakery and a long tail use Gutenberg, classic editor, or some other builder.

SleekView reads the same shortcodes and meta keys WPBakery itself relies on to detect builder content, then exposes pages with WPBakery shortcodes as a focused view. Template, last edited, author, and status all appear as sortable columns. Inline editing covers the standard WordPress fields, slug, parent, status, menu order, so renaming a page or reparenting it under a new section does not require opening the WPBakery editor at all.

The most valuable workflow is finding stale layouts. On any WPBakery site older than two years, pages accumulate from one-off campaigns, A/B tests, and seasonal landing pages that never got cleaned up. Filter by last edited under a date threshold and a published status, and the cleanup queue surfaces immediately. Filter by template and the inventory of pages using a deprecated template appears in one shot. Migration-prep teams use the same view to tag pages for rebuild and export the list as their project plan.

WPBakery is one of the longest-running page builders in WordPress, which means most WPBakery sites are old. Old sites accumulate pages: one-off landing pages from campaigns long since archived, A/B test variations whose results were never acted on, seasonal promos that never got unpublished, content from previous agency relationships nobody on the current team built. The default Pages screen does not help with this.

It lists pages with no information about which builder they use, no surface for last edited together with template, and no saved views for an editor who only wants to see the pages they own. Cleanups happen rarely because they are tedious, and the longer the cleanup is deferred the more the inventory drifts from any documented site map. Migration projects make this worse: when a team decides to move off WPBakery, they need an inventory of WPBakery pages first, and producing that inventory by hand on a site with hundreds of pages is a multi-day job.

SleekView treats the page list as data. The cleanup, the inventory, and the migration prep all become saved views over the same dataset.