Seo Tehnic

18 Noiembrie 2025 11 minute

În SEO, SEO-ul Tehnic este fundația.

Majoritatea clienților care ajung la noi vin cu o "casă" (un website) care arată acceptabil la exterior: are culori, are poze, are un text de vânzare. Dar când ne uităm "în subsol", vedem că fundația e construită pe nisip. Iar când încerci să scalezi afacerea (să mai pui un etaj), totul începe să crape: site-ul se mișcă greu, Google nu indexează paginile noi, iar campaniile plătite aduc trafic care nu convertește, pentru că viteza proastă le consumă bugetul degeaba.

În acest ghid, vei înțelege de ce un scor mic în Core Web Vitals îți taie din profit, de ce dependența de WordPress nu e întotdeauna o soluție scalabilă și cum o migrare făcută prost îți poate șterge 5 ani de istoric digital într-o singură noapte.

Ce este, de fapt, SEO Tehnic?

Metafora Fundației și a Materialelor

SEO Tehnic este o colecție de optimizări aplicate structurii, codului și infrastructurii site-ului tău. Scopul nu este să atragă utilizatorul (asta e treaba copywriter-ului), ci să se asigure că motoarele de căutare (Googlebot, Bingbot etc.) pot:

1. Accesa site-ul (fără erori de server).
2. Parcurge tot conținutul tău (fără pagini blocate accidental).
3. Înțelege ierarhia și relevanța fiecărei pagini (fără conținut duplicat sau confuzie semantică).

Poți avea cel mai bun conținut din lume, dar dacă "țevile" sunt sparte (link-uri moarte), dacă "ușa" se deschide greu (viteză mică de încărcare) sau dacă "adresa" nu e clară în cadastru (probleme de indexare), nimeni nu va intra în casă. Sau, dacă intră, vor ieși imediat, mărind rata de respingere (Bounce Rate).

De ce nu e treaba "băiatului de la IT"

O confuzie majoră este că orice programator știe SEO tehnic. Fals.

Un programator știe să facă codul să funcționeze. Un expert SEO tehnic știe să facă acel cod să fie înțeles de Google și rapid pentru utilizator. Există o diferență uriașă între a scrie un CSS care arată bine și a scrie un CSS critic care se încarcă asincron pentru a nu bloca randarea paginii.

Dacă fundația e greșită, orice efort ulterior de marketing este ca și cum ai încerca să umpli o găleată spartă.

Core Web Vitals: Nu sunt puncte pentru Google, sunt indicatori direcți ai profitului tău

Probabil ai auzit de Core Web Vitals (CWV): LCP, CLS și, mai nou, INP. CWV nu sunt doar niște note pe care Google le dă site-ului. Ele sunt standarde de User Experience (UX) traduse în metrici tehnice. Google le folosește ca semnal de clasificare deoarece știe că utilizatorii au răbdare zero cu site-urile lente sau instabile.

Traducerea CWV în rată de conversie:

1. LCP (Largest Contentful Paint)

Ce măsoară: Cât timp durează până când se încarcă cel mai mare element de conținut vizibil (imagine, bloc de text, header) pe ecran. Standardul Google: Sub 2.5 secunde. Impact Business: Dacă site-ul tău se încarcă în 6 secunde, probabilitatea ca un utilizator să plece crește cu peste 90%. Asta înseamnă că plătești reclame, omul dă click, așteaptă, se enervează și pleacă. Ai plătit click-ul, ai pierdut clientul. Soluții Tehnice Avansate:

• Optimizarea Font-urilor: Pre-încărcarea font-urilor critice (e.g., <link rel="preload" as="font" ...>).
• Imagini Viteză: Eliminarea imaginilor din zona Above the Fold sau redimensionarea lor perfectă.

2. CLS (Cumulative Layout Shift)

Ce măsoară: Stabilitatea vizuală. Cât de mult conținutul vizibil se "mișcă" sau "sare" în timp ce se încarcă resursele (imagini, reclame, bannere de cookie-uri). Standardul Google: Sub 0.1. Impact Business: Ai pățit să vrei să apeși pe butonul "Cumpără" sau "Trimite", dar în ultima fracțiune de secundă apare o reclamă sau o imagine întârziată care împinge butonul mai jos? Asta e CLS. Duce la click-uri greșite, frustrare și rată de respingere mare. Soluții Tehnice Avansate:

• Specificarea Dimensiunilor: Întotdeauna specificăm width și height pentru toate elementele media (imagini, video, iframes) în HTML.
• Spațiu Rezervat: Alocarea de spațiu fix pentru reclame sau bannere care se încarcă dinamic, folosind CSS.

3. INP (Interaction to Next Paint) - Noul Standard de Interactivitate

Ce măsoară: INP a înlocuit vechiul FID (First Input Delay) și este mult mai relevant. Măsoară timpul total de la interacțiunea utilizatorului (un click, o apăsare de tastă) până când browser-ul afișează vizual rezultatul acelei interacțiuni (de exemplu, cât durează să se deschidă meniul pop-up după click). Standardul Google: Sub 200 milisecunde. Impact Business: INP reflectă cât de "responsiv" se simte site-ul. Un INP prost înseamnă că site-ul "agață" sau "îngheață" la fiecare click. Un site care "agață" pare stricat, nesigur sau slab întreținut, reducând drastic încrederea. Soluții Tehnice Avansate (Dezvoltare):

• Optimizarea Main Thread-ului (Firul Principal): Cele mai multe probleme INP vin din sarcini JavaScript lungi. Soluția este împărțirea codului în bucăți mici (Code Splitting) și folosirea funcției requestIdleCallback sau setTimeout pentru a "ceda" controlul browser-ului.
• Reducerea Hydration-ului (în framework-uri JS): Tehnologii precum Astro abordează direct această problemă, reducând masiv JavaScript-ul trimis inițial (vezi Secțiunea 4).

Verdictul nostru: Un site lent și instabil are o rată de conversie mică, indiferent cât de bun e produsul. SEO tehnic optimizează aceste aspecte pentru a ține utilizatorul pe site și pentru a-i face experiența fluidă.

Mitul WordPress și "Pluginul care rezolvă tot"

Aceasta este discuția pe care o am cel mai des cu clienții noi. "Dar am instalat Yoast/RankMath și am toate bulinele verzi. De ce nu sunt pe prima pagină?"

Adevărul dureros despre plugin-uri

Un plugin de SEO îți permite să editezi titluri și meta-descrieri. Atât. Nu îți repară viteza serverului, nu îți optimizează codul JavaScript sau CSS și nu îți restructurează arhitectura informației.

Mai mult, mentalitatea de "există un plugin pentru asta" este exact motivul pentru care multe site-uri WordPress performează prost tehnic:

• Ai nevoie de un formular? Plugin 1.
• Ai nevoie de un slider? Plugin 2.
• Ai nevoie de caching? Plugin 3.

Rezultatul? Un "Frankenstein" digital. 20-30 de plugin-uri, multe dintre ele făcute de dezvoltatori diferiți, rulează scripturi în paralel, intră în conflict unele cu altele și îngreunează site-ul masiv. Această complexitate nejustificată se traduce în datorie tehnică (technical debt) pe care o plătești ulterior cu timp și bani.

Diferența dintre "Montator de teme" și "Dezvoltator"

Multe site-uri din România sunt făcute de freelanceri sau agenții care nu scriu cod, ci instalează teme cumpărate (ThemeForest etc.) și page builders (Elementor, Divi).

Problema cu o temă cumpărată e că a fost gândită să facă orice pentru oricine. Are mii de linii de cod, tone de font-uri și funcționalități pe care nu le vei folosi niciodată, dar pe care site-ul tău le încarcă la fiecare vizită.

• Acest bloat (încărcare inutilă) te sabotează direct la LCP și INP.
• În plus, după 2-3 ani, dacă dezvoltatorul temei nu o mai actualizează, te trezești cu o gaură de securitate și cu un site care nu mai e compatibil cu noile standarde.

Un dezvoltator cu viziune SEO tehnică construiește site-ul cu exact codul de care are nevoie, nu cu tot "kit-ul de scule".

De ce Digital Empr a ales Astro ( vs. Wordpress)

