Ecommerce SEO: Optimizarea crawling-ului

Optimizarea crawling-ului pentru site-urile de comerț electronic

Lungime articol: 7 460 de cuvinte
Timp estimativ de citire: 50 de minute

Aceasta este cea de-a treia secțiune a cursului de SEO pentru ecommerce. Pentru a citi celelalte capitole, folosiți link-urile de mai jos.

1. Arhitectura website-urilor
2. Cercetarea cuvintelor cheie
3. Optimizarea crawling-ului
4. Link-ingului intern
5. Paginile de start (Home Pages)
6. Paginile de listare (PLP) și categorii (CAT)
7. Paginile cu detalii despre produs (PDP)

Optimizarea acțiunii de crawling (parcurgerea site-ului de către roboții motoarelor de căutare) are rolul de a ajuta motoarele de căutare să descopere cât mai eficient URL-rile. Paginile relevante trebuie să fie ușor de găsit, în timp ce paginile mai puțin importante nu ar trebui să risipească așa-numitul „buget de crawling” și nu ar trebui să pună capcane roboților. Bugetul de crawling este definit ca numărul de URL-uri pe care motoarele de căutare pot și vor să îl analizeze.

Motoarele de căutare atribuie un buget de crawling fiecărui website, în funcție de autoritatea acestuia. În general, autoritatea unui site este cumva proporțională cu PageRank-ul său.

Conceptul bugetului de crawling este esențial pentru website-urile de e-commerce, deoarece acestea cuprind de regulă un număr uriaș de URL-uri – de la câteva zeci la mii și milioane.

Dacă arhitectura tehnică bagă roboții motoarelor de căutare (cunoscute, de asemenea, sub numele de robot, bot sau spider) în bucle infinite și alte capcane, bugetul de crawling va fi irosit pe pagini care nu sunt importante pentru utilizatori sau motoarele de căutare. Această risipă poate duce la ignorarea unor pagini importante de către indicatorii motoarelor de căutare.

În plus, optimizarea operațiunii de crawling permite website-urilor mari să profite de oportunitatea de a avea doar paginile cruciale indexate și paginile cu un PageRank mai mic analizate mai frecvent.[1]

Numărul de URL-uri pe care Google le poate indexa a crescut dramatic odată cu introducerea arhitecturii Percolator[2], după actualizarea “Caffeine”.[3] Totuși, este încă important să verificați ce resurse cer roboții motoarelor de căutare pe website și să prioritizați acțiunea de crawling în funcție de acestea.

Înainte de a începe, este important să înțelegem că acțiunea de crawling și cea de indexare reprezintă două procese diferite. Crawling se referă doar la preluarea fișierelor de pe website-uri (fetching). Indexarea înseamnă analizarea fișierelor și luarea unei decizii cu privire la meritul lor de a fi incluse. Astfel, chiar dacă motoarele de căutare fac crawling pe o pagină, nu o vor indexa neapărat.

Crawling este influențat de mai mulți factori, precum structura website-ului, linking-ul intern, autoritatea domeniului, accesibilitatea URL-urilor, prospețimea conținutului, frecvența actualizărilor și setările legate de rata de crawling din Google Search Console sau Bing Webmaster.

Înainte de a detalia acești factori, trebuie să urmăriți și să monitorizați roboții de urmărire.

Urmărirea și monitorizarea roboților de căutare

Googlebot, Yahoo! Slurp, și Bingbot sunt “roboți politicoși”,[4] ceea ce înseamnă că mai întâi vor respecta directivele de crawling găsite în fișierele robots.txt, înainte de a solicita resursele de pe website. Roboții politicoși se vor identifica serverului web, astfel încât îi puteți controla după cum doriți. Solicitările făcute de roboți sunt stocate în fișierele log și sunt disponibile pentru a fi analizate.

Instrumentele webmaster, precum cele puse la dispoziție de Google și Bing, dezvăluie doar o mică parte a ceea ce roboții fac pe website – de ex., pe câte pagini fac crawling sau date legate de utilizarea lățimii de bandă (bandwith). Aceste informații vă sunt utile într-un fel, dar nu sunt suficiente.

Pentru perspective cu adevărat utile trebuie să analizați fișierele de înregistrare a traficului (traffic log files). Din acestea veți putea extrage informațiile care vă pot ajuta să identificați problemele la scară mare.

În mod tradițional, analiza fișierelor log era efectuată folosind lina de comandă grep cu expresii regulate. Dar, în ultima vreme, există și soluții desktop și web care ușurează acest tip de analiză tehnică și o fac mai accesibilă comercianților.

Pe website-urile de e-commerce, fișierele lunare log sunt imense de obicei – gigabyte sau chiar terabyte de date. Totuși, nu aveți nevoie de toate datele din fișierele log pentru a urmări și monitoriza roboții motoarelor de căutare. Nu aveți nevoie decât de rândurile generate de solicitările roboților. Astfel, puteți reduce semnificativ dimensiunea fișierelor log de la gigabytes, la megabytes.

Folosind următoarea comandă Linux (comanda e sensibilă la majuscule) veți extrage doar rândurile care conțin “Googlebot”, dintr-un fișier log (access_log.processed), în altul (googlebot.log):

grep “Googlebot” access_log.processed > googlebot.log

Pentru a extrage date similare pentru Bing și alte motoare de căutare, înlocuiți „Googlebot” cu alte nume de roboți.

Fișierul log a fost redus de la 162.5Mb la 1.4Mb.

 

Deschideți fișierul log specific robotului, mergeți la Data –> Text to Columns și folosiți Delimited with Space pentru a introduce datele fișierului log într-un format de tabel ca cel de mai jos:

C:\Users\Traian\AppData\Local\Temp\SNAGHTML231c431.PNG

Datele sunt filtrate după Status, pentru a obține o listă a tuturor erorilor 404 Not Found întâlnite de Googlebot.

 

Notă: puteți importa cel mult un milion de rânduri în Excel, dacă trebuie să importați mai multe, folosiți MS Access sau Notepad++.

Pentru a identifica rapid problemele de crawling la nivelurile paginilor de categorii, creați o diagramă a căutările Googlebot pentru fiecare categorie. Acum vedeți unul din avantajele navigării pe bază de categorii în structura URL-urilor?

Se pare că directorul /bracelets/ trebuie investigat, deoarece sunt prea puține solicitări ale roboților, în comparație cu alte directoare.

 

Prin pivotarea datelor fișierelor log după URL-uri și date de crawling, puteți identifica conținutul care este parcurs cel mai rar de Googlebot:

Datele când URL-urile au fost preluate (fetched).

 

În acest tabel pivot, puteți vedea că deși cele trei URL-uri sunt poziționate la același nivel în ierarhie, URL-ul numărul trei este supus mult mai des acțiunii de crawling decât celelalte două. Acesta este un semn că URL#3 este considerat mai important.

C:\Users\Traian\AppData\Local\Temp\SNAGHTML61a6f94.PNG

