Dragon Redirect Manager

Redirects with an indexed hot path, plus a 404 triage inbox that filters out bot noise so you only see the dead ends that matter.

#Requirements

WordPress 6.2+, PHP 8.0+. Every screen, email and notice is translatable; every screen uses the dragon-redirect-manager text domain.

#Redirect rules

Create rules under Redirects → Add New:

• Exact - matches one normalized path via an indexed hash lookup, so redirect checks add no measurable overhead to normal traffic. The path is compared without its query string and without a trailing slash, so /page, /page/ and /page?utm=x are the same rule; a second exact rule for the same path is refused and you are pointed at the existing one.
• Prefix - matches a path and everything under it, on a whole-segment basis: /news covers /news and /news/2026/story but not /newsletter. The rest of the path is carried over to the target, joined with a single slash (/old → /new/ sends /old/page to /new/page, and /old/page/ to /new/page/). Like exact rules, a prefix rule does not carry the request's query string over to the target. Prefixes are compared the same way request paths are, so /café matches the encoded /caf%C3%A9/... and a prefix typed without a leading slash is saved with one.
• Regex - full pattern matching with capture groups, named groups and lookbehinds (^/product-(\d+)$ → /shop/item-$1). A pattern is matched against the request path without its trailing slash and without the query string, percent-encoded (/caf%C3%A9, not /café). Patterns are validated against catastrophic backtracking before saving. With an absolute target, visitors only ever leave your site for the host written in the rule: a captured group cannot change the host (https://$1.example.com/ keeps visitors on your site), so put a slash before it (https://shop.example.com/$1).
• Status codes: 301, 302, 307, 308, or 410 (Gone) for content that is deliberately removed. A 410 rule needs no target; leave it empty (in the form, a CSV row, or wp drm add /old-page --code=410).
• Rules can be toggled Active/Inactive without deleting, and hits are counted per rule.
• Loop detection refuses rules that would redirect to themselves, directly or through an existing chain. Only same-site targets count: /pricing → https://shop.example.net/pricing is a valid cross-site redirect.

#The 404 Monitor

Redirects → 404 Monitor is a triage inbox, not a firehose: hits are grouped per URL, counted, and scored for bot likelihood - scanner/exploit probes (/wp-content/backup.sql, .env and friends) are hidden by default. For a real 404, Create redirect pre-fills the source so a typo'd inbound link is fixed in seconds. Ignore dismisses a URL you don't care about. A URL you fixed with a redirect that 404s again (for example because the redirect was deleted or disabled) reopens automatically; ignored URLs stay ignored. Rows are purged automatically after your retention period. Fixed rows are kept as a record; past the retention period their referrer, user agent and IP hash are cleared, unless the retention filter below keeps fixed rows forever or longer. Developers can set a different window per status with the dragonredirectmanager_log_retention_days filter ($days, $status; return 0 to never purge that status; for fixed it sets how long fixed rows keep their visitor details); without it, your retention setting applies to every status.

#Fuzzy typo correction (free since 1.0.3)

When enabled in Settings, a 404 whose URL is a confident close match to exactly one published post or page is 301-redirected there automatically. Uncertain matches are always left to stand - nothing is ever guessed to the homepage. The confidence threshold is adjustable (higher = stricter).

#Slug-change auto-redirects

Renaming a published post's slug automatically creates a redirect from the old URL, so inbound links never break. If you later rename it back, the earlier redirect away from the restored URL is switched off (and the reverse redirect added) so the post never redirects to itself, even after several renames. Only redirects that slug tracking created (note "auto: slug change") are switched off this way; a redirect you set up yourself or imported on the new path is left alone, with or without a note.

#Import & export

CSV export of your full rule set, CSV import, and one-click importers for Redirection, Simple 301 Redirects and Quick Page/Post Redirect Plugin. The CSV columns are source,target,type,code,active,note; active (1/0) and note are optional on import, so older four-column files still import with every rule active. A row with no target is skipped, and the import result says how many, unless its code is 410. The Redirection importer reads the JSON file from Redirection's Import/Export screen; it keeps regex rules as regex and disabled rules disabled, imports redirect and error (410) rules, and skips and counts conditional, pass-through and random rules.

Preview first. The import form's preview box (ticked by default) runs the import without writing anything and shows a table of every row: the source, target, code, active state and note it would get, and for each skipped row the reason (no target, a condition this plugin cannot apply, a source on another site, a duplicate of an existing rule or of another row, a loop with an existing rule). One click then imports the rows marked "Will be created". Running an import a second time leaves exact rules that already exist unchanged and counts them in the result. Prefix and regex rules from a CSV or Redirection file are not checked for duplicates, so import those once.

#Quick Page/Post Redirect Plugin (closed on WordPress.org, 14 April 2026)

That plugin kept its redirects in this site's database and leaves them there when it is deleted, so nothing needs to be exported: choose Quick Page/Post Redirect Plugin (this site's stored rules) under Import. The form says how many quick redirects and per-post redirects were found.

