Migrare SEO: 390 de adrese, fără pierderi de poziții

Refacerea unui site e momentul cu cel mai mare risc de pierdere de trafic din viața unui domeniu. Nu pentru că designul nou ar fi mai slab, ci pentru că adresele se schimbă, iar Google are un index plin de adrese care, brusc, nu mai răspund. Site-uri cu ani de autoritate acumulată pierd jumătate din trafic în două săptămâni și nu-l mai recuperează niciodată complet.

Articolul ăsta e studiul de caz al migrării propriului nostru site, de pe WordPress pe o platformă statică. Cifrele sunt reale, verificate cu un script care citește exportul original, nu o listă scrisă de mână: 390 de adrese vechi · 175 servite direct · 205 redirecționate · 10 retrase · 0 fără destinație. Include și capcana pe care nu o vede aproape nimeni și care singură ar fi produs 210 pagini de eroare.

Cuprins

De ce migrările pierd trafic
Pasul 0: inventarul
Ce se întâmplă cu pozițiile când refaci un site
Regula care a salvat proiectul
Capcana celor 210 pagini de atașament
301, 410 și când folosești fiecare
Verificarea automată
De ce am păstrat arhiva din 2005
Checklistul de lansare
Ce am migrat și ce am lăsat în urmă
Metadatele: singura parte fără nimic de pierdut
Ce urmărești în primele 30 de zile

De ce migrările pierd trafic

Cinci cauze, în ordinea frecvenței:

1. Adrese schimbate fără redirecționare. Cea mai comună și cea mai gravă. Fiecare adresă indexată care returnează eroare e o pagină pierdută din index.

2. Redirecționări în lanț. A duce la B, B duce la C. Funcționează pentru vizitator, dar diluează semnalul și consumă din bugetul de parcurgere.

3. Adrese uitate. Cele pe care nimeni nu le-a numărat: pagini de arhivă, pagini de paginație, adrese vechi rămase din redenumiri anterioare.

4. Redirecționare masivă către pagina de start. „Tot ce nu găsim trimitem acasă.” Din perspectiva unui motor de căutare e un semnal de pagină inexistentă, nu o redirecționare utilă — și pierzi tot.

5. Conținut care nu a migrat. Pagina există la aceeași adresă, dar cu jumătate din text. Poziția se pierde pentru că relevanța a scăzut.

Ce au în comun

Toate cinci sunt probleme de inventar, nu de tehnologie. Nu poți păstra ce n-ai numărat.

Pasul 0: inventarul

Înainte de orice decizie de design, se face lista completă a ceea ce există.

Sursele, în ordinea încrederii

Exportul platformei. Pentru WordPress, fișierul XML complet. E singura sursă care conține tot, inclusiv adrese vechi memorate la redenumiri.
Baza de date. Pentru ce nu apare în export.
Search Console. Ce e efectiv indexat și ce aduce afișări.
Analytics. Ce pagini au avut trafic real în ultimul an.
Un crawler. Ce e accesibil prin legături interne.

De ce nu e suficientă o singură sursă

Fiecare vede altceva. Un crawler nu găsește o pagină la care nu duce nicio legătură, dar care e indexată de ani de zile. Search Console nu arată paginile fără afișări. Exportul nu arată ce a fost șters.

Noi am pornit de la export, pentru că a fost singura sursă care garanta acoperirea completă a ceea ce a existat vreodată în WordPress.

Ce a ieșit

390 de adrese distincte. Site-ul „avea”, după cum credea toată lumea, în jur de 180 de pagini.

Diferența de peste 200 e explicată în secțiunea despre paginile de atașament.

Ce se întâmplă cu pozițiile când refaci un site

Dacă adresele rămân aceleași și conținutul se păstrează, de regulă nu se întâmplă nimic — poate o fluctuație de câteva zile în timpul reindexării. Dacă adresele se schimbă și sunt redirecționate corect cu 301, se transferă cea mai mare parte a autorității, cu o perioadă de instabilitate de câteva săptămâni. Dacă adresele se schimbă fără redirecționare, pierderea e mare și, în multe cazuri, permanentă.

Cu alte cuvinte: riscul nu e în platforma nouă, e în continuitatea adreselor.

Regula care a salvat proiectul

Adresele urâte rămân urâte.

Site-ul vechi avea 155 de pagini de proiect la adrese de forma /portfolio-items/<slug>/. E o adresă generată de un șablon comercial, nu una aleasă de cineva. /portofoliu/<slug>/ ar fi fost, evident, mai frumos.

Nu am schimbat-o.

De ce

