SleekView reads wp_ilj_linkindex for the resolved insertions with source, target, and keyword columns, and wp_postmeta filtered on the ilj_linkdefinition key for the keyword catalog. Both follow the install's WordPress prefix and live alongside the core tables.

No. The matcher, the cache rebuild, the per-post limits, and the actual link insertion all stay inside Internal Link Juicer. SleekView only reads from the index table and the postmeta. Changing a keyword definition still happens in the ILJ meta box.

Yes. The donut groups by source post type from the join to wp_posts. Any card on the view can be filtered to a single post type as well, so a site that uses ILJ only for the blog can hide page-based insertions completely.

Deactivation leaves the data. Uninstall with the plugin's uninstall hook removes wp_ilj_linkindex. SleekView reads whatever is currently in the table at query time, so if the index is wiped the dashboard returns zero until ILJ rebuilds it.

Yes. A Table view alongside the chart view shows the per-row data: source post, target post, keyword. The chart dashboard tells the team where to look, and the table answers the per-keyword drill-down without leaving WordPress.

Yes if the free version writes to wp_ilj_linkindex. The Pro version adds richer matching options, but the data shape SleekView reads is the same. Pro-only fields show up automatically if they are added to the index table by a future release.

The reports tab is per-post. SleekView is corpus-wide. The two answer different questions. Editors keep using the reports tab to debug a single post. SEO leads use the chart view to audit the link graph across thousands of posts in one screen.

The link index is typically smaller than wp_posts. Aggregations on keyword and source post type are indexed and return in milliseconds. SleekView caches results between views and only re-runs the query on a refresh or a filter change, so the impact on the admin is negligible.