Lanțul de redirecționări și SEO: câte salturi sunt prea multe?

Un lanț de redirecționări înseamnă două sau mai multe redirecționări la rând între URL-ul cerut de cineva și pagina care răspunde în cele din urmă cu 200. Google documentează că Googlebot urmărește până la 10 salturi, recomandă redirecționarea directă la destinația finală și enumeră lanțurile lungi ca pe o frână pentru crawl. Nu spune că ele distrug poziționarea și spune că redirecționările permanente nu provoacă o pierdere de PageRank. Așadar, rezumatul sincer este că lanțurile sunt o problemă de latență și de eficiență a crawl-ului pe care ar trebui s-o repari ieftin, nu o catastrofă SEO.

Majoritatea lanțurilor nu sunt construite intenționat. Cineva adaugă o regulă HTTPS, altcineva adaugă o regulă www, un instrument de marketing învelește linkul într-un tracker, iar fiecare salt este rezonabil în sine. Mai jos: cum se stivuiesc straturile, cât costă fiecare salt, care afirmații SEO rezistă în fața documentației Google și cum urmărești și aplatizezi un lanț. Pentru vocabularul codurilor de stare, tipurile de redirecționări URL sunt harta. Dacă lanțul se întoarce asupra lui, vrei în schimb cum repari o buclă de redirecționare.

Ce este un lanț de redirecționări

Un lanț de redirecționări apare când URL-ul A redirecționează către B, iar B redirecționează către C, în loc ca A să indice direct spre C. Fiecare săgeată este propriul ei răspuns HTTP, iar clientul face o cerere nouă pentru fiecare. O redirecționare este normală; "lanț" începe de la două.

Redirecționări multiple și salturi de redirecționare descriu același lucru din unghiuri diferite: numărul de redirecționări între cerere și pagina finală. O buclă de redirecționare este un lanț care nu se termină niciodată, pentru că revine la un URL. Un lanț, în schimb, se termină; doar că durează prea mult până acolo.

Cum se formează lanțurile de redirecționări

Lanțurile se stivuiesc pentru că fiecare strat își impune propria preferință. Straturile obișnuite, în ordinea în care le întâlnește o cerere:

• Schema. http:// trece la https://, de obicei printr-o regulă a serverului sau a proxy-ului.
• Gazda. Apex-ul trece la www, sau invers, printr-o altă regulă care se declanșează după regula schemei.
• Calea. Un normalizator pentru bara oblică finală sau pentru litere mici rescrie /Promo/ în /promo.
• Învelișul de campanie sau de urmărire. Un tracker de clicuri din reclame, un rescriitor de linkuri al unei platforme de e-mail sau un link scurt stă în fața tuturor celorlalte.
• Harta moștenită. O redirecționare dintr-un redesign trecut pe care nimeni nu a mai reorientat-o.

Pune-le laolaltă și un simplu http://example.com/Promo/ poate face patru salturi: la HTTPS, apoi la www, apoi la calea normalizată, apoi printr-o regulă veche de redesign până la pagina activă. Linkurile scurte se alătură la început. Unul este un salt legitim. Răul începe când destinația lui nu este URL-ul final. Lipește http://example.com/promo ca țintă și linkul tău conduce un lanț pe care site-ul de destinație l-a construit, nevăzut. Dăunează scurtătoarele de URL-uri SEO-ului tratează partea de poziționare a acestei întrebări; pe scurt, un salt curat este în regulă, iar unul stivuit este al tău de reparat.

Lanțurile sunt ușor de ratat pentru că browserele le ascund: bara de adresă arată URL-ul final și pagina se încarcă, deci nimic nu pare greșit. Ele apar și doar pentru varianta de cerere care activează fiecare regulă, de obicei cel mai vechi link http:// de pe cel mai vechi material tipărit.

Câte salturi urmărește Googlebot?

Googlebot urmărește implicit până la 10 salturi de redirecționare. Aceasta vine direct din documentația crawlerului Google. Aceasta adaugă că anumite produse Google pot folosi limite diferite și că instrumentul URL Inspection nu urmează deloc redirecționările. Google nu precizează ce se întâmplă cu un lanț mai lung, așa că presupune că ținta pur și simplu nu este atinsă.

Zece este un plafon, nu o recomandare. Ghidul Google pentru mutarea unui site spune să redirecționezi direct la destinația finală și, când nu se poate, să ții lanțul scurt, "ideally no more than 3 and fewer than 5", pentru că înlănțuirea adaugă latență pentru utilizatori și nu toți agenții utilizator acceptă lanțuri lungi. Citează asta: un obiectiv de un salt, o toleranță de câteva și o oprire fermă la zece.

Browserele au propriile limite. Chrome renunță la 20 și returnează ERR_TOO_MANY_REDIRECTS, simptomul tratat în ghidul despre bucla de redirecționare. Nici standardul HTTP nu fixează un număr: RFC 9110 spune doar că clienții ar trebui să detecteze și să intervină în redirecționările ciclice.

Cât costă fiecare salt în latență