Mai multe backlink-uri externe și mențiuni pe platformele sociale ar putea conduce la o frecvență mai mare de crawling.

 

Iată câteva probleme și idei pe care să le aveți în vedere când analizați comportamentul roboților, folosind fișierele log:

  • Analizați erorile de răspuns ale serverului și identificați ce anume generează aceste erori.
  • Descoperiți paginile supuse inutil acțiunii de crawling și capcanele de parcurgere a URL-urilor.
  • Corelați zilele de la ultima acțiune de crawling cu poziționările; când faceți modificări pe o pagină, asigurați-vă că efectuați din nou crawling pentru ea. Dacă nu parcurgeți noua pagină, actualizările nu vor fi luate în calcul pentru poziționări decât după crawling-ul natural al Googlebot (poate dura luni de zile, pe site-urile cu număr mare de URL-uri).
  • Analizați dacă produsele listate în topul listărilor sunt supuse mai des acțiunii de crawling decât produsele listate pe paginile componente (listări paginate). Luați în calcul mutarea celor mai importante produse pe prima pagină, în loc să le lăsați pe paginile componente.
  • Verificați frecvența și adâncimea acțiunii de crawling.

Scopul urmăriri roboților este de a:

  • Determina pe ce se folosește bugetul de crawling.
  • Identifica solicitările inutile (de ex., link-uri de tipul “Scrie o recenzie” care deschid pagini cu același conținut, cu excepția numelui produsului, de ex., mysite.com/review.php?pid=1, mysite.com/review.php?pid=2 și așa mai departe).
  • Repara scurgerile.

În loc să irosiți bugetul pe URL-uri nedorite (de ex., URL-uri cu conținut duplicat), concentrați-vă pe trimiterea roboților la paginile care contează pentru voi și pentru utilizatorii site-ului.

O altă aplicație utilă a fișierelor log este aceea de a evalua calitatea backlink-urilor. Închiriați link-uri de pe diverse website-uri externe și îndreptați-le spre paginile fără alte backlink-uri (pagini cu detalii produse sau pagini care sprijină paginile cu detaliile produselor). Apoi, analizați activitatea roboților pe aceste pagini de pe site-ul vostru. Dacă frecvența de crawling crește, atunci acel link este mai valoros decât un link care nu crește deloc activitatea roboților. O creștere a frecvenței de crawling pe pagini sugerează că pagina de pe care ați obținut link-ul este supusă frecvent, de asemenea, acțiunii de crawling, ceea ce înseamnă că acea pagină are o autoritate bună. Odată ce ați identificat oportunitățile bune, încercați să obțineți link-uri naturale de pe acele website-uri.

Structura plată a website-ului

Dacă nu există alte impedimente tehnice în calea operațiunii de crawling a website-urilor mari (de ex., navigare fațetată care pot fi supusă procesului de crawling, sau spații infinite[5]), o structură plată a website-ului poate ajuta operațiunii de crawling permițând motoarelor de căutare să ajungă la paginile din profunzime doar în câțiva pași, folosind prin urmare într-un mod foarte eficient bugetul alocat.

Paginarea — sau, pentru a fi mai exacți, de-paginarea— este un mod de a aplatiza arhitectura website-ului vostru. Vom discuta despre paginare mai târziu, în secțiunea Paginile de Listare. .

Pentru mai multe informații despre arhitectura plată a website-ului, vezi secțiunea intitulată Conceptul de arhitectură plată din secțiunea Arhitectura Site-ului.

Accesibilitate

Voi face referire la accesibilitate din prisma optimizării pentru motoarele de căutare, și nu a accesibilității site-ului pentru utilizatori.

Accesibilitatea este, probabil, factorul critic al operațiunii de crawling. Bugetul de crawling este dictat de modul în care serverul răspunde traficului roboților. Dacă arhitectura tehnică a website-ului împiedică roboții motoarelor de căutare să acceseze URL-urile, atunci acele URL-uri nu vor fi indexate. URL-urile care sunt deja indexate dar nu pot fi accesate după câteva încercări nereușite, pot fi scoase din indicii motoarelor de căutare.

Google începe acțiunea de crawling a website-urilor noi la o rată foarte redusă, apoi crește treptat rata până la nivelul la care nu se creează probleme de accesibilitate pentru utilizatori sau serverul vostru.

Prin urmare, ce poate împiedica URL-urile și conținutul să fie accesibile?

DNS și probleme de conectivitate

Folosiți http://www.intodns.com/ pentru a verifica problemele legate de DNS. Orice este marcat cu roșu și galben necesită atenția voastră (chiar dacă este o înregistrare MX).

Raport de la intodns.com.

 

Folosind conturile webmaster Google și Bing, reparați toate problemele legate de DNS și conectivitate:

Raportul privind informațiile de crawling de la Bing.

C:\Users\Traian\Desktop\Site Errors Bad.png

Raportul Erori Site de la Google în versiunea veche a GSC.[6]

 

O problemă DNS căreia trebuie să îi acordați atenție este legată de înregistrările DNS wildcard, ceea ce înseamnă că web serverul răspunde cu un cod 200 OK la orice cerere a sub-domeniilor, chiar și pentru cele care nu există. O problemă și mai gravă legată de DNS este reprezentată de numele gazdă (hostnames) care nu pot fi recunoscute, ceea ce înseamnă că, căutarea DNS eșuează atunci când se încearcă rezolvarea numele domeniului.

Un comerciant avea o altă configurare DNS cu probleme. Două din domeniile de top ale codului de țară (ccTLDs)— US (.com) și UK (.co.uk)—trimiteau la același IP. Dacă aveți ccTLD-uri multiple, găzduiți-le pe IP-uri diferite (în mod ideal din țara pe care o aveți în vedere cu ccTLD) și verificați modul în care se rezolvă numele domeniului.

Evident, dacă serverele web au cedat, nimeni nu va putea accesa website-ul (inclusiv roboții motoarelor de căutare). Puteți arunca o privire asupra disponibilității site-ului vostru folosind instrumente de monitorizare precum Monitor.Us, Scoutt sau Site24x7.

Host load

Host load reprezintă numărul maxim de conexiuni simultane pe care un web server le poate suporta. Fiecare solicitare de încărcare a unei pagini de către Googlebot, Yahoo! Slurp, sau Bingbot generează o conexiune cu serverul vostru web. Deoarece motoarele de căutare folosesc crawling distribuit de pe mai multe computere în același timp, teoretic puteți atinge limita de conexiuni, și website-ul va ceda (mai ales dacă aveți un plan de găzduire comun cu alte site-uri).

Folosiți instrumente precum cele de pe loadimpact.com pentru a verifica câte conexiuni poate suporta website. Aveți grijă, totuși; site-ul poate deveni indisponibil sau poate chiar ceda în timpul acestui test.

Dacă website-ul se încarcă în sub două secunde când este folosit de un număr mare de vizitatori, totul este în regulă – (grafic generat de loadimpact.com).

 

Timpul de încărcare a paginii