Sunt 155 de adrese indexate de ani de zile, conținutul cel mai profund al site-ului.
Redenumirea ar fi însemnat 155 de redirecționări, fiecare cu o pierdere mică, dar cumulativă.
Câștigul: o adresă mai plăcută pe care niciun vizitator nu ar fi observat-o.
Riscul: pierderea unei părți din singurul capital SEO real al site-ului.

Raport risc/beneficiu inacceptabil. Au rămas exact cum erau.

Regula generalizată

Într-o migrare, o adresă se schimbă numai dacă se rezolvă o problemă reală: o structură care împiedică creșterea, o adresă cu parametri care produce conținut duplicat, o taxonomie folosită ca destinație de meniu.

Estetica nu e o problemă reală.

Ce am schimbat, totuși

Vechi	Nou	De ce
`/category/blog/`	`/blog/`	arhivă de taxonomie folosită ca pagină de meniu
`/portfolio_category/<cat>/`	`/portofoliu/<cat>/`	arhivele au devenit pagini reale de categorie
`/acasa/`	`/`	pagina de start răspundea la două adrese

Trei schimbări structurale, fiecare cu un motiv. Restul, neatins.

Capcana celor 210 pagini de atașament

Descoperirea care a justificat singură tot efortul de inventariere.

Ce sunt

WordPress creează, implicit, o pagină separată pentru fiecare fișier încărcat în biblioteca media. Nu doar fișierul — o pagină HTML care conține imaginea, la o adresă situată sub pagina în care a fost inserată:

/portfolio-items/ambike/            ← pagina proiectului
/portfolio-items/ambike/ambike-ro/  ← pagina imaginii din proiect

/servicii/packaging/                          ← pagina de serviciu
/servicii/packaging/top-realizare-concept-ambakaj/   ← pagina imaginii

De ce sunt o problemă

Nimeni nu știe că există. Nu apar în meniuri, nu apar în listarea de pagini a panoului de administrare.
Sunt indexate. Google le găsește din codul paginii părinte.
Nu apar în niciun inventar făcut manual.
Într-o migrare, devin toate erori 404.

În cazul nostru: 210 astfel de pagini. Peste jumătate din totalul de 390 de adrese.

Cum le-am tratat

Fiecare pagină de atașament redirecționează 301 către pagina de care aparținea. E destinația logică: cineva care ajunge acolo căuta, de fapt, proiectul sau serviciul respectiv.

Regula, generalizată printr-un tipar de adresă:

# O pagină de atașament e un segment sub o pagină reală.
# Gărzile !-f și !-d fac regula să sară peste orice pagină
# care există efectiv în build — fiecare e un director pe disc.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([^/.]+)/[^/.]+/?$ /$1/ [R=301,L]

Zece cazuri fără părinte

Zece imagini fuseseră încărcate direct în bibliotecă, fără să fie atașate vreunei pagini. Adresele lor nu aveau nicio destinație logică.

Pentru ele am folosit 410, nu 301 și nu 404. Explicație în secțiunea următoare.

301, 410 și când folosești fiecare

Cod	Înseamnă	Când
301	mutat permanent	conținutul există la altă adresă
302	mutat temporar	rar; într-o migrare, aproape niciodată
404	negăsit	adresă care nu a existat
410	dispărut definitiv	a existat, nu mai există, nu se întoarce

De ce 410 și nu 404

Ambele înseamnă „nu e aici”. Diferența e în intenție: 404 spune „nu găsesc”, 410 spune „a existat și am eliminat-o deliberat”.

Practic, o adresă care returnează 410 iese din index mai repede și mai curat. O adresă care returnează 404 e recontrolată periodic, uneori luni de zile, și poate rămâne raportată ca eroare.

Pentru conținut eliminat intenționat — cele zece pagini de imagine fără părinte — 410 e răspunsul corect.

Reguli pentru 301

Într-un singur pas. Dacă /acasa/ ducea la / și o imagine de sub /acasa/ ar fi dus la /acasa/, ai un lanț. Se scrie regula ca imaginea să meargă direct la destinația finală.

Către destinația echivalentă, nu către pagina de start. O redirecționare masivă spre / e tratată ca pagină inexistentă.

La nivel de server, nu prin HTML. Un generator de site static poate emite pagini cu reîmprospătare automată în loc de redirecționări. Funcționează pentru vizitator, dar nu e o redirecționare 301 reală. Pe găzduire cPanel/Apache, regulile se scriu în .htaccess și produc răspunsuri 301 autentice.

Verificarea automată

Partea cea mai importantă și cea mai des sărită.

De ce nu ajunge o listă scrisă de mână

Pentru că lista scrisă de mână conține ce știi. Problema e ce nu știi — cele 210 pagini de atașament.