Fiecare salt costă cel puțin un drum dus-întors prin rețea. Un salt către un alt hostname costă mai mult. Clientul rezolvă noul nume, deschide o conexiune TCP și încheie un handshake TLS înainte să poată trimite ceva. Auditul propriu al Lighthouse pică o pagină cu două sau mai multe redirecționări și spune că drumul suplimentar poate întârzia o resursă "by hundreds of milliseconds."

Iată aritmetica, ca ilustrare și nu ca benchmark. Presupune un drum dus-întors de 100 ms, obișnuit pentru o conexiune mobilă cu semnal mediocru. Un salt către o gazdă nouă, cu DNS, TCP și un handshake TLS 1.3 înainte de cerere, poate costa ușor trei-patru drumuri dus-întors, deci 300 până la 400 ms. Un salt care refolosește o conexiune deschisă către aceeași gazdă costă unul, deci 100 ms. Un lanț cu patru salturi și două conexiuni noi consumă atunci aproximativ 900 ms înainte ca pagina reală să înceapă, față de cam 450 ms pentru o singură redirecționare plată.

Mobilul înrăutățește lucrurile dintr-un motiv simplu: latența, nu lățimea de bandă, este constrângerea. Răspunsurile de redirecționare sunt minuscule, deci așteptarea este făcută numai din drumuri dus-întors, iar un abonament mai rapid nu face nimic pentru ele. Ștergerea unui salt este adesea mai ieftină decât micșorarea unei imagini. Pentru cât ar trebui să coste un singur salt pe partea de server, vezi cum coboară redirecționările sub 15 ms.

Lanțurile pierd și date. Fiecare salt este un loc unde o regulă de rescriere poate elimina un șir de interogare, iar un utm_source eliminat este modul obișnuit în care parametrii UTM dispar din analiză.

Link equity și bugetul de crawl: ce documentează Google

Mai întâi link equity. Documentația Google pentru mutarea unui site afirmă că "301 and other permanent redirects don't cause a loss in PageRank". Gary Illyes de la Google a spus același lucru despre redirecționările 30x în 2016, dar aceea a fost o postare socială, nu documentație. Deci vechea regulă empirică potrivit căreia fiecare salt de redirecționare scurge un procent fix de equity este folclor. Nicio sursă Google nu dă un procent, iar numere precum 15 procente le vei vedea repetate în articole SEO fără citare. Dacă cineva îți dă unul, cere sursa.

Lanțurile tot nu sunt gratuite. Sunt documentate două efecte. Primul, eficiența crawl-ului: ghidul Google despre bugetul de crawl pentru site-uri mari spune clar să eviți lanțurile lungi de redirecționări, care au un efect negativ asupra crawl-ului. Al doilea, latența pentru utilizator, tratată mai sus, care alimentează semnalele de experiență a paginii. Bugetul de crawl contează mai ales pe site-uri foarte mari sau care se schimbă rapid; un site de 200 de pagini este puțin probabil să simtă o problemă de buget de crawl din câteva lanțuri, deși vizitatorii tot simt costul de viteză.

Există și o nuanță de indexare. Google folosește redirecționările permanente ca semnal canonic pentru țintă. Care URL este afișat depinde în parte de dacă fiecare redirecționare a fost temporară sau permanentă. Un lanț care amestecă salturi 301 și 302 face acest semnal mai puțin clar, un motiv bun să stabilești codurile o singură dată. Canonical vs redirecționare 301 intră în detaliu despre cum interacționează aceste semnale.

Poziția mea: nu intra în panică din cauza equity, repară lanțurile pentru viteză și igienă de crawl și nu promite o creștere de poziționare din aplatizarea unuia. Nimeni nu a documentat o astfel de creștere. Încărcările mai rapide și mai puține preluări irosite sunt ceea ce poți măsura.

Cum detectezi lanțurile de redirecționări

Începe cu curl, pentru că afișează fiecare salt acolo unde un browser le ascunde. Prima comandă arată linia de stare și Location al fiecărui răspuns:

curl -sIL http://example.com/Promo/ | grep -E '^HTTP|^[Ll]ocation'

Un rezultat curat este un 3xx, apoi un 200. Un lanț arată mai întâi două sau mai multe linii 3xx. Pentru un număr și pentru timpul petrecut în redirecționări, cere-i lui curl propriile cifre:

curl -sL -o /dev/null \
  -w 'hops: %{num_redirects}\nfinal: %{url_effective}\nredirect time: %{time_redirect}s\ntotal: %{time_total}s\n' \
  http://example.com/Promo/

Două avertismente. -I trimite o cerere HEAD, iar câteva servere răspund diferit la HEAD față de GET, deci dacă rezultatul pare prea curat, repetă fără -I și aruncă corpul cu -o /dev/null -D -. Și testează varianta cea mai rea, cea care ar declanșa fiecare regulă: http://, fără www, cale cu majuscule, bară oblică finală. Testarea doar a URL-ului canonic este modul în care supraviețuiesc lanțurile. Prefer să testez în exces variantele urâte decât să am încredere în cea curată.

Într-un browser, deschide devtools, mergi la panoul Network, bifează "Preserve log" ca salturile anterioare să supraviețuiască navigării și reîncarcă. Fiecare redirecționare apare ca propriul rând 301 sau 302. Verificatorul nostru de linkuri arată același lanț fără un terminal.

