Title: EffortLess Smart Page Redirects
Author: domclic
Published: 11 agosto, 2026
Last modified: 22 agosto, 2026
---
Pesquisar plugins
# EffortLess Smart Page Redirects
Por [domclic](https://profiles.wordpress.org/domclic/)
[Baixar](https://downloads.wordpress.org/plugin/effortless-smart-page-redirects.1.7.0.zip)
* [Detalhes](https://br.wordpress.org/plugins/effortless-smart-page-redirects/#description)
* [Avaliações](https://br.wordpress.org/plugins/effortless-smart-page-redirects/#reviews)
* [Instalação](https://br.wordpress.org/plugins/effortless-smart-page-redirects/#installation)
* [Desenvolvimento](https://br.wordpress.org/plugins/effortless-smart-page-redirects/#developers)
[Suporte](https://wordpress.org/support/plugin/effortless-smart-page-redirects/)
## Descrição
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 `` 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
## Instalação
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.
## Perguntas frequentes
### What is the difference between the two redirect modes?
The immediate mode sends a `301 Moved Permanently` header 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 Permanently`
via `wp_safe_redirect()`. The delayed mode is a client-side redirect and does not
send a `301` status.
### 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.
### I turned on 404 handling but broken addresses still show the 404 page
Check each of the following:
* The setting is enabled on the site you are testing. On a multisite network a
site set to “Inherit from network” (labelled “Use the network-wide settings”)
uses the network setting, not its own.
* The address does not end in a file extension. Requests for files are left alone
on purpose.
* “If nothing matches” is set to “Redirect to the home page” — with “Show the 404
page” selected, only addresses close enough to a real page are redirected.
* The address is not the page’s own address.
## Avaliações
Não há avaliações para este plugin.
## Colaboradores e desenvolvedores
“EffortLess Smart Page Redirects” é um programa de código aberto. As seguintes pessoas
contribuíram para este plugin.
Colaboradores
* [ domclic ](https://profiles.wordpress.org/domclic/)
[Traduzir o “EffortLess Smart Page Redirects” para seu idioma.](https://translate.wordpress.org/projects/wp-plugins/effortless-smart-page-redirects)
### Interessado no desenvolvimento?
[Navegue pelo código](https://plugins.trac.wordpress.org/browser/effortless-smart-page-redirects/),
consulte o [repositório SVN](https://plugins.svn.wordpress.org/effortless-smart-page-redirects/)
ou assine o [registro de desenvolvimento](https://plugins.trac.wordpress.org/log/effortless-smart-page-redirects/)
por [RSS](https://plugins.trac.wordpress.org/log/effortless-smart-page-redirects/?limit=100&mode=stop_on_copy&format=rss).
## Registro de alterações
#### 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 `