What Is a Redirect 301?

The number isn't a minor technical detail: 301 means "moved permanently," 302 means "moved temporarily," and Google treats each one differently. With a 301, the target URL becomes the canonical version, the one Google shows in search results. With a 302, Google keeps showing the original URL in results for as long as the redirect stays in place, because it assumes the old address could become active again at any point.

The costliest mistake is leaving a 302 on a change that's actually permanent. It happens constantly during domain migrations: the new CMS or platform defaults to a 302, nobody double-checks it, and for weeks Google keeps showing the old domain in results instead of consolidating value on the new one. The new domain inherits crawl history and click history more slowly, because as far as Google is concerned, the redirect could still be reversed at any moment.

The practical rule is simple: if there's any real chance the old URL becomes active again, it's a 302. If that chance doesn't exist, it's a 301.

Checking the actual code takes seconds from the command line, regardless of what the CMS or plugin claims:

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

HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page

Protocol and subdomain switches count as 301s too, even when they don't feel like a "migration": moving from http to https, or from a non-www version to www (or the other way around), consolidates permanently onto a single address and should always carry this code, never a temporary 302, and definitely not both versions left standing with no redirect at all.

In practice, the mistake is rarely a deliberate choice for 302, it's the software's default setting. Plenty of redirect plugins and reverse-proxy configurations set a 302 without asking, because it's the safer default: a redirect wrongly marked permanent is harder to undo than one wrongly marked temporary. Anyone who doesn't check after a migration often keeps the wrong code for months without noticing, because the site keeps working fine for visitors. Only the search engine sees the difference.

A canonical tag and a redirect 301 solve the same underlying problem, content that's duplicated or split across several URLs, in opposite ways. The canonical leaves both URLs reachable: whoever visits the old address still sees it, and Google is simply told which version should be indexed as preferred. A redirect 301, on the other hand, stops the old URL from responding on its own: whoever tries to reach it, person or crawler, lands automatically on the new address, with no option to stay on the old one.

That difference decides which tool fits. If both versions need to keep existing, a product page with and without a color parameter, for instance, a canonical is enough on its own: redirecting there would break navigation for anyone specifically looking for that variant. If the old URL has no reason left to be reachable, a domain migration, a new category structure, two pages merging into one, a redirect 301 is the right tool, and canonical falls short: it would keep a URL reachable that should genuinely be gone.

The typical mistake runs in both directions. Using only a canonical when the old URL should actually be deleted keeps it alive for no reason, generating low-quality duplicates a crawler keeps visiting unnecessarily. Using a redirect 301 when both versions need to coexist cuts off access to one of them: whoever is looking for that specific variant can no longer reach it on their own.

There's a practical user-facing difference too. A canonical is invisible to visitors, they never notice it exists, while a redirect 301 actively intervenes in navigation: a saved bookmark or an old screenshot carrying the original URL now leads somewhere else automatically. That's the intended behavior for a genuine move, but it would be an unnecessary break in expectations for a plain parameter variant.

A 404 error says "there's nothing here." A redirect 301 says "this moved, here's the new one." The distinction sounds obvious until someone has to decide what to do with a specific URL that stopped existing, and that's exactly where the most common mistake happens.

When the content has a genuine equivalent somewhere else, a redirect 301 is almost always the right call: it carries along both the people arriving through an old link or a saved bookmark and the ranking signals accumulated at that address. Leaving it as a 404 in that case wastes both for no good reason.

A 404 stays the correct answer when there's no real equivalent to send people to. Forcing a redirect toward a page with no genuine connection to the content that disappeared, the homepage used as a catch-all being the classic case, doesn't solve the problem: it confuses anyone who was looking for something specific and erodes trust in the rest of the site, and Google can end up treating that redirect as poorly relevant to the original query. In that scenario, a well-designed 404 page with its own navigation and search is more honest, and more useful, than a forced redirect.

Someone deliberately removing content, and certain no replacement is coming, can use the less common 410 code instead of a 404: it communicates "deliberately and permanently gone" rather than the vaguer "nothing here" that a 404 also returns for links that broke by accident. In practice Google treats the two similarly; the difference mostly matters for whoever is reading the server logs.

• Avoid redirect chains: if URL A points to B, make sure B is already the final version, not another hop toward C. Every extra hop costs crawl budget and delays signal transfer.
• Always redirect to a page with genuinely equivalent content, never by default to the homepage.
• Use 301 for any change you consider permanent, even with some lingering doubt at implementation time: a 301 is easier to fix later than a 302 that quietly held back signal transfer for months before anyone noticed.
• Update internal links that pointed to the old URL so they go straight to the new address, instead of routing them through the redirect.
• Before any domain or structural migration, build a complete URL-by-URL redirect map; improvising redirects on the fly is the most common cause of blanket redirects to the homepage.
• Verify with a command-line tool (curl -I is enough) that the redirect actually returns 301 and not a 302 the CMS set by default.
• Watch the new URL's traffic in Search Console and analytics for the weeks after a migration; a sustained drop usually points to badly mapped redirects, not a problem with the 301 itself.

• Leaving a 302 in place on a permanent change because it's what the CMS sets by default, and nobody reviews it.
• Redirecting every old URL from a migration to the homepage instead of to its actual equivalent.
• Building multi-hop redirect chains that nobody checks until someone notices crawling has slowed down.
• Leaving internal links pointing to the old URL after setting up the redirect, instead of updating them to the new address.
• Mixing contradictory signals: a URL with a canonical pointing one way while internal linking redirects it another.
• Using a redirect 301 to "hide" problematic content instead of fixing it or removing it deliberately.