WordPress ridică rar probleme de SEO tehnic din start. Le acumulează în timp, prin plugin-uri instalate peste altele, teme schimbate fără curățenie și setări bifate din reflex. Cele mai multe probleme pe care le prindem în audituri se rezolvă din back-office, fără dezvoltator, dacă știi unde să te uiți.
Preluăm des site-uri pe WordPress care arată bine la o privire rapidă și au trafic în cădere de câteva luni. Nu e nimic spectaculos în cauze. E o combinație de decizii mărunte, luate de oameni diferiți, pe care nimeni nu le-a verificat împreună. Mai jos sunt opt situații pe care le întâlnim aproape în orice audit tehnic pe WordPress, cu ce se strică efectiv și ce facem noi când preluăm site-ul.
1. Setarea „Descurajați motoarele de căutare” rămasă activă după lansare
În Setări – Citire există un checkbox care spune site-ului să ceară motoarelor de căutare să nu îl indexeze. Se bifează în timpul dezvoltării, ca să nu apară versiunile de test în Google. La lansare, cineva trebuie să îl debifeze. Uneori, nu se întâmplă.
Efectul este că WordPress adaugă un noindex pe tot site-ul și un Disallow în robots.txt. Nu contează cât conținut ai scris, câte linkuri ai construit sau cât de rapid e site-ul. Google nu indexează nimic.
Verificarea durează treizeci de secunde. Intri în Setări – Citire și te uiți la ultima opțiune. Dacă e bifată, o debifezi. Apoi deschizi raportul Indexare pagini din Search Console și forțezi reindexarea paginilor importante. Găsim asta la site-uri lansate de câteva luni, cu clientul convins că „SEO-ul are nevoie de timp”.
2. Permalink-uri pe structura implicită
Structura implicită WordPress generează URL-uri de tipul ?p=123. Sunt funcționale, dar nu spun nimic despre pagină nici pentru utilizator, nici pentru Google. Structura recomandată este cea cu numele articolului, setată din Setări – Legături permanente.
Problema apare când schimbi structura pe un site care are deja pagini indexate. Toate URL-urile vechi devin 404 dacă nu adaugi redirect-uri 301 către cele noi. Am văzut migrări în care s-a schimbat structura peste noapte, fără redirect-uri, iar traficul a picat cu totul în trei săptămâni.
Dacă site-ul e nou, setezi structura corectă înainte să publici. Dacă e vechi, faci maparea URL-urilor și redirect-urile înainte de orice schimbare. Nu invers.
3. Categorii și taguri indexate fără să vrei
WordPress generează automat pagini de arhivă pentru fiecare categorie, tag, autor și dată. Cele mai multe sunt pagini subțiri, cu titluri și extrase care se repetă. Google le indexează, apoi le compară cu paginile principale și decide care e mai relevantă. Uneori decide invers decât ai vrea.
Rezultatul este canibalizare: două pagini de pe același site concurează pe aceeași căutare, iar Google nu știe pe care să o afișeze. Am văzut articole de blog bine scrise, îngropate sub o pagină de tag cu trei articole pe ea.
Deciziile diferă de la site la site. La un magazin, categoriile de produse sunt paginile pe care le vrei în Google, iar tag-urile de obicei nu. La un blog editorial, categoriile bine construite pot fi utile, iar tag-urile aproape niciodată. Setarea se face din plugin-ul SEO instalat: marchezi cu noindex ce nu vrei să apară. Nu bifa la întâmplare. Verifică în Search Console care dintre aceste pagini aduc trafic înainte să le scoți din index.
4. Sitemap-ul generat de două plugin-uri simultan
WordPress are, din versiunile recente, un sitemap propriu la /wp-sitemap.xml. Plugin-urile SEO generează propriul lor sitemap, de obicei la /sitemap_index.xml. Când amândouă sunt active și niciunul nu îl dezactivează pe celălalt, ai două sitemap-uri diferite pe același site, cu conținut parțial suprapus.
Google nu se blochează, dar primește semnale contradictorii despre ce pagini contează. Verificăm întotdeauna care sitemap e trimis în Search Console și dacă mai există unul care nu e trimis, dar e accesibil public. Ținem unul singur, cel din plugin-ul SEO, și dezactivăm sitemap-ul nativ din WordPress printr-un filtru sau printr-o opțiune din plugin.
5. Imagini încărcate direct din telefon, la dimensiuni uriașe
Cea mai comună problemă de viteză pe WordPress nu ține de hosting, ci de imagini. Cineva încarcă o fotografie de 4 MB direct din telefon, WordPress o afișează redimensionată în pagină, dar în realitate browserul descarcă fișierul complet. La zece imagini pe pagină, ajungi la 40 MB descărcați pentru o pagină de produs.
Efectul se vede în Core Web Vitals, în special la Largest Contentful Paint. Se vede și în PageSpeed Insights, la secțiunea de imagini. Dar cel mai clar se vede la clientul care se plânge că site-ul e lent pe telefon și nu înțelege de ce.
Ce facem: instalăm un plugin care comprimă și convertește imaginile în WebP la upload, redimensionăm manual imaginile deja încărcate care depășesc o anumită greutate și îl instruim pe cel care adaugă produse să nu urce niciodată direct din telefon. Ultimul pas e cel mai important și rămâne în sarcina clientului. Dacă nu îl face, ne întoarcem la aceeași problemă peste trei luni.
6. Plugin-uri de cache configurate agresiv, care sparg pagini
Plugin-urile de cache ajută viteza, dar au opțiuni care, activate fără atenție, strică lucruri vizibile. Minificarea JavaScript combinată cu concatenarea fișierelor sparge frecvent formulare, sliderele, coșul de cumpărături sau meniuri mobile. Utilizatorul vede o pagină care nu răspunde. Google vede o pagină care se încarcă rapid, dar are erori în consolă.
Regula noastră este simplă: activăm opțiunile de cache una câte una și verificăm site-ul după fiecare, pe desktop și pe mobil, în paginile care contează comercial. Când ceva se strică, ne întoarcem și dezactivăm exact opțiunea vinovată. Nu bifăm „optimizează tot” și ne rugăm să meargă.
7. Schimbarea temei fără curățenie
Când cineva schimbă tema WordPress fără să anunțe agenția, se strică lucruri pe care nu le controlăm. Tema veche adăuga schema.org în anumite locuri. Tema nouă o pune în alte locuri sau deloc. Tema veche avea breadcrumbs. Tema nouă are altă structură de breadcrumbs sau niciuna. Tema veche folosea alte etichete pentru H1 și H2. Tema nouă le rearanjează.
Vedem asta când raportul lunar arată o scădere bruscă la trei săptămâni după o dată pe care clientul nu ne-a menționat-o. Întrebăm ce s-a schimbat. Răspunsul e des: „am refăcut design-ul, dar conținutul e același”. Conținutul poate fi același. Structura HTML din spate nu este.
Ce cerem în colaborare: să fim anunțați înainte de orice schimbare de temă sau de dezvoltator care lucrează în cod. Nu ca să aprobăm noi, ci ca să facem o captură a stării tehnice de dinainte, cu care să comparăm după. Fără reperul ăsta, diagnosticul unei scăderi se face pe presupuneri.
8. Canonical-uri greșite pe magazine online
WooCommerce generează URL-uri diferite pentru același produs când adaugi filtre, sortări sau paginare. Fiecare variantă are un tag canonical care ar trebui să indice varianta principală. Când plugin-ul SEO și WooCommerce nu sunt sincronizate, canonical-ul indică fie pagina însăși, fie o pagină ștearsă, fie o categorie fără legătură.
Efectul nu e imediat vizibil. Google trimite paginile pe rând în raportul Indexare pagini din Search Console, la secțiunea „URL alternativ cu tag canonical corect” sau „URL declarat cu canonical, dar Google a ales altul”. A doua e cea care contează. Dacă apare, înseamnă că semnalele tale către Google nu sunt luate în serios.
Verificăm canonical-urile pe câteva pagini de fiecare tip: produs, categorie, pagină cu filtre active, rezultatele căutării interne. Reparăm din plugin-ul SEO și, unde nu se poate, printr-un fragment de cod în tema copil. La magazine mari, asta poate lua câteva zile de muncă în tăcere, fără nimic vizibil în rapoarte. Merită.
Ce nu rezolvă niciun plugin
Plugin-urile SEO pentru WordPress sunt bune. Yoast, Rank Math, SEOPress fac aceleași lucruri de bază decent. Diferența dintre ele e mai mică decât se scrie pe internet. Ce nu poate face niciunul este să decidă în locul tău ce pagini contează, cum se leagă între ele și ce răspunde la ce caută clientul tău. Scorul verde de la Yoast nu înseamnă că pagina e bine făcută. Înseamnă că are un titlu, o descriere și un keyword prezent de suficiente ori.
Auditul nostru automat, disponibil ca audit SEO gratuit, prinde majoritatea problemelor tehnice din lista de mai sus. Nu prinde canibalizarea între o categorie și un articol de blog, nu îți spune dacă structura de site are sens pentru business și nici dacă textul răspunde la ce caută clientul tău. Pentru asta, cineva trebuie să se uite manual la site, cu contextul de business în minte.
Ordinea în care le rezolvăm
Când preluăm un site WordPress cu probleme tehnice, nu le atacăm în ordinea în care le găsim. Le atacăm în ordinea impactului asupra indexării, apoi asupra vitezei, apoi asupra structurii.
Întâi verificăm dacă Google poate indexa site-ul: setarea de descurajare, robots.txt, canonical-urile, noindex-urile plasate din greșeală. Fără indexare, restul nu contează. Apoi ne uităm la ce se indexează și nu ar trebui, sau invers. Apoi la viteză și Core Web Vitals, pentru că afectează experiența reală, nu doar rapoartele. Abia la final la optimizare SEO on-page, structuri interne de linkuri, schema.org și restul.
Ordinea asta nu e regulă universală. E ordinea la care ajungem pentru că orice altă abordare produce muncă pe care o rescrii peste două luni.
Întrebări frecvente
Pot rezolva singur problemele astea, fără agenție?
Da, cele mai multe. Verificările din Setări – Citire, Setări – Legături permanente, sitemap-uri și noindex pe categorii sau tag-uri se fac din back-office. Ai nevoie de o oră de citit documentația plugin-ului tău SEO. Ce nu poți face singur, dacă nu ai lucrat pe site-uri, este să prioritizezi corect problemele și să eviți să strici ceva ce merge când repari altceva.
De ce nu e suficient să instalez Yoast sau Rank Math?
Plugin-ul SEO îți dă unelte, nu decizii. Îți permite să pui noindex, dar nu îți spune pe care pagini. Îți generează sitemap, dar nu îți spune care pagini merită să fie acolo. Îți semnalează titluri prea scurte, dar nu îți spune dacă titlul răspunde la ce caută clientul. Semaforul verde e o iluzie utilă, nu un verdict.
Cât durează să se vadă efectul după ce reparăm partea tehnică?
Depinde de ce ai reparat. O setare de descurajare debifată produce efecte în câteva zile, pe măsură ce Google reindexează. O curățenie de canibalizare produce efecte în câteva săptămâni. O restructurare majoră a site-ului se stabilizează în câteva luni. Primele rezultate vizibile într-o colaborare SEO apar de regulă în 3-6 luni, iar reparațiile tehnice sunt doar o parte din motive.



