SmartCrawl SEO is WPMU DEV's free-and-Pro SEO suite, and it writes a familiar set of postmeta keys to every post: _wds_metadesc for the meta description, _wds_title for the SEO title, _wds_focus-keyword for the focus keyphrase, _wds_meta-robots-noindex for the indexability flag, and _wds_canonical for canonicals. The plugin's own dashboard renders this as a per-post audit and a per-post health score.

That per-post lens is the right tool when an editor is writing one post. It is the wrong tool when an editorial lead needs to know whether the bottom half of the archive has any meta at all, whether the docs custom post type is silently going to the index with no descriptions, or whether the noindex policy on thin pagination is actually being applied.

SleekView reads the same _wds_ postmeta and renders the audit as a real grid. Each row carries the post title, the post type, the meta description (truncated or empty), the focus keyword, the noindex flag, and the post_date. Saved filters do the rest: a view filtered to _wds_metadesc IS NULL is the coverage gap, a view filtered to _wds_meta-robots-noindex equals 1 is the noindex audit, and a view grouped by post_type surfaces which custom post types are silently missing SEO meta.

SmartCrawl SEO does the per-post work well: focus keyphrase analysis, snippet preview, schema settings, and a per-post health score. But the per-post lens is the wrong one for site-wide audits. An editorial lead does not care whether a single post is missing a meta description; they care whether a hundred posts in the docs custom post type are silently going to the index without any meta.

SleekView reads the _wds_ keys SmartCrawl already writes and renders them as the queryable, filterable grid the per-post screen cannot deliver. Counts, ratios, post-type splits, and a missing-meta queue turn the audit into a real surface. The plugin keeps owning the per-post work; the grid owns the site-wide view.