set_redirect: Agent-Applied Redirect Changes

set_redirect is the tool the Get AI Traffic agent uses to point one URL at another after you approve a fix. It creates or updates a single redirect rule, from a dead or moved URL to the page that replaces it, and publishes it through your site’s connection.

This page documents what the tool touches, what it refuses to touch, and how to undo it. For the decision of whether a dead URL deserves a redirect at all, which is the part that actually matters, read Not Every 404 Is a Bug, and Redirecting Them All Is Worse. This page is about the mechanics.

What it does

When you approve a fix that needs a redirect, the agent writes one rule: this URL now sends visitors to that one. On WordPress the tool routes to whichever plugin owns redirects. If the Redirection plugin owns them, the rule goes there; otherwise the Get AI Traffic plugin stores and serves the rule itself. So the redirect lands wherever your site already keeps them, instead of in a second competing layer.

Before it writes anything, the tool checks the destination and refuses to proceed if the target is not worth pointing at:

• The target must return a 2xx. If the destination is itself dead, the tool reports a dead target and writes nothing.
• The target must not itself redirect. If the destination is a 3xx, the tool reports a redirect chain and stops rather than building a two-hop path.
• The target must not be the source. A rule pointing a URL at itself is a loop, and it is refused outright.

Those checks run first, so a failed precondition leaves no ledger entry and no rule. The redirect either lands correctly or nothing happens at all.

What it will not touch

• The dead page itself. This writes a redirect rule. It does not restore, rebuild, or edit the page that went missing.
• Your other dead URLs. One rule, one URL. Every other 404 on the site keeps returning the error it should return, which is usually the right outcome.
• The choice of destination. The tool verifies the target is alive and direct. It has no way to judge whether that page genuinely answers what the old one answered. That judgment stays with you.

Timing

The rule takes effect on your site immediately. Search engines pick it up on their next crawl of the old URL, which can take a while for a page they have already learned is dead, since Google crawls known 404s less and less often. A permanent redirect is what moves the target into search results, so expect the swap to show up over subsequent crawls rather than the same day.

Rolling back

Every applied change is written to the ledger with the prior destination. roll_back restores the previous state exactly, whether that was a different redirect or no rule at all, in which case the URL goes back to returning its error.

Related tools

• delete_redirect removes a rule instead of creating one. It refuses when no redirect exists at that URL, and rollback recreates the rule it removed.
• purge_cache runs after an apply, so a cached copy of the old response does not keep serving at the edge after the rule lands.

Findings this tool resolves

• status_40x: a URL returns 404 or another client error. This tool is the fix only when a genuine replacement page exists, which is the whole subject of the linked article.

Two findings it does not resolve, despite appearing in the same report:

• status_50x and timeout: the server failed to answer, on a page that probably should exist. That is an outage, not a move. Redirecting it hides a broken server rather than fixing it.