Timpul de încărcare a paginii nu este doar un factor de crawling, ci și de poziționare (ranking) și ușurința utilizării (usability). Se spune că Amazon și-a crescut veniturile cu 1% pentru fiecare îmbunătățire de 100 ms a timpului de încărcare,[7] iar Shopzilla și-a crescut veniturile cu 7-12% scăzând timpul de încărcare a paginii cu cinci secunde.[8]

Există numeroase articole despre optimizarea vitezei de încărcare a paginii și pot fi destul de tehnice. Iată câteva aspecte sintetice privind modul în care puteți optimiza timpii de încărcare:

  • Amânați încărcarea imaginilor până când este necesară afișarea în browser.
  • Folosiți CSS sprites.
  • Folosiți protocoale HTTP2.

Amazon folosește CSS pentru a minimaliza numărul de solicitări către serverele lor.

 

Apple a folosit sprites pentru navigarea principală.

 

  • Folosiți rețele de livrare conținut (CDN) pentru fișierele media și alte fișiere care nu se actualizează prea des.
  • Implementați optimizarea bazei de date și a cache-ului (folosiți server-side caching).
  • Activați compresia HTTP și implementați funcționalitatea condițional GET.
  • Optimizați imaginile.
  • Folosiți expires headers.[9]
  • Asigurați un design rapid și responsiv (sau adaptabil) pentru a scădea time to first byte (TTFB). Folosiți http://webpagetest.org/ pentru a măsura TTFB. Pare să existe o corelație clară între poziționările mai slabe și o rată TTFB crescută.[10]

Dacă paginile se încarcă greu, motoarele de căutare pot interpreta acest lucru ca o problemă de conectivitate, ceea ce înseamnă că vor renunța la operațiunea de crawling a URL-urilor cu probleme.

Perioada de timp petrecută de Google pentru a descărca o pagină pare să influențeze numărul de pagini pe care le va cere de pe server. Cu cât este mai mic timpul de descărcare a unei pagini, cu atât mai multe pagini vor fi cerute/parcurse.

Corelația dintre perioada petrecută pentru descărcarea unei pagini și numărul de pagini supuse crawling-ului pe zi pare evidentă în acest grafic.

 

Link-uri defecte (broken links)

Este evident. Când link-urile interne sunt defecte, roboții nu vor putea găsi paginile corecte. Efectuați o operațiune completă de crawling a întregului website cu un instrument de crawling la alegerea voastră și reparați toate URL-urile defecte. De asemenea, folosiți instrumentele webmaster puse la dispoziție de motoarele de căutare pentru a căuta URL-urile defecte.

HTTP caching cu Last-Modified/If-Modified-Since și antete E-Tag

Cu privire la optimizarea procesului de crawling, termenul “cache” se referă la o pagină stocată în indexul unui motor de căutare. Rețineți că, caching-ul este o problemă foarte tehnică și setările incorecte pot face motoarele de căutare să efectueze operațiunea de crawling și indexare a website-ului vostru în mod haotic.

Atunci când un motor de căutare solicită o resursă de pe website, face mai întâi o solicitate serverului web pentru a verifica statutul acelei resurse. Serverul va răspunde cu un header response. Pe baza acestui header response, motoarele de căutare vor hotărî să descarce resursa sau să o sară.

Multe motoare de căutare verifică dacă resursa pe care o solicită s-a schimbat față de ultima dată când au făcut crawling pentru ea. Dacă s-a schimbat, trebuie să o extragă din nou (fetch) – dacă nu, o vor sări. Acest mecanism este cunoscut sub numele de conditional GET (obținere condiționată). Bing a confirmat că folosește antetul If-Modified-Since,[11] la fel și Google.[12]

Mai jos este răspunsul antetului (header response) pentru o pagină nou descoperită care suportă antetul If-Modified-Since, atunci când există o solicitare de a o accesa.

Utilizați comanda curl pentru a obține ultima dată a modificării unui document.

 

Când robotul solicită același URL data următoare, va adăuga o solicitare de tip If-Modified-Since. Dacă documentul nu s-a modificat, va răspunde cu un cod de statut 304 (Page Not Modified):

Un răspuns de tip 304în antet

 

If-Modified-Since va reda 304 Not Modified dacă pagina nu a fost modificată. Dacă a fost modificată, răspunsul header-ului va fi 200 OK, și motorul de căutare va explora pagina din nou. Headerul E-Tag funcționează la fel, dar este mai complicat de gestionat.

Dacă platforma voastră de e-commerce folosește personalizare, sau dacă conținutul de pe fiecare pagină se schimbă frecvent, poate fi mai dificil de implementat HTTP caching, dar chiar și paginile dinamice pot suporta If-Modified-Since.[13]

Hărțile site-ului (Sitemaps)

Există două tipuri majore de sitemaps:

  • HTML sitemaps
  • XML Sitemaps

Puteți trimite Sitemaps în următorul format: fișiere text simple, RSS sau mRSS.

Dacă aveți probleme de crawling și indexare, rețineți că sitemaps sunt doar o rezolvare de scurtă durată pentru problemele mai severe, precum conținut duplicat, conținut subțire sau linking intern incorect. Crearea de sitemaps este o idee bună, dar nu va rezolva aceste probleme.

HTML sitemaps

HTML sitemaps sunt o formă de navigare secundară. Ele sunt de obicei accesibile persoanelor și roboților prin intermediul unui link plasat în partea de jos a website-ului, în subsol (footer).

Un studiu privind ușurința utilizării efectuat pe mai multe website-uri, inclusiv de e-commerce, a descoperit că persoanele rareori folosesc HTML sitemaps. În 2008, doar 7% din utilizatori au apelat la sitemap când li s-a cerut să descopere structura unui site,[14] în scădere de la 27% în 2002. Astăzi, procentajul este probabil și mai mic.

Totuși, HTML sitemaps sunt utile pentru trimiterea roboților către paginile de la nivelurile inferioare ale taxonomiei website-ului, și pentru crearea unui linking intern plat.

Mostră de arhitectură plată.

 

Iată câteva sfaturi de optimizare pentru HTML sitemaps:

Folosiți sitemaps segmentate

Atunci când optimizați HTML sitemaps pentru crawling, este important să rețineți că PageRank se împarte între toate link-urile de pe o pagină. Împărțirea HTML sitemap în mai multe segmente mai mici este un mod bun de a crea pagini mai ușor de folosit pentru persoane și motoarele de căutare în website-urile mari, precum cele de e-commerce.

În locul unei pagini sitemap imense care face link către aproape fiecare pagină din website, creați o pagină principală sitemap de indexare (de ex., sitemap.html) și faceți link de pe ea către pagini mai mici componente ale sitemap-ului (sitemap-1.html, sitemap-2.html, etc.).

Puteți împărți HTML sitemaps în funcție de subiecte, categorii, departamente sau mărci. Începeți prin a lista principalele categorii pe pagina index. Modul în care împărțiți paginile depinde de numărul de categorii, subcategorii și produse din catalogul vostru.

