Program SEO, 18 februarie 2022

Acesta este un rezumat al celor mai interesante întrebări și răspunsuri de la Google SEO Office Hours cu John Mueller pe 18 februarie 2022.

Tipuri de site-uri web afectate de actualizarea Recenzii de produse

4:03 „[…] Întrebarea mea se referă la actualizarea recenziilor despre produse […]. Am vrut să înțeleg cum identifică Google dacă o pagină sau un site are legătură cu recenziile de produse. […] De exemplu, există un site de comerț electronic […] și au și un blog în care își revizuiesc propriile produse. Ei scriu despre avantajele și dezavantajele produselor lor, compară diferite produse. […] Va spune Google că […] este vorba și de recenzii de produse și pot fi analizate prin actualizarea recenziilor de produse? […]”

După cum a explicat John, „[…] Recomandările pe care le avem pentru recenziile produselor […] ar fi relevante pentru orice tip de recenzie a produsului. Așa că nu aș încerca neapărat să văd, Google crede că site-ul meu este un site de recenzii de produse sau nu […]. Dar, mai degrabă, dacă credeți că aceste bune practici s-ar aplica conținutului dvs., atunci faceți acele bune practici […]”.

Utilizarea API-ului de indexare

6:53 „[…] [documentația Google] menționează că API-ul de indexare ar trebui utilizat pentru pagini precum postarea de locuri de muncă sau evenimente de difuzare. Este posibil să încercăm acest API pentru diferite tipuri de conținut, cum ar fi unele articole de știri sau conținut de blog?”

John a răspuns: „Oamenii încearcă. Dar, în esență, ceea ce am documentat este pentru ce folosim API-ul. Dacă nu aveți conținut care se încadrează în acele categorii, atunci API-ul nu vă va ajuta acolo”.

EAT și algoritmii Google

10:54 „[…] EAT este menționat în [ Ghidul evaluatorului de calitate ], dar vreau să știu dacă algoritmii reali [includ și] factori EAT, cum ar fi expertiza autorului?”

John a spus: „Aș presupune că există o muncă indirectă făcută pentru a încerca să facă lucruri similare. […] Am pus acest lucru în ghiduri, astfel încât să putem îndruma testatorii de calitate să verifice aceste lucruri. Și dacă credem că este ceva important, atunci aș presupune că și oamenii din partea calității căutării lucrează pentru a încerca să înțeleagă asta într-un mod mai algoritmic.

Dar nu aș vedea […] [că ar exista] un scor EAT și trebuie să obții cinci sau ceva de genul acesta. Este mai mult încercarea de a înțelege contextul conținutului de pe web”.

Mențiuni de marcă neconectate și conținut generat de utilizatori

12:01 „[…] Văd că oamenii vorbesc despre mențiunile de marcă nelegate […]. Crezi că este important și pentru algoritmii [Google] […]?”

Prin mențiuni de marcă deconectate, persoana se referea la situații în care alte site-uri menționează marca dvs., dar nu includ un link către site-ul dvs.

John a spus: „[…] Cred că este cam complicat, pentru că nu știm cu adevărat care este contextul. Nu cred că este un lucru rău […] pentru utilizatori, deoarece, dacă vă pot găsi site-ul prin această mențiune, atunci acesta este întotdeauna un lucru bun. Dar nu aș presupune că există un […] factor SEO care încearcă să-și dea seama unde cineva menționează numele site-ului tău”.

12:58 „[…] Dar recenziile sau comentariile utilizatorilor? Crezi că este și un factor de clasare pentru un articol sau produs?”

John a răspuns că „[…] De multe ori, oamenii vor scrie despre pagină cu propriile cuvinte și asta ne oferă puțin mai multe informații despre cum putem afișa această pagină în rezultatele căutării. Din acest punct de vedere, cred că comentariile sunt un lucru bun pe o pagină. Evident, găsirea unei modalități de a le menține într-un mod rezonabil este uneori dificilă, deoarece oamenii spam și aceste comentarii […]. Dacă poți găsi o modalitate de a menține comentariile pe o pagină web, asta îți oferă puțin mai mult context și îi ajută pe cei care caută în moduri diferite să găsească și conținutul tău”.

Googlebot și derulare infinită

