301 Redirects in WordPress: Fix 404s Without Redirect Chains

Use a 301 redirect when a URL has moved permanently and a 302 only when the original URL is coming back. Always redirect to the final live page, never to another redirect, and never to the homepage as a catch-all. Find the 404s worth fixing from Google Search Console, your server logs and a site audit, then pair each one that carries links or traffic with a single-hop 301 and let the rest return an honest 404.

That is the whole discipline in three sentences. The rest of this guide is about why each part matters, how to do it in WordPress without touching server configuration, and how to stop redirect chains from quietly accumulating over the years. Where we mention Hydrogen SEO's redirection manager as a worked example, note that RankWave AI and Hydrogen SEO are both built by Sheesh Labs, so read those parts as a builder's view rather than a neutral recommendation; the rules themselves apply whatever tool you use.

301 vs 302: which should you use?

An HTTP status code is the server's one-line answer to "where is this page?". A 301 Moved Permanently says the page lives at a new address forever, and search engines respond by transferring the old URL's accumulated signals to the new one and eventually swapping it in the index. A 302 Found says the page is elsewhere for now but this address remains its home, so search engines keep the original URL indexed and treat the destination as a stand-in. Visitors land on the target either way; the difference is almost entirely in what you are telling crawlers.

Two folklore points are worth clearing up. First, you will read that a 301 passes exactly 100% of PageRank and a 302 passes none; nobody outside Google can measure either figure, and Google has said publicly that a long-standing 302 is eventually treated like a 301. Second, that "eventually" is unpaid work you could have done deliberately. The classic mistake is the accidental permanent 302, installed during a redesign and forgotten for two years. If you cannot remember why a 302 exists, that is your answer: make it a 301. The 301 vs 302 decision reference covers 307 and 308 too, though for WordPress content SEO the two classic codes cover every real case.

What do 404s really cost?

A 404 is not an emergency in itself. Every healthy site returns some, and Google expects it. The cost comes from 404s on URLs that used to matter, and it arrives in three forms, none of which needs an invented statistic to be real.

• Lost link equity. When a page that earned external links dies without a redirect, everything those links conferred stops flowing anywhere. That authority was earned once and is simply discarded. Internal links still pointing at the dead URL leak the same way.
• Crawl waste. Crawlers revisit URLs they have seen before. Every request spent on a dead URL is attention not spent discovering or refreshing your live pages. On a large site, thousands of lingering 404s meaningfully dilute how often the pages you care about are crawled.
• Lost visitors. Someone who followed a link from another site, an old newsletter or a search result and lands on "Not Found" rarely tries a second URL. The error page is often the whole first impression.

The practical implication is that 404s are a triage problem, not a cleanliness problem. You want a list ranked by what each URL carries, not a count driven to zero.

How do you find every 404 on a WordPress site?

No single source sees everything, so use three and merge the lists.

Google Search Console

Go to Indexing → Pages and look under "Why pages aren't indexed" for Not found (404). Export the list. These are URLs Google itself crawled and found missing, usually because something links to them, which makes them the highest-priority set. Then open Links → Top linked pages and check whether any URL earning backlinks now returns a 404; those are the most expensive dead ends you have.

A site audit for broken internal links

Broken internal links are the 404s entirely under your control, because your own pages are actively sending visitors and crawlers into them. A crawler-style audit lists each broken target alongside the page linking to it. The free Hydrogen SEO plugin's site audit does this from Hydrogen SEO → Dashboard and the docs walk through the workflow to find and fix 404 errors; any site crawler that reports broken internal links will give you the same list.

Server logs and analytics

Your host's access logs, filtered for status 404 and sorted by hit count, surface what real traffic is requesting: inbound typos from other sites, truncated URLs in emails, old attachment paths still embedded somewhere. Neither Search Console nor your own audit would flag a URL you never created. If you cannot reach raw logs, your analytics platform's page report filtered to your 404 page title is a workable substitute.

What is a redirect chain and why does it matter?

A redirect chain is a redirect that points at another redirect: A → B → C. Chains almost never get built on purpose. They accumulate as a site ages: a 2019 slug change stacked under a 2022 category restructure stacked under an HTTPS migration, each layer added by someone who did not know about the one below. Every hop adds latency for every visitor, crawlers follow only a limited number of hops before abandoning the URL, and signals pass less cleanly through several hops than through one.

The fix is flattening. Point A directly at C and B directly at C. The habit that prevents new chains is a single question every time you add a rule: does anything already redirect to the URL I am now redirecting away from? If so, repoint that older rule at the new final destination in the same sitting. A redirect loop, where a source eventually redirects back to itself, is the same problem taken to its limit and will show as an error in the browser; edit or delete one of the rules involved.

