SleekView reads wp_404_logs for captured 404s with url, referrer, and timestamp columns, and wp_404_redirects for the auto-suggested redirects with status and confidence columns. Both tables sit alongside the standard WordPress tables and use the same prefix.

No. The fuzzy matcher, threshold, and queue actions are entirely inside 404 Solution. SleekView only reads the resulting rows. Lowering the matcher confidence still happens in the plugin's settings, and the donut on the dashboard will rebalance on the next refresh.

Yes. wp_404_redirects has a confidence column. A second donut or a histogram on confidence buckets shows where the matcher is least sure. Combined with the auto vs manual mix, it tells the SEO lead whether the threshold is set too aggressively or too conservatively.

404 Solution can prune wp_404_logs on a schedule. SleekView sees only what is currently in the table at query time, so a fresh prune resets the trend area to zero. Raise the retention setting in the plugin or copy rows on a schedule into an archive table that SleekView can also read.

Yes. SleekView views and data sources are per-site by default, so each subsite reads its own wp_404_logs and wp_404_redirects under its own table prefix. The network admin can also build a network-wide source if 404 Solution is run network-activated with shared tables.

Yes. Cards accept a filter on the user-agent or referrer column. Common bot patterns can be excluded so the KPI tracks human-shaped 404 traffic only, which is closer to what the SEO team treats as real link-equity loss.

No. The suggestion queue is where editors approve, reject, or override matches. SleekView is the read-out across thousands of rows. The two work together. The dashboard shows trends and totals, the queue handles individual decisions.

Modern MySQL handles a few hundred thousand rows in either table without trouble. The aggregations SleekView runs are indexed on url, status, and timestamp. If the install logs millions of 404s per month, archiving older rows to a secondary table keeps the live cards fast while the archive still feeds annual reports.