24:00 „[…] Știți dacă Googlebot este suficient de avansat pentru a gestiona derularea infinită sau măcar ceva în care conținutul continuă să se bazeze pe ceva?”

John a spus: „ Puțin […].

Ce se întâmplă atunci când redăm o pagină este că folosim un viewport destul de înalt, ca dacă ai un ecran foarte lung, și redăm pagina pentru a vedea ce va afișa pagina acolo. De obicei, aceasta ar declanșa o anumită cantitate de defilare infinită în orice metode JavaScript pe care le utilizați pentru a declanșa derularea infinită. Indiferent ce se va încărca acolo, asta ar fi ceea ce am putea indexa.

[…] În funcție de modul în care implementați derularea infinită, se poate întâmpla să avem această pagină mai lungă în index. S-ar putea să nu avem tot ce s-ar potrivi în pagina respectivă. Pentru că, în funcție de modul în care declanșați derularea infinită, este posibil să încărcați pagina următoare. Atunci s-ar putea să avem două sau trei dintre aceste pagini încărcate pe o singură pagină cu defilare infinită, dar nu totul. […] Aș recomanda să testați asta cu instrumentul de inspecție [URL] și să vedeți cât de mult ar ridica Google”.

Reîmprospătați și descoperiți datele din raportul Statistici de accesare cu crawlere

33:32 „În raportul Search Console [ Statistici cu crawlere ], 97% dintre solicitările de crawler sunt reîmprospătate, iar doar 3% sunt descoperiri. Cum să optimizați acest lucru și să lăsați Google să descopere mai multe pagini?”

John a răspuns: „[…] Este normal ca […] un site web mai vechi, mai stabilit să aibă multe accesări cu crawlere de reîmprospătare , deoarece ne vom uita la cantitatea de pagini despre care știm și care crește în timp. Iar cantitatea de pagini noi care intră tinde să fie destul de stabilă. Este destul de obișnuit, mai ales pentru un site web care este oarecum stabilit și care crește încet, să aibă un echilibru ca acesta, că cea mai mare parte a accesului cu crawling este pe crawling-ul de reîmprospătare și nu atât pe crawling-ul de descoperire.

Cred că ar fi diferit dacă ai avea un site web […] unde ai o mulțime de articole noi care apar, iar conținutul vechi devine irelevant foarte repede. Atunci cred că am avea tendința să ne concentrăm mai mult pe descoperire. […] Dacă aveți ceva de genul unui site de comerț electronic, în care doar creșteți cantitatea de conținut pe care o aveți încet, iar majoritatea conținutului vechi rămâne valabil, […] cantitatea de reîmprospătare cu crawling [va] probabil să ajungă la fii un pic mai sus”.

Accesarea cu crawlere redusă a unui site web

35:09 „În ultimele săptămâni, am observat o scădere uriașă a statisticilor de crawl, de la 700 la 50 pe zi. Există vreo modalitate de a înțelege din raportul Search Console care ar putea fi cauza acestei scăderi? Ar putea fi încărcarea paginii sursă? Cum pot citi corect defalcarea solicitării de accesare cu crawlere?”

John a oferit o explicație detaliată a modului în care Google accesează cu crawlere site-urile web și a factorilor care afectează accesarea cu crawlere: „[…] Există câteva lucruri care se referă la cantitatea de accesare cu crawlere pe care o facem.

[…] Încercăm să ne dăm seama cât de mult trebuie să accesăm cu crawlere de pe un site web pentru a păstra lucrurile actuale și utile în rezultatele căutării noastre. Și asta se bazează pe înțelegerea calității site-ului tău web, a modului în care lucrurile se schimbă pe site-ul tău. Numim asta cererea de crawl.

Pe de altă parte, există [există] limitările pe care le vedem de la serverul dvs., […] site-ul web, […] infrastructura de rețea în ceea ce privește cât de mult putem accesa cu crawlere un site web. Încercăm să le echilibrăm pe cele două.

Și restricțiile tind să fie legate de două lucruri principale: […] timpul general de răspuns la solicitări

la site-ul web și […] numărul de […] erori de server pe care le vedem în timpul accesării cu crawlere. Dacă vedem multe erori de server, atunci vom încetini accesul cu crawlere […]. Dacă vedem că serverul tău devine mai lent, atunci vom încetini și accesarea cu crawlere […].

