301 or 302: which redirect fits when?

What types of redirect are there?

A redirect sends browsers and crawlers from one URL to another. The most reliable option is a server-side redirect. The server responds with a status code in the 3xx range and names the target in the Location header. There are also redirects in the HTML via meta refresh and redirects via JavaScript.

Google recommends permanent server-side redirects wherever possible. According to Google, you should only use JavaScript redirects if server-side redirects and meta refresh are not an option. If rendering fails, Google never sees the redirect.

When is 301 right, and when 302?

The underlying question is which URL should appear in search. With a permanent redirect, the target takes on that role. With a temporary one, the old URL usually stays canonical, although Google still follows the redirect.

If the move is permanent, send a permanent code as well. Other search engines and clients read the codes too, so the right code is worth it even where Google treats two codes the same.

Setting up redirects

Where you maintain redirects depends on your setup. With many rules, it helps to keep them in one place, for example in the server configuration or in the CDN. That way you spot overlaps between old and new rules earlier.

Apache

nginx

Checking in the terminal

With curl you see every hop and the final status. If there is more than one redirect, you have a chain.

Chains and loops

A chain occurs when A redirects to B and B redirects to C. A typical cause is a combination of several rules, for example http to https, then non-www to www, then old URL to new URL. In a loop, C points back to A, and browsers stop with “too many redirects”.

You find chains with a crawl that logs every hop individually. Three lists matter: internal links to redirects, redirects with more than one hop, and redirects whose target returns an error. Point internal links straight to the final target. Adjust old rules so that they redirect directly to the new target.

Redirects during a migration

During a migration, the redirect mapping decides whether rankings move with you. Every old URL with clicks, rankings or backlinks gets the target that matches its content.

1. Collect old URLs from Search Console, web analytics, Rank Tracking, backlinks and a crawl of the old website.
2. Assign each URL a target that matches its content and search intent. The homepage is only the last resort.
3. Export existing redirects and switch their targets to the new URLs. That way, no new chains appear.
4. Cover every variant of the old URL: with and without www, http and https, with and without a trailing slash.
5. Test on the staging environment before go-live. Check beforehand whether the error page there returns a real 404 status, otherwise missing pages look like hits.
6. After go-live, crawl all old URLs again and compare status and target with the mapping.
7. Keep redirects for at least a year, as Google recommends for site moves. After that, log files and backlinks show which rules can go.

When changing domains, a global rule that only swaps the domain name is risky. It carries old errors and unnecessary URLs over to the new domain. One-to-one rules for the important URLs and patterns for the rest work better. The guide Testing redirects shows step by step how to test redirects before and after a migration.

Common mistakes

• All old URLs redirect to the homepage. Google may treat this as a soft 404.
• A 302 stays in place after the migration, although the move is permanent.
• Internal links, canonicals and the XML sitemap still point to old URLs.
• New rules and old redirects create chains.
• The target of a redirect returns a 404 or redirects itself.
• Redirects are deleted after a few weeks because the new website is “up and running”.

Frequently asked questions