Every imported rule comes in disabled, for you to review. That plugin matched addresses in ways exact rules cannot copy faithfully: it tried several spellings of each request, let quick redirects win over per-post ones, ignored letter case by default and added the visitor's query string to the target. So no imported rule redirects anyone until you have looked at it and switched it on. Search the Redirects list for "Quick Page/Post Redirect" to find them; each note says where the rule came from and anything you should know about it. The preview shows the same before anything is written.

What comes across:

• Quick redirects (the request/destination list) become exact rules with code 301, which is what the source plugin always sent. A request stored as a full URL on this site keeps its path; one on another site is skipped, and so is one that only matched with a query string (such as /shop/?cat=1), since a rule here matches the path alone and would catch every request to it. On a subdirectory install the home path is added, since the source plugin matched its requests relative to the home URL.
• Per-post redirects (the box on the edit screen) become exact rules from the post's address with the post's own code (301, 302, 307; 302 when none was set) or the global type override if one was set. A redirect on a post that is not published is skipped: it had no public address. So is one on a site with plain permalinks (/?p=42), for the same query-string reason. The target is read the way the source plugin read it, so a bare www. address, a post number and a bare path all resolve the same way.
• Notes for the review. A rule's note says if it was switched off in the source plugin, if every redirect there was switched off or went to one override URL, if another stored redirect had the same address here, and any setting with no equal here: new window, no follow and rewrite links (which changed how links were rendered, not where visitors went) and meta refresh (which waited and showed a message; it becomes a 302). Site-wide settings are reported in the result.
• Two stored redirects, one address here. Two entries that differ only in letter case were one redirect in the source plugin, which matched any case and used the later entry; only that later one is imported. Two that differ in a trailing slash or encoding (/old and /old/) were separate there but match the same requests here, so the first is imported and the rest are skipped.
• Values the source plugin's forms never saved are refused. A destination or address holding markup, control characters or surrounding spaces, or an address with a fragment (#...), was written some other way (the plugin was closed for a security issue), so it is skipped with a reason rather than cleaned and reinterpreted. Any redirect the source plugin kept on your site that would, as stored here, send visitors to another site is skipped too.
• The source plugin's options and post meta are read only, so you can delete that plugin before or after importing, and its data stays exactly as it was.

#Data & privacy

The 404 monitor records URL, referrer (including links from other sites), user agent and a salted hash of the visitor IP (raw IPs only if you explicitly enable that). Rows auto-purge on your retention schedule (or on per-status windows set through the retention filter; Settings says when an add-on's windows are in effect). Rows marked fixed are kept; past your retention period they keep only the URL, hit count and dates. Uninstalling keeps your rules by default; opt into deletion in Settings.

#Uninstall

Deleting the plugin keeps all its data by default, so a reinstall picks up where you left off. To remove everything on uninstall, tick Delete all data on uninstall in the plugin's settings first (this sets the dragonredirectmanager_delete_data_on_uninstall option).