SEO pentru dezvoltatori: randare, coduri de stare, etichete, performanță și crawlere AI

Test rapid

Ți se potrivește SEO și cum ar trebui să începi?

Întrebarea 1 din 425%

Oamenii caută pe Google ce vinzi?

Da, cred că daNu, este nou sau foarte de nișăNu știu

SEO pentru dezvoltatori este partea optimizării pentru motoarele de căutare care trăiește în cod: șabloane, rutare, randare, anteturi și performanță. Specialiștii în marketing aleg cuvintele cheie și scriu conținutul, dar un cod de stare greșit, o rută doar pe client sau un noindex uitat pot șterge toată această muncă dintr-un singur deploy. Noțiunile de bază despre SEO pentru JavaScript ale Google descriu trei etape (crawling, randare, indexare), iar fiecare are defecte pe care doar dezvoltatorii le pot remedia. Acest ghid le parcurge în ordinea în care se strică.

Ce parte a SEO ține de dezvoltator?

Cum ar trebui randate paginile pentru motoarele de căutare?

Googlebot randează JavaScript, dar într-un al doilea pas, care poate fi întârziat, iar Google scrie el însuși că „randarea pe server sau pre-randarea rămâne o idee foarte bună”, pentru că este mai rapidă atât pentru utilizatori, cât și pentru crawlere, și pentru că nu toți boții rulează JavaScript. Acest ultim punct contează acum mai mult ca niciodată: în analiza din decembrie 2024 The rise of the AI crawler, Vercel a constatat că „niciunul dintre marii crawlere AI nu randează în prezent JavaScript”, printre ei numărându-se GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot și PerplexityBot. Gemini, care folosește infrastructura Google, este excepția.

Două reguli se aplică oricare ar fi framework-ul. Linkurile trebuie să fie elemente <a> cu atributul href: Google precizează că poate descoperi doar linkurile în această formă, deci butoanele cu handlere de click și rutele bazate pe fragmente sunt fundături. Și fiecare rută are nevoie de propriul URL, fără #, care returnează direct conținutul. Ghidurile noastre despre SEO pentru JavaScript, SEO pentru aplicații cu o singură pagină și SEO pentru Next.js detaliază aspectele specifice fiecărui framework.

Ce coduri de stare HTTP contează pentru SEO?

Codurile de stare sunt instrucțiuni pentru crawlere. Documentația Google despre codurile de stare HTTP și erorile de rețea descrie cum este tratată fiecare familie:

• 200: pagina este eligibilă pentru indexare. Dacă conținutul pare o eroare sau o pagină goală, Search Console raportează un soft 404.
• 301 și 308: redirecționări permanente, pe care Google le tratează ca un semnal puternic că destinația trebuie procesată. Folosește-le pentru conținut mutat și pentru schimbări de domeniu.
• 302 și 307: redirecționări temporare, semnal slab. Nu le folosi pentru mutări permanente.
• 404 și 410: pagina nu există. Google renunță treptat la URL. Returnează un 404 real, nu un 200 cu textul „pagină negăsită”.
• 429 și 5xx: crawlerele Google încetinesc crawlingul, iar URL-urile care returnează constant erori de server ajung până la urmă eliminate din index.

Verifică ce trimite serverul tău cu adevărat folosind un verificator de anteturi HTTP, și păstrează lanțurile de redirecționare la un singur salt: articolul nostru despre redirecționările SEO acoperă modelele de migrare.

Ce etichete trebuie să fie în head-ul HTML?

Fiecare pagină indexabilă are nevoie de un titlu și o descriere unice, de un canonical care trimite la ea însăși și, pe site-urile multilingve, de adnotări hreflang. Păstrează-le în răspunsul serverului:

<title>Running shoes for flat feet | Example</title>
<meta name="description" content="Tested picks, sizes and prices.">
<link rel="canonical" href="https://example.com/running-shoes-flat-feet">
<link rel="alternate" hreflang="fr" href="https://example.com/fr/chaussures-pieds-plats">
<meta name="robots" content="index, follow">

Eticheta canonical trebuie să indice URL-ul pe care vrei să îl vezi clasat, cu protocolul, gazda și convenția de bară finală exact ca pe site-ul tău.

Cum ar trebui construite URL-urile și linkurile interne?

