Pe scurt
Un redirect 301 este răspunsul prin care serverul anunță că o pagină s-a mutat definitiv la altă adresă: vizitatorul ajunge automat pe adresa nouă, iar Google o indexează în locul celei vechi. Îl folosești când muți sau redenumești pagini, când treci pe HTTPS și când schimbi domeniul, câte un redirect pentru fiecare adresă veche.
Ce este un redirect 301
Un redirect 301, în română redirecționare permanentă, este codul de stare HTTP „301 Moved Permanently”, prin care serverul răspunde că pagina cerută s-a mutat definitiv la adresa din antetul Location. Browserul cere imediat adresa nouă, iar motoarele de căutare înțeleg că adresa veche a fost înlocuită.
MDN Web Docs, documentația Mozilla, îl descrie ca pe răspunsul care indică mutarea permanentă a resursei cerute la o altă adresă, iar Wikipedia adaugă consecința practică: linkurile și înregistrările spre adresa veche ar trebui actualizate. Schimbul dintre browser și server arată așa:
GET /servicii-vechi.html HTTP/1.1
Host: exemplu.ro
HTTP/1.1 301 Moved Permanently
Location: https://exemplu.ro/servicii/
Redirectul se face pe server. Există și redirecționări din pagină, prin meta refresh sau prin JavaScript, dar documentația Google Search Central le tratează ca soluții de rezervă, pentru situațiile în care nu ai acces la server.
Redirect 301, 302, 307 sau 308: care e diferența
301 și 308 sunt redirecturi permanente, 302 și 307 sunt temporare. În fiecare pereche, diferența e metoda cererii: 307 și 308 o păstrează, deci un formular trimis prin POST rămâne POST, pe când la 301 și 302 browserele pot transforma cererea în GET.
| Cod | Tip | Metoda cererii | Când îl folosești |
|---|---|---|---|
| 301 Moved Permanently | Permanent | Poate deveni GET | Pagină mutată sau redenumită, trecere pe HTTPS, domeniu nou |
| 302 Found | Temporar | Poate deveni GET | Pagină scoasă pentru scurt timp, trimitere temporară spre altă pagină |
| 307 Temporary Redirect | Temporar | Păstrată | Redirecționare temporară pentru formulare sau API-uri |
| 308 Permanent Redirect | Permanent | Păstrată | Mutare definitivă când contează metoda; codul implicit al unor framework-uri, cum e Next.js |
Este un redirect 302 permanent? Nu. Un 302 îi spune lui Google că pagina veche revine, așa că adresa veche poate rămâne în rezultate. Pentru o mutare definitivă e alegerea greșită, chiar dacă vizitatorul nu vede nicio diferență.
Folosesc 301 sau 308? Pentru Google sunt echivalente: documentația Google Search Central spune că 301 și 308 înseamnă amândouă că pagina s-a mutat permanent. La paginile obișnuite poți folosi oricare; 308 contează la adresele care primesc formulare sau cereri de API, unde metoda trebuie păstrată.
Ce spune Google despre redirecturi
Google tratează un redirect permanent de pe server ca pe un semnal puternic că adresa nouă trebuie afișată în rezultate, iar unul temporar ca pe un semnal slab, după care poate păstra adresa veche. Documentația Google Search Central despre redirecturi mai precizează că:
- un meta refresh instant e interpretat ca permanent, iar unul cu întârziere ca temporar;
- redirecturile din JavaScript sunt urmate după randarea paginii și sunt recomandate doar când nu ai altă variantă;
- multe adrese vechi trimise spre o pagină fără legătură cu ele, de obicei prima pagină, pot fi tratate ca soft 404, adică pagini fără conținutul căutat;
- după mutarea unui site, fluctuațiile de trafic sunt normale o vreme.
Redirectul e unul dintre semnalele după care Google alege adresa canonică, alături de eticheta canonical, sitemap și linkurile interne. Când toate arată spre aceeași adresă, alegerea e simplă; când se contrazic, Google poate alege altă adresă decât cea dorită. Cum ajunge Google la pagini și cum le clasează găsești în ghidul despre SEO pentru firme mici.
Harta de redirecturi: fiecare adresă veche spre cea mai apropiată adresă nouă
Harta de redirecturi este tabelul în care fiecărei adrese vechi îi asociezi adresa nouă cu același subiect și codul de răspuns. O faci înainte de lansare, nu după ce apar erorile. Inventarul adreselor și pașii unei relansări sunt în ghidul despre când și cum refaci un site; aici contează regulile după care completezi harta:
- Unu la unu, spre cea mai apropiată pagină ca subiect. Un serviciu renunțat merge spre categoria din care făcea parte, nu spre homepage.
- 404 sau 410 când nu există echivalent, de exemplu pentru o promoție încheiată.
- Direct la destinația finală, adică la adresa care răspunde cu 200.
- Toate formele adresei vechi: cu și fără slash final, cu majuscule, cu parametri de tipul ?p=412, dacă apar în linkuri sau în Search Console.
| Adresa veche | Adresa nouă | Cod | De ce |
|---|---|---|---|
| /servicii/implanturi-dentare/ | /implant-dentar | 301 | Același serviciu, adresă nouă |
| /?p=412 | /ghiduri/periaj-corect | 301 | Articol vechi, rescris |
| /servicii/albire-laser/ | /estetica-dentara | 301 | Serviciu inclus într-o pagină mai largă |
| /promotie-vara/ | — | 410 | Campanie încheiată, fără echivalent |
Să zicem că o clinică stomatologică din București își mută site-ul de pe WordPress pe o platformă construită în cod, cu adrese noi, fără slash final. Harta are un rând pentru fiecare serviciu și pentru fiecare articol cu vizite din Google. Când lista adreselor vechi trece printr-un crawler, apar și adrese care nu erau în sitemap: PDF-uri cu liste de prețuri și pagini de campanie, cu linkuri din alte site-uri. Primesc și ele un rând în hartă înainte de lansare, nu după ce apar ca erori 404.
Lanțuri și bucle de redirecționare
Un lanț apare când o adresă veche trece prin mai multe redirecționări până la pagina finală (A spre B, apoi B spre C); o buclă, când redirecționările se întorc la punctul de plecare. Lanțurile adaugă timp la fiecare salt, iar Google, potrivit documentației lui, urmează doar un număr limitat de salturi. Buclele fac pagina imposibil de deschis: Chrome afișează eroarea ERR_TOO_MANY_REDIRECTS.
Un scenariu frecvent: un site a trecut cândva pe HTTPS, apoi a renunțat la www, iar acum se relansează cu adrese noi. Fiecare schimbare a adăugat o regulă peste cele vechi, așa că http://www.exemplu.ro/contact.php face trei salturi până la /contact. Rezolvarea e să rescrii regulile astfel încât orice formă a adresei vechi să ajungă direct la destinație.
Buclele au de obicei una dintre trei cauze: un CDN sau un proxy care cere paginile de la server pe HTTP, în timp ce serverul forțează HTTPS; două setări contradictorii, de exemplu panoul de găzduire trimite www spre varianta fără www, iar configurația serverului face invers; o regulă care se potrivește și pe propria destinație, ca /blog/:path* trimis spre /blog/arhiva/:path*.
HTTP spre HTTPS și www spre fără www, într-un singur salt
Orice pagină are patru variante de adresă: cu sau fără HTTPS, cu sau fără www. Alegi una ca versiune principală, iar celelalte trei trimit direct la ea, printr-un singur redirect 301.
| Adresa cerută | Răspunsul corect |
|---|---|
| http://exemplu.ro/contact | 301 spre https://exemplu.ro/contact |
| http://www.exemplu.ro/contact | 301 direct spre https://exemplu.ro/contact, nu prin https://www |
| https://www.exemplu.ro/contact | 301 spre https://exemplu.ro/contact |
| https://exemplu.ro/contact | 200, pagina |
Alegerea dintre www și varianta fără www e o preferință; important e să fie aceeași peste tot: în redirecturi, în eticheta canonical, în sitemap, în linkurile interne și în Search Console. Certificatul trebuie să acopere ambele nume, altfel adresa https://www afișează un avertisment de securitate înainte ca redirectul să apuce să funcționeze; ce acoperă un certificat afli din ghidul despre certificatul SSL și HTTPS. Pentru trecerea pe HTTPS nu folosești instrumentul de schimbare a adresei din Search Console; acela e pentru mutarea pe alt domeniu.
Schimbarea domeniului fără pierderi SEO
Schimbi domeniul fără pierderi SEO dacă fiecare adresă veche trimite cu 301 la echivalenta ei de pe domeniul nou, anunți mutarea în Search Console și păstrezi domeniul vechi înregistrat. Riscul nu dispare complet: documentația Google descrie o perioadă de fluctuații după orice mutare.
- Verifici în Search Console ambele proprietăți, veche și nouă, din același cont.
- Redirecționezi cale cu cale: veche.ro/servicii/montaj spre noua.ro/servicii/montaj, nu totul spre noua.ro.
- Folosești instrumentul de schimbare a adresei (Change of Address) din setările proprietății vechi; el verifică, printre altele, că pagina principală veche trimite cu 301 spre cea nouă.
- Actualizezi ce controlezi: sitemap-ul, profilul de companie din Google, rețelele sociale, reclamele, semnăturile de email.
- Ții domeniul vechi activ. Dacă expiră, redirecturile dispar, iar linkurile vechi duc la eroare sau la cine îl cumpără după tine. Cum nu pierzi un domeniu la reînnoire afli din pașii pentru înregistrarea unui domeniu .ro.
Să zicem că o firmă de amenajări din Ilfov își schimbă numele și domeniul. Dacă trimite toate paginile vechi spre noul homepage, clientul care și-a salvat pagina cu portofoliul trebuie să o caute din nou, iar Google poate trata adresele vechi ca soft 404. Cu redirecturi cale cu cale, fiecare pagină veche e înlocuită de echivalenta ei.
Cum implementezi un redirect 301: Next.js, Apache, Nginx și WordPress
Redirectul se configurează acolo unde răspunde site-ul: în aplicație (Next.js), în configurația serverului (Apache, Nginx) sau în managerul de redirecționări al platformei. Exemplele de mai jos folosesc https://exemplu.ro, fără www, ca versiune principală.
Next.js: redirects() în next.config
În Next.js, regulile stau în funcția redirects() din next.config. Opțiunea permanent: true răspunde cu 308, echivalent pentru Google cu 301; dacă ai nevoie strict de 301, folosești statusCode: 301 în locul ei.
// next.config.js
module.exports = {
async redirects() {
return [
// o pagină mutată
{ source: '/servicii-vechi', destination: '/servicii', permanent: true },
// o secțiune întreagă, cu păstrarea restului adresei
{ source: '/blog/:slug', destination: '/ghiduri/:slug', permanent: true },
// varianta cu www spre cea fără www
{
source: '/:path*',
has: [{ type: 'host', value: 'www.exemplu.ro' }],
destination: 'https://exemplu.ro/:path*',
permanent: true,
},
]
},
}
Dacă găzduirea setează deja HTTPS și varianta www din panoul domeniului, nu le dubla în cod: așa apar lanțurile și buclele.
Apache: fișierul .htaccess
Pe Apache, inclusiv pe multe găzduiri cu cPanel, regulile se scriu în .htaccess, cu modulul mod_rewrite. Destinațiile sunt adrese complete, ca o adresă veche cerută pe http sau cu www să ajungă tot dintr-un singur salt.
RewriteEngine On
# pagini mutate: direct la adresa finală
RewriteRule ^servicii-vechi\.html$ https://exemplu.ro/servicii/ [R=301,L]
RewriteRule ^contact\.php$ https://exemplu.ro/contact/ [R=301,L]
# orice altă adresă cerută pe http sau cu www: spre https://exemplu.ro
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^(.*)$ https://exemplu.ro/$1 [R=301,L]
În spatele unui CDN care cere paginile de la server pe HTTP, condiția %{HTTPS} off e mereu adevărată și produce o buclă; în acest caz, trecerea pe HTTPS se face din CDN.
Nginx
Pe Nginx se folosește return 301, iar pentru mai multe adrese un bloc map, pus în contextul http, în afara blocului server, ține harta separat de reguli.
map $uri $adresa_noua {
/servicii-vechi.html /servicii/;
/contact.php /contact/;
}
server {
listen 80;
listen 443 ssl;
server_name exemplu.ro www.exemplu.ro;
# ssl_certificate și ssl_certificate_key, valabile pentru ambele nume
if ($adresa_noua) {
return 301 https://exemplu.ro$adresa_noua;
}
set $origine "$scheme://$host";
if ($origine != "https://exemplu.ro") {
return 301 https://exemplu.ro$request_uri;
}
# restul configurației site-ului
}
WordPress, Wix și Shopify
Pe WordPress, redirecturile merg în .htaccess, dacă serverul e Apache, sau într-un plugin de redirecționări, de exemplu Redirection, care poate înregistra și adresele care dau 404. Pe Wix sau Shopify nu ai acces la server, așa că folosești managerul de redirecționări din setări. Indiferent de instrument, verifică ce cod trimite: unele unelte folosesc implicit un redirect temporar.
La Magnitude Web, când un site nou înlocuiește unul existent, redirecturile 301 de pe site-ul vechi fac parte din proiectul de creare site web, alături de sitemap, robots.txt, etichetele canonical și Search Console configurat, cu indexarea testată înainte de lansare. Construim în cod, pe React și Next.js, Nuxt, Svelte sau HTML, CSS și JavaScript, iar tu primești acces complet la cod, domeniu și hosting.
Cum testezi redirecturile
Un redirect e corect dacă adresa veche răspunde cu 301 sau 308, trimite direct la adresa finală, iar aceasta răspunde cu 200. Verifici pe mediul de test înainte de lansare și din nou pe domeniul real, imediat după.
Cu curl, din terminal. Comanda urmează fiecare salt și afișează codul și destinația lui:
curl -sIL http://www.exemplu.ro/servicii-vechi.html | grep -iE "^(HTTP|location)"
Un rezultat corect are un singur redirect:
HTTP/1.1 301 Moved Permanently
Location: https://exemplu.ro/servicii/
HTTP/2 200
Mai multe linii Location înseamnă un lanț; o eroare despre numărul maxim de redirecționări înseamnă o buclă.
În fila Network a browserului, cu Preserve log și Disable cache bifate, primul rând arată codul și antetul Location. Două capcane: browserele memorează redirecturile 301, deci un redirect corectat poate apărea tot greșit; iar un rând „307 Internal Redirect” spre HTTPS vine din browser, care a memorat regula HSTS a site-ului, nu de la server.
Cu un crawler, pentru toată harta. Un program care parcurge site-ul ca un motor de căutare, de exemplu Screaming Frog SEO Spider, primește lista adreselor vechi și raportează pentru fiecare codul, destinația finală și numărul de salturi. Pentru câteva adrese ajunge un verificator online, ca redirect-checker.org.
În Search Console, după lansare. Inspectarea URL-urilor arată cum vede Google o adresă veche, raportul de indexare a paginilor grupează redirecturile, erorile 404 și paginile soft 404, iar raportul de performanță arată dacă click-urile trec pe adresele noi.
Cât timp păstrezi redirecturile
Păstrezi redirecturile cât mai mult, ideal pentru totdeauna. Documentația Google Search Central recomandă păstrarea lor pe termen lung, iar motivul e practic: linkurile din alte site-uri, semnele de carte și emailurile vechi trimit spre adresele vechi încă mult timp.
Un redirect nu costă aproape nimic să fie ținut. Riscul apare la următoarea relansare, când cineva șterge regulile vechi fără să știe de ce existau. Ține harta lângă cod, cu istoric, și urmărește în Search Console adresele care încep să dea 404; corectarea erorilor din Search Console poate intra într-o mentenanță a site-ului, la cerere sau lunară.
Checklist pentru migrarea unui site fără pierderi SEO
O migrare se joacă în trei momente: înainte de lansare pregătești și testezi, la lansare activezi, după lansare urmărești.
| Etapă | Ce faci | Cum verifici |
|---|---|---|
| Înainte | Aduni adresele vechi: sitemap, crawler, Search Console, Analytics | Lista include PDF-urile, articolele vechi și paginile de campanie |
| Înainte | Completezi harta, cu 404 sau 410 unde nu există echivalent | Niciun rând trimis spre homepage din comoditate |
| Înainte | Testezi regulile pe mediul de test | Un singur salt și destinație 200 pe toată harta |
| Înainte | Muți linkurile interne, etichetele canonical și sitemap-ul pe adresele noi | Crawlerul nu găsește linkuri interne spre redirecturi |
| Lansare | Activezi redirecturile, elimini noindex și blocajele din robots.txt | curl pe adresele importante, inspectarea URL-urilor |
| Lansare | Trimiți sitemap-ul nou; la domeniu nou, ceri schimbarea adresei | Search Console confirmă sitemap-ul și mutarea |
| După | Urmărești indexarea și click-urile | Rapoartele de indexare și de performanță |
| După | Păstrezi redirecturile și domeniul vechi | Reînnoirea automată e activă pentru domeniul vechi |
Greșeli frecvente la redirecturi
Pierderile de după o mutare vin de obicei din configurare, nu din redirect în sine.
- Toate adresele vechi spre prima pagină, pe care Google le poate trata ca soft 404.
- Redirect temporar în loc de permanent. În PHP, header("Location: ...") trimite implicit 302, iar în Next.js funcția redirect() din cod răspunde cu un cod temporar; pentru mutări definitive folosești permanentRedirect() sau regulile din next.config.
- Lanțuri adunate de la o relansare la alta.
- Redirecturi doar în JavaScript, deși serverul ar putea răspunde direct cu 301.
- Linkuri interne și sitemap lăsate pe adresele vechi, așa că fiecare click din meniu trece printr-un redirect.
- Redirecturi șterse după câteva luni sau domeniul vechi lăsat să expire.
Pe unde începi
Începi cu lista adreselor vechi și cu harta lor, înainte de design și de cod. Apoi alegi versiunea principală a domeniului, scrii regulile acolo unde răspunde site-ul, le testezi pe toată harta și urmărești indexarea în Search Console după lansare. Dacă redirecturile vin odată cu un site nou, cere ca harta să apară în ofertă ca livrabil, testat înainte de lansare.
Întrebări frecvente
Pierd poziții în Google dacă folosesc un redirect 301?
Un redirect 301 corect nu e o cauză de pierderi: Google îl tratează ca pe un semnal puternic că adresa nouă o înlocuiește pe cea veche. Pozițiile scad de obicei din alte motive: destinații fără legătură cu pagina veche, conținut tăiat la relansare, lanțuri sau redirecturi lipsă. O perioadă de fluctuații după mutare e normală, potrivit documentației Google.
Ce înseamnă „301 Moved Permanently” când apare ca eroare?
Codul 301 nu e o eroare. Dacă textul apare pe ecran, fie serverul a trimis codul fără o adresă validă în antetul Location, fie clientul care face cererea nu urmează redirecționările, cum face curl fără opțiunea -L. În fila Network a browserului vezi ce antet Location primește adresa.
Redirect 301 sau etichetă canonical: pe care o folosesc?
Folosești 301 când pagina veche nu mai trebuie să existe pentru vizitatori. Folosești eticheta canonical când ambele pagini rămân accesibile, dar vrei ca Google să o indexeze pe una singură, de exemplu la variantele aceleiași pagini cu filtre. Redirectul mută vizitatorul; eticheta canonical doar îi recomandă lui Google o adresă.
Pot face un redirect 301 din DNS sau de la registrar?
DNS-ul doar indică serverul care răspunde pentru un domeniu, deci nu poate trimite un cod 301. Redirecționarea oferită de registrar funcționează printr-un server al registrarului. Înainte să te bazezi pe ea, verifică cu curl că trimite 301, nu 302 sau o pagină încadrată (frame), și că păstrează calea paginii. Pentru o schimbare de domeniu cu multe pagini, un server pe care îl controlezi e de obicei mai sigur.