Puteți folosi regula de „100 link-uri pe pagină” ca și recomandare, dar nu vă cramponați de acest număr, mai ales dacă website are o autoritate bună.

Dacă aveți mai mult de 100 categorii de top, ar trebui să le afișați pe primele 100 pe pagina sitemap de indexare și restul pe pagini sitemap suplimentare. Puteți permite utilizatorilor și motoarelor de căutare să navigheze sitemap-ul folosind link-uri pentru pagini anterioare și următoare (de ex., „vezi mai multe categorii).

Dacă aveți mai puțin de 100 categorii de nivel de top în catalog, veți avea loc să listați sub-categorii importante, de asemenea, după cum se arată mai jos:

Un exemplu de HTML sitemap curat.

 

Categoriile de top de pe acest sitemap sunt Photography, Computers & Solutions și Pro Audio. Deoarece firma are un număr limitat de categorii de top, există spațiu pentru mai multe sub-categorii (Digital Cameras, Laptops, Recording).

Nu faceți link către redirecționări

URL-urile la care se face link de pe paginile sitemap ar trebui să trimită roboții de crawling pe URL-urile finale, și nu să treacă prin redirecționări URL (redirects).

Îmbogățiți sitemaps

Adăugarea câtorva date suplimentare prin adnotarea link-urilor cu informații este utilă pentru utilizatori și oferă un oarecare context și pentru motoarele de căutare. Puteți adăuga date precum imagini thumbnail pentru produs, ratinguri de la clienți, numele producătorilor și așa mai departe.

Acestea sunt doar câteva sugestii pentru HTML sitemaps pentru a putea face paginile mai ușor de citit pentru utilizatori, și cu un linking foarte ușor pentru roboții de crawling. Totuși, cel mai bun mod de a ajuta motoarele de căutare să descopere conținutul de pe website este de a le pune la dispoziție o listă de URL-uri în formate diferite de fișier. Un astfel de format de fișier este XML.

XML Sitemaps

Platformele moderne de ecommerce ar trebui să auto-genereze XML Sitemaps, dar de multe ori fișierul output implicit nu este optimizat pentru crawling și analiză. Este important, prin urmare, să analizați manual și să optimizați outputul automat sau să generați sitemaps conform propriilor reguli.

Dacă nu aveți unele dubii legate de competitorii care vă spionează structura URL, este de preferat să includeți calea către fișierului XML Sitemap în fișierul robots.txt.

Robots.txt este solicitat de motoarele de căutare de fiecare dată când încep o nouă sesiune de crawling pe website. Fișierul este analizat pentru a vedea dacă a fost modificat de la ultima operațiune de crawling. Dacă nu a fost modificat, atunci motoarele de căutare vor folosi fișierul cache robots.txt existent pentru a determina care sunt URL-urile care pot fi parcurse de roboți.

Dacă nu specificați locația XML Sitemap în interiorul fișierului robots.txt, atunci motoarele de căutare nu vor ști unde să o găsească (exceptând dacă ați trimis-o în cadrul conturilor webmaster). Trimiterea locației către Google Search Console sau Bing Webmaster permite accesul la mai multe informații, precum numărul de URL-uri trimise, câte sunt indexate și ce erori posibile sunt prezente în sitemap.

Dacă aveți o rată de indexare de aproape 100% probabil nu trebuie să vă faceți griji despre optimizarea operațiunii de crawling.

 

Folosirea XML Sitemaps pare să aibă un efect accelerator asupra ratei de crawling:

“La început, numărul de vizite s-a stabilizat la o rată de 20 – 30 pagini pe oră. Imediat ce sitemap-ul a fost încărcat prin Webmaster Central, robotul a accelerat la aproximativ 500 pagini pe oră. În câteva zile, a atins o valoare maximă de 2.224 pagini pe oră. În timp ce robotul vizita, în medie, 26,59 pagini pe oră, a crescut la o medie de 1.257,78 pagini pe oră, o creștere de nu mai puțin de 4.630,27%”.[15]

Iată câteva sfaturi pentru optimizarea XML Sitemaps pentru website-urile mari:

  • Adăugați doar URL-uri care răspund cu 200 OK. Prea multe erori și motoarele de căutare nu vor mai avea încredere în sitemap-uri. Bing are

“o toleranță de 1% pentru erori într-un sitemap. Exemple de erori includ apariția unei redirecționări, un cod 404 sau 500 când se dă click pe un URL. Dacă vedem un nivel de erori de peste 1%, ne pierdem încrederea în acel sitemap”.[16]

Google este mai puțin strict decât Bing; nu le pasă de erorile din sitemap.

  • Eliminați link-urile către conținut duplicat și URL-urile care canonicalizează către alte URL-uri – păstrați doar link-urile către destinația finală.
  • Plasați imaginile video, noutățile și informațiile mobile în Sitemaps separate. Pentru video puteți folosi sitemaps, dar formatul mRSS este suportat, de asemenea.
  • Segmentați Sitemaps după subiect, categorie, și după sub-subiect și sub-categorie. De exemplu, puteți avea un sitemap pentru categoria Camping – sitemap_camping.xml, un altul pentru categoria de Biciclete – sitemap_cycle.xml, și un altul pentru categoria de Running Shoes (teniși alergare) – sitemap_running_shoes.xml. Această segmentare nu îmbunătățește direct clasările organice, dar ajută la indexare la nivel granular.
  • Creați fișiere Sitemap separate pentru paginile de produse. Segmentați în funcție de cel mai mic nivel al categoriilor (leaf categories).
  • Rezolvați erorile legate de Sitemap înainte de trimite fișierele motoarelor de căutare. Puteți face acest lucru în contul Google Search Console, folosind funcția Test Sitemap:

Funcția Test Sitemap din Google Search Console.

 

  • Păstrați URL-uri specifice pentru fiecare limbă în Sitemaps diferite.
  • Nu atribuiți aceeași importanță tuturor paginilor (scorul vostru se poate baza pe frecvența actualizărilor sau alte reguli de afaceri).
  • Auto-actualizați Sitemaps ori de câte ori sunt create URL-uri importante.
  • Includeți doar URL-uri care conțin filtre esențiale și importante (vezi secțiunea Paginile cu detalii despre produs).

Ați observat probabil un aspect comun al acestor sfaturi: segmentarea. Este o idee bună să împărțiți fișierele XML cât de mult puteți, fără a abuza de acest lucru (de ex., doar 10 URL-uri pe fișier), pentru a putea identifica și repara mai ușor problemele legate de indexare.[17]

Rețineți că sitemaps, fie XML sau HTML, nu trebuie folosite ca un substitut pentru o arhitectură slabă a website-ului sau alte probleme legate de operațiunea de crawling, ci doar ca backup. Asigurați-vă că există alte căi (de ex., link-uri interne contextuale) pentru roboții de căutare pentru a ajunge la toate paginile importante de pe website.

Iată câțiva factori care pot influența bugetul de crawling:

Popularitate