Ce am construit

Un script care:

Citește adresele vechi din exportul WordPress. Nu dintr-o listă întocmită de om.
Parsează regulile din .htaccess și le aplică în aceeași ordine în care le aplică Apache. Ordinea contează: prima regulă care se potrivește câștigă.
Caută destinația în build-ul final. Există efectiv fișierul?
Raportează fiecare adresă: servită direct, redirecționată, retrasă, sau fără destinație.

Rezultatul


Adrese vechi verificate	390
Servite direct, la aceeași adresă	175
Redirecționate 301	205
Retrase cu 410	10
Fără destinație	0

Verificarea inversă

Regulile care prind paginile de atașament sunt largi. O regulă prea lacomă ar putea prinde o pagină reală.

Scriptul verifică și invers: trece toate cele 189 de pagini construite prin regulile de redirecționare fără gărzile !-f și !-d, și raportează dacă vreuna ar fi preluată. Rezultat: niciuna.

E o verificare pe care o recomandăm oricui scrie reguli generale de redirecționare. O regulă care „prinde tot ce nu există” e o regulă care, într-o zi, va prinde ceva ce există.

Ce nu se poate verifica local

.htaccess nu se aplică într-o previzualizare locală. După încărcarea pe server, fiecare regulă se verifică pe producție:

curl -sI https://digital-art.ro/portfolio-items/ambike/ambike-ro/ | head -3

Răspunsul trebuie să fie 301 cu antetul Location: către destinația corectă. Se face pentru un eșantion din fiecare categorie de regulă, nu pentru toate cele 390.

De ce am păstrat arhiva din 2005

Site-ul are un subdomeniu, vechiul-website.digital-art.ro, care găzduiește versiunea din 2005–2017. Fișiere PHP statice, design de acum aproape două decenii.

Întrebarea firească: de ce nu îl ștergem?

Datele

Din 23 de clicuri în 58 de zile pe tot domeniul, 12 au venit de pe arhivă. Mai mult decât site-ul principal.

Dintre acestea, nouă au venit de pe o singură pagină: prezentarea unei vile din Eforie Nord, cu o rată de clic de 5,92% și poziția medie 4,47.

Ce ne spune

Un fișier PHP din 2007 aduce mai mult trafic decât toate cele zece pagini de servicii ale site-ului nou la un loc.

Nu pentru că ar fi bine făcut. Pentru că e specific: are un nume propriu, un loc și un subiect precis. Iar concurența pe „vila monica eforie nord” e practic inexistentă, în timp ce pe „creare site de prezentare” e feroce.

Lecția

Nu șterge conținut vechi care încă aduce trafic, oricât de prost ar arăta. Verifică întâi datele. O pagină urâtă cu o rată de clic de 5,92% valorează mai mult decât o pagină frumoasă cu 0%.

Am păstrat arhiva ca subdomeniu separat, cu regulile de redirecționare ale site-ului principal explicit scoase din calea ei — o precauție de configurare care merită menționată: o regulă generală scrisă neglijent poate ajunge să afecteze un subdomeniu la care nu te gândeai.

Checklistul de lansare

În ordinea corectă. Ordinea contează.

ÎNAINTE DE LANSARE
☐ Inventar complet, din exportul platformei — nu dintr-un crawler
☐ Fiecare adresă veche are o destinație: directă, 301 sau 410
☐ Zero adrese fără destinație — verificat cu script, nu manual
☐ Verificare inversă: nicio pagină reală nu e prinsă de regulile generale
☐ Nicio redirecționare în lanț
☐ Conținutul migrat integral — verificat pagină cu pagină
☐ Titlurile și descrierile scrise pentru fiecare pagină
☐ Copie de siguranță completă a site-ului vechi

ZIUA LANSĂRII
☐ Publicare
☐ Încărcarea regulilor de redirecționare la nivel de server
☐ Verificarea cu curl a unui eșantion din fiecare tip de regulă
☐ Verificarea certificatului SSL
☐ Verificarea că robots.txt nu blochează nimic din greșeală
☐ Trimiterea hărții noi în Search Console
☐ Vechea hartă păstrată accesibilă câteva săptămâni
☐ Testarea formularelor de pe un dispozitiv real
☐ Verificarea măsurării: analiza funcționează, evenimentele se înregistrează

DUPĂ
☐ Urmărirea erorilor în Search Console, zilnic în prima săptămână
☐ Urmărirea indexării
☐ Urmărirea datelor de performanță de la utilizatori reali

De ce vechea hartă se păstrează

Ca Google să recontroleze adresele vechi și să vadă redirecționările. E contraintuitiv — pare că trimiți motorul spre pagini moarte — dar exact asta accelerează remaparea.

