301, 302, 307 or 308: which status code?
| Code | Meaning | When to use |
|---|---|---|
| 301 | Moved permanently | The default for moves, HTTPS, www and new URLs. Google passes the signals on to the target and after a while only indexes the new URL. |
| 308 | Permanent, keeps method | Like 301, but a POST stays a POST. Useful for APIs and form endpoints. Equivalent to 301 for Google. |
| 302 | Found, temporary | Short-term redirects, such as a promotion page. The old URL stays in the index. Leaving a 302 in place permanently sends mixed signals. |
| 307 | Temporary, keeps method | Like 302, but without changing the method. Browsers also show 307 internally when HSTS kicks in. |
Important: browsers often cache 301 and 308 permanently. So test new rules with 302 or with curl first, and only switch to 301 once everything is right. Otherwise, after a fix, you end up chasing an old cache entry.
Avoid redirect chains
A chain happens when a request is redirected more than once, for example http://www.example.com first to https://www.example.com and then to https://example.com. Every hop costs a full network round trip, easily 100 to 300 milliseconds on a first mobile visit. That hurts load time and Core Web Vitals, and Google only follows long chains to a limited extent.
The two combined variants above ("HTTPS and without www" or "with www") check both conditions at once and redirect to the final address in a single hop. Do not add a second HTTPS rule in Plesk or a plugin on top, or the chain comes right back. Also check internal links and the sitemap: they should point directly to the final URL, not to a redirected one.
Test redirects with curl
The browser is a poor testing tool because it caches redirects. curl -I only requests the headers and shows the status code and the target:
curl -sI http://www.example.com/ | grep -iE "^(HTTP|location)"-L shows the whole chain with every hop. More than one location line means there is a chain.
curl -sIL http://www.example.com/ | grep -iE "^(HTTP|location)"Only the final result, handy for scripts:
curl -sIL -o /dev/null -w "%{http_code} %{url_effective}\n" http://www.example.com/Test all four variants of the start address: with and without www, each with http and https. Each one should land on the target address with exactly one hop or directly with 200.
HTTPS redirect in Plesk with a switch
For a plain HTTP to HTTPS redirect you do not need a custom rule in Plesk. Under Websites & Domains, Hosting & DNS, Hosting Settings there is an option for a permanent, SEO-safe 301 redirect from HTTP to HTTPS. Plesk applies it directly in the web server configuration. You make the www decision in the same hosting settings under "Preferred domain". If you set both in the panel, you only need the generator for single URLs, directories and domain moves.
Make sure that the Plesk switches, your own rules and the WordPress settings (Site Address under Settings, General) all use the same target address. If they contradict each other, you get chains or redirect loops.
Common mistakes
- Redirect loop behind a proxy or CDN: if Cloudflare sits in front in "Flexible" mode, every request reaches the server over HTTP. The rule then keeps redirecting to HTTPS. Fix: SSL mode "Full (strict)" with a valid certificate on the server.
- Rule placed after the WordPress block: WordPress passes everything to
index.phpwith[L]. Your own redirects therefore belong before# BEGIN WordPress. - Query parameters: Apache automatically appends the original parameters to the target, the nginx rules above carry them over with
$is_args$argsor$request_uri. - Redirecting everything to the home page: when moving a site, Google often treats blanket redirects of old URLs to the new home page as soft 404s. Better redirect every important old URL to its matching counterpart.