Roboții de căutare vor solicita paginile mai frecvent dacă descoperă link-uri interne și externe către acele pagini.

Majoritatea website-urilor de comerț electronic au dificultăți în construirea de link-uri externe către paginile de categorii sau cu detalii despre produs, dar acesta este un lucru care trebuie făcut. Găzduirea de articole de la invitați (guest posts), cadourile promoționale, atragerea de link-uri (link bait), conținutul de calitate, solicitările directe de link prin emailurile de confirmare, programe de tip ambasador și pagini de categorii de vacanță permanente sunt doar câteva din strategiile care pot ajuta la construirea de link-uri.

Setările legate de rata de crawling

Puteți modifica (de obicei micșora) rata de crawling a Googlebot folosind Google Search Console. Totuși, nu este recomandată schimbarea ratei decât dacă robotul încetinește serverul web.

Cu funcția Crawl Control de la Bing, o puteți seta diferit chiar și pe zile.

Interfața Crawl Control de la Bing.

 

Conținut proaspăt

Actualizarea conținutului pe pagini și apoi notificarea (pinging) motoarelor de căutare (de ex., prin crearea de feed-uri pentru paginile de produse și categorii) ar trebui să aducă roboții de căutare către conținutul actualizat relativ repede.

Dacă actualizați mai puțin de 300 URL-uri pe lună, puteți folosi funcția „Fetch as Google” din Google Search Console pentru a avea URL-urile actualizate parcurse imediat de Googlebot. De asemenea, puteți crea în mod regulat (de exemplu săptămânal) și trimite un nou fișier XML Sitemap doar pentru actualizări sau pentru noile pagini.

Există mai multe moduri în care puteți păstra conținutul proaspăt. De exemplu, puteți include un extras de aproximativ 100 cuvinte din postări blog înrudite pe paginile cu detalii despre produs. În mod ideal, extrasul ar trebui să includă numele produsului și link-uri către paginile de categorii părinte. De fiecare dată când menționați un produs într-o actualizare a unui articol de pe blog, actualizați și extrasul de pe pagina cu detalii despre produs.

Puteți include chiar extrase din articole care nu menționează în mod direct numele produsului, dacă articolul este legat de categoria de produse în care poate fi catalogat produsul.

Secțiunea “From Our Blog” păstrează pagina actualizată și proaspătă.

 

O altă strategie utilă de a menține conținutul proaspăt este de a genera în permanență recenzii ale produselor cumpărate de utilizatori, întrebări și răspunsuri despre produse, sau alte forme de conținut generat de utilizator.

Rating-urile și recenziile sunt un mod inteligent de a păstra paginile actualizate, în special pentru produsele cu foarte mare căutare.

Autoritatea domeniului

Cu cât autoritatea domeniului este mai mare, cu atât mai multe vizite vor face roboții motoarelor de căutare. Autoritatea domeniului vostru crește prin crearea unui număr mai mare de link-uri externe către website – un lucru mult mai ușor de spus decât de făcut.

RSS feeds

RSS feeds reprezintă unul din cele mai rapide moduri de a notifica motoarele de căutare cu privire la noi produse, categorii sau alte tipuri de conținut proaspăt de pe website. Iată ce a spus în trecut Duane Forrester (fostul Webmaster senior product manager de la Bing) despre RSS feeds:

“Lucruri precum RSS vor deveni o cale de dorit pentru noi de a găsi conținut…este o reducere substanțială de cost pentru noi”.[18]

Puteți determina motoarele de căutare să efectueze operațiunea de crawling pe noul conținut în câteva minute de la publicare, cu ajutorul RSS. De exemplu, dacă scrieți conținut care suportă pagini de categorii sau cu detalii despre produs, și dacă faceți linking inteligent de pe aceste pagini suport, motoarele de căutare vor solicita și vor face crawling și pe URL-urile categoriilor și produselor cu, care s-a făcut link.

Zappos are un RSS feed pentru paginile de marcă. Utilizatorii (și motoarele de căutare) sunt notificate instant de fiecare dată când Zappos adaugă un produs nou de la o anumită marcă.

 

Ghidarea roboților de căutare

Cel mai bun mod de a evita irosirea bugetului de crawling pe URL-uri cu valoare adăugată mică este de a evita crearea de link-uri către acele URL-uri în primul rând. Totuși, acest lucru nu este întotdeauna posibil. De exemplu, trebuie să permiteți persoanelor să filtreze produsele pe baza a trei sau mai multe atribute. Sau, vreți să permiteți utilizatorilor să trimită un email unui prieten de pe paginile cu detalii despre produs. Sau trebuie să le oferiți utilizatorilor posibilitatea de a scrie recenzii despre produse. Dacă creați URL-uri unice cu link-uri “Email to a Friend “ de exemplu, puteți ajunge să creați conținut duplicat.

Conținutul pentru URL-urile din imaginea de mai sus este duplicat. Totuși, aceste URL-uri nu trebuie să fie accesibile motoarelor de căutare. Blocați fișierul email-friend.php în robots.txt

 

Aceste URL-uri de tip Email to a Friend vor conduce, cel mai probabil, la același formular web, iar motoarele de căutare vor solicita și efectua crawling inutil pe sute sau mii de astfel de link-uri, în funcție de dimensiunea catalogului vostru. Veți irosi bugetul de crawling dacă permiteți motoarelor de căutare să descopere și să facă crawling pe aceste URL-uri.

Trebuie să controlați ce link-uri pot fi descoperite de roboții motoarelor de căutare și care nu. Cu cât există mai multe solicitări inutile din partea unui robot pentru pagini fără însemnătate, cu atât sunt mai mici șansele de a ajunge la URL-urile importante.

Directivele pentru roboți de căutare pot fi definite la niveluri diferite, în această ordine:

  • La nivel de site, folosind robots.txt.
  • La nivel de pagină, folosind noindex meta tag și cu antete (headers) HTTP (HTTP headers).
  • La nivel de element, folosind micro-formatul nofollow.

Directivele la nivel de site preced directivele la nivel de pagină și cele de la nivel de pagină au întâietate în fața directivelor la nivel de element. Este important să înțelegem această prioritate, deoarece pentru a permite unei directive de nivel de pagină să fie descoperită și urmată, directivele la nivel de site trebuie să permită accesul la acea pagină. Același lucru se aplică directivelor la nivel de pagină și la nivel de element.

Ca observație suplimentară, dacă doriți să păstrați confidențialitatea conținutului de pe site, unul din cele mai bune moduri este să folosiți autentificarea pe server, și să parolați zonele protejate.

Robots.txt

Deși fișierele robots.txt pot fi folosite pentru a controla accesul roboților de căutare, URL-urile blocate cu robots.txt pot ajunge totuși în indicii motoarelor de căutare din cauza backlink-urilor externe care indică spre URL-urile „robotizate”. Acest lucru sugerează că URL-urile blocate cu robots.txt pot acumula PageRank. Totuși, URL-urile blocate cu robots.txt nu vor transfera PageRank, deoarece motoarele de căutare nu pot efectua crawling și indexa conținutul și link-urile de pe astfel de pagini. Excepție fac URL-urile indexate anterior, caz în care vor transfera PageRank.