Ce am migrat și ce am lăsat în urmă

Un inventar al conținutului, separat de cel al adreselor. Cele două se confundă des și sunt lucruri diferite: o adresă poate supraviețui cu jumătate din conținut, iar rezultatul e o pierdere de poziție pe care nimeni nu o leagă de migrare.

Ce a fost migrat

Categorie	Cantitate	Tratament
Pagini publicate	17	text păstrat integral
Articole de blog	3	păstrate, cu adresele lor
Proiecte de portofoliu	155	păstrate, cu adresele lor
Cuvinte de conținut	~19.300	migrate integral
Întrebări frecvente	14	păstrate, plus date structurate noi
Imagini originale	245	reprocesate din originale

Regula pentru text: verbatim. Textul e ce se clasează. Am corectat diacritice și greșeli evidente; n-am rescris nimic în timpul migrării. Rescrierea de conținut e un proiect separat, făcut după ce migrarea s-a stabilizat — altfel nu mai știi ce a cauzat o schimbare de poziție.

Ce a fost lăsat în urmă

Ce	Cantitate	De ce
Derivate de imagine generate automat	3.410 fișiere, 86 MB	se regenerează la construire, din originale
JavaScript de la editorul vizual	62 fișiere, 40,6 MB	nefolosit
CSS de la editorul vizual	10 fișiere, 12,2 MB	nefolosit
Cache de fonturi	32 fișiere	site-ul nou își alege fonturile
Jurnal de depanare al unei extensii	1 fișier, 2,6 MB	nu trebuia să fie public
Copii de siguranță orfane	38 fișiere	reziduuri

Din 181 MB, conținutul real era 35 MB. Restul: artefacte.

O verificare care merită făcută

Pe orice migrare, caută în arhiva de fișiere după extensii care nu ar trebui să existe public: fișiere de jurnal, arhive, copii de siguranță, fișiere de configurare. Se găsesc surprinzător de des, indexate.

Metadatele: singura parte fără nimic de pierdut

O descoperire care a simplificat proiectul.

Ce am căutat

Am scanat baza de date completă după cheile pe care le folosesc extensiile de optimizare pentru a stoca titluri, descrieri și adrese canonice.

Ce am găsit

Zero rânduri. Site-ul vechi nu avusese niciodată o extensie de optimizare instalată. Fără meta-descrieri, fără etichete pentru rețele sociale, fără date structurate, fără adrese canonice personalizate.

De ce contează

Riscul standard al unei migrări — „păstrează titlurile și descrierile” — nu se aplica. Nu exista un corpus de metadate care să poată fi pierdut.

Asta reorientează întreg proiectul: riscul se concentra aproape integral în continuitatea adreselor, iar tot ce adăuga site-ul nou — descrieri, etichete sociale, date structurate — era câștig net, nu portare.

Lecția generalizabilă

Înainte de a planifica o migrare, verifică ce metadate există efectiv. Dacă există, sunt de păstrat cu atenție. Dacă nu există, ai un proiect mai simplu decât credeai și o oportunitate imediată: fiecare titlu și descriere scrise acum sunt o îmbunătățire față de starea anterioară, nu o replicare.

Verificarea durează zece minute și schimbă estimarea de efort.

Ce urmărești în primele 30 de zile

Perioadă	Ce urmărești	Ce e normal
Zilele 1–3	erori de parcurgere	câteva; ar trebui să scadă
Zilele 1–7	indexarea paginilor principale	apar treptat
Săptămânile 1–3	fluctuație de poziții	normală, nu interveni
Săptămânile 2–4	trafic organic	revine către nivelul anterior
Săptămâna 4	Core Web Vitals, date reale	se acumulează după ~28 de zile

Ce nu faci

Nu modifica nimic în primele două săptămâni, în afară de erori evidente. Fluctuația de poziții e normală în timpul reindexării. Fiecare modificare făcută în panică prelungește perioada de instabilitate.

Când ai o problemă reală

Erori de parcurgere care cresc după prima săptămână.
Pagini importante care nu se indexează după 14 zile.
Trafic organic sub 70% din nivelul anterior după 30 de zile.

În oricare dintre cazuri, prima verificare e aceeași: rulează din nou inventarul. Aproape întotdeauna e o adresă uitată.

Ai un site de refăcut și te temi de partea asta? Pe bună dreptate — e partea în care se pierd lucruri. Scrie-ne și facem întâi inventarul, înainte de orice discuție despre design.

Citește mai departe: Structura SEO a unui site de prezentare, WordPress sau site static și SEO în era AI Overviews.