Migrare de pe WordPress la Astro: cum nu pierzi traficul Google

TL;DR: Migrarea de pe WordPress catre Astro (sau orice arhitectura statica moderna) iti aduce site mult mai rapid, mai sigur si mai usor de indexat. Riscul real al migrarii nu este tehnic — este SEO. Daca nu mapezi corect URL-urile vechi catre cele noi prin redirecturi 301, pierzi pozitiile castigate. Cu un plan bun, migrarea conserva 95-100% din ranking-ul vechi si pune fundatia pentru crestere.

---

De ce migrezi de pe WordPress

WordPress a fost cea mai populara platforma de site-uri timp de un deceniu. Are insa cateva probleme grele pentru proiecte serioase:

• Lent prin definitie — PHP la fiecare request, plugin-uri care fac query-uri inutile, teme bloated.
• Suprafata de atac mare — actualizari constante de securitate, plugin-uri vulnerabile, login wp-admin tinta clasica de atac.
• Costuri ascunse — hosting premium pentru viteza acceptabila, licente plugin-uri, mentenanta lunara.
• Mediu fragmentat — pluginurile se cearta intre ele, actualizarile pica site-ul, dezvoltatorii lucreaza in ecosisteme rupte.

Arhitecturile statice moderne (Astro, Next.js cu static export, Hugo, Eleventy) rezolva toate astea. Site-ul devine un set de fisiere HTML/CSS/JS servit la edge — fara baza de date, fara PHP la runtime, fara plugin-uri care sa cada.

Beneficiile concrete dupa migrare

• Lighthouse 95+ posibil din prima, nu dupa luni de optimizari.
• LCP sub 1.5s standard, nu exceptie.
• Costuri hosting scad cu 70-90% — un site static traieste pe Cloudflare Pages free sau pe orice nginx ieftin.
• Securitate drastic mai bun — nu exista panou de admin pe domeniul public.
• AEO — continutul curat e perfect pentru ingestia in motoare AI. Detalii in ghidul nostru SEO si AEO.

Riscul real: pierderea traficului Google

Aici este punctul critic. Daca un URL vechi /blog/2023/cum-faci-x nu mai exista pe site-ul nou, Google il primeste cu 404 si scoate pagina din index in cateva saptamani. Pozitiile castigate cu ani inainte se evapora.

Solutia este harta de redirecturi 301. Pentru fiecare URL care exista in indexul Google si in linkurile externe catre site-ul tau, definesti un redirect catre noua locatie. Nu sari peste niciun URL.

Plan de migrare in 8 pasi

1. Inventar complet URL-uri vechi

Sursele tale de adevar:

• Export WordPress XML (toate paginile si articolele cu URL-urile lor).
• Sitemap-ul curent (/sitemap.xml).
• Google Search Console — toate paginile cu impresii in ultimele 12 luni.
• Google Analytics — paginile cu trafic in ultimele 12 luni.
• Backlink-urile externe (Ahrefs / SEMrush gratuit pentru date de baza).

Centralizezi tot intr-un tabel: URL vechi, importanta (trafic, backlink-uri), echivalent nou.

2. Arhitectura URL noua

Decizi structura noului site. Recomandare: slug-uri scurte, fara date in URL, fara categorii in path daca nu sunt critice. URL stabil = SEO bun.

Exemplu trecere:

• Vechi: /2023/04/15/securitate-retea/
• Nou: /blog/securitate-retea/

3. Maparea redirecturilor

Pentru fiecare URL vechi, o destinatie noua. Daca un articol vechi nu mai are sens, redirectionezi catre cea mai apropiata pagina (categorie sau homepage). Niciodata nu lasi 404 pentru URL-uri care aveau trafic.

Formate de implementare:

• Astro: redirects: { '/vechi': '/nou' } in astro.config.mjs.
• Cloudflare Pages: fisier _redirects cu /vechi /nou 301.
• Nginx: rewrite ^/vechi$ /nou permanent; (dar evita daca ai panou de control care regenereaza vhost-ul).

4. Continut

Exporti continutul din WordPress (XML), il transformi in Markdown (sau MDX). Pastrezi:

