Program SEO, 1 iulie 2022

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

PageSpeed ​​Insights sau Google Search Console ‒ care dintre ele este mai precisă?

0:44 „Când îmi verific scorul PageSpeed ​​Insights pe site-ul meu, văd un număr simplu. De ce nu se potrivește cu ceea ce văd în Search Console și raportul Core Web Vitals? Care dintre aceste numere este corect?”

Potrivit lui John: „[…] Nu există un număr corect când vine vorba de viteză – când vine vorba de a înțelege cum funcționează site-ul tău pentru utilizatorii tăi. În PageSpeed ​​Insights, în mod implicit, cred că arătăm un singur număr care este un scor de la 0 la 100, care se bazează pe o serie de ipoteze în care presupunem că diferite lucruri sunt puțin mai rapide sau mai lente pentru utilizatori. Și pe baza asta, calculăm un scor.

În Search Console, avem informațiile Core Web Vitals , care se bazează pe trei numere pentru viteză, capacitate de răspuns și interactivitate. Și aceste numere sunt ușor diferite, desigur, pentru că sunt trei numere, nu doar un număr. Dar, de asemenea, există o mare diferență în modul în care sunt determinate aceste numere. Și anume, există o diferență între așa-numitele date de teren și datele de laborator.

Datele de câmp sunt ceea ce utilizatorii au văzut când accesează site-ul dvs. web. Și asta este ceea ce folosim în Search Console. Acesta este ceea ce folosim și pentru Căutare. În timp ce datele de laborator sunt o vedere teoretică a site-ului dvs., în care sistemele noastre au anumite ipoteze în care cred că, ei bine, utilizatorul obișnuit este probabil așa, folosind acest tip de dispozitiv și poate cu acest tip de conexiune. Și pe baza acestor ipoteze, vom estima care ar putea fi acele numere pentru un utilizator mediu. Vă puteți imagina că aceste estimări nu vor fi niciodată 100% corecte.

În mod similar, datele pe care utilizatorii le-au văzut – care se vor schimba în timp, de asemenea, în cazul în care unii utilizatori ar putea avea o conexiune foarte rapidă sau un dispozitiv rapid și totul merge rapid pe site-ul lor sau când vă vizitează site-ul, iar alții ar putea să nu au asta. Și din această cauză, această variație poate duce întotdeauna la numere diferite.

Recomandarea noastră este, în general, să folosiți datele de câmp, datele pe care le-ați vedea în Search Console, ca o modalitate de a înțelege care este situația actuală pentru site-ul nostru web și apoi să folosiți datele de laborator, și anume testele individuale pe care le puteți rula direct pe tine, pentru a-ți optimiza site-ul și a încerca să îmbunătățești lucrurile. Și când sunteți destul de mulțumit de datele de laborator pe care le obțineți cu noua versiune a site-ului dvs. web, atunci, în timp, puteți colecta datele de câmp, care se întâmplă automat și să verificați din nou dacă utilizatorii le văd ca fiind mai rapide sau mai receptiv, de asemenea.

Deci, pe scurt, din nou, nu există un număr corect când vine vorba de oricare dintre aceste valori. […] Dar, mai degrabă, există ipoteze diferite și moduri diferite de colectare a datelor, iar fiecare dintre acestea este subtil diferită.”

De ce Googlebot se luptă cu indexarea paginilor bazate pe JavaScript?

4:19 „Avem câteva pagini de clienți care folosesc Next.js fără un fișier robots.txt sau un fișier de hartă site. Teoretic, Googlebot poate ajunge la toate aceste pagini, dar de ce este indexată doar pagina de pornire? Nu există erori sau avertismente în Search Console. De ce Googlebot nu găsește celelalte pagini?”

John a spus: „[…] Next.js este un cadru JavaScript, ceea ce înseamnă că întreaga pagină este generată cu JavaScript. Dar un răspuns general, de asemenea, la toate aceste întrebări, cum ar fi, de ce Google nu indexează totul – este important să spunem mai întâi că Googlebot nu va indexa niciodată totul pe un site web. Nu cred că li se întâmplă unui site web de dimensiuni netriviale ca Google să se oprească și să indexeze complet totul. Din punct de vedere practic, nu este posibil să indexați totul pe întregul web. Deci presupunerea că situația ideală este totul este indexată ‒ Aș lăsa asta deoparte și aș spune că vrei ca Googlebot să se concentreze pe paginile importante.

Celălalt lucru, totuși, care a devenit puțin mai clar când, cred, persoana m-a contactat pe Twitter și mi-a oferit puțin mai multe informații despre site-ul lor, a fost că modul în care site-ul web genera link-uri către celelalte pagini a fost într-un mod pe care Google nu l-a putut prelua. Deci, în special, cu JavaScript, puteți lua orice element dintr-o pagină HTML și puteți spune, dacă cineva face clic pe aceasta, atunci executați această bucată de JavaScript. Și acea bucată de JavaScript poate fi pentru a naviga la o altă pagină, de exemplu. Și Googlebot nu face clic pe toate elementele pentru a vedea ce se întâmplă, ci, mai degrabă, mergem și căutăm link-uri HTML normale, care este modul tradițional, normal, prin care ați face legătura către pagini individuale de pe un site web.

Și, cu acest cadru, nu a generat aceste link-uri HTML normale. Deci nu am putut recunoaște că există mai multe de accesat cu crawlere, mai multe pagini de privit. Și acesta este ceva pe care îl puteți repara în modul în care implementați site-ul JavaScript. Avem o mulțime de informații pe site-ul Search Developer Documentation despre JavaScript și SEO, în special, pe tema link-urilor, deoarece acestea apar din când în când. Există o mulțime de modalități creative de a crea link-uri, iar Googlebot trebuie să găsească acele link-uri HTML pentru ca acesta să funcționeze. […]”

Și, cu excepția documentației oficiale Google, consultați Ghidul final pentru SEO JavaScript de pe blogul nostru. „

Legăturile către pagini HTTP influențează SEO site-ului dvs.?

7:35 „Îmi afectează negativ scorul SEO dacă pagina mea trimite către un site web extern nesigur? Deci pe HTTP, nu HTTPS.”

John a spus: „În primul rând, nu avem o noțiune de scor SEO, așa că nu trebuie să vă faceți griji cu privire la scorul SEO.

Dar, indiferent, înțeleg că întrebarea este de genul: este rău dacă fac link la o pagină HTTP în loc de o pagină HTTPS. Și, din punctul nostru de vedere, e perfect. Dacă aceste pagini sunt pe HTTP, atunci la asta ați face legătura. Asta s-ar aștepta utilizatorii să găsească. Nu este nimic împotriva trimiterii către astfel de site-uri. Nu există niciun dezavantaj pentru site-ul dvs. să evite conectarea la pagini HTTP, deoarece acestea sunt vechi sau cruste și nu sunt la fel de cool ca pe HTTPS. Nu mi-aș face griji pentru asta.”

Ar trebui să ștergeți fișierul de respingere?

10:16 „În ultimii 15 ani, am dezavuat peste 11.000 de link-uri în total. […] Este posibil ca linkurile pe care le-am dezavuat să fi fost de la site-uri piratate sau de la conținut prostesc, generat automat. Deoarece Google susține acum că au instrumente mai bune pentru a nu include aceste tipuri de linkuri piratate sau spam în algoritmii lor, ar trebui să șterg fișierul meu de respingere? Există vreun risc sau dezavantaj în a-l șterge?”

John a răspuns: „[…] Dezavuarea link-urilor este întotdeauna unul dintre acele subiecte dificile, deoarece se pare că Google probabil nu vă spune informațiile complete.

Dar, din punctul nostru de vedere, […] ne străduim să nu luăm în considerare aceste link-uri. Și facem asta pentru că știm că instrumentul de linkuri Disavow este oarecum un instrument de nișă, iar SEO știu despre el, dar persoana obișnuită care conduce un site web habar nu are despre asta. Și toate acele link-uri pe care le-ați menționat sunt genul de link-uri pe care orice site le primește de-a lungul anilor. Și sistemele noastre înțeleg că acestea nu sunt lucruri pe care încercați să le faceți pentru a folosi algoritmii noștri.

Deci, din acest punct de vedere, dacă sunteți sigur că nu există nimic în jurul unei acțiuni manuale pe care a trebuit să o rezolvați cu privire la aceste legături, aș șterge fișierul de respingere și […] aș lăsa toate acestea deoparte. Un lucru pe care l-aș face personal este să îl descarc și să fac o copie, astfel încât să aveți o înregistrare a ceea ce ați șters. Dar, altfel, dacă sunteți sigur că acestea sunt doar lucrurile normale și cruste de pe Internet, l-aș șterge și aș merge mai departe. Există mult mai mult pentru care să-ți petreci timpul când vine vorba de site-uri web, decât să renunți la aceste lucruri aleatorii care se întâmplă oricărui site de pe web.”

Este mai bine să blocați accesarea cu crawlere cu robots.txt sau cu metaeticheta robots?

14:19 „Ce este mai bine: blocarea cu robots.txt sau utilizarea metaetichetei robots pe pagină? Cum putem preveni cel mai bine târârile?”

John: „[…] Am făcut recent și un episod podcast despre asta . Așa că aș verifica asta. […]

În practică, există o diferență subtilă aici în care, dacă ești în SEO și ai lucrat cu motoarele de căutare, atunci probabil că ai înțeles deja asta. Dar pentru oamenii care sunt noi în zonă, uneori nu este clar unde sunt exact toate aceste linii.

Cu robots.txt, care este primul pe care l-ați menționat la întrebare, puteți bloca accesarea cu crawlere. Astfel, puteți împiedica Googlebot să vă uite chiar și paginile. Și cu metaeticheta roboți, când Googlebot se uită la paginile dvs. și vede acea metaetichetă roboți, puteți face lucruri precum blocarea indexării. În practică, ambele fac ca paginile dvs. să nu apară în rezultatele căutării, dar sunt subtil diferite.

Deci, dacă nu ne putem târâi, atunci nu știm ce ne lipsește. Și s-ar putea să spunem, ei bine, de fapt, există o mulțime de referințe la această pagină. Poate este util pentru ceva. Nu știm. Și atunci acea adresă URL ar putea apărea în rezultatele căutării fără conținutul său, deoarece nu o putem privi. În timp ce cu metaeticheta roboților, dacă ne putem uita la pagină, atunci putem să ne uităm la metaeticheta și să vedem dacă există un noindex acolo, de exemplu. Apoi încetăm să indexăm acea pagină și apoi o renunțăm complet din rezultatele căutării.

Deci, dacă încercați să blocați accesul cu crawlere, atunci cu siguranță robots.txt este calea de urmat. Dacă nu doriți ca pagina să apară în rezultatele căutării, atunci aș alege cea care vă este mai ușor de implementat. Pe unele site-uri, este mai ușor să setați o casetă de selectare care spune că nu vreau ca această pagină să fie găsită în Căutare și apoi adaugă o metaetichetă noindex. Pe altele, poate că editarea fișierului robots.txt este mai ușoară. [Depinde] de ce ai acolo.”

Puteți plasa aceeași adresă URL în mai multe fișiere sitemap?

16:40 „ Există implicații negative pentru a avea adrese URL duplicat cu atribute diferite în sitemap-urile dvs. XML? De exemplu, o adresă URL într-un sitemap cu o adnotare hreflang și aceeași adresă URL într-un alt sitemap fără acea adnotare.”

John a spus: „[…] Din punctul nostru de vedere, acest lucru este perfect. […] Acest lucru se întâmplă din când în când. Unii oameni au adnotări hreflang în fișierele sitemap separate în mod special și apoi au un fișier normal sitemap pentru tot. Și există o oarecare suprapunere acolo.

Din punctul nostru de vedere, procesăm aceste fișiere sitemap pe cât posibil și luăm în considerare toate aceste informații. Nu există niciun dezavantaj în a avea aceeași adresă URL în mai multe fișiere sitemap.  

Singurul lucru la care aș avea grijă este că nu aveți informații conflictuale în aceste fișiere sitemap. Deci, de exemplu, dacă cu adnotările hreflang, spui, această pagină este pentru Germania, iar apoi pe celălalt fișier de hartă a site-ului, spui, ei bine, de fapt, această pagină este și pentru Franța, […] atunci sistemele ar putea fi ca, ei bine, ce se întâmplă aici? Nu știm ce să facem cu acest amestec de adnotări. Și atunci se poate întâmpla să alegem una sau alta.

În mod similar, dacă spuneți, această pagină a fost schimbată ultima dată acum 20 de ani […], iar în celălalt fișier sitemap, spuneți, ei bine, de fapt, a fost acum cinci minute. Atunci sistemele noastre ar putea să se uite la asta și să spună, ei bine, unul dintre voi greșește. Nu știm care. Poate o vom urma pe una sau pe alta. Poate că vom ignora complet data ultimei modificări. Deci, acesta este lucrul de care trebuie să fii atent.

Dar în rest, dacă sunt menționate doar mai multe fișiere sitemap și informațiile fie sunt consecvente, fie funcționează împreună, în sensul că poate unul are data ultimei modificări, celălalt are adnotări hreflang, este perfect.”

Cum să împiedici indexarea paginilor video încorporate?

19:00 „Sunt responsabil de o platformă de redare video, iar încorporațiile noastre sunt uneori indexate individual. Cum putem preveni asta?”

John a răspuns: „[…] M-am uitat la site-ul web și acestea sunt iframe care includ o pagină HTML simplificată cu un player video încorporat în aceasta.

Din punct de vedere tehnic, dacă o pagină are conținut iframe, atunci vedem acele două pagini HTML. Și este posibil ca sistemele noastre să fi indexat ambele pagini HTML, deoarece sunt pagini HTML separate. Unul este inclus în celălalt, de obicei, dar teoretic ar putea sta și singuri.

Și există o modalitate de a preveni acest lucru, care este o combinație destul de nouă cu metaetichete robots pe care o puteți face, și anume cu metaeticheta indexifembedded robots împreună cu o metaetichetă noindex robots .

Și la versiunea încorporată, deci fișierul HTML cu videoclipul direct în el, ați adăuga combinația de metaetichete noindex plus indexifembedded robots. Și asta ar însemna că, dacă găsim acea pagină individual, am vedea că există un noindex [tag]. Nu trebuie să indexăm asta.

Dar cu indexifembedded, ne spune că […] dacă găsim această pagină cu videoclipul încorporat în site-ul general, atunci putem indexa acel conținut video, ceea ce înseamnă că pagina HTML individuală nu ar fi indexată. Dar pagina HTML cu încorporarea, cu informațiile video, care ar fi indexată în mod normal. Deci asta este configurația pe care aș folosi-o acolo. Și aceasta este o metaetichetă a roboților destul de nouă, deci este ceva de care nu toată lumea are nevoie. Deoarece această combinație de conținut iframe sau conținut încorporat este rară. Dar, pentru unele site-uri, are sens să o faci așa.”