Ce este SEO tehnic — fundația invizibilă care decide dacă Google te poate citi

SEO tehnic este munca prin care un site devine accesibil, inteligibil și stabil pentru motoarele de căutare: Google trebuie să poată descoperi URL-ul, să îi acceseze resursele, să proceseze conținutul și să aleagă versiunea corectă pentru index. Abia după aceea conținutul poate concura pentru vizibilitate.

Nu este o colecție de scoruri și nici un serviciu rezervat magazinelor mari. O bifă greșită în CMS poate scoate o pagină din index, iar un șablon lent poate face un formular greu de folosit. Pentru contextul mai larg, vezi ce este SEO; aici rămânem strict la fundația tehnică.

Distincția contează fiindcă o problemă tehnică se repară altfel decât una editorială. Dacă serverul livrează o eroare, dacă o directivă interzice indexarea sau dacă textul există numai după o interacțiune pe care crawlerul nu o execută, rescrierea paginii nu rezolvă cauza. Invers, dacă URL-ul este accesibil și indexabil, dar răspunsul este vag, instalarea unui plugin nu va crea relevanță. Cerințele tehnice minime publicate de Google sunt surprinzător de scurte: Googlebot să nu fie blocat, pagina să răspundă funcțional și conținutul indexabil să existe într-un format acceptat. Restul muncii tehnice reduce ambiguitatea, erorile și risipa.

Ce înseamnă SEO tehnic, fără jargon

Imaginează-ți site-ul ca pe un magazin. Conținutul este marfa și argumentul de vânzare. SEO tehnic înseamnă că adresa există, ușa se deschide, raioanele pot fi parcurse, etichetele indică produsul corect și casa de marcat funcționează.

Procesul are patru porți:

1. Descoperire: Google află că URL-ul există, de regulă prin linkuri sau sitemap.
2. Accesare: crawlerul primește pagina și resursele necesare, fără blocaje accidentale.
3. Procesare: conținutul, imaginile și JavaScript-ul pot fi interpretate.
4. Indexare și servire: Google decide dacă păstrează pagina și pentru ce căutări poate fi relevantă.

Trecerea porților nu garantează o poziție. Documentația Google separă clar eligibilitatea tehnică de evaluarea relevanței și calității. Un site perfect accesibil, dar cu pagini nefolositoare, rămâne un site nefolositor.

Ghidul detaliat despre funcționarea Google Search descrie trei etape — crawling, indexing și serving — și precizează că nu toate paginile trec prin fiecare. Pentru proprietarul site-ului, SEO tehnic înseamnă să transforme fiecare etapă într-o întrebare care poate fi testată, nu într-o presupunere.

Această separare previne două erori frecvente: să numești „problemă de indexare” orice pagină fără trafic și să numești „problemă de conținut” o pagină pe care Google nu o poate accesa. În primul caz ai nevoie de date despre interogări și relevanță; în al doilea, de reproducerea blocajului tehnic.

Ce verifică Google înainte să afișeze o pagină

Google Search funcționează în trei etape generale: crawling, indexing și serving. Nu fiecare pagină trece automat în etapa următoare, iar accesarea și indexarea nu sunt garantate.

Ghidul Google pentru dezvoltatori recomandă URL Inspection sau Rich Results Test pentru a vedea pagina din perspectiva sistemului. Nu este suficient să o deschizi în browserul tău: poți fi autentificat, poți avea resurse în cache sau poți vedea o versiune diferită de cea servită crawlerului.

URL Inspection din Search Console este testul cel mai apropiat de întrebarea „ce vede Google?”. Raportul arată starea URL-ului indexat, versiunea canonică și permite testarea paginii live. Pentru un diagnostic complet al paginilor absente, folosește ghidul despre indexarea în Google.

Există însă două fotografii diferite. Documentația URL Inspection separă datele despre versiunea indexată de testul live. Prima fotografie arată ce știe Google din ultima procesare; a doua verifică ce poate accesa acum. O remediere poate apărea în testul live și să lipsească încă din index până la recrawl. De aceea, jurnalul trebuie să noteze cel puțin URL-ul, data testului, canonicalul declarat, canonicalul ales, resursele blocate și capturile relevante.

