SleekView for Redirection
Redirection writes every rule to wp_redirection_items, every matched hit to wp_redirection_logs, and every miss to wp_redirection_404. SleekView reads those tables and renders the redirect set as a sortable, filterable grid.
♾️ Lifetime License available
Three admin tabs collapse into one queryable grid
Redirection is the most widely installed redirect plugin in the WordPress directory, and its schema reflects how mature it is: wp_redirection_items for the rules (url, action_code, match_type, regex, last_count, last_access, status, group_id), wp_redirection_groups for the buckets, wp_redirection_logs for matched hits, and wp_redirection_404 for unmatched paths. Each table lives behind a separate tab in Tools, Redirection.
That tabbed model is the right shape when an SEO lead is adding a single rule. It is the wrong shape the moment the question becomes site-wide: which rules carry traffic, which group has the most 302s left over from the last migration, what does the 404 cadence look like since launch. Answering today means flipping between three tabs and reconstructing the picture in a notebook.
SleekView reads wp_redirection_items, joins last_count and last_access, and renders the redirect set as one grid. Each row carries the source URL, the destination, the action code, the group, the last_access timestamp, and the hit count. Saved filters carry the rest: a view filtered to action_code equals 302 surfaces the legacy temporary redirects that should have been 301s years ago, a view scoped to group_id equals shop isolates the e-commerce redirects from editorial, and a view sorted by last_count descending is the migration cleanup-priority list.
Workflow
From three tabs to one redirect grid
Read the rule tables
Map the columns
Save the audit views
Drill into a rule
Sample columns
A typical Redirection table view
wp_redirection_items joined to wp_redirection_groups and wp_redirection_logs
| Source | Destination | Code | Group | Last hit | Hits |
|---|---|---|---|---|---|
| /old-pricing | /pricing | 301 | Marketing | 2026-05-15 09:42 | 4,812 |
| /blog/launch-2019 | /blog | 302 | Editorial | 2026-05-14 11:18 | 1,204 |
| /shop/old-sku-1842 | /shop | 301 | Shop | 2026-05-15 06:11 | 318 |
| /legacy/api-docs | — | 410 | Docs | 2026-05-15 10:02 | 47 |
| /old-author/jane | /author/jane | 301 | Editorial | 2025-12-04 08:11 | 0 |
Comparison
Default Redirection admin vs SleekView
Default Redirection
- Rules, logs, and 404s live in three separate tabs
- No combined view of rule plus hit count plus last access
- Cannot save a filter for legacy 302s or dead-weight rules
- Dead-weight rules (zero hits in 90 days) blend into the rule list
- 404 log is paginated, not filterable into a real cleanup queue
SleekView
- One row per rule with destination, code, group, last hit, and hit count
- Filter by action_code, group_id, status, regex, or last_access window
- Saved view for legacy 302s and another for zero-hit rules
- Spot rules that have not matched a request in 90 days
- Click through to the rule in Redirection's editor or to the 404 log
Features
What SleekView gives you for Redirection
Rule observability
Confirm which rules actually carry traffic and which are dead weight, using the same last_count column Redirection already maintains. No guessing on a cleanup sprint.
Group isolation
Filter the grid to one group (shop, editorial, docs) to audit a single section in isolation. Useful when one section is being migrated and the rest should not be in the view.
404 cleanup queue
A saved view of wp_redirection_404 in the last 7 days is the actual cleanup queue. The 404 tab becomes the queryable feed the migration lead has been asking for.
Audience
Who uses SleekView for Redirection
SEO leads
Sort by hits descending and the top rules are the ones the cleanup decision should respect. The legacy 302 filter shows the historical mistakes worth fixing this quarter.
Migration teams
After a launch, filter wp_redirection_404 to created within the last 14 days. That is the migration cleanup queue; the grid shrinks as new rules catch the legacy paths.
Developers and ops
Filter to regex equals 1 and group_id equals system to audit the regex rules that intercept everything. Greedy patterns become visible without reading every entry.
The bigger picture
Why a tabbed redirect plugin earns a single grid
Redirection has aged into one of the most reliable plugins in the WordPress ecosystem, and that reliability has produced sites with thousands of accumulated rules across years of cleanups. The plugin's three-tab admin is fine for spot edits and weak for the audits that actually matter at scale. Which rules carry traffic, which are dead weight, where is the 404 cadence concentrated, which group has the legacy 302s nobody got around to fixing.
SleekView reads the same four tables Redirection writes and renders the answers as a sortable, filterable, exportable grid. The matching engine, the regex parser, and the import/export stay exactly where John Godley built them. The audit becomes a real surface.
Questions
Common questions about SleekView for Redirection
No. Redirection owns the matching engine, the regex parser, the group ordering, and the HTTP response. SleekView reads from the tables Redirection writes. Disabling SleekView leaves every redirect rule firing exactly as before.
 From wp_redirection_items (rules), wp_redirection_groups (buckets), wp_redirection_logs (matched hits, when logging is enabled), and wp_redirection_404 (unmatched paths, when 404 logging is enabled). No additional logger and no premium add-on is required.
 Yes. group_id is a real filterable column, so isolating shop, editorial, or docs redirects is one click. Useful when a site has separate groups per section and audits happen at the section level.
 Partially. wp_redirection_items is always populated, so the rule, status, group, and last_count columns work regardless of logging. wp_redirection_logs and wp_redirection_404 only fill when their respective logging options are on; with logging off, those columns honestly show empty rather than fabricated numbers.
 Yes. last_access is a column on wp_redirection_items, so a filter on last_access older than 90 days surfaces dead-weight rules. The cleanup sprint can drop them with a defensible record instead of a guess.
 Yes. The plugin writes per-site tables on multisite, and SleekView respects that scope. Each subsite has its own redirect grid, and a network roll-up can aggregate rule counts when one SEO team monitors the whole network.
 No. Only the rows on the current page are queried, and the redirection tables are well indexed by the plugin. A site with thirteen hundred rules queries the same as a site with thirteen because pagination keeps the row count constant.
 Yes. Any filtered view exports to CSV with source, destination, code, group, last_access, and last_count, which is the exact shape a migration contractor or a server-level rules file generator needs to port the set.
 Pricing
More than 1000+
happy customers
Explore our flexible licensing options tailored to your needs. Upgrade your license anytime to access more features, or opt for a lifetime license for ongoing value, including lifetime updates and lifetime support. Our hassle-free upgrade process ensures that our platform can grow with you, starting from whichever plan you choose.
Lifetime ♾️
Most popular
EUR
once
- Unlimited websites
- Lifetime updates
- Lifetime support
...or get the Bundle Deal
and save €250 🎁
The Bundle (unlimited sites)
Pay once, own it forever
Elevate your WordPress site with our exclusive plugin bundle that includes all of our premium plugins in one package. Enjoy lifetime updates and lifetime support. Save significantly compared to buying plugins individually.
What’s included
-
SleekAI
-
SleekByte
-
SleekMotion
-
SleekPixel
-
SleekRank
-
SleekView
€749
Continue to checkout