How to Configure 301 Redirects: HTTP to HTTPS, Naked Domain to WWW, and Domain Migration

301 and 302 differ by only one digit, but their significance to search engines is completely different: a 301 indicates a permanent move and passes link equity (weight) to the new address; a 302 indicates a temporary redirect and does not pass equity. Using the wrong code for site canonicalization or domain migration is equivalent to slowly losing your accumulated indexing.

Another high-frequency issue is redirect loops—after configuration, browsers report “too many redirects,” rendering the site unusable. These two scenarios account for the vast majority of redirect problems.

Distinguish Between Two Dimensions First

The judgment method is simple: Will this redirect be reversed? If it will not be reversed, use 301; if it is temporary, always use 302. For scenarios like site canonicalization that are “permanently effective,” you must use 301.

Scenario 1: HTTP to HTTPS

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

$request_uri preserves the original path and parameters. Writing it as https://$host/ will redirect all pages to the homepage—one of the most common errors.

Scenario 2: Unifying Naked Domain and WWW

# Naked domain → www (301)
server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /path/fullchain.pem;
    ssl_certificate_key /path/key.pem;
    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl http2;
    server_name www.example.com;
    ssl_certificate     /path/fullchain.pem;
    ssl_certificate_key /path/key.pem;
    # Main site configuration
}

Note: The server block for the naked domain must also have certificates configured. The HTTPS handshake occurs before the redirect; without a certificate, users will see a certificate error before being redirected.

Scenario 3: Old Address to New Address

# Single page
location = /old-page.html {
    return 301 https://example.com/new-page.html;
}

# Entire directory
location ^~ /old-dir/ {
    rewrite ^/old-dir/(.*)$ https://example.com/new-dir/$1 permanent;
}

Scenario 4: Full Domain Migration

server {
    listen 80;
    listen 443 ssl;
    server_name old.com www.old.com;
    ssl_certificate     /path/old-fullchain.pem;
    ssl_certificate_key /path/old-key.pem;
    return 301 https://new.com$request_uri;
}

When changing domains, the old domain’s certificate must remain valid; otherwise, the redirect link itself will throw an error. It is recommended to keep the old domain’s 301 redirect for at least six months.

Apache Configuration

# .htaccess
RewriteEngine On

