8 martie 2019 – Google Help Hangout Notes

Săptămâna aceasta, John răspunde la câteva întrebări grozave referitoare la Viteza paginii, Anchor Text, Java Script. Ca întotdeauna, videoclipul complet și transcrierea pot fi găsite mai jos!

Cum este tratat conținutul tradus?

0:33

Cred că este bine să ai un site web combinat ca acesta. Cred că pentru utilizatori este logic să o faceți astfel încât să fie ușor de citit pentru ei, astfel încât, dacă sunteți vorbitor de engleză și accesați site-ul dvs. web, să nu fie ca o combinație de conținut în rusă, ucraineană și engleză, ci mai degrabă acesta este tot conținutul în limba engleză. S-ar putea să nu fie tot conținutul pe care îl aveți în diferite limbi, dar este bine. Din punct de vedere SEO, are sens să transformăm traducerile în conținut de înaltă calitate. Deci nu doar folosind Google Translate pentru asta. Instrumentele de traducere sunt încă din ce în ce mai bune pentru asta, dar dacă îl traduceți manual sau luați versiunea google translate și o curățați și o faceți mai lizibilă, atunci este mai bine. Este ceva pe care utilizatorii îl observă și asta este, de asemenea, ceva pe care îl observăm din punct de vedere algoritmic. Dacă putem spune că acesta este un conținut de înaltă calitate, atunci îl vom trata mai bine în rezultatele căutării.

Rezumat: asigurați-vă că conținutul dvs. tradus poate fi citit în alte limbi și nu doar tradus automat cu Google Translate. De asemenea, asigurați-vă că traducerile sunt de înaltă calitate și au valoare pentru utilizatori.

Dacă site-ul meu rulează pe Javascript și timpul de indexare este critic pentru conținut, cum îmi pot da seama că va dura să fie indexat?

3:10

Deci, în general, prima parte este corectă. Este cazul că încercăm să indexăm conținutul cât mai repede posibil, ceea ce putem dacă avem o versiune HTML statică, iar apoi următorul pas este să încercăm să redăm pagina așa cum ar face un browser și alegem și acel conținut și folosiți-l pentru indexare. Cele două lucruri combinate funcționează în general împreună, dar nu este cazul ca versiunea HTML statică să fie amânată (artificial) până când versiunea javascript este gata. Deci, din acest punct de vedere, pentru majoritatea site-urilor nu este esențial să existe această diferență și nu avem niciun timp explicit care să se aplice timpului necesar pentru a începe redarea unei pagini. Acest lucru poate diferi în funcție de tipul de pagină, când am găsit-o, cum am găsit-o, ce se întâmplă în jurul acelei pagini. De exemplu, dacă credem că acesta este ceva care se afișează foarte repede în căutare, atunci vom încerca să îl redăm imediat. Deci este cam greu de luat în considerare. Nu există un număr fix acolo. În general, aș folosi acest lucru ca un ghid aproximativ pentru a determina dacă trebuie să faceți ceva cu conținutul javascript de partea clientului. De exemplu, dacă aveți conținut de știri care trebuie indexat rapid, atunci m-aș asigura că Google poate prelua acel conținut cât mai repede posibil, fără a fi nevoie să redeze acel conținut separat. Pentru site-urile de știri, în special pe paginile de peste site-uri de știri unde faci link la toate articolele noi, m-aș asigura că acele pagini funcționează bine doar cu HTML static oferit motoarele de căutare. Așa că așa m-aș gândi la asta, gândește-te cât de critic este ca conținutul meu să fie indexat imediat și nu în termeni de câte minute durează, deoarece nu există un timp fix pentru cât timp poate dura.

Rezumat : pentru site-urile javascript, Google Firsts indexează pagina și apoi are nevoie de timp pentru a procesa javascript. Nu există un timp fix cu privire la cât timp durează. Deci, dacă conținutul dvs. are nevoie de actualizare frecventă, este mai bine să difuzați o versiune HTML statică a paginii.

Care sunt principalele diferențe față de instrumentul de inspecție a adreselor URL și testul pentru dispozitive mobile, dacă ambele preiau pagini de pe serverul live?

9:16

Deci, ideea testului de compatibilitate cu dispozitivele mobile este doar de a testa dacă această versiune este prietenă cu dispozitivele mobile, așa că acesta este un fel de obiectiv principal. Și instrumentul de inspecție a adreselor URL, instrumentul de testare live, este destinat mai mult pentru a vedea „cum ar fi această pagină în indexare?”, verifică lucruri, cred, cum ar fi codul de răspuns fără index, un fel de lucruri obișnuite care s-ar aplica. pentru dacă luăm această pagină și o punem în indexul nostru sau nu. Testul de compatibilitate cu dispozitivele mobile se concentrează în principal pe partea mobilă, iar instrumentul de inspectare a adreselor URL este ca acest cuțit mare de buzunar cu diferite caracteristici pe care le puteți folosi pentru diferite lucruri.

Rezumat : testul de compatibilitate cu dispozitivele mobile este de a vedea cât de bine s-ar descurca site-ul pe mobil, în timp ce instrumentul de inspecție a adreselor URL verifică dacă indexarea funcționează așa cum ar trebui, ca și cum nu există coduri de răspuns la index.

Mă gândesc să-mi împart paginile de produse pe site-ul meu de comerț electronic. În prezent, acestea sunt configurabile pe o singură pagină, cu mai multe variante afișate. Care sunt recomandarile tale?

18:00

Cred că aspectul pe care l-aș analiza mai mult este dacă are sens să împărțim acele produse în pagini separate, deoarece ceea ce faci schimb este o pagină de produs care este destul de puternică pentru acel produs și toate variantele, comparativ cu mai multe pagini care trebuie să lucreze singuri și să fie sprijiniți pe cont propriu. Deci, în loc să ai o pagină foarte puternică pentru „pantofi de alergat”, ai mai multe pagini care trebuie să se lupte cu „pantofi de alergat albaștri”, „pantofi de alergat roșii”, „pantofi de alergare verzi”. Deci, dacă cineva caută „pantofi de alergare”, atunci aceste pagini mici nu sunt într-adevăr la fel de puternice ca pagina de produs pe care o ai pentru acel produs principal. Deci, sfatul meu general este de a spune, dacă credeți că aceste variații sunt doar atribute ale produselor principale, în sensul că oamenii tind să caute conținutul principal și apoi să spună „oh ce culoare vreau, parcă am găsit produsul Vreau, dar trebuie doar să aleg culoarea pe care o vreau.” apoi le-aș pune pe o pagină partajată. În timp ce oamenii caută în mod explicit acea variație și acea variație este într-adevăr unică și iese în evidență de la sine, iar oamenii nu vin pe site-ul tău doar spunând „Vreau pantofi de alergat”, ci mai degrabă „Vreau acest tip specific de alergare pantofi în această culoare”, atunci acesta este ceva care poate merită scos ca produs separat.

Rezumat : cu excepția cazului în care variațiile de produs ies în evidență pe cont propriu și oamenii ar căuta acea variație specifică decât este mai bine să le păstrați pe toate pe o singură pagină puternică. În acest fel, diferitele variante ale paginilor de produse nu concurează între ele.

Este viteza importantă pentru versiunea mobilă a site-ului dvs.?

21:00

Deci partea bună este că avem o mulțime de factori de clasare, așa că nu trebuie să faci întotdeauna totul perfect. Dar asta înseamnă și că te confrunți cu situații ca aceasta în care spui „Google spune că viteza este importantă, dar site-ul de top aici nu este atât de rapid, așa că nu trebuie să fie important”. Pentru noi este cu siguranță important, dar asta nu înseamnă că trece peste orice altceva. Vă puteți imagina că cea mai rapidă pagină la care v-ați putea gândi este probabil o pagină goală. Dar o pagină goală ar fi un rezultat de căutare cu adevărat groaznic dacă ai căuta ceva cu adevărat specific. Este foarte rapid, dar nu există conținut acolo, așa că utilizatorul nu ar fi mulțumit. Deci trebuie să echilibrăm toți acești factori, conținutul, linkurile și toate aceste semnale și să încercăm să ne dăm seama cum să facem clasamentul pe baza acestui amestec de diferiți factori pe care îl avem. Și face schimbări în timp, se poate schimba destul de repede. De exemplu, dacă ceva este cu adevărat demn de știri în acest moment, atunci putem alege să arătăm site-uri ușor diferite, ceva care este mai mult un subiect de cercetare, veșnic verde.

Rezumat : Viteza este doar unul dintre factorii de clasare pe care îi folosește Google. Doar pentru că site-urile de top ar putea să nu fie rapide, nu înseamnă că nu este important pentru site-ul tău.

Ce tip de markup de schemă este de preferat pentru Google, dacă folosim JSON sau micro-date, microformate. Care este de preferat?

22:30

În prezent, preferăm marcajul JSON-LD. Cred că majoritatea noilor tipuri de date structurate apar mai întâi pentru JSON-LD, așa că asta preferăm.

Rezumat: JSON-LD este preferat de Google.

Cât de important este Anchor Text?

25:10

Așa că, în primul rând, cred că nu mi-aș face prea multe griji cu privire la brevetele Google, brevetăm o mulțime de lucruri care nu se aplică neapărat la ceea ce trebuie să facă maeștrii web. Așa că cred că este interesant să văd că inginerii noștri lucrează, dar asta nu înseamnă neapărat că vom fi afectați de asta imediat. În ceea ce privește textul ancorat în general, îl folosim pentru text. Este ceva pe care noi îl luăm. Este o modalitate excelentă de a ne oferi context despre un link. În special pe site-ul dvs., dacă aveți un link care spune doar „click aici pentru mai multe informații”, nu ne este foarte util. În cazul în care aveți un link care spune „puteți găsi mai multe informații pe această pagină de produs” și un link cu acel nume al produsului respectiv la pagina respectivă, atunci care ne spune că poate această pagină este într-adevăr despre acest produs. Așa că, cu siguranță, aș continua să mă uit la textul de ancorare pe care îl utilizați, în special în interiorul site-ului dvs. web și aș încerca să mă asigur că furnizați text de ancorare care este cu adevărat util și oferă context la ceea ce este legat pe pagină.

Rezumat: Anchor Text este foarte important, deoarece oferă context pentru Google despre ce este pagina. Textul de ancorare precum „Faceți clic aici pentru mai multe informații” nu oferă Google multe informații, dar Textul de ancorare precum „Puteți găsi mai multe informații despre această pagină de produs” îi spune Google că această pagină este despre această pagină de produs.

Nota noastră: dacă vă creați propriile link-uri, dacă aveți prea multe link-uri la cuvinte cheie, este posibil să dezvăluiți echipa de spam web în cazul în care primiți o examinare manuală.

Cum vede Google vizual pagina ta?

39:00

Încercăm să privim pagina în mod vizual, dar mai ales în ceea ce privește conținutul real de deasupra pliului sau spațiul de deasupra paginii este doar un anunț uriaș. Cam pe asta ne concentrăm, de asemenea, în ceea ce privește compatibilitatea cu dispozitivele mobile, încercăm să cartografiam vizual o pagină și să vedem dacă aceasta este o pagină care ar funcționa bine pe un dispozitiv mobil. Și pentru asta trebuie să cartografiam pagina, e ok dacă unele elemente sunt ilizibile atâta timp cât funcționează pe un dispozitiv mobil. Dacă acele linkuri sunt acolo, au dimensiunea potrivită și oamenii pot face clic pe ele, atunci este perfect. Dacă faceți o transformare CSS de lux pentru a transforma acest lucru în text 3d, asta depinde în totalitate de dvs. Partea importantă este că textul în sine este vizibil pe pagină și că nu faceți prea multe markupuri elegante pentru a împărți acel text. Deci, de exemplu, dacă aveți un titlu în vechiul sistem în care aveți un aspect bazat pe tabel și doriți să împărțiți vindecarea deasupra, se pare că oamenii pun litere individuale în celule individuale de tabel și, din punctul nostru de vedere, acest lucru face este aproape imposibil să vezi că acesta este de fapt un cuvânt, deoarece folosești markup pentru a-l împărți în bucăți deconectate. Din punctul de vedere al analizei paginii, este foarte dificil.

Rezumat: Google încearcă în mare parte să vadă dacă conținutul real este deasupra pliului și nu doar un anunț uriaș. În ceea ce privește compatibilitatea cu dispozitivele mobile, Google încearcă să înțeleagă dacă există aceleași link-uri, totul are dimensiunea potrivită și dacă oamenii pot face clic pe acele link-uri. Cel mai important este dacă textul în sine este vizibil pe pagină.

Puteți schimba o adresă URL cu Javascript?

43:00

Da, o putem ridica. Partea importantă cred că este că adresa URL trebuie schimbată după ce pagina este încărcată. Nu ar trebui să fie schimbat atunci când un utilizator face o anumită acțiune. Deci, de exemplu, dacă un utilizator trece cu mouse-ul peste un link și apoi utilizați JavaScript pentru a schimba adresa URL, ceea ce nu ar fi ceva ce am observa sau dacă un utilizator face clic pe un link și apoi utilizați JavaScript pentru a schimba adresa URL, atunci asta de asemenea, nu ar fi ceva ce am observa. Dar dacă pagina se încarcă și apoi executați niște JavaScript care curăță URL-ul, astfel încât acestea să trimită la versiunile canonice adecvate, este perfect bine și cam așa cum am vorbit la început când vine vorba de randare, uneori, acest lucru durează puțin. timp. Deci, nu este un lucru imediat să luăm am putea sau este probabil să luăm ambele versiuni atât linkul original pe care îl aveați acolo, cât și versiunea JavaScript. Deci nu ar fi ca vechile versiuni să dispară complet.

Rezumat : Google poate prelua dacă o adresă URL a fost schimbată după încărcarea unei pagini. Singurul lucru de care trebuie să fii conștient este să te asiguri că adresa URL nu este schimbată atunci când un utilizator efectuează o anumită acțiune.

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.

Întrebarea 0:33 - Întrebare despre traducere. Știu că dacă traduc conținut din engleză în rusă sau ucraineană, iar majoritatea oamenilor folosesc doar traducerea Google și doar pun conținutul. Dar se pare că 90% din ele necesită o corecție dacă îl citești ca vorbitor nativ. Ma intereseaza doua puncte. Dacă vreau să fac o altă versiune sau altă limbă pe site-ul meu, cum ar fi engleza, rusă sau ucraineană, este bine? În al doilea rând, găsesc un articol interesant despre nișa mea și vreau să-l traduc, este bun sau nu? Trebuie să-l fac adaptabil pentru cititorii autohtoni?

Răspuns 1:38 - Cred că este bine să ai un site web combinat ca acesta. Cred că pentru utilizatori este logic să o faceți astfel încât să fie ușor de citit pentru ei, astfel încât, dacă sunteți vorbitor de engleză și accesați site-ul dvs. web, să nu fie ca o combinație de conținut în rusă, ucraineană și engleză, ci mai degrabă acesta este tot conținutul în limba engleză. S-ar putea să nu fie tot conținutul pe care îl aveți în diferite limbi, dar este bine. Din punct de vedere SEO, are sens să transformăm traducerile în conținut de înaltă calitate. Deci nu doar folosind Google Translate pentru asta. Instrumentele de traducere sunt încă din ce în ce mai bune pentru asta, dar dacă îl traduceți manual sau luați versiunea google translate și o curățați și o faceți mai lizibilă, atunci este mai bine. Este ceva pe care utilizatorii îl observă și asta este, de asemenea, ceva pe care îl observăm din punct de vedere algoritmic. Dacă putem spune că acesta este un conținut de înaltă calitate, atunci îl vom trata mai bine în rezultatele căutării.

Întrebarea 3:10 - Google accesează cu crawlere și indexează conținutul în doi pași. În primul rând este redarea pe partea serverului și în al doilea rând este redarea pe partea clientului, conform declarațiilor anterioare, poate dura zile sau săptămâni pentru ca acest proces să fie finalizat. Pentru site-urile care utilizează Javascript, acestea pot întâmpina probleme serioase dacă indexarea este critică în timp. Cum pot spune cât timp va dura?

Răspuns 3:46 - Deci, în general, prima parte este corectă. Este cazul că încercăm să indexăm conținutul cât mai repede posibil, ceea ce putem dacă avem o versiune HTML statică, iar apoi următorul pas este să încercăm să redăm pagina așa cum ar face un browser și alegem și acel conținut și folosiți-l pentru indexare. Cele două lucruri combinate funcționează în general împreună, dar nu este cazul ca versiunea HTML statică să fie amânată (artificial) până când versiunea javascript este gata. Deci, din acest punct de vedere, pentru majoritatea site-urilor nu este esențial să existe această diferență și nu avem niciun timp explicit care să se aplice timpului necesar pentru a începe redarea unei pagini. Acest lucru poate diferi în funcție de tipul de pagină, când am găsit-o, cum am găsit-o, ce se întâmplă în jurul acelei pagini. De exemplu, dacă credem că acesta este ceva care se afișează foarte repede în căutare, atunci vom încerca să îl redăm imediat. Deci este cam greu de luat în considerare. Nu există un număr fix acolo. În general, aș folosi acest lucru ca un ghid aproximativ pentru a determina dacă trebuie să faceți ceva cu conținutul javascript de partea clientului. De exemplu, dacă aveți conținut de știri care trebuie indexat rapid, atunci m-aș asigura că Google poate prelua acel conținut cât mai repede posibil, fără a fi nevoie să redeze acel conținut separat. Pentru site-urile de știri, în special pe paginile de peste site-uri de știri unde faci link la toate articolele noi, m-aș asigura că acele pagini funcționează bine doar cu HTML static oferit motoarele de căutare. Așa că așa m-aș gândi la asta, gândește-te cât de critic este ca conținutul meu să fie indexat imediat și nu în termeni de câte minute durează, deoarece nu există un timp fix pentru cât timp poate dura.

Întrebarea 6:17 - Și acum avem o întrebare lungă uriașă despre înțelegerea tipului de semnalare în consola de căutare, atunci când semnalăm ceva ca „duplicat Google alege un alt canonic decât utilizatorul” sau „duplicat adresa URL trimisă și nu selectată ca probleme canonice .

[Utilizatorul sună în] Este o pagină Javascript. Este pre-redat, tot conținutul este în HTML static și totuși Google încă încearcă să execute pagina. Și descoperim în acest mediu de comerț electronic că aceste pagini de produse unice cu descrieri unice și conținut semnificativ sunt semnalate ca Google ca conținut duplicat. Presupunem că acest lucru se datorează unui fel de eșec de redare JavaScript, în care Googlebot continuă să vadă aceeași pagină de eroare sau ceva de genul acesta și, prin urmare, crede că sunt duplicate - cum putem înțelege ce înseamnă serviciul de redare web cu asta ar putea avea ca rezultat conținutul care pare duplicat pentru robotul Google.

Răspuns 7:43 - Ar trebui să mă uit la câteva exemple reale, așa că dacă ai putea să-mi trimiți câteva exemple care mi-ar fi cu adevărat utile.

Întrebarea 8:00 - Este Google conștient de o problemă în curs?

Răspuns 8:00 - Nu... Am auzit de la unele site-uri care s-au plâns de acest lucru mai mult decât altele, așa că dacă trimiteți câteva exemple, ar fi util.

Întrebarea 8:24 - Dacă o adresă URL este semnalată, există oricum ceva despre redarea care s-a întâmplat în momentul analizei respective. Există oricum pentru a vedea erorile de încărcare a resurselor care au apărut într-unul care a fost indexat? Nu aveți acea interfață în consola de căutare, sau cel puțin eu nu pot ajunge la ea. Și sau există vreun loc în care putem vedea cum arată de fapt conținutul în momentul în care indexatorul și/sau instrumentul de detectare a duplicatelor îl examinează

Răspuns 8:41 - Momentan nu. Este ceva care ar avea foarte mult sens. Pentru majoritatea site-urilor nu este critic. Dar într-un caz ca acesta ar fi util să avem.

Întrebarea 9.16 - Următoarea întrebare. Test de compatibilitate cu dispozitivele mobile. L-ați referit de câteva ori pentru a înțelege modul în care indexatorul ar vedea conținutul. Cu toate acestea, constatăm că există o mulțime de alte erori etichetate în încărcarea resurselor și rata la care apar acele erori pare să varieze de la un domeniu la altul. Deci, prima întrebare, sunt erorile pe care le vedem în testul de compatibilitate cu dispozitivele mobile reprezentative pentru erorile pe care le-ar întâlni serviciul în timpul indexării? Sau există diferite alocări de resurse pentru testul MF?

Răspuns 10:04 - Deci cred că vă referiți în mod special la resursele încorporate care sunt extrase pentru test, nu? Ca fișierele JS CSS răspunsuri diferite așa ceva? Cred că unul dintre aspectele este un pic complicat în acest moment în sensul că avem priorități diferite pentru testul de compatibilitate cu dispozitivele mobile față de botul Google normal. Încercăm să extragem resurse cât mai repede posibil de pe serverul live și în timpul indexării stocăm în cache o mulțime de resurse și luăm doar versiunea stocată în cache a paginii. Deci, ceea ce ați putea vedea în testul de compatibilitate cu dispozitivele mobile este că încercăm să redăm această pagină cât mai repede posibil și putem obține o mulțime de aceste resurse, dar pentru unele dintre ele, în esență, expirăm, în esență, cu capacitatea de a extrage acest lucru live de la server-ul. Deci, acestea sunt în mare parte unele dintre erorile pe care le vedeți cu testul de compatibilitate cu dispozitivele mobile. De asemenea, cred că, în instrumentul de inspectare URL, dacă utilizați un test live, încercăm să tragem totul live și, uneori, pur și simplu nu este posibil să o facem live. Și pentru indexare avem mult mai mult, puțin mai mult timp, pe care îl avem disponibil pentru asta. Deci, dacă vedem că aceste resurse sunt necesare, le vom extrage, le vom stoca în cache și vom încerca să le avem disponibile pentru când vom încerca să facem randarea. Deci, acesta este ceva în care nu trebuie să facem nimic live, așa că dacă va dura puțin mai mult pentru a face asta, vom avea răbdare și vom aștepta ca toate acestea să vină împreună. Există încă un aspect al timpului, care este că aceste resurse sunt toate de așa natură încât nu le putem stoca în cache (de exemplu, ID-ul sesiunii și toate URL-urile JS), iar asta ne face să păstrăm o versiune în cache și reutilizați-l mai târziu, atunci acestea sunt cele pe care nu știu, din orice motiv, să nu le putem prelua pentru indexare. Pe scurt, cred că este dificil să diagnosticați probleme de genul acesta, mai ales dacă aveți o mulțime de resurse încorporate. Îndrumările pe care le primesc în general de la echipa de ingineri sunt că ar trebui să le spunem oamenilor să aibă mai puține resurse încorporate și să nu se confrunte cu această problemă. Nu este întotdeauna atât de ușor, deci, dar, în general, ceea ce aș face este să iau testul de compatibilitate cu dispozitivele mobile ca un ghid aproximativ, așa că dacă funcționează în MTF, atunci cu siguranță sunteți în siguranță. Dacă observați că alte lucruri expiră cu această altă eroare, atunci în cea mai mare parte le putem folosi în continuare pentru indexare.

Întrebarea 12:57 - Ați atins-o. Cred că, în mod tangenţial, ar trebui să fim conștienți de vreun timeout greu sau arbitrar la randare de către serviciul de redare web. Există vreo claritate cu privire la conținutul care este utilizat de fapt dacă o pagină durează mult timp pentru a fi redată de Googlebot în serviciul de redare. Pur și simplu renunță și folosește conținutul html al paginii care era acolo inițial? Avem vreo claritate cu privire la cât de departe poți ajunge în procesul de randare?

Răspuns 13:45 - în cea mai mare parte, dacă ceva se întrerupe sau expiră, facem doar un instantaneu atunci și acolo. Așa că da... Cred că în cazul tău, dacă pre-rendați conținutul, atunci nu ar trebui să existe o problemă acolo, deoarece conținutul este acolo. Ceea ce vedem uneori cu site-urile de comerț electronic sau cu site-uri care folosesc un cadru foarte modelat este că ne confruntăm cu situații în care presupunem că există conținut duplicat înainte de a testa cu adevărat adresele URL. Deci, acest lucru se poate întâmpla dacă, de exemplu, vedem un model de adresă URL. Dacă accesăm o grămadă de adrese URL cu modele diferite acolo sau parametri diferiți, de exemplu, și vedem că toate aceste adrese URL conduc la același conținut, atunci sistemul nostru ar putea spune „ok, bine, acest parametru nu este atât de relevant pentru site-ul web după toate” și avem tendința de a renunța la acele adrese URL și am spune „acest set de adrese URL este probabil același cu celălalt set de adrese URL pe care l-am accesat deja cu crawlere. Deci, în special, dacă aveți lucruri undeva, să vedem, un exemplu pe care l-am văzut destul de mult este dacă aveți destul de multe site-uri web de comerț electronic diferite și toate vând aceleași produse - deci întreaga cale după partea de produs a URL-urile sunt aceleași într-un număr mare de domenii - atunci sistemul nostru va spune „toate aceste adrese URL sunt la fel, toate duc la același produs”, așa că, prin urmare, ar fi bine să indexăm doar unul dintre aceste domenii în loc de toate dintre aceste domenii. Nu știu dacă acest lucru s-ar aplica în cazul dvs., așa că nu știu dacă este util, dar este unul dintre acele lucruri în care sistemele noastre încearcă să optimizeze pentru ceea ce găsim pe web și presupunem că alte persoane greșeli și pe web și încercăm să rezolvăm asta. Vedem „toți acești oameni creează duplicate, dar nu trebuie să accesăm cu crawlere toate aceste duplicate”, astfel încât să ne putem concentra pe ceea ce credem că sunt adresele URL reale.

Întrebarea 16:22 - Pentru a prelua testul de compatibilitate cu dispozitivele mobile și testul live pe instrumentul de inspecție a adreselor URL. La testul de compatibilitate cu dispozitivele mobile, Googlebot încearcă să preia o pagină de pe serverul live, deci prin ce diferă de instrumentul de inspecție a adreselor URL cu această funcție? Cum este diferit redarea sau preluarea paginilor și a resurselor

Răspuns 17:04 - Deci, ideea cu testul de compatibilitate cu dispozitivele mobile este doar de a testa dacă această versiune este prietenă pentru mobil, așa că acesta este un fel de obiectiv principal. Și instrumentul de inspecție a adreselor URL, instrumentul de testare live, este destinat mai mult pentru a vedea „cum ar fi această pagină în indexare?”, verifică lucruri, cred, cum ar fi codul de răspuns fără index, un fel de lucruri obișnuite care s-ar aplica. pentru dacă luăm această pagină și o punem în indexul nostru sau nu. Testul de compatibilitate cu dispozitivele mobile se concentrează în principal pe partea mobilă, iar instrumentul de inspectare a adreselor URL este ca acest cuțit mare de buzunar cu diferite caracteristici pe care le puteți folosi pentru diferite lucruri.

Întrebarea 18:00 - Un site de comerț electronic al clienților noștri, unele dintre produse sunt vândute ca configurabile, ceea ce înseamnă că mai multe variante diferite ale produsului sunt afișate și gestionate pe aceeași pagină. Ne gândim să împărțim acele pagini, astfel încât fiecare să aibă propria lor pagină de produs separată cu o adresă URL nouă. Recenziile clienților ar fi apoi mutate de pe pagina veche pe cele noi simple. Faptul că vechea recenzie are o dată mai veche decât noua dată de creare ar putea fi marcată ca black hat SEO?

Răspuns 18:37 - Deci, nu văd deloc nicio problemă cu recenziile, atâta timp cât puteți continua să adăugați recenzii noi pe acele pagini de produse. Cred că aspectul pe care l-aș analiza mai mult este dacă are sens să împărțim acele produse în pagini separate, deoarece ceea ce faci schimb este o pagină de produs care este destul de puternică pentru acel produs și toate variantele, comparativ cu mai multe pagini care trebuie să lucreze singuri și să fie sprijiniți pe cont propriu. Deci, în loc să ai o pagină foarte puternică pentru „pantofi de alergat”, ai mai multe pagini care trebuie să se lupte cu „pantofi de alergat albaștri”, „pantofi de alergat roșii”, „pantofi de alergare verzi”. Deci, dacă cineva caută „pantofi de alergare”, atunci aceste pagini mici nu sunt într-adevăr la fel de puternice ca pagina de produs pe care o ai pentru acel produs principal. Deci, sfatul meu general este de a spune, dacă credeți că aceste variații sunt doar atribute ale produselor principale, în sensul că oamenii tind să caute conținutul principal și apoi să spună „oh ce culoare vreau, parcă am găsit produsul Vreau, dar trebuie doar să aleg culoarea pe care o vreau.” apoi le-aș pune pe o pagină partajată. În timp ce oamenii caută în mod explicit acea variație și acea variație este într-adevăr unică și iese în evidență de la sine, iar oamenii nu vin pe site-ul tău doar spunând „Vreau pantofi de alergat”, ci mai degrabă „Vreau acest tip specific de alergare pantofi în această culoare”, atunci acesta este ceva care poate merită scos ca produs separat. Deci, aceasta este distincția pentru care poate m-aș face griji - nu mi-aș face griji atât de mult pentru partea recenziilor.

Întrebarea 20:36 Noua funcționalitate a schemei de marcare a consolei de căutare a rămas aceeași ca în cea veche?

Răspuns 20:50 Nu știu care sunt planurile exacte pentru noua consolă de căutare în ceea ce privește funcțiile de date structurate, dar intenționăm să acceptăm toate aceste caracteristici de date structurate. Deci, ceea ce s-ar putea întâmpla este că aceste funcții ajung în consola de căutare într-un mod ușor diferit.

Întrebarea 21:00 Cum rămâne cu viteza pentru versiunea mobilă, este crucial să avem viteză în zona verde și, dacă da, de ce multe dintre site-urile de top sunt încă atât de lente?

Răspuns 21:20: Deci partea bună este că avem o mulțime de factori de clasare, așa că nu trebuie să faci întotdeauna totul perfect. Dar asta înseamnă și că te confrunți cu situații ca aceasta în care spui „Google spune că viteza este importantă, dar site-ul de top aici nu este atât de rapid, așa că nu trebuie să fie important”. Pentru noi este cu siguranță important, dar asta nu înseamnă că trece peste orice altceva. Vă puteți imagina că cea mai rapidă pagină la care v-ați putea gândi este probabil o pagină goală. Dar o pagină goală ar fi un rezultat de căutare cu adevărat groaznic dacă ai căuta ceva cu adevărat specific. Este foarte rapid, dar nu există conținut acolo, așa că utilizatorul nu ar fi mulțumit. Deci trebuie să echilibrăm toți acești factori, conținutul, linkurile și toate aceste semnale și să încercăm să ne dăm seama cum să facem clasamentul pe baza acestui amestec de diferiți factori pe care îl avem. Și face schimbări în timp, se poate schimba destul de repede. De exemplu, dacă ceva este cu adevărat demn de știri în acest moment, atunci putem alege să arătăm site-uri ușor diferite, ceva care este mai mult un subiect de cercetare, veșnic verde.

Întrebarea 22:30 Ce tip de marcare de schemă este de preferat pentru Google, dacă folosim JSON sau micro-date, microformate. Care este de preferat?

Răspuns 22:48 În prezent preferăm marcajul JSON-LD. Cred că majoritatea noilor tipuri de date structurate apar mai întâi pentru JSON-LD, așa că asta preferăm.

Întrebarea 23:00 Google a făcut actualizări grele în februarie sau martie?

Răspuns: 23:15 Nu știu, adică facem actualizări tot timpul. Nu știu ce ai considera greu. Probabil depinde de site-ul dvs. Dacă site-ul dvs. a fost puternic afectat de una dintre aceste actualizări, probabil credeți că este destul de greu. Dacă ne uităm la web în ansamblu, poate că este la fel ca schimbările în mod normal, așa cum se întâmplă întotdeauna.

Întrebarea 23:24. Ce înseamnă conținutul subțire pentru site-urile web afiliate?

Răspuns 23:34 Conținutul subțire nu înseamnă nimic diferit pentru site-urile afiliate față de orice alte site-uri web. Ceea ce am văzut, în special cu site-urile web afiliate, există această tendință de a prelua conținut dintr-un feed, deoarece este foarte ușor de făcut. Puteți obține ca scripturi să facă acest lucru pentru dvs. destul de repede, este ușor de făcut, nu aveți două pentru a face o mulțime de muncă, creează o mulțime de URL-uri. Dar, desigur, pentru utilizatori și pentru Noi, nu este chiar atât de interesant, deoarece oferiți același lucru pe care îl au deja toți ceilalți.

Întrebarea 24:40 Conținutul ascuns în file reprezintă o problemă pentru indexare?

Răspuns 24:50 În general, nu este o problemă pentru indexare. Poate fi o problemă pentru utilizatori, așa că dacă există conținut acolo pe care credeți că utilizatorii chiar trebuie să îl vadă pentru a face conversie, atunci ar fi oarecum problematic din punctul dumneavoastră de vedere. În ceea ce privește indexarea, putem prelua acel conținut și îl putem arăta, astfel încât aceasta este o problemă mai mică.

Întrebarea 25:10 Este textul ancora un factor important de clasare în 2019? Multe companii au făcut studii care subliniază că nu există o corelație. Și apoi există un link către un brevet Google.

Răspuns 25:30 Așa că, în primul rând, cred că nu m-aș îngrijora prea mult cu privire la brevetele Google, brevetăm o mulțime de lucruri care nu se aplică neapărat la ceea ce trebuie să facă masterii web. Așa că cred că este interesant să văd că inginerii noștri lucrează, dar asta nu înseamnă neapărat că vom fi afectați de asta imediat. În ceea ce privește textul de ancorare în general, îl folosim pentru text. Este ceva pe care noi îl luăm. Este o modalitate excelentă de a ne oferi context despre un link. În special pe site-ul dvs., dacă aveți un link care spune doar „click aici pentru mai multe informații”, nu ne este foarte util. În cazul în care aveți un link care spune „puteți găsi mai multe informații pe această pagină de produs” și un link cu acel nume al produsului respectiv la pagina respectivă, atunci care ne spune că poate această pagină este într-adevăr despre acest produs. Așadar, cu siguranță, aș continua să mă uit la textul de ancorare pe care îl utilizați, în special în interiorul site-ului dvs. web și aș încerca să mă asigur că furnizați un text de ancorare care este cu adevărat util și oferă context la ceea ce este legat pe pagină.

Întrebarea 27:00 Ne puteți spune cum funcționează procesul DMCA?

Răspuns 27:01 Nu vă pot spune cum funcționează asta pentru că nu cunosc detaliile despre asta și este, de asemenea, un proces legal și nu vă pot oferi sfaturi juridice.

Question 27:30 How does a content platform like medium get its status as content provider? When I check the transparency report for medium the status is, check a specific URL, it's hard to provide a specific status for a site like medium that has a lot of content. We're also a content provider, hosting supermarket catalogs and other PDF publications online, generated by users. So I guess the questions is how do we get that status?

More context from the person who asked the question. Basically the problem we're trying to solve is, our platform allows adding outgoing links in the catalogue and if one specific Url is flagged for going to a bad site, our entire domain is at risk and we have been blacklisted before. Basically it fits the bill because we have a large number of content and all of that is user generated, so how does one go about being in this standing?

Answer 28:48 Um, I don't know. Is it mostly in regards to the transparency report with regards to phishing or maybe malware? It sounded like originally you just want the status that's provided in the transparency report but with regards to link and the content that's provided that sounds more like it's towards phishing or spam?

We're trying to solve for the issue where the domain is blacklisted for phishing and spam. Under the hood we are solving that problem but the generic solution seems to be something like this because even if individual long-tail domains are blacklisted for a period of time our main commercial domain is sage, is that even a good assumption?

Answer 29:50 I don't know how to best attack that. So I think from my point of view, there's one thing that you could do. I don't know your website so its hard for me to say already. Make it so it's easier for us to understand which parts of our website belong together. So for example, if you have different subdomains per user then its easy for us to say, well this problem is isolated on this specific subdomain or subdirectory and then our algorithms can then focus on that on a subdomain level. Where as if all the content is within the main domain and the URL structure is a slash and then a number then its really have for our algorithms to say everything that matches this pattern is maybe phishing or spam that wasn't caught in time. The easier you can make it for us for figure out which parts belong together, which could be by user, or could be by type of content depending on how you group the content then the easier it is for us to kind of match an action that applies just to this part of the website.

Question Continued 31:33 There is no process that your aware of that you can apply or get the status of content provider? And does it actually link to having decreased risk for whole domain blacklisting?

Answer 31:46 I don't think the two side are connected, so I think that content provider status in the transparency report is something that's specific to the transparency report and wouldn't apply to the spam handling. We do have some fold here who are working on something specific for hostess or CMS providers, which I think is kind of what you fall into here. To try to give them more information on where we see spam and to better understand the grouping of content in regards to individual websites.

Question 37:00 Is it necessary to Hreflang links to paginated pages beyond page one?

Answer 37:18 So it's never necessary to add Hreflang links, that's kind of the first thing there. It's not like you will be penalized for having those links on all pages across your website, those links do help us better understand which pages belong together. HReflang links work on a per page basis so if links work well between the homepage version of your site and not between the product pages on your website that's perfectly fine. Use them for the URLs that you think need to have that connection for the language and country versions, you don't need to do that for everything. The other thing, sometimes doing Hreflang links properly is really complicated, especially if your mixing things like pagination and maybe filtering then that feels like something where you're adding so much complexity that it's unlikely you will end up with a useful result and I would just drop the hreflang links so that you don't have extra noise in search console. That's kind of the pragmatic approach that I would take there. Use Hreflang where you see that you have problems and if you don't have any problems in regards to localization then don't worry about the hreflang part.

Question 39:00 Does Google determine a page is low quality by taking into account what the pages looks like visually? I have a site that has elements that get 3D rotated when a user taps on them, when I look at this page as Googlebot, it see's these elements with the ext backwards and looks weird. Is that a problem or not?

Answer 39:20 From my point of view, that's no problem. We do try to look at the page visually but mostly with regards to, is the actual content above the fold or is the above the fold space just one giant ad. That's kind of what we focus on, also with regards to mobile friendliness we try to visual map a page and see, is this a page that would work well on a mobile device. And for that we kind of have to map out the page, its ok if some elements are unreadable as long as they work on a mobile device. If those links are there, they're the right size and people can click on them, then that's perfectly fine. If you're doing some fancy css transformation to turn this into 3d text, that's totally up to you. The important part is that the text itself is visible on the page and that you're not doing too much fancy markup to split that text up. So as an example if you have a headline in the old system where you have a table based layout and you wanted to split the healing on top, I've seem people put individual letters into individual table cells and from our point of view that makes it pretty much impossible to see that this is actually one word because you're using markup to split it up into disconnected chunks. From a parsing the page point of view that's really tricky.

Question 41:26 - I've heard that changing a title tag for page will drop in ranking temporarily is that true what if I have a number that has just changed on the page title?

Answer 41:47 - So it's not true that changing a title will automatically drop a page in ranking I don't think that would make sense. However if you change a title and you put new keywords in there then we obviously need to figure out like how we should rank that page based on that title. Where the title is is one of the things that we do look at. We do look at a lot of other things on a page as well a lot of other signals that are involved with ranking so just changing a title on its own should have a big effect over all but if you're adding something new there that wasn't there before and you want to rank for that new piece of thing there then obviously that does take a little bit of time. So if you're just changing numbers in the title then if people were searching for those old numbers or those new numbers that might be an effect that you would see. In practice people are not going to search for like number three or number five and expect your page to show up. I mean maybe there are exceptions but for the most part that's not going to be something that would affect your your pages ranking. So if you're changing numbers in a title over time I think that's perfectly fine if users are okay with that if that works for everyone.

Question 43:00 - Can Google crawl hyperlinks that we've swapped out the URL with JavaScript we do this as a workaround with our client due to CMS limitations.

Answer 43:08 - Yes we can pick that up. The important part I think is that the URL needs to be swapped out after the page is loaded. It shouldn't be swapped out when a user does a specific action. So for example if a user hovers over a link and then you use JavaScript to swap out the URL that wouldn't be something that we would notice or if a user clicks on a link and then you use JavaScript to swap out the URL then that also wouldn't be something that we would notice. But if the page loads and then you execute some JavaScript that cleans up the URL so that they link to the proper canonical versions that's perfectly fine and kind of like like we talked about in the beginning when it comes to rendering sometimes this takes a bit of time. So it's not an immediate thing that we would pick up we might or it's likely that we would pick up both of these versions both the original link that you had there as well as the JavaScript version. So it wouldn't be that the old versions would drop out completely.

Question 44:20 - Does Google understand related topics for example if I create a page about pets but I don't mention cats and dogs will that make it harder for Google to rank me?

Answer 44:35 - No I don't think that would be problematic. So it would of course make it harder to rank this page if someone searches for cats or dogs but you can create a page about pets that doesn't include all of those different types and I think that's that's pretty normal. Like there's a lot of variation of content out there and some content focuses more on on this side of the topic and some focuses more on a different part of the topic that's completely normal.

Question 45:09 - How does Google understand the quotes page given that they're technically duplicate content. Can Google tell that these are quotes pages and lots of content is also on other websites is that a bad thing or not? How does Google know?

Answer 45:30 - We do recognize when there are kind of parts of a page that are shared across other pages. So a really common situation is you have a footer on your web page that you share across a lot of pages. We can tell that this this part of text is the same as you have across other parts of your website. So what generally happens there is if someone searches for something that's in the shared piece of content we'll will try to pick the most matching page for that. If someone searches for something that's a combination of that content and something else on a page that will try to pull that best matching page. So that's the same as what would happen with these quotes pages and that if someone searches for a specific quote that you have on this page then we'll try to pick one of the many quotes pages that we have that has the same quote on it. It might be yours it might be like hundred other people, a lot of people have these quotes, and we'lll try to show that one in the search results. It's not that we would see this page as being lower quality it's just that you're competing with a lot of other sites that have the exact same quotes on it so if there is something unique that you're providing on these pages then I would make sure that that is also very visible there. So that it's easy for us to tell that well pages about this quote but also has a lot of information about other I don't know, Russian quotes or other German quotes, and we can tell this user is used to searching in Russian or German so we'll bring them to your site rather than to a generic site that has just all kinds of quotes. So the more you can bring unique value into those kind of pages more likely we'll be able to show that in the search results. But it's not necessarily something that you have to hide, we recognize these quotes we we understand that as sometimes are shared across lots of websites that's completely normal.

Question 47:40 - Suppose I started a blog the most following methodology is connecting your site map to the webmaster site from day one but what if I write 50 posts and then add a sitemap file is there any difference

Răspuns 47:54 - Ambele metode funcționează. Prin urmare, fișierul sitemap ne ajută să înțelegem mai bine paginile noi și să schimbăm paginile de pe un site web. Nu este un factor de clasare, așa că nu vă veți clasa mai sus doar pentru că aveți un fișier de hartă site, ne ajută să înțelegem care dintre aceste pagini sunt disponibile pe un site web, dar în cea mai mare parte, în special pentru site-urile mai mici, le putem accesa cu crawlere în mod normal de asemenea, și nu există o mare diferență în ceea ce privește modul în care un site este afișat în căutare, dacă îl putem accesa cu crawlere în mod normal sau dacă îl accesăm cu crawlere cu un fișier de hartă site. Deci, un fișier de hartă a site-ului cu siguranță nu este esențial pentru site-uri mai mari dacă modificați părți de conținut care sunt uneori puțin mai jos în site, atunci, evident, un fișier de hartă a site-ului ne ajută să găsim acele modificări mult mai rapid, dar dacă abia începeți un blog de care nu trebuie neapărat să aveți un fișier de hartă site.

Întrebarea 48:50 - Revindem hoteluri în Grecia prin intermediul site-ului nostru web, am dezvoltat o secțiune bună pentru hoteluri, dar, de asemenea, duplicăm conținutul și titlurile acelor hoteluri pe măsură ce încorporăm videoclipuri YouTube ale acelor hoteluri. Este dăunător pentru noi?

Răspuns 49:10 - Ei bine, cred că acest gen de întrebări se întoarce la celelalte întrebări pe care le-am avut cu privire la conținutul duplicat. Conținut duplicat în care într-adevăr trebuie să vă concentrați pe a vă asigura că aveți ceva unic pe site-ul dvs., dacă într-adevăr oferiți același lucru pe o mulțime de site-uri web diferite, ceea ce ne face foarte greu să spunem bine că acest lucru este de fapt, un site web pe care trebuie să le arătăm rezultatele căutării. Așadar, aș recomanda să faceți un pas înapoi și să vă gândiți la ce ați putea face pentru a vă asigura că site-ul dvs. este cu adevărat unic și convingător în sine, mai degrabă decât același lucru ca toate celelalte site-uri web.

Întrebarea 50:00 - Dacă o poveste a fost redirecționată pentru că era conținut subțire și veche de mulți ani, efectele negative ale articolului sunt oarecum transmise odată cu redirecționarea?

Răspuns 50:12 - Nu, nu neapărat. Deci, mai ales când vine vorba de conținut, ne uităm la conținutul pe care îl găsim pe pagina finală pe care ajungem. Deci, dacă ați eliminat conținut, dacă ați curățat ceva și cred că asta se întâmplă automat. dacă redirecționați pagina respectivă și conținutul vechi nu mai este acolo și avem doar conținut nou, atunci este perfect. Așa că nu ar fi ceva ce s-ar putea duce mai departe.

Întrebarea 50:45 - Este firesc dacă consola de căutare raportează erori de compatibilitate cu dispozitivele mobile sunt subversia de testare a unei pagini atunci când am asociat versiunea adaptată pentru dispozitive mobile a unei pagini cu link-ul rel alternativ act

Răspuns 50:57 - Deci, de obicei, asta înseamnă că nu avem o înțelegere clară despre care dintre acele pagini aparțin împreună. Deci, dintr-un motiv sau altul, am indexat aceste pagini individual, mai degrabă decât ca o pereche, unde știm că această pagină de desktop aparține acestei pagini mobile. Așa că ar putea duce la o nepotrivire cu modul în care ați configurat linkul alternativ sau linkul canonic rel pe acele pagini de acolo. Așa că mă uit și la asta și celălalt lucru, bineînțeles, este că aș analiza și ce ar fi nevoie pentru a trece la un design receptiv, deoarece mai ales cu un index mobil primul, toate aceste tipuri de probleme în care avem mobil separat. URL-uri doar fac totul atât de mult complicat inutil. În timp ce, dacă puteți trece la un design receptiv sau un design care utilizează doar aceleași adrese URL pentru versiunile desktop și mobile. Deci, te salvezi, ai atât de multe probleme, așa că în loc să urmărești acest tip de problemă, poate să-ți ia timp să spui, bine, ar trebui să investesc într-un plan pentru a trece la un design receptiv, astfel încât să nu trebuiască să mă concentrez asupra acestora. probleme în viitor.

Întrebarea 1:01:01- Este o idee bună să adăugați un link nofollow la wikipedia și la articolele de ajutor Google, ca și alte link-uri externe? Și cât timp durează evidențiatorul de date bun pentru a avea efect într-o căutare?

Răspuns 1:01: 16 - Skay, așa că adăugați nofollow la link-urile Wikipedia. Nu cred că are prea mult sens decât dacă Wikipedia te plătește pentru a plasa acele linkuri. Așa că aș adăuga un nofollow link-urilor pe care nu doriți să le asociați cu site-ul dvs. Dar, altfel, dacă este un link normal în conținut și aș arăta normal, așa că dacă Wikipedia nu vă plătește pentru acele linkuri, atunci cred că aș gândi normal. Și pentru evidențiatorul de date, ceea ce se întâmplă, există un fel de proces algoritmic care poate dura ceva timp, deoarece se bazează pe paginile cache pe care le învață din paginile de index de pe site-ul dvs. și, evident, se bazează pe marcajul pe care îl faceți datele. iluminator și apoi îl ia și îl aplică paginilor noi pe măsură ce le reindexăm și le reindexăm pe site-ul dvs. Deci, acesta este ceva care necesită o perioadă de timp pentru a se aplica conținutului, pe măsură ce îl reindexăm și îl reindexăm pe site-ul dvs. web. Deci, nu există o cronologie fixă, uneori destul de rapidă pentru o mulțime de pagini și uneori poate dura câteva luni pentru a fi vizibil. Deci, nu există niciun fel de buton instantaneu pentru asta, este nevoie de timp ca orice alte date structurate pe care le-ai adăuga manual paginilor tale.

Întrebarea 1:02:58 - Este Google conștient și anunță o schimbare substanțială a modului în care conținutul duplicat a început să fie tratat la sfârșitul lunii noiembrie, începutul lunii decembrie a anului trecut? Sau a existat o schimbare substanțială în modul în care serviciul de redare web își desfășoară activitatea sau relația dintre redarea web și indexare față de indexarea cu crawlere în acea perioadă, deoarece nimic nu s-a schimbat în sistemul nostru și am văzut, așa cum am spus, probleme substanțiale începând de atunci în special, nu doar pentru noi înșine, dar am observat și o serie de alte observații ale acestei clase de probleme în aceeași perioadă?

Răspuns - 1:03:47 - Unde s-a schimbat ceva substanțial acolo. Singurul lucru care cred că s-a întâmplat în jurul toamnei sau cam asa ceva este că am început să adăugăm această caracteristică în consola de căutare pentru a evidenția acele probleme și, de asemenea, cred că am început să văd mai multe dintre aceste rapoarte odată ce am evidențiat-o. utilizatorii care, hei, am aruncat aceste adrese URL și parcă există un grafic al lor, deoarece credem că toate sunt duplicate și, desigur, toată lumea spune, oh, aceasta este o problemă nouă, dar în mare parte a fost întotdeauna ca și cum că nu am vorbit niciodată despre asta în consola de căutare. Așa că nu știu exact când am început să lansăm această funcție în consola de căutare, dar probabil ca în a doua jumătate a anului trecut ceva pe atunci.