22 ianuarie 2019 – Note pentru Hangouts Google Help

Săptămâna aceasta, John se află în Big Apple, New York. S-au alăturat IRL, de la stânga la dreapta, de Martin Splitt de la echipa Java Script de la Google, Chris Love, Lily Ray, Marie Haynes, Dave Minchala și Quason Carter. Săptămâna aceasta au fost câteva întrebări grozave despre Cloudfare, QRG și New Page Speed ​​Tool. Linkul către videoclip și transcrierea completă pot fi găsite mai jos!

Cloudflare blochează uneori Googlebot?

7:58

„Da, nu știu cum s-a configurat asta cu Cloudflare în acest moment, dar știu că în trecut obișnuiau să blocheze oamenii care falsifică Googlebot. Deci, dacă îl folosești pe al tău, nu știu, Screaming Broasca sau ceva de genul -- spuneți, eu folosesc agentul utilizator Googlebot, atunci ar bloca asta pentru că ar putea spune, cum ar fi, acesta nu este un Googlebot legitim. Putem bloca asta. Dar, în cea mai mare parte, cred că au suficientă practică pentru a recunoaște roboții Google obișnuiți și pentru a-i lăsa să se acceseze cu crawlere normal.”

Rezumat: uneori, la testare, poate părea că Cloudflare blochează Googlebot. Ceea ce se întâmplă probabil aici este că Cloudflare blochează oamenii care se prefac a fi Googlebot. Deci, dacă utilizați un instrument precum Screaming Frog și alegeți Googlebot ca agent de utilizator, este posibil să nu puteți accesa cu crawlere site-uri folosind Cloudflare .

Linkurile nenaturale mai pot afecta un site din punct de vedere algoritmic? Dacă da, poate ajuta utilizarea instrumentului de respingere?

14:01

"Cred că a fost o întrebare bună. Deci, din punctul meu de vedere, ceea ce m-aș uita acolo este, pe de o parte, cu siguranță cazul în care există o acțiune manuală. Dar și cazurile în care vrei și Dacă vezi o mulțime de acțiuni manuale, ar spune, ei bine, dacă echipa de spam web s-ar uita la asta acum, ți-ar oferi o acțiune manuală. Un fel de cazuri în care ai spune, ei bine, acțiunea manuală este mai mult o chestiune de timp și nu se bazează pe ceva care a fost făcut-- nu știu-- unde s-a făcut în mod clar acum câțiva ani, și nu a fost un fel de limită. Dar genul de lucruri în care te uiți la el și spuneți, dacă cineva din echipa de spam web ar primi asta ca un sfat, ar face o acțiune manuală și, cu siguranță, acesta este genul de lucru în care aș curăța asta și aș face ca o dezavuare pentru asta. Da, cred este greu de spus dacă există o anumită cronologie. Dar, în general, dacă echipa de spam web s-a uitat la asta și a spus că lucrurile au trecut mai departe. Acest lucru a fost în mod clar d unul acum cativa ani. Nu a fost total rău intenționat. Atunci probabil că nu ar lua măsuri manuale pentru asta. "

Și presupun că probabil că nu puteți răspunde la asta, dar există vreo modalitate prin care... cum ar fi, deci să spunem că nu am primit o acțiune manuală sau nu au primit o acțiune manuală. Pot acele link-uri să-i rănească din punct de vedere algoritmic? Pentru că simțim că vedem unele îmbunătățiri pe unele site-uri, știi, după ce am dezavuat. Deci, din nou, știu că întotdeauna... nu este niciodată alb-negru.

Asta poate fi cu siguranță cazul. Deci este ceva în care algoritmii noștri când ne uităm la asta și văd, oh, sunt o grămadă de link-uri foarte proaste aici, atunci poate că vor fi puțin mai precauți în ceea ce privește linkurile în general pentru site-ul web. Deci, dacă curățați asta, atunci algoritmii se uită la asta și spun, oh, există-- există un fel de-- e OK. Nu este rău.

Rezumat: dacă aveți linkuri care au fost create special doar pentru SEO și aveți multe dintre ele, acestea pot determina algoritmii Google să nu aibă încredere în toate linkurile dvs. Cel mai bine ar fi dezavuat pentru astfel de cazuri.

Cum măsoară algoritmii Google EAT al editorilor?

33:40

„Nu știu. Cred că probabil că este greu de înțeles din punct de vedere algoritmic. Și dacă ar trebui să faci orice fel de lucruri tehnice, atunci te-am anunța. Deci, dacă există lucruri precum marcarea autorului pe care le-am am avut în unele momente despre care credem că ar fi util pentru așa ceva, cu siguranță am aduce asta acolo. Dar o mulțime de lucruri sunt într-adevăr un fel de factori de calitate mai blânzi pe care încercăm să-i dăm seama și nu este ceva tehnic pe care îl ai fie faci, fie nu faci. Este mai degrabă să încerc să-mi dau seama cum ar putea privi un utilizator la asta. Deci nu ceva anume la care aș putea indica.”

Rezumat: Există o mulțime de „factori de calitate soft” pe care Google ia în considerare. Privește lucrurile din perspectiva utilizatorului. De asemenea, marcarea autorului poate ajuta Google să înțeleagă mai bine lucrurile.

Dacă ceva este în Ghidul evaluatorilor de calitate, este rezonabil să presupunem că Google dorește ca acest lucru să se reflecte în algoritmii lor?

34:44

Cred că, în general, este probabil o practică bună să urmărești asta. Evit să încerc să mă concentrez prea mult asupra a ceea ce Google ar putea folosi ca factor algoritmic și să-l privesc mai mult deoarece-- credem că acest lucru este bun pentru web și, prin urmare, vom încerca să mergem în acea direcție și să facem acestea. fel de lucruri. Așadar, nu atât de mult, este ca și cum aș face un site bun doar ca să mă pot clasa mai bine, dar fac un site bun pentru că atunci când apar în căutare, vreau ca oamenii să aibă o experiență bună. Și apoi se vor întoarce pe site-ul meu și poate vor cumpăra ceva. Așa că asta este direcția în care aș vedea că, nu ca să fac asta pentru a mă clasa, ci pentru a avea o relație sănătoasă, pe termen lung, pe web.

Rezumat: gândiți-vă la ce este mai bine pentru utilizatori. Chiar dacă nu tot ce este în QRG este reflectat în prezent în algoritmii Google, toți aceștia sunt pași grozavi către îmbunătățirea calității în general.

Există o schemă care să ajute site-urile să apară mai sus pentru rezultatele căutării vocale?

36:10

Nu știu. Nu pot să mă gândesc la nimic neplăcut. Așadar, există un marcaj vorbibil pe care îl puteți folosi, care este probabil rezonabil să... să vă uitați pentru a vedea unde ar putea avea sens pe o pagină. Nu cred că îl vom folosi încă în toate locațiile.

Rezumat: marcajul vorbibil nu este folosit încă în toate locațiile geografice. Dar, acesta este un loc bun pentru a începe.

Câteva sfaturi pentru a câștiga fragmente recomandate

38:03

Dar fragmentele prezentate, în special, nu cred că avem vreun tip de marcare specific pentru asta. Deci, asta este ceva în care dacă aveți o structură clară pe pagină, asta ne ajută foarte mult. Dacă putem recunoaște ca tabele pe o pagină, atunci le putem scoate mult mai ușor. În timp ce, dacă folosești HTML și CSS de lux pentru a-l face să arate ca un tabel, dar nu este de fapt un tabel, atunci ne este mult mai greu de scos.

Rezumat: nu există nici un marcaj pe care îl puteți adăuga pentru a câștiga un fragment recomandat. Dar, o bună utilizare a etichetelor h și a tabelelor HTML normale poate ajuta cu adevărat.

Ar trebui adăugată schema de locație la toate paginile?

50:47

Răspuns 51:42 - Din câte știu eu, este doar pagina de pornire. Nu știu. Știți vreunul dintre voi?

Răspuns de la Liz 51:4 7 - Ar trebui să fie doar o pagină, de obicei cu organizație și corporație. Asta este in general recomandarea.

MARTIN SPLITT 52:00 - Bănuiesc că nu contează care... nu contează la fel de mult ce pagini, la fel cum nu o puneți pe fiecare pagină pe care o aveți, cred că este partea mai importantă. Cred că depinde de... dacă sunteți un site de știri, probabil că are sens să îl puneți în pagina de contact, sau în pagina despre, sau așa ceva. În timp ce într-un site web de magazin sau restaurant, probabil că este OK să îl puneți pe pagina de pornire.

IOAN 52:20 - Cred că, de asemenea, în acest caz, nu contează atât de mult pentru noi pentru că trebuie să-l putem găsi undeva, cum ar fi pagina de start sau pagina de contact. Dar dacă îl avem în altă parte, nu ne schimbă nimic. Deci, cel mai important lucru cu care să nu-l comparăm este marcajul pentru recenzii, unde vedem uneori oameni care pun o recenzie ca o companie pe toate paginile site-ului, cu speranța de a obține stelele și rezultatele căutării pentru fiecare pagină de pe site-ul lor. Și asta ar fi rău pentru noi. Dar informațiile de contact, dacă le aveți marcate, sunt... Nu văd nicio problemă cu asta.

Rezumat: Nu prea contează. Ar trebui să fie pe pagina de contact și probabil despre pagina dvs. și pagina de pornire. A avea o schemă de locație pe site nu este o problemă, dar nici probabil nu este necesară.

De ce este noul instrument PageSpeed ​​Insights, bazat pe Lighthouse, atât de mai dur atunci când punctează site-urile web?

53:05

Marie Haynes: Nu este întrebarea mea, dar pentru a da un context, noile date Lighthouse pentru viteza paginii sunt mult mai dure decât obișnuia să fie Page Speed ​​Insights. Deci ceva care a avut un scor de 80 pe Page Speed ​​Insights ar putea fi un 29 roșu pe Lighthouse. Deci asta e o întrebare bună. Este posibil ca asta să cauzeze... pentru că știm că pe dispozitive mobile, site-urile foarte lente ar putea fi retrogradate. Deci, este bine să spunem, știi, dacă ești în roșu la testul Lighthouse, că ar trebui să îmbunătățim lucrurile pentru că ar putea provoca o retrogradare sau există o întrerupere?

Răspuns 54:07 - Deci nu avem o mapare unu-la-unu a instrumentelor externe și a tot ceea ce folosim pentru social. Da, este foarte greu de spus, dar în căutare, încercăm să folosim o combinație de date reale, ce sunt, teste de laborator, care este un fel ca testul Lighthouse și datele din raportul Chrome UX, unde în esență ce Măsurăm ceea ce ar vedea utilizatorii site-ului web.

MARTIN SPLITT 55:37 - De asemenea, este important să vedem că Lighthouse, de exemplu, măsoară în mod specific pentru o conexiune 3G la capătul median - sau ca un telefon de performanță medie, da. Deci, practic, dacă utilizați un Apple McIntosh recent sau un computer recent cu Windows rapid, cu o conexiune foarte bună, cum ar fi prin cablu, sau o conexiune Wi-Fi foarte bună în biroul dvs., desigur, vedeți un timp de încărcare de două secunde, dar un utilizator real cu telefonul în sălbăticie probabil că nu vede asta. Deci, este unul dintre aceste cazuri ca și cum nu strica niciodată să vă faceți site-ul mai rapid, dar acest lucru este foarte, foarte greu de spus cum ar arăta din perspectivă interioară, deoarece folosim valori foarte specifice care nu sunt neapărat să mapeze unul cu unul la ceea ce expun instrumentele....desigur că este important să remediați asta, pentru că nu doriți ca utilizatorii să aștepte pe site-ul dvs. pentru totdeauna. Asta te va răni. Asta va răni utilizatorii tăi. Asta o să te doară în căutare. Dar nu plătesc... Aș spune că uită-te la instrumente. Dacă instrumentele vă spun că vă descurcați bine, atunci nu ar trebui să vă faceți griji prea mult pentru asta. Dacă instrumentele vă spun că nu vă descurcați bine, atunci cred că timpul petrecut pentru a afla de ce spune... de exemplu, dacă ceea ce spune este relevant, este irosit. Ar trebui mai degrabă să te uiți la a face site-ul mai rapid.

Performanța mobilă este un factor foarte important pentru utilizatorii dvs., precum și pentru orice altceva. Așadar, aș spune că asigurați-vă că site-ul dvs. are performanțe bune în condițiile din lumea reală. Poate chiar să-mi iau un telefon ieftin și să încerc site-ul din când în când, și dacă... asta e ceva ce îmi place să fac și obișnuiam să fac înainte de a mă alătura Google cu echipa de dezvoltare cu care lucram. Am fost, uite, vrei să folosești acest site pe acest telefon? Era ca și cum, oh, asta e oribil. Sunt ca, mhm, da, așa că poate ar trebui să facem ceva în privința asta.

JOHN - În Chrome, îl puteți configura și încerca diferite viteze de conectare. Emulator mobil. Cred că sunt lucruri foarte bune la care să te uiți și, de asemenea, să te uiți la baza ta de utilizatori. Uitați-vă la datele dvs. de analiză dacă observați că oamenii vă folosesc site-ul web doar cu un iPhone de ultimă generație, atunci poate că este o problemă mai mică decât dacă observați că oamenii se conectează la site-ul dvs. din conexiuni rurale aleatorii, care sunt lent și au dispozitive low-end, atunci poate că e mai mult.

Rezumat: Lighthouse măsoară vitezele pentru o conexiune 3G, astfel încât majoritatea site-urilor vor funcționa mult mai rapid decât este afișat aici pentru majoritatea sesiunilor. Notă: după ce acest hangout a fost încheiat, Martin a continuat spunând că este „prima vopsea plină de conținut” care este cea mai importantă în ceea ce privește potențialele retrogradări în clasament.

Dacă vă plac astfel de lucruri, vă va plăcea newsletter-ul meu!

Eu și echipa mea raportăm în fiecare săptămână despre cele mai recente actualizări ale algoritmului Google, știri și sfaturi SEO.

Video și transcriere completă

Întrebarea 1:32 - Mă întrebam dacă aveți mai multe îndrumări sau mai multe puncte de vedere despre testare într-un mod pe care SEO-ul îl poate folosi pentru a fi mai precis și mai încrezător în raportarea companiei. Am încercat chestia asta și și-a avut impactul. Și am făcut-o într-un mod sigur, așa cum ne-ar recomanda Google.

Răspuns 3:20 - Deci, din punctul meu de vedere, încerc să separ lucrurile de tip mai tehnic de schimbările de tipul calității. Deci, orice lucru care este cu adevărat un lucru tehnic clar, puteți testa destul de mult dacă funcționează sau nu funcționează. Nu este o chestiune că funcționează sau nu funcționează, dar multe dintre aceste lucruri tehnice, mai ales când te uiți la randare sau când te uiți la Google poate indexa acest conținut, asta este ceva care fie funcționează, fie nu. Unde devine dificil este tot ceea ce este vorba -- este indexat, dar cum apare în clasamente? Și cred că pentru o mulțime de asta, nu există o modalitate absolută de a testa asta cu adevărat. Pentru că dacă testezi asta într-o situație izolată, cum ai face un site de testare, și îl configurezi cu orice recomandări ai, nu poți presupune cu adevărat că un site de testare va funcționa la fel ca un site web normal. Uneori sunt lucruri simple, cum ar fi dacă este un site de testare, atunci poate că nu vom face randare completă pentru că credem că nu are sens să petrecem atât de mult timp pe asta și asta, pentru că, de exemplu, nimeni nu se uită la el. Nu apare niciodată în rezultatele căutării, de ce ar trebui să ne deranjez să punem atâtea resurse în spatele asta? În timp ce dacă ai face asta pe un site web normal, asta ar funcționa foarte diferit. Așa că nu am îndrumări clare despre ce ar trebui să faci sau ce nu ar trebui să faci. Pare mai degrabă genul de lucru în care te uiți la tendințele generale în care vezi că apare site-ul web, la felul schimbărilor în clasamente pe care le vezi pentru acele interogări și încerci să aplici cele mai bune practici acolo.

Întrebarea 5:21 - Deci poate dacă-- un exemplu concret, poate îl puteți folosi pentru-- poate că ar fi util, așa că ceva de genul unui test de etichetă de titlu, nu? Dacă ai fi făcut asta... ce, dacă ar fi ceva, ar trebui să căutăm? Sau există ceva de urmărit pentru a dezlega -- asta se datorează testului nostru sau se datorează schimbării ceva la server, algo, dinamica competitivă? [Râsete] Presupunând că facem alte lucruri pentru a ne uita la aceste externalități.

Răspuns 5:56 - Cred că o schimbare a etichetei de titlu este de fapt destul de complexă din partea noastră, deoarece există un fel de interacțiune între Google folosește o etichetă de titlu pe care o oferiți de fapt, pe de o parte, pentru clasare, pe pe de altă parte, pentru afișarea în rezultatele căutării. La fel ca pentru desktop și mobil, avem o cantitate diferită de spațiu, așa că s-ar putea să arătăm etichete de titlu ușor diferite. Utilizatorii ar putea răspunde la asta în moduri diferite. Deci ați putea să vă clasați în același mod, dar utilizatorii s-ar putea gândi, oh, aceasta este o pagină grozavă. O voi afișa mai sus -- sau voi face clic pe ea în rezultatele căutării, deoarece arată ca o pagină grozavă. Și atunci ai mai mult trafic. Dar clasamentul este de fapt același. Deci este ca un lucru bun? Probabil, presupun. Dacă te uiți doar la clasament, atunci ar părea că, ei bine, nu ai schimbat nimic din nimic și doar am primit mai mult trafic.

Dar asta este ceva în care există o mulțime de aspecte diferite care curg acolo. Așa că este ceva în care cred că, în calitate de SEO, este util, pe de o parte, să ai o înțelegere tehnică a lucrurilor care s-au întâmplat, dar și să ai mai multă înțelegere de marketing și calitate a modului în care utilizatorii reacționează la schimbare, la ce sunt schimbări pe termen lung pe care le-am putea afecta utilizatorilor, cum le puteți conduce pentru a vă asigura că site-ul nostru este văzut ca cel mai relevant site în situațiile în care oamenii caută ceva legat de asta. Și cred că este ceva foarte greu de testat. Chiar și în marketingul tradițional, unde au avut ani și ani de practică, este foarte greu de testat, cum ar fi, are acest lucru un impact mare sau nu? Este ceva în care ajung să se uite la imaginea de ansamblu sau să facă studii asupra utilizatorilor, ceea ce poți face și ca SEO. Îmi pare rău. [RÂSETE]

Întrebarea 7:58 - Am o întrebare mai directă. Deci, un număr dintre site-urile noastre, știți, utilizează Cloudflare și am observat că blochează direct Googlebot, nu? Dar nu a avut prea mult impact asupra clasamentelor noastre, asupra vizibilității noastre etc. Așadar, încercăm să ne dăm seama cum, de exemplu, folosiți un alt bot pentru a accesa cu crawlere un index în afara robotului Google și cum ar trebui să ne gândim la asta atunci când CDN-urile fac tot posibilul să blocheze botul?

Răspuns 8:33 - Da, nu știu cum este configurat cu Cloudflare în acest moment, dar știu că în trecut obișnuiau să blocheze oamenii care falsifică Googlebot. Deci, dacă folosești, cum ar fi, propriul tău, nu știu, Screaming Frog sau ceva de genul -- spui, folosesc agent de utilizator Googlebot, atunci ar bloca asta pentru că ar putea spune, cum ar fi, acesta nu este un agent legitim Googlebot. Putem bloca asta. Dar, în cea mai mare parte, cred că au suficientă practică pentru a recunoaște roboții Google obișnuiți și pentru a-i lăsa să se târască în mod normal.

Întrebarea 9:02 - Da, a fost interesant. Pentru că a contactat o grămadă de colegi de la alte agenții și ei reproduceau situații similare chiar și pe propriul lor site. De exemplu, a existat un bilet de asistență în Cloudflare și acesta a fost, de asemenea, blocat când încercam doar să randez direct de pe Googlebot sau smartphone-ul Googlebot.

Răspuns 9:21 - Bine, da. Ei bine, nu avem nicio soluție. De exemplu, dacă site-urile web ne blochează, suntem oarecum blocați. Dar, de obicei, dacă un serviciu precum Cloudflare ne-ar bloca în mod implicit, atunci asta ar afecta o mulțime de site-uri web. Și am observa asta. Probabil că am contacta Cloudflare pentru așa ceva. Poate că au niveluri diferite de servicii. Deci, este ca și cum ești la nivelul inferior, atunci este ca un serviciu gratuit, dar avem o limită cu volumul de trafic. Nu stiu daca au asa ceva. Este ceva ce am văzut cu alți hosteri, unde, dacă aveți un fel de găzduire implicită gratuită configurată, atunci uneori au doar un plafon de trafic și blochează lucrurile.

MARTIN SPLITT: S-ar putea să nu vezi imediat asta în statistici, după cum ești clasat și alte chestii. Pentru că, în principiu, dacă avem conținut de la tine, și practic, site-ul web nu este... în funcție de ceea ce înseamnă blocat, în acest caz, pentru că nu am văzut asta. Și conduc câteva site-uri în spatele Cloudflare și nu am avut probleme. Dar, din nou, nu am un site web gigantic sau nu-mi place cantități uriașe de trafic pentru că sunt pe planul gratuit. Asta e... dar dacă nu primești o eroare din partea noastră, s-ar putea să păstrăm conținutul pe care l-am văzut ultima dată. Și asta pur și simplu se clasează bine și e în regulă.

Răspuns 12:09 - Da, deci cred că ceea ce s-ar întâmpla într-un caz ca al tău este că am încetini accesul. Și am încerca să păstrăm conținutul pe care îl putem obține mai mult pe index și am relua un pic mai mult. Dar asta înseamnă, de asemenea, că dacă faceți modificări pe site-ul dvs. web, ne va dura mai mult să le luăm. Dacă trebuie să accesăm din nou cu crawlere lucrurile în mod semnificativ, cum ar fi, nu știu, AMP, sau dacă adăugați ceva de genul sau așa pe întregul site, atunci totul va dura mult mai mult. Deci, dacă observați în mod regulat că nu putem accesa cu crawlere cu un robot Google obișnuit, atunci asta e ceva pe care îl încep cu gazda, ca să putem vedea.

Întrebarea 14:01 - Grozav. Deci am o întrebare despre instrumentul de dezavuare. Așa că avem tot timpul oameni care vor să facem audituri de legături. Și încă de la Penguin 4.0, deci în septembrie 2016, unde a spus Gary Illyes, și cred că ai spus și tu, de exemplu, Google se pricepe destul de bine la ignorarea linkurilor nenaturale. Deci, gândul meu la acel moment era că nu ar trebui să folosim instrumentul de dezavuare pentru a cere Google să ignore link-urile pe care le ignoră deja, cu excepția cazului în care ați avut o acțiune manuală pentru link-uri nenaturale. Așa că l-am recomandat doar pentru site-uri care au creat în mod activ link-uri, au încercat să manipuleze lucruri, lucruri care sunt link-uri nenaturale. Dar cred că există atât de multă confuzie în rândul webmasterilor pentru că văd oameni tot timpul, știi, percepând tone de bani pentru a audita-- pentru a dezavua link-urile care sunt doar-- Știu că sunt ignorați. Așa că mi-ar plăcea dacă am putea avea doar puțin mai multe lămuriri. Așadar, poate dacă pot să vă dau un exemplu, cum ar fi, dacă a existat un proprietar de afaceri care, acum câțiva ani, a angajat o companie de SEO și acea companie de SEO a făcut o grămadă de postări de invitați doar pentru link-uri și, știți, chestii care a fost un fel de calitate medie, dacă știți ce vreau să spun, nu ultra spam, putem fi siguri că Google ignoră acele link-uri? Sau ar trebui să intrăm și să dezavuim?

Răspuns 15:22 - Cred că a fost o întrebare bună. Deci, din punctul meu de vedere, ceea ce m-aș uita acolo este, pe de o parte, cu siguranță cazul în care există o acțiune manuală. Dar, de asemenea, cazurile în care doriți să vedeți o mulțime de acțiuni manuale ar spune, ei bine, dacă echipa de spam web s-ar uita la asta acum, v-ar da o acțiune manuală. Un fel de cazuri în care ați spune, ei bine, acțiunea manuală este mai degrabă o chestiune de timp și nu se bazează pe ceva care a fost făcut -- nu știu -- unde s-a făcut în mod clar câțiva ani acum, și a fost un fel de limită nu. Dar genul de lucruri în care te uiți la el și spui, dacă cineva din echipa de spam web ar primi asta ca un sfat, ar face o acțiune manuală și, cu siguranță, acesta este genul de lucru în care aș curăța asta și aș face ca o dezavuare pentru asta. Da, cred că este greu de spus dacă există o anumită cronologie. Dar, în general, dacă echipa de spam web s-a uitat la asta și a spus că lucrurile au mers mai departe. Acest lucru a fost clar făcut acum câțiva ani. Nu a fost total rău intenționat. Atunci probabil că nu ar lua măsuri manuale pentru asta.

Întrebarea 16:43 - Și presupun că probabil că nu puteți răspunde la asta, dar există vreo modalitate prin care... cum ar fi, deci să spunem că nu am primit o acțiune manuală sau nu au primit o acțiune manuală. Pot acele link-uri să-i rănească din punct de vedere algoritmic? Pentru că simțim că vedem unele îmbunătățiri pe unele site-uri, știi, după ce am dezavuat. Deci, din nou, știu că întotdeauna... nu este niciodată alb-negru.

Răspuns 17:03 - Cu siguranță așa poate fi. Deci este ceva în care algoritmii noștri când ne uităm la asta și văd, oh, sunt o grămadă de link-uri foarte proaste aici, atunci poate că vor fi puțin mai precauți în ceea ce privește linkurile în general pentru site-ul web. Deci, dacă curățați asta, atunci algoritmii se uită la asta și spun, oh, există-- există un fel de-- e OK. Nu este rău.

Întrebarea 17:24 - Este totuși bine să dezavuezi doar pentru a preveni o acțiune manuală, corect?

Răspuns 17:29 - Cred că dacă vă aflați într-un caz în care este foarte clar că echipa de spam web vă va oferi o acțiune manuală în funcție de situația actuală, atunci asta aș respinge.

Întrebarea 17:37 - Așa că e bine să gândești ca la Google, cum ar fi cineva din echipa de spam Google doar gândește, cum ar fi, știi, dacă se uită la asta, ce ar face dacă ar face acest lucru?

Răspuns 17:47 - Da.

Întrebarea 17:48 - Problema este însă că majoritatea oamenilor nu știu. Adică, proprietarul obișnuit de afaceri nu știe care legături ar avea echipa de spam web-- Adică, există linii directoare, dar este foarte-- știi, este greu de interpretat. Așa că cred că... vreau să spun, am câteva preocupări, dar principala mea preocupare este că oamenii cheltuiesc tone de bani pe audituri de linkuri despre care cred că nu merită. Pe de altă parte, s-ar putea să nu facem audituri de link-uri și să dezavuim unele site-uri care ar putea beneficia de pe urma. Așa că mi-ar plăcea, știi, cred că ceea ce ai spus a ajutat foarte mult, astfel încât să... știi, asta e bine.

Răspuns 18:22 - Da, cred că pentru marea majoritate a site-urilor au un fel de amestec normal de lucruri în care parcă ai urmat niște sfaturi proaste în trecut și parcă ai trecut mai departe, iar lucrurile sunt destul de naturale acum, atunci chiar nu trebuie să facă asta. Acesta este un fel de obiectiv cu toate acestea și de aceea instrumentul de respingere nu este ca o caracteristică principală în Search Console. Îl cauți în mod explicit. Toate acestea sunt făcute intenționat, deoarece pentru majoritatea site-urilor, chiar nu trebuie să vă concentrați atât de mult pe linkuri. Ceea ce îmi place la instrumentul de dezavuare, totuși, este că, dacă ești îngrijorat de acest lucru, poți să mergi acolo și să spui, OK, știu că există asemenea câteva lucruri pe care le-am făcut câțiva ani. acum, și sunt foarte îngrijorat de asta. Atunci dezavuarea lor, din punctul meu de vedere, nu este o problemă. Nu aș ieși și aș căuta în mod special toate acele lucruri. Dar dacă știi despre asta și ești cu adevărat îngrijorat, atunci poți să ai grijă de asta.

Întrebarea 19:27 - Am o întrebare despre unul dintre site-urile web ale clienților noștri. Deci au club pe... au club în trei orașe din New South Wales. Și fiecare club are un subdomeniu pe site. Acum, când adaugă orice pagină pe site-ul lor, creează pagina pentru fiecare subdomeniu. Deci, recent, au adăugat o pagină, care este despre activitățile clubului lor, și au adăugat această pagină la toate subdomeniile lor. Deci înseamnă că toate subdomeniile au același conținut, cu excepția faptului că titlul paginii este diferit. Pentru că atunci când adaugă la... pentru Sydney, își adaugă numele locației în eticheta de titlu. Când îl adaugă pentru Newcastle, îl adaugă Newcastle în eticheta de titlu, dar restul conținutului de pe pagină este același. Deci va fi o problemă pentru că au 50 de subdomenii și au creat 50 de pagini, care au același conținut, cu excepția titlului?

Răspuns 20:36 - Asta sună ca ceva cam ineficient, cred. Așa că vreau să spun, deja o aduci în discuție și cam zici că asta pare ceva care ar putea fi făcut diferit. Cred că dacă sunteți în cazul în care aveți 50 de subdomenii care au toate același conținut și doar schimbați eticheta de titlu, atunci probabil că nu ne furnizați mult conținut cu adevărat util. Deci, aceasta este situația în care aș spune că este mai logic să combinați lucrurile și să faceți pagini cu adevărat puternice decât să diluați lucrurile în și mai multe subdomenii.

Întrebarea 21:44 - Ce zici de crearea unei pagini și apoi de a utiliza URL-ul canonic către alte pagini de locație. Vreau doar să creez o pagină, despre care vom vorbi despre activitățile lor și voi folosi linkul ca URL canonic către alte pagini de locație.

Răspuns 22:10 - Locație-- da. Cred că ar putea avea sens pentru că atunci combini lucrurile din nou. Atunci faci o pagină puternică, mai degrabă decât o grămadă de pagini diluate.

Întrebarea 22:20 - Pentru că ce se întâmplă atunci când cineva vizitează site-ul web și își alege locația, redirecționează automat acea persoană către acel subdomeniu pentru care a indicat pentru locația lor anume. Deci, acesta este motivul pentru care au nevoie de pagina de pe acel subdomeniu. Deci, cred că de aceea, dacă păstrăm o singură pagină și adăugăm URL-ul canonic, asta are... este singura opțiune pe care o avem în acest moment.

Răspuns 23:08 - OK, dar cred că dacă ai pagini separate pe care trebuie să le ai din motive tehnice pe site și ai pus canonic, e o abordare bună.

Întrebarea 23:21 - Ar fi asta ca... ca și cum o afacere care are mai multe francize în locații diferite care ar avea în esență același conținut pentru fiecare franciză ar fi într-un alt oraș sau localitate, sau orice altceva, și un fel de pâlnie care de la dvs. punct de vedere înapoi la o singură pagină?

Răspuns 23:34 - Cred că este întotdeauna puțin complicat, deoarece echilibrați oamenii care caută acest tip de afacere într-o anumită locație cu un fel de pagină de informare în jurul acelei afaceri în mod direct. Așa că este ceva în care uneori are sens să fie separat pentru o afacere. Uneori este logic să aveți un fel de informații generale într-un loc central și să aveți la fel ca... pagini de destinație ale locației, care sunt mai concentrate pe adresă, orele de deschidere, astfel de lucruri.

Întrebarea 24:12 - Da, am... Am o întrebare legată de punctul canonic pe care l-ați susținut. Aceasta este o întrebare pe care echipa mea și cu mine o avem de câțiva ani. Și încă nu știm exact soluția. Deci, dacă vă ocupați de un mare site de comerț electronic cu multe, multe produse și multe, multe categorii. Să presupunem că vă aflați pe o pagină de categorie care are o mulțime de filtre și fațete diferite și lucruri de această natură care modifică ușor conținutul paginii, dar poate nu suficient pentru a justifica existența propriei adrese URL. Dar poate că, în unele cazuri, cu anumite filtre, justifică a avea o adresă URL a site-ului. Deci, cum te descurci cu crawling în această situație? Ca și cum funcționează o etichetă canonică? Este o soluție generală pentru a crea doar o pagină care este indexată? Sau ar trebui să te uiți, știi, să nu indexezi anumite fațete și filtre sau să folosești roboți, sau cum poți controla asta pentru site-urile mari de comerț electronic?

Răspuns 24:57 - E complicat. Nu cred că avem îndrumări clare în acest sens în acest moment. Deci, acesta este ceva în care toate aceste tipuri diferite de metode pot avea sens. În general, încerc să evit să folosesc robots.txt pentru asta, deoarece ceea ce se poate întâmpla este să găsim URL-urile. Doar că nu știm ce este acolo. Deci, dacă nu vezi cu adevărat probleme care au cauzat prea multă încărcare pe server, încerc să folosesc lucruri precum no index, folosesc rel canonical. Poate că folosiți rel no-follow cu link-uri interne pentru un fel de lucruri pentru a face un pic mai clar ce ar trebui să accesăm cu crawlere un index, mai degrabă decât să folosim robots.txt. Dar un fel de decizie cu privire la momentul în care să combinați lucrurile într-o pagină la nivel de index și când să o blocați de la indexare, când să o ghidați ușor către o adresă URL canonică, asta e-- este foarte dificil uneori.

Întrebarea 25:53 - Pentru că uneori canonicalele sunt ignorate dacă conținutul paginii este prea diferit.

Răspuns 25:57 - Exact. Dacă conținutul este diferit, atunci am putea spune, ei bine, acestea sunt pagini diferite. Nu ar trebui să folosim canonicul. În timp ce ați putea spune, ei bine, acesta este într-adevăr ceva pe care nu vreau să îl indexez. Poate că un no-index ar avea mai mult sens decât un canonic. De asemenea, le puteți combina pe ambele. Nu recomandăm să le combinăm pentru că ne este foarte dificil să spunem, ei bine, ce vrei să spui? Vrei să spui că acestea sunt la fel, dar unul este indexabil și unul nu este indexabil, atunci nu sunt la fel. Dar este ceva în care îmi imaginez că pe parcursul anului va avea niște îndrumări clare cu privire la ceea ce ar putea funcționa acolo. Dar mai ales cu site-uri de comerț electronic cu adevărat mari, partea de crawling poate fi destul de dificilă.

Întrebarea 26:46 - Deci, există un scenariu pe care am încercat să-l rezolv cu câțiva dintre clienții mei în ultima vreme. Încercăm să ne dăm seama de ce nu reușim, în esență, să aruncăm un site nedorit care încă folosește HTTP și care pare mai mult sau mai puțin abandonat, deoarece pagina nu a fost actualizată de ceva timp, iar conținutul este vechi, depășit și în general. cam subțire, așa că am câteva teorii despre asta. O parte din asta este, cred, că poate a fost în index atât de mult încât toți aveți un factor de încredere construit cu ei. And it's kind of hard to unseat them. That's part of my theory on that. So I'm just trying to figure out what's going on because I know HTTPS is a factor. I don't know how much of a factor it can be, but I also think the age might be part of the problem of trying to provide that newer, fresher content that-- in most cases, what we have done over last year is a lot more thorough than what was written, say 10, 12 years ago. So we're trying to figure out why is it taking so long to essentially move ahead of those pages in a lot of cases.

Answer 27:46 - So HTTPS is a ranking factor for us. But it's really kind of a soft ranking factor. It's really a small thing.

Question 27:55 - One of the things I've noticed about when I encounter sites that are still using HTTP is they haven't really-- they haven't been updated, in general, in two or three years, usually. So to me, it's kind of like they've almost been abandoned. To me I'm looking at it as a signal of freshness and stuff like that.

Answer 28:10 - Yeah, I mean, freshness is always an interesting one, because it's something that we don't always use. Because sometimes it makes sense to show people content that has been established. If they're looking at kind of long-term research, then like some of this stuff just hasn't changed for 10, 20 years.

Question 28:30 - I'll give you a pragmatic examples since I'm a web developer. I see pages that were written, say in 2006 or 2007. They haven't actually been changed, but the web standards, web specifications, or just the general way of handling those things has evolved. But that page is still written as if it's 2006. And yet I've got something that's fresher, you know, that's more in depth and things like that, and I'm like at number 11. They're sitting at number four, for example, like, why are they still up there, you know?

Answer 28:59 - Yeah. It's hard to say without looking at the specific cases. But it can really be the case that sometimes we just have content that looks to us like it remains to be relevant. And sometimes this content is relevant for a longer time. I think it's tricky when things have actually moved on, and these pages just have built up so much kind of trust, and links, and all of the kind of other signals over the years, where like, well, it seems like a good reference page. But we don't realize that, actually, other pages have kind of moved on and become kind of more relevant. So I think long-term, we would probably pick that up. But it might take a while.

I don't know if we call it trust or anything crazy like that. It's more-- it feels more like we just have so many signals associated with these pages, and it's not that-- like, if they were to change, they would disappear from rankings. It's more, well, they've been around. They're not doing things clearly wrong or for as long time, and people are maybe still referring to them, still linking to them. Maybe they're kind of misled in kind of linking to them because they don't realize that, actually, the web has moved on. Or maybe, I don't know, a new PHP version came out, and the old content isn't as relevant anymore. But everyone is still linking to, I don't know, version 3 or whatever.

Question 30:42 - But I've also seen that kind of in the health and fitness space as well, you know, like workout types were more popular 10 years ago, but the particular, you know, approach to it isn't necessarily as popular now or been kind of proven to not necessarily be as good. You know, it's just some other general observations I've made too.

Answer 31:06 - Yeah, I think it's always tricky because we do try to find a balance between kind of showing evergreen content that's been around and kind of being seeing more as reference content and kind of the fresher content and especially when we can tell that people are looking for the fresher content. But we'll try to shift that as well. So it's not something that would always be the same.

Question 32:20 - "We have a large e-commerce site that's not in the mobile-first index yet. We know we serve different HTML for the same URL, depending on the user agent. Could this harm us?

Answer 32:38 - So you don't have a ranking bonus for being in the mobile-first index. So it's not that you need to be in there. But it's more a matter of when we can tell that a site is ready for the mobile-first index, then we'll try to shift it over. And at the moment, it's not at the stage where we'd say, we're like flagging sites with problems and telling them to fix things. But more where we're just trying to get up to the current status and say, OK, we've moved all of the sites over that we think are ready for mobile-first indexing. And kind of as a next step, we'll trying to figure out the problems that people are still having and let them know about these issues so that they can resolve them for mobile-first indexing. So it's not that there is any kind of mobile-first indexing bonus that's out there. It's more that we're, step by step, trying to figure out what the actual good criteria should be.

Question 33:40 - Given that the search quality guidelines are an indication of where Google wants its algorithm to go, how does the current algorithm handle measuring the expertise and credibility of publishers?

Answer 33:59 - I don't know. I think that's probably hard to kind of figure out algorithmically. And if there were any kind of technical things that you should do, then we would let you know. So if there are things like authorship markup that we had at some points that we think would be useful for something like this, we would definitely bring that out there. But a lot of things are really more kind of soft quality factors that we try to figure out, and it's not something technical that you're either doing or not doing. It's more, like, trying to figure it out how a user might look at this. So not anything specific that I could point at.

Question 34:44 - Is that reasonable to assume that if something is in the Quality Raters' Guidelines that Google-- I mean, that's what Ben Gomes said, right? That's where the Google wants the algorithm to go. So I mean, we may be guilty putting too much emphasis on the Quality Raters' Guidelines, but it's all good stuff in there, right? So is it reasonable to make that assumption? Like, if it's in there, we should aim for that sort of standard of quality?

Answer 35:09 - I think, in general, it's probably good practice to aim for that. I avoid trying to focus too much on what Google might use as an algorithmic factor and look at it more as-- we think this is good for the web, and, therefore, we will try to kind of go in that direction and do these kind of things. So not so much it's like I'm making a good website just so that I can rank better, but I'm making a good website because when I do show up in search, I want people to have a good experience. And then they'll come back to my website, and maybe they'll buy something. So that's kind of the direction I would see that, not as, like, do this in order to rank, but do this in order to kind of have a healthy, long-term relationship on the web.

Question 36:10 - Is there a particular type of schema that is more likely to obtain featured snippets of voice search results?

Answer 36:18 - I don't know. I can't think of anything offhand. So there is the speakable markup that you can use, which is probably reasonable to-- kind of look into to see where it could make sense on a page. I don't think we'll use that in all locations yet.

Question 36:41 - Is that the goal to us it in more locations?

Answer 36:47 - I believe-- I guess. I mean, it's always a bit tricky because, sometimes, we try them out in one location, and we try to refine it over time. And usually, that means we roll it out in the US, and where we can kind of process the feedback fairly quickly, we can look to see how it works, how sites start implementing it or not. And based on that, we can refine things and say, OK, we're doing this in other countries, and other languages, and taking it from there. But it's not always the case that that happens. Sometimes it happens that we keep it in the US for a couple of years, and then we just said, oh, actually, this didn't pan out the way that we wanted it. So we'll try something new, or we'll give it up. Yeah. But a lot of the structured data types, we do try to roll out in other countries, other languages. I imagine the speakable markup is tricky with regards to the language. So that's something more where we'd say, well, Google Assistant isn't available in these languages. So, like, why do we care what markup is actually used there.

I don't know how many places this system is available yet. Maybe that's everywhere now. But featured snippets, in particular, I don't think we have any type of markup that's specific to that. So that's something where if you have clear kind of structure on the page, that helps us a lot. If we can recognize like tables on a page, then we can pull that out a lot easier. Whereas if you use fancy HTML and CSS to make it look like a table, but it's not actually a table, then that's a lot harder for us to pull out.

Question 38:37 - John, do internal links help with featured snippets if you have an anchor? Sorry, not an internal, like, an anchor like-- do you think that that would help?

Answer 38:48 - I don't know. I do know we sometimes show those anchor links in search as a sub site link-type thing. But I don't know if that would work for featured snippets.

Question 39:04 - Does cross domain site map submissions still work when 301 redirecting to an external sitemap file URL?

Answer 39:16 - Hopefully.

Question 39:17 - What about using meta-refresh? This was something that was recommended by a video hosting company. People said, we'll host the site map on our site, but, you know, the XML file will metarefresh over to our site where all the links are located.

Answer 39:33 - I don't think that would work. So sitemap files are XML files, and we process those kind of directly.

So if you do something that's more like a JavaScript redirect or that uses JavaScript to get us the sitemap content, then that would work. It would really need to be a server-side redirect. What you can also do is use the robots.txt file to specify a sitemap file on a different host. That also confirms to us that actually you told us specifically to use a sitemap file from there. So I probably use something like that more than any kind of a redirect. I imagine the 301 server-side redirect would work. But, no, I don't know, you should be able to see some of that in Search Console too, like, if we're picking the sitemap up in the index composition tool, you can pick the sitemap file, then that's a pretty clear sign that we can process that.

Întrebarea 42:29 - Era vorba despre site-urile agențiilor de turism pentru călătorii. Alegem căutarea internă pentru a afișa conținut dinamic, cum ar fi primele 10 cele mai ieftine hoteluri din orașul de căutare, OK? Deci cadrul paginii se încarcă într-o clipă. Dar primele 10 rezultate ale celor mai ieftine hoteluri se încarcă dinamic în aproximativ 30 de secunde de când a fost efectuată căutarea, deoarece site-ul trebuie să efectueze această căutare în spate și apoi să compare și să rafinească rezultatele pentru a enumera, pentru cel care caută, primele 10 ieftine. hoteluri. Deci este nevoie de puțin timp pentru a le enumera. Deci, acum, Googlebot vede doar fundalul paginii. Apoi, acei 10 substituenți goali au fost unde rezultatele se vor încărca puțin mai târziu, după ce a fost efectuată căutarea internă. Deci, deoarece aceasta este o tendință pentru site-urile web de călătorie de a aduce informații cât mai actuale și cât mai exacte posibil, mă gândesc, ce face Google în acest sens. Desigur, putem enumera conținut static pe aceste pagini, așa cum fac toate celelalte site-uri web în prezent pentru Google, dacă îmi permit să spun așa. Dar acest fel de învinge scopul a ceea ce majoritatea utilizatorilor doresc să vadă acum, proaspăt și ieftin.

Răspuns 44:00 - Deci, dacă nu se încarcă acolo, atunci nu îl putem indexa. Dar, de obicei, aceasta este mai degrabă o chestiune de a nu putea procesa JavaScript sau poate fi blocat să accesăm efectiv conținutul de acolo. Deci este ceva ce poți face într-un mod care să funcționeze. Nu prin design nu ar funcționa niciodată. Deci, acesta este ceva în care puteți săpa în detalii folosind lucruri precum testul de compatibilitate cu dispozitivele mobile pentru a vedea dacă există erori JavaScript implicate, dacă lucrurile sunt blocate și să le rafinați de acolo. Deci nu este imposibil, dar este nevoie de puțină muncă.

Întrebarea 44:42 - John, mă uit la asta pentru a mă asigura că nimic nu este blocat de la Google. Singurul lucru pe care vrem să-l facă Google este să așteptăm puțin până când conținutul dinamic să se încarce în pagini, știi? Acesta este următorul pas, dacă îmi permit să spun așa, deoarece, deși această pagină nu este ca un scroll fără sfârșit, să spunem Facebook, este o pagină limitată de 10 rezultate. Deci este finit. Este limitat. Chestia este că Google ar trebui să aștepte puțin conținutul dinamic. Vă dau doar un exemplu. Dar sunt sigur că există o mulțime de alte exemple în sălbăticie. Și pentru că, deoarece aceasta este tendința ca oamenii să vadă conținut dinamic, deoarece cumva sortează lucrurile și timpul petrec din ce în ce mai puțin - oamenii petrec din ce în ce mai puțin timp pe site-uri web și doresc să găsească cât mai repede posibil rezultate perfecte, dacă pot să spun așa. Mă întrebam dacă vă uitați la această îmbunătățire.

Răspuns 45:55 - Așa că așteptăm puțin pentru randare. Dar dacă oamenii sunt nerăbdători, atunci acesta este un semn că oricum ar trebui să fii mai rapid. Deci asta e ceva în care m-aș analiza oricum. Dar cred că, uitându-mă la captura de ecran, toate articolele de acolo au fost blocate doar în casete gri. Deci, se simte ca ceva care este mai mult o problemă tehnică, mai degrabă decât doar o pauză.

MARTIN SPLITT : Da. Eram pe cale să spun că vedem o mulțime de conținut dinamic care este indexat fără probleme, chiar dacă folosește JavaScript și altele. Deci, dacă expirăm, atunci s-ar putea să aveți o problemă în ceea ce privește durata căutărilor, iar asta s-ar putea reflecta și în altă parte. Așteptăm destul de mult ca conținutul să se termine.

Întrebarea 46:48 - Poți... îmi poți da un interval de timp? Cât aștepți?

MARTIN SPLITT : Este foarte, foarte complicat pentru că practic... deci, motivul pentru care nu vă putem oferi un interval de timp este pentru că timpul... și asta o să sune foarte ciudat și suportați-mă pentru o secundă. . Timpul în redarea Googlebots este special și nu urmează neapărat principiile lui Einstein. [Râsete] Deci nu pot spune prea multe. Ceea ce pot spune este că dacă rețeaua este ocupată și rețeaua este blocajul, probabil că așteptăm, dar așteptăm doar atât de mult. Așadar, dacă îți ia cam un minut sau 30 de secunde, atunci probabil că vom opri între ele. Dar nu este greu... dacă îți spun 10 secunde, s-ar putea să funcționeze sau nu. Dacă îți spun 30 de secunde, s-ar putea să funcționeze sau nu. Așa că prefer să nu spun un număr. Ceea ce aș spune, încercați să o introduceți cât de repede puteți. Și dacă nu puteți obține rapid, atunci încercați ceva de genul ca memorarea rezultatelor căutării, astfel încât căutarea să devină mai mult sau mai puțin în-- sau producerea rezultatelor pe pagină devine din ce în ce mai mult-- mai mult sau mai puțin instantanee. Sau încercați redarea dinamică de partea dvs., care ar putea fi o soluție pentru aceasta. Ceea ce puteți încerca, de asemenea, este că puteți încerca să-l puneți pe partea de server și, practic, să încercați să generați cât mai mult conținut posibil în prima trecere. Acesta este ceva de care beneficiază și utilizatorii, mai ales dacă aceștia se află pe rețele lente. Deci da. Îmi pare rău, nu am un răspuns simplu, dar timpul în Googlebot este ciudat.

Răspuns 49:29 - Cred că probabil depinde de ceea ce face site-ul web. Unul dintre lucrurile dificile cu viteza de randare este că putem stoca în cache o mulțime de lucruri care sunt trimise de la un server mai mult decât ar fi într-un browser, deoarece ne putem folosi indexul pentru multe dintre aceste lucruri. Deci, uneori, dacă JavaScript este stocat în cache de partea noastră, nu trebuie să-l preluam. Apoi, dacă comparați din nou timpii, atunci nu se va potrivi cu ceea ce vede un utilizator. Nu se va potrivi cu ceea ce vezi pe webpagetest.org. Deci este destul de complicat și pentru părțile în care știm că durează mai mult, vom fi puțin mai răbdători. Dar este dificil de testat. De aceea, avem acum toate aceste instrumente de testare care arată cât mai multe erori posibil pentru a face posibil să ne dăm seama, cum ar fi, nu funcționează deloc? Uneori funcționează și unde sunt uneori problemele care apar?

Întrebarea 50:29 - Pentru site-urile web foarte mari, contează ordinea URL-urilor în hărțile de site XML?

Răspuns 50:34 - Nu. Nu ne interesează. Este un fișier XML. Atragem toate datele. Procesăm totul deodată.

Întrebarea 50:44 - Atunci cum rămâne cu parametrul de prioritate din hărțile site-ului?

Răspuns 50:47 - Nu folosim deloc asta. Deci, la început, ne-am gândit că asta ar putea fi util pentru a ne da seama cât de des ar trebui să accesăm paginile cu crawlere. Dar se dovedește că, dacă îi întrebi pe webmasteri, ei spun că totul este prioritar. Este cel mai important. Și la fel, cred, frecvența schimbărilor în sitemap-urile, unde observăm, de asemenea, că oamenii ne spun că lucrurile se schimbă tot timpul, dar ultima actualizare a fost anul trecut. Deci, dacă aveți frecvența modificării și data, atunci vom obține informațiile respective de la dată oricum. Deci ignorăm frecvența schimbării.
Întrebarea 51:35 - Ar trebui adăugată schema corporativă doar la pagina principală, pagina de contact sau la toate paginile?

Răspuns 51:42 - Din câte știu eu, este doar pagina de pornire. Nu știu. Știți vreunul dintre voi?

Răspuns de la Liz 51:4 7 - Ar trebui să fie doar o pagină, de obicei cu organizație și corporație. Asta este in general recomandarea.

MARTIN SPLITT 52:00 - Bănuiesc că nu contează care... nu contează la fel de mult ce pagini, la fel cum nu o puneți pe fiecare pagină pe care o aveți, cred că este partea mai importantă. Cred că depinde de... dacă sunteți un site de știri, probabil că are sens să îl puneți în pagina de contact, sau în pagina despre, sau așa ceva. În timp ce într-un site web de magazin sau restaurant, probabil că este OK să îl puneți pe pagina de pornire.

IOAN 52:20 - Cred că, de asemenea, în acest caz, nu contează atât de mult pentru noi pentru că trebuie să-l putem găsi undeva, cum ar fi pagina de start sau pagina de contact. Dar dacă îl avem în altă parte, nu ne schimbă nimic. Deci, cel mai important lucru cu care să nu-l comparăm este marcajul pentru recenzii, unde vedem uneori oameni care pun o recenzie ca o companie pe toate paginile site-ului, cu speranța de a obține stelele și rezultatele căutării pentru fiecare pagină de pe site-ul lor. Și asta ar fi rău pentru noi. Dar informațiile de contact, dacă le aveți marcate, sunt... Nu văd nicio problemă cu asta.
Întrebarea 53:05 - Testul de viteză a site-ului Google pe care l-am folosit a înregistrat timpi de încărcare a paginii foarte lenți, dar testele independente pe care le-am făcut cu colegii de peste mări au afișat un timp de încărcare a paginii foarte rapid. Măsurile Google de înregistrare falsă afectează modul în care site-ul nostru este clasat în algoritmul Google?

Marie Haynes: Nu este întrebarea mea, dar pentru a da un context, noile date Lighthouse pentru viteza paginii sunt mult mai dure decât obișnuia să fie Page Speed ​​Insights. Deci ceva care a avut un scor de 80 pe Page Speed ​​Insights ar putea fi un 29 roșu pe Lighthouse. Deci asta e o întrebare bună. Este posibil ca asta să cauzeze... pentru că știm că pe dispozitive mobile, site-urile foarte lente ar putea fi retrogradate. Deci, este bine să spunem, știi, dacă ești în roșu la testul Lighthouse, că ar trebui să îmbunătățim lucrurile pentru că ar putea provoca o retrogradare sau există o întrerupere?

Răspuns 54:07 - Deci nu avem o mapare unu-la-unu a instrumentelor externe și a tot ceea ce folosim pentru social. Da, este foarte greu de spus, dar în căutare, încercăm să folosim o combinație de date reale, ce sunt, teste de laborator, care este un fel ca testul Lighthouse și datele din raportul Chrome UX, unde în esență ce Măsurăm ceea ce ar vedea utilizatorii site-ului web.

MARTIN SPLITT 55:37 - De asemenea, este important să vedem că Lighthouse, de exemplu, măsoară în mod specific pentru o conexiune 3G la capătul median - sau ca un telefon de performanță medie, da. Deci, practic, dacă utilizați un Apple McIntosh recent sau un computer recent cu Windows rapid, cu o conexiune foarte bună, cum ar fi prin cablu, sau o conexiune Wi-Fi foarte bună în biroul dvs., desigur, vedeți un timp de încărcare de două secunde, dar un utilizator real cu telefonul în sălbăticie probabil că nu vede asta. Deci, este unul dintre aceste cazuri ca și cum nu strica niciodată să vă faceți site-ul mai rapid, dar acest lucru este foarte, foarte greu de spus cum ar arăta din perspectivă interioară, deoarece folosim valori foarte specifice care nu sunt neapărat să mapeze unul cu unul la ceea ce expun instrumentele....desigur că este important să remediați asta, pentru că nu doriți ca utilizatorii să aștepte pe site-ul dvs. pentru totdeauna. Asta te va răni. Asta va răni utilizatorii tăi. Asta o să te doară în căutare. Dar nu plătesc... Aș spune că uită-te la instrumente. Dacă instrumentele vă spun că vă descurcați bine, atunci nu ar trebui să vă faceți griji prea mult pentru asta. Dacă instrumentele vă spun că nu vă descurcați bine, atunci cred că timpul petrecut pentru a afla de ce spune... de exemplu, dacă ceea ce spune este relevant, este irosit. Ar trebui mai degrabă să te uiți la a face site-ul mai rapid.

Performanța mobilă este un factor foarte important pentru utilizatorii dvs., precum și pentru orice altceva. Așadar, aș spune că asigurați-vă că site-ul dvs. are performanțe bune în condițiile din lumea reală. Poate chiar să-mi iau un telefon ieftin și să încerc site-ul din când în când, și dacă... asta e ceva ce îmi place să fac și obișnuiam să fac înainte de a mă alătura Google cu echipa de dezvoltare cu care lucram. Am fost, uite, vrei să folosești acest site pe acest telefon? Era ca și cum, oh, asta e oribil. Sunt ca, mhm, da, așa că poate ar trebui să facem ceva în privința asta.

JOHN - În Chrome, îl puteți configura și încerca diferite viteze de conectare. Emulator mobil. Cred că sunt lucruri foarte bune la care să te uiți și, de asemenea, să te uiți la baza ta de utilizatori. Uitați-vă la datele dvs. de analiză dacă observați că oamenii vă folosesc site-ul web doar cu un iPhone de ultimă generație, atunci poate că este o problemă mai mică decât dacă observați că oamenii se conectează la site-ul dvs. din conexiuni rurale aleatorii, care sunt lent și au dispozitive low-end, atunci poate că e mai mult.