Only WordPress postmeta written by SmartCrawl: _wds_metadesc, _wds_title, _wds_focus-keyword, _wds_meta-robots-noindex, _wds_canonical and related keys, plus standard wp_posts columns. SleekView never re-runs SmartCrawl's analysis or hits any external service.

Most of the meta keys are populated by the free version, which is enough to drive the coverage KPI, the indexable pie, the post-type bar and the per-month area chart. Pro adds extra fields (like schema and additional crawl-scan signals); when Pro is active, SleekView simply exposes those as extra columns the dashboard can chart.

Yes. _wds_meta-robots-noindex is a 1/0 postmeta value, so a Pie or Bar grouped by it shows the split. Useful for confirming that thin-content or pagination noindex policy is actually being applied at the post level.

Yes. Group a Bar card by post_type with a Count aggregation on posts where _wds_metadesc is non-empty, and the chart shows which post types have full coverage and which are silently missing SEO meta. Custom post types are the most common offenders.

Yes. Group by post_date with a Count aggregation on posts that have a _wds_metadesc value, and the Area chart shows whether SEO meta is keeping up with new content or whether the gap is growing every month.

Yes. A filter on _wds_metadesc IS NULL surfaces every post SmartCrawl has not yet written meta for. That filter on top of a post_type bar is the exact list editorial leads want when planning a meta-coverage sprint.

Yes. Any filtered set behind a card exports as CSV with the same columns the audit table would show. Useful for handing a per-post-type gap list to an external editor or for archiving a meta-coverage snapshot before a content audit.

No. SmartCrawl's per-post audit still runs, still reports per-post issues and still writes the same _wds_ keys. SleekView only reads those keys. Both views stay in sync because they share storage; an editor fixing a meta description in SmartCrawl's UI sees the coverage KPI tick up in the SleekView dashboard.