A nonexistent URL redirects to another WordPress post

Check that the address actually redirects

You open an address that should be unavailable. WordPress displays different content whose address starts with the same characters. The forum describes this with a short address opening a similarly named archive page. The reply distinguishes two possible mechanisms. WordPress may know an old slug associated with content. It may also try to guess a destination when a request produces a 404. Similarity between addresses alone does not establish the cause.

Open browser developer tools and display Network. Enable Preserve log, then reload the original address in a staging session or private window. Identify the first document response. A 301 or 302 response with Location establishes an HTTP redirect. If the initial document returns 200 and the address changes afterward, examine navigation triggered by the page or a script. If the code is 200 and the address stays unchanged, the server may display unexpected content or an error document with a success status. This guide concerns the first case: a measurable public redirect.

Record the first hop, then open the destination. Check that it is accessible and does not redirect to a third address. A protocol or hostname redirect may precede the behavior of interest. Compare paths on the staging domain using the same protocol. Record the final status and resulting content title. A browser may remember a permanent redirect. Measure again in a fresh session and, if possible, with a command that does not retain browser cache.

1. Record the requested path, first status, Location value and final path. Remove sensitive parameters before sharing the record.
2. Open the same path from a public session. Compare with a logged-in session if content has access rules.
3. Check whether another nonexistent URL behaves the same way. If all errors redirect to the homepage, first look for a general rule.

Build four control addresses

In staging, prepare an accessible publication with a distinctive slug, such as fiche-temoin-archive. Check its address in the post list and open it as a visitor. Ensure no published content owns the shorter /fiche-temoin/ path. On a copy used for other tests, also check that this address is not an old slug. Choose a third path unrelated to names used and record a fourth address with an intentional documented redirect. For example, use the confirmed old slug of a post renamed in staging.

Paths in the following block are fictional. Replace the domain and four paths with the copy's, retaining any prefix if WordPress is served from a subdirectory. Run the block in Bash. In PowerShell, run curl.exe for each URL with the same options and use NUL instead of /dev/null. Requests are GETs and the command stops at the first response. Then open the destination separately to record its code and content.

Compare all four results. If the exact path returns 200, the unrelated path returns 404 and the prefix redirects to the exact content, guessing becomes plausible. Always check slug history and existing rules. Behavior depends on permalink rules and the request WordPress understands. A short prefix therefore does not trigger a redirect on every installation. If the exact publication is itself unavailable, first resume diagnosis of that publication.

base='https://recette.example.test'
for chemin in /fiche-temoin/ /fiche-temoin-archive/ /introuvable-71/ /ancien-nom-confirme/; do
  printf '\n%s\n' "$chemin"
  curl --silent --show-error --max-time 15 --dump-header - \
    --output /dev/null --write-out 'code=%{http_code}\n' "$base$chemin"
done

Correct the link source with editorial access

If the short link appears in a menu, block or post and should open the existing publication, edit its source. In a block theme, find the link under Appearance > Editor, then in its navigation or template. For a classic menu, use Appearance > Menus when available. In content, select the link in the editor and choose the exact address. Then open the linking page in staging and follow it as a visitor. It should reach the intended publication directly.

If the short path corresponds to another page that should be public, open that page in the dashboard. Check status, slug and parent page. A draft, private page or page moved under a parent may be accessible in an administrator preview without responding the same way publicly. Confirm the displayed path and editorial goal before publishing or renaming. After correcting the copy, check that the intended path returns the expected title and archive content retains its own address.

When the short path was actually distributed and must keep working, prepare an explicit redirect between two confirmed addresses. Use the team's existing redirect tool, add a match limited to that path and test first with a temporary redirect. If the address should remain unavailable, correct editorial links using it and have the layer causing the hop examined. Restoring the old menu target or removing the added rule returns to the initially recorded state.

Distinguish the historical slug, guessing and an explicit rule

Start with rules you can inspect. Check the site's redirect tool, then the hosting or CDN panel if accessible. Look for an exact match and a rule covering a set of paths. Conditions may depend on language, domain or parameter presence. An X-Redirect-By header, when present, helps identify the component, but several mechanisms may produce the same header. Compare the first public response with the origin only through the authorized diagnostic route.

Next examine the destination publication's history. With WP-CLI access, find its _wp_old_slug metadata using wp --path="/chemin/recette" --url="https://recette.example.test" post meta list 123 --keys=_wp_old_slug --fields=meta_key,meta_value. Replace 123 with the destination content ID. The short slug's presence warrants checking whether it is a known former address. This read is a clue for inspected content. It rules out neither a plugin rule nor history on another object. Core has separate handling for some old addresses. In staging, test an old slug with known history and compare it with the short path.

Native guessing operates on certain requests producing a 404 for which WordPress interpreted a content name. Core may search for a slug starting with that name, considering request information such as post type or date. This explains why two sites with different URL structures may respond differently to a similar address. If the redirect disappears and leaves a 404 when you disable only guessing for this address in staging, you have more precise evidence than the destination name alone.

