Pāriet uz saturu

Apmeklētāji pirms lapas iziet cauri vairākām pāradresācijām

Brīdinājums Viss domēns Drošība

Vispārīgas norādes. Atveriet šo rakstu no sava PageCheck pārskata, lai redzētu to aizpildītu ar Jūsu vietnē atrastajām pāradresāciju ķēdēm un noteikumu Jūsu hostingam (Cloudflare, Plesk, cPanel, Apache vai nginx).

Kas tas ir

Vietnei ir četras saknes adreses: ar www un bez, caur http:// un caur https://. Apmeklētāji ieraksta jebkuru no tām, vecas saites un meklēšanas rezultāti norāda uz jebkuru no tām. Tikai viena rāda lapu; pārējām trim apmeklētājs uz to jāsūta ar vienu pastāvīgu (301) pāradresāciju — tieši uz https:// adresi un nekad pa ceļam caur http://.

Katra papildu pāradresācija ir pilns ceļš līdz serverim un atpakaļ, pirms lapa vispār var sākt ielādēties, un Google prasa ne vairāk kā vienu. Lēciens no https:// atpakaļ uz http:// pirmreizējo apmeklētāju noliek uz nešifrēta savienojuma, ko ikviens tajā pašā tīklā var nolasīt vai novirzīt.

Kas ir nepareizi

Vienai vai vairākām saknes adresēm līdz lapai vajag divas vai vairāk pāradresācijas, tās pa ceļam iet caur nešifrētu http://, izmanto pagaidu pāradresāciju, beidzas citā vietnē vai lapu nesasniedz nemaz.

Kā labot

1. Izlemiet vienu galīgo adresi un pārliecinieties, ka HTTPS darbojas katram nosaukumam. Lapa tiek rādīta adresē https://example.com, tāpēc tā ir adrese, uz kuru jānorāda visām pārējām. Pirms pievienojat jebkādu pāradresāciju, atveriet pārlūkā https:// otram nosaukumam (www.example.com): tas nedrīkst rādīt sertifikāta brīdinājumu. Let's Encrypt un Cloudflare sertifikāti aptver abus nosaukumus, ja abi ir norādīti; ja kāda trūkst, vispirms pievienojiet to sertifikātam, citādi katra pāradresācija no šī nosaukuma sāksies ar brīdinājumu.

2. Iestatiet vienu pastāvīgu pāradresāciju no katras pārējās saknes adreses tieši uz galīgo. Izmantojiet noteikumu tai vietai, kur Jūsu vietne atbild (hostinga pakalpojuma sniedzējs to var pateikt): vienu noteikumu, kas shēmu un www apstrādā vienā solī, nevis divus noteikumus vienu pēc otra. Izmantojiet 301, nekad 302 vai 307, un saglabājiet ceļu un vaicājuma virkni.

Apache vai LiteSpeed (arī Plesk un cPanel hostings ar Apache): vietnes galvenās mapes .htaccess failā, virs rindas „# BEGIN WordPress“

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]

nginx: vietnes server bloki

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name www.example.com;
    # the certificate must cover www.example.com
    return 301 https://example.com$request_uri;
}

Cloudflare, ja vietne ir aiz tā: Rules → Redirect Rules → Create rule

When incoming requests match (custom filter expression):
    http.host eq "www.example.com"

Then: Dynamic redirect, status code 301, preserve query string:
    concat("https://example.com", http.request.uri.path)
  • Plesk: Websites & Domains → Hosting Settings: iestatiet „Preferred domain“ uz izvēlēto formu (https://example.com) un atzīmējiet „Permanent SEO-safe 301 redirect from HTTP to HTTPS“. Plesk tad katru pārējo saknes adresi sūta uz galīgo vienā solī.
  • cPanel: Domains → Redirects: pastāvīga (301) aizstājējzīmes pāradresācija no otra nosaukuma uz galīgo adresi, „Redirect with or without www“ — vai augstāk dotais .htaccess noteikums.
  • Ja CDN vai slodzes balansētājs HTTPS beidz pirms servera, serveris redz nešifrētu http://, un augstāk dotais .htaccess noteikums veido ciklu. Pārbaudiet galveni „X-Forwarded-Proto“, nevis %{HTTPS}, vai iestatiet pāradresāciju CDN pusē, kā ar Cloudflare.
  • Pēc tam noņemiet katru citu pāradresācijas noteikumu šīm adresēm (vecāku „piespiest HTTPS“ spraudni, otru vadības paneļa pāradresāciju): tieši divi noteikumi rada divus lēcienus.

3. Lieciet pārlūkiem jau no sākuma izmantot https://. Kad https:// darbojas abiem nosaukumiem, sūtiet galveni Strict-Transport-Security: max-age=31536000; includeSubDomains abiem. Pārlūks, kas vietni reiz apmeklējis, vairs nekad nemēģina http://, tāpēc atkārtotiem apmeklētājiem http:// lēciens izzūd. Pievienojiet „preload“ un iesniedziet domēnu hstspreload.org tikai tad, kad katrs apakšdomēns darbojas caur HTTPS.

4. Pārbaudiet. Vaicājiet katrai saknes adresei tās pirmo atbildi: katrai, izņemot galīgo adresi, jāatbild ar 301 un galīgo adresi laukā „location“, bet galīgajai adresei jāatbild ar 200:

Terminālī

curl -sI http://www.example.com/ | grep -i '^HTTP\|^location'
curl -sI https://www.example.com/ | grep -i '^HTTP\|^location'
curl -sI http://example.com/ | grep -i '^HTTP\|^location'
curl -sI https://example.com/ | grep -i '^HTTP\|^location'

Pēc tam palaidiet šo pārbaudi vēlreiz: tā seko visām četrām adresēm un uzskaita katru lēcienu.

Make every root address of my website reach the page in one permanent redirect: http://www.example.com/, https://www.example.com/ and http://example.com/ must each answer 301 straight to https://example.com (same path and query), never via http:// on the way, and https://example.com/ must answer 200.
The site is not known to be behind a CDN.

Steps:
1. Make sure the certificate covers example.com and www.example.com (no warning on https:// for either name).
2. Replace all existing redirect rules for these addresses with ONE rule that handles scheme and host in the same step: on Cloudflare a Single Redirect `http.host eq "www.example.com"` → `concat("https://example.com", http.request.uri.path)` (301, preserve query string) with Always Use HTTPS left on; on Apache/LiteSpeed a RewriteCond %{HTTPS} off [OR] / RewriteCond %{HTTP_HOST} ^www\.example\.com$ / RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L] block above # BEGIN WordPress; on nginx a port-80 server block for both names and a port-443 block for www.example.com, each `return 301 https://example.com$request_uri;`. Behind a TLS-terminating proxy test X-Forwarded-Proto, not %{HTTPS}.
3. Remove the other rules (control panel redirects, force-HTTPS / force-www plugins) so no address takes two hops.
4. Send `Strict-Transport-Security: max-age=31536000; includeSubDomains` on both names once https:// works on both.
5. Verify with curl -sI on all four root addresses: three answer 301 with location https://example.com/… in one hop, the final one 200; show me the output.
Tell me exactly which files or settings you changed.

Resources:
- Google Search Central, redirects and Google Search: https://developers.google.com/search/docs/crawling-indexing/301-redirects
- Cloudflare, Single Redirects: https://developers.cloudflare.com/rules/url-forwarding/single-redirects/

Pārbaudiet savu vietni, lai uzzinātu, vai tai ir šī problēma. Pārbaudīt vietni