Pentru un singur URL, ordinea de control este:

1. deschizi rezultatul indexat și notezi starea, ultima accesare și canonicalul ales;
2. rulezi testul live, fără să presupui că repetă informația indexată;
3. compari captura sau HTML-ul randat cu pagina vizibilă utilizatorului;
4. repari cauza la nivel de șablon dacă afectează un tip întreg de pagină;
5. soliciți indexarea numai după ce testul live vede versiunea corectă;
6. revii după recrawl și separi confirmarea implementării de impresiile ulterioare.

Probleme tehnice frecvente pe site-urile mici

Cele mai costisitoare erori nu sunt întotdeauna sofisticate. Apar după lansare, migrare, schimbarea temei sau activarea unui plugin.

Nu toate paginile neindexate indică o eroare. Search Console spune explicit că „Not indexed” poate fi legitim pentru duplicate, redirecționări sau pagini excluse intenționat. Întrebarea utilă este dacă URL-urile importante sunt indexate, nu dacă procentul ajunge la 100%.

Patru fișiere sau semnale sunt confundate des. Robots.txt controlează accesarea, nu este metoda corectă pentru eliminarea sigură a unei pagini HTML din index. noindex cere ca pagina să nu fie indexată, dar crawlerul trebuie să o poată accesa ca să vadă directiva. Canonicalul este un semnal pentru alegerea versiunii reprezentative, nu o redirecționare și nu o interdicție. Sitemapul enumeră URL-urile preferate pentru descoperire; nu obligă Google să le indexeze.

Și răspunsul serverului are semnificație. Documentația Google despre efectul codurilor HTTP asupra căutării trebuie citită împreună cu standardul HTTP: 200 indică o cerere reușită, 301 o mutare permanentă, 404 faptul că resursa nu a fost găsită, iar 410 că a fost eliminată intenționat. O pagină vizuală de eroare servită cu 200 poate arăta bine pentru om, dar transmite serverului și crawlerului că există o resursă normală.

La site-urile mici, cauzele apar de obicei după schimbări concrete:

• mediul de dezvoltare este mutat live cu noindex sau cu blocajul general păstrat;
• versiunea HTTP, HTTPS, cu www și fără www nu converge spre aceeași destinație;
• pluginul SEO generează canonical diferit de URL-urile din sitemap și din linkurile interne;
• filtrele și parametrii produc multe variante aproape identice;
• șablonul returnează aceeași pagină pentru URL-uri inexistente;
• JavaScript-ul încarcă târziu conținutul principal sau îl cere dintr-un API blocat;
• o migrare păstrează meniul, dar pierde redirecționările de la URL-urile vechi.

Nu porni de la numele erorii dintr-o unealtă. Reprodu problema pe un URL, identifică stratul care o produce și verifică dacă se repetă pe același șablon. Aceasta transformă o listă de sute de avertismente într-un număr mic de cauze remediabile.

Prioritatea nu vine din culoarea raportului, ci din combinația dintre rolul paginii, amploarea efectului și certitudinea diagnosticului. Un noindex pe toate paginile de servicii are altă greutate decât un title duplicat pe două arhive fără trafic. Înainte să deschizi un ticket, numără URL-urile afectate și verifică dacă problema lovește un traseu comercial real.

După remediere, repetă exact controlul care a demonstrat problema. Dacă ai diagnosticat un răspuns 404, verifică răspunsul serverului, nu doar aspectul paginii. Dacă ai diagnosticat canonicalul, compară versiunea declarată, versiunea aleasă și linkurile interne. Dacă ai diagnosticat randarea, caută textul și linkurile în rezultatul randat. O captură „arată bine” nu este echivalentă cu testul tehnic potrivit.

Această disciplină reduce și riscul de a optimiza lucruri care nu schimbă nimic. Un audit poate raporta sute de abateri de stil, dar proprietarul are nevoie de o ordine: blocaje de acces și indexare, erori care afectează șabloane comerciale, experiență și stabilitate, apoi curățenie tehnică. Ordinea se reface după fiecare val, fiindcă repararea unei cauze poate elimina multe simptome.

Ce poți verifica singur, fără programator

Începe cu paginile care produc bani: servicii, categorii, produse importante și formulare. Pentru fiecare:

• caută URL-ul în Search Console și rulează URL Inspection;
• deschide pagina pe telefon într-o fereastră privată;
• verifică dacă textul și imaginile apar complet;
• urmărește toate linkurile importante și formularul;
• confirmă că URL-ul nu redirecționează neașteptat;
• caută în sursa HTML noindex și canonical dacă știi unde sunt;
• verifică dacă pagina este legată din navigație sau dintr-o pagină relevantă.

Poți rula și PageSpeed Insights, dar nu lua decizii după culoarea unui singur scor. Separă datele de teren, culese de la utilizatori reali, de testul de laborator executat într-un mediu controlat. Ghidul despre viteza site-ului și Core Web Vitals explică diferența.

PageSpeed Insights poate afișa date de teren și un test Lighthouse, dar cele două răspund unor întrebări diferite. Datele de teren agregă experiențe reale, iar laboratorul reproduce o sesiune controlată și ajută la diagnostic. Pentru Core Web Vitals, reperele publicate sunt LCP de cel mult 2,5 secunde, INP de cel mult 200 milisecunde și CLS de cel mult 0,1 la percentila 75; web.dev explică atât pragurile, cât și separarea pe mobil și desktop. Aceste cifre sunt repere de experiență, nu o formulă de poziționare.

Un control de 20 de minute, fără abonament SEO, poate arăta astfel:

Nu repari tot în acest interval. Obții o listă reproductibilă, cu URL și dovadă. Dacă o problemă apare pe toate paginile de serviciu, prioritatea ei este diferită de un avertisment izolat pe o pagină veche.

Semnal bun: pagina importantă este accesibilă, indexabilă, legată intern, randată complet și utilizabilă pe mobil.

Când ai nevoie de un specialist pentru partea tehnică

Nu modifica la întâmplare robots.txt, redirecturi sau canonical. O remediere aplicată global poate afecta mii de URL-uri. Cere ajutor când:

• aceeași problemă apare pe un întreg tip de pagină;
• site-ul a fost migrat sau urmează să-și schimbe domeniul;
• paginile sunt generate prin JavaScript și testul live nu vede conținutul;
• serverul răspunde intermitent cu erori;
• există sute de variante de filtrare și parametri;
• tema sau pluginurile schimbă automat directivele SEO;
• datele de teren indică experiență slabă, dar cauza nu este evidentă.

Un specialist bun nu livrează doar o listă de erori. Pentru fiecare constatare arată URL-ul afectat, impactul, metoda de reproducere, responsabilul și testul de acceptare. Acesta este și standardul dintr-un audit SEO pas cu pas.

Ai nevoie de programator când remedierea schimbă răspunsul serverului, rutarea, șablonul, încărcarea resurselor sau logica aplicației. Ai nevoie de specialist SEO când trebuie stabilit ce URL merită indexat, cum se consolidează duplicatele, ce pagini primesc legături și cum se validează migrarea. Uneori este nevoie de amândoi: SEO-ul definește comportamentul dorit și cazurile de test, iar programatorul îl implementează fără efecte secundare.

Ghidul Google pentru JavaScript SEO arată de ce o aplicație poate funcționa în browser și totuși să ceară controale suplimentare de randare, titluri, linkuri și coduri HTTP. Pentru o migrare, documentația despre schimbarea URL-urilor tratează maparea și monitorizarea ca proces, nu ca simpla instalare a unui certificat sau copiere a fișierelor.

Brief-ul tehnic trebuie să includă:

• lista de șabloane și exemplele de URL afectate;
• comportamentul actual, cu pași de reproducere;
• comportamentul dorit pentru utilizator și crawler;
• răspunsul HTTP, directiva și canonicalul așteptate;
• riscul unei modificări globale și metoda de revenire;
• controlul pe staging și controlul după publicare;
• persoana care confirmă remedierea și data recrawlului.

Fără aceste câmpuri, „rezolvă SEO-ul tehnic” devine un ticket imposibil de verificat. Cu ele, recomandarea are proprietar, condiție de terminare și urme măsurabile.

Cum arată dovada că fundația tehnică funcționează

Dovada este un lanț de teste, nu un badge „SEO 100”.

Pentru o firmă mică, raportarea lunară ar trebui să arate ce s-a rupt, ce s-a remediat și cum s-a confirmat. Dacă primești doar un scor care se schimbă fără explicație, nu ai încă dovada că fundația funcționează. Serviciul nostru de optimizare SEO tratează tehnicul ca parte a unui sistem, împreună cu paginile și măsurarea.

Harta SEO-07 cere și o dovadă internă despre audituri tehnice pe site-uri de IMM, blocajele de citire întâlnite cel mai des și timpul de remediere. Registrul cu proiectele nu este disponibil în materialele acestei redactări. Articolul nu transformă cerința într-un număr estimat. Când registrul este furnizat, datele se adaugă separat, cu definiția eșantionului, perioada, tipurile de site, regula de numărare a unui blocaj și diferența dintre timpul de implementare și timpul până la recrawl.

Fișa de dovadă poate avea următoarele coloane:

Abia după completarea câmpurilor poți spune care blocaj a apărut cel mai des și cât a durat remedierea. Până atunci, dovada disponibilă este metoda de test și limita declarată.

Ghidul tehnic publicat de Autoritatea pentru Digitalizarea României include verificări de utilizabilitate și redimensionare la 200%; este o sursă locală pentru controlul experienței, separată de metricile de performanță definite de web.dev.

Întrebări frecvente

Ce pot verifica singur la partea tehnică, fără programator?

Starea URL-urilor importante în Search Console, funcționarea pe mobil, linkurile, formularele, redirecturile vizibile și existența paginii în navigație. Nu schimba reguli globale dacă nu înțelegi efectul lor.

Cum îmi dau seama că problema este tehnică și nu de conținut?

Dacă pagina nu poate fi accesată, randată sau indexată corect, problema este întâi tehnică. Dacă trece aceste teste, dar nu răspunde intenției ori nu oferă valoare distinctă, conținutul devine ipoteza principală.

Un scor PageSpeed mic înseamnă că nu mă pot poziționa?

Nu. Viteza și experiența paginii contează, dar Google folosește multe semnale. Un scor de laborator este un diagnostic, nu o sentință și nu înlocuiește datele reale.

Sitemapul garantează indexarea?

Nu. Ajută Google să descopere URL-urile importante, dar documentația oficială spune că includerea într-un sitemap nu garantează crawlingul sau indexarea.

Cât de mare poate fi un sitemap XML?

Specificația folosită de Google limitează un singur sitemap la 50 MB necomprimat sau 50.000 de URL-uri. Pentru un site mai mare se folosesc mai multe sitemapuri și, opțional, un index de sitemapuri. Limita nu spune că toate URL-urile enumerate vor fi indexate.

Fundația se verifică înainte să se cosmetizeze

Ordinea bună este simplă: acces, randare, indexare, experiență, apoi relevanță și rezultat. Când fiecare etapă are un test de acceptare, SEO tehnic încetează să fie o zonă misterioasă și devine muncă verificabilă.

În practică, începi cu cinci URL-uri care contează comercial, nu cu scorul întregului domeniu. Verifici versiunea indexată și versiunea live, grupezi problemele după cauză, trimiți fiecărei cauze un responsabil și revii după implementare. Dacă pagina poate fi citită, procesată și aleasă corect, fundația este observabilă; dacă nu primește impresii sau cereri, investigația continuă spre intenție, conținut, autoritate și ofertă, fără să atribui automat totul tehnicului.