Dificultatea cu aspectul viteză este că avem două […] moduri diferite de a privi viteza. Uneori, asta devine confuz când te uiți la rata de accesare cu crawlere. În special pentru rata de accesare cu crawlere, ne uităm doar la cât de repede putem solicita o adresă URL de la serverul dvs.?

Iar celălalt aspect al vitezei cu care probabil te întâlnești este totul în jurul Core Web Vitals și cât de repede se încarcă o pagină într-un browser. Viteza pe care o ia într-un browser tinde să nu fie direct legată de viteza cu care este nevoie pentru a prelua o adresă URL individuală pe un site web. Pentru că într-un browser, trebuie să procesați JavaScript, să introduceți toate aceste fișiere externe, să redați conținutul, să recalculați pozițiile tuturor elementelor de pe pagină. Și asta necesită o perioadă diferită de timp decât preluarea acelei adrese URL.

[…] Dacă încercați să diagnosticați o modificare a ratei de accesare cu crawlere, atunci nu vă uitați la cât timp durează o pagină pentru a se reda. […] Uită-te la cât de mult durează pentru a prelua acea adresă URL de pe server.

Celălalt lucru […] este că […] încercăm să înțelegem unde este găzduit site-ul […]. Dacă recunoaștem că un site web schimbă găzduirea de la un server la un alt server – care ar putea fi la un alt furnizor de găzduire, […] se mută la un CDN sau schimbă CDN-uri […] – atunci sistemele noastre vor reveni automat la unele rata de siguranță în care știm că nu vom crea probleme și apoi, pas cu pas, creștem din nou.

Ori de câte ori faceți o schimbare mai mare în găzduirea site-ului dvs., aș presupune că rata de accesare cu crawlere va scădea. Și apoi, în următoarele două săptămâni, va reveni la orice credem că putem accesa cu crawlere în siguranță pe site-ul nostru. S-ar putea să fie ceva ce vezi aici.

Celălalt lucru este că, din când în când, algoritmii noștri pentru a determina cum clasificăm site-urile web și serverele […] se pot actualiza și ei. […] Chiar dacă nu schimbați nimic cu infrastructura dvs. de găzduire, algoritmii noștri vor încerca să descopere [că] acest site web este găzduit pe acest server, iar acest server este unul care este frecvent supraîncărcat. Ar trebui să fim mai atenți la accesarea cu crawlere a acestui site web, pentru a nu cauza probleme. Acesta este ceva care, de asemenea, se stabilește automat în timp, de obicei peste câteva săptămâni […].

[…] În [Google] Search Console, puteți specifica o rată de accesare cu crawlere […] și asta ne ajută să înțelegem că aveți anumite setări […] pentru site-ul dvs. și vom încerca să ținem cont de asta. Dificultatea cu setarea ratei de crawl este că este o setare maximă. Nu este un semn că ar trebui să ne târăm atât de mult, ci mai degrabă că ar trebui să ne târăm cel mult ceea ce specificați voi acolo. De obicei, această setare este mai utilă pentru momentele în care trebuie să reduceți cantitatea de crawling, nu atunci când doriți să creșteți cantitatea de crawling.

[…] Un lucru pe care îl puteți face este că, în Centrul de ajutor pentru Search Console, avem un link către raportarea problemelor cu Googlebot. Dacă observați că accesarea cu crawlere a site-ului dvs. web este cu mult în afara limitei pentru ceea ce v-ați aștepta să fie, atunci puteți raporta probleme cu Googlebot prin acel link […]”.

Cum identifică Google țările vizate de pagini

56:25 „[…] În ceea ce privește direcționarea geografică, pe lângă folosirea hreflang, cum își dă Google ce [țara] vizați [cu] acest site web sau subdirectorul specific?”

Răspunsul lui John a fost: „ Încercăm să grupăm adresele URL după modele clare pe care le putem recunoaște […], de exemplu, după subdomeniu sau după subdirector. Dacă aveți țara în subdirector într-un loc mai înalt într-o cale, atunci ne este mult mai ușor să spunem, tot ce este pe această cale este pentru această țară, tot ce este sub acest alt drum este pentru o altă țară.

