Program SEO – 8 octombrie 2021

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

Numărul de pagini indexate față de autoritatea site-ului

03:52 „Deci ați recomandat de mai multe ori în trecut ca site-urile mari […] să se concentreze pe un set mai mic de pagini […]. Site-ul la care lucrez acum, avem […] cam 1.000 de pagini care nu primesc trafic, care sunt vechi, așa că am recomandat să le eliminați. Dar există o întrebare pe care o are echipa noastră de dezvoltatori că aveau impresia că, cu cât Google a indexat mai multe pagini ale site-ului dvs., cu atât o autoritate mai mare îi atribuie site-ului și sunt reticenți în a elimina orice pagini. Ai putea să faci puțină lumină în acest sens?”

După cum a spus John, „Cu siguranță nu este cazul că dacă aveți mai multe pagini indexate, credem că site-ul dvs. este mai bun. […] Uneori, are sens să ai o mulțime de pagini indexate. Uneori, sunt un fel de pagini utile de indexat așa. Dar nu este un semn de calitate în ceea ce privește câte pagini sunt indexate. Și mai ales dacă vorbiți despre […] 1.000, 2.000, 5.000 de pagini, acesta este un număr destul de mic pentru sistemele noastre în general. Și nu este că am spune că 5.000 de pagini este mai bine decât 1.000 de pagini. Pentru noi, totul este ca și cum, ei bine, este un site web mic și ne descurcăm cu ceea ce putem scoate acolo. Și, desigur, site-ul mic este relativ. Nu este ca și cum ai spune că este un site web irelevant. Poate fi mic, dar poate fi totuși foarte util […]”.

Evaluarea scopului principal al unui site web

10:03 „Ultima dată am vorbit despre unele probleme cu site-ul […] – este un site de comerț electronic unde avem informații și chestii tranzacționale. […] Sfatul dumneavoastră a fost să separați puțin acest conținut în pagini orientate spre tranzacții și pagini orientate spre informații. Deci am o altă întrebare în legătură cu asta. Dacă aveți, să zicem, un site de comerț electronic și aveți un blog uriaș, sau o revistă sau ceva de genul ăsta în care aveți o mulțime de informații, dar este o secțiune veche. Și pe de altă parte, aveți toate aceste pagini de produse, categorii și așa mai departe. Așadar, acest bloc uriaș cu lucruri pur informaționale ar oferi întregului site web o notă informativă sau un caracter, astfel încât Google să spună, oh, nu suntem siguri dacă acesta este […] ceva în care oamenii pot obține informații mai degrabă decât să cumpere lucruri, sau este această evaluare făcută pe pagină?”

John a spus: „[…] Înțeleg că aceasta este mai mult o chestie la nivel de pagină. […] Multe site-uri web au doar o combinație de diferite tipuri de conținut. Și apoi încercați să vă dați seama care dintre aceste pagini se potrivește cu intenția celui care caută și încercați să le clasați corespunzător. […]

Adică, vezi asta cu site-urile de știri des. […] Au evenimentele recente, dar au și secțiuni pentru evenimente mai vechi care au avut loc, sau […] pentru alte evenimente mari, au cam o secțiune de arhivă izolată. Și acestea sunt intenții foarte diferite, dacă vrei ceva cu adevărat acum care se întâmplă sau dacă vrei un fel de cercetare informațională, conținut de tip evergreen.

[…] Trebuie să ne uităm la el pe pagină și să nu spunem, oh, acesta este un site web de cercetare pentru că există un conținut de cercetare aici”.

Redirecționarea link-urilor

13:21 „Vedem că oamenii fac linkuri către […] subcategoria noastră, să zicem, de pagini. Și problema este că […] conținutul nostru vine și pleacă, ceea ce înseamnă că uneori apare mai mult conținut în anumite categorii. Uneori, conținutul este șters. Și astfel pot fi create și pot dispărea și subcategorii. Și vedem o grămadă de recomandări de la backlink-uri, deoarece se leagă la subcategorii care nu mai există. Întrebarea mea aici este: este OK să redirecționezi […] aceste link-uri către categoria părinte. Și dacă facem așa, cum facem asta – cu 302, de exemplu? Ca o redirecționare temporară, pentru că în viitor, această subcategorie ar putea fi din nou populată cu conținut, […] nu este o redirecționare permanentă”.

John a răspuns: „Deci, dacă vedem că acest lucru se întâmplă la o scară mai mare, pe care îl redirecționați la nivelul părintelui, probabil că am vedea asta ca un soft 404. […] Și în loc de un cod 404, redirecționați și poate asta este mai bine pentru utilizatori, dar îl vedem ca un 404. […] Dacă are sens din punctul de vedere al utilizatorului să redirecționez, atunci aș merge doar pentru asta.

[…] În ceea ce privește 301 sau 302, nu cred că are importanță acolo, pentru că ori am vedea asta ca un soft 404, ori am vedea-o ca o întrebare de canonizare. Dacă este un soft 404, atunci codul nu contează. Dacă este o întrebare de canonizare, atunci se rezumă la ce adresă URL arătăm în rezultatele căutării. Și de obicei, cel de nivel superior va avea oricum semnale mai puternice și ne vom concentra pe cel de nivel superior. Deci nu contează dacă este un 301 sau un 302 în acest caz.

[…] Dacă îl vedem ca un soft 404, […] am încetini accesarea cu crawlere a acelei adrese URL pentru că nu există nimic aici […]. Dacă îl vedem ca o redirecționare […], nu trebuie să accesăm cu crawlere acest lucru în fiecare zi, deoarece ne concentrăm pe adresa URL principală. Așa că cred că în ambele cazuri, am încetini accesul cu crawlere a acelei adrese URL până când primim semnale noi care ne spun, de fapt, că acesta este poate ceva nou din nou. […] Ar fi ca o legătură internă sau un fișier de hartă de site […]. Și acesta ar fi semnul mai puternic pentru noi să ne târâm din nou. Dar cred că încetinirea crawling-ului ar fi similară în toate aceste cazuri.

[…] Cred că doar [actualizarea] hărților site-ului nu este suficient. M-aș asigura că și legătura internă este clară ”.

Recuperare din actualizările de bază

18:34 „Așa că în urmă cu aproximativ un an, am văzut o scădere semnificativă a traficului. După audit, […] toate semnalele au indicat că site-ul avea probleme de calitate. Am reușit să rezolvăm aceste probleme până în luna februarie a acestui an. Și până la actualizarea de bază din iunie, am văzut unele creșteri. Dar încă nu este la nivelul la care eram înainte de scădere cu aproximativ un an în urmă. Deci întrebarea mea este problemele legate de calitatea site-ului, dacă acesta a fost cazul, aceasta este recuperarea la care ne putem aștepta sau ne putem aștepta la o recuperare mai mare dacă credem că am abordat toate problemele identificate […]?”

John a spus: „[…] Nu este atât de mult încât am considera că este o situație în care trebuie să repari ceva. Dar mai degrabă […] dacă lucrezi la îmbunătățirea relevanței site-ului tău web, atunci […] ai un site web mai bun. Deci nu este că […] îl vom schimba înapoi la starea anterioară. […] Nu este la fel sau nu este comparabil cu înainte, așa că ar fi cam dificil să ne așteptăm să se schimbe în starea în care era înainte […].

[…] Cu actualizările de bază, nu ne concentrăm atât de mult pe probleme individuale, ci mai degrabă pe relevanța site-ului în ansamblu . Și asta poate include lucruri precum gradul de utilizare și reclamele de pe o pagină, dar este, în esență, site-ul în general. Și, de obicei, asta înseamnă, de asemenea, concentrarea conținutului, modul în care prezentați lucrurile, modul în care clarificați utilizatorilor ce se află în spatele conținutului, cum ar fi care sunt sursele […] . Dacă doriți cu adevărat ca Google să vă vadă site-ul web ca pe ceva semnificativ mai bun, probabil că trebuie să lucrați și la partea de conținut .

[…] Gândiți-vă unde ar putea fi conținut de calitate scăzută, unde ar putea fi confuzi utilizatorii când merg pe site-ul meu. Și această confuzie este ceva ce putem aborda cu probleme tehnice, cu modificări UX? Sau chiar trebuie să schimbăm o parte din conținutul pe care îl prezentăm?”

Link-uri în postările invitaților

28:24 „[…] Dacă [un site web are] o postare pentru oaspeți, iar Google nu știe dacă este plătită sau nu, cum va determina Google că [ar trebui] să ia acest link sau să ardă acest link? Care este răspunsul, astfel încât să fim în siguranță din toate unghiurile?”

Potrivit lui John, „[…] Îndrumarea noastră pentru link-uri și postări pentru invitați este că acestea ar trebui să nu fie urmărite . […] Aș fi foarte atent să mă asigur că linkurile nu sunt urmărite, astfel încât să promovați conștientizarea, să vorbiți despre ceea ce faceți, să faceți acest lucru astfel încât utilizatorii să poată merge la dvs. pagină. Dar, în esență, este o reclamă pentru afacerea ta. Deci, din acest punct de vedere, le-aș face doar să nu-i urmărească”.

Prețul produsului ca factor de clasare

32:25 „Dacă există două site-uri de comerț electronic concurente care vând exact același produs – un site oferă produsul la 500 USD, celălalt la 100 USD, toate semnalele SEO sunt egale. Site-ul web mai puțin costisitor ar avea șanse mai mari de a se clasa, deoarece există o astfel de diferență de preț pentru exact același produs?”.

John a spus: „Deci pur din punct de vedere al căutării pe web, nu. Nu este cazul în care am încerca să recunoaștem un preț pe o pagină și să-l folosim ca factor de clasare. Deci nu este cazul în care am spune că îl vom lua pe cel mai ieftin și îl vom clasa mai sus […].

Cu toate acestea, multe dintre aceste produse ajung, de asemenea, în rezultatele căutării de produse, ceea ce ar putea fi pentru că trimiteți un feed sau pentru că recunoaștem informațiile despre produse de pe aceste pagini. Și rezultatele căutării de produse, nu știu cum sunt comandate. S-ar putea să ia în considerare prețul sau lucruri precum disponibilitatea […].

Deci, din punct de vedere al căutării pe web, nu ținem cont de preț. Din punct de vedere al căutării de produse, este posibil . Și partea dificilă, cred, ca un SEO este, aceste aspecte diferite ale căutării sunt adesea combinate într-o singură pagină cu rezultatele căutării, unde veți vedea rezultate web normale și poate veți vedea unele rezultate ale produselor în lateral, sau poate veți vedea un amestec din asta […]”.

Mutarea adreselor URL între sitemapurile

34:04 „Dacă avem 200 de fișiere de hartă de site și 20% până la 30% dintre adresele URL trec de la un fișier la altul în fiecare săptămână, cât de rău poate fi? Sau ar trebui să ne păstrăm strict URL-urile în același fișier pentru totdeauna?”

„[…] Recomandarea noastră este de obicei să păstrăm aceeași adresă URL în același fișier sitemap . Motivul principal pentru aceasta este că procesăm fișierele sitemap la rate diferite. Prin urmare, dacă mutați o adresă URL dintr-un fișier sitemap în altul, este posibil să avem aceeași adresă URL în sistemele noastre din mai multe fișiere sitemap. Și dacă aveți informații diferite pentru această adresă URL – cum ar fi diferite date de modificare, de exemplu – atunci nu am ști ce atribut să folosim efectiv.

Deci, din acest punct de vedere, dacă îl aveți întotdeauna în același fișier sitemap, atunci ne este mult mai ușor să spunem, oh, avem informațiile pentru această adresă URL aici și putem avea încredere în acele informații, deoarece sunt doar acolo. Așa că este ceva în care încerc să evit […] aceste adrese URL care se amestecă la întâmplare. Dar, în același timp, de obicei nu va întrerupe procesarea fișierului sitemap. Și cu siguranță nu va avea un efect de clasare pe site-ul dvs. Deci nu există nimic în sistemul nostru de hărți de site care să corespundă calității unui site web ”.

Conținut multi-regional

38:13 „Lucrez pe verticala știrilor. Echipa mea caută să ne extindă prezența internațională și a lucrat pentru a crea subdirectoare multi-regionale. În cea mai mare parte, paginile din diferitele ediții multiregionale vor arăta la fel. Pagina de pornire și paginile secțiunilor precum politica sau stilul de viață vor avea conținut similar minus câteva piese unice în regiune.

Articolele sunt complicate. Nu putem diferenția prea multe subdirectoare multi-regionale în afara modulelor cu linkuri aferente, ceea ce ne face îngrijorat de problemele de conținut duplicat. Cum gestionează Google conținutul duplicat în spațiul de știri? […] Conținutul rămâne același, dar elementele șablonului sunt diferite. Ar trebui să existe un singur canonic pe toate site-urile web multiregionale?”

Răspunsul lui John a fost: „[…] Se pare că acestea sunt regiuni diferite din aceeași țară și conținutul în aceeași limbă. […] Dacă acestea sunt țări diferite, atunci aveți aspectul de direcționare geografică, care joacă un rol în cazul în care acestea sunt limbi diferite. Deci, dacă lucrați, să zicem, în Europa și acoperiți Germania, Franța, Italia sau ceva, atunci aveți și limbi diferite.

[…] Dar dacă vorbiți despre aceeași țară, conținut în aceeași limbă, atunci […] este puțin mai ușor pentru că nu trebuie să vă faceți griji pentru toate aceste conexiuni tehnice. Dar, pe de altă parte, problemele de conținut duplicat sunt mult mai vizibile. Și când vine vorba de conținut duplicat, aspectul complicat pe site-uri ca acestea este că, în esență, ajungi să concurezi cu tine însuți. Și dacă aveți un articol de știri pe care îl publicați pe […] cinci sau șase site-uri web regionale diferite, atunci toate aceste site-uri web regionale diferite încearcă să se claseze exact pentru același articol. Și asta ar putea duce la faptul că articolul respectiv nu se clasifică la fel de bine cum ar fi altfel.

Din această cauză, aș recomanda să încercați să găsiți adrese URL canonice pentru aceste articole individuale, astfel încât să puteți spune cu adevărat „ei bine, am acest articol pe cele cinci site-uri web regionale, dar aceasta este versiunea mea preferată pe care vreau să o văd în căutare'. Și apoi ne putem concentra toată energia, toate semnalele noastre, pe acea versiune preferată și putem încerca să o clasificăm puțin mai bine. Nu trebuie să fie aceeași versiune tot timpul. Deci, poate fi cu siguranță cazul că aveți un articol de știri care se află într-o regiune cam canonic, un articol de știri diferit este mai canonic pentru o altă regiune. Modul în care alegeți regiunea pe care o alegeți ca canonică depinde în totalitate de dvs. […] De obicei, ai încerca să-ți dai seama unde este cel mai relevant și ai alege-o ca versiune canonică. Deci asta este pentru articolele individuale în sine.

Pentru categorii, secțiuni și pagini de start, se pare că ar fi ceva în care conținutul este mai unic și mai specific regiunilor individuale. Și din această cauză, aș încerca să le păstrez separate la nivel de index. Deci, dacă aveți cinci site-uri web regionale diferite, pagina lor de pornire, secțiunile lor de categorii, toate ar fi indexate individual. Și articolele de știri în sine ar fi mapate la una dintre aceste regiuni diferite. Așa că acesta este un fel de abordare pe care o recomandăm acolo […].

Și această abordare […] funcționează pentru diferite nume de domenii. Deci, dacă aveți domenii diferite pentru regiuni individuale, dar toate fac parte din același grup de știri, puteți face în continuare această schimbare canonică între diferitele versiuni. Dacă o faci în același domeniu cu subdirectoare, e bine”.

Redirecționare într-o mutare a site-ului

44:34 „Care este cel mai bun curs de acțiune de luat atunci când trebuie să redirecționați 301 toate adresele URL către un nou set de adrese URL? Numărul de pagini va fi de peste un milion și doriți să minimizați efectul sandbox? Dacă există un efect sandbox, cât ar putea dura? Am pierde clasamentul pe care s-ar putea să nu ne mai recuperăm niciodată? Intenționăm să facem o redirecționare unu-la-unu și am solicitat redirecționări în loturi, dar aceasta nu este o posibilitate, așa că paginile, imaginile, URL-urile etc. ar trebui să se răstoarne în același timp”.

După cum a spus John: „Pentru mine, aceasta sună ca o situație tradițională de mutare a site-ului. Treci de la un domeniu la altul și redirecționezi toate adresele URL de pe vechiul tău site către unul nou, iar noi trebuie să ne ocupăm de asta […]. Cu siguranță nu există nimic definit ca efect sandbox din partea noastră când vine vorba de mutarea site-ului . Deci, dacă trebuie să faceți o mutare a site-ului, atunci faceți o mutare a site-ului și redirecționați toate paginile dvs. Adesea, cea mai ușoară abordare este să redirecționați toate paginile simultan. Sistemele noastre sunt, de asemenea, reglate puțin la asta pentru a încerca să recunoască asta. Deci , când vedem că un site web începe să redirecționeze toate paginile către un alt site web, atunci vom încerca să-l reprocesăm puțin mai repede , astfel încât să putem procesa acea mișcare a site-ului cât mai repede posibil. Și cu siguranță nu este cazul în care am spune, oh, fac o mutare a site-ului, prin urmare, vom încetini lucrurile […]”.

API și bugetul de accesare cu crawlere

46:13 „Am un site web care se conectează la API-uri din partea clientului pentru a obține date. Sunt acele adrese URL incluse în bugetul de accesare cu crawlere? Dacă interziceți acele adrese URL, […] ar crea asta vreo problemă?”

„[…] Dacă aceste API-uri sunt incluse atunci când o pagină este redată, atunci da, vor fi incluse în accesare cu crawlere și vor fi luate în considerare pentru bugetul dvs. de accesare cu crawlere, în esență, deoarece trebuie să accesăm cu crawlere acele adrese URL pentru a reda pagina. Le puteți bloca prin robots.txt dacă preferați să nu fie accesate cu crawlere sau să nu fie utilizate în timpul redării. Depinde total de tine dacă preferi să faci asta. Mai ales dacă aveți un API care este cam costisitor de întreținut sau necesită o mulțime de resurse, atunci uneori, asta are sens.

Partea dificilă, cred, este că, dacă interziceți accesarea cu crawlere a punctului final API, nu vom putea folosi date despre returnările API pentru indexare. Deci, dacă conținutul paginii dvs. provine exclusiv din API și nu permiteți accesarea cu crawlere a API-ului, nu vom avea acel contact. […] Dacă API-ul face doar ceva suplimentar paginii, cum ar fi poate desenează o hartă sau […] o grafică a unui tabel numeric pe care îl aveți pe o pagină, […] atunci poate că nu contează dacă acel conținut nu este nu este inclus în indexare. Un alt lucru este că, uneori, nu este banal modul în care funcționează o pagină atunci când API-ul este blocat. În special, dacă utilizați JavaScript și apelurile API sunt blocate din cauza robots.txt, atunci trebuie să gestionați această excepție cumva. Și, în funcție de modul în care încorporați JavaScript în pagină, de ce faceți cu API-ul, trebuie să vă asigurați că încă funcționează. Deci, dacă acel apel API nu funcționează și apoi restul redării paginii se întrerupe complet, atunci nu putem indexa prea mult pentru că nu mai este nimic de randat.

Cu toate acestea, dacă apelul API se întrerupe și putem indexa în continuare restul paginii dvs., atunci s-ar putea să fie perfect. […] Cred că este mai complicat dacă rulați un API pentru alți oameni, pentru că, dacă nu permiteți accesarea cu crawlere, atunci aveți un efect de ordinul doi că site-ul altcuiva ar putea depinde de API-ul dvs. Și, în funcție de ceea ce face API-ul tău, dintr-o dată, site-ul lor nu are conținut indexabil. Și s-ar putea să nu observe, pentru că nu au fost conștienți că, dintr-o dată, ați adăugat o interdicție acolo. Și asta ar putea provoca un fel de efecte indirecte […]”.

JavaScript și cache Google

49:36 „Deci sunt două pagini care provin din același domeniu. URL-ul este puțin diferit, care face parte din aceeași structură de directoare. Și […] sunt generate de NextJS. Deci NextJS este un cadru de reacție redat pe partea de server. Și sunt indexate, dar văd o pagină în memoria cache Google, iar a doua pagină nu este în memoria cache Google. Și văd același model, indiferent de modul în care generez pagina […]. Majoritatea paginilor mele sunt în cache Google, dar acum sunt îngrijorat pentru că în prezent trec de la stiva mea de tehnologie bazată pe Java, care generează toate aceste pagini, la Google NextJS. […] Când depanam, am descoperit că aceasta este și o problemă cu stiva Java mai veche pe care o folosim.

Deci întrebarea este în două părți. Practic, de ce acest comportament? Și a doua este, va afecta acest comportament clasamentul meu? Văd acele pagini care apar în rezultatele căutării care nu sunt în cache Google”.

John a răspuns: „[…] Paginile cache sunt complet separate de ceea ce indexăm. Deci , dacă există sau nu o pagină de cache, nu contează deloc pentru clasare, nu contează deloc pentru indexare . Uneori, există motive tehnice pentru care nu avem o pagină de cache. Uneori, pur și simplu nu avem o pagină de cache pentru adrese URL individuale. Celălalt lucru este că dacă pagina folosește un cadru JavaScript, atunci dacă JavaScript rulează sau nu pe o pagină cache este uneori dificil, deoarece pagina cache este găzduită pe un domeniu Google. În funcție de tipul de JavaScript pe care îl aveți, de unde trage fișierele JavaScript, uneori, JavaScript nu poate rula pe domeniul Google.

[…] Pagina cache nu este pagina redată. În esență, este doar fișierul HTML pe care l-am solicitat și o copie a acestuia. Și dacă fișierul HTML arată ceva, este în regulă. Dacă folosește JavaScript și JavaScript nu rulează deoarece este o pagină cache, este la fel de bine. Pur și simplu nu îl vedeți în pagina de cache. Deci, dacă pagina de cache nu apare, nu mi-aș face griji pentru asta. Acesta nu este un semn al vreunei probleme. Și adesea, […] nu poți controla dacă există sau nu o pagină cache. Pur și simplu aș ignora asta”.

https://www.youtube.com/watch?v=Vd0rEQrwHDc