Noi nu suntem împotriva WordPress-ului (îl folosim pentru anumite bloguri), dar suntem împotriva ineficienței. Pentru clienții care vor performanță de top și scoruri perfecte la CWV, am ales să construim site-uri custom, folosind un stack modern de tip Jamstack/Static Site Generation (SSG), cu Astro ca bază.

(mai multe detalii la: WordPress to Astro: Why Our Agency Made the Switch)

JavaScript SEO: Când Google nu-ți înțelege site-ul (Probleme Tehnice Critice)

Dacă site-ul tău este construit pe o tehnologie care se bazează masiv pe JavaScript (ex: Single Page Applications - SPA, cum ar fi React sau Angular care folosesc Client-Side Rendering - CSR), ai o problemă de SEO tehnic pe care mulți o ignoră.

1. Mecanismul de Randare al Google

Google folosește un proces în două etape:

1. Crawl: Googlebot vede codul HTML sursă (foarte puțin pentru un SPA).
2. Render: Google trimite pagina către un serviciu bazat pe Chrome (Web Rendering Service - WRS) care rulează JavaScript-ul, randează pagina ca un utilizator normal și indexează conținutul.

Problema: Nu toate paginile sunt randate imediat. Unele pagini pot aștepta zile sau chiar săptămâni. Dacă conținutul tău vital (titlul, textul important) se încarcă doar prin JavaScript, riști:

• Indexare Târzie: Paginile noi apar greu.
• Indexare Grea: Googlebot poate avea probleme de Crawl Budget (buget de parcurgere) și nu randează tot conținutul.

2. Soluția de urgență: Dynamic Rendering

Pentru site-urile care trebuie să folosească CSR (de exemplu, o aplicație web complexă), recomandăm implementarea Dynamic Rendering.

• Pentru Utilizatori (Browser): Se livrează versiunea CSR (rapidă și interactivă).
• Pentru Googlebot & Alți Bots: Se livrează o versiune pre-randată (statică), care conține tot HTML-ul gata făcut.

Atenție: Dynamic Rendering nu este Cloaking (o tehnică Black Hat). Google înțelege că îi servești o versiune statică pentru a-l ajuta să indexeze conținutul rapid. Este o soluție tehnică validă, dar complexă de implementat, care necesită control la nivel de server.

Cele mai frecvente probleme tehnice pe care le găsim în audituri

Când preluăm un client nou, facem o inspecție detaliată. Iată "bubele" care apar în 8 din 10 cazuri și care mănâncă din Crawl Budget-ul tău:

1. Imagini Neoptimizate (și Erori de Caching)

Este clasic. Clientul urcă o poză de 5MB făcută cu telefonul, direct pe site.

• Impact: Site-ul se încarcă în 10 secunde pe mobil. Consumă bandă (costă bani).
• Soluția: Folosirea formatelor moderne (WebP sau AVIF), redimensionare automată la dimensiunea de afișare și lazy-loading (încărcare doar când utilizatorul ajunge la imagine).

O altă problemă este Caching-ul: dacă nu setezi corect expirarea resurselor (CSS, JS, Imagini) în header-ul HTTP, browser-ul descarcă aceleași fișiere la fiecare vizită.

2. Indexare Haotică (Index Bloat)

Teoria e simplă: vrei ca Google să îți indexeze paginile valoroase. Realitatea: Multe site-uri WordPress, lăsate pe setările default, indexează tot.

• Paginile care nu aduc valoare, dar sunt indexate: Pagini de autor, pagini de tag-uri (etichete), pagini de atașamente media, pagini de paginare (paginile 2, 3, 4 dintr-o arhivă).

Te trezești cu un site de 20 de pagini reale, dar cu 300 de URL-uri în Google. Google își consumă resursele (Crawl Budget) pe pagini inutile în loc să îți viziteze paginile de servicii, care îți aduc bani.

Soluția: Folosim combinația corectă de robots.txt (pentru a bloca parcurgerea resurselor neimportante) și noindex (pentru a bloca indexarea paginilor inutile, dar necesare pe site).

3. Conținut Duplicat Tehnic

