Program SEO – 24 decembrie 2021

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

Conținut cu pereți de plată și deghizare

00:49 „În ceea ce privește datele de tip paywall cu conținut paywall. […] Avem un site web. Am făcut o mulțime de articole și totul este accesibil pentru Google. Și am dori să adăugăm un paywall acolo, dar […] doar […] să arătăm Google conținutul paywall cu fragmentele de date structurate pe care le aveți. Este considerat demascare?

Așadar, verific dacă este Googlebot și doar [apoi] arăt […] datele structurate – […] datele cu pereți de plată. Dar apoi utilizatorului obișnuit […], nu arăt datele structurate, este bine?”

John nu a văzut problema cu această soluție: „Este bine. Din punct de vedere tehnic, ar fi în continuare considerată dezvăluire, pentru că arăți ceva diferit, dar din politicile noastre, acest lucru este acceptabil. Pentru că utilizatorii […] dacă trec prin peretele de plată […] vor vedea conținutul pe care îl afișați Googlebot.”

Potențiale probleme de indexare

03:38 „Public conținut de înaltă calitate, am trimis o hartă a site-ului și uneori solicit indexarea din Google Search Console. Dar încă mai am o problemă la indexarea conținutului nou sau este indexat [cu întârziere]. […] Este o eroare de la Google sau este o nouă actualizare a algoritmului?”

John a răspuns: „Nu există nicio problemă de partea noastră în acest sens. […] Pur și simplu nu indexăm tot conținutul , iar unele site-uri web generează mult conținut. Și dacă nu indexăm totul […], poate fi OK. Dar poate vrei ca totul să fie indexat, iar noi nu putem face totul tot timpul.

Partea dificilă […] este că, în trecut, […] multe site-uri web nu erau din punct de vedere tehnic atât de grozave. A fost puțin mai clar ce tip de conținut nu a fost indexat. În zilele noastre, site-urile web sunt ok din punct de vedere tehnic și este […] ca și cum bara de calitate este puțin mai înaltă […]. Oricine poate publica ceva care, teoretic, ar putea fi indexat, dar […] trebuie să ne asigurăm că indexăm lucrurile potrivite care sunt de fapt utile și relevante pentru utilizatori. Așa că uneori trebuie să lăsăm unele lucruri neindexate.”

Actualizare a recenziilor produselor – limbi și țări afectate

14:01 „Despre actualizarea recenziilor despre produse. […] Chiar dacă actualizarea afectează doar site-urile web de limbă engleză, am văzut câteva mișcări și în Căutarea germană. Mă întrebam dacă ar putea exista și un efect asupra site-urilor web în alte limbi prin această actualizare a recenziilor despre produse sau orice fel […]?”

După cum a spus John, „ Presumarea mea a fost că aceasta a fost globală și în toate limbile […]. Dar, de obicei, încercăm să împingem echipa de ingineri să ia o decizie în acest sens, astfel încât să o putem documenta corect în postarea de pe blog. Nu știu dacă asta s-a întâmplat cu actualizarea recenziilor despre produse. […] Pare ceva ce am putea face în mai multe limbi și nu ar fi legat doar de engleză. Și chiar dacă inițial ar fi fost engleză, pare ceva relevant în general și ar trebui să încercăm să găsim modalități de a-l extinde și în alte limbi în timp. Așa că nu sunt deosebit de surprins că vedeți schimbările din Germania […]”.

După ce a aflat că postarea de pe blogul Google a menționat doar actualizarea care afectează site-urile în limba engleză, John a detaliat în continuare:

„Cu acest tip de actualizări, încercăm să începem cu o limbă sau o locație și să vedem ce trebuie să modificăm, apoi ne extindem de acolo. […] Cu ceva care este mai legat de conținut, de obicei durează puțin mai mult să se extindă în diferite limbi […].”

Localizarea paginilor pentru țările vorbitoare de limbă engleză

17:53 „Cunoașteți alte modalități de a localiza același set de pagini pentru diferite țări de limbă engleză? […] Avem mai multe subdomenii cu domeniul de nivel superior .jo, cum ar fi poate din subdomenii din Australia, Noua Zeelandă și am setat țara în backend-ul JSA și, de asemenea, folosim hreflang la nivel de pagină. […] Nu am putut găsi alte modalități de a ne ajuta să localizăm aceste subdomenii. Aveți metode bune sau modalități pe care le putem îmbunătăți?”

Iată cum a discutat John acest subiect:

„Cred că le-ai acoperit pe cele principale. Aceasta este direcționarea geografică în Search Console și setările hreflang.

Geotargeting funcționează la nivel de subdirector sau subdomeniu, toate paginile sunt acolo.

Hreflang este pe pagină. Dacă aveți o pagină de pornire pentru o țară și diferite pagini de produse pentru aceeași țară, atunci fiecare dintre acele pagini ar trebui să fie încrucișată cu hreflang.

Celălalt lucru pe care încerc mereu să-l recomand este să ai un fel de plan de rezervă, […] ceva de genul unui banner bazat pe JavaScript pe care îl poți afișa atunci când recunoști că utilizatorul se află pe versiunea greșită a unui site. De exemplu, dacă un utilizator din Australia ajunge pe pagina din Anglia, puteți afișa un banner JavaScript care spune: „Hei, avem o versiune australiană a acestei pagini aici. Poți să mergi acolo direct. Avantajul unui banner bazat pe JavaScript este că îl poți bloca cu robots.txt, astfel încât din punct de vedere al indexării, să nu apară. Și dacă nu redirecționați automat, […] [motoarele de căutare] vor putea procesa aceste două versiuni în mod independent.

Dacă aceste pagini sunt în esență aceleași, se poate întâmpla ca una dintre aceste pagini să fie tratată ca versiune canonică. De exemplu, dacă aveți o pagină pentru Noua Zeelandă și Australia și întregul conținut este același, singurul lucru care este ușor diferit este moneda de pe pagină, atunci […] împăturim acele pagini și alegem una dintre ele ca un canonic și folosiți-l ca bază pentru Căutare.

Dacă aveți un hreflang, și pe acele pagini, vom folosi în continuare hreflang pentru a afișa versiunea corectă a adresei URL. Dar conținutul indexat va fi doar din versiunea canonică, iar toate rapoartele din Search Console vor fi pentru versiunea canonică. Asta face ca uneori să fie puțin complicat, mai ales dacă aveți un site web mai mare, cu […] același conținut pentru diferite țări.”

Adăugarea de conținut dinamic în pagini

25:0 „Site-ul meu web are milioane de pagini, cum ar fi pagini de categorie, subcategorie și produse, comerț electronic […]. Am adăugat conținut dinamic, deoarece [cu] milioane de pagini […] [este] dificil să adăugați conținut separat sau […] conținut unic pe fiecare pagină. Am adăugat […] conținut bazat pe șablon pe paginile de categorii, paginile de subcategorii și paginile de produse. […] Ar fi bine pentru performanța site-ului nostru sau nu, sau ar trebui să actualizăm conținutul pentru fiecare pagină? […]”.

Iată cum a răspuns John:

„ Adăugarea dinamică a conținutului relevant pe o pagină […] poate avea sens , deoarece […] [este] în esență doar face […] o căutare în baza de date și adaugă conținut pe baza acesteia. […] Depinde cu adevărat de cum ai configurat.

Principalul lucru pe care l-aș evita este să te întâlnești într-o situație în care adaugi artificial conținut pe o pagină, doar în speranța că această pagină se clasifică mai bine pentru cuvintele cheie pe care le adaugi artificial. […] Când utilizatorii merg acolo, vor fi de genul „De ce sunt aceste cuvinte cheie aleatorii pe această pagină?” […] Asigurându-vă că aveți într-adevăr conținut bun și relevant pentru acele cuvinte cheie cheie, pe asta m-aș concentra mai mult […].”

Când a fost întrebat dacă este necesar să scrie conținut relevant pentru fiecare pagină pentru ca Google să vadă paginile ca oferind valoare, John a spus:

„Ar trebui să fie ceva relevant pe pagină. Și dacă este o pagină de categorie, atunci produsele pe care le-ați enumerat acolo sunt foarte relevante […] și, de obicei, aveți o descriere a acelei categorii. […] Nu este că trebuie să scrii un articol Wikipedia în partea de jos despre toate aceste produse și de unde provin ele […] ci un pic de informații care sunt relevante pentru pagină, asta contează.”

Redarea și indexarea fișierelor JavaScript

28:28 „Site-ul meu […] [folosește] Reacționează cu randarea pe partea clientului, […] când dezactivăm JavaScript și browserul, pagina mea este complet goală. Asta poate fi cauza unei poziții mai scăzute sau poate a performanței slabe a paginii web?”

Răspunsul lui John a fost: „ Nu ar trebui să fie. […] Pentru căutare, facem randare și procesăm JavaScript din pagini. Dacă este vizibil într-un browser normal și nu faci nimic deosebit de rău, atunci am fi capabili să indexăm acele pagini în mod normal. Puteți verifica din nou cu instrumentul Inspectați adresa URL din Search Console pentru a vedea dacă conținutul este de fapt vizibil atunci când Googlebot încearcă să redea pagina și dacă conținutul este vizibil, atunci ar trebui să fiți gata .”

Indexarea URL-urilor generate prin căutarea într-un site web

30:11 „Am adăugat deja o casetă de căutare pe site-ul nostru , astfel încât utilizatorul intră pe site-ul nostru și caută acolo și generează o adresă URL unică pentru fiecare căutare. Aceste adrese URL ar trebui să fie indexabile sau nu ?”

După cum a spus John, „ De obicei nu. […] Există două motive principale pentru asta.

Pe de o parte, este foarte ușor să ajungeți într-o situație în care aveți încă un milion de adrese URL care sunt doar căutări diferite, ceea ce nu vă oferă nicio valoare. Îl numim un spațiu infinit […]. Este ceva ce vrei sa eviti.

Celălalt lucru pe care doriți să îl evitați este ca oamenii să facă spam în caseta de căutare și să încerce să le indexeze , ceea ce ar putea fi ceva de genul căutării numărului lor de telefon și […] tipul lor de afaceri […]. Dintr-o dată, pagina de căutare a site-ului dvs. se clasează pentru acest tip de afacere și arată numărul lor de telefon, chiar dacă nu aveți niciun conținut care să se potrivească cu acele interogări, […] fac acest lucru pentru a încerca să fie vizibili în rezultatele căutării. Aș bloca acest tip de pagini de căutare cu robots.txt. Astfel poți fi sigur că nu vom putea indexa niciun conținut.”

Site-uri SEO ca YMYL

31:55 „O firmă de SEO ar fi clasificată drept site-ul Your Money sau Your Life sau are legătură doar cu site-uri de consiliere medicală și financiară?”

Potrivit lui John, „[…] Nu cred că site-urile web SEO sunt atât de esențiale pentru viața oamenilor. Evident, dacă lucrezi la o companie SEO, atunci ești legat de asta, dar nu este vorba că site-ul în sine este un site de tip Your Money sau Your Life. […] Nu orice site web care vinde ceva se încadrează în această categorie.

Ceea ce aș recomanda aici este, în loc să încerc orbește să vedeți „Acest tip de site web se încadrează în această categorie specifică?”, […] să citiți de unde provine această categorie, și anume Ghidul pentru evaluarea calității, și să înțelegeți puțin mai multe ce încearcă Google să facă cu înțelegerea acestor diferite tipuri de site-uri web . […] Asta vă va oferi puțin mai multe informații de fundal despre ceea ce se întâmplă de fapt […].”

Implementarea datelor structurate breadcrumb

39:56 „Când vine vorba de datele structurate de tip breadcrumb, trebuie să fie exact aceleași cu briadcrumb-urile pe care le-ar vedea un vizitator pe o pagină? Uneori văd o versiune condensată a pesmeturilor pe pagină, în timp ce datele structurate sunt o cale completă de pesmet. Sunt ambele opțiuni acceptabile?”

După cum a spus John, „[…] Încercăm să recunoaștem dacă datele structurate sunt vizibile pe o pagină sau nu. Și dacă nu este […], trebuie să ne dăm seama „Mai are sens să arătăm asta în rezultatele căutării? ”

Dacă faceți ceva de genul afișării unei versiuni mai scurte a unui fir de navigare pe o pagină și nu putem să o potrivim, s-ar putea să fie un pic greșit, dacă luăm de fapt acel marcaj de breadcrumb și îl folosim.

Dacă luați firimituri individuale sau […] elementele individuale din lista de pesmet și le arătați doar pe unele dintre acestea, dar nu pe toate, s-ar putea să le luăm pe acestea. S-ar putea să luăm în continuare restul pentru că vedem […] o mulțime de potriviri pesmet.

Nu este garantat că vom putea prelua și folosi marcajul complet pe care îl aveți dacă nu îl afișați pe pagină și este similar cu alte tipuri de date structurate.

Cred că principala excepție […] este […] marcajul Întrebări frecvente, unde aveți întrebări și răspunsuri, unde […] partea importantă este că întrebarea este de fapt vizibilă, iar răspunsul poate fi ceva ca o secțiune restrânsă pe un pagina, dar […] cel puțin trebuie să fie vizibil.”

Traducerea doar a unor pagini de pe un site web

44:00 „Derulăm un site cu sub 300 de pagini de index, toate în engleză. Căutăm să traducem aproximativ jumătate din aceste pagini în spaniolă, care vor fi plasate în subdirectorul de pe același domeniu, cum ar fi /ES, și etichetate ca versiuni în limbi alternative ale conținutului în limba engleză. Este în regulă să traducem doar o parte din conținutul paginii sau ar trebui să traducem totul pentru a oglindi exact site-ul în limba engleză și să avem cele mai bune șanse de a ne clasa în alte locații?”

John a spus: „ Este bine să traduci doar câteva pagini de pe un site web. Ne uităm la limba paginilor individual. Dacă aveți unele pagini în spaniolă, ne uităm doar la acele pagini în spaniolă, când cineva caută în spaniolă. Nu este cazul în care am spune: „Sunt mult mai multe pagini în engleză decât pagini spaniole aici. Prin urmare, site-ul spaniol este mai puțin important.' […] Acestea sunt pagini spaniole și se pot clasa bine în spaniolă. […] Pentru utilizatori, uneori, are sens să aibă cât mai mult conținut tradus. Dar, de obicei, acesta este ceva pe care îl îmbunătățești treptat în timp, unde începi cu unele pagini, le localizezi bine și adaugi mai multe pagini […].

Adnotările hreflang sunt, de asemenea, pe pagină. Dacă aveți câteva pagini în engleză și în spaniolă și le legați, este perfect. Dacă aveți unele pagini doar în spaniolă, este în regulă - nu aveți nevoie de hreflang. Unele pagini sunt doar în engleză, e bine. Din acest punct de vedere, aceasta pare a fi o modalitate rezonabilă de a începe.”

Accesați cu crawlere bugetul și adresele URL generate automat

46:12 „Site-ul web despre care vorbesc este un site WordPress. Acesta generează automat mai multe adrese URL nedorite. […] Există o modalitate prin care pot opri crawler-ul pentru a afla aceste adrese URL? Știu că nu-l pot indexa, iar toate acestea nu sunt URL-uri indexate. Dar apoi, le pot vedea pe Search Console sub partea Exclus. […] Este un site de știri, avem mii de URL-uri. […] Va afecta bugetul de crawling?”

John a întrebat despre dimensiunea site-ului și i s-a spus că are între 5.000 și 10.000 de adrese URL.

Având în vedere acest lucru, John a spus: „ Nu mi-aș face griji în privința bugetului de crawling. […] Putem accesa cu crawlere atât de multe pagini destul de repede, de obicei în câteva zile. Celălalt lucru […] este că „noindex” este o metaetichetă pe pagină. Trebuie să accesăm cu crawlere pagina pentru a vedea metaeticheta, ceea ce înseamnă că nu puteți evita să verificăm paginile „noindex”. […] Dacă vedem că există un „noindex” pe pagină, de obicei, în timp, accesăm cu crawlere acele pagini mai rar. Vom verifica în continuare din când în când, dar nu vom verifica la fel de mult ca o pagină normală care este altfel indexată. Cealaltă abordare este utilizarea robots.txt. Cu fișierul robots.txt, puteți bloca complet accesarea cu crawlere a acestor pagini. Dezavantajul este că uneori URL-ul în sine poate fi indexat în rezultatele căutării, nu conținutul paginii […].”

John a dat și următorul exemplu:

„Dacă […] aveți un site de știri despre fotbal și aveți unele articole care sunt blocate și unele articole care pot fi accesate cu crawlere, atunci dacă cineva caută știri despre fotbal, va găsi versiunile indexabile ale paginilor dvs. și nu va conta că există alte pagini care sunt blocate de robots.txt. Cu toate acestea, dacă cineva face în mod explicit o interogare de site pentru acele pagini blocate, atunci veți putea vedea acele adrese URL în căutare […]. Într-o situație ca a ta, […] nu mi-aș face griji în privința bugetului de crawl.”

John a mai adăugat: „ Din punct de vedere practic, atât „noindex” cât și robots.txt ar fi oarecum echivalente. […] Acest conținut probabil nu ar apărea în rezultatele căutării și ar trebui totuși să-l accesăm cu crawlere dacă există „noindex”, dar numerele sunt atât de mici încât nu contează cu adevărat. S-ar putea să-l indexăm în continuare cu o adresă URL dacă sunt blocate de robots.txt […]”.

Referitor la metoda preferată, John a spus: „Aș alege cea care este mai ușor de implementat de partea ta. Dacă […] ai WordPress și poți avea doar o casetă de selectare pe postare care spune „Această pagină nu are index”, poate că aceasta este cea mai ușoară abordare […].”

Accesarea cu crawlere a adreselor URL cu parametri

54:25 „Vedem în fișierele noastre jurnal și, de asemenea, demonstrăm că este Googlebot prin IEP, o mulțime de accesări cu crawlere de la botul organic la URL-urile parametrilor UTM, Google Display și campaniile universale de aplicații. […] Nu vedem niciun link care vin de nicăieri către acele URL-uri. […] Ai idee unde sau de ce s-ar putea întâmpla asta?”

John a răspuns că „Singurul loc în care cu Googlebot accesăm cu crawlere și paginile pe care le enumerați în campaniile de anunțuri […] este pentru căutarea de produse. Dacă aveți un feed de căutare de produse sau un feed Merchant Center […] configurat, atunci vom accesa cu crawlere acele pagini pentru Googlebot pentru a ne asigura că le putem prelua pentru Merchant Center. Dacă aveți adrese URL etichetate acolo, […] vom păstra acele adrese URL etichetate și le vom reprocesa.

De asemenea, s-ar putea ca și alte persoane să poată trimite acest tip de produse, […] s-ar putea să nu le trimiți neapărat tu, ci poate cineva care lucrează în numele tău sau are permisiunea să facă și asta.

Dacă găsim undeva link-uri către aceste pagini, vom încerca să le accesăm cu crawlere. Dacă ați etichetat linkuri interne într-un site web, vom încerca totuși să le ridicăm și să le accesăm cu crawlere. Dacă aveți lucruri configurate în JavaScript pe care poate aveți URL-uri de urmărire cu acești parametri configurați undeva și, atunci când procesăm JavaScript, se pare că este un link către acele adrese URL de urmărire, am putea procesa și asta. […] Mi se pare că nu sunt cazuri individuale […], ci mai degrabă un număr mare de aceste adrese URL, iar asta seamănă foarte mult cu partea Merchant Center a lucrurilor.”