Cum Muți un Site de pe WordPress Fără să Pierzi Pozițiile în Google

Teama e justificată. Un site care se clasează bine are ani de muncă în spate, iar o mutare prost făcută îi poate șterge rezultatele dintr-o zi în alta. Vestea bună e că aproape tot ce se pierde la o migrare se pierde din aceleași câteva motive, iar fiecare dintre ele se poate preveni.

Articolul ăsta e despre ce verifici înainte, în timpul și după mutarea unui site de pe WordPress pe o platformă nouă — fie că e vorba de un export static, de un alt CMS sau de o reconstrucție completă.

Nu conținutul se pierde, ci adresele

Prima confuzie e că oamenii se tem pentru texte. În realitate, Google nu-ți clasează textul în gol: îl clasează la o adresă. Adresa e cea care a strâns linkuri, e cea din rezultate, e cea pe care o are cineva în bookmark-uri.

Deci întrebarea nu e „se mută conținutul?", ci „fiecare adresă care există azi va răspunde și mâine?". Dacă răspunsul e nu, ai pierdut exact cât valora adresa aceea.

Inventarul de adrese se face de pe site-ul viu, nu din CMS

Aici se greșește cel mai des. Te uiți în panoul de administrare, vezi 40 de pagini, și presupui că alea sunt toate adresele.

Nu sunt. Un site WordPress care a trăit câțiva ani acumulează adrese pe care nimeni nu și le mai amintește:

• slug-uri vechi, schimbate la un redesign, pe care WordPress le redirecționează de atunci în tăcere;
• adrese generate de temă, cum sunt paginile de portofoliu ale unui șablon, care au propria structură;
• arhive pe dată, dacă articolele au stat sub /2024/03/;
• pagini de categorie și etichetă, uneori indexate și ele.

Inventarul corect se face din afară: sitemap-ul actual, raportul de pagini din Google Search Console, un crawl al site-ului viu și lista de linkuri din subsolul propriu.

Capcana care nu apare pe nicio listă de verificare

Iată una care costă scump și pe care n-o găsești în ghidurile obișnuite.

Unele redirecturi de pe site-ul tău nu sunt pe server, sunt în WordPress. O adresă veche pe care platforma o redirecționează de ani de zile e o setare din WordPress — iar în ziua în care oprești WordPress, setarea aia dispare odată cu el.

Rezultatul: o adresă care azi răspunde 301 frumos devine 404 chiar în ziua lansării, fără ca nimeni să fi șters nimic.

Verificarea e simplă și trebuie făcută înainte: iei fiecare adresă veche pe care o bănuiești și te uiți ce cod întoarce acum. Dacă întoarce 301, notează unde duce — redirectul ăla trebuie recreat pe gazda nouă. Altfel îl pierzi fără să afli.

Redirecturile 301, și de ce nu orice redirect e bun

Un redirect spune browserului unde s-a mutat pagina. Dar codul contează:

• 301 — mutare definitivă. Google transferă poziția la adresa nouă. Ăsta vrei.
• 302 sau 307 — mutare temporară. Google păstrează adresa veche în index și nu mută poziția.
• 308 — e tot permanent, dar unele unelte de verificare îl raportează ca anomalie.

Pe unele platforme, opțiunea numită „permanent" produce de fapt 308, nu 301. Dacă ai de ales, scrie codul explicit.

Încă un amănunt care rupe redirecturi în tăcere: slash-ul de la final. Multe gazde normalizează adresa înainte să caute regula de redirect. O regulă scrisă fără slash nu se va potrivi niciodată cu o cerere care are slash, iar rezultatul e 404 — deși fișierul de configurare arată perfect.

DNS-ul: partea în care se strică ce n-are legătură cu site-ul

Când muți site-ul, muți și înregistrarea DNS care arată unde e el. Problema e că pe multe domenii mailul e legat de aceeași înregistrare.

Dacă MX-ul domeniului arată către domeniul însuși — nu către un server de mail cu nume propriu — atunci mailul se livrează la orice ține înregistrarea A. Muți A-ul pe gazda nouă, și mailul pleacă după el, către un server care nu primește mail. Adresele de contact se opresc, fără ca nimeni să se fi atins de ele.

Reparația se face înainte de mutare: dai MX-ului un nume propriu (mail.domeniul-tau.ro), aștepți TTL-ul, trimiți un mail de test, și abia apoi muți site-ul.

Mai e un detaliu: dacă zona DNS are o înregistrare wildcard, un subdomeniu nou va părea că rezolvă corect deși nu i-ai creat nicio regulă — până când observi că duce în altă parte.

Canonical, hreflang și sitemap

După ce adresele sunt rezolvate, mai sunt trei lucruri care spun motoarelor de căutare cum să citească site-ul:

• canonical — fiecare pagină declară care e adresa ei adevărată. Dacă site-ul e servit și cu, și fără www, una dintre ele trebuie să fie cea canonică, iar cealaltă să redirecționeze spre ea;
• hreflang — dacă ai mai multe limbi, fiecare pagină trebuie să-și declare perechea. Altfel versiunile se concurează între ele ca duplicate;
• sitemap — regenerat pe adresele noi și trimis în Search Console.

Un site de prezentare bine construit le generează pe toate trei automat, din conținut. Dacă le scrii de mână, vor rămâne în urmă la prima pagină adăugată. Despre cum arată o structură care se susține singură am scris pe pagina de optimizare SEO.

Ce verifici după mutare

În ziua lansării, nu te uita doar dacă prima pagină se încarcă:

1. Fiecare adresă veche întoarce 301, nu 302 și nu 200.
2. www și varianta fără duc amândouă unde trebuie.
3. Sitemap-ul răspunde și conține adresele noi.
4. Mailul funcționează — trimite un test real, nu presupune.
5. Search Console nu raportează un val de 404 în zilele următoare.

Merită automatizat: o listă de verificare rulată dintr-o comandă prinde în două minute ce altfel descoperi peste o lună, din raportul de erori.

Cât durează până revin pozițiile

Onest: depinde, și oricine îți dă o cifră exactă ghicește. Ce se poate spune e că, dacă adresele răspund corect și conținutul a rămas același, Google reprocesează site-ul în săptămânile următoare, nu în ani.

Ce prelungește procesul sunt exact greșelile de mai sus: redirecturi lipsă, lanțuri de redirecturi unul după altul, sau conținut rescris „cu ocazia asta" în același timp cu mutarea. Dacă muți și rescrii simultan, nu vei ști niciodată care dintre ele a fost cauza.

Pe scurt

O migrare nu pierde poziții pentru că platforma nouă e mai slabă. Pierde pentru că o adresă nu mai răspunde, un redirect e temporar în loc de permanent, sau o setare care trăia în vechea platformă a dispărut odată cu ea.

Dacă ai un site care aduce trafic și te gândești să-l reconstruiești, partea de adrese se planifică înainte de prima linie de cod. Poți citi și despre cum construim site-uri sau despre ce intră în mentenanța lunară după lansare — iar dacă vrei o părere pe cazul tău, scrie-ne.