Este interesant să notăm că paginile cu butoane Google+ (serviciu închis în 2019) pot fi vizitate de Google când cineva dă click pe butonul plus, ignorând directivele robots.txt.[19]

Una din cele mai mari concepții greșite cu privire la robots.txt este că poate fi folosit pentru a controla conținutul duplicat. Adevărul este că există metode mai bune pentru controlarea conținutului duplicat, iar robots.txt nu ar trebui folosit decât pentru a controla accesul roboților de căutare la documentele de pe servere. Acestea fiind spuse, pot exista cazuri în care se poate să nu avem control asupra modului în care sistemul de gestionare al conținutului (CMS) generează conținutul, sau cazuri în care nu putem face modificări la paginile generate din mers. În astfel de situații, se poate încerca în ultimă instanță controlarea conținutului duplicat cu robots.txt.

Fiecare website de e-commerce este unic, cu propriile cerințe de afaceri specifice, prin urmare nu există o regulă generală în privința paginilor care trebuie să fie supuse operațiunii de crawling și care nu. Indiferent de particularitățile website-ului vostru, va trebui să gestionați conținutul duplicat fie folosind rel=“canonical”, fie antete HTTP.

Deși motoarele de căutare principale nu vor încerca să „adauge în coș” și nu vor începe un proces de plată online, sau o înregistrare a unui newsletter în mod voit, erorile de codare le pot determina să acceseze URL-uri nedorite. Luând în calcul aceste aspecte, iată câteva tipuri comune de URL-uri la care puteți bloca accesul:

Paginile de tip „coș de cumpărături” și pagini de plată

Add to Cart, View Cart, și alte URL-uri de plată online pot fi adăugate fără probleme în robots.txt.

Dacă URL-ul View Cart este mysite.com/viewcart.aspx, puteți folosi următoarele comenzi pentru a bloca parcurgerea paginilor:

User-agent: *

# Do not crawl view cart URLs

Disallow: *viewcart.aspx

# Do not crawl add to cart URLs

Disallow: *addtocart.aspx

# Do not crawl checkout URLs

Disallow: /checkout/

Directivele de mai sus înseamnă că tuturor roboților li se interzice să facă crawling pe orice URL care cuprinde viewcart.aspx sau addtocart.aspx. De asemenea, toate URL-urile sub directorul /checkout/ sunt interzise.

Robots.txt permite utilizarea limitată de expresii regulate (regular expressions abreviat, regex) pentru a se potrivi cu tiparele URL, prin urmare programatorii au la dispoziție un spectru larg de URL-uri. Când folosiți expresii comune, simbolul * „star” înseamnă „orice”, simbolul $ „dolar” înseamnă „se încheie cu” și simbolul ^ ”caret” indică „începe cu”.

Paginile cu conturile utilizatorilor

URL-urile de cont, precum Account Login pot fi blocate, de asemenea:

User-agent: *

# Do not crawl login URLs

