RedirectNest Free: When a Restored Page Still Redirects

If a restored WordPress page still sends visitors to its former replacement, check for an obsolete exact redirect. In RedirectNest Free, record the rule and starting behavior, then test a reversible pause—not another redirect.

A local match does not prove which layer served a public redirect. Keep the rule paused as the repair only after fresh public checks reach the approved restored content and the former destination remains independently accessible.

Confirm the page should serve at its original address

This guide covers the reviewed native-account Free 1.1.2 release, requiring WordPress 6.7 or later and PHP 8.1 or later. Pro is not required. You need appropriate site permissions. On multisite, work within the affected site; sites are handled separately.

Confirm the restored page’s published permalink, visibility and approved content. An editor preview does not establish that signed-out visitors can access it. If the page is private, unpublished or restored at a different address, resolve that through WordPress before changing routing.

If a menu or other controlled link points to the wrong address, correct that source link instead. This repairs the placement, not an obsolete redirect encountered through existing bookmarks.

Capture the candidate rule and public baseline

Copy the full failing URL from the actual link or bookmark. Preserve its hostname, path spelling, trailing slash and query string.

Search the saved exact redirects for the original source path. Inspect the candidate’s destination, response code and current state, then run the local matching test for the failing input. Record the input and reported outcome; a similar-looking source is not enough.

If no corresponding rule is found, or the local test does not select it, leave the rules unchanged. Capture the public baseline described below and give that evidence to the site maintainer to investigate further.

Local matching makes no external HTTP requests and cannot prove public availability or content relevance. The local URL-maintenance documentation explains this boundary. Available URL-change and removed/restored-content history can support the diagnosis, but is not a complete account of earlier changes.

Export the existing rules. Separately record the candidate’s identifying details, source, destination, response code, active or paused state, and other saved settings. Name someone authorized to restore that state if necessary.

Capture the public baseline before editing:

• Open browser network tools in a signed-out session. Retain the request log across navigation and disable browser caching for the test, then visit the original URL.
• Record the initial response and redirect sequence, followed by the final URL and visible content.
• Save the date, time and test method. If you cannot capture the sequence, ask the site maintainer to do so.

Disabling browser caching helps distinguish stored browser behavior from a new response. It does not establish that a content delivery network (CDN) or server cache has been bypassed.

Pause one rule as a reversible test

The content owner’s approval, a corresponding local match and a public redirect to the same destination can justify a controlled pause. They support the diagnosis but do not prove which layer generated the public redirect.

Pause only that exact rule rather than deleting it. Keep the export and recorded settings available for recovery. Restoring that rule’s previous state is narrower than blindly reimporting unrelated settings.

Do not deactivate the whole plugin, bulk-pause neighboring rules or redirect the former destination back to the restored page. Those changes widen the impact and obscure the diagnosis.

Pausing does not restore missing content, publish a private page, clear caches or control redirects implemented elsewhere. Fresh public checks are still required.

Worked example: workshops return to their old URL

This example is entirely hypothetical. Assume both pages are approved for public access on the same site. These outcomes illustrate a completed record; they are not observed product-test results or predictions for your site.

• Before: An active exact rule sends /services/workshops/ to /services/ with a 301 permanent redirect. The local test selects that rule. A public request returns the 301 and lands on the general services page, despite the workshops page having been republished.
• After the controlled pause: The repeated local test no longer reports the obsolete diversion. A fresh public request returns 200, a successful response, at /services/workshops/ and displays the approved workshop content.
• Independent destination check: A direct request to /services/ still returns 200 and displays the general services content.

The intended repair withdraws the obsolete routing decision without changing the former destination. In a real record, attach timestamps and request evidence to each observation.

Repeat the checks and close or escalate

Repeat the same local input and public-request method after pausing. Test relevant query-bearing or alternate links separately. An approved canonical redirect, such as hostname normalization, may be acceptable if it ends at the intended restored page. A successful response code alone is not enough; inspect the content.

Use discrepancies to choose the next investigation:

• The paused rule still appears responsible locally: Recheck the affected site, saved state and exact test input before making another change.
• Another rule matches locally: Review its purpose and scope separately. Do not assume it is also obsolete.
• Local matching stops reporting the diversion, but fresh public requests still redirect: Record the repair as unresolved. Ask the responsible administrator to investigate CDN, server, cache or other-component routing.

Requests handled entirely outside WordPress are outside local plugin handling. Do not keep changing its rules to compensate for behavior at another layer.

Finish the before-and-after record with these observable checks:

Working checklist

Tick each step as you go. Your choices are not saved or sent.

• Save the original URL, intended content, rule settings, export and dated local/public baseline.
• Record the paused state and repeated local result, including any other match.
• Save dated public results for the original URL and relevant variants, including the response sequence, final URL and visible content.
• Record a direct public visit to the former destination and confirm its intended content remains accessible.
• Mark the result repaired or unresolved, and name the owner of any further investigation or recovery decision.

Retain the pause as the repair when both public journeys pass. Otherwise, hand the exact URL, response sequence, local results and timestamps to a named owner, who should decide whether to restore the recorded rule state while the unresolved cause is investigated.