Chains are also why redirects belong in one place. Rules scattered across an .htaccess file, a host control panel and two plugins are impossible to check for chains, because no one screen shows the whole graph. One list, sorted by source, is where chains become visible.

How to add redirects in WordPress

With a redirection manager plugin

Most modern SEO plugins include a redirection manager, and the workflow is broadly the same in each. Taking Hydrogen SEO's as the example (disclosure again: our sister product, and Beta software), the steps are:

1. In wp-admin go to Hydrogen SEO → Redirections and click Add Redirect.
2. Enter the source as a path, not a full URL: /old-post/, never https://example.com/old-post/. The rule applies to your own site's URLs only.
3. Enter the target as a relative path (/new-post/) to stay on the site or an absolute URL to send visitors to another domain.
4. Choose 301 (Permanent) or 302 (Temporary) and save. The redirect takes effect immediately; confirm it in a private browser window.

The redirection manager documentation adds two rules worth adopting whatever tool you use: one hop, never a chain, and no loops. A useful pattern is to create a rule as a 302 while you confirm the destination is right, then edit it to a 301 once you are certain. Because the redirect is issued before WordPress renders a page, it works alongside page caching and host-level caches; if a brand-new rule does not fire, clear the cache once. Every rule is visible in one list with its source, target and type, which is the property that makes chain-hunting possible.

With .htaccess or Nginx, for advanced users

If you administer your own server and prefer redirects at the web-server layer, the equivalents are a Redirect 301 /old-post/ /new-post/ line in Apache's .htaccess, or a return 301 /new-post/; inside a location = /old-post/ block in Nginx. Server-level rules fire before PHP starts, so they are marginally faster, but they carry three costs: a syntax error in .htaccess takes the whole site down, managed hosts often do not allow edits at all, and the rules live in a file only one person on the team knows about. For a handful of high-traffic migration redirects on a server you control, the web-server layer is fine. For the living list a content site accumulates, keep them where the whole team can see them.

When you change permalinks or delete a post

Most 404s on WordPress sites trace back to two ordinary editorial actions, and a rule for each prevents the majority of them.

• When you rename a slug, add the 301 in the same sitting. WordPress does not reliably leave a redirect behind when a permalink changes, and every existing link to the old slug breaks the moment you save. Treat the redirect as part of the rename, not a follow-up.
• When you delete a post, decide its fate as part of deleting it. Either it 301s to the page that best replaces it, or it 404s deliberately, and you write down which. A trashed post with backlinks and no decision is a slow leak.
• When you change the whole permalink structure or migrate domains, build the map before launch. Export every current URL, pull the top pages from analytics and Search Console so you know which carry value, map each old URL one-to-one to its most relevant new URL, and stage the redirects to go live with the new site rather than days later. Then update your XML sitemap to list only final, live URLs and resubmit it; our WordPress XML sitemap guide covers what belongs in it.
• Fix internal links at the source, not just with a redirect. A redirect is a patch; a corrected link is the repair. When a site audit shows a broken internal link, edit the linking page so it points at the final URL directly. Do both when the broken URL also has external links.

Keep migration redirects in place for the long term. Google has recommended at least a year; in practice, if the old URL has backlinks, the rule costs nothing to keep and something to remove.

When should you not redirect?

A redirect is not always the answer, and the reflex to redirect everything creates its own problems.

• Unrelated content. If nothing on the site replaces the dead page, do not redirect it to the homepage or a vaguely related category. Google typically treats blanket redirects to irrelevant pages as soft 404s, so you gain nothing, and the visitor loses. Return a 404, or a 410 Gone to signal the removal was deliberate. Search engines may drop 410 URLs slightly faster; for most sites the practical difference is small.
• Content deleted by accident that still ranks. Restore it. A redirect passes some value to a different page; the original ranking page usually recovers far more by simply existing again.
• A URL that never existed. An inbound typo from another site is worth redirecting to the page the linker clearly meant, but only once the log shows it receiving real hits. Do not pre-emptively build rules for every misspelling you can imagine.

Monthly redirect hygiene checklist

Redirect health fails when nobody owns it. A short pass each month keeps the list honest and takes minutes once the habit exists.

1. Open Search Console's 404 report and check for new URLs that carry links or traffic. Add single-hop 301s for those; leave the rest.
2. Re-run your broken internal link audit and fix each result at the source page, adding a redirect only where the URL also has external links.
3. Scan the redirect list for chains: any target that also appears as a source. Flatten them.
4. Promote 302s that have turned out to be permanent into 301s. If it has been temporary for twelve months, it is not temporary.
5. Delete rules whose sources no longer receive any traffic or links, once they have done their job for a long while. Hundreds of stale rules are a maintenance burden with no return.
6. Confirm your XML sitemap contains only live, final URLs and no redirecting ones.