Program SEO, 3 iunie 2022

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

Pot folosi două coduri de rezultat HTTP pe o pagină?

1:22 „[…] Este teoretic posibil să aveți două coduri de rezultat HTTP diferite pe o pagină, dar ce va face Google cu acele două coduri? Le va vedea Google? Și dacă da, ce va face Google? De exemplu, un 503 plus un 302.”

Răspunsul lui John a fost: „[…] Cu codurile de rezultat HTTP, puteți include o mulțime de lucruri diferite. Google va analiza primul cod de rezultat HTTP și, în esență, îl va procesa.

Și , teoretic, puteți avea în continuare două coduri de rezultat HTTP sau mai multe acolo dacă sunt redirecționări care duc la o pagină finală. Deci, de exemplu, ați putea avea o redirecționare de la o pagină la alta. Acesta este un cod de rezultat. Și apoi pe acea altă pagină, ați putea difuza un alt cod de rezultat. Deci ar putea fi o redirecționare 301 către o pagină 404 […]. Și din punctul nostru de vedere, în acele situații în lanț în care putem urmări redirecționarea pentru a obține un rezultat final, în esență ne vom concentra doar pe acel rezultat final.

Și dacă acel rezultat final are conținut, atunci acesta este ceva pe care am putea să-l folosim pentru canonizare. Dacă rezultatul final este o pagină de eroare, atunci este o pagină de eroare. Și asta e în regulă și pentru noi.”

Folosirea unui CDN îmbunătățește clasamentul dacă site-ul meu este deja rapid în țara mea principală?

2:50 „[…] Primim cea mai mare parte a traficului nostru dintr-o anumită țară. Ne-am găzduit site-ul web pe un server situat în acea țară. Sugerați să puneți întregul nostru site web în spatele unui CDN pentru a îmbunătăți viteza paginii pentru utilizatorii la nivel global sau nu este necesar în cazul nostru?”

John a răspuns: „ Nu cred că ar avea deloc un efect mare asupra Google în ceea ce privește SEO.

Singurul efect în care mi-aș putea imagina că s-ar putea întâmpla ceva este ceea ce utilizatorii ajung să vadă. […] Dacă majoritatea utilizatorilor tăi văd deja un site web foarte rapid, deoarece serverul tău se află acolo, atunci […] faci ceea ce trebuie. Dar, desigur, dacă utilizatorii din alte locații văd un rezultat foarte lent, pentru că poate că conexiunea cu țara ta nu este atât de bună, atunci s-ar putea să ai câteva oportunități de a îmbunătăți acest lucru.

[…] Dacă există ceva ce poți face pentru a îmbunătăți lucrurile la nivel global pentru site-ul tău, cred că este o idee bună. Nu cred că este critic […]. Dar este ceva ce poți face pentru a […] să-ți dezvolți site-ul web dincolo de țara ta actuală.

Poate ar trebui să clarific un lucru, dacă accesarea cu crawlere a Google este cu adevărat, foarte lentă, atunci desigur că poate afecta cât de mult putem accesa cu crawlere și indexăm de pe site […]. Nu am văzut asta ca fiind o problemă în ceea ce privește niciun site web care nu are milioane și milioane de pagini mari […].

Puteți verifica din nou cât de repede se accesează cu crawlere Google în Search Console și statisticile de accesare cu crawlere. Și dacă pare rezonabil, chiar dacă nu este foarte rapid, atunci nu mi-aș face griji pentru asta.”

Ar trebui să interzic solicitările API pentru a reduce accesul cu crawlere?

5:20 „[…] Site-ul nostru cheltuiește în prezent aproximativ 20% din bugetul de accesare cu crawlere pe subdomeniul API, încă 20% pe miniaturile de imagini ale videoclipurilor. Niciunul dintre aceste subdomenii nu are conținut care să facă parte din strategia noastră SEO. Ar trebui să interzicem accesarea cu crawlere a acestor subdomenii sau cum sunt descoperite sau utilizate punctele finale API?”

După cum a spus John, „[…] În multe cazuri, punctele finale API ajung să fie folosite de JavaScript pe un site web și vă vom reda paginile. Și dacă accesează un API care se află pe site-ul dvs., atunci vom încerca să încărcăm conținutul din acel API și să îl folosim pentru redarea paginii.

Și, în funcție de modul în care este configurat API-ul și cum este configurat JavaScript, s-ar putea să ne fie greu să memorăm în cache rezultatele API-ului, ceea ce înseamnă că poate accesăm cu crawlere multe dintre aceste solicitări API pentru a încerca să obținem o versiune redată. paginilor dvs., astfel încât să le putem folosi pentru indexare. Deci, de obicei, acesta este locul unde se descoperă asta. Și asta este ceva pe care îl puteți ajuta, asigurându-vă că rezultatele API-ului pot fi stocate în cache, că nu injectați nicio marca de timp în adrese URL […] când utilizați JavaScript pentru API […].

Dacă nu vă pasă de conținutul care este returnat cu aceste puncte finale API, atunci, desigur, puteți bloca accesarea cu crawlere a întregului subdomeniu cu fișierul robots.txt. Și asta va bloca în esență toate aceste solicitări API.

[…] În primul rând trebuie să vă dați seama, sunt aceste rezultate API […] fac parte din […] conținut critic pe care vreau să îl indexez de la Google? Și dacă da, atunci probabil că nu ar trebui să blocați accesarea cu crawlere. Dar dacă […] […] generează ceva […] care nu este critic pentru paginile tale […], atunci ar putea fi util să verifici din nou cum arată când sunt blocate.

Și o modalitate prin care puteți verifica acest lucru este dacă ați putea crea o pagină de testare separată care să nu apeleze API-ul sau care să folosească o adresă URL întreruptă pentru punctul final API. […] Puteți vedea cum se redă de fapt această pagină în browserul meu? Cum se redă pentru Google?”

Ar trebui să folosesc rel="nofollow” pe link-urile interne?

8:05 „Este adecvat să folosim un atribut nofollow pe link-urile interne pentru a evita solicitările inutile ale crawler-urilor către adrese URL pe care nu dorim să fie accesate cu crawlere sau indexate?”

Iată cum a răspuns John: „[…] Cred că, în cea mai mare parte, are foarte puțin sens să folosești nofollow pe link-urile interne. Dar dacă asta e ceva ce vrei să faci, mergi.

În cele mai multe cazuri, voi încerca să fac ceva de genul utilizării rel=canonical pentru a indica adrese URL pe care doriți să le indexați sau să folosesc robots.txt pentru lucruri pe care nu doriți să le fi accesat cu crawlere.

Încercați să vă dați seama, este mai degrabă un lucru subtil […] pe care preferați să îl indexați și apoi să utilizați rel=canonic pentru asta? Sau este ceva în care spui – de fapt, când Googlebot accesează aceste adrese URL, provoacă probleme serverului meu. Determină o sarcină mare. Face totul foarte lent. E scump sau ce ai tu.

Și pentru aceste cazuri, aș interzice accesarea cu crawlere a acelor URL-uri. […] Cu rel=canonic, evident, va trebui mai întâi să accesăm pagina respectivă pentru a vedea rel=canonical. Dar, de-a lungul timpului, ne vom concentra asupra canonicului pe care l-ați definit. Și îl vom folosi pe acesta în primul rând pentru accesarea cu crawlere și indexare.”

Există vreo modalitate de a forța sitelinkurile să apară?

16:02 „Există vreo strategie prin care paginile dorite pot apărea ca link de site în rezultatele Căutării Google?”

John a clarificat că „[…] Nu există metaetichetă sau date structurate pe care le puteți folosi pentru a impune afișarea unui link de site .

[…] Sistemele noastre încearcă să descopere ce este […] legat sau relevant pentru utilizatori atunci când se uită la această singură pagină web […]? […] Recomandarea noastră este, în esență, să avem o structură bună a site-ului web, să avem legături interne clare, astfel încât să ne fie ușor să recunoaștem ce pagini sunt legate de acele pagini și să avem titluri clare pe care să le putem folosi și […] să le arătăm ca un link de site.

[…] Nu este că există o garanție că toate acestea vor fi arătate așa. Dar ne ajută să ne dăm seama ce are legătură. Și dacă credem că are sens să arătăm un link de site, atunci ne va fi mult mai ușor să alegem unul pe baza acestor informații.”

Site-ul nostru încorporează PDF-uri cu iframe, ar trebui să OCR textul?

17:14 „Site-ul nostru web folosește cadre iframe și un script pentru a încorpora fișiere PDF în paginile noastre și pe site-ul nostru. Există vreun avantaj să luați textul OCR al PDF-ului și să-l lipiți undeva în HTML-ul documentului în scopuri SEO sau Google va analiza pur și simplu conținutul PDF cu aceeași greutate și relevanță pentru a indexa conținutul?"

John a răspuns: „[…] Se pare că doriți să luați textul PDF-ului și […] să-l ascundeți în HTML în scopuri SEO. Și asta este ceva pe care cu siguranță nu l-aș recomanda să fac. Dacă doriți să aveți conținutul indexabil, faceți-l vizibil pe pagină.

[…] Încercăm să scoatem textul din PDF-uri și să îl indexăm pentru PDF-urile în sine. Din punct de vedere practic, ceea ce se întâmplă cu un PDF este ca unul dintre primii pași, îl convertim într-o pagină HTML și încercăm să-l indexăm ca pe o pagină HTML. […] Ceea ce faci este […] să încadrezi o pagină HTML indirectă. Și când vine vorba de iframe, putem lua în considerare acel conținut pentru indexare în pagina principală. Dar se poate întâmpla oricum să indexăm PDF-ul separat. […] Aș întoarce întrebarea și aș încadra-o ca ce vrei să se întâmple?

Și dacă doriți ca paginile dvs. web obișnuite să fie indexate cu conținutul fișierului PDF, atunci faceți astfel încât acel conținut să fie imediat vizibil pe pagina HTML. Așadar, în loc să încorporați PDF-ul ca element principal de conținut, faceți din conținutul HTML piesa principală și conectați la fișierul PDF.

Și apoi se pune întrebarea dacă vrei ca acele PDF-uri să fie indexate separat sau nu? Uneori doriți să aveți PDF-uri indexate separat. Și dacă doriți să le indexați separat, atunci conectarea la ele este grozavă.

Dacă nu doriți să le indexați separat, atunci este bine să folosiți robots.txt pentru a le bloca indexarea. De asemenea, puteți utiliza noindex [? x-roboți?] Antet HTTP. Este puțin mai complicat pentru că trebuie să serviți asta ca antet pentru fișierele PDF dacă doriți să aveți acele fișiere PDF disponibile în iframe, dar nu chiar indexate.”

Google accesează cu crawlere adresele URL în marcarea datelor structurate?

23:24 „Google accesează cu crawlere adresele URL situate în marcarea datelor structurate sau Google doar stochează datele?”

John a explicat că „În cea mai mare parte, când ne uităm la pagini HTML, dacă vedem ceva care arată ca un link, s-ar putea să încercăm și acel URL. […] Dacă găsim o adresă URL în JavaScript, putem încerca să o luăm și să încercăm să o folosim. Dacă găsim un link într-un fișier text de pe un site, putem încerca să îl accesăm cu crawlere și să îl folosim. Dar nu este chiar o legătură normală.

[…] Dacă doriți ca Google să se oprească și să acceseze cu crawlere acea adresă URL, asigurați-vă că există un link HTML natural către acea adresă URL , cu un text de ancorare clar, de asemenea, că oferiți câteva informații despre pagina de destinație.

Dacă nu doriți ca Google să acceseze cu crawlere respectiva adresă URL, atunci poate blocați-o cu robots.txt sau pe pagina respectivă, utilizați un rel=canonic care indică versiunea preferată, ceva de genul acesta. […] Nu aș presupune orbește că doar pentru că este în date structurate nu va fi găsit și nici nu aș presupune orbește că doar pentru că este în date structurate va fi găsit.

[…] În schimb, m-aș concentra pe ceea ce vrei să se întâmple acolo. Dacă doriți să îl vedeți ca un link, atunci faceți-l un link. Dacă nu doriți să fie accesat cu crawlere sau indexat, atunci blocați accesul cu crawlere sau indexarea […].”