EffortLess Smart Page Redirects

Description

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 another site it applies to the content with the same numeric ID as the selected page, and if no content there has that ID, to the content with the same slug (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

When a visitor opens a page, the plugin looks for an applicable rule in two passes:

1. By page ID. A rule applies if the content being viewed has the ID selected in the rule.
2. By page slug. Only if no rule matched by ID, a rule applies if the content being viewed has the same slug as the page selected in that rule.

The ID pass always wins, so on a single site nothing changes. The slug pass matters on multisite, where a network-wide rule created on one site can now also apply on sites where the corresponding page has a different ID but the same slug. It also keeps a rule working if its target page was deleted and recreated under the same slug.

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 is matched by ID before it is matched by slug. If a site has unrelated content at the same numeric ID as the rule’s target page, that content is what gets redirected on that site.
• 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, and when the slug of any content changes — on multisite this applies to every site of the network, so a network-wide rule takes effect everywhere immediately.
• 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.

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