Page Links To stores its target URL in the _links_to postmeta key and an optional link target attribute in _links_to_target. SleekView reads both. Any custom variants the site has added are picked up automatically as additional columns on the data source.

No. The redirect itself runs on the WordPress permalink hook before any chart query happens. SleekView only reads from wp_postmeta after the fact. Disabling SleekView changes nothing about how Page Links To handles requests on the front end.

Yes. The donut groups by host parsed from the meta_value column. A computed column can normalize subdomains so youtube.com and m.youtube.com count together, or so all partner subdomains roll up under one label for cleaner audits.

By default cards filter wp_posts.post_status to publish only, so drafts do not inflate the KPI. The filter is per-card, so a separate view can include drafts for editors planning future off-site redirects before publishing.

Yes. Cards accept a filter on wp_posts.post_type. A site that uses Page Links To mainly for a custom post type, say sponsored or partner, can pin a separate view scoped to that type without blog posts diluting the read-out.

When _links_to is removed from a post, the row disappears from the join, so the KPI drops on the next query. The trend area still reflects the deletion as a movement in the post_modified date, which is useful for audit trail purposes even after the meta has been cleared.

Cards aggregate. Individual post rows are not exposed unless a separate Table view is granted to the role. The KPI and donut tell editors how many redirects exist and where they point, without listing every URL by hand.

Yes. SleekView can read several redirect plugin tables on the same dashboard. A site running Page Links To plus Redirection can show the postmeta-based redirects on one card and the table-based ones on another, painting a complete picture of how requests get rerouted.