Pentru a audita un site întreg, un crawler desktop precum Screaming Frog sau Sitebulb are un raport de lanțuri de redirecționări care listează fiecare lanț cu toate salturile și codurile de stare. Pentru linkuri cu viață lungă, pune aceeași urmărire într-un job programat, ca în monitorizarea redirecționărilor de linkuri.

Cum aplatizezi un lanț de redirecționări

A aplatiza înseamnă că fiecare URL moștenit indică direct URL-ul final. Pașii, în ordine:

1. Alege forma canonică: schema, gazda, politica pentru bara oblică finală și literele mari sau mici. Notează-o.
2. Urmărește fiecare URL vechi și înregistrează destinația lui finală.
3. Rescrie fiecare regulă să țintească acea destinație finală, nu următoarea regulă.
4. Actualizează linkurile interne, sitemap-urile și etichetele rel="canonical" la URL-ul final, ca crawlerele și utilizatorii să nu mai intre deloc în lanț.
5. Rulează din nou urmărirea și confirmă cel mult un salt.

Trucul de pe partea serverului este să combini schema și gazda într-o singură regulă. În nginx arată așa, folosind $request_uri ca să supraviețuiască calea și șirul de interogare:

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

server {
    listen 443 ssl;
    server_name example.com;
    # ssl_certificate and key directives go here
    return 301 https://www.example.com$request_uri;
}

O cerere http://example.com/page merge acum la https://www.example.com/page într-un singur salt, acolo unde două reguli ar fi produs două. Configurarea unei redirecționări în .htaccess și cum redirecționezi un URL acoperă echivalentele pentru Apache și la nivel de aplicație.

Testează mai întâi cu 302. Browserele memorează agresiv în cache 301, așa că o greșeală persistă. Odată ce lanțul are un singur salt, treci la codul permanent. Ajută și HSTS: după ce un browser a văzut un antet Strict-Transport-Security, el face intern upgrade de la http:// la https://, deci vizitatorii care revin sar peste acel salt cu totul. Nu face nimic pentru crawlere sau pentru vizitatorii noi, deci completează regula unui singur salt și nu o înlocuiește.

Dacă lanțurile continuă să reapară, cauza este procesul, nu sintaxa; prevenirea degradării linkurilor descrie obiceiul de audit care oprește acumularea hărților vechi.

Cum arată o redirecționare corectă a unui link scurt

Un link scurt ar trebui să fie exact un salt de la slug la pagina canonică finală și nimic altceva. Cererea ajunge la domeniul scurt. Răspunsul este un 3xx cu destinația în Location. Destinația răspunde direct cu 200. Niciun scurtător intermediar, niciun tracker care redirecționează din nou, nicio destinație care face salt la www sau la HTTPS pentru că ai lipit forma veche.

Codul depinde de cazul de utilizare.

• 302 (sau 307) pentru linkuri urmărite și editabile din campanii, postări sociale, e-mail și coduri QR. Îți permite să reorientezi destinația mai târziu și face ca fiecare clic să ajungă la stratul de redirecționare, deci analiza rămâne completă.
• 301 (sau 308) când mutarea este permanentă și vrei ca destinația să fie tratată drept canonică, de exemplu un URL vanity care înlocuiește definitiv o adresă veche.

Redirecționările 301 vs 302 parcurg capcana de cache care face ca opțiunea implicită 302 să fie rezonabilă. Două obiceiuri țin lanțul la un salt. Lipește întotdeauna URL-ul final ca destinație, după ce l-ai încărcat o dată și ai copiat adresa din bară, și rulează numărătoarea curl de mai sus pe linkurile noi înainte de lansare. Dacă vrei ca acea destinație să fie stocată o singură dată și editabilă fără retipărire, începe cu un spațiu de lucru Elido gratuit și urmărește primul tău link cu comenzile din acest articol.

Terții pot adăuga salturi pe care nu le controlezi. Trackerul de clicuri al unei platforme de reclame sau învelișul de linkuri al unui furnizor de e-mail stă în fața linkului tău scurt, fie că îți place sau nu, ceea ce este cel mai bun argument pentru a ține partea ta de traseu la un salt. Un domeniu de brand nu adaugă unul, după cum explică domeniile personalizate pentru linkuri scurte.

Acest articol se află în clusterul de inginerie. Pentru harta completă a codurilor de stare, citește tipurile de redirecționări URL, iar pentru stratul de redirecționare din spatele unui link scurt, cum funcționează scurtătoarele de URL-uri.

Alte articole de pe blog

• Buclă de redirecționare: cum găsești și repari ERR_TOO_MANY_REDIRECTS
• Tipuri de redirecționări URL: 301, 302, 307, 308 și altele
• Redirecționări 301 vs 302: pe care ar trebui să-l folosească linkurile scurte
• Dăunează scurtătoarele de URL-uri SEO-ului? Răspunsul sincer
• Canonical vs redirecționare 301: cum alegi semnalul potrivit
• Cum redirecționezi un URL: șase moduri și când este potrivit fiecare