Rich Table of Contents auto-inserts a TOC into posts when a global setting (enabled post types, heading levels included, minimum heading count) and per-post postmeta overrides combine to a yes. Readers get clean navigation; editorial gets the per-post toggle inside each editor and a global settings screen. Nothing in between exists for a content audit.

SleekView reads the same options row and the per-post overrides, plus a parsed heading index of post_content, and renders the result as a sortable audit table. One row per post, with TOC status (rendered, below threshold, opted out, suppressed), heading count, deepest heading level, post type, author and last modified. Filter to long posts where the TOC is suppressed, scope to docs post types missing a TOC, sort by heading count to find articles that should split a wall of H3s into a real H2 skeleton.

Because the dataset is built from standard WordPress storage plus a parsed heading index, no new tables are involved. The plugin keeps owning TOC rendering and styling; SleekView adds the per-post audit table a global settings screen cannot offer.

Rich Table of Contents quietly inserts navigation into posts when they meet a threshold, which is precisely why teams pick it: the editorial team writes, the plugin handles the TOC. The trade-off is that the same threshold makes coverage invisible. A site can have three hundred long posts, fifty of them shipping without a TOC because a single H2 got dropped to a paragraph during a rewrite, and nobody will notice until a reader complains.

SleekView reads the same settings, the same per-post overrides and the actual heading structure of every post and renders the result as a sortable grid with status, heading count and joined post fields. Filters stack so the long-without-TOC list, the opted-out cohort and the docs-without-coverage rows become one-click views rather than a manual audit. The plugin keeps owning rendering; editorial finally gets the per-post surface a global settings screen cannot offer.