EffortLess Smart Page Redirects

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.

1. In your WordPress admin, go to Plugins → Add New → Upload Plugin and upload the plugin zip file, or copy the effortless-smart-page-redirects folder into /wp-content/plugins/.
2. Activate the plugin through the Plugins menu.
3. A Redirect Rules menu appears in the admin sidebar. Go to Redirect Rules → Add New.
4. Give the rule a title for your own reference (for example "Old pricing page").
5. In the Redirect Settings box, choose the Page to Redirect and type the Destination URL.
6. Leave Analytics-Safe Redirect unchecked for a standard 301 redirect, or check it and set the delay method and delay if you want your analytics to record the visit first.
7. Click Publish. The redirect is active immediately.
8. To turn on 404 handling, go to Redirect Rules → Settings, tick Enable 404 handling, and click Save Changes.

To disable a redirect later, edit the rule and switch it back to draft, or move it to the trash.

1.7.0

• Added: An optional 404 handling setting. A request for an address that does not exist is matched against published content by its slug and, when an equivalent page is found, redirected to it with a 301. Addresses with no match are sent to the home page with a 302
• Added: A Settings screen under Redirect Rules, with a network-wide default on multisite that each site can inherit or override
• Fixed: On a site installed in a subdirectory, the self-redirect loop guard built the "current page" address by passing the raw request path to home_url(), which counted the subdirectory prefix twice (for example a site at example.com/blog requesting /blog/foo produced example.com/blog/blog/foo instead of example.com/blog/foo). This could stop the guard from recognizing a redirect rule that pointed at the very page being viewed, on subdirectory installs only, causing the browser to loop until it reported an error. The address is now built from the site's own host instead, fixing this for both existing redirect rules and the new 404 handler
• Fixed: The "Support the development" donate notice link no longer includes a parameter identifying the site's own home address. The link's utm_source, utm_medium, utm_campaign and version parameters are unchanged
• Changed: Tested up to WordPress 7.1

1.6.11

• Fixed: A network-wide rule reaching another site of the network is now matched on the target page's slug instead of its numeric page ID. Page IDs are per site, so the rule was previously applied to whatever unrelated content happened to carry that number on the other sites, and did not reach the intended page at all
• Fixed: A rule whose destination is the page being redirected is now ignored instead of redirecting to itself until the browser reports too many redirects
• Fixed: Networks with more than 100 sites no longer have the rules of the remaining sites ignored
• Improved: The network-wide rules of the other sites are read from a network option rebuilt when a rule changes, instead of querying every site of the network while a page is being displayed
• Fixed: The active site is restored even if collecting another site's rules fails partway through

1.6.10

• Removed: Rules are matched on the target page ID only again. The slug-based fallback added in 1.6.8 also compared against the network-wide rules of the other sites of a network, so a rule whose target page merely shared a slug with the page being viewed could take over that page
• Fixed: The page ID comparison now casts both sides to an integer, so a rule is matched whether or not the queried post exposes its ID as a string

1.6.9

• Fixed: Immediate (301) rules pointing at a URL on another domain sent the visitor to the site's admin URL instead of the destination, because the destination host was not on the list of hosts WordPress permits redirecting to. The host of the rule being applied is now permitted for that single redirect

1.6.8

• Added: A rule is now also matched on the target page slug when no content matches its page ID, so a network-wide rule works across sites whose page IDs differ
• Fixed: Network-wide rules coming from another site of the network were read against the current site's tables, so their destination URL and options could be missing or wrong
• Fixed: The cached rule list is now refreshed when a rule is trashed, restored or deleted, when a slug changes, and across every site of a network instead of only the site where the rule was saved

1.6.7

• Improved: Rewritten readme with a factual description of the plugin, a description of every setting, and clearer configuration steps
• Improved: Plugin header description reworded without marketing claims

1.6.6

• Fixed: Text Domain now matches the plugin slug (effortless-smart-page-redirects, was singular effortless-smart-page-redirect)

1.6.5

• Fixed: Plugin identifiers now use the elspr_ / ELSPR_ prefix (was espr_), with a one-time automatic migration of existing redirect rules
• Fixed: Version number mismatch between plugin header and code
• Fixed: Inline <script>/<style> tags replaced with properly enqueued assets
• Added: Donate link plugin header and standardized donate notice
• Improved: Tested up to WordPress 7.0

1.6.3

• Fixed: Remaining PHPCS warning on the network-wide rules query
• Improved: Spinner font stack

1.6.2

• Added: Object caching of redirect rules
• Fixed: Sanitization of the destination URL
• Fixed: Script enqueuing with version and footer loading
• Improved: Early exit when the current page has no rule

1.6.1

• Fixed: Typo in save_meta() that prevented rules from being stored
• Improved: Escaping and sanitization
• Changed: The JavaScript redirect now uses wp_add_inline_script()

1.6.0

• Initial release