1. Record redirect rules applying to the path, then confirm whether the destination content once had the short slug.
2. If the redirect is intentional and corresponds to a useful former address, retain it among validation controls. If an explicit rule is wrong, correct it and measure again.
3. If no rule or known former address explains the response, use the targeted check below with the copy's maintainer.

Check and disable guessing for one path

This route suits someone managing staging files where the path must remain unavailable. The code uses a WordPress filter to refuse guessing for two forms of the same path, with and without a trailing slash. It accounts for site ID so the same file does not change another subsite's response. Replace 7 with the target ID, such as get_current_blog_id() read through WP-CLI using that site's URL. For a subdirectory installation, enter the complete browser-requested path. The example targets addresses without parameters. Compare parameter variants separately if part of the report.

In the staging must-use plugins folder, usually wp-content/mu-plugins/, create atelier-404-cible.php with the following contents. Top-level PHP files in this folder load automatically. With terminal access, first validate syntax using php -l atelier-404-cible.php. Check the first response for all four control addresses after loading. If the short path now returns 404 while the exact address and old-slug control work, the result supports the guessing hypothesis. If the hop persists, remove the staging file and continue finding the rule producing the response.

The filter leaves other mechanisms active. A historical redirect or explicit rule may still answer for this path. Another plugin may also modify the same filter. Measure the effect on the actual URL rather than concluding from the file's presence. Avoid removing all WordPress canonicalization to resolve one 404. It handles other URL forms too. To restore the previous staging configuration, remove only the added file and reread control responses.

<?php
/**
 * Plugin Name: Atelier. Contrôle d’une devinette 404
 */
if (!defined('ABSPATH')) {
    exit;
}
add_filter('do_redirect_guess_404_permalink', static function (bool $enabled): bool {
    if ((int) get_current_blog_id() !== 7 || !is_404()) {
        return $enabled;
    }
    $method = $_SERVER['REQUEST_METHOD'] ?? '';
    $uri = $_SERVER['REQUEST_URI'] ?? '';
    if (in_array($method, ['GET', 'HEAD'], true)
        && in_array($uri, ['/fiche-temoin/', '/fiche-temoin'], true)) {
        return false;
    }
    return $enabled;
});

Interpret results when several rules overlap

Several responses may precede the post. If the first leads to the same path with a trailing slash, record that hop, then query the path in Location. If the next hop leads to similarly named content, compare that second path with the control. Do the same when hosting first redirects to the preferred domain. The staging filter acts inside WordPress. A redirect handled before the request reaches WordPress can therefore mask the test result.

When the bare path responds as intended, repeat measurements with a useful variant, such as a dummy tracking parameter, language prefix or same address on the control subsite. The example filter compares the raw address. A parameterized variant does not match the targeted path and may continue redirecting. Decide separately whether it should respond identically. For an internal link, correcting its source may suffice. For a distributed campaign, check what the address promised readers and prepare an explicit rule if it must remain usable.

When two starting addresses return different destinations for the same content, first compare their paths and the request type WordPress interprets. A short address under a post-type path may be treated differently from the same string at root. Changing permalink structure would affect many more links. Retain current settings during testing and choose a control in the same post type.

If the expected historical redirect also stops working in staging, remove the change and compare again. Check whether another rule changed simultaneously. The repair must produce distinct results for the contentless address and retained link. One corrected response does not validate both.

Confirm the status and links that must keep working

Revisit the four addresses in a public session. The corrected path must produce the intended result. If the page does not exist, check a genuine 404 status and intended error document. If the link should lead to valid content, check the first hop and exact destination, or a direct response if you corrected the link at source. Confirm the similarly named publication still responds and the retained old link reaches its destination. If the site has several languages, a subdirectory or a network, also test a control outside the target path.

An old 301 may persist in the browser or shared cache after an origin correction. Compare a fresh-session result with an uncached staging access. If an old response remains in site or CDN cache, invalidate the affected path through the team's procedure, then reread the first response. Do not treat changed parameters as proof of purging, since cache may handle those addresses separately. Keep all four records, test domain, changed rule and planned rollback. If a retained link stops working, restore the previous configuration and reproduce the issue on the copy before broadening correction.

Create an explicit mapping with free Redirection

If the need is to preserve a known former address, the free Redirection plugin can manage a precise rule. Install it through Plugins > Add New Plugin on the copy and open Tools > Redirection. Keep logging choices appropriate for staging needs and record them before proceeding.

Add a rule with the exact source path, such as /ancienne-visite/, and the new page's validated URL as target. Leave regular expressions disabled for this case. Choose a temporary 302 redirect during verification; once the destination and permanent nature are confirmed, adjust status according to site policy. Also check how the rule handles URL parameters.

Test the source, direct target and a similar path that should be unaffected. The rule must produce one hop to a correct page without looping. To undo, disable this rule and repeat all three requests in a fresh session. This plugin does not replace the guessing diagnostic filter: if the goal is a genuine 404, adding a redirect to other content would contradict that choice.