Confident 404 Redirect

The visitor asked for a specific page and the homepage is not it. A 200 response for a URL that does not exist is also a soft 404, which tells search engines your site is padded with thin pages. If you want that behaviour anyway, it is one setting away. It is not the default.

No. Nothing runs on a page that loads normally. A unique exact slug hit costs one indexed lookup, plus a permalink read for whatever it found - one query on a plain permalink structure, a few more where the structure asks for categories or ancestors - unless that post is already in the cache. A slug several posts share pays that permalink read per candidate. A miss costs more. The near-match pass reads up to four indexed prefix scans, widest first - the first word of the slug, then two, three, and the slug missing its last character - and stops at the first that comes back whole and contains the narrower ones - which the prefixes of one slug normally do, though a slug filter can make them not, and then the ladder reads on; on a site where the first word is rare that is one scan. Title matching, where it runs, adds one more: a single bounded read of the titles themselves - one row past the scan threshold at most, which is how it notices a corpus that outgrew the guard and stands down - scored in PHP, which is also what lets a Latin URL find the Cyrillic title a slug plugin transliterated it from. A URL that matches nothing at all costs up to seven queries in the measured baseline, and a slug a dozen posts share, where each candidate's permalink is read, measured at about thirteen - both numbers from a plain permalink structure, which is what the benchmarks run; a category-based structure adds its own reads to every permalink. Once a day, the first 404 that gets as far as title matching also refreshes a cached count of your content, which adds a few queries and, on a site of twenty thousand posts, tens of milliseconds. When the cache retains that count, later 404s read it; when storage cannot retain it, title matching alone stands down after the count and asks again later instead of paying for an unguarded title scan - slug matching, your fallback and the no-match action carry on, because the database did answer. A count the database itself refuses is different: that stands the whole matcher down for the request, fallback included, because an unanswered read is not a 404 verdict. A 404 that resolves on a unique, perfect slug match never asks for the count at all - anything less certain still consults it before title matching weighs in.

Several things can stop it, and they all come down to the same rule: a permanent redirect to the wrong page is worse than a 404. The three most common are these. The score was below your confidence threshold, which you can lower under Settings. Or the two best candidates were too close to tell apart, whether the slug engine, the title engine, or one of each found them. Two pages called Contact score the same; two slugs one character away from what was asked for score within a point or two of each other, and that gap measures their length rather than how close they are. Two engines finding the same post still count as one candidate. A close pair of different posts identifies neither, so neither earns a permanent redirect. The rest of the requested path can still settle it: two pages slugged or titled alike under two parents are told apart by the parent the request was made below; a request at the root prefers the candidate at the root, so a site whose translations share a slug under a language directory still gets its default-language near misses; two candidates at one address - a post and a page sharing a slug - are one destination and no tie; a request on one language domain prefers the translation on that domain; when one of them has an address the plugin would not send nothing is offered at all; and the comparison ignores ASCII case, as WordPress does when it routes a path. confident_404_redirect_ambiguity_margin sets how wide the gap has to be, and zero restores acting on anything that is not an exact draw. Or the URL pointed into a crowded group: a slug that more than five posts share exactly, or a prefix of the requested slug - down to its first word - that more slugs share than the plugin reads at once, twenty-five unless confident_404_redirect_candidate_limit says otherwise. There the plugin can only see a sample of the group, and the post you wanted may not be in it, so the closest it saw is offered as a suggestion and never sent. Either kind of crowd holds back every other match for that request too, a title match included: a title unique among those posts is no evidence which of them the visitor meant, and a slug the plugin did not read may be closer than the title. On a site where more slugs than that share the first word of a mistyped address, this means such a typo is offered as a suggestion rather than redirected. When there is a usable near miss, the plugin offers it to your 404 template instead, so a theme can still ask the visitor whether that was what they meant. That includes a near miss the plugin deliberately held below its score floor - a crowded slug, a tie, a truncated sample - which is offered but never redirected. A title whose raw similarity falls below the floor is noise and is never offered; nor is a URL that is unsafe or resolves back to the same request, or a match abandoned because the database could not answer.

Yes, with one caveat that belongs to the cache rather than the plugin: WordPress can only redirect a 404 it actually serves. Most page caches pass 404s through, which is their common default, and the plugin adds nothing to pages that are cached. A server cache or CDN configured to cache 404 or redirect responses will keep serving its stored copy until it expires or is purged.

Yes. The plugin watches its own database reads through wpdb's query filter and its query counter, which every drop-in built on wpdb keeps. wpdb's ready flag is read only on a stock wpdb: those drop-ins never set it, and reading it there once stood the plugin down on every request behind them. A connection that dies mid-request is read as an unanswered read, not as an empty site: WordPress reports that failure to nobody once the template stage has begun, and the plugin reads the result handle it leaves behind.

No. Anything under this site's own uploads directory - the one on this site's host and port; uploads moved to another host, or another port of this host, are another site's - is excluded, and so is any URL ending in a recognised file extension, unless that extension is one a page can have. The rule works that way round on purpose: a format nobody thought of is left alone rather than answered with a page.

The plugin reads the site's home address once per request and judges every path and its own directories against it, while a redirect target and the loop check are judged against the origin the visitor actually requested, so it has to be a plain http or https address of an ASCII host, on a port a socket can have, with no credentials. An internationalised domain is spelled in punycode there, as WordPress itself expects; a home_url filter has to answer an address. Until it does, the plugin stands down - no redirect, no fallback - and, under the default guessing setting, hands WordPress its own permalink guessing back rather than hold it down for nothing.

WordPress does not index post titles, so searching them means reading every title, on every 404 that gets that far. The cost grows with your content - tens of milliseconds a few thousand items in, and around a second at the twenty-thousand ceiling on the benchmark site - and crawlers produce 404s in bulk, so above a threshold of 2,000 items the plugin stands the title engine down. Slug matching keeps working. The count is of the content the plugin is set to search, so narrowing the post types narrows it too. The threshold is filterable through confident_404_redirect_scan_limit, up to a hard ceiling of twenty thousand. The title pass costs the corpus size per 404, linearly, times a per-title price that grows with title length - measured at that ceiling over ordinary titles, a miss across twenty thousand titles takes around a second on the benchmark site, and a corpus of titles hundreds of characters long can multiply that - so raising the threshold trades 404 latency for reach, and the ceiling is where that trade stops being offered.