Motoarele de căutare indexează URL-urile, deci schema URL-urilor este o decizie de SEO. Folosește căi lizibile, scrise cu litere mici și cu cratime; alege o singură convenție pentru bara finală și redirecționează-o pe cealaltă; și păstrează un singur URL pentru fiecare bucată de conținut. Filtrele, sortările și parametrii de urmărire înmulțesc URL-urile fără să adauge conținut: canonicalizează-le spre versiunea curată și nu crea linkuri către combinații de parametri pe care nu vrei să le crawl-ezi.

Linkurile interne poartă atât descoperirea, cât și importanța. Randează navigația, breadcrumb-urile și blocurile de conținut conex pe server, oferă listelor paginate linkuri simple către fiecare pagină și evită derularea infinită fără URL-uri paginate în spate. Un produs sau un articol accesibil doar prin căutarea de pe site sau printr-un filtru JavaScript este, pentru un crawler, o pagină orfană.

Cum se încadrează robots.txt și sitemap-urile?

robots.txt controlează crawlingul, nu indexarea: un URL blocat poate apărea totuși în rezultate dacă alte pagini îl link-uiesc. Ca să ții o pagină în afara indexului, lasă-o să fie crawl-ată și returnează noindex. Generează sitemap-ul XML din rutele sau din baza ta de date, listează doar URL-urile canonice cu 200 și actualizează lastmod doar când conținutul se schimbă cu adevărat. Testează regulile cu un verificator robots.txt înainte de fiecare lansare și nu trimite niciodată în producție un robots.txt de staging cu „Disallow: /”.

Cum afectează performanța clasările?

Google folosește Core Web Vitals ca parte a semnalelor sale de experiență a paginii. Potrivit web.dev, o pagină este bună atunci când atinge aceste praguri la percentila 75 a încărcărilor reale, pe mobil și pe desktop:

INP a înlocuit First Input Delay ca Core Web Vital stabil în 2024. Folosește datele de teren (Search Console, Chrome UX Report) ca să judeci și instrumentele de laborator ca să depanezi. Intrarea noastră din glosar despre Core Web Vitals enumeră instrumentele.

Cum adaugi date structurate?

Folosește JSON-LD într-un tag script, randat pe server, care descrie ceea ce este vizibil pe pagină:

<script type="application/ld+json">
{"@context": "https://schema.org", "@type": "Article",
 "headline": "Running shoes for flat feet",
 "datePublished": "2026-10-01",
 "author": {"@type": "Person", "name": "Jane Doe"}}
</script>

Generează-l din aceleași date ca pagina, ca cele două să nu divergă niciodată, validează-l în CI și evită să-l injectezi printr-un tag manager. Un generator de scheme oferă un șablon de pornire pentru tipurile uzuale.

Cum faci un site lizibil pentru asistenții AI?

Vizibilitatea în AI începe cu accesul. Decide ce user agents AI permiți (GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot și alții) și scrie reguli explicite în robots.txt; ghidul nostru despre robots.txt pentru crawlerele AI explică diferența dintre boții de antrenament și cei de căutare. Apoi asigură-te că textul, prețurile, specificațiile și FAQ-ul sunt în HTML-ul inițial, folosește titluri și tabele semantice în loc de imagini cu text și păstrează paginile suficient de ușoare ca să fie descărcate repede. Un fișier llms.txt poate rezuma paginile-cheie pentru instrumentele AI, dar niciun asistent important nu a confirmat că se bazează pe el, deci tratează-l ca opțional.

Sorank este produsul nostru: un software de SEO și GEO autopilot. Dezvoltatorii îl întâlnesc în special prin integrările sale: publică articole pe WordPress, Shopify, Webflow sau Wix, sau pe orice stack personalizat printr-un webhook, cum este descris pe pagina de instalare. Chatul SEO răspunde la întrebări despre site-ul tău în conversație, iar Urmărirea mențiunilor AI verifică în fiecare lună dacă ChatGPT, Claude și Gemini citează brandul tău.

Versiunea scurtă: livrează din server HTML complet, coduri de stare sincere și etichete head corecte, apoi măsoară performanța pe utilizatori reali. Asta servește Googlebot și crawlerele AI care nu rulează JavaScript. Ca să umpli un site bine construit cu conținut care se clasează, vezi planurile Sorank, de la 49$ pe lună, cu o perioadă de probă gratuită de 3 zile.