• Titlu, descriere, data publicarii originale.
• Imaginile (re-optimizate la WebP/AVIF).
• Linkurile interne — le rescrii catre noile rute.

Pentru imagini, scriptul ideal: descarca toate imaginile referite, le re-genereaza in WebP/AVIF cu marimi reale (nu cele inflate de WordPress).

5. Schema si meta

Pentru fiecare tip de pagina, defineste JSON-LD corespunzator:

• Organization + WebSite + LocalBusiness pe homepage.
• BlogPosting pe articole.
• Service pe paginile de servicii.
• BreadcrumbList peste tot.
• FAQPage la sectiunile cu intrebari.

<title> si <meta description> revizuite pentru fiecare pagina — nu copiezi direct din WordPress.

6. Robots si llms.txt

robots.txt cu boti AI permisi explicit. llms.txt si llms-full.txt pentru AEO. Sitemap automat generat de framework.

7. Testare inainte de lansare

• Build local, browse complet, click pe toate link-urile principale.
• curl -I pe 20-30 URL-uri vechi reprezentative, verificare 301.
• Lighthouse pe 5-6 pagini cheie — 95+ pe toate metricile.
• Schema valida pe validator.schema.org.
• Verificare mobile pe doua dispozitive reale.

8. Lansare si monitorizare

• Schimbi DNS la noua infrastructura.
• Submit sitemap nou in Google Search Console.
• Submit URL-uri importante manual pentru indexare rapida.
• Monitorizezi 4-12 saptamani: pozitii, impresii, click-uri, erori in Search Console.

Daca apar 404 in Search Console, le mapezi imediat — nu astepti.

Cat dureaza si cat costa

Un site WordPress de 30-50 pagini cu structura clara: 4-6 saptamani. Un site cu sute de articole si ecommerce: 8-12 saptamani.

Costul depinde mai mult de cat continut trebuie revizuit si cate integrari ai (ecommerce, formulare custom, API-uri terte) decat de tehnologia in sine. Vezi pagina noastra de site-uri si ecommerce si exemplele concrete din portofoliu.

---

Intrebari frecvente

Pierd ceva din ranking daca migrez bine? Daca redirecturile 301 sunt complete, in mod normal nu. Google trece pozitia veche pe URL-ul nou in 2-6 saptamani. Daca migrezi prost (404 in loc de 301), pierzi semnificativ.

Pot pastra blogul WordPress si migra doar restul? Da, dar e contraproductiv. Site-ul ramane lent pe parte de blog, mentenanta dubla, doua stack-uri de gestionat. Mai bine migrezi tot.

Trebuie sa schimb si CMS-ul? Optional. Pentru editori non-tehnici, un CMS headless (Sanity, Strapi, Decap) sau articole in Markdown din Git iti rezolva editarea. Decizia se ia pe baza echipei care va edita continutul.

Ce fac cu plugin-urile WordPress critice (WooCommerce, Yoast, etc.)? WooCommerce → Snipcart, Shopify headless sau modul Odoo Ecommerce, in functie de scala. Yoast → schema generata manual sau prin framework (nu mai e necesara unealta separata). Formularele Contact Form 7 → endpoint PHP simplu (vezi exemplul nostru), Formspree sau Resend.

De ce Astro si nu Next.js? Astro este optimizat pentru site-uri cu continut (blog, prezentare, ecommerce static). Trimite zero JavaScript by default si adauga JS doar pe componentele care chiar au nevoie (Islands). Next.js e mai potrivit pentru aplicatii cu state complex. Pentru site de business, Astro castiga la performanta si simplitate.

---

Glosar

• Redirect 301: redirect permanent care semnaleaza motoarelor de cautare ca URL-ul s-a mutat definitiv. Transfera ranking-ul.
• Astro Islands: arhitectura unde majoritatea paginii e HTML static si doar componentele interactive (carucior, formular) primesc JavaScript.
• Headless CMS: sistem de gestiune continut fara front-end propriu — expune doar API pentru a fi consumat de orice framework.
• Edge rendering: continutul este servit de servere apropiate geografic de utilizator, nu de un singur server central.