Discuția „Astro sau WordPress“ e prost pusă în majoritatea cazurilor, fiindcă pornește de la tehnologie. Întrebarea corectă e alta: cine modifică conținutul, cât de des, și ce se întâmplă între două modificări? Răspunsul la ea decide arhitectura. Restul sunt detalii de implementare.

Mai jos e diferența reală dintre cele două abordări și o listă de criterii pe care le poți aplica în zece minute pe propriul site.

Diferența de fond: când se construiește pagina

WordPress construiește pagina la fiecare vizită. Un vizitator cere o adresă, serverul pornește PHP, interoghează baza de date, execută tema și pluginurile active, asamblează HTML-ul și îl trimite. Cache-ul de pagină ascunde pasul ăsta pentru vizitele următoare, dar mecanismul rămâne: există cod care rulează pe un server, la cerere, pentru fiecare pagină.

Astro construiește pagina o singură dată, la publicare. Rezultatul e un set de fișiere HTML, CSS și imagini, care se copiază pe un CDN. Când vine un vizitator, nu se execută nimic — se returnează un fișier deja existent, de la nodul cel mai apropiat geografic.

Din diferența asta decurg toate celelalte:

	WordPress	Astro (static)
Când se generează HTML-ul	la fiecare cerere	la build
Ce rulează în producție	PHP + bază de date	nimic
Suprafață de atac	cod executabil, admin, pluginuri	fișiere statice
Actualizări obligatorii	săptămânal	la nevoie, controlat
Cine editează conținutul	oricine, din browser	cine are acces la repo sau la un CMS extern

Ultimul rând e cel care decide, de fapt, alegerea.

JavaScript-ul livrat: partea unde Astro chiar diferă

Astro randează componentele la build și trimite în browser HTML fără JavaScript, implicit. Dacă o componentă chiar are nevoie de interactivitate, o marchezi explicit și doar ea primește JavaScript — restul paginii rămâne static. Modelul se numește „insule“ și e diferența majoră față de un framework care hidratează toată pagina.

Pentru un site de prezentare, consecința practică e că un meniu mobil și un comutator de temă pot însemna câteva sute de octeți de JavaScript, nu câteva sute de kilobytes. Nu pentru că e magie, ci pentru că nu se livrează cod pentru elemente care nu au nevoie de el.

Asta nu înseamnă automat scoruri perfecte. Un site static prost construit — imagini nedimensionate, fonturi externe, un script de analytics în calea critică — poate fi la fel de lent ca oricare altul. Arhitectura elimină o categorie de probleme, nu toate.

Când merită să treci la Astro

Semnele sunt destul de clare. Dacă recunoști trei sau mai multe, discuția merită purtată:

Site de prezentare de 5–20 de pagini, care se modifică de câteva ori pe an.
Nimeni din firmă nu intră în admin. Modificările le ceri oricum cuiva din exterior.
Ai deja cinci pluginuri ale căror funcții le-ai putea scrie o singură dată, corect.
Performanța contează — pentru poziționare, pentru campanii plătite sau pentru că e o parte din ce vinzi.
Ai avut un incident de securitate sau ai fost aproape de unul.

În situația asta, un site static îți scoate din ecuație categorii întregi de probleme: nu există panou de administrare de protejat, nu există bază de date de injectat, nu există versiune de PHP de urmărit. Găzduirea devine aproape gratuită, iar timpul de răspuns nu mai depinde de încărcarea unui server partajat.

Când nu merită, categoric

La fel de important. Rămâi pe WordPress dacă:

Ai magazin online cu inventar, comenzi și plăți. Ecosistemul WooCommerce rezolvă probleme reale pe care nu vrei să le rezolvi de la zero.
Publici des, cu mai mulți autori care nu sunt tehnici. Un flux editorial cu ciorne, revizii și programare de publicare e exact ce face WordPress bine.
Ai nevoie de conturi de utilizator, zone protejate, abonamente.
Depinzi de un plugin specific fără echivalent, integrat în procesele tale.
Echipa ta editează zilnic și orice pas suplimentar de publicare va fi resimțit ca frecare.

Ultimul punct merită subliniat. Un site static publicat prin deploy e excelent când conținutul se schimbă rar. Când se schimbă zilnic, ai nevoie fie de un CMS extern conectat la build, fie de altceva. Nu e o limitare tehnică insurmontabilă, e o decizie de proces care trebuie luată conștient, nu descoperită după livrare.

Ce se pierde la trecere

Onest, sunt lucruri pe care le pierzi și merită enumerate înainte, nu după.

Editarea din browser, dacă nu conectezi un CMS. Textul se modifică în fișiere versionate și ajunge live prin deploy. E mai sigur și mai trasabil, dar e alt obicei.

Instalarea unei funcții într-un minut. Nu mai cauți un plugin, ci scrii sau ceri codul. E mai puțin cod în total și mai mult efort inițial per funcție.

Previzualizarea instantă a unei modificări, dacă lucrezi fără un mediu de preview configurat. Se rezolvă cu un flux de deploy pe ramuri, dar trebuie configurat.

Compensația e că lista de lucruri care se pot strica singure devine foarte scurtă. Un site care nu execută cod în producție nu se strică între două intervenții.

Ce rămâne exact la fel

O confuzie frecventă merită lămurită: schimbarea platformei nu îți schimbă poziționarea în căutări prin ea însăși. Google indexează HTML, iar HTML-ul rămâne HTML indiferent cine l-a generat.

Ce rămâne identic: structura de titluri, textele, linkurile interne, datele structurate, canonicalul, sitemap-ul. Toate se pot face bine sau prost pe ambele platforme. Diferența pe care o aduce generarea statică ține de viteza de livrare și de stabilitate — factori reali, dar nu singurii și rareori decisivi singuri.

Ce se poate strica la o trecere făcută în grabă: adresele paginilor. Dacă adresele se schimbă și nu există redirecționări permanente, pierzi exact semnalele acumulate. E partea care cere cel mai mult atenție și cea mai des tratată superficial. Regula simplă: fiecare adresă veche primește o decizie explicită — echivalent, pagină consolidată, sau 404 cu o pagină utilă. Nicio adresă nu se trimite generic pe prima pagină, fiindcă asta îl lasă pe vizitator exact unde nu voia să ajungă.

Cum decizi în zece minute

Ia site-ul tău actual și răspunde:

Câte modificări de conținut ai făcut în ultimele 12 luni? Sub 20 înseamnă „rar“.
Cine le-a făcut? Dacă răspunsul e „am cerut cuiva“, editarea din browser nu e un avantaj real pentru tine.
Câte pluginuri active ai și pe câte te bazezi cu adevărat?
Ai funcționalități care cer cod pe server — coș, conturi, căutare complexă?
Cât plătești anual pentru găzduire, licențe și mentenanță?

Dacă la 1 și 2 răspunsurile sunt „rar“ și „altcineva“, iar la 4 răspunsul e „nu“, schimbarea are sens economic, nu doar tehnic.

Ce facem noi

Construim site-uri cu Astro pentru exact profilul descris mai sus, și continuăm să facem mentenanță WordPress pentru cine are nevoie de WordPress. Nu sunt poziții contradictorii — sunt două răspunsuri la două întrebări diferite.

Dacă nu ești sigur în ce categorie intri, cel mai rapid e să ne trimiți adresa site-ului și o propoziție despre cât de des îl modifici. Îți spunem ce vedem, inclusiv atunci când răspunsul e „lasă-l așa“. Ai și un inventar al costurilor de mentenanță dacă vrei să faci socoteala înainte de discuție.

Scrie-ne — răspundem în maxim 24 ore lucrătoare.

Astro vs WordPress: când merită să renunți la WordPress