EffortLess Smart Page Redirects lets you send visitors of a specific WordPress page to another URL. Each redirect is stored as its own “Redirect Rule”, so you can add, edit, disable (by moving the rule to draft) or delete redirects without touching theme files or the .htaccess file.

Two redirect modes are available per rule:

Immediate redirect (default). The page never renders; WordPress sends a 301 Moved Permanently response to the destination URL.
Delayed redirect (“Analytics-Safe Redirect”). The page starts loading, a full-screen overlay with a loading spinner is shown, and the browser is sent to the destination after a delay you choose (0.5 to 10 seconds). Because the page is actually loaded, analytics scripts that run on it — such as Matomo, Google Analytics 4 or Google Tag Manager — have time to fire and record the pageview before the visitor leaves.

The delayed mode can use either a <meta http-equiv="refresh"> tag or a JavaScript setTimeout() call, selectable per rule.

What each setting does

Every Redirect Rule has the following fields:

Page to Redirect — the published page whose visitors will be redirected. The dropdown lists your pages with their IDs.
Destination URL — the full target URL, including the https:// scheme. It may point to another page on your site or to an external address.
Network Wide (multisite only) — when checked, the rule is also evaluated on the other sites of the network. On those sites it applies to the content whose slug matches the slug of the selected page (see “How a rule is matched” below).
Analytics-Safe Redirect — unchecked means an immediate 301; checked switches the rule to the delayed mode and reveals the two settings below.
Delay Method — Meta Refresh (works without JavaScript) or JavaScript.
Delay (seconds) — how long to wait before leaving the page, between 0.5 and 10 seconds. Between 1.5 and 3 seconds is usually enough for a tracking script to send its request.

How a rule is matched

How a rule is matched depends on where it was created, because page IDs are per site: every site of a network has its own set of pages numbered from 1, so the ID 42 refers to different content on every site.

On the site where the rule was created, the rule applies to the content that has the page ID selected in the rule. This is exact and is unaffected by slugs.
On the other sites of a network (only for rules with Network Wide checked), the rule applies to the content whose slug matches the slug of the page selected in the rule. The rule’s page ID is ignored on those sites, because it does not identify the same content there.

A site’s own rules are checked first, so a rule created on a site always wins over a network-wide rule inherited from another site for the same content.

A rule stops applying on its own site if its target page is deleted and recreated, because the new page receives a new ID. Re-select the page in the rule when that happens.

Notes and limitations

A rule only takes effect once it is published. Rules kept as drafts are ignored, which is a convenient way to switch a redirect off temporarily.
Only one rule is applied per page; if several published rules point at the same page, the first one found is used.
On multisite, a network-wide rule reaches another site only if that site has content with the same slug as the rule’s target page. If the slug differs there, the rule does not apply on that site.
A rule whose destination is the page it redirects is ignored, so a rule cannot send visitors back to where they already are.
Rules are cached for one hour per site to avoid a database query on every page view. The cache is refreshed when a rule is saved, trashed, restored or deleted — on multisite this applies to every site of the network, so a network-wide rule takes effect everywhere immediately.
On multisite, the network-wide rules of every site are kept in a network option that is rebuilt whenever a rule changes, so displaying a page never queries the other sites of the network.
Redirects are not applied in the admin area or in the block/theme editor preview.
The plugin adds no tracking of its own and sends no data anywhere.

404 handling

The plugin can also redirect requests for addresses that do not exist to an equivalent page, instead of showing the site’s 404 page. This is a separate feature from the redirect rules described above, is configured on its own Settings screen (Redirect Rules Settings), and is off by default.

Enable 404 handling — turns the feature on or off. Off by default; nothing changes on upgrade until this is checked.
Find a matching page first — checked by default once the feature is enabled. When checked, the plugin looks for a published page, post or other public content whose address is the same as, or close to, the requested one, and sends the visitor there. When unchecked, the plugin only looks for an exact address match.
If nothing matches — either “Redirect to the home page” (default) or “Show the 404 page”. Controls what happens when no page is found (or “Find a matching page first” is off and there is no exact match).
Similarity required — a whole number from 50 to 100 (default 80). Only used when “Find a matching page first” is checked. It is the minimum similarity, as a percentage, between the requested address and a candidate page’s address before that page is used. A higher number matches fewer addresses but is less likely to send a visitor to the wrong page.

On a multisite network, each site can either inherit the network-wide default or override it with its own values, using the Settings source choice at the bottom of the site’s Settings screen (“Use the network-wide settings” or “Use the settings on this screen instead”). The network-wide default itself is configured on Network Admin Settings Smart Page Redirects, which offers the same four fields above (without the source choice, since that is a per-site decision).

A request that finds a matching page is sent there with a 301 Moved Permanently response, because it is a genuine equivalent and the link equity of the dead address should transfer to it. A request that falls back to the home page is sent there with a 302 Found response instead: a permanent redirect from an unrelated missing address to the home page is the soft-404 pattern search engines decline to honour, so the fallback is marked temporary.

404 handling: notes and limitations

The setting is off until enabled; nothing changes on upgrade.
Requests for files (.php, .jpg, .css, and similar extensions) are never redirected.
Only published content is matched; drafts and private posts are not considered.
Attachments are excluded from matching.
A resolution is cached for up to 12 hours, and the cache clears when a post is saved or deleted, or when the settings change.
The redirect applies to logged-in users too, so an administrator testing a broken address is redirected like any other visitor.
A page whose own address is the one requested is never used as its own match target, so the feature cannot redirect a page to itself.

Donate

If this plugin is useful to you and you would like to support its maintenance, donations are welcome at https://id7.dev/donate/ , including in Bitcoin (BTC): bc1q8a9a5khvfyxlptfyyrpn2x44a4hq40qxql6tx4