Disallow: /store/account/*.aspx$

Directiva de mai sus înseamnă că toate paginile din directorul /store/account/ nu trebuie parcurse de roboții motoarelor de căutare.

Mai jos aveți alte câteva tipuri de URL-uri pe care le puteți bloca.

C:\Users\traiann\Gdrive traianneacsu\carte\capitole\04 Crawl Optimization\Images\CO fig 25 robots.png

Mai sus sunt alte câteva tipuri de pagini pe care le puteți bloca.

 

Câteva observații despre resursele subliniate cu galben:

  • Dacă gestionați un website de e-commerce pe WordPress, lăsați roboții de căutare să facă crawling pe URL-urile din directorul tag; au existat vremuri când trebuia să blocați paginile tag, dar acestea au trecut.
  • Directorul /includes/ ar trebui să nu conțină scripturi care sunt folosite pentru randarea conținutului pe pagini. Blocați-l doar dacă găzduiți scripturile necesare pentru crearea unor link-uri de nedescoperit în cadrul /includes/.
  • Același lucru este valabil pentru directoarele /scripts/ and /libs/– nu le blocați dacă conțin resurse necesare pentru randarea conținutului.

Problemele legate de conținutul duplicat sau aproape duplicat, precum paginarea și sortarea, nu sunt adresate în mod optim cu robots.txt.

Înainte să încărcați fișierul robots.txt, vă recomand să îl testați pe URL-urile existente. Mai întâi, generați o listă a URL-urilor de pe website, folosind una din metodele de mai jos:

  • Cereți ajutor de la programatorii firmei.
  • Faceți crawling pe întreg site-ul cu software-ul preferat.
  • Folosiți fișiere log.

Apoi deschideți această listă într-un editor de text care permite căutarea în funcție de expresii regulate. Programe precum RegexBuddy, RegexPal sau Notepad++ sunt alegeri bune. Puteți testa tiparele folosite în fișierul robots.txt folosind aceste programe, dar rețineți că este posibil să trebuiască să rescrieți puțin tiparul regex pe care l-ați folosit în robots.txt, în funcție de programul pe care îl folosiți.

Să spunem că doriți să blocați accesul roboților la paginile de destinație pentru campaniile de email marketing, localizate sub directorul /ads/. Fișierul robots.txt va include rândurile de mai jos:

User-agent: *

# Do not crawl view cart URLs

Disallow: /ads/

Folosind RegexPal, puteți testa lista de URL-uri folosind acest regex simplu: /ads/

RegexPal subliniază automat tiparul comun.

Dacă lucrați cu fișiere mari, care conțin sute de mii de URL-uri, folosiți Notepad++ pentru a descoperi URL-urile cu expresii regulate, deoarece Notepad++ poate gestiona ușor fișierele de mari dimensiuni.

De exemplu, să spunem că vreți să blocați toate URL-urile care se termină cu extensia .js. Fișierul robots.txt va include rândul:

Disallow: /*.js$

Pentru a descoperi URL-urile din lista voastră care se potrivesc directivelor robots.txt folosind Notepad++, veți introduce “\.js” în câmpul “Find what” și veți folosi apoi modul de căutare după expresii regulate:

Modul de căutare după expresii regulate în Notepad++

 

Răsfoirea rapidă a URL-urilor subliniate cu galben poate elimina dubiile cu privire la URL-urile care trebuie excluse cu robots.txt.

Când trebuie să blocați roboții de căutare să acceseze materiale precum cele video, imagini sau fișiere .pdf, folosiți X-Robots-Tag HTTP header[20] în loc de fișierul robots.txt file.

Rețineți, totuși, dacă doriți să soluționați problemele legate de conținutul duplicat pentru documentele non-HTML, folosiți antete HTTP rel=“canonical”.[21] (rel=”canonical” HTTP header)

Parametrul de excludere

Cu această tehnică puteți adăuga selectiv un parametru (de ex., crawler=no) sau un șir (ex., ABCD-9) URL-urilor pe care le doriți inaccesibile și apoi blocați acel parametru sau șir cu robots.txt.

Mai întâi, hotărâți-vă ce URL-uri doriți să blocați. Să spunem că doriți să controlați parcurgerea de către roboții motoarelor de căutare a navigației fațetate, interzicând acestor să facă crawling pe URL-urile generate prin aplicarea mai multor valori de filtrare în cadrul aceluiași filtru (cunoscută și sub numele de multi-select). În acest caz, veți adăuga parametrul crawler=no tuturor URL-urilor generate când o a doua valoare a filtrului este selectată pe același filtru.

Dacă doriți să blocați roboții când încearcă să facă crawling pe un URL generat prin aplicarea a mai mult de două valori de filtrare pe filtre diferite, veți adăuga parametrul crawler=no tuturor URL-urilor generate atunci când este selectată o a treia valoare a filtrului, indiferent ce opțiuni au fost alese și de ordinea în care au fost alese. Iată un scenariu pentru acest exemplu:

Robotul este pe pagina de sub-categorie Battery Chargers.

Ierarhia este: Home > Accessories > Battery Chargers

URL-ul paginii este: mysite.com/accessories/motorcycle-battery-chargers/

Apoi, robotul „selectează” una din valorile filtrului Brands: Noco. Aceasta este prima valoare de filtru și, prin urmare, veți permite robotului să acceseze această pagină.

URL-ul pentru această selecție nu conține parametrul de excludere:

mysite.com/accessories/motorcycle-battery-chargers?brand=noco

Robotul verifică apoi una din valorile filtrului Style: cables. Deoarece aceasta este a doua valoare aplicată, încă veți permite robotului să acceseze URL-ul.

URL-ul încă nu conține parametrul de excludere. Conține doar parametrii URL brand și style:

mysite.com/accessories/motorcycle-battery-chargers?brand=noco&style=cables

Acum, robotul „selectează” una din valorile filtrului Pricing: 1. Deoarece aceasta este a treia valoare de filtru, veți atașa parametrul crawler=no URL-ului.

URL-ul devine:

mysite.com/accessories/motorcycle-battery-chargers?brand=noco&style=cables&pricing=1&crawler=no

Dacă doriți să blocați URL-ul de mai sus, fișierul robots.txt file va conține:

User-agent: *

Disallow: /*crawler=no

Metoda descrisă mai sus împiedică parcurgerea URL-urilor generate de navigarea fațetă atunci când se aplică mai mult de două valori de filtrare, dar nu permite un control specific asupra căror filtre urmează să fie parcurse și care nu. De exemplu, dacă robotul „selectează” mai întâi opțiunea de Pricing, URL-ul care conține parametrul de preț va fi parcurs de robot. Vom discuta despre navigarea fațetată în detaliu în secțiunea Navigarea fațetată, din capitolul Paginile de listare.

Gestionarea parametrilor URL

Parametrii URL pot provoca probleme de eficiență a procesului de crawling, precum și probleme legate de conținutul duplicat. De exemplu, dacă implementați sortarea, filtrarea și paginarea folosind parametri, veți avea în final un număr mare de URL-uri, care vor irosi bugetul de crawling. Google ne arată[22] cum 158 produse de pe googlestore.com au generat o incredibilă cifră de 380.000 URL-uri pentru roboții de căutare.

Controlarea parametrilor URL în Google Search Console și Bing Webmaster Tools poate îmbunătăți eficiența procesului de crawling dar nu va rezolva cauza conținutului duplicat. Va trebui să rezolvați problemele legate de canonicalizare, la sursă. Totuși, deoarece website-urile de e-commerce folosesc parametri URL multipli, controlarea lor corectă cu instrumentele webmaster se poate dovedi anevoioasă și riscantă. Dacă nu știți exact ceea ce faceți, mai bine folosiți o setare conservatoare sau setările implicite.

Gestionarea parametrilor URL se folosește cel mai adesea pentru a decide ce pagini trebuie indexate și către ce pagină să canonicalizăm.

Unul din avantajele gestionării parametrilor URL în cadrul conturilor webmaster este că directivele de la nivel de pagină (i.e. rel=“canonical” sau meta noindex) se vor aplica în continuare, atât timp cât paginile care conțin astfel de directive nu sunt blocate cu robots.txt sau alte metode. Deși este posibilă folosirea limitată de expresii regulate în cadrul fișierului robots.txt pentru a împiedica procesul de crawling a URL-urilor cu parametri, robots.txt va suprascrie directivele de nivel de pagină și element.

Notificare din Google Search Console privind parametrii URL.

 

Uneori există cazuri în care nu trebuie să vă jucați cu setările parametrilor URL. În captura de ecran de mai sus puteți vedea un mesaj care spune că Google nu are probleme cu clasificarea parametrilor URL-urilor. Dacă Google poate face crawling fără dificultate pe întreg site-ul, puteți lăsa setările implicite așa cum sunt. Dacă doriți să setați parametrii, dați click pe link-ul Configure URL parameters.

Această captură de ecran este pentru un website de e-commerce cu mai puțin de 1,000 SKUs (stock-keeping unit number). Puteți vedea modul în care navigarea fațetată a generat milioane de URL.

 

În imaginea de mai sus, parametrul limit (folosită pentru modificarea numărului de produse listate pe o pagină de categorie) a generat 6,6 milioane de URL-uri în combinație cu alți posibili parametri. Totuși, deoarece website-ul are o autoritate puternică, primește multă atenție și ”iubire” din partea Googlebot, și nu are probleme de crawling sau indexare.

Când gestionați parametri, primul lucru pe care trebuie să îl decideți este care parametri modifică conținutul (parametri activi) și ce parametri nu fac acest lucru (parametri pasivi). Cel mai eficient e să faceți acest lucru cu programatorii site-ului, deoarece ei vor ști cel mai bine utilizarea parametrilor. Parametrii care nu afectează modul în care conținutul este afișat pe pagină (de ex., parametrii de urmărire a acțiunilor utilizatorului pe site – tracking parameters) sunt o țintă sigură în vederea excluderii.

Deși Google în sine se descurcă foarte bine cu identificarea parametrilor care nu modifică conținutul, merită să îi setați manual.

Pentru a schimba setările pentru astfel de parametri, dați click pe Edit:

Controlarea parametrilor URL din Google Search Console.

În exemplul nostru, parametrul utm_campaign a fost folosit pentru a urmări performanța promoțiilor interne și nu modifică conținutul de pe pagină. În acest scenariu, alegeți “No: Does not affect page content (ex: track usage)”.

Parametrii Urchin Tracking Module (cunoscuți mai mult ca parametrii UTMs), pot fi consolidați fără probleme cu URL-urile reprezentative.

 

Pentru a fi siguri că nu blocați parametrii greșiți, testați URL-urile mostră prin încărcarea lor în browser. Încărcați URL-ul și vedeți ce se întâmplă dacă scoateți parametrii de urmărire. Dacă conținutul nu se schimbă, acel parametru poate fi exclus.

Ca observație suplimentară, urmărirea promoțiilor interne cu parametri UTM nu este alegerea ideală. Parametrii UTM sunt creați pentru campanii de urmărire în afara website-ului vostru. Dacă doriți să urmăriți performanța internă a bannerelor de marketing, folosiți alte nume de parametri sau folosiți urmărirea de evenimente (event tracking).

Alți parametri comuni pe care îi puteți lua în calcul pentru excludere sunt numerele de identificare sesiune (session IDs), parametrii UTM (utm_source, utm_medium, utm_term, utm_content și utm_campaign) și ID-urile afiliaților.

Este necesar un avertisment aici, iar această recomandare vine direct de la Google.[23]

“Configurarea parametrilor din site poate avea efecte severe, neintenționate, asupra modului în care Google face crawling și indexează paginile. De exemplu, imaginați-vă un website de e-commerce care folosește storeID atât în identificarea magazinului cât și pentru verificarea disponibilității unui produs într-un magazin:

/store-locator?storeID=123

/product/foo-widget?storeID=123

Dacă configurați storeID să nu fie supus procesului de crawling, atunci atât /store-locator cât și /foo-widget vor fi afectate. Drept urmare, este posibil ca Google să nu poată indexa ambele tipuri de URL-uri, să nu le arate în rezultatele căutării. Dacă acești parametri sunt folosiți pentru scopuri diferite, recomandăm folosirea de nume diferite de parametri”.

În scenariul de mai sus, puteți păstra locația magazinului într-un cookie.

Lucrurile se complică și mai mult când parametrii schimbă modul în care conținutul este afișat pe o pagină.

O setare sigură pentru parametrii care schimbă conținutul este să îi sugerați lui? Google modul în care parametrul afectează pagina (de ex., sortare, filtre, specificare, traducere, paginare și altele) și să folosiți opțiunea implicită Let Google decide. Această abordare va permite Google să facă crawling pe toate URL-urile care includ parametrul vizat.

O setare sigură este să informați Google cu privire la faptul că un parametru schimbă conținutul și să lăsați Google să decidă ce face cu acel parametru.

 

În exemplul de mai sus, știam că parametrul mid modifică conținutul de pe pagină, astfel încât am subliniat pentru Google că parametrul sortează produse. Totuși, când se ia o decizie asupra URL-urilor care trebuie parcurse de Googlebot, las pe Google să ia această decizie.

Motivul pentru care recomand să lăsați Google să decidă este datorat modului în care Google alege URL-urile canonice: grupează URL-urile cu conținut duplicat în clustere pe baza linking-ului intern (PageRank), popularității link-ului extern și conținutului. Apoi Google găsește cel mai bun URL de indicat în rezultatele de căutare pentru fiecare cluster de conținut duplicat. Deoarece Google nu vă informează cu privire la graficul complet de link-uri al website-ului vostru, nu veți ști ce URL-uri au cele mai multe link-uri, astfel încât nu puteți alege întotdeauna URL-ul potrivit pe care să îl canonicalizați.

Capitole

1. Arhitectura website-urilor

2. Cercetarea cuvintelor cheie

3. Optimizarea crawling-ului

4. Link-ingului intern

5. Paginile de start (Home Pages)

6. Paginile de listare (PLP) și categorii (CAT)

7. Paginile cu detalii despre produs (PDP)

Traducerea în română: Cătălin Drăcșineanu

Referințe:

  1. Google Patent On Anchor Text And Different Crawling Rates, http://www.seobythesea.com/2007/12/google-patent-on-anchor-text-and-different-crawling-rates/ ↑
  2. Large-scale Incremental Processing Using Distributed Transactions and Notifications, http://research.google.com/pubs/pub36726.html ↑
  3. Our new search index: Caffeine, http://googleblog.blogspot.ca/2010/06/our-new-search-index-caffeine.html ↑
  4. Web crawler , http://en.wikipedia.org/wiki/Web_crawler#Politeness_policy ↑
  5. To infinity and beyond? No!, http://googlewebmastercentral.blogspot.ca/2008/08/to-infinity-and-beyond-no.html ↑
  6. Crawl Errors: The Next Generation, http://googlewebmastercentral.blogspot.ca/2012/03/crawl-errors-next-generation.html ↑
  7. Make Data Useful, http://www.scribd.com/doc/4970486/Make-Data-Useful-by-Greg-Linden-Amazon-com ↑
  8. Shopzilla’s Site Redo – You Get What You Measure, http://www.scribd.com/doc/16877317/Shopzilla-s-Site-Redo-You-Get-What-You-Measure ↑
  9. Expires Headers for SEO: Why You Should Think Twice Before Using Them, http://moz.com/ugc/expires-headers-for-seo-why-you-should-think-twice-before-using-them ↑
  10. How Website Speed Actually Impacts Search Ranking, http://moz.com/blog/how-website-speed-actually-impacts-search-ranking ↑
  11. Optimizing your very large site for search — Part 2, http://web.archive.org/web/20140527160343/http://www.bing.com/blogs/site_blogs/b/webmaster/archive/2009/01/27/optimizing-your-very-large-site-for-search-part-2.aspx ↑
  12. Matt Cutts Interviewed by Eric Enge, http://www.stonetemple.com/articles/interview-matt-cutts-012510.shtml ↑
  13. Save bandwidth costs: Dynamic pages can support If-Modified-Since too, http://sebastians-pamphlets.com/dynamic-pages-can-support-if-modified-since-too/ ↑
  14. Site Map Usability, http://www.nngroup.com/articles/site-map-usability/ ↑
  15. New Insights into Googlebot, http://moz.com/blog/googlebot-new-insights ↑
  16. How Bing Uses CTR in Ranking, and more with Duane Forrester, http://www.stonetemple.com/search-algorithms-and-bing-webmaster-tools-with-duane-forrester/ ↑
  17. Multiple XML Sitemaps: Increased Indexation and Traffic, http://moz.com/blog/multiple-xml-sitemaps-increased-indexation-and-traffic ↑
  18. How Bing Uses CTR in Ranking, and more with Duane Forrester, http://www.stonetemple.com/search-algorithms-and-bing-webmaster-tools-with-duane-forrester/ ↑
  19. How does Google treat +1 against robots.txt, meta noindex or redirected URL, https://productforums.google.com/forum/#!msg/webmasters/ck15w-1UHSk/0jpaBsaEG3EJ ↑
  20. Robots meta tag and X-Robots-Tag HTTP header specifications, https://developers.google.com/webmasters/control-crawl-index/docs/robots_meta_tag ↑
  21. Supporting rel=”canonical” HTTP Headers, http://googlewebmastercentral.blogspot.ca/2011/06/supporting-relcanonical-http-headers.html ↑
  22. Configuring URL Parameters in Webmaster Tools, https://www.youtube.com/watch?v=DiEYcBZ36po&feature=youtu.be&t=1m50s ↑
  23. URL parameters, https://support.google.com/webmasters/answer/1235687?hl=en