Marketing Online SEO

Audit SEO: De Ce Este Important si Cum il Facem Noi?

Cum procedam & ce analizam in agentie pentru SEO tehnic

Scopul SEO este sa creasca traficul organic pe site.

Astazi vorbim despre Auditul SEO care face parte din intregul proces de optimizare SEO, alaturi de:

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

Care sunt acele tipuri de audit care se fac la noi in agentie:

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

Auditul tehnic SEO se ocupa de toate elementele tehnice ale platformei. Sunt multe aspecte pe care noi le optimizam si le luam in calcul si toate sunt strans legate de factorii de ranking.

Inainte sa trecem prin elementele tehnice, hai sa vedem de ce sa facem un audit SEO sau nu, care sunt implicatiile si care sunt procedurile agentiei Moloso pentru SEO tehnic.

Imi aduc aminte prima data cand am facut un audit SEO complet, prin 2011. Avea cateva zeci de pagini, mult continut, multe elemente SEO analizate, multe povesti, multe explicatii (de parca imi doream sa ii invat SEO pe clienti :)). Eram foarte mandru de piesa de rezistenta din SEO: AUDITUL, care era cerut la acea vreme.

Mi-a luat ceva timp sa inteleg ca auditul SEO, acel document livrabil era inutil pentru client, pentru ca niciodata nu se implementa nimic din el.

Pe vremea respectiva erau recomandari ca:

  • sunt 100 de titluri duplicate
  • sunt 500 de titluri care depasesc x caractere
  • sunt 1000 de pagini care nu au canonical
  • sunt 3 linkuri 404
  • nu exista sitemap sau robots

Ce se facea la vremea respectiva era sa aducem la suprafata problemele, insa fara solutii clare, iar clientii erau si mai in ceata fata de la inceput, pentru ca nu stiau ce au de facut. Mai mult, acel document cu implementarile tehnice trebuia sa ajunga la developeri, care niciodata nu aveau timp sa citeasca toate explicatiile noastre de SEO. Nici macar nu era treaba lor sa faca acest lucru.

Nu stim cum inca procedeaza alte agentii sau alti oameni de SEO, insa noi nu mai livram audit SEO pentru ca:

  • sunt prea multe informatii tehnice inutile pentru client
  • sunt prea multe “povesti” pentru programatori (care nu au nevoie sa cunoasca istoria SEO)
  • sunt mult prea multe pagini care nu vin cu rezolvari concrete
  • dureaza mult timp sa construim un astfel de audit (si nu este rabdare)
  • nu este productiv pentru nimeni

Insa daca nu mai facem acest lucru, cum procedam cum auditul SEO totusi? 

Mie imi place foarte mult analiza tehnica si tot ce tine de tehnic, de platforme. Imi place sa descopar problemele SEO si sa le rezolv. Am inteles de la inceput cat de importante sunt elementele tehnice din site daca sunt facute bine.

Am vazut in nenumarate cazuri cresterile aduse pe site-uri atunci cand se rezolva problemele tehnice. Aici tine foarte mult si de tipul de site, de cat de mare/mic este. Cele mai mari beneficii si cresteri de trafic se vad clar in cazul site-urilor mari (10k+ pagini), atunci cand sunt optimizate.

Partea buna este ca odata ce sunt implementate, ele raman optimizate atat timp cat vor exista site-ul si platforma. Asta pentru ca ne place sa ne gandim pe termen lung la beneficii si la ROI.

Modelul nostru de audit SEO intern este urmatorul:

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

In functie de ce descoperim, prioritizam toate acele probleme pe care daca le rezolvam stim ca vor avea cel mai mare impact SEO in cel mai scurt timp. Revin la scop, care este cresterea traficului organic. 

Ce analizam la inceput?

In primul rand, analizam traficul organic din Google Analytics pe ultimii ani, pentru a vedea daca sunt scaderi sau penalizari Google. Urmarind trendul de trafic si comparatiile de la an la an, ne putem da seama daca s-a facut SEO sau nu, daca sunt miscari in piata si daca trebuie sa prioritizam penalizarile.

In al doilea rand, corelam datele de trafic din Analytics cu datele din Google Search Console, unde putem vedea clar trendul pe ultimele 12-16 luni. Aici verificam daca exista penalizari manuale sau daca sunt alte probleme semnalate de Google.

Tot in search console analizam raportul de Index Coverage pentru a vedea cate pagini sunt indexate, cate nu sunt indexate si ne uitam la motivele pentru care acele pagini nu sunt indexate.

Dupa ce ne uitam aici, analizam ce exista pe site. Folosim un crawler ca Screaming Frog, care ne arata tot ce avem nevoie sa stim din punct de vedere tehnic.

Apoi stim exact ce avem de optimizat si in ce ordine. Modelul acesta este modelul Agile, prin care noi in agentie ne asiguram ca pentru orice proiect rezolvam problemele care au cel mai mare impact pentru traficul organic.

Pentru cei care sunt mai tehnici, hai sa vedem care sunt elementele SEO tehnice pe care noi le auditam iar, apoi le vom defalca pe rand. 

  1. Audit trafic organic
  2. Audit penalizari (care sunt primele doua lucruri la care ne uitam)

Audit SEO Tehnic: 

  1. Crawl Budget
  2. Duplicate Content
  3. Indexabilitate
  4. Mobile SEO
  5. Analiza de Loguri de Server
  6. Performance si 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 ca fiecare site are)

Inainte sa le luam pe fiecare in parte, insist pe importanta implementarii recomandarilor agentei de SEO. As putea probabil sa scriu un articol intreg despre acest lucru. Este una dintre cele mai mari probleme de care noi ne lovim. Daca nu sunt implementate configuratiile de SEO, atunci sunt facute degeaba, pentru ca nu ajuta la nimic. Ele vor ramane un document agatat intr-un email, sau intr-un ticket la dev.

Atunci cand faci SEO, programatorii sunt automat implicati, pentru ca este necesar ca implementarile sa fie facute. Doar asa Google poate vedea noile directive, pe care sa le ia in calcul pentru crawling, indexare si ranking.

Avem cazuri cand asteptam si peste 6 luni ca recomandarile noastre sa fie implementate, iar atunci in aceste cazuri, businessul este afectat, pentru ca traficul organic nu creste. Noi avem astfel de cazuri, in care se prelungeste voit sau nu rezultatul din SEO. Din nou, insist pe implementarea lor, pentru ca sunt importante. 

Acum vom lua fiecare element in parte si vom vorbi despre el.

Optimizare Crawl Budget

Bugetul de Crawl este cel mai important aspect de optimizare cand vorbim despre site-urile foarte mari. Aici fiecare platforma are anumite configurari, de cum isi construieste navigatia si URL-urile. Multe platforme au acea problema numita Infinite Spaces, prin care Google poate crawla site-ul la infinit.

In cazul site-urilor mici (zeci, sute de pagini) nu este cazul neaparat sa iti faci probleme pentru bugetul de crawl, insa atunci cand ai foarte multe pagini, este cazul sa fie optimizat.

De ce?

Gandeste-te in felul urmator: magazinul tau online are 300 de categorii / subcategorii si 15.000 de produse. Fiecare categorie are cate 10 sectiuni de filtre a cate 10 filtre unice fiecare. Orice categorie poate avea filtre care se combina 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 in URL, pentru ca am selectat aproape toate filtrele din acea categorie.

Acum tu ai pe site categoriile si produsele pe care le vrei indexate, insa din cauza faptului ca bugetul de crawl nu este optimizat, Google, in loc sa crawleze si sa indexeze paginile “curate” din site, va aloca resurse pentru pagini ca cea de mai sus.

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

index coverage report gsc moloso

In acest caz avem 20.500 de pagini indexate si excluse peste 6.42M. Sunt asa multe excluse pentru ca aici la acest client avem infinite spaces.

Daca mergem mai departe la raportul de pagini excluse putem vedea care sunt motivele pentru care acele pagini nu sunt in index:

excluded pages gsc report moloso

Chiar daca nu iti poti da seama de probleme din acest raport, iti spunem noi ca Google se duce mereu fix acolo unde nu vrem sa se duca. Aproape 3M de pagini au noindex, pentru ca noi am setat noindex.

In cazul unui astfel de site, primul lucru pe care il optimizam este clar bugetul de crawl, pentru ca vrem ca site-ul sa fie indexat corect si cat mai repede.

Mai jos este un exemplu de cresterea traficului organic din 2019 dupa ce am facut optimizari de buget de crawl. Cresterile din luna 2 au fost de peste 30% si vorbim de peste 1M useri anual pe organic.

optimizare crawl budget

Duplicate Content

Duplicate content nu este ce crezi tu ca este :). In general, cand vorbim de duplicate content ne gandim la continutul preluat de pe alte site-uri. Pentru ecommerce este aproape imposibil sa ai continut 100% unic, pentru ca descrierea de produs este aceeasi la toate produsele. Descrierile vin de la producator si in general nu ai ce sa modifici la descriere si la detaliile tehnice.

Chiar si asa se pot face imbunatatari la descrierea de produs, sa nu ai tot continutul copiat de la producator. Se pot lua, de exemplu, top produse vandute si se poate dezvolta continut pentru ele. Un exemplu frumos am vazut la Dedeman:

continut produs dedeman

Am intrat pe site la Dedeman si am luat random un produs “boring” despre care nu ai ce sa scrii, dar chiar si asa, in text s-a descris produsul. S-a construit un mic text in functie de imaginea produsului si de detaliile tehnice.

In 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 in care in text se descrie efectiv cum este produsul.

continut produs dedeman canapea coltar

Hai sa revenim la duplicate content. Continutul duplicat apare de la urmatoarele lucruri:

  • Filtre
  • Sortari
  • URL-uri separate pentru acelasi produs

Google spune clar ca nu penalizeaza site-urile pentru continutul duplicat intern, insa […] ce se intampla de fapt este ca Google poate crawla acele pagini si nu mai indexeaza paginile curate. In acest fel, atat indexarea, cat si rankingul si traficul organic sunt afectate de continutul duplicat.

Hai sa luam cateva 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 genereaza ceea ce noi numim duplicate content. Tot aceste tipuri de pagini genereaza probleme de crawl budget. Ele trebuie tratate ca atare, pentru a le rezolva.

Indexabilitate

Include mai multe aspecte. Pentru indexabilitate avem de luat in calcul robots.txt, meta robots, canonicals, sitemaps si crawl budget. Acest lucru este important, pentru ca trebuie sa stii cat de bine este site-ul tau indexat sau nu. Aici revenim la raportul de indexabilitate din GSC.

Trebuie sa stii cate pagini ai in site vs cate sunt indexate.

indexabilitate gsc

Mobile SEO

Din 2019, 1 Iulie, Google a introdus Mobile First Indexing. Ce inseamna acest lucru? Google crawleaza si indexeaza prima data versiunea de Mobile, si nu pe cea de desktop.

Asta inseamna ca Google aloca mai multe resurse de crawling cu botul de Mobile. Acest lucru se poate verifica in GSC la Crawl Stats.

google bot crawl stats

Din totatul de crawl requests 37% au venit de pe mobile si 28% de pe Desktop. Vei vedea aceste lucruri in raportul din Google Search Console. Chiar daca Google aloca resurse si pe Desktop, indexarea se face tot pe Mobile.

In zilele noastre, aproape toate layout-urile / template-urile sunt destul de bine optimizate pentru mobile. Cea mai comuna tehnologie folosita este cea de Responsive Design. In general, pentru Mobile nu sunt probleme si site-urile raspund bine, insa avem acele cazuri cand exista probleme mari.

Probleme pentru Mobile SEO:

  • Continut diferit pe mobil vs desktop – intotdeauna continutul trebuie sa fie la fel atat pe mobil, cat si pe desktop
  • Fonturi prea mici – Google recomanda fontul de minimum 16px pentru text. Eu sunt fan 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
  • Optimizari doar pentru anumite device-uri vs altele
  • Continut mai mare decat display-ul
  • Load time prea mare pe mobil
  • Google vede site-ul ca nevalid pe mobile, insa el functioneaza bine pe live test sau invers.
  • mobile seo report GSC

Pentru acest lucru, exista la Page Experience in Google Search Console un raport de Mobile Usability in care Google afiseaza ce probleme a descoperit pe Mobile.

Atunci cand se testeaza site-ul mobile, ce greseala comuna am vazut este ca se testeaza doar HomePage-ul pe Mobile Test de la Google.

mobile test google.ro

Trebuie testate mai multe tipuri de pagini, in special cele pe care GSC le raporteaza cu erori. Cateodata poate fi dificil sa replici eroarea pe care Botul o semnaleaza. Google nu poate deschide site-ul tau 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 ofera cea mai clara viziune asupra a ce vede, ce crawleaza si ce indexeaza Google pe site-ul tau. Sunt necesare, pentru ca poti face multe optimizari pentru bugetul de crawl si SEO.

De exemplu, ai nevoie sa stii ce crawleaza Google vs ce indexeaza Google, pentru ca sunt doua lucruri total diferite. Mai mult decat atat, poti vedea daca ai probleme in site, comasand datele live din site vs datele din loguri.

In loguri poti vedea exact care sunt erorile pe care Google le intampina la tine in site, care sunt user agentii care iti acceseaza cel mai mult site-ul, care sunt http status codes, care sunt acele mixed status codes (de exemplu: un URL poate raspunde cu 200, insa la accesarile botilor a raspuns cu 5xx).

Poti optimiza mai bine structura interna a site-ului pentru ca poti vedea unde ai cele mai multe accesari. Aici sunt multe de discutat, insa logurile de server iti ofera cea mai mare claritate asupra a ce face Google pe site-ul tau.

Nici un alt instrument nu poate face acest lucru.

Problema pe care o intampinam noi cu logurile este ca sunt mai greu de primit, mai ales din partea SaaS-urilor. De exemplu, la Shopify nu putem avea logurile de server. In exemplul de mai jos avem putine hit-uri, pentru ca sunt logurile pe cateva ore. Insa, in general avem sute de mii de hituri in loguri si putem vedea mult mai clar pe 30 de zile ce se intampla.

server logs exemplu moloso

Performance si Load Time

Timpul de incarcare este un factor de ranking pentru SEO, insa el este important si pentru conversii. Cu cat site-ul se incarca mai repede, cu atat el converteste mai bine. Nimeni nu vrea sa astepte minute in sir sa se incarce un site sau sa plaseze o comanda.

Acum, pentru timpii de incarcare si Performance sunt mai multe lucruri de luat in considerare.

De exemplu, Load Time raportat in Google Analytics este un timp mediu de load calculat pe un sample de pagini pe toate dispozitivele, browserele, device-urile, conexiunile etc. Cat ar trebui sa fie acest timp mediu? 

Cel mai bun timp de incarcare pe care eu l-am vazut in Ecommerce-ul romanesc, este de 1.74s. Da, 1.74s se poate pe un site de ecommerce, care are listate cateva milioane de produse si care are aproximativ 70.000 de sesiuni lunar. Cel mai bun timp a fost in august cu 1.3s.

average load time ga moloso

Cel mai mare load time constant pe care l-am vazut in ecommerce-ul romanesc este de peste 8 secunde.

high load time ga

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

Bineinteles ca apoi trebuie sa te uiti pe ce browsere si pe ce sisteme de operare sunt cei mai mari timpi de incarcare, raportat si la numarul de useri / sesiuni.

De exemplu, daca 60% din useri iti vin pe Chrome, iar pe Chrome load time este de 5s, inseamna ca trebuie sa imbunatesti timpii pe Chrome. Degeaba pe IE ai load time de 2 secunde daca pe IE vin doar 1% din useri.

Performance Report

Raportul de performance se face de catre Google cu Lighthouse, pe care este bazat si PageSpeed Insights.

Performance Report Google LightHouse

In raportul de mai jos, avem homepage-ul de la site-ul care in medie are load time sub 2s, unde s-au investit peste 6 luni de programare pentru a fi optimizati metricii de la Google si chiar si asa, TTI tot apare ca 7.5s.

lighthouse cool

In acest raport sunt cativa metrici la care Google se uita in mod special, pe care Google ii numeste Core Web Vitals. Cei mai importanti sunt acestia:

  1. LCP (Largest Contenful Paint)
  • Masoara performanta in termeni de Load, de cand pagina incepe sa se incarce pana cand cea mai mare portiune de text/imagine(i) este afisata pe ecran.
  • Google recomanda ca LCP sa fie <2.5s

FID (First Input Delay)

  • Masoara interactivitatea cu pagina. Masoara timpul de cand un user face o actiune (click, tap, scroll etc.) pana cand browserul poate sa raspunda la acea interactiune.
  • Google recomanda ca FID sa fie <100ms

CLS (Cumulative Layout Shift)

  • Masoara stabilitatea vizuala. Calculeaza un scor pentru stabilitatea vizuala, adica acel scor prin care userii experimenteaza schimbari neasteptate in (butoane care nu merg, texte, elemente web care isi schimba pozitia, etc). Google recomanda ca CLS sa fie sub 0.1.

Din experienta noastra, optimizarea vitezei de incarcare este cel mai greu de facut, pentru ca Google are anumite cerinte, programatorii au altele. In acelasi timp, acesti metrici de la Google cer anumite lucruri care trebuie schimbate in platforme.

Cand vorbim de SaaS-uri, ele sunt foarte greu de schimbat. Hai sa luam exemplu DOM-ul (Document Object Model). DOM-ul creste cu fiecare element HTML, iar la Load Time, Browserul creeaza DOM-ul paginii.

DOM moloso

Cu cat sunt mai multe elemente in DOM, cu atat Load Time creste mai mult, insa in cazul SaaS-urilor sau a template-urilor cumparate, este complicat de modificat structura. De multe ori este mai simplu sa faci ceva de la 0 decat sa reoptimizezi un template.

Avand in vedere dificultatea si implicatiile tehnice, o agentie de SEO nu trebuie sa stie cum sa se faca programarea, ci ea poate sa semnaleze aceste probleme si dev-ul sa gaseasca solutii de rezolvare a lor. Din experienta noastra, dev-ul vine rar cu solutii.

Pentru a vedea cum performeaza site-ul tau in ochii lui Google, poti merge la raportul de Core Web Vitals din Search Console. In cazul de mai jos, atat pe mobile cat si pe Desktop avem 152 de Good URLs si 0 Poor sau care au nevoie de imbunatari.

core web vitals gsc

HTTP vs HTTPS

HTTPS este factor de ranking, si site-ul trebuie sa aiba un certificat SSL Valid. Acest lucru se verifica usor in Chrome.

certificat ssl valid

Alte probleme de la HTTP:

  • resurse interne ca CSS, JS, imagini se incarca pe HTTP
  • in site sunt multe linkuri interne care sunt pe HTTP
  • nu se verifica clar toate redirecturile + canonicals intre HTTP, HTTP WWW si HTTPS.
  • versiunea de https face 301 spre http

JavaScript SEO

In ultima vreme ne-am tot intalnit cu aceasta problema, care apare in special la SaaS-uri ca Shopify si de la template-urile de layout pentru Ecommerce.

JavaScriptul in sine nu este o problema, si este foarte folosit la tot ce inseamna Web. In schimb, Google, pentru a indexa continutul prin JS are nevoie sa faca mai multe actiuni si sa aloce alte resurse, care sunt limitate.

Tu vrei ca site-ul tau sa fie indexat, insa pentru acest lucru trebuie sa ii facem viata usoara si lui Google. Google ca sa poate sa indexeze JS-ul are nevoie sa crawleze site-ul, sa gaseasca fisierele JS, sa le trimita la randare (este practic un browser care emuleaza pagina) si abia apoi sa le trimita la indexare.

Google e super fan continut HTML pe care il crawleaza si indexeaza repede. Insa, pentru JS are nevoie de multe resurse de randare ca sa poate intelege paginile web.

googlebot-crawl-render-index

 

Pe scurt, cu cat ai mai mult JS pe site, si continutul magazinului online este dinamic, cu atat site-ul tau va fi indexat mai greu si cu atat traficul nu va creste. Dupa cum vezi mai sus, este o schema complicata de indexare / randare si alti termeni complicati de SEO :).

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

js seo chr

 

Mai jos este ce exista in HTML:

js seo chr source page

Dupa cum se vede, nu exista continut static, nu exista nimic de care Google se poate “agata” ca sa indexe rapid si usor aceste pagini. Tot continutul  site-ului este dinamic, nu apare nimic static.

Noi ca agentie in aceste cazuri trebuie sa ne asiguram ca Google indexeaza site-ul si trebuie sa venim cu solutii pentru aceste tipuri de probleme, pentru ca linkurile si etc. nu ajuta asa mult daca nu exista continut indexabil.

Fisierul robots.txt

Fisierul robots.txt (care este case sensitive) este acel prim fisier pe care Google il cere atunci cand iti crawleaza site-ul. In cazul site-urilor mici, o configuratie simpla cum este la moloso.ro este suficienta:

Moloso Robots.txt

Google trebuie sa stie ce si ce sa nu crawleze pe site si de aceea este nevoie de un astfel de fisier. Este important pentru ca poti bloca botii sa acceseze anumite sectiuni din site sau anumite tipuri de pagini.

In acelasi timp, daca nu se configureaza cum trebuie, poti sa ai probleme mari de indexare. Noi folosim robots.txt pentru a optimiza Bugetul de Crawl, insa configuratiile facute sunt mereu la nivel de platforma si sunt diferite si separate pentru fiecare in parte.

Uite un exemplu de fisier “complicat” pe Shopify care blocheaza parametri, sortari si alte tipuri de pagini care nu trebuie sa apara in Google Search.

robots.txt shopify example

Meta Robots / X Robots Tag

Pentru SEO, eu sunt foarte fan Meta Robots. Ca directive, sunt printre cele mai importante pentru Google si sunt luate in calcul repede.

Bugetul de crawl se optimizeaza cel mai bine cu meta robots si robots.txt.

Ce directive sunt cel mai des folosite:

  • noindex
  • follow
  • nofollow

Noi folosim configuratia de noindex, nollow pe toate acele pagini junk, care sunt total inutile pentru indexare. Insa, pentru a le indentifica, este nevoie de multe analize in spate, unde trebuie sa luam in calcul:

  • traficul pe acele pagini
  • linkurile externe pe acele pagini
  • configuratiile actuale
  • pageviews
  • utilitatea lor in search
  • intentia de cautare
  • canonicals

Meta Robots merge mana in mana cu Robots.txt.

Insa, daca setezi noindex in meta robots, ai in vedere sa nu blochezi din Robots.txt accesul la acele pagini, pentru ca Google nu va citi directiva de noindex si vei ramane in continuare cu problemele de crawl budget.

Noindex trebuie foarte bine testat si setat, pentru ca se poate pierde trafic mult daca nu este folosit corect.

Canonical Tag

Multa vreme am numit canonical tag a 7-a minune SEO, insa in ultimii ani, analizand logurile de server, am realizat ca nu functioneaza corect, mai ales in cazul site-urilor foarte mari. Canonical pentru Google este un hint, ci nu o directiva clara.

Canonical functioneaza bine doar in cazul in care continutul a doua pagini este foarte similar si gradul de duplicare este mare. Insa daca ai infinite spaces de exemplu, canonical tag nu este util.

Daca il lasi pe Google sa iti trateze paginile duplicate dupa cum vrea el, nu va face o treaba buna deloc. Am vazut cazuri in care Google raporteaza ca duplicate doua pagini de produs total diferite. Singurul lucru comun intre ele erau cateva cuvinte din URL.

Tagul este destul de bun, pentru parametri si UTM-uri.

Cand vorbim de site-uri enterprise, pentru a ne asigura ca optimizam bugetul de crawl, trebuie facute de la caz la caz combinatii intre canonical, noindex si robots.txt.

La fel ca in cazul noindex, canonical tag trebuie testat foarte bine, pentru ca si aici daca nu este implementat corect (cum se intampla mai des decat am vrea) putem avea probleme mari.

Hai sa luam un exemplu in cazul unei migrari, in care sunt implicate redirect and canonical chains, care sunt foarte daunatoare pentru crawling, indexare si traficul organic.

Avem URL vechi:

https://site.ro/categorie/ care trebuie sa faca 301 redirect spre https://site.ro/nume-nou-categorie/ 

Dupa implementarea migrarii avem asa:

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 (fara / la final).

In acest caz avem redirect & canonical chain, iar pentru o migrare poti pierde mult trafic organic, pentru ca Google nu poate merge lin prin toate aceste redirecturi si are nevoie de mult prea multe resurse sa poata sa indexeze site-ul corect.

Am mai vazut cazuri cand toate URL-urile de produs si linkurile interne din site sunt intr-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/. In acest caz, Google va indexa mult mai greu varianta finala, pentru ca nu primeste linkuri interne si pentru ca va ajunge greu la ele. Dupa cum spuneam, canonical este hint, nu directiva clara.

Title Tags, Meta Description, URLs si Headings

Le-am adaugat pe toate in aceasta sectiune, pentru ca sunt meta tagurile (mai putin URL-urile) si sunt cele mai importante elemente de onpage, unde sa mapam cuvintele cheie.

Toate trebuie sa fie unice, la nivel de landing page si sa fie relevante pentru continutul paginii.

  • Titlurile trebuie sa fie pana la maximum 60 de caractere pentru a fi afisate complet in Google Search.
  • Meta Descrierile trebuie sa fie pana la maximum 155 de caractere pentru a fi afisate complet in Google Search.

Noi, in agentie, mapam cuvintele cheie in aceste elemente SEO, doar dupa ce avem finalizata strategia de Keyword Research.

Pentru relevanta si pentru trafic optimizam atat cuvinte head terms cat si long tail, pentru a ne asigura ca maximizam traficul organic.

Trebuie luat in calcul faptul ca meta tagurile pe mobile se afiseaza diferit fata de Desktop, si pe anumite cautari, Google poate afisa mai multe caractere pe mobile decat pe Desktop.

URL-urile sunt importante, pentru ca ele sunt adresele la care ajung userii si botii, pentru a face anumite actiuni pe site. Problemele de indexare si crawling apar in general de la URL-uri, pentru ca nu sunt facute corect.

Cea mai buna structura de URL-uri este cea pe foldere:

site.ro/categorie/

site.ro/categorie/subcategorie/

site.ro/produs/

Ce greseli comune am vazut la URL-uri:

  • prea multi parametri
  • lipsa unei versiuni canonice cu / la final sau fara / la final
  • diacritice in URL-uri (mai ales la SaaS-uri)
  • URL-uri prea lungi
  • URL-uri encodate non ASCII
  • URL-uri cu (_) underscore in loc de –
  • prea multe cuvinte de legatura

analiza URL-uri

Mai jos asa arata rezultatele pe Desktop:

meta tags desktop

Asa arata rezultatele pe Mobile:

meta tags mobile

 

Pe mobile se vad clar imaginile, iar la Mindblower Google alege pe mobile sa afiseze si Brandul la final, pe cand pe Desktop nu o face.

Google spune ca isi ia libertatea sa schimbe atat TItlul paginii cat si Meta Descrierea in functie de cautarea facuta. Acest lucru pentru noi ca agentie de SEO nu ne avantajeaza, pentru ca optimizam aceste elemente pentru:

  • CTR
  • Sales
  • Relevanta
  • Cuvintele cheie

Cea mai buna metoda sa ne asiguram ca meta tagurile performeaza este sa facem A / B teste pe ele, in care sa testam diferite variante si cuvinte si sa vedem clar unde creste CTR-ul.

La analiza meta tagurilor analizam urmatoarele:

  • in primul rand, daca exista
  • cuvintele cheie optimizate
  • duplicarile
  • verificam afiseara lor in cautari
  • numarul de caractere

analiza meta taguri

Cele mai comune greseli pe care le-am intalnit:

  • lipsa meta tagurilor
  • lipsa cuvintelor cheie relevante
  • lipsa CTA in meta descriere
  • duplicari prea multe

Imagini

Imaginile sunt importante pentru useri, pentru sales. Noi in agentie nu insistam pe imagini, pentru ca vine putin trafic din Google Images.

La imagini ne asiguram de urmatoarele lucruri:

  • ca au dimensiuni potrivite (am vazut imagini de produs de 15mb :))
  • ca au alt text setat pentru produse

Pe site exista multe bannere sau imagini mici, iconite unde nu insistam sa adaugam alt text, pentru ca nu ajuta.

audit imagini

Pentru imagini, Google nu mai arata informatii in Google Search Console, sa stii, spre exemplu, cate click-uri / afisari exista.

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

Pentru ca site-ul sa functioneaze corect, sa fie indexabil si sa poata ranka, are nevoie ca toate paginile sa raspunda cu 200. Asta inseamna ca pagina este live.

Web-ul este atat de dinamic, ecommerce-ul la fel, incat este aproape imposibil sa nu existe si alte erori, ca 404, 410, 502, 503, 302 si altele. In general, erorile 3xx si 4xx interne in site sunt daunatoare si trebuie rezolvate.

Ele apar pentru ca paginile se schimba, poate se sterg din greseala, apar alte categorii, produsele din site dispar definitiv din stoc, etc.

Erorile de 5xx tin de server si trebuie sa te asiguri ca serverul este bun, poate tine mult trafic pe site si face fata cu brio la crawlingul botilor.

Cum le verificam? In site le verificam prin crawling si in functie de eroare le rezolvam dinamic sau manual. In general, 404 si 301 se rezolva manual. 

audit http status codes

 

Apoi trebuie sa verificam in GSC la crawl stats ce se intampla cu botii cand ajung pe site. De exemplu daca serverul raspunde la boti cu prea mult 5xx sau 4xx, asta inseamna ca Google nu iti va mai crawla site-ul si implicit indexarea va avea de suferit.

audit http status codes gsc

 

Apoi trebuie verificate si logurile pentru a vedea exact care sunt acele pagini care nu raspund corect. Sunt semnalate la dev si ei stiu apoi ce au de facut.

Sitemaps

Sitemapurile sunt utile, pentru ca il ajuta pe Google sa stie despre paginile din site-ul tau. Daca setezi sitemap-urile nu inseamna ca site-ul va fi si indexat. Pentru Google, un sitemap este ca un roadmap, prin care el descopera mai repede paginile tale si le poate prioritiza pentru crawling.

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

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

Sitemap-urile trebuie adaugate in Google Search Console si sunt utile pentru ca poti verifica gradul de indexare al site-ului tau la nivel de sitemap.

Dupa cum se vede mai jos, pe sitemapul de produse, avem indexate 1.340 de produse, insa 382 din ele inca nu sunt indexate. Putem vedea mai jos ce a facut Google.

audit sitemaps

Intr-un sitemap pot intra pana la 50.000 de URL-uri. Deci, daca exista multe produse in site, noi recomandam pentru produse sa facem sitemapuri de cate 10.000 de produse.

Schema.org

Pentru cine nu stie ce este Schema, de obicei toti o asociaza cu stelutele de rating din Search. Insa nu este doar atat, ce este acolo este doar ce se vede la suprafata.

Schema este importanta pentru Google pentru ca, folosind microdatele, el “intelege si stie” aproape la fel ca un om despre ce este site-ul tau. Cele mai importante tipuri de schema pentru Ecommerce sunt:

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

Este nevoie de Schema pentru ecommerce, pentru ca Google foloseste acele informatii si pentru Google Shopping. Exista rapoarte separate in GSC pentru aceasta zona.

Cu Schema.org este mai dificil in anumite cazuri, pentru ca sunt multe lucruri de pus la punct si trebuie setata corect. Ce se intampla de multe ori este ca setarile merg bine pentru o parte din produse, dar pentru altele nu.

Sunt multe campuri necesare de completat si multe date care merita sa fie adaugate. Este nevoie de o intelegere clara a acestei Schema si a modului in care functioneaza. Partea buna este ca ne ajuta si Google cu rapoartele din GSC si putem imbunatati unde apar probleme.

In GSC intotdeauna vei vedea acele warnings, care apar de la campurile care nu sunt obligatorii. De exemplu, nu toate produsele tale vor avea review-uri si Google le raporteaza ca warnings. Este important sa fie toate celelalte campuri valide.

audit schema

 

Schema trebuie testata cu https://search.google.com/test/rich-results pentru a ne asigura ca tipurile de schema sunt bine facute. In acest caz, avem mai multe tipuri setate care functioneaza corect, chiar daca exista un Warning.

Este important sa nu avem Erori.

schema tester

Pagina 404

Pagina 404 trebuie sa raspunda cu 404. Cea mai mare greseala pe care am vazut-o a fost la pagina 404 sa raspunda cu 200.

Pagina 404 trebuie sa fie creativa si sa contina linkuri interne spre alte pagini utile din site.

Mai jos avem un exemplu de 404 facut bine si creativ de la Travel Matters. Pe fundal este un video cu 4 tineri care sunt pe o plaja exotica. In pagina este un CTA mare pentru HomePage.

404 travel matters

 

Linkuri interne

Linkurile interne sunt importante pentru crawling, indexare si ranking. Structura interna de categorii trebuie sa fie facuta doar dupa research-ul de cuvinte cheie. Fiecare cuvant ales va determina cum va ranka pagina .

Categoriile si subcategoriile trebuie sa aiba ancore interne pe cuvintele cheie cu volumele cele mai mari de cautari, iar linkurile spre produse trebuie sa fie pe long tail.

Structura de categorii determina relevanta paginilor, mai ales atunci cand este facuta pe silozuri.

Linkurile interne trebuie sa fie prezente in HTML pentru a putea fi citite de Google.

Greseli comune:

  • meniul principal este facut prin JS si Google nu citeste corect toate linkurile interne
  • ancorele interne nu sunt exact match
  • nu se foloseste breadcrumbs
  • linkurile interne spre produse nu sunt prioritizate in functie de anumiti algoritmi (cum ar fi sa linkezi top sales)
  • in categorii nu sunt linkuite top produse vandute (si sunt afisate produse fara stoc)
  • nu exista relevanta intre linkurile interne
  • structura de categorii nu e relevanta
  • crawl depth este prea mare (exista prea multe linkuri interne pe lvl 4-5-6-10)

Cu cat se ajunge prin mai multe click-uri la o pagina, cu atat acea pagina va fi indexata mai greu.

“Sweet spot” este la maximum 3 click-uri de pe home, pentru a ajunge la produse.

crawl depth

In acest caz, dupa cum se vede, pe lvl 4-9 sunt prea multe pagini. Aici trebuie redus numarul de linkuri si imbunatatita structura.

In GSC exista un raport de linkuri interne si aici prima pagina cea mai linkuita din site trebuie sa fie HomePage-ul. De obicei, paginile de /contact/, /policy, /privacy vor aparea mereu in top. Nu este nimic de facut aici, ci trebuie verificat daca categoriile primesc indeajuns de multe linkuri interne.

internal links report

Alte probleme de SEO

Pentru ca web-ul este atat de vast si exista multe platforme si mai multe tehnologii, fiecare site are parte de problemele lui unice, pentru care este nevoie de multe analize pentru a fi descoperite.

In mai multe cazuri, probleme noi apar si pe parcurs de la update-uri sau de la alte modificari. Trebuie luat in calcul si acest lucru, pentru ca de fiecare data noi intampinam si descoperim probleme si dupa audit.

Mie imi place sa le caut si sa le rezolv, pentru ca se aduce mult plus valoare pentru business.

Ce tool-uri folosim in agentie?

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

SEO este simplu, insa este complex dupa cum vezi. Trebuie sa stii unde sa te uiti, cum sa te uiti si cum sa tratezi fiecare aspect in parte in functie de business si de site. Sunt multe elemente care merg mana in mana si este necesar sa fie cunoscute bine.

Acum gandeste-te cum ar fi sa primesti un document in care rezolvam toate aceste probleme? :).

Noi in agentie punem mult accent pe solutii si de fiecare data venim cu solutia optima pentru fiecare problema in parte. Chiar si asa, sunt cazuri in care asteptam mult implementarea solutiilor oferite.

SEO este si foarte tehnic in acelasi timp, iar o platforma defectuoasa nu iti va sustine cresterea business-ului tau. Este cazul si poate timpul sa iei in calcul si optimizarea tehnica a platformei.

Sursa imagine.

Author

Daniel Ene

SEO Growth Hacker & Partner at Moloso Agency. Daniel Ene se considera unul dintre norocosii care si-a gasit pasiunea inca de la inceput. De peste 11 ani s-a implicat in proiecte mari si mici, de la start-upuri pana la companii internationale. Este in permanenta in cautare de nou si de evolutie atat profesionala, cat si personala. Zi de zi cauta, testeaza si implementeaza noi trucuri de SEO pentru a a-si ajuta clientii sa aiba succes.