# HTTP → HTTPS
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# Naked domain → www
RewriteCond %{HTTP_HOST} ^example.com$ [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [L,R=301]

Verification Commands

# Check status code and redirect target (check both)
curl -I http://example.com/
curl -sIL http://example.com/ | grep -iE '^HTTP|^location'

# Follow all redirects to check for chained transfers
curl -sIL https://example.com/ -o /dev/null -w '%{num_redirects} redirects, final %{url_effective}'

# Check for loops (an abnormally large number of redirects indicates a loop)
curl -sIL --max-redirs 5 https://example.com/ 2>&1 | grep -ic 'location'

Expected result: A single 301 redirect, with Location pointing to the final address, and the final status code should be 200. If there are multiple redirects (chained) or an uncontrolled number of redirects (loop), the configuration has issues.

Decision Tree

Redirect Anomaly
├─ Reports "Too many redirects"
│  └─ Loop, common causes:
│     ① HTTP→HTTPS and www→non-www point to each other
│     ② The application itself performs redirects, stacking with Web server rules
│     → Perform redirection in one place only, remove from the other
├─ All pages redirect to homepage
│  └─ Missing $request_uri / %{REQUEST_URI} in the rule
├─ Path or parameters lost after redirect
│  └─ Same as above, check if the original URI is included
├─ Certificate error appears before redirect
│  └─ The destination domain also needs a valid certificate
└─ Search engine indexing not transferred
   ├─ Used 302 instead of 301 → Change to 301
   └─ Old address returns 404 instead of 301 → Add redirect rule

Scenario Deduction: Redirects Configured Correctly, Yet Indexing Continues to Decline

Symptom: After changing the domain name, standard redirect configurations were applied. Accessing the old domain does redirect, but search traffic has not transferred and continues to drop.

1. Check where it redirects to, not just whether it redirects → Tracing the full redirect chain reveals that regardless of which specific page is accessed, it ultimately lands on the homepage.
2. Confirm this is the key issue → Deep pages that were previously indexed under the old domain now all point to the homepage. Search engines interpret this behavior as soft 404s, causing the accumulated value of those pages to become invalid.
3. Check configuration syntax → The redirect rule does not include the original request path, only the target domain.
4. Modify to preserve paths → Ensure the complete path visited by the user is carried over during the redirect.
5. Verify by category → Test redirects for URLs with and without www, HTTP and HTTPS, deep paths, and parameterized links to confirm they jump to corresponding new addresses rather than the homepage.
6. Check for circular redirects → Multiple coexisting rules can easily form back-and-forth jumps; use tracing tools to confirm the number of redirects is normal.

# Full redirect chain: See where it finally lands
curl -sSL -o /dev/null -w '%{url_effective}  Redirected %{num_redirects} times' http://old.com/deep/page?a=1

# Verify each format (all should jump to corresponding deep pages, not the homepage)
for u in http://old.com/p/123 http://www.old.com/p/123 https://old.com/p/123; do
  printf '%-32s ' "$u"
  curl -sS -o /dev/null -w '%{http_code} -> %{redirect_url}' "$u"
done

# Key to correct syntax: Preserve $request_uri
# return 301 https://new.com$request_uri;

Root Cause: The redirect rule discards the original request path, directing all old links to the homepage. The site appears to “redirect correctly,” but search engines treat it as soft 404s, resulting in the loss of indexing and external link value for deep pages.

Two points worth remembering:

• When verifying redirects, look at “where it goes,” not “if it goes.”
  The difference is just one variable, but the effect is completely different—the former transfers weight, the latter resets it to zero.
• After a domain change, troubleshoot deep paths first, do not test the homepage.
  Any redirect configuration will appear “normal” on the homepage; only specific pages can expose whether the path is being preserved.

8 Common Pitfalls

1. Using 302 when 301 is required: Weight is not transferred; changing domains becomes futile.
2. Omitting $request_uri: All pages redirect to the homepage, causing a massive drop in indexing.
3. Opposite redirect directions in two places: Directly causes loops, making the site unusable.
4. Destination domain lacks certificates: Certificate errors appear before the redirect.
5. Chained redirects: HTTP→HTTPS→WWW done in two steps is common, but merge them if possible to reduce one round trip.
6. Verifying without clearing cache after changes: 301s are cached by browsers, leading to false judgments that the configuration hasn’t taken effect.
7. Removing the old site too quickly after domain change: Keep 301s for at least six months; weight transfer takes time.
8. Configuring redirects at both CDN and origin server levels: This easily forms loops; ensure it only takes effect at one level.

Real Customer Feedback (From Cloud Market Reviews and Consultations for Similar Products)

The following excerpts are taken from real buyer reviews and consultations for similar operations services on Alibaba Cloud / Tencent Cloud / Huawei Cloud Cloud Markets (service providers include our store and peers, provided for reference only, not fictional tickets from this site):

b****4 Rating: 5.0 2025-06-23 16:57 b****4 Rating: 5.0 2025-06-23 16:56 Jian****Wei Rating: 5.0 2021-01-20 15:03 Excellent technical skills, very fast! It turned out Baidu global hijacking was caused by a trojan!!!! f****u Rating: 5.0 2021-01-02 20:43 Thanks for assisting in maintaining Yuncai’s normal operation. 1****1 Rating: 5.0 2020-11-20 10:03 Consistently good service 1****1 Rating: 5.0 2020-11-17 09:13 Thank you for the consistently good service. 1****1 Rating: 5.0 2020-09-25 15:42 Many thanks. 1****1 Rating: 5.0 2020-08-24 15:34 Many thanks to your company’s technical staff 1****1 Rating: 5.0 2020-07-24 09:49 Many thanks! 1

10***77 2022-09-19 5.0 Affordable price | Skilled technology | Patient and professional Received filing rectification notice, found this service just in time, handled quickly 10***49 2022-04-12 5.0 On-time delivery | Affordable price | Skilled technology Needed rectification, configuration was fast, not bad