Descripción
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 Permanentlyresponse 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) orJavaScript. - 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.
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
Instalación
- In your WordPress admin, go to Plugins Add New Upload Plugin and upload the plugin zip file, or copy the
effortless-smart-page-redirectsfolder into/wp-content/plugins/. - Activate the plugin through the Plugins menu.
- A Redirect Rules menu appears in the admin sidebar. Go to Redirect Rules Add New.
- Give the rule a title for your own reference (for example “Old pricing page”).
- In the Redirect Settings box, choose the Page to Redirect and type the Destination URL.
- Leave Analytics-Safe Redirect unchecked for a standard
301redirect, or check it and set the delay method and delay if you want your analytics to record the visit first. - Click Publish. The redirect is active immediately.
To disable a redirect later, edit the rule and switch it back to draft, or move it to the trash.
FAQ
-
What is the difference between the two redirect modes?
-
The immediate mode sends a
301 Moved Permanentlyheader before anything is rendered, which is what search engines expect for a permanent move. The delayed mode loads the page first, shows a spinner overlay, and then moves the visitor to the destination. Use the delayed mode when you need scripts on the page — analytics in particular — to run before the visitor leaves. -
Which analytics tools does the delayed mode work with?
-
It is not tied to a specific tool. The plugin simply keeps the visitor on the page for the delay you configure, so any script that is already loaded on that page, including Matomo, Google Analytics 4 and Google Tag Manager, has that time to send its request. Whether a given pageview is recorded depends on how quickly that script loads on your site; increase the delay if visits are missing.
-
Does it support 301 redirects?
-
Yes. Rules with Analytics-Safe Redirect unchecked are sent as
301 Moved Permanentlyviawp_safe_redirect(). The delayed mode is a client-side redirect and does not send a301status. -
Can I redirect to an external site?
-
Yes. Enter the full URL in the Destination URL field.
-
Does it work on multisite?
-
Yes. Rules are created per site, and checking Network Wide makes a rule apply on the other sites of the network as well. On those sites the rule matches content whose slug is the same as the target page’s slug, since page IDs are not shared between sites.
-
Will it slow down my site?
-
The list of published rules is read once and cached for an hour per site, and the check runs only on single pages and posts on the front end. Pages without a matching rule are left untouched.
-
I created a rule but nothing happens
-
Check that the rule is published rather than saved as a draft, that both the page and the destination URL are filled in (the rule is not saved if either is empty), and that you are testing on the front end while not previewing the page from the editor.
Reseñas
No hay reseñas para este plugin.
Colaboradores y desarrolladores
«EffortLess Smart Page Redirects» es un software de código abierto. Las siguientes personas han colaborado con este plugin.
ColaboradoresTraduce «EffortLess Smart Page Redirects» a tu idioma.
¿Interesado en el desarrollo?
Revisa el código , echa un vistazo al repositorio SVN o suscríbete al registro de desarrollo por RSS.
Registro de cambios
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 singulareffortless-smart-page-redirect)
1.6.5
- Fixed: Plugin identifiers now use the
elspr_/ELSPR_prefix (wasespr_), 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