O redirecționare este un răspuns HTTP: un status 301 sau 302 cu un antet Location care îi spune browserului unde să meargă în schimb. Asta e tot ce este ea pe fir, ceea ce înseamnă că întrebarea nu este cu adevărat cum redirecționezi un URL, ci care strat din fața site-ului tău ar trebui să fie cel care răspunde.
Șase straturi pot face treaba, și nu sunt interschimbabile. Diferă prin cine servește răspunsul, dacă calea și query string-ul supraviețuiesc călătoriei, cât de repede te poți răzgândi, și cât de mult din configurare deții. Acest ghid parcurge toate cele șase, tabelul care alege între ele, și cele două verificări care separă o redirecționare care funcționează de una care îți mănâncă pe tăcute parametrii de campanie. Pentru codurile de status în sine, tipurile de redirecționări URL este referința de dedesubtul acestuia.
Unde locuiește de fapt o redirecționare
Începe cu mitul, pentru că irosește mai multe după-amiezi decât oricare altul: DNS-ul nu poate redirecționa un URL. O înregistrare DNS mapează un hostname către o adresă. Nu vede niciodată calea, nu vede niciodată query string-ul, și nu are niciun mecanism prin care să spună "du-te în altă parte în schimb". O înregistrare A sau CNAME indică; nu redirecționează.
Așa că, atunci când registratorul tău oferă "redirecționare URL", ceea ce face de fapt este să îndrepte hostname-ul către un mic server web pe care îl rulează ei, care returnează redirecționarea HTTP în numele tău. Util, și perfect legitim, dar un server web face treaba, nu DNS-ul. Odată ce vezi lucrurile așa, cele șase metode de mai jos încetează să mai pară alternative și încep să pară o singură întrebare: ce mașină din calea cererii vrei să răspundă?
Șase locuri unde poți pune o redirecționare
Fiecare dintre acestea se termină cu același răspuns pe fir. Ce diferă este costul configurării, cine o controlează, și ce se întâmplă cu tot ce vine după numele domeniului.
Redirecționarea domeniului la registrator
Cea mai rapidă opțiune, și cea mai brutală. În panoul de control al registratorului tău, îndrepți domeniul către o destinație și alegi permanent sau temporar. Bună pentru un domeniu cumpărat defensiv, un rebranding în care numele vechi ar trebui pur și simplu să predea ștafeta, sau un domeniu de campanie de scurtă durată.
Capcana este ce face cu restul URL-ului: majoritatea redirecționărilor la registrator aplatizează fiecare cerere către singura destinație configurată de tine, așa că un link adânc ajunge pe pagina principală. Unele oferă un mod care păstrează calea; verifică înainte să te bazezi pe el.
O regulă în serverul tău web
Dacă rulezi nginx sau Apache, redirecționarea aparține aici, pentru că obții control exact asupra potrivirii și păstrării. Documentația Apache despre remaparea URL-urilor cu reguli de rewrite acoperă tiparele, iar referința modulului de rewrite al nginx acoperă return 301 și rewrite ... permanent, care este calea rapidă pentru o mutare simplă.
Regulile de server sunt instrumentul potrivit pentru impunerea hostului canonic și a HTTPS, rescrieri de cale după o restructurare, și orice e condițional. Sunt și locul unde regulile de redirecționare se acumulează pe tăcute de-a lungul anilor, așa că tratează fișierul ca pe ceva de curățat, nu doar de adăugat la el.
O regulă la platforma ta de hosting
Majoritatea gazdelor moderne stau în fața originii și oferă propriul lor strat de redirecționare: un fișier _redirects, un bloc de configurare, o interfață de reguli în dashboard. Acestea sunt evaluate înainte ca aplicația ta să ruleze, ceea ce le face rapide și sigure, și sunt de obicei cel mai bun loc pentru redirecționări în masă după o migrare de site, pentru că trăiesc în controlul versiunilor, alături de restul proiectului.
Un plugin sau o setare în CMS-ul tău
Fiecare CMS serios are un manager de redirecționări, iar pentru o echipă de conținut este răspunsul potrivit: fără deploy, fără acces la server, o urmă de audit, și o persoană care înțelege conținutul luând decizia de mapare. Compromisul este că cererea trebuie să ajungă la aplicație înainte ca redirecționarea să fie emisă, așa că este mai lentă decât straturile de mai sus și încetează să funcționeze dacă aplicația este picată.
Meta refresh sau JavaScript pe pagină
Ultima soluție, pentru când nu poți atinge nimic de partea serverului. Pagina se încarcă, apoi trimite vizitatorul mai departe cu o etichetă <meta http-equiv="refresh"> sau un script. Funcționează, dar costă o încărcare completă de pagină, depinde de clientul care o execută, iar motoarele de căutare o tratează ca pe un semnal mai slab decât un răspuns de server. Folosește-o atunci când alternativa este nimic.
Un link scurt gestionat
Când lucrul redirecționat este un link pe care l-ai publicat, nu o pagină pe care o deții, redirecționarea aparține unui manager de linkuri. Destinația este o valoare stocată pe care o poți schimba fără să atingi DNS-ul, serverele, sau un pipeline de deploy, fiecare hop este înregistrat, iar linkul continuă să funcționeze după ce a fost tipărit sau distribuit. Acesta este întregul mecanism din spatele a ceea ce este un scurtător de URL-uri, și de aceea un link de campanie tipărit nu ar trebui niciodată să indice direct către o pagină de destinație.
Alegerea uneia în treizeci de secunde
Cea mai mare parte a deciziei se reduce la două coloane: cine are acces, și ce trebuie să supraviețuiască.
| Metodă | Cine o servește | Calea și query-ul păstrate | Cel mai potrivit pentru |
|---|---|---|---|
| Redirecționare la registrator | Serverul registratorului | Adesea nu, verifică întâi | Predarea întregului domeniu |
| Regulă de server web | Originea ta | Da, dacă e scrisă așa | Host canonic, restructurare |
| Regulă de platformă | Gazda din față | Da | Redirecționări de migrare în masă |
| Plugin CMS | Aplicația ta | Da | Echipă de conținut, fără deploy-uri |
| Meta refresh sau JS | Browserul | Da, dar încet | Fără niciun acces la server |
| Link scurt gestionat | Serviciul de linkuri | Da, din URL-ul stocat | Linkuri publicate și tipărite |
Păstrarea căii și a query string-ului
Acesta este eșecul care supraviețuiește testării, pentru că toată lumea testează rădăcina domeniului, iar rădăcina funcționează întotdeauna.
Îndreaptă oldsite.com către newsite.com cu o redirecționare simplă de domeniu, apoi urmărește un link real de intrare, oldsite.com/pricing?utm_source=newsletter. Cu o redirecționare care aplatizează, acel vizitator ajunge pe noua pagină principală, calea a dispărut, iar parametrii de campanie au dispărut o dată cu ea. Nimic nu dă eroare. Analizele tale arată pur și simplu trafic direct către pagina principală, iar newsletterul pare că nu a făcut nimic.
Două obiceiuri previn asta. Testează cu un URL adânc, care poartă un query string, niciodată cu domeniul simplu. Și când cele două site-uri au structuri diferite, mapează explicit căile importante, în loc să trimiți totul către rădăcină, ceea ce este și ce păstrează valoarea SEO a URL-urilor vechi atașată de cea mai apropiată pagină nouă potrivită. Aceeași disciplină se aplică atunci când moștenești linkurile altcuiva, motiv pentru care migrarea linkurilor scurte fără să le strici este mai întâi un exercițiu de mapare, și abia apoi unul tehnic.
Dacă linkurile în cauză sunt unele pe care le-ai publicat tu, păstrarea destinației editabile valorează mai mult decât orice din toate astea: pune-ți linkurile pe propriul domeniu și maparea devine un câmp pe care îl schimbi, nu un fișier de configurare pe care îl faci deploy.
Verifică-o înainte s-o anunți
O singură comandă lămurește totul:
curl -sIL "https://oldsite.com/pricing?utm_source=newsletter" | grep -E '^HTTP|^[Ll]ocation'
Citește trei lucruri în output. Codul de status ar trebui să fie cel intenționat, 301 pentru permanent și 302 cât timp lucrurile sunt încă în mișcare, iar 301 vs 302 explică de ce alegerea asta contează mai mult decât pare. Antetul Location ar trebui să poarte calea completă și query string-ul, nu un domeniu simplu. Și ar trebui să existe exact o singură redirecționare: un lanț de trei sau patru tot se rezolvă, dar fiecare hop înseamnă latență și încă o șansă de a pierde parametri, iar un hostname repetat înseamnă că ai construit o buclă de redirecționare, nu o redirecționare.
Dacă preferi să nu deschizi deloc un terminal, verificatorul nostru de linkuri urmărește lanțul și afișează statusul la fiecare hop.
Ce fac motoarele de căutare cu ea
O redirecționare făcută corect nu este un risc SEO, iar recomandările sunt neobișnuit de clare în privința asta. Documentația Google despre redirecționări și Search tratează o redirecționare permanentă de partea serverului ca pe cel mai puternic semnal pentru consolidarea unui URL pe înlocuitorul lui, clasează redirecționările de partea clientului sub aceasta, și cere ca lanțurile să rămână scurte.
Cele două greșeli care chiar te costă sunt colapsarea multor URL-uri vechi pe pagina principală, ceea ce aruncă relevanța specifică pe care o avea fiecare, și păstrarea unui lanț de hop-uri istorice după mai multe migrări. Niciuna nu e un motiv să eviți redirecționările; ambele sunt motive să le auditezi. Acel audit este același obicei săptămânal ca prevenirea degradării linkurilor, iar dacă redirecționarea este pe un domeniu scurt personalizat, domenii personalizate pentru linkuri scurte acoperă jumătatea de DNS și certificat a configurării.
Alege stratul care se potrivește cu cine deține schimbarea, păstrează calea, ține-o la un singur hop, și o redirecționare încetează să mai fie ceva de care să te îngrijorezi.
Citește seria fundamentală
Acest articol face parte din clusterul tutorials. Pentru codurile de status și semantica lor, tipurile de redirecționări URL este harta, iar cum funcționează scurtătoarele de URL-uri acoperă ce se întâmplă când redirecționarea este un link, nu o pagină.
Alte articole de pe blog
- Tipuri de redirecționări URL: 301, 302, 307, 308 și altele
- Redirecționări 301 vs 302: pe care ar trebui să o folosească linkurile scurte
- Buclă de redirecționare: cum găsești și repari ERR_TOO_MANY_REDIRECTS
- Domenii personalizate pentru linkuri scurte: DNS, TLS și edge
- Migrează de la Bitly fără să-ți strici linkurile
- Strică scurtătoarele de URL-uri SEO-ul? Mecanismele care contează
Întrebări frecvente
Cum redirecționez un URL către alt URL?
Fă ca orice servește cererea să returneze un 301 sau 302 cu un antet Location care indică noua adresă. În practică, asta înseamnă să alegi un strat: redirecționarea domeniului la registratorul tău, o regulă în serverul tău web sau la platforma de hosting, un plugin în CMS-ul tău, sau un link scurt gestionat. Metoda schimbă cine servește răspunsul și dacă calea și query string-ul supraviețuiesc, nu ce primește browserul.
Pot redirecționa un URL cu DNS?
Nu, iar aceasta este cea mai comună neînțelegere din tot acest subiect. DNS rezolvă un hostname către o adresă; nu are nicio idee despre ce cale a fost cerută și nu poate returna o redirecționare. Când un registrator oferă redirecționare URL, de fapt îndreaptă hostname-ul către un mic server web de-al lui, care emite redirecționarea HTTP în numele tău.
O redirecționare păstrează calea și query string-ul?
Depinde în întregime de metoda aleasă. Redirecționarea domeniului la registrator aplatizează adesea totul către o singură destinație, așa că /pricing?utm_source=email ajunge pe pagina principală, cu parametrii dispăruți. O regulă de server sau de platformă poate păstra ambele, dacă o scrii în acest fel, iar un link scurt gestionat redirecționează către destinația stocată, inclusiv query string-ul ei. Testează cu un URL adânc, nu doar cu rădăcina domeniului.
Ar trebui să folosesc o redirecționare 301 sau 302?
Folosește un 301 atunci când mutarea este permanentă și vrei ca motoarele de căutare să consolideze semnalele pe noul URL, și un 302 cât timp ceva este încă în mișcare. Capcana practică este că browserele stochează în cache un 301 foarte agresiv, așa că o redirecționare permanentă de care te răzgândești mai târziu continuă să se declanșeze pentru vizitatorii care revin, mult după ce ai schimbat serverul. Testează cu un 302, promovează la 301 abia după ce destinația s-a stabilizat.
Cum verific dacă redirecționarea mea funcționează?
Rulează curl -sIL asupra URL-ului și citește liniile de status și anteturile Location. Vrei o singură redirecționare, codul de status corect, și destinația pe care o aștepți, cu calea și query-ul intacte. Un lanț de mai multe hop-uri tot funcționează, dar irosește latență, iar un hostname repetat înseamnă că ai construit o buclă, nu o redirecționare.
Redirecționările strică SEO-ul?
O redirecționare implementată corect nu o face. Google tratează un 301 ca un semnal puternic pentru a consolida clasarea pe destinație, iar lanțurile lungi, nu redirecționările în sine, sunt cele care cauzează probleme. Păstreaz-o la un singur hop, îndreaptă URL-urile vechi către cea mai apropiată pagină nouă potrivită, în loc să arunci totul pe pagina principală, și evită redirecționările de partea clientului atunci când una de partea serverului este posibilă.
Încearcă Elido
Lipește un URL, obții un link scurt funcțional
Fără înregistrare. Linkul este activ timp de 30 de zile. Înregistrează-te ca să-l păstrezi pentru totdeauna.
Gratuit, fără înregistrare · 2 pe zi