Google urăște să vadă același conținut pe două adrese diferite. Cele mai dese greșeli tehnice sunt legate de URL-uri:

• Site-ul merge și cu http și cu https (Versiuni nesecurizate).
• Site-ul merge și cu www și fără www.
• URL-uri cu parametri de filtrare (ex: /magazin?culoare=rosu&marime=M) care afișează același conținut ca pagina principală, dar sunt indexate separat.

Soluția noastră: Folosim Canonical Tags agresiv și corect, pentru a-i spune lui Google: "Aceasta este versiunea originală, ignoră restul copiilor." De asemenea, implementăm hreflang pentru site-urile multi-limbă (RO/EN/HU), pentru a-i semnala lui Google care pagină este traducerea celeilalte.

7. Arhitectura Informațională și Optimizarea Crawl Budget

Crawl Budget-ul este ca un rezervor de benzină. Google are o cantitate limitată de resurse pe care le alocă lunar site-ului tău. Cu cât e mai mare și mai haotic, cu atât e mai ineficient.

Adâncimea de Click (Click Depth)

Aceasta este o metrică esențială pentru a determina cât de importantă este o pagină.

• Definiție: Câte click-uri îi ia utilizatorului (sau Googlebot) să ajungă de la pagina principală (Homepage) la pagina respectivă.
• Regula de Aur: Paginile de conversie (Servicii, Contact, Produse principale) nu ar trebui să fie la mai mult de 3 click-uri distanță de Homepage.

Dacă un articol de blog este îngropat la 6 click-uri sub o mulțime de pagini de arhivă, Googlebot nu îl va vizita des și nu va considera că este important.

Pagini Orfane (Orphan Pages)

O pagină orfană este o pagină care există pe site, dar către care nu există niciun link intern.

• Problema: Google știe de ea doar dacă i-ai trimis Sitemap-ul, dar nu o poate descoperi organic prin parcurgerea site-ului (crawling).
• Impact: Paginile orfane nu primesc autoritate (PageRank) și nu se poziționează niciodată bine.
• Soluția: O structură de Internal Linking Siloed (pe categorii tematice). Fiecare pagină importantă trebuie să fie legată de cel puțin o altă pagină relevantă.

Analiza Fișierelor Log (Log File Analysis)

Acest lucru este apanajul experților SEO tehnici. Analiza fișierelor log de pe serverul tău (Apache, Nginx) arată:

1. Când exact vine Googlebot (zi, oră).
2. Ce pagini parcurge cel mai des.
3. Ce pagini generează erori (Status 404, 500).
4. Cât timp îi ia să descarce o pagină (Time to Download).

Această analiză ne permite să vedem discrepanțe. De exemplu: de ce Googlebot parcurge de 100 de ori pe zi pagina de "Termeni și Condiții" și o dată pe săptămână pagina de "Servicii Principale"? Odată ce știm asta, putem ajusta structura de link-uri și semnalele de indexare pentru a reorienta Crawl Budget-ul.

Migrarea Site-ului: Cum să pierzi 5 ani de muncă într-o noapte

Să detaliem de ce o migrare făcută fără consultanță SEO tehnică duce la faliment digital:

Procesul de Mapare 1:1

Când faci un Rebranding sau o Schimbare de Temă, trebuie să tratezi migrarea ca pe o operație pe creier.

Checklist esențial (Migrare):

1. Maparea URL-urilor: Lista veche a URL-urilor trebuie mapată la lista nouă, folosind exclusiv Redirecturi 301. Nu doar 5-6 URL-uri, ci TOATE, inclusiv cele vechi care încă mai primesc trafic.
2. Maparea Titlurilor/H1: Tema nouă nu trebuie să genereze titluri generice. Titlurile (H1) și meta-titlurile trebuie să fie copiate 1:1, pentru că Google te cunoaște după ele.
3. Verificarea Indexării: După lansare, se verifică imediat în Google Search Console și cu un Screaming Frog sau un tool similar, că noul site nu a introdus mii de pagini inutile la indexare.

Studiu de Caz: Pierderea masivă de trafic