De asemenea, puteți verifica căi individuale în Search Console […], ceea ce ne face puțin mai ușor. În practică, nu aud prea multe feedback de la oameni care spun că acest lucru face o mare diferență.

[…] Aș încerca să fac […] cât mai clar posibil care țară este relevantă pentru adresele URL individuale, cu o cale clară în URL. Cred că a fost o întrebare pe care cineva a trimis-o și despre utilizarea țării ca parametru URL la sfârșit. Teoretic, poți face asta […]. Pentru sistemele noastre, recunoașterea adreselor URL aparțin cărei țări este mult mai dificilă […]. Dacă utilizați hreflang, atunci aceasta este o problemă mai mică acolo, deoarece puteți face asta pe bază de adresă URL”.

Un număr mare de adrese URL marcate ca Descoperite – momentan nu sunt indexate

58:25 „[…] Suntem un mare site de comerț electronic și, pe măsură ce ne-am verificat raportul de accesare cu crawlere, am constatat că există cantități uriașe de adrese URL în [ Secțiunea Descoperite – neindexate în prezent ] […]. Este acesta un indiciu al [o] problemă [pe site-ul nostru] […]?”

John a spus: „ Cred că depinde de care sunt acele pagini și de cum le folosești pe site-ul tău. […] Găsim tot felul de adrese URL pe web și multe dintre acele URL-uri nu trebuie accesate cu crawlere și indexate, pentru că poate sunt doar variante ale adreselor URL pe care le cunoaștem deja sau […] un forum sau un scraper aleatoriu scriptul a copiat adrese URL de pe site-ul dvs. și le-a inclus într-un mod rupt. […] Este foarte normal să existe multe dintre aceste adrese URL care fie sunt accesate cu crawlere și nu sunt indexate, fie descoperite și nu accesate cu crawlere, doar pentru că există atât de multe surse diferite de adrese URL pe web.

[…] Încercați să descărcați […] un eșantion din acestea, astfel încât să puteți privi exemple individuale și […] să clasificați care dintre acele URL-uri sunt cele care vă pasă și care […] sunt cele pe care le puteți ignora.

[…] Cei la care îți pasă, asta este ceva în care aș încerca să-mi dau seama ce ai putea face pentru a le lega mai bine pe site-ul tău în ceea ce privește lucruri precum linkurile interne. Deci, dacă acestea sunt produse sau categorii individuale care nu sunt găsite, încercați să vă dați seama ce puteți face într-un mod sistematic pentru a vă asigura că toate aceste adrese URL sunt mai bine legate între ele. […] În special cu un site de comerț electronic mai mare, poate deveni dificil, deoarece nu poți să te uiți la fiecare URL individual tot timpul.

Dar, uneori, există trucuri pe care le poți face acolo unde spui: orice este categoria de prim nivel, fac link la el de pe pagina mea de pornire. Și mă asigur că categoria mea de primul nivel are cel mult […] poate 100 de articole sau 200 de articole, astfel încât să aveți o funcție de forțare în ceea ce privește ceea ce îi dați Google să acceseze cu crawlere și să indexeze. Pe baza acestui lucru, îl puteți construi puțin mai sistematic.

[…] Într-o oarecare măsură, aș accepta doar că Google nu poate accesa cu crawlere și indexa totul. […] Dacă recunoașteți, de exemplu, că […] produse individuale nu sunt accesate cu crawlere și indexate, asigurați-vă că cel puțin pagina de categorie pentru acele produse este accesată cu crawlere și indexată. Pentru că astfel, oamenii pot găsi în continuare conținut pentru acele produse individuale pe site-ul tău […].

Vedeți dacă vă puteți accesa cu crawlere site-ul dvs., astfel încât să aveți date puțin mai directe despre cum poate fi accesat cu crawlere un site ca al dvs. Există diverse instrumente de crawling acolo. […] Prin accesarea cu crawlere a site-ului web, puteți vedea care dintre aceste adrese URL sunt legate foarte departe de pagina de pornire și care dintre acestea sunt legate mai aproape de pagina dvs. de pornire. Și pe baza asta, uneori poți modifica puțin structura site-ului pentru a te asigura că lucrurile sunt rezonabil de apropiate sau rezonabil de stabile, în ceea ce privește distanța de la pagina ta de pornire”.