Audit SEO: De Ce Este Important și Cum îl Facem Noi?

Cum procedăm & ce analizăm în agenţie pentru SEO tehnic

Scopul SEO este să crească traficul organic pe site.

Astăzi vorbim despre Auditul SEO care face parte din întregul proces de optimizare SEO, alături de:

1. keyword research
2. optimizarea structurii website-ului
3. link building

Care sunt acele tipuri de audit care se fac la noi în agenţie:

1. Audit SEO
2. Audit de Content Marketing
3. Audit de Profil de Linkuri

Auditul tehnic SEO se ocupă de toate elementele tehnice ale platformei. Sunt multe aspecte pe care noi le optimizăm şi le luăm în calcul, toate fiind strâns legate de factorii de ranking.

Înainte să trecem prin elementele tehnice, hai să vedem de ce se face un audit SEO, care sunt implicaţiile şi care sunt procedurile agenţiei pentru SEO tehnic.

Prima dată când am făcut un audit SEO complet, era anul 2011. Avea câteva zeci de pagini, mult conţinut, multe elemente SEO analizate, multe poveşti, multe explicaţii (de parcă ne doream să îi învățăm SEO pe clienţi). Eram foarte mândri de piesa de rezistenţă din SEO: AUDITUL, care era cerut la acea vreme.

Ne-a luat ceva timp să înţelegem că auditul SEO, acel document livrabil era inutil pentru client, pentru că niciodată nu se implementa mai nimic din el. Pe vremea respectivă documentul conținea aspecte de tipul:

• sunt 100 de titluri duplicate
• sunt 500 de titluri care depăşesc x caractere
• sunt 1000 de pagini care nu au canonical
• sunt 3 linkuri 404
• nu există sitemap sau robots

Ce se făcea la vremea respectivă era să aducem la suprafaţă problemele, însă fără soluţii clare, iar clienţii erau şi mai în ceaţă faţă de primele noastre întâlniri, pentru că nu ştiau ce au de făcut. Mai mult, acel document cu implementările tehnice trebuia să ajungă la developeri, care niciodată nu aveau timp să citească toate explicaţiile noastre de SEO. Nici măcar nu era treaba lor să facă acest lucru.

Nu ştim cum încă procedează alte agenţii sau alţi oameni de SEO, însă noi nu mai livrăm audit SEO pentru că:

• sunt prea multe informaţii tehnice inutile pentru client;
• sunt prea multe „poveşti” pentru programatori (care nu au nevoie să cunoască istoria SEO);
• sunt mult prea multe pagini care nu vin cu rezolvări concrete;
• durează mult timp să construim un astfel de audit (şi nu este răbdare);
• nu este productiv pentru nimeni.

Însă, dacă nu mai facem acest lucru, cum procedăm cu auditul SEO totuşi?

Nouă ne place foarte mult analiza tehnică şi tot ce ţine de tehnic, de platforme. Ne place să descoperim problemele SEO şi să le rezolvăm. Am înţeles de la început cât de importante sunt elementele tehnice din site dacă sunt făcute bine.

Am văzut în nenumărate cazuri creşterile aduse pe site-uri atunci când se rezolvă problemele tehnice. Acest lucru ţine foarte mult şi de tipul de site, de cât de mare/mic este. Cele mai mari beneficii şi creşteri de trafic se văd clar în cazul site-urilor mari (10k+ pagini), atunci când sunt optimizate.

Partea bună este că odată ce sunt implementate, ele rămân optimizate atât timp cât vor exista site-ul şi platforma. Acest lucru se datorează faptului că ne place să ne gândim pe termen lung la beneficii şi la ROI.

Modelul nostru de audit SEO intern este următorul:

La fiecare client nou, la fiecare site nou, facem auditul SEO la început, trecem prin elementele tehnice, pentru a vedea clar unde sunt toate problemele majore.

În funcţie de ce descoperim, prioritizam toate acele probleme pe care dacă le rezolvăm ştim că vor avea cel mai mare impact SEO în cel mai scurt timp. Revenim la scop, care este creşterea traficului organic.

Ce analizăm la început?

În primul rând, analizăm traficul organic din Google Analytics pe ultimii ani, pentru a vedea dacă sunt scăderi sau penalizări Google. Urmărind trendul de trafic şi comparaţiile de la an la an, ne putem da seama dacă s-a făcut SEO sau nu, dacă sunt mişcări în piaţă şi dacă trebuie să prioritizăm penalizările.

În al doilea rând, corelăm datele de trafic din Analytics cu datele din Google Search Console, unde putem vedea clar trendul pe ultimele 12-16 luni. Aici verificăm dacă există penalizări manuale sau dacă sunt alte probleme semnalate de Google.

Tot în Search Console analizăm raportul de Index Coverage pentru a vedea câte pagini sunt indexate, câte nu sunt indexate şi ne uităm la motivele pentru care acele pagini nu sunt indexate.

După ce verificăm acest aspect, analizăm ce există pe site. Folosim un crawler ca Screaming Frog, care ne arată tot ce avem nevoie să ştim din punct de vedere tehnic.

În acest fel, vom afla cu exactitate ce avem de optimizat şi în ce ordine. Modelul acesta este modelul Agile, prin care noi în agenţie ne asigurăm că pentru orice proiect rezolvăm problemele care au cel mai mare impact pentru traficul organic.

Pentru cei care sunt mai tehnici, hai să vedem care sunt elementele SEO tehnice pe care noi le audităm iar, apoi, le vom defalca pe rând.

1. Audit trafic organic
2. Audit penalizări (care sunt primele două lucruri la care ne uităm)

Audit SEO Tehnic: 

1. Crawl Budget
2. Duplicate Content
3. Indexabilitate
4. Mobile SEO
5. Analiza de Loguri de Server
6. Performance şi Load Time
7. HTTPS vs HTTP
8. JavaScript SEO
9. Robots.txt
10. Meta Robots / X Robots Tag
11. Canonicals
12. Title Tags
13. Meta Description Tags
14. Headings
15. URLs
16. Imagini
17. HTTP Status Codes (2xx, 3xx, 4xx, 5xx)
18. Sitemaps
19. Schema.org
20. 404 Page
21. Linkuri interne
22. Alte probleme sau erori (pentru că fiecare site are)

Înainte să le luăm pe fiecare în parte, insistăm pe importanța implementării recomandărilor agenției de SEO. Am putea probabil să scriem un articol întreg despre acest lucru. Este una dintre cele mai mari probleme de care noi ne lovim. Dacă nu sunt implementate configuraţiile de SEO, atunci sunt făcute degeaba, pentru că nu ajută la nimic. Ele vor rămâne un document agăţat într-un email sau într-un ticket la dev.

Atunci când faci SEO, programatorii sunt automat implicaţi, pentru că este necesar ca implementările să fie făcute. Doar aşa Google poate vedea noile directive, pe care să le ia în calcul pentru crawling, indexare şi ranking.

Avem cazuri când aşteptăm şi peste 6 luni ca recomandările noastre să fie implementate, iar în aceste cazuri, businessul este afectat, pentru că traficul organic nu creşte. Din nou, insistăm pe implementarea lor, pentru că sunt importante.

Acum vom lua fiecare element în parte şi vom vorbi despre el.

Optimizare Crawl Budget

Bugetul de Crawl este cel mai important aspect de optimizare când vorbim despre site-urile foarte mari. Fiecare platformă are anumite configurări, legate de cum îşi construieşte navigaţia şi URL-urile. Multe platforme au acea problemă numită Infinite Spaces, prin care Google poate crawla site-ul la infinit.

În cazul site-urilor mici (zeci, sute de pagini) nu este neapărat cazul să îţi faci probleme pentru bugetul de crawl, însă, atunci când ai foarte multe pagini, este cazul să fie optimizat.

De ce?

Gândeşte-te în felul următor: magazinul tău online are 300 de categorii / subcategorii şi 15.000 de produse. Fiecare categorie are câte 10 secţiuni de filtre a câte 10 filtre unice fiecare. Orice categorie poate avea filtre care se combină la infinit.

Exemplu de la Cellini:

cellini.ro/ceasuri/filtre/marci-premium-breitling/marci-premium-carl-f-bucherer/marci-premium-iwc-schaffhausen/marci-premium-longines/tip-mecanism-automatic/swiss-made-da/model-barbati/model-femei/model-unisex/tip-display-analog/material-geam-cristal-safir/forma-carcasa-rotunda/culoare-carcasa-argintiu/culoare-carcasa-auriu/material-carcasa-otel-inoxidabil/tip-curea-bratara-bratara/rezistenta-apa-3-atm/garantie-2-ani/promo-promotii/stoc-da

Aceste tipuri de URL-uri pot fi crawlate de Google. Sunt peste 10 LVL de depth în URL, pentru că am selectat aproape toate filtrele din acea categorie.

Acum, tu ai pe site categoriile şi produsele pe care le vrei indexate, însă, din cauza faptului că bugetul de crawl nu este optimizat, Google, în loc să crawleze şi să indexeze paginile „curate”, va aloca resurse pentru pagini ca cea de mai sus.

Cel mai simplu se vede acest lucru în raportul de Index Coverage din Google Search Console:

În acest caz, avem 20.500 de pagini indexate şi excluse peste 6.42M. Sunt atât de multe excluse pentru că la acest client avem infinite spaces.

Dacă mergem mai departe, la raportul de pagini excluse, putem vedea care sunt motivele pentru care acele pagini nu sunt în index:

Chiar dacă nu îţi poţi da seama de probleme din acest raport, îţi spunem noi că Google se duce mereu fix acolo unde nu vrem să se ducă. Aproape 3M de pagini au noindex, pentru că noi am setat noindex.

În cazul unui astfel de site, primul lucru pe care îl optimizăm este clar bugetul de crawl, pentru că ne dorim ca site-ul să fie indexat corect şi cât mai repede.

Mai jos este un exemplu de creştere a traficului organic din 2019, după ce am făcut optimizări de buget de crawl. Creşterile din luna 2 au depășit 30% şi vorbim de peste 1M useri anual în zona organică.

Duplicate Content

Duplicate content nu este ce crezi tu că este :). În general, când vorbim de duplicate content, ne gândim la conţinutul preluat de pe alte site-uri. Pentru ecommerce este aproape imposibil să ai conţinut 100% unic, pentru că descrierea de produs este asemănătoare, dacă nu chiar identică, indiferent de magazinul care comercializează un anumit produs. Descrierile vin de la producător şi, în general, nu ai ce să modifici, în special la detaliile tehnice.

Chiar şi aşa, se pot face îmbunătățiri la descrierea de produs, să nu ai tot conţinutul copiat de la producător. Se pot lua, de exemplu, top produse vândute şi se poate dezvolta conţinut pentru ele. Un exemplu frumos am văzut la Dedeman:

Am intrat pe site la Dedeman şi am luat random un produs „boring”, despre care nu ai ce să scrii, dar chiar şi aşa, în text s-a descris produsul. S-a construit un mic text în funcţie de imaginea produsului şi de detaliile tehnice.

În exemplul de mai jos este: https://www.dedeman.ro/ro/coltar-living-extensibil-pe-stanga-roxana-cu-lada-negru-gri-235-x-151-x-85-cm-3c/p/8027154, unde se descrie efectiv cum este produsul.

Să revenim la duplicate content. Conţinutul duplicat apare de la următoarele lucruri:

• Filtre
• Sortări
• URL-uri separate pentru acelaşi produs

Google spune clar că nu penalizează site-urile pentru conţinutul duplicat intern, însă […] ce se întâmplă de fapt este că Google poate crawla acele pagini şi nu mai indexează paginile curate. În acest fel, atât indexarea, cât şi rankingul şi traficul organic sunt afectate de conţinutul duplicat.

Hai să luăm câteva exemple de astfel de pagini de la un site fictiv:

site.ro/categorie/filtru-culoare/filtru-pret/filtru-caracteristica/

site.ro/categorie/?sort_orderby=price-low_to_high

site.ro/product/nume-produs/

vs

site.ro/collection/category/subcategory/nume-produs/

Aceste tipuri de pagini generează ceea ce noi numim duplicate content. Tot aceste tipuri de pagini generează probleme de crawl budget. Ele trebuie tratate ca atare, pentru a le rezolva.

Indexabilitate

Aceasta include mai multe aspecte. Pentru indexabilitate avem de luat în calcul robots.txt, meta robots, canonicals, sitemaps şi crawl budget. Indexabilitatea este importantă, pentru că trebuie să ştii cât de bine este site-ul tău indexat sau nu. Aici revenim la raportul de indexabilitate din GSC.

Trebuie să ştii câte pagini ai în site vs câte sunt indexate.

Mobile SEO

Din 2019, 1 Iulie, Google a introdus Mobile First Indexing. Ce înseamnă acest lucru? Google crawlează şi indexează prima dată versiunea de Mobile, nu pe cea de Desktop.

Cu alte cuvinte, Google alocă mai multe resurse de crawling cu botul de Mobile. Acest lucru se poate verifica în GSC la Crawl Stats.

Din totalul de crawl requests, 37% au venit de pe Mobile şi 28% de pe Desktop. Vei vedea aceste lucruri în raportul din Google Search Console. Chiar dacă Google alocă resurse şi pe Desktop, indexarea se face tot pe Mobile.

În zilele noastre, aproape toate layout-urile / template-urile sunt destul de bine optimizate pentru mobile. Cea mai comună tehnologie folosită este cea de Responsive Design. În general, pentru Mobile nu sunt probleme şi site-urile răspund bine, însă avem acele cazuri când există probleme mari.

Probleme pentru Mobile SEO:

• Conţinut diferit pe mobil vs desktop – întotdeauna conţinutul trebuie să fie la fel atât pe mobil, cât şi pe desktop;
• Fonturi prea mici – Google recomandă fontul de minimum 16px pentru text. Noi suntem fani fonturi mai mari (de la 17-18px), pentru a vedea textul mai clar;
• Prea mult JavaScript – Google are probleme la indexarea JS;
• Elemente / butoane prea apropiate;
• Optimizări doar pentru anumite device-uri;
• Conţinut mai mare decât display-ul;
• Load time prea mare pe mobil;
• Google vede site-ul ca nevalid pe mobile, însă el funcţionează bine pe live test sau invers.

Pentru acest lucru, există la Page Experience în Google Search Console un raport de Mobile Usability în care Google afişează ce probleme a descoperit pe Mobile.

Atunci când se efectuează teste, o greșeală comună pe care am văzut-o este că se testează doar HomePage-ul pe Mobile Test de la Google.

Trebuie testate mai multe tipuri de pagini, în special cele pe care GSC le raportează cu erori. Câteodată poate fi dificil să replici eroarea pe care Botul o semnalează.

Google nu poate deschide site-ul tău pe iPhone :), ci el va emula comportamentul de iPhone cu un Browser, care este user agentul de Mobile (Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html))

Pentru mobile SEO, testele sunt cele mai importante.

Analiza Logurilor de Server

Aici intervine zona de SEO avansat. Logurile de server oferă cea mai clară viziune asupra a ce vede, ce crawlează şi ce indexează Google pe site-ul tău. Sunt necesare, pentru că poţi face multe optimizări pentru bugetul de crawl şi SEO.

De exemplu, ai nevoie să ştii ce crawlează Google vs ce indexează Google, pentru că sunt două lucruri total diferite. Mai mult decât atât, poţi vedea dacă ai probleme în site, comasând datele live din site vs datele din loguri.

În loguri poţi vedea exact care sunt erorile pe care Google le întâmpină la tine în site, care sunt user agenţii care îţi accesează cel mai mult site-ul, care sunt http status codes, care sunt acele mixed status codes (de exemplu: un URL poate răspunde cu 200, însă la accesările boților a răspuns cu 5xx).

Poţi optimiza mai bine structura internă a site-ului pentru că poţi vedea unde ai cele mai multe accesări. Aici sunt multe de discutat, însă logurile de server îţi oferă o claritate sporită asupra a ce face Google pe site-ul tău.

Nu există un alt instrument care să poată face acest lucru. Problema pe care o întâmpinăm noi cu logurile este că sunt mai greu de primit, mai ales din partea SaaS-urilor. De exemplu, la Shopify nu putem avea logurile de server. În exemplul de mai jos avem puţine hituri, pentru că sunt logurile pe câteva ore. Însă, în general, avem sute de mii de hituri în loguri şi putem vedea mult mai clar pe 30 de zile ce se întâmplă.

Performance și Load Time

Timpul de încărcare este un factor de ranking pentru SEO, însă el este important şi pentru conversii. Cu cât site-ul se încarcă mai repede, cu atât el converteşte mai bine. Nimeni nu vrea să aştepte minute în şir să se încarce un site sau să plaseze o comandă.

Acum, pentru timpii de încărcare şi Performance sunt mai multe lucruri de luat în considerare.

De exemplu, Load Time raportat în Google Analytics este un timp mediu de load calculat pe un sample de pagini pe toate dispozitivele, browserele, device-urile, conexiunile etc. Cât ar trebui să fie acest timp mediu?

Cel mai bun timp de încărcare pe care noi l-am văzut în Ecommerce-ul românesc, este de 1.74s. Da, 1.74s se poate pe un site de ecommerce, care are listate câteva milioane de produse şi care are aproximativ 70.000 de sesiuni lunar. Cel mai bun timp a fost în august cu 1.3s.

Cel mai mare load time constant pe care l-am văzut în ecommerce-ul românesc este de peste 8 secunde.

Ca un rule of thumb, acest Avg Page Load Time din Analytics ar trebui să fie sub 3s pentru ecommerce.

Bineînţeles că apoi trebuie să te uiţi pe ce browsere şi pe ce sisteme de operare sunt cei mai mari timpi de încărcare, raportat şi la numărul de useri / sesiuni.

De exemplu, dacă 60% din useri îţi vin pe Chrome, iar pe Chrome load time este de 5s, înseamnă că trebuie să îmbunătăţeşti timpii pe Chrome. Degeaba pe IE ai load time de 2 secunde, dacă pe IE vin doar 1% din useri.

Performance Report

Raportul de performance se face de către Google cu Lighthouse, pe care este bazat şi PageSpeed Insights.

În raportul de mai jos, avem homepage-ul de la site-ul care în medie are load time sub 2s, unde s-au investit peste 6 luni de programare pentru a fi optimizaţi metricii de la Google şi, chiar şi aşa, TTI tot apare ca 7.5s.

În acest raport sunt câţiva metrici la care Google se uită în mod special, pe care îi numeşte Core Web Vitals. Cei mai importanţi sunt aceştia:

1. LCP (Largest Contenful Paint)

• Măsoară performanţa în termeni de Load, de când pagina începe să se încarce, până când cea mai mare porţiune de text/imagine(i) este afişată pe ecran.
• Google recomandă ca LCP să fie <2.5s.

FID (First Input Delay)

• Măsoară interactivitatea cu pagina. Măsoară timpul de când un user face o acţiune (click, tap, scroll etc.) până când browserul poate să răspundă la acea interacţiune.
• Google recomandă ca FID să fie <100ms.

CLS (Cumulative Layout Shift)

• Măsoară stabilitatea vizuală. Calculează un scor pentru stabilitatea vizuală, adică acel scor prin care userii experimentează schimbări neaşteptate (butoane care nu merg, texte, elemente web care îşi schimbă poziţia etc). Google recomandă ca CLS să fie sub 0.1.

Din experienţa noastră, optimizarea vitezei de încărcare este cel mai greu de făcut, pentru că Google are anumite cerinţe, programatorii au altele. În acelaşi timp, aceşti metrici de la Google cer anumite lucruri care trebuie schimbate în platforme.

Când vorbim de SaaS-uri, ele sunt foarte greu de schimbat. Hai să luăm exemplu DOM-ul (Document Object Model). DOM-ul creşte cu fiecare element HTML, iar la Load Time, Browserul creează DOM-ul paginii.

Cu cât sunt mai multe elemente în DOM, cu atât Load Time creşte, însă în cazul SaaS-urilor sau a template-urilor cumpărate, este complicat de modificat structura. De multe ori, este mai simplu să faci ceva de la 0 decât să reoptimizezi un template.

Având în vedere dificultatea şi implicaţiile tehnice, o agenţie de SEO nu trebuie să ştie cum să se facă programarea, ci ea poate să semnaleze aceste probleme şi dev-ul să găsească soluţii de rezolvare a lor. Din experienţa noastră, dev-ul vine rar cu soluţii.

Pentru a vedea cum performează site-ul tău în ochii lui Google, poţi merge la raportul de Core Web Vitals din Search Console. În cazul de mai jos, atât pe Mobile, cât şi pe Desktop avem 152 de Good URLs şi 0 Poor sau care au nevoie de îmbunătăţiri.

HTTP vs HTTPS

HTTPS este factor de ranking, iar site-ul trebuie să aibă un certificat SSL Valid. Acest lucru se verifică uşor în Chrome.

Alte probleme de la HTTP:

• resurse interne ca CSS, JS, imagini etc. se încarcă pe HTTP;
• în site sunt multe linkuri interne care sunt pe HTTP;
• nu se verifică clar toate redirecturile + canonicals între HTTP, HTTP WWW şi HTTPS;
• versiunea de https face 301 spre http.

JavaScript SEO

În ultima vreme, ne-am tot întâlnit cu această problemă, care apare în special la SaaS-uri ca Shopify şi de la template-urile de layout pentru Ecommerce.

JavaScriptul în sine nu este o problemă, fiind folosit la tot ce înseamnă Web. În schimb, Google, pentru a indexa conţinutul prin JS, are nevoie să facă mai multe acţiuni şi să aloce alte resurse, care sunt limitate.

Tu vrei ca site-ul tău să fie indexat, însă pentru acest lucru trebuie să îi facem viaţa uşoară şi lui Google. Pentru a-i fi posibil motorului de căutare să indexeze JS-ul are nevoie să crawleze site-ul, să găsească fişierele JS, să le trimită la randare (este practic un browser care emulează pagina) şi abia apoi să le trimită la indexare.

Google e fan conţinut HTML pe care îl crawlează şi indexează repede. Însă, pentru JS are nevoie de multe resurse de randare pentru a putea înţelege paginile web.

Pe scurt, cu cât ai mai mult JS pe site, iar conţinutul magazinului online este dinamic, cu atât site-ul tău va fi indexat mai greu şi traficul nu va creşte. După cum vezi mai sus, este o schemă complicată de indexare / randare şi alţi termeni complicaţi de SEO :).

Mai jos este un exemplu de cum arată site-ul christiantour.ro cu JS dezactivat din Browser. Nu apare nimic.

Mai jos este ce există în HTML:

După cum se vede, nu există conţinut static, nu există nimic de care Google se poate „agăţa” pentru a indexa rapid aceste pagini. Tot conţinutul site-ului este dinamic, nu apare nimic static.

Noi, ca agenţie, trebuie să ne asigurăm că Google indexează site-ul şi trebuie să venim cu soluţii pentru aceste tipuri de probleme, pentru că linkurile şi alte optimizări nu ajută atât de mult dacă nu există conţinut indexabil.

Fisierul robots.txt

Fişierul robots.txt (care este case sensitive) este acel prim fişier pe care Google îl cere atunci când îţi crawlează site-ul. În cazul site-urilor mici, o configuraţie simplă cum era la site-ul moloso.ro este suficientă:

Google trebuie să ştie ce şi ce să nu crawleze pe site şi, de aceea, este nevoie de un astfel de fişier. Este important pentru că poţi bloca boţii să acceseze anumite secţiuni din site sau anumite tipuri de pagini.

În acelaşi timp, dacă nu se configurează cum trebuie, poţi să ai probleme mari de indexare. Noi folosim robots.txt pentru a optimiza Bugetul de Crawl, însă configuraţiile făcute sunt mereu la nivel de platformă, fiind diferite şi separate pentru fiecare în parte.

Uite un exemplu de fişier „complicat” pe Shopify care blochează parametri, sortări şi alte tipuri de pagini care nu trebuie să apară în Google Search.

Meta Robots / X Robots Tag

Pentru SEO, suntem mari fani Meta Robots. Ca directive, sunt printre cele mai importante pentru Google şi sunt luate în calcul repede.

Bugetul de crawl se optimizează cel mai bine cu meta robots şi robots.txt.

Ce directive sunt cel mai des folosite:

• noindex
• follow
• nofollow

Noi folosim configuraţia de noindex, nofollow pe toate acele pagini junk, care sunt inutile pentru indexare. Însă, pentru a le identifica, este nevoie de multe analize, unde trebuie să luăm în calcul:

• traficul pe acele pagini;
• linkurile externe pe acele pagini;
• configuraţiile actuale;
• pageviews;
• utilitatea lor în search;
• intenţia de căutare;
• canonicals.

Meta Robots merge mâna în mână cu Robots.txt.

Însă, dacă setezi noindex în meta robots, ai în vedere să nu blochezi din Robots.txt accesul la acele pagini, pentru că Google nu va citi directiva de noindex şi vei rămâne în continuare cu problemele de crawl budget.

Noindex trebuie foarte bine testat şi setat, pentru că se poate pierde trafic mult dacă nu este folosit corect.

Canonical Tag

Multă vreme am numit canonical tag a 7-a minune SEO, însă, în ultimii ani, analizând logurile de server, am realizat că nu funcţionează corect, mai ales în cazul site-urilor foarte mari. Canonical pentru Google este un hint, nu o directivă clară.

Canonical funcţionează bine doar în cazul în care conţinutul a două pagini este foarte similar şi gradul de duplicare este mare. Însă, dacă ai infinite spaces de exemplu, canonical tag nu este util.

Dacă îl laşi pe Google să îţi trateze paginile duplicate după cum vrea el, nu va face o treabă bună deloc. Am văzut cazuri în care Google raportează ca duplicate două pagini de produs total diferite. Singurul lucru comun între ele era reprezentat de câteva cuvinte din URL.

Tagul este destul de bun pentru parametri şi UTM-uri.

Când vorbim de site-uri enterprise, pentru a ne asigura că optimizam bugetul de crawl, trebuie făcute, de la caz la caz, combinaţii între canonical, noindex şi robots.txt.

La fel ca în cazul noindex, canonical tag trebuie testat foarte bine, pentru că şi în acest caz, dacă nu este implementat corect (cum se întâmplă mai des decât ne-am dori) putem avea probleme mari.

Hai să luăm un exemplu în cazul unei migrări, în care sunt implicate redirect and canonical chains, care sunt foarte dăunătoare pentru crawling, indexare şi traficul organic.

Avem URL vechi:

https://site.ro/categorie/ care trebuie să facă 301 redirect spre https://site.ro/nume-nou-categorie/

După implementarea migrării avem aşa:

https://site.ro/categorie/ face 301 spre https://www.site.ro/categorie/ care face 301 spre https://www.site.ro/nume-nou-categorie/ care are setat canonical spre https://www.site.ro/nume-nou-categorie (fără / la final).

În acest caz avem redirect & canonical chain, iar pentru o migrare poţi pierde mult trafic organic, pentru că Google nu poate merge lin prin toate aceste redirecturi şi are nevoie de mult prea multe resurse să indexeze site-ul corect.

Am mai văzut cazuri în care toate URL-urile de produs şi linkurile interne din site sunt într-un fel, iar ele au setat canonical spre alt URL. Shopify face acest lucru, de exemplu.

Toate URL-urile de produs din site au forma /collection/category/product-name/ care au setat canonical spre /products/product-name/. În acest caz, Google va indexa mult mai greu varianta finală, pentru că nu primeşte linkuri interne şi pentru că va ajunge greu la ele. După cum spuneam, canonical este hint, nu directivă clară.

Title Tags, Meta Description, URLs și Headings

Le-am adăugat pe toate în această secţiune, pentru că sunt meta taguri (mai puţin URL-urile) şi sunt cele mai importante elemente de onpage, unde să mapăm cuvintele cheie.

Toate trebuie să fie unice, la nivel de landing page, şi să fie relevante pentru conţinutul paginii.

• Titlurile trebuie să fie până la maximum 60 de caractere pentru a fi afişate complet în Google Search.

• Meta Descrierile trebuie să fie până la maximum 155 de caractere pentru a fi afişate complet în Google Search.

Noi, în agenţie, mapăm cuvintele cheie în aceste elemente SEO, doar după ce avem finalizată strategia de Keyword Research.

Pentru relevanță şi pentru trafic, optimizăm atât cuvinte head terms, cât şi long tail, pentru a ne asigura că maximizăm traficul organic.

Trebuie luat în calcul faptul că meta tagurile pe Mobile se afişează diferit faţă de Desktop şi, pe anumite căutări, Google poate afişa mai multe caractere pe Mobile decât pe Desktop.

URL-urile sunt importante, pentru că ele sunt adresele la care ajung userii şi boţii, pentru a face anumite acţiuni pe site. Problemele de indexare şi crawling apar în general de la URL-uri, pentru că nu sunt făcute corect.

Cea mai bună structură de URL-uri este cea pe foldere:

site.ro/categorie/

site.ro/categorie/subcategorie/

site.ro/produs/

Ce greşeli comune am văzut la URL-uri:

• prea mulţi parametri;
• lipsa unei versiuni canonice cu / la final sau fără / la final;
• diacritice în URL-uri (mai ales la SaaS-uri);
• URL-uri prea lungi;
• URL-uri encodate non ASCII;
• URL-uri cu (_) underscore în loc de –;
• prea multe cuvinte de legătură.

Așa arată rezultatele pe Desktop:

Aşa arată rezultatele pe Mobile:

Pe mobile se văd clar imaginile, iar la Mindblower, Google alege pe mobile să afişeze şi brandul la final, pe când pe Desktop nu o face.

Google spune că îşi ia libertatea să schimbe atât Titlul paginii, cât şi Meta Descrierea în funcţie de căutarea făcută. Acest lucru pe noi ca agenţie de SEO nu ne avantajează, pentru că optimizăm aceste elemente pentru:

• CTR
• Sales
• Relevanță
• Cuvintele cheie

Cea mai bună metodă de a ne asigura că meta tagurile performează, este să facem A / B teste pe ele, în care să testăm diferite variante şi cuvinte şi să vedem clar unde creşte CTR-ul.

La analiza meta tagurilor analizăm următoarele:

• existența lor;
• cuvintele cheie optimizate;
• duplicările;
• afişarea lor în căutări;
• numărul de caractere.

Cele mai comune greşeli pe care le-am întâlnit:

• lipsa meta tagurilor;
• lipsa cuvintelor cheie relevante;
• lipsa CTA în meta descriere;
• duplicări prea multe.

Imagini

Imaginile sunt importante pentru useri, pentru sales. Noi, în agenţie, nu insistăm pe imagini, pentru că vine puţin trafic din Google Images.

La imagini ne asigurăm de următoarele lucruri:

• că au dimensiuni potrivite (am văzut imagini de produs de 15mb);
• că au alt text setat pentru produse.

Pe site există multe bannere sau imagini mici, iconiţe unde nu insistăm să adăugăm alt text, pentru că nu ajută.

HTTP Status Codes (2xx, 3xx, 4xx, 5xx)

Pentru ca site-ul să funcţioneze corect, să fie indexabil şi să poată ranka, are nevoie ca toate paginile să răspundă cu 200. Acest lucru înseamnă că pagina este live.

Web-ul este atât de dinamic, ecommerce-ul la fel, încât este aproape imposibil să nu existe şi alte erori, ca 404, 410, 502, 503, 302 şi altele. În general, erorile 3xx şi 4xx interne în site sunt dăunătoare şi trebuie rezolvate.

Ele apar pentru că paginile se schimbă, poate se şterg din greşeală, apar alte categorii, produsele din site dispar definitiv din stoc etc.

Erorile de 5xx ţin de server şi trebuie să te asiguri că serverul este bun, poate ţine mult trafic pe site şi face faţă cu brio la crawlingul boților.

Cum le verificăm? În site le verificăm prin crawling şi, în funcţie de eroare, le rezolvăm dinamic sau manual. În general, 404 şi 301 se rezolvă manual.

Apoi, trebuie să verificăm în GSC la crawl stats ce se întâmplă cu boţii când ajung pe site. De exemplu, dacă serverul răspunde la boţi cu prea mult 5xx sau 4xx, acest lucru înseamnă că Google nu îţi va mai crawla site-ul şi implicit indexarea va avea de suferit.

Apoi, trebuie verificate şi logurile pentru a vedea exact care sunt acele pagini care nu răspund corect. Sunt semnalate la dev şi ei ştiu apoi ce au de făcut.

Sitemaps

Sitemapurile sunt utile, pentru că îl ajută pe Google să ştie despre paginile din site-ul tău. Dacă setezi sitemapurile, nu înseamnă că site-ul va fi şi indexat. Pentru Google, un sitemap este ca un roadmap, prin care el descoperă mai repede paginile tale şi le poate prioritiza pentru crawling.

În cazul site-urilor mari, noi facem un sitemap index, care include mai multe sitemapuri:

• sitemap de categorii
• sitemap de produse
• sitemap de imagini

Sitemapurile trebuie adăugate în Google Search Console şi sunt utile pentru că poţi verifica gradul de indexare al site-ului tău la nivel de sitemap.

După cum se vede mai jos, pe sitemapul de produse, avem indexate 1.340 de produse, însă alte 382 încă nu sunt indexate. Putem observa mai jos ce a făcut Google.

Într-un sitemap pot intra până la 50.000 de URL-uri. Așadar, dacă există multe produse în site, noi recomandăm pentru produse să facem sitemapuri de câte 10.000 de produse.

Schema.org

Pentru cine nu ştie ce este Schema, de obicei, toţi o asociază cu steluţele de rating din Search. Însă, nu este doar atât, ce este acolo este doar ce se vede la suprafaţă.

Schema este importantă pentru Google pentru că, folosind microdatele, el „înţelege şi ştie” aproape la fel ca un om despre ce este site-ul tău. Cele mai importante tipuri de schemă pentru Ecommerce sunt:

• Breadcrumbs
• Product
• Organization/LocalBusiness
• Review
• Logo
• AggregateRating

Este nevoie de Schemă pentru ecommerce, pentru că Google foloseşte acele informaţii şi pentru Google Shopping. Există rapoarte separate în GSC pentru această zonă.

Cu Schema.org este mai dificil în anumite cazuri, pentru că sunt multe lucruri de pus la punct şi trebuie setată corect. Ce se întâmplă de multe ori este că setările merg bine pentru o parte din produse, dar pentru altele nu.

Sunt multe câmpuri necesare de completat şi multe date care merită să fie adăugate. Este nevoie de o înţelegere clară a acesteia şi a modului în care funcţionează. Partea bună este că ne ajută şi Google cu rapoartele din GSC şi putem îmbunătăţi unde apar probleme.

În GSC întotdeauna vei vedea acele warnings, care apar de la câmpurile care nu sunt obligatorii. De exemplu, nu toate produsele tale vor avea review-uri şi Google le raportează ca warnings. Este important să fie toate celelalte câmpuri valide.

Schema trebuie testată cu https://search.google.com/test/rich-results pentru a ne asigura că tipurile de Schema sunt bine făcute. În acest caz, avem mai multe tipuri setate care funcţionează corect, chiar dacă există un Warning.

Este important să nu avem Erori.

Pagina 404

• Pagina 404 trebuie să răspundă cu 404. Cea mai mare greşeală pe care am văzut-o a fost ca pagina 404 să răspundă cu 200.
• Pagina 404 trebuie să fie creativă şi să conţină linkuri interne spre alte pagini utile din site.

Mai jos avem un exemplu de 404 făcut bine şi creativ de la Travel Matters. Pe fundal este un video cu 4 tineri care sunt pe o plajă exotică. În pagină este un CTA mare pentru HomePage.

Linkuri interne

Linkurile interne sunt importante pentru crawling, indexare şi ranking. Structura internă de categorii trebuie să fie făcută doar după research-ul de cuvinte cheie. Fiecare cuvânt ales va determina cum va ranka pagina.

Categoriile şi subcategoriile trebuie să aibă ancore interne pe cuvintele cheie cu volumele cele mai mari de căutări, iar linkurile spre produse trebuie să fie pe long tail.

Structura de categorii determină relevanța paginilor, mai ales atunci când este făcută pe silozuri.

Linkurile interne trebuie să fie prezente în HTML pentru a putea fi citite de Google.

Greşeli comune:

• meniul principal este făcut prin JS şi Google nu citeşte corect toate linkurile interne;
• ancorele interne nu sunt exact match;
• nu se folosesc breadcrumbs;
• linkurile interne spre produse nu sunt prioritizate în funcţie de anumiţi algoritmi (cum ar fi să linkezi top sales);
• în categorii nu sunt linkuite top produse vândute (şi sunt afişate produse fără stoc);
• nu există relevanță între linkurile interne;
• structura de categorii nu e relevantă;
• crawl depth este prea mare (există prea multe linkuri interne pe lvl 4-5-6-10).

Cu cât se ajunge prin mai multe click-uri la o pagină, cu atât acea pagină va fi indexată mai greu.

Acel „sweet spot” este la maximum 3 click-uri de pe HomePage, pentru a ajunge la produse.

În acest caz, după cum se vede, pe lvl 4-9 sunt prea multe pagini. Aici trebuie redus numărul de linkuri şi îmbunătăţită structura.

În GSC există un raport de linkuri interne şi, aici, prima pagină cea mai linkuită din site trebuie să fie HomePage-ul. De obicei, paginile de /contact/, /policy, /privacy vor apărea mereu în top. Nu este nimic de făcut, ci trebuie verificat dacă categoriile primesc îndeajuns de multe linkuri interne.

Alte probleme de SEO

Pentru că web-ul este atât de vast şi există multe platforme şi mai multe tehnologii, fiecare site are parte de problemele lui unice, pentru care este nevoie de multe analize pentru a fi descoperite.

În anumite cazuri, probleme noi apar şi pe parcurs, de la update-uri sau de la alte modificări. Trebuie luat în calcul şi acest lucru, pentru că de fiecare dată noi întâmpinăm şi descoperim probleme şi după audit.

Nouă ne place să le căutăm și să le rezolvăm, pentru că se aduce multă plus valoare pentru business.

Ce tool-uri folosim în agenţie?

1. Screaming Frog
2. Screaming Frog Log Analyzer
3. CognitiveSEO
4. aHrefs
5. Google Search Console
6. Google Analytics
7. Google Tools

La suprafață, SEO poate părea simplu, însă este complex după cum vezi. Trebuie să ştii unde să te uiţi, cum să te uiţi şi cum să tratezi fiecare aspect în parte în funcţie de business şi de site. Sunt multe elemente care merg mână în mână şi este necesar să fie cunoscute bine.

Acum gândeşte-te cum ar fi să primeşti un document în care rezolvăm toate aceste probleme? 🙂

Noi în agenţie punem mult accent pe soluţii şi, de fiecare dată, venim cu rezolvarea optimă pentru fiecare problemă în parte. Chiar şi aşa, sunt cazuri în care aşteptăm mult implementarea soluţiilor oferite.

SEO este şi foarte tehnic în acelaşi timp, iar o platformă defectuoasă nu îţi va susţine creşterea businessului. Este cazul şi poate timpul să iei în calcul şi optimizarea tehnică a platformei.

În final, te lăsăm și cu un scurt studiu de caz:

Sursa imagine.