Clientul avea un istoric de 5-6 ani, cu o medie de 50 de vizite organice zilnice, pe o nișă B2B. Schimbarea temei a fost făcută de un designer excelent, dar ignorant SEO. Designerul nu a implementat redirecturi și a lăsat vechile URL-uri să returneze Eroare 404.

• În 3 săptămâni, traficul a scăzut la 2 vizite zilnice.
• Googlebot a văzut că 90% din site-ul vechi a dispărut și l-a considerat inoperabil.
• Recuperarea, care a inclus găsirea vechilor URL-uri (din arhivele web și Search Console) și implementarea a 50 de redirecturi manuale, a durat 6 luni. Costul total (consultanță, trafic pierdut) a fost de 5 ori mai mare decât ar fi fost o migrare planificată.

Lecția: Nu dați switch la tot site-ul într-o noapte. Migrarea se face secțiune cu secțiune și se verifică statusul fiecărei pagini înainte și după. Doar un consultant SEO tehnic îți poate garanta că nu îți ștergi istoria digitală.

Mecanica Fină: Redirecturi, Schema și Status Codes (Nivel Code)

Pentru cei care vor să înțeleagă exact cum se face corect, iată câteva soluții la nivel de cod.

Implementarea Redirectului 301 (Permanent)

Un redirect prost implementat poate crea un Lanț de Redirecturi (A -> B -> C -> D), care nu doar încetinește site-ul, dar și diluează autoritatea. Un 301 curat se face la nivel de server, în fișierul .htaccess (Apache) sau în fișierul de configurare nginx.conf.

Atenție: Niciodată nu faci Redirect 301 către Homepage (/) decât dacă pagina veche nu are nicio relevanță tematică. Dacă are legătură cu un serviciu, fă Redirect către acel serviciu!

Structured Data (Schema.org) Corectă

Schema Markup ajută Google să afișeze rezultate îmbogățite (Rich Snippets) care atrag atenția (review-uri cu steluțe, prețuri, întrebări frecvente).

Validare: După implementare, trebuie să folosești Google Rich Results Test pentru a te asigura că schema este citită corect. Dacă nu validezi, riști să fi făcut o muncă inutilă.

SEO Local și Tehnic: De ce o virgulă te costă clienți

Pentru afacerile locale (cabinete, restaurante, service-uri), SEO tehnic înseamnă și consistență în afara site-ului.

Conceptul NAP (Name, Address, Phone).

Trebuie să fie identic pe toate platformele unde ești listat (Google Business Profile, site-ul tău, directoare, Facebook).

Exemple de Inconsistență care te penalizează:

• Nume: Pe site: SRL X | Pe Google: SRL X Consulting.
• Adresă: Pe site: Str. Libertății, Nr. 5 | Pe Google: Strada Libertății 5.
• Telefon: Pe site: 07xx.xxx.xxx | Pe Google: +40 7xx xxx xxx.

Inconsistența detaliilor NAP este un semnal negativ de ranking local. Google pierde încrederea în identitatea afacerii tale.

Soluția: Folosește Schema.org LocalBusiness pe site pentru a dicta exact cum arată datele tale. Apoi, copiază-le exact așa pe toate celelalte platforme.

SEO tehnic nu vinde singur, dar fără el pierzi bani

SEO Tehnic nu este o destinație, ci un proces continuu. Nu e la fel de "sexy" ca un copy bun sau o campanie virală pe TikTok. Dar este multiplicatorul eforturilor tale:

• Ai un site cu SEO Tehnic bun? Fiecare articol de blog va ranka mai ușor. Fiecare euro investit în Ads va converti mai bine.
• Ai un site cu probleme tehnice? Te lupți cu morile de vânt.

La Digital Empr, abordarea noastră este bazată pe rezultate și pe eficiență:

1. Fundamente: Control total asupra codului prin Astro pentru site-uri rapide și scalabile.
2. Transparență: Înțelegi exact ce rezolvăm și de ce (CWV, INP, Crawl Budget).
3. Conversii: Optimizăm viteza și stabilitatea vizuală pentru a transforma vizitatorii în clienți.

Checklist de Audit Tehnic Rapid pentru Antreprenori

Iată 5 întrebări simple la care trebuie să răspunzi pentru a vedea dacă ai o problemă de fundație: