How to set up 301 and 302 redirects after fixing broken links

A redirect is how an old URL keeps working after the page behind it has moved or gone. Done right, the visitor never notices. Done wrong, one broken link becomes a slow one, or a page that quietly stops ranking and nobody can say when it started.

This guide covers what a redirect actually is, when to reach for a 301 and when for a 302, and the exact steps on WordPress, Shopify and a plain HTML site.

Start by finding out what is actually broken

You cannot write a redirect for a URL you have not identified, and guessing from memory finds the pages you already knew about. There are two separate problems here, and they need different tools.

Links on your site that lead somewhere dead. These are the ones your readers actually click: an internal link to a post you renamed, an outbound link to a site that reorganised itself last year. A crawler finds them by walking your pages the way a visitor would. A no-login scanner like the Verflink free scan does this without an account or a snippet to install: give it your address, and it comes back with the bad links and the page each one sits on, which is the difference between fixing and searching.

Links from other sites pointing at URLs on your site that no longer exist. A crawler of your own pages cannot see these, because the link lives somewhere else. Google Search Console's page indexing report and your server's 404 logs are where those show up.

Redirects are the fix for the second problem and for part of the first. Which part, and what to do with the rest, is the next section.

What a redirect is

When a browser asks for a page, your server can answer with the page, or it can answer with a status in the 300s and a Location header naming a different address. The browser goes there instead, usually too fast to see. Crawlers follow it too, and they read the status code as an instruction about what to do with the old URL.

That status code is the whole decision. It is not a technical detail: it is you telling every search engine whether the old address is finished or just away for a while.

301 or 302

301 Moved Permanently. The old URL is not coming back. Search engines eventually drop it from the index, keep the new one, and consolidate the old page's accumulated signals onto the target. Browsers cache a 301 hard, often until someone clears the cache by hand. That last part is the trap: a visitor who hits a wrong 301 once keeps being sent to the wrong place even after you have fixed the server. Check the destination before you ship it.

302 Found. The move is temporary. The old URL stays the one in the index, signals stay with it, and browsers ask your server again every time rather than remembering the answer.

The rule of thumb fits in one question: is the old URL ever coming back? If no, 301. If yes, 302.

Getting it backwards costs you in both directions. A 302 on a permanent move leaves the old address indexed and splits your signals across two URLs that are meant to be one page. A 301 on a temporary move can get the old address replaced by the new one, and the browser cache makes it awkward to undo when the page returns.

Two footnotes worth knowing. 307 and 308 are the strict versions of 302 and 301: they guarantee the request method is not quietly changed from POST to GET. For ordinary page moves this rarely matters, and search engines treat 308 the way they treat 301. And a redirect that lands on another redirect works, but every hop costs the visitor time and each one is a chance to lose the trail, so point every old URL straight at its final destination rather than chaining them.

The scenarios that cover almost everything

You renamed a page or changed the permalink structure. One 301 per old URL, pointing at its new address.
The page is gone and nothing replaces it. Resist the reflex to send it to the homepage. Search engines treat a pile of redirects to the homepage as a soft 404 and ignore them, and the visitor lands somewhere that answers a question they did not ask. Redirect to the closest genuine equivalent, the product's category or the topic's hub, or let the URL return a 404 with a page that helps.
The dead link points at somebody else's site. No redirect on your server can fix this, because you do not control that address. Edit the link to the merchant's current page, or remove it. This is most of what a crawl of an older blog turns up.
You moved domain, went to HTTPS, or standardised on www. One site-wide 301 rule, not one line per page.
The page is temporarily unavailable. A 302, or better, keep the page up and say on it when the product is back.

WordPress

The plugin route is the one to take unless you have a reason not to, because it survives theme changes and does not need file access.

Install a redirect plugin. Redirection is free and does nothing else, which is what you want. Plugins, then Add New, search for it, install, activate, then run its setup wizard once. Some SEO plugins bundle a redirect manager too, and either is fine, but do not run two at once.
Open Tools, then Redirection, then Add new redirection.
Put the old path in Source URL, written relative, like /old-post-name/. Put the destination in Target URL, relative for your own site or the full address for another.
The default type is 301. If the move is temporary, open the gear icon next to the form and pick 302.
Save, then load the old URL in a private window and confirm where you land.

If you would rather not add a plugin and your host runs Apache, the same thing goes in the .htaccess file at the root of your site:

Redirect 301 /old-post-name/ https://example.com/new-post-name/

One detail that catches people: put your rules above the # BEGIN WordPress block. WordPress's own rules end in a catch-all, and anything below it never runs. On nginx the equivalent lives in the server block and needs a reload:

location = /old-post-name/ { return 301 /new-post-name/; }

Whichever route you take, purge your caching plugin and your CDN afterwards. A cached copy of the old 404 will happily keep serving.

Shopify

Shopify has this built in, so no app is needed.

In the admin, open Online Store, then Navigation, then URL Redirects. Shopify has moved this screen between admin versions, so if it is not where you expect, type "redirect" into the admin search and it will take you straight there.
Click Create URL redirect. Redirect from is a path on your store, like /products/old-handle. Redirect to is a path or a full address.
Save, then test the old URL.

Three things to know before you start. Shopify's redirects are 301 only: there is no 302 option in that screen, so for a genuinely temporary change you are better off keeping the page and explaining the situation on it. Shopify will refuse to redirect a URL that currently resolves to something live, which is a feature, not a bug. And when you change a product or page handle, the SEO section offers to create the redirect for you: leave that box ticked and half of this work never becomes necessary.

For a migration with hundreds of old URLs, the same screen imports a CSV, which beats typing them one at a time.

Plain HTML sites

There is no admin here, so the redirect belongs in whatever serves the files. Every one of these is a real server-side status code, which is what you want.

Apache, in .htaccess at the site root: Redirect 301 /old-page.html /new-page.html
nginx, in the server block, followed by a reload: location = /old-page.html { return 301 /new-page.html; }
Netlify and Cloudflare Pages, in a file named _redirects next to your HTML: /old-page.html /new-page.html 301
Vercel, in vercel.json, as a redirects array with source, destination, and permanent set to true. Note that Vercel's permanent flag issues a 308 rather than a 301, which is the stricter equivalent and is treated the same way by search engines.

GitHub Pages is the awkward one, because it gives you no server configuration at all. The fallback is a small HTML file at the old address containing a meta refresh and a canonical tag pointing at the new one:

It works, and search engines will follow it, but treat it as the option you use when you have no other. It is slower than a real redirect and a weaker signal. A redirect written in JavaScript is weaker still, since it carries no status code at all and does nothing for a client that has not run your script.

Confirm it actually works

Do not trust the admin screen that said "saved". Ask the server:

curl -I https://example.com/old-page

You want a 301 or 302 on the first line and a location header pointing where you intended. To see a whole chain at once, and catch the redirects that quietly go through three hops:

curl -sIL https://example.com/old-page

Then open the old URL in a private window, because your own browser may have cached an earlier answer and will show you a result nobody else gets.

The short version

Find the broken links first, with a crawl of your own pages for the ones your readers click and Search Console for the ones other sites point at.
301 when the old URL is finished, 302 when it is coming back.
Never bulk redirect dead pages to the homepage.
A dead outbound link is edited, not redirected.
Point each old URL straight at its final destination, no chains.
Verify with curl and a private window, then purge the cache.

Redirects are the easy half. Knowing which URLs need one is the half that takes a crawler, and the free scan gives you that list in about a minute, no account needed. See also what link rot is and how often to check for it, and how to find broken affiliate links if the links you are fixing are the ones that pay you.