Astro SEO pas cu pas: randare statică sau pe server, tag-uri head, sitemap, hreflang, imagini, JSON-LD și redirecționări, verificate față de documentația oficială.

Pe această pagină
Pe scurt
Astro este unul dintre cele mai prietenoase cadre web pentru căutare, pentru că randează paginile în HTML simplu și nu trimite JavaScript pe partea clientului decât dacă îl ceri. Astfel, Google și crawlerele AI primesc conținutul complet din prima cerere. Astro nu îți scrie însă SEO-ul în locul tău: titlurile, meta-descrierile, canonicalele, hreflang, datele structurate și redirecționările le adaugi tu, în mare parte într-o componentă comună de head, plus integrarea oficială pentru sitemap.
Vrei să afli mai mult? Întreabă
Test rapid
Ți se potrivește SEO și cum ar trebui să începi?
Sorank se potrivește răspunsurilor tale
Testează-l 3 zile pe propriul site și vezi unde te afli pe Google, ChatGPT și pe celelalte IA.
Începe perioada de test gratuită de 3 zile3 zile gratuit, apoi renunți oricând vrei. Garanție de rambursare în 90 de zile dacă nu vezi rezultate.
Astro SEO înseamnă transformarea acestui HTML curat în pagini care se clasează. Ghidul de bază al Google pentru SEO-ul JavaScript explică faptul că procesează site-urile cu JavaScript în trei faze (crawlare, randare, indexare) și afirmă că „randarea pe server sau pre-randarea rămân o idee foarte bună”, pentru că nu toți boții pot rula JavaScript. Astro pornește implicit de la această poziție. Acest ghid acoperă restul, setare cu setare, iar fiecare comportament este verificat față de documentația oficială Astro. Ca fapt de context, site-ul sorank.com pe care îl citești rulează pe Astro.
Da, din punct de vedere tehnic. Astro randează componentele în HTML în momentul build-ului și elimină JavaScriptul pe care cadre precum React sau Vue l-ar trimite în mod obișnuit browserului. Rezultatul evită problemele clasice descrise în ghidul nostru despre SEO pentru JavaScript: cochilii HTML goale, conținut care apare doar după randare, linkuri care nu sunt etichete de ancoră reale. Evită și capcanele de rutare ale unei aplicații cu o singură pagină, pentru că fiecare rută Astro este un URL real, cu propriul fișier HTML.
Ce nu face Astro este la fel de important. Nu există plugin SEO integrat, nicio meta-descriere automată, niciun tag canonical automat și nicio dată structurată. Tabelul de mai jos separă ce primești gratuit de ce trebuie să construiești tu.
| Element SEO | Ce îți oferă Astro | Ce adaugi tu |
|---|---|---|
| HTML crawlabil | HTML pre-randat implicit | Nimic, dacă nu randezi conținutul doar pe client |
| Titlu și meta-descriere | Un head pe care îl controlezi în fiecare layout | O componentă SEO comună, alimentată de fiecare pagină |
| Tag canonical | Astro.site și Astro.url pentru URL-uri absolute | Tag-ul link în sine, cu un slash final consecvent |
| Sitemap XML | Integrarea oficială @astrojs/sitemap | O instalezi, setezi opțiunea site, filtrezi paginile private |
| hreflang | Rutare i18n și o opțiune i18n pentru sitemap | Linkuri alternative în head-ul fiecărei pagini |
| Imagini | Componentele Image și Picture care optimizează fișierele | Text alt descriptiv, dimensiuni sensibile |
| Date structurate | Nimic specific | Scripturi JSON-LD pe tip de pagină |
| Redirecționări | O opțiune redirects în configurare | Adevărate 301-uri la nivel de gazdă pentru build-urile statice |
Documentația Astro despre randarea la cerere este clară: implicit, paginile, rutele și endpoint-urile API sunt pre-randate în momentul build-ului, ca pagini statice. Pentru SEO, ieșirea statică este varianta implicită cea mai sigură: fiecare URL este un fișier HTML finalizat, servit dintr-un CDN, rapid și identic pentru fiecare vizitator și fiecare bot.
Randarea la cerere (pe server) necesită un adaptor pentru gazda ta (Node, Netlify, Vercel sau Cloudflare, de exemplu). Poți scoate o singură rută din pre-randare cu export const prerender = false, sau poți comuta întregul proiect cu output: 'server' și reactivezi paginile statice. Ambele moduri produc HTML complet, deci Google vede același lucru. Diferențele sunt în altă parte:
Regula practică: păstrează paginile de marketing, articolele de blog și documentația statice, iar randarea la cerere folosește-o doar pentru rutele care au nevoie de date live. Documentația Astro dă aceeași recomandare: păstrează modul static implicit până când majoritatea paginilor au nevoie de randare la cerere.
Creează o componentă SEO (de multe ori numită BaseHead sau Seo) și include-o în head-ul fiecărui layout. Ea primește un titlu, o descriere, o imagine opțională și un indicator opțional noindex, și generează:
Setează mai întâi opțiunea site în astro.config.mjs: canonicalul, sitemap-ul și tag-urile sociale depind de ea. Apoi alege o politică trailingSlash ('always' sau 'never') și respect-o, ca /blog/post și /blog/post/ să nu concureze ca două versiuni ale aceleiași pagini. Parametrii din URL trebuie eliminați din canonical, ca parametrii de urmărire să nu creeze duplicate.
Sfat
Dacă articolele tale trăiesc în colecții de conținut, fă ca titlul și descrierea să fie câmpuri obligatorii în schema colecției. Build-ul se oprește atunci când un autor uită o meta-descriere, în loc să trimită un fragment gol către Google.
Folosește integrarea oficială documentată pe pagina @astrojs/sitemap. Rularea comenzii npx astro add sitemap o instalează și o adaugă în configurare. Are nevoie de opțiunea site și, în momentul build-ului, scrie un fișier sitemap-index.xml care indică spre fișiere numerotate (sitemap-0.xml, apoi altele pe site-urile mari). Fiecare fișier conține implicit până la 45000 de intrări, setate prin opțiunea entryLimit. Dacă ești nou în acest format, intrarea noastră din glosar despre sitemap-ul XML explică ce face Google cu el.
Trei setări contează pentru SEO:
Atenție
Documentația precizează că integrarea nu poate genera intrări în sitemap pentru rutele dinamice în modul SSR. Dacă paginile tale de produs sau de articol sunt randate la cerere, lipsesc din sitemap, în afară de cazul în care le pre-randezi sau le adaugi tu.
Pentru robots.txt, un fișier static în folderul public este suficient pe majoritatea site-urilor. Dacă conținutul diferă între mediul de test și producție, generează-l din endpoint (src/pages/robots.txt.ts). În ambele cazuri, adaugă o linie Sitemap care indică spre sitemap-index.xml și testează rezultatul cu un verificator robots.txt înainte de lansare. Aceeași tehnică de endpoint produce un fișier llms.txt; ghidul nostru despre cum instalezi un fișier llms.txt îi acoperă conținutul.
Rutarea i18n integrată a Astro se ocupă de partea URL-urilor. În configurare declari un defaultLocale și o listă de locale și alegi dacă limba implicită primește și un prefix (prefixDefaultLocale). Funcții ajutătoare precum getRelativeLocaleUrl construiesc linkuri localizate, iar Astro.currentLocale îi spune fiecărei pagini în ce limbă este.
Ghidul de rutare nu acoperă tag-urile hreflang din head, deci planifică să le scrii tu în componenta SEO: pentru fiecare pagină, câte un link alternativ pentru fiecare versiune lingvistică, plus un x-default, toate ca URL-uri absolute, iar fiecare versiune trebuie să le listeze pe toate celelalte (linkuri de retur). Generarea lor din aceeași listă de locale ca rutarea evită cea mai frecventă greșeală, o alternativă care indică spre o pagină inexistentă. Ca să verifici logica pe câteva URL-uri, generatorul nostru hreflang produce setul complet de tag-uri pentru o pagină. Apoi activează opțiunea i18n a sitemap-ului ca al doilea semnal.
Viteza este domeniul în care Astro câștigă cel mai mult și se vede în Core Web Vitals. Ghidul Astro pentru imagini descrie componenta Image din astro:assets: optimizează imaginile locale, le convertește formatul, generează încărcare leneșă și decodare asincronă și deduce dimensiunile imaginii pentru a evita Cumulative Layout Shift. Atributul alt este obligatoriu la ea, ceea ce impune o regulă de bază a SEO-ului pentru imagini. Componenta Picture merge mai departe și servește AVIF sau WebP, cu o variantă de rezervă.
Două obiceiuri completează imaginea. Păstrează imaginile care trebuie optimizate în src (fișierele din public sunt servite așa cum sunt, fără procesare). Și nu aplica încărcarea leneșă imaginii principale de la începutul paginii: dă-i încărcare imediată, ca să nu întârzie Largest Contentful Paint.
Arhitectura pe insule ține JavaScriptul sub control. O componentă este HTML static până adaugi o directivă client: client:load o hidratează imediat, client:idle când browserul este liber, client:visible doar când intră în zona vizibilă. Rezervarea lui client:load pentru ce trebuie să reacționeze imediat (un meniu, un coș) este cea mai simplă cale de a proteja Interaction to Next Paint. Insulele de pe server (server:defer) lasă un bloc personalizat să se încarce după pagina din cache, fără să încetinească conținutul principal.
Notă
O insulă ascunde doar interactivitatea, nu textul, atâta timp cât componenta se randează mai întâi pe server. Conținutul încărcat în browser după încărcarea paginii este alt caz: crawlerele care nu rulează JavaScript, adică mulți crawlere AI, nu îl vor vedea.
Astro nu are o funcție de scheme, ceea ce îți lasă control deplin. Construiește un obiect JavaScript pentru fiecare tip de pagină (Article, Product, Organization, BreadcrumbList, FAQPage) și scrie-l într-un tag script de tip application/ld+json, folosind directiva set:html cu JSON.stringify, ca JSON-ul să nu fie scăpat. Alimentează-l din aceleași date frontmatter sau din colecție ca pagina vizibilă, astfel încât markupul să corespundă mereu cu ce văd utilizatorii, ceea ce este o cerință a ghidurilor Google pentru markupul de schemă.
Ca să scrii JSON-ul pentru un tip nou de pagină, generatorul nostru gratuit de scheme îți dă un bloc de pornire valid, pe care apoi îl transformi într-un șablon. Validează un eșantion de pagini construite cu Rich Results Test de la Google după fiecare modificare a șablonului.
Migrările din WordPress sau Next.js sunt momentul cel mai riscant pentru un site Astro. Păstrează fiecare URL care are trafic sau backlinkuri și asociază celelalte, unul câte unul, cu echivalentul cel mai apropiat, prin redirecționări permanente, așa cum explicăm în ghidul nostru despre redirecționările SEO.
Configurarea Astro acceptă un obiect redirects care asociază căile vechi cu cele noi. Cu un adaptor de server, acestea devin redirecționări HTTP reale. Pe un build pur static, Astro scrie în schimb o pagină HTML cu un meta refresh, pe care Google o urmează, dar o tratează ca un semnal mai slab decât un 301 pe server. Pentru un site static, declară redirecționările în formatul propriu al gazdei (un fișier _redirects pe Netlify sau Cloudflare Pages, un fișier vercel.json pe Vercel), ca crawlerele să primească un 301 adevărat.
Să fii citat de ChatGPT, Perplexity sau Gemini începe cu a fi lizibil. Mulți crawlere AI descarcă HTML-ul brut și nu execută JavaScript, deci un site care trimite tot textul din primul răspuns, cum face Astro implicit, înlătură o barieră pe care o mai au site-urile randate pe client. Titluri curate, paragrafe care răspund direct la întrebare, date structurate și un fișier llms.txt fac apoi fiecare pagină mai ușor de citat.
După lansare, măsoară în loc să ghicești. Panoul Sorank GEO și SEO reunește datele tale din Search Console și vizitele venite de la asistenții AI, ca să vezi dacă noul site își menține pozițiile.

Calitatea tehnică se plătește doar cu conținut care se poate clasa. generatorul de articole de blog cu AI al Sorank scrie și publică articole optimizate pentru Google și asistenții AI și se conectează la un site personalizat, precum un proiect Astro, prin webhook.
Astro îți oferă implicit HTML rapid și crawlabil; clasarea depinde în continuare de tag-urile head, sitemap-ul, hreflang, datele structurate și redirecționările pe care le adaugi peste acestea. Configurează mai întâi componenta SEO comună și sitemap-ul, apoi parcurge tabelul de mai sus înainte de lansare.
Nu. Astro nu are un plugin SEO oficial tot-în-unu: scrii titlul, meta-descrierea, canonicalul și tag-urile sociale într-o componentă comună de head. Integrarea oficială @astrojs/sitemap acoperă sitemap-ul. Există pachete din comunitate, dar o componentă mică, scrisă de tine, este ușor de întreținut și rămâne complet sub controlul tău.
Ambele pot produce HTML complet randat, deci Google poate indexa bine oricare. Astro trimite implicit mult mai puțin JavaScript, ceea ce face de obicei site-urile de conținut mai rapide și ajută Core Web Vitals. Next.js se potrivește mai bine aplicațiilor foarte interactive; pentru bloguri, site-uri de marketing și documentație, Astro este alegerea mai simplă pentru SEO.
Da. O pagină randată la cerere returnează în continuare HTML complet către Googlebot, exact ca o pagină pre-randată. Punctele de urmărit sunt timpul de răspuns al serverului, care afectează viteza de încărcare, și integrarea sitemap, care nu poate lista rutele dinamice randate în modul server decât dacă le adaugi tu.
AU ÎNCERCAT SORANK ÎNAINTEA TA
