Ecommerce SEO: Optimizarea paginilor de listare

Optimizarea paginilor de listare de produse (PLPs) sau categorii (CAT)

Lungime articol: 22 327 de cuvinte
Timp estimativ de citire: 2 ore și 30 de minute

Aceasta este cea de-a șasea 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)

Cei implicați în ecommerce într-un fel sau altul numesc paginile cu detalii despre produs (cunoscute, de asemenea, ca product detail pages sau PDPs), drept „paginile bănoase” (money pages). Acest lucru pare să implice faptul că multe persoane consideră PDPs ca fiind cele mai importante pagini pentru e-commerce. Din cauza acestei mentalități, PDPs primesc adesea cea mai mare atenție, în detrimentul paginilor de listare a produselor sau  a paginilor pentru categorii.

Totuși, paginile de listare sunt de fapt adevărate nuclee pentru website-urile de e-commerce și pot aduna și transfera cea mai mare autoritate nivelurilor superioare și inferioare din ierarhia website-ului. De asemenea, dezvoltarea de backlink-urilor pentru e-commerce se concentrează de obicei pe paginile de categorii și sub-categorii; prin urmare, paginile de listare merită mai multă atenție.

Paginile de listare afișează conținutul într-o grilă sau o listă. Atunci când aceste pagini listează produse, ele sunt denumite pagini de listare produse (product listing pages sau PLPs). Când paginile listează categorii, subcategorii (de exemplu, ghiduri, orașe, servicii etc.), ele sunt denumite pagini pagini de categorii.

Două tipuri de listări

Paginile de listare afișează de obicei unul din două tipuri de elemente:

  • Produse – această listare afișează produse care aparțin categoriei vizualizate în acel timp.
  • Subcategorii – această listare afișează subcategorii sub categoria sau departamentul vizualizat în acel moment.

Listările de produse

Listele (sau grilele) cu produse afișează thumbnail images pentru toate produsele clasificate într-o anumită categorie sau subcategorie. Acest lucru înseamnă că toate produsele listate aici au un părinte comun în ierarhie.

Această captură de ecran arată o grilă clasică de produse. Toate produsele afișate în zona principală de conținut aparțin categoriei Guitars.

 

Folosirea unei listei de produse are avantajul că  trimite mai multă autoritate direct produselor din listă, în special celor de pe prima pagină a listei. Totuși, aceste listări pot prezenta prea multe opțiuni pentru utilizatori, care pot fi nevoiți să cearnă prin sute sau mii de produse, după cum se arată în imaginea de mai jos:

2,839 produse de îmbrăcăminte într-o singură categorie vor impune paginarea.

 

În multe cazuri, nu are sens să arăți utilizatorilor o întreagă listă de produse care aparțin unei categorii din topul ierarhiei categoriilor. Aceștia au nevoie de îndrumare în alegerea unui produs și listarea a mii de produse este prea mult și prea generică.

Să vedem câteva recomandări pentru optimizarea paginilor de listare a produselor.

Instalați o funcție de Vizualizare Rapidă (Quick-View), prietenoasă din punct de vedere SEO

Folosiți această funcționalitate pentru a oferi mai mult conținut și context pentru utilizatori și motoarele de căutare Această funcționalitate este implementată de obicei cu ferestre modale pentru a oferi rapid informații sumare despre produse, fără a vizita pagina cu detalii despre produs în sine.

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

Un click pe butonul QUICK LOOK deschide fereastra modală în partea dreaptă. Această funcționalitate poate conduce la o experiență îmbunătățită pentru cumpărători.

 

Pentru a profita de această funcționalitate, implementați-o cu JavaScript prietenos din punct de vedere SEO, ori de câte ori este posibil. De exemplu, puteți livra mai mult conținut care poate fi analizat de roboții de căutare încărcând descrierea statică a produsului în codul sursă dar afișându-l în browser numai atunci când se dă click pe Quick Look. Informațiile dinamice, precum disponibilitatea produsului, culorile disponibile sau prețul pot fi încărcate la cerere cu AJAX.

La fel ca în cazul oricărei alte metode care afișează conținutul pentru utilizatori doar în urma unor acțiuni în browser, este o idee bună să nu abuzați de implementarea Quick Look. Acest lucru înseamnă că, conținutul trebuie să fie super relevant și scurt. 50-150 de cuvinte sunt, probabil, mai mult decât suficiente pentru descrierea unui produs din listă.

De asemenea, linking-ul intern nu ar trebui exagerat; două – cinci link-uri sunt suficiente pentru scurta descriere a produsului.

Suplimentar, puteți lua în calcul numărul de produse pe care le încărcați în vizualizarea implicită, respectiv ceea ce este înregistrat în cache de motoarele de căutare. Dacă încărcați 20 produse cu descrieri de 100 cuvinte fiecare, aveți un conținut de 2.000 cuvinte pe acea pagină. Dacă încărcați 50 produse, respectiv 5.000 cuvinte, poate fi prea mult.

Creați și îmbunătățiți algoritmii interni pentru a afișa în mod optim produsele din listă.

SEO înseamnă creșterea profiturilor prin măsurile de optimizare pentru utilizatorii care ajung pe website cu ajutorul motoarelor de căutare. Dacă un utilizator ajunge pe o pagină de categorii și primele produse de pe listă sau din grilă nu generează profituri, risipiți șanse importante.

Trebuie să creați și să folosiți un algoritm care atribuie o poziție pentru fiecare produs (product rank), și trebuie să organizați produsele pe baza acestui parametru. Algoritmul nu trebuie să fie super complex. Poate lua în calcul câțiva parametri diferiți, de exemplu procentul de adaos, statisticile de vânzări, disponibilitatea stocului, proximitatea față de locația utilizatorului și chiar produse alese individual.

Ideea este să puneți produsele care generează maximul de profit primele pe listă.

Cele mai multe site-uri au produsele cele mai bine vândute sau cele mai populare ca vizualizare implicită în lista de produse, ceea ce este bine pentru uzabilitate deoarece majoritatea clienților caută cele mai vândute produse.[1] Totuși, acest lucru nu înseamnă că nu trebuie să optimizați profiturile experimentând algoritmul de clasare..

Adăugați conținut specific categoriei

Adăugarea de conținut pe paginile PLPs poate crește șansele de a apărea mai sus în motoarele de căutare. Acest lucru se aplică categoriilor de la toate nivelurile ierarhiei.

Cunoașteți probabil „conținutul SEO” pentru descrierea categoriilor; multe website-uri de e-commerce folosesc acest tip de conținut, de obicei în partea de jos a paginii. Să aruncăm o privire pe imaginea de mai jos:

“Conținutul SEO” este afișat după lista sau grila de produse pentru a permite afișarea produselor pe primul ecran (above the fold). Influența SEO a acestui conținut poate fi îmbunătățiră adăugând link-uri spre mai multe pagini interne.

 

Vă întrebați dacă acest lucru funcționează pentru Newegg?

Newegg se clasează #2 pentru “monitoare LCD”, peste Best Buy.

 

Bineînțeles, alți factori au contribuit la clasarea paginii pe poziția a doua, dar acea descriere a categoriei a avut și ea o anumită influență. Rețineți, SEO înseamnă schimbări mici și incrementale, ca acel text.

Unele website-uri preferă să plaseze acest tip de conținut deasupra listei, dar această abordare nu lasă mult spațiu pentru text și va împinge în jos conținutul principal, așa cum puteți vedea în imaginea următoare:

”Textul SEO” pentru această categorie (în partea de sus a listei) împinge produsele în josul paginii.

 

În exemplul de mai sus, descrierea categoriei nu este lungă deloc, dar bannerul de marketing împinge grila de produse chiar și mai jos.

Nu există nici o îndoială că un conținut text de calitate si mai bogat poate ajuta la SEO. Totuși, dacă adăugați prea mult conținut deasupra listei de produse împingeți produsele dincolo de primul ecran (below the fold), ceea ce poate crea confuzie pentru utilizatori și poate afecta ratele de conversie. Pe de cealaltă parte, afișarea conținutului sub grila de produse nu este la fel de eficientă și de ajutor ca afișarea conținutului în partea de sus a paginii.

Există câteva tehnici pentru a soluționa această problemă, de exemplu extindere/restrângere (extend/collapse) a unui conținut suplimentar la click, sau folosirea de carusele JavaScript. Cred că navigarea cu tab-uri este una din cele mai prietenoase și elegante soluții din punct de vedere SEO, pentru a cuprinde mult conținut în partea de sus a paginii. Această abordare este bună atât pentru utilizatori, cât și pentru roboții de căutare, și se poate implementa într-un spațiu limitat, fără a face spam.

O scurtă observație despre conținutul din spatele tab-urilor și click-urilor de extindere: înainte de indexarea pentru mobile în primul rând (mobile-first indexing), un astfel de conținut era considerat mai puțin important și primea o autoritate redusă. Totuși, acest lucru s-a schimbat odată cu implementarea indexării pentru mobile.

Să comparăm imaginile cu navigarea cu tab-uri „înainte și după”.

Captura de ecran de mai jos ne arată cum arăta o pagină de categorii pe REI. Afișa puțin conținut în partea de sus a listei dar nu folosea navigarea cu tab-uri. Observați modul în care conținutul din partea de sus împinge lista în josul paginii.

Această implementare nu impune tab-uri.

 

Iată cum arată versiunea cu navigarea cu tab-uri:

Acest design nou folosește tab-uri pentru a afișa mai mult conținut pe screen-ul inițial (above the fold).

 

Shop by Category este tab-ul implicit, ceea ce este grozav pentru utilizatori deoarece listează subcategorii. Ultimul tab, Expert Advice & Activities, adaugă multă valoare SEO:

Conținutul de mai sus este minunat pentru utilizatori și motoare de căutare.

 

Conținutul din imaginea de mai sus nu este doar conținut bine scris care se concentrează pe utilizatori și conversii mai mult decât pe SEO, ci este și „hrană” foarte bună pentru motoarele de căutare. Acest tip de conținut abordează vizitatorii în diverse etape ale procesului de cumpărare și îi va ghida în pâlnia de conversie, ceea ce este minunat. Va crește, de asemenea, șansele categoriei respective de a se clasa mai bine în SERP.

O scurtă observație aici: REI ar putea adăuga ușor unul sau două link-uri text contextuale către subcategoriile sau produsele înrudite tematic pentru a transfera capital SEO către acestea.

Lecția de aici este că orice conținut plasat în navigarea cu tab-uri trebuie să fie util pentru utilizatori și să nu fie doar un text oarecare de tip șablon (boilerplate).

Am mai menționat acest lucru și îl voi spune din nou: website-urile de comerț electronic trebuie să publice conținut dacă vor să aibă succes pe termen lung. Aceasta nu este o strategie SEO ci mai curând o abordare sănătoasă de marketing. Conținutul pe care îl plasați pe fiecare pagină ar trebui să răspundă intenției utilizatorului căruia i se adresează pagina respectivă. În cazul în care căutarea pe care o vizați cu o pagină este generică, de exemplu vizarea unor nume de categorii, încercați să satisfaceți intenții multiple pe acea pagină. Numesc acest lucru conținut cu intenții multiple (multi-intent content).

În plus față de conținutul foarte bun cuprins în acest tab, REI a adăugat și mai mult conținut în partea de jos a grilei de subcategorie, în afara navigării cu tab-uri:

Adăugarea de conținut suplimentar în partea de jos a paginii are rolul de a crește relevanța acestei pagini de subcategorii.

 

Un model bun de implementare de conținut SEO în partea de jos a grilei de prezentare este pe website-ul Home Depot.

Ei au plasat ghiduri de cumpărare, ghiduri de proiecte și conținut pentru comunitate asociat cu categoriile, ceea ce este minunat pentru utilizatori iar motoarelor de căutare le va plăcea la nebunie. Doar o singură observație: ar fi interesant de testat efectele asupra conversiilor dacă acest tip de conținut ar fi mutat sus în prezentare, deasupra grilei de produse.

Crearea unui tip de conținut similar celui folosit de Home Depot este o strategie câștigătoare în orice situație deoarece:

  • Utilizatorii vor avea acces la conținut foarte bun pentru a-i ajuta cu nevoile lor și pentru a le răspunde la întrebări, ceea ce conduce la rate mai bune de conversie.
  • Motoarelor de căutare le va plăcea un astfel de conținut, ceea ce va conduce la un trafic organic mai mare.

O secțiune foarte utilă este prezentată la finalul listării produselor.

 

O altă opțiune pentru a adăuga mai mult conținut pe paginile de categorii este să introduceți un link sau un buton spre conținut suplimentar, chiar deasupra produselor. Puteți vedea un exemplu în imaginea de mai jos:

Când utilizatorii dau click pe butonul View Guide sunt direcționați spre o pagină nouă. Ghidul de pe această pagină nouă este lung și de calitate, dar nu adaugă nici o valoare paginii de listare în sine.

 

În loc să deschideți ghidul într-o pagină nouă, o opțiune SEO mai bună este să deschideți o fereastră modală care conține un fragment din ghid. Pre-încărcați fragmentul de text în cod HTML pentru a fi accesibil motoarelor de căutare. Această fereastră modală va conține un link către ghidul HTML, astfel încât utilizatorii pot da click pe el dacă vor să citească întregul ghid.

Crearea de conținut consumă timp și resurse, prin urmare trebuie să identificați categoriile cu cele mai bune rezultate sau cu marja de profit cea mai mare pentru a începe cu ele și apoi să treceți treptat la celelalte.

Profitați de conținutul generat de utilizator (user-generated content sau UGC)

Conținutul generat de utilizatori are o valoare SEO foarte mare, prin urmare să aruncăm o privire asupra a două tipuri de UGC pe care le puteți implementa pe paginile de listare: recenziile produselor și postările din forumuri.

Recenziile produselor

Adăugarea de recenzii relevante pentru produse va influența ratele de conversie și clasările făcute de motoarele de căutare:

În această imagine puteți vedea modul în care secțiunea dedicată recenziilor este afișată în partea de jos a paginii de listare produse. Recenziile din această secțiune ar trebui, în mod ideal, să reflecte produsele prezentate în listă.

 

Dacă listarea este paginată, recenziile ar trebui listate pe pagina index și nu ar trebui repetate pe paginile numerotate. Dacă aveți suficiente recenzii pentru a umple paginile 2-N ale seriei, ați putea fi tentați să faceți acest lucru, dar nu este o idee bună.

În astfel de cazuri, puteți lua în calcul creșterea numărului de recenzii pe care le listați pe pagina index. În loc să listați trei recenzii, creșteți numărul la cinci sau zece.

Când faceți acest lucru, trebuie să creați reguli pentru a evita problemele legate de conținutul duplicat dintre paginile de listare de produse și paginile cu detaliile despre produse. Astfel de reguli pot include:

  • Nu afișați mai mult de două recenzii pentru același produs pe aceeași pagină.
  • Afișați doar cinci recenzii pe aceeași pagină de listare.
  • Pe pagina de listare nu afișați aceleași recenzii pe care le-ați afișat pe pagina produsului.

Postări din forumuri

Conținutul creat de comunitate, precum postările din forumuri, pot fi utile nu doar în secțiunea de forum a unui website (bineînțeles, dacă aveți una), ci și pe paginile de listare de categorii sau produse:

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

În plus față de recenziile produselor, unele postări relevante din forum sunt listate sub grila de produse.

 

Optimizați pentru SERP snippets mai bune

Paginile de listare de produse pot obține rich snippets în paginile cu rezultatele căutării din Google:

Extras din pagina de rezultate (SERP Snippet ) îmbogățit cu numărul produselor din listă. Uneori, Google afișează doar numărul de produse din listă; alteori afișează și câteva nume de produse.

 

Deși multe website-uri de e-commerce sunt interesate cum pot obține aceste rich snippets, recomandarea oficială a Google nu oferă prea multe detalii:[2]

“Dacă rezultatul unei căutări este format în cea mai mare parte dintr-o listă structurată, ca un tabel sau o serie de produse numerotate, vom arăta o listă cu trei rânduri sau produse relevante sub rezultat, într-un format numerotat. Snippet-ul va arăta, de asemenea, o valoare aproximativă a numărului total de rânduri sau produse de pe acea pagină (de exemplu, “40+ items” ca în imaginea de mai sus)”.

Un cod HTML curat poate ajuta la indicarea numărului de produse în rich snippet.

 

Google poate folosi codul HTML pentru a genera rich snippets, ceea ce înseamnă că nu are nevoie neapărat de un marcaj semantic (semantic mark-up), precum Schema.org. Iată de ce este important să păstrăm codul curat și bine structurat.

Rețineți că dacă paginile de listare obțin rich snippets care includ numele produselor, atunci rândul de descriere din snippet în SERP va fi mai scurt decât cele obișnuite. În loc de două sau trei rânduri de text, snippet-ul de descriere poate fi truncat la doar un singur rând de text. Este o idee bună să verificați impactul asupra ratei CTR în SERP în aceste cazuri.

Iată câteva sfaturi pentru a obține rich snippets pentru listările de categorii:

Validați codul HTML pentru al listei

Dacă deschideți un element din listă dar nu îl închideți corect, sau dacă incorporați elementele incorect, va fi mai dificil pentru Google să înțeleagă structura paginii.

Fiecare produs din grilă este inclus într-un element al listei care este corect închis. De asemenea, observați numele de clasă DIV și UL.

 

Nu separați tabelele HTML

Rich snippet va afișa numărul de produse de pe pagina index (de ex., “40+ items”) dacă grila de produse conține 40+ produse într-un singur tabel, dar numai dacă marcajul tabelului nu este întrerupt. Dacă ceva rupe tabelul între rândurile 10 și 11, Google va afișa în schimb mesajul “10+ items”. Dacă listați produsele în tabele multiple, Google va alege să afișeze numărul din unul singur.

Folosiți nume de clase sugestive pentru HTML

Se afirmă[3] că folosirea numelui de clasă „item” în DIV-ul produsului ajută la obținerea de rich snippets pentru PLP:

“Doar pentru a confirma, am incorporat câteva produse în <div class=items> și snippet-ul a fost actualizat. A durat patru zile să apară în SERPs”.

Acest sfat pare să funcționeze, cel puțin într-o oarecare măsură, după cum puteți vedea în imaginea de mai jos:

Observați numele de clasă LI.

 

Elementul DIV care incorporează grila de produse conține termenul „products” și acest lucru pare să fie comun în rândul website-urilor care obțin rich snippets fără a folosi un marcaj semantic. De asemenea, numele clasei de produse conține termenul „item”.

Rich snippet pentru categoria Running Shoes include numărul de produse pe pagină și numărul total de produse din această categorie.

 

Un număr total mare de produse în listă poate atrage mai multe click-uri, deoarece consumatorii caută o listă cuprinzătoare când aleg unde să dea click. Astfel ajungem la o altă idee de optimizare.

Reanalizați numărul de produse din listare

Dacă numărul de produse din categoria vizualizată în mod curent este destul de mic și ușor de răsfoit (de ex., 50 produse într-o grilă cu cinci rânduri pe zece coloane), atunci încărcați-le pe toate pe o pagină. În funcție de câte link-uri aveți pe pagină și autoritatea generală a domeniului, puteți urca acest număr la 100 sau chiar mai mult.

Dacă credeți că este necesar să afișați un număr redus de produse din perspectiva experienței pentru utilizator, puteți încărca 50, 100 sau 150 produse în codul sursă într-o manieră prietenoasă SEO, și puteți folosi AJAX pentru a afișa doar 10, 15 sau 20 produse în browser, pentru a evita excesul de informații. Puteți folosi apoi AJAX pentru a actualiza conținutul paginii pe baza cererilor utilizatorilor, precum navigarea în josul paginii, sortare, afișare toate produsele etc.

Dacă aveți mii de produse sub aceeași categorie, luați în considerare defalcarea lor în subcategorii mai ușor de gestionat. Puteți lista subcategorii în loc de produse, după segmentarea lor în calupuri mai mici.

Etichetați recenziile produselor cu un marcaj structurat

Aceasta este o strategie deschisă dezbaterilor, prin urmare trebuie să fiți atenți la modul în care o implementați. Motoarele de căutare nu suportă marcajul pentru recenziile produselor pe paginile de listare și pot considera un astfel de marcaj ca spam; fiți atenți.

Marcajul Review poate fi folosi în siguranță doar pe paginile PDP. Paginile PLP ar trebui să limiteze acest marcaj.

 

Asigurați-vă că nu folosiți entitatea AggregateOffer în marcaj deoarece va putea fi considerat spam. Cea mai sigură entitate de folosit pe PLP este Offer. Pentru a învăța mai mult despre marcajul produselor Schema.org citiți acest articol.[4]

Afișați căutările legate de categorie sub câmpul de căutare

Secțiunea Related searches (căutări similare) a fost tradițional folosită pentru a face link intern cu celelalte pagini și pentru a aplatiza arhitectura website-ului. Iată un exemplu clasic:

Secțiunea Related Searches ajută la linking-ul intern către celelalte pagini.

 

Căutările similare există pentru a ajuta utilizatorii să descoperă și să identifice produsele, oferind link-uri foarte relevante către celelalte pagini ale unui website. Dat fiind acest lucru, de ce să nu le plasați mai aproape de locul în care utilizatorii ar efectua o astfel de căutare, precum câmpul de căutare? Puteți vedea acest lucru pe website-ul Zappos:

Link-urile din secțiunea Search by sunt plasate într-un loc vizibil, pentru a transfera autoritate paginilor cu care se face linking și pentru a ajuta utilizatorii.

 

Totuși, pe Zappos link-urile sunt aceleași pe fiecare pagină și nu au logică pe secțiunea Bags a website-ului:

Zappos afișează opțiunile de căutare ca link-uri HTML simple imediat sub câmpul de căutare.

 

Size, Narrow Shoes și Wide Shoes nu sunt detalii utile pentru cineva care caută genți, nu-i așa? În schimb, puteți modifica dinamic aceste link-uri către ceva înrudit cu gențile, poate făcând un link la o pagină care filtrează gențile după Stil sau alte atribute care se potrivesc categoriei genți (Bags).

Dacă nu doriți să folosiți prea mult spațiu pentru a lista 10 sau mai multe căutări similare populare, puteți implementa o fereastră modală care se deschide la click pe “Căutări populare”. Asigurați-vă că conținutul acesteia este disponibil motoarelor de căutare la încărcarea paginii. Puteți lista oricâte cuvinte cheie similare populare câte doriți pentru fiecare categorie.

Imaginea de mai sus descrie o posibilă implementare a căutărilor populare folosind fereastra modală.

 

După cum am menționat în secțiunea Home Pages (pagini de start), puteți folosi una din sursele următoare pentru a descoperi căutările utile pentru utilizatori:

  • Aflați care sunt căutările cele mai frecvente pe fiecare pagină de categorii.
  • Identificați produsele sau subcategoriile cele mai vizitate după vizualizarea paginii de categorii.
  • Obțineți principalele cuvinte cheie de referință. Rețineți, Google și alte motoare de căutare comerciale ascund căutările sub eticheta „indisponibil” (not provided).

Întârziați încărcarea imaginilor thumbnail pentru produse

Atunci când încărcați zeci de produse într-o pagină de listare, există șanse ca multe din ele să se afle sub linia primului ecran (below the fold).[5] Încărcarea simultană a tuturor imaginilor thumbnail nu este nici necesară, nici recomandată. Încărcați imaginea doar când utilizatorul navighează în jos pentru a vizualiza mai multe produse.

Deși întârzierea afișării imaginilor nu are un impact mare asupra clasărilor în Google, va îmbunătăți experiența utilizatorilor scăzând timpul de încărcare a paginii.

Observați cât de mic este cursorul scroll lateral (pătratul roșu); această dimensiune transmite faptul că pagina este foarte lungă. Produsele din imagine sunt la câteva mii de pixeli „sub primul ecran”.

 

O scurtă avertizare cu privire la înțelesul termenului „primul ecran”. Acesta are un înțeles foarte clar în tipografie (respectiv îndoirea pe mijloc a ziarului), dar în ceea ce privește website-urile semnificația nu e atât de clară. Va trebui să identificați și să definiți primul ecran al website-ului vostru, luând în calcul rezoluția browser-ului și sistemele folosite cel mai des de majoritatea utilizatorilor.

Evident, primul ecran va fi diferită pe mobil decât pe desktop.

Înlăturați sau consolidați link-urile inutile

Listele de produse ridică adesea problema link-urilor repetitive. De exemplu, în imaginea de mai jos există un link pe imaginea thumbnail a produsului și un altul pe numele produsului. Ambele indică spre același URL.

Link-urile de pe imaginea thumbnail a produsului și numele produsului indică spre același URL.

Există mai multe moduri de soluționare a acestei probleme, și le-am discutat anterior. Vedeți secțiunea Poziția link-ului din secțiunea Linking intern.

O altă problemă foarte similară redundanței link-urilor pe thumbnail și nume produs apare când plasați un link pe stelele recenziei și alt link pe textul care afișează numărul de recenzii pentru același produs:

Link-ul imagine de pe stele și link-ul text pe numărul “6” trimit la același URL.

 

În exemplul de mai sus, niciunul din link-uri nu poate oferi o relevanță deosebită motoarelor de căutare din cauza lipsei textului ancoră, prin urmare păstrați un singur link. Aș păstra link-urile pe imaginile stelelor, deoarece puteți adăuga un context SEO suplimentar folosind alt text și deoarece zona pentru link pe aceste imagini este mai mare decât numerele text. Link-ul de pe numărul de recenzii ar putea, eventual, fi scris cu JavaScript.

Înlăturarea link-urilor inutile sau a altor elemente de pe pagină poate decongestiona designul, oferind spațiere între produse, și poate reduce numărul de link-uri care au scurgeri de autoritate către pagini greșite.

Este inutil să afișați link-ul cu Special Offers pentru fiecare produs. În schimb, folosiți tooltips sau afișați mici simboluri sau stickere pentru a scoate în evidență astfel de oferte.

 

Un alt element listat frecvent în lista de produse este butonul „adaugă în coș”. Nu sugerez că ar trebui să îl înlăturați din acest tip de pagină fără o analiză riguroasă, dar puteți face un test A/B pentru a vedea modul în care influențează rata de conversie.

Vă recomand să urmăriți evenimentele „adaugă în coș” și să analizați dacă utilizatorii adaugă produse în coș direct din paginile de listare produse. Dacă da, mergeți un pas înainte și identificați ce tip de utilizatori fac acest lucru (de ex., clienți anteriori, vizitatori pentru prima dată etc.). În multe cazuri, cei care adaugă produse direct de pe pagina de listare a produselor sunt clienți anteriori care cunosc foarte bine marca, produsele, și website-ul; de obicei, ei știu exact ce doresc. Dacă hotărâți să scoateți butoanele „adaugă în coș”, acești utilizatori vor ști că pot adăuga produse în coș de pe paginile cu detalii despre produs.

Utilitatea butoanelor „adaugă în coș” de pe paginile de listare a produselor trebuie testată. Testați-o prin înlocuirea cu alte CTAs, adăugarea unor detalii suplimentare produselor, sau scoaterea completă a acestei funcționalități.

 

Faceți vizualizarea de tip listă vizualizarea implicită

De obicei, vizualizarea tip listă permite mai mult spațiu pentru conținut legat de produse, ceea ce este util pentru utilizatori și motoarele de căutare.

Aceasta este vizualizarea grilă. Nu există prea mult spațiu pentru a prezenta informații despre produs într-o grilă (doar numele și prețul).

 

Într-o vizualizare tip listă există spațiu pentru afișarea mai multor informații despre produse.

 

În exemplul de mai sus, vizualizarea tip listă este implicită (default) pentru utilizatori și motoarele de căutare, dar utilizatorii au opțiunea de a trece la vizualizarea tip grilă, în interfață.

La începutul acestei secțiuni am menționat că există două tipuri de listări. Până acum, am discutat despre listările de produse. Este timpul să vorbim acum despre cel de-al doilea tip:

Listările de categorii (cunoscute ca și pagini pentru categorii)

Listarea de categorii înseamnă că în loc să afișați produse, arătați subcategoriile disponibile pe care le conține o categorie, fiecare afișată printr-o imagine thumbnail reprezentativă. Listările de categorii sunt implementate în primele două sau trei niveluri ale ierarhiei de categorii a unui site, în funcție de dimensiunea catalogului de produse. Deoarece numărul de subcategorii de afișat este redus, de cele mai multe ori paginile de listare a categoriilor folosesc vizualizarea tip grilă și nu cea tip listă.

Să vedem cum Home Depot au implementat grila cu subcategorii de o manieră prietenoasă cu utilizatorul și motoarele de căutare.

Acesta este primul nivel al ierarhiei, Appliances.

 

Primul nivel din ierarhie (Appliances), listează mai multe imagini de subcategorii (Refrigerators, Ranges, Washers, etc.), precum și link-uri de sub-subcategorii (de ex., sub Refrigerators ei prezintă link-uri către French Door Refrigerators, Top Freezer Refrigerators, Side By Side Refrigerators etc.)

Când dați click pe Refrigerators, se încarcă o pagină care listează categorii. De data aceasta listarea afișează cele mai importante sub-subcategorii pentru subcategoria Refrigerators.

Acesta este al treilea nivel al ierarhiei.

 

Al treilea nivel al ierarhiei (Appliances > Refrigeration > Refrigerators) încă listează categorii în loc de produse. Acest lucru încurajează utilizatorii să aleagă un traseu de selecție mai precis înainte ca pagina să afișeze zeci sau sute de produse.

Implementarea listărilor de subcategorii în primele două niveluri ale ierarhiei e-commerce are avantajul de a trimite mai mult PageRank paginilor de subcategorii. Este mai bine astfel decât transferul de PageRank doar spre câteva produse, deoarece eforturile de obținere a backlink ar trebui să facă trimitere spre paginile de categorii și subcategorii. Nu este fezabil economic să vizați paginile de produse cu construirea de link-uri decât dacă aveți un buget foarte mare sau doar puține produse în catalog. Dezvoltarea de backlink-uri externe construiește autoritate SEO pentru paginile de categorii și subcategorii, care se transferă mai departe paginilor PDP.

Implementarea primelor două niveluri ale ierarhiei e-commerce ca listare de subcategoriilor facilitează, de asemenea, o experiență mai bună pentru utilizatori. Testele de uzabilitate web au demonstrat[6] că utilizatorii pot fi încurajați să navigheze mai adânc în nivelurile ierarhiei și să facă alegeri mai bune ale gamei de produse.

Alegerea dintre listarea produselor și a subcategoriilor depinde de particularitățile fiecărui website. De obicei, listarea subcategoriilor este o alegere mai bună, în special pentru website-urile cu stocuri mari de produse, si cu un număr mare de categorii. Decizia legată de subcategoriile care trebuie prezentate la fiecare nivel al ierarhiei ar trebui să se bazeze pe reguli de business (de ex., primele cinci categorii cu marja cea mai mare de profit sau primele cinci cel mai bine vândute produse).

Iată câteva recomandări pentru construirea unor pagini de listare a subcategoriilor mai bune:

  • Pentru a trimite autoritate SEO direct către produse, adăugați o listă a produselor de top în partea de jos a paginii, după cum puteți vedea în imaginea următoare:

Rețineți să nu listați prea multe produse; 5-10 produse e suficient.

 

  • Păstrați navigarea laterală stânga disponibilă utilizatorilor deoarece aici au fost formați să caute pentru navigarea secundară; acest tipar de navigare influențează conversiile[7]. De asemenea, este mai ușor să scanezi și să alegi din link-uri de navigare secundară.
  • Navigarea secundară nu va conține filtre până când utilizatorul nu ajunge într-un punct în care listați produse în loc de subcategorii.
  • Afișați imagini thumbnail profesionale, după cum se arată mai jos.

Imaginile de înaltă calitate asigură utilizatorii că au de-a face cu o firmă serioasă.

 

  • Adăugați o descriere scurtă a categoriei ori de câte ori este posibil și eventual faceți link spre ghiduri de cumpărare sau instrumente interactive de identificare a produselor pentru a-i ajuta pe utilizatori să se hotărască ce produs este cel mai bun pentru ei. Acest lucru este cu atât mai important cu cât piața voastră țintă nu cunoaște foarte bine produsele pe care le vindeți sau dacă vindeți produse de mare valoare.

O descriere scurtă pentru fiecare categorie poate ajuta utilizatorii care cumpără pentru prima dată să înțeleagă terminologia nișei și poate oferi mai mult context motoarelor de căutare.

 

Oferirea de ghiduri și conținut educațional ajută la creșterea ratei de conversie.

 

În exemplul de mai sus, designul original nu includea butoane precum “Find the right fridge”, “Find the right washer“sau “Find the right dryer”. Totuși, aceste link-uri pot fi de mare valoare pentru utilizatori și pot ajuta la SEO, de asemenea. Dacă utilizatorii dau click pe aceste butoane după ce au ajuns pe o pagină după o căutare generică (de ex., „cele mai bune electrocasnice”), click-urile vor ajuta la micșorarea ratei bounce și va conduce la timpi mai buni de vizitare a site-ului.

  • Folosiți o funcționalitate SEO de vizualizare rapidă (Quick View) pentru a adăuga mai multe detalii despre fiecare categorie.

La fel cum această funcționalitate merge pe paginile de listare produse, o abordare similară poate fi implementată pentru listările de categorii.

În această imagine am adăugat butonul More Info la designul original în scop ilustrativ.

 

Un click pe More Info va deschide o fereastră modală. În această fereastră puteți include detalii precum o scurtă explicație a categoriei, ceea ce utilizatorii pot găsi în această categorie, link-uri către alte categorii din ierarhie și chiar întrebări și răspunsuri frecvente.

Breadcrumbs

Breadcrumbs sunt o formă de elemente de navigare și sunt afișate de obicei între titlu și conținutul principal:

Breadcrumbs oferă un sentiment de “localizare” pentru utilizatori.

 

De exemplu, un breadcrumb pe un website care vinde produse de bricolaj ar putea suna așa: Home > Appliances > Cooking.

În structura unui breadcrumb, Home, Appliances, și Cooking sunt denumite elemente, iar semnul > este denumit separator.

Breadcrumbs sunt adesea neglijate ca factor SEO, dar există câteva motive bune pentru care ar trebui să le acordați o atenție sporită:

  • Link-urile din breadcrumb sunt elemente de navigare foarte importante care comunică locația unei pagini în ierarhia website-ului pentru utilizatori și îi ajută să navigheze ușor în interiorul website-ului.[8],[9]
  • Breadcrumbs sunt unul din cele mai bune moduri de a crea silozuri (silos), permițând roboților motoarelor de căutare să facă crawling vertical spre nivelurile superioare ale taxonomiei.
  • Navigarea prin breadcrumb ajută motoarele de căutare să analizeze și să înțeleagă arhitectura site-ului.
  • Breadcrumbs sunt unul din cele mai sigure locuri unde puteți folosi cuvinte cheie exacte pentru textul ancoră.

În ciuda uzabilității bune și a beneficiilor SEO, multe website-uri de ecommerce nu reușesc să implementeze corect breadcrumbs pentru utilizatori și motoarele de căutare.

Puteți ghici ce pagină este în exemplul de mai sus?

 

Aruncați o privire rapidă pe imaginea de mai sus. Ce pagină credeți că este? Este Edition page? Poate pagina Gifts? Sau Designer Sale? Sau este pagina Shop by Designer page? Niciuna din acestea. Este pagina de categorie Shoes & Handbags. Ați descoperit eticheta, până acum? Este în drop-down în navigarea din stânga.

Folosirea unui breadcrumb pe acest website ar ușura sarcina pentru utilizatori să înțeleagă unde se află în ierarhie.

Dacă doar uzabilitatea nu v-a convins încă să acordați o atenție mai mare pentru breadcrumbs, atunci poate este momentul să vă reamintesc că unele breadcrumbs corect implementare apar direct în rezultatele căutării în Bing[10] și Google:[11]

SERP snippets care conțin breadcrumbs.

 

În această imagine vedeți cum website-urile BestBuy, NewEgg, și Dell au o structură breadcrumb în snippet-ul rezultatelor, dar Walmart nu are niciuna. Probabil codul lor HTML pentru breadcrumbs nu este marcat corect.

Cu privire la includerea breadcrumb-urilor în SERP rich snippets, un brevet Google[12] discută despre taxonomia website-ului, linking-ul intern, navigarea primară și secundară, și URL-uri structurare printre alte lucruri pe care le iau în considerare când decid să afișeze breadcrumbs în SERP. Pentru a crește șansele ca breadcrumbs să apară în paginile de rezultate ale motoarelor de căutare, implementați-le în mod constant pe întreg website-ul și respectați recomandările oficiale ale Google folosind marcajul structurat Breadcrumbs cu micro-data sau RDFa.[13]

În trecut, listările breadcrumbs în rezultatele căutării permiteau utilizatorilor nu doar să dea click pe titlul albastru din SERP, ci și pe breadcrumbs, de asemenea. Totuși, Google a hotărât să nu mai facă hyperlink pentru aceste link-uri din breadcrumbs. Presupun că utilizatorii dădeau click pe link-uri de categorii intermediare și ajungeau pe pagini care nu se potriveau intenției căutării, așa că Google a decis să retragă această opțiune.

Dacă un produs este clasificat în mai multe categorii, este OK să listați mai multe breadcrumbs pe aceeași pagină,[14] atât timp cât produsul nu este clasificat în prea multe categorii diferite. Totuși, primul breadcrumb de pe pagină trebuie să fie traseul canonic spre acel produs, deoarece Google alege primul breadcrumb pe care îl găsește pe pagină.

Breadcrumbs declanșate doar la un anumit nivel de adâncime

Unele website-uri implementează breadcrumbs doar la o anumită adâncime în ierarhia website-ului, dar nu este cel mai bun lucru pentru utilizatori și motoarele de căutare.

Când utilizatorii se află pe pagina de categorie Furniture (primul nivel in ierarhie), nu există breadcrumbs.

 

Când utilizatorii navighează spre o subcategorie din Furniture (de ex. Bedroom Furniture), breadcrumbs încep să fie afișate. Toate subcategoriile aflate sub Bedroom Furniture vor avea breadcrumbs.

 

Breadcrumbs care sunt afișate la o anumită adâncime pot funcționa bine pentru utilizatorii care încep navigarea de pe pagina de start, dar în prezent orice pagină de pe website ar putea sluji drept punct de intrare pentru utilizatori și motoarele de căutare. Prin urmare, este important să includeți breadcrumbs de la primul nivel al taxonomiei website-ului. Suplimentar, folosirea de breadcrumbs doar pe unele pagini dar nu pe altele poate dezorienta utilizatorii.

De multe ori, numele categoriei este prezentat, de asemenea, în breadcrumbs.

 

Este OK să repetați numele categoriei în breadcrumb și titlu. Totuși, ultimul element din breadcrumb nu trebuie să fie link, deoarece acel link va face auto-referențiere la pagina activă, ceea ce este foarte derutant pentru utilizatori.

În funcție de modul de implementare, există trei tipuri de breadcrumbs:[15] bazate pe traseul pe site (path-based), bazate pe locație (location-based) și bazate pe atribute (attribute-based).

Breadcrumbs bazate pe traseul pe site

Acest tip de breadcrumbs arată traseul urmat de utilizatori în cadrul website-ului pentru a ajunge la pagina curentă. Acționează de genul unui indiciu „așa ați ajuns aici” pentru utilizatori. Breadcrumbs vor fi actualizate dinamic pentru a reflecta istoricul navigării pe site. Istoricul paginilor vizualizate se realizează fie prin etichetarea URL-urilor, fie prin cookies bazate pe sesiuni.

Nu este o idee bună să implementați acest tip de breadcrumb, exceptând paginile de rezultate pentru căutările internă pe site. Utilizatorii care ajung de de pe motoarele de căutare pot atinge pagini adânci din cadrul unui website fără a fi nevoiți să navigheze prin website. În acest caz, un breadcrumb bazat pe paginile vizitate devine lipsit de sens pentru utilizatori. Același lucru se aplică roboților motoarelor de căutare, care pot ajunge la pagini din josul ierarhiei din surse de referință externe.

Breadcrumbs bazate pe locație

Acesta este cel mai popular tip de breadcrumb și indică poziția paginii curente în ierarhia website-ului. Este indiciul de genul „vă aflați aici” pentru utilizatori. Acest tip de breadcrumbs menține utilizatorii pe un traseu fix de navigare, pe baza taxonomiei website-ului, indiferent de paginile anterioare vizitate în timpul navigării. Acesta este tipul de breadcrumb recomandat de taxonomiști[16] și de experții în uzabilitate.[17]

Pe paginile categoriilor de nivel de top, breadcrumb va fi doar un link către pagina de start, în timp ce numele categoriei va fi text simplu (nu un hyperlink).

Numele categoriei nu are hyperlink, deoarece aceasta este pagina activă. Acesta este comportamentul corect.

 

Primul element din breadcrumb ar trebui să fie întotdeauna un link către pagina de start, dar nu trebuie neapărat să folosească textul ancoră „pagină de start” sau „acasă”. Puteți folosi în schimb numele companiei sau un mic simbol tip căsuță cu numele companiei în alt text.

Nivelurile următoare din breadcrumbs sunt numele categoriilor și subcategoriilor folosite în taxonomie. Repet, nu faceți un link pe pagina curentă deoarece va deruta utilizatorii.

Există situații când utilizarea unui cuvânt cheie în link-ul textului ancoră care face trimitere la pagina de start are sens (de exemplu, când numele afacerii este The Furniture Store). Dar chiar și atunci, folosiți-l cu atenție.

 

Breadcrumbs bazate pe atribute

Beadcrumbs bazate pe atribute, după cum sugerează numele, folosesc atribute ale produselor sau valori ale filtrelor (precum stil, culoare sau marcă) pentru a crea o navigare care este prezentată în genul unui breadcrumb. Acest tip de breadcrumb este un indiciu de genul „așa ați filtrat produsele” pentru utilizatori:

Această pagină prezintă breadcrumbs ca filtre.

 

Dacă ați da click pe Bed &Bath și apoi pe Comforter Sets ați vedea breadcrumbs listate în partea de sus a paginii. În exemplul de mai sus, elementele din breadcrumb nu sunt link-uri (semnele „X” sunt link-uri).

Din punct de vedere tehnic, acestea nu sunt breadcrumbs, ci mai curând valori ale filtrelor. Totuși, această implementare copiază utilizarea tradițională de breadcrumbs, iar utilizatorii se așteaptă ca filtrele să poate fi accesate, la fel cum se așteaptă ca breadcrumbs să fie afișate orizontal și nu vertical.

Nu recomand de obicei înlocuirea categoriilor cu filtre pentru categoriile de nivel de top și pentru primele niveluri de subcategorii. Alegerea dintre o categorie și un filtru se rezumă la momentul în care nu are sens să creați categorii separate pentru atribute specifice ale produselor. De exemplu, categorii separate pentru dimensiunile de pantofi nu are sens. Dimensiunea este mai curând un atribut al produsului care se va traduce într-un filtru de navigare pe partea stângă.

Separator

Trebuie să separați clar fiecare element din șirul breadcrumb; puteți separa elementele cu ajutorul separatoarelor. Cel mai comun separator între elementele unui breadcrumb este semnul „mai mare decât” (>). Alte opțiuni bune includ semnele (»), (/) sau săgețile (→). Nu uitați să marcați separatoarele cu entitățile HTML corecte.[18]

Paginare

SEO începe să se complice când paginile de listare au nevoie de paginare. Paginarea apare pe website-urile de e-commerce din cauza numărului mare de produse care trebuie segmentate în mai multe pagini (cunoscute, de asemenea, drept pagini componente). De obicei, paginarea apare pe paginile de listare a produselor și pe paginile de căutare internă pe site.

Paginarea din exemplul de mai sus se întinde pe 113 pagini, ceea ce este mult prea mult pentru utilizatori și este greu de optimizat pentru roboții de căutare.

 

Dacă paginarea apare pe paginile care listează alte subcategorii în loc de produse, este timpul să revizuiți structura, făcând subcategoriile disponibile utilizatorilor fără paginare. Puteți face acest lucru crescând numărul de subcategorii pe care le prezentați pe o pagină sau prin împărțirea subcategoriilor în sub-subcategorii.

Paginarea este una din cele mai vechi probleme apărute pe website-urile cu seturi mari de produse și rezolvarea sa însemna ochirea unei ținte în mișcare. În prezent, abordarea cea mai recomandată este cu relaționările rel=“prev” și rel=“next”.

Totuși, au existat câteva strategii de abordare a paginării chiar înainte ca Google să introducă aceste relații la finalul anului 2011. Astfel de strategii includeau non-indexarea tuturor paginilor, cu excepția primei pagini sau utilizarea unei pagini view-all (vizualizează toate produsele).

Pentru a face paginarea și mai derutantă, Google spune că una din opțiunile de gestionare a paginării este să le lăsăm „așa cum sunt”,[19] sugerând că pot identifica o pagină canonică și pot gestiona bine paginarea.

Cu toate acestea, orice puteți face pentru a ajuta motoarele de căutare să înțeleagă mai bine sau mai eficient website-ul, este în avantajul vostru. Problema nu este dacă trebuie să faceți ceva cu paginarea, ci cum să procedați.

Din perspectiva SEO, o funcție “simplă” precum paginarea poate pune probleme serioase capacității motoarelor de căutare de a face crawling și de a indexa conținutul site-ului vostru. Să aruncăm o privire asupra unor probleme legate de paginare.

Probleme de crawling

O listare cu mii de produse va avea nevoie de paginare deoarece o prezentare ca atare a acestora nu va ajuta nici utilizatorii, nici motoarele de căutare. Totuși, paginarea poate afecta o structură plată a unui website mai mult ca orice altceva.

De exemplu, în exemplul de mai jos este posibil ca motoarele de căutare să aibă nevoie de 15 pași pentru a ajunge la pagina 50. Dacă singurul mod de a ajunge la produsele listate pe pagina 50 este de a trece prin paginare pagină cu pagină, acele produse vor avea o șansă foarte redusă de a fi descoperite. Probabil acele pagini vor fi supuse procesului de crawling mai puțin frecvent, ceea ce nu este ideal.

Ne aflăm pe pagina 7 din serie și această pagină listează trei URL-uri suplimentare de paginare (8, 9 și 10) în comparație cu pagina 1.

 

În exemplul nostru de paginare există pagini componente lipsă din serie (paginile 2 și 3), ceea ce înseamnă că roboții de căutare pot sări de la pagina 1 direct la pagina 4. Datorită acestor lipsuri din URL-urile componente, roboții pot ajunge la pagina 50 în aproximativ 15 pași în loc de 43 (roboții vor avea nevoie de 43 pași pentru a atinge pagina 50 deoarece ei pot merge de la pagina 1 direct la pagina 7 deoarece pagina 7 este listată pe pagina index. De la pagina 7 vor fi necesari alți 43 pași/click-uri pe Next până când ajung la pagina 50).

Șansele ca Googlebot să “sară” prin conținutul paginat pentru a face crawling pe paginile finale descresc cu fiecare pagină din serie și mai semnificativ la pagina 5.

Graficul de mai sus este un experiment asupra paginării. După cum puteți vedea, Google face crawling pe paginile componente 6-N mult mai rar.[20]

 

Experimentul a demonstrat că:

“Cu cât numărul paginii este mai mare, cu atât este mai mică probabilitatea ca acea pagină să fie indexată…În medie, șansa ca robotul să facă crawling pe pagina următoare a rezultatelor de căutare descrește cu 1,2 – 1,3% pe pagină”.

Dacă aveți un număr mare de pagini componente, găsiți un mod de a adăuga link-uri paginilor intermediare în serie. În loc să faceți linking către paginile 1, 2, 3 și 4 și apoi să săriți la ultima pagină, adăugați link-uri către pagini intermediare multiple. În exemplul nostru de mai sus, putem rupe seria în patru părți făcând linking la fiecare a 28-a pagină din serie. De ce am ales să fac link la fiecare a 28-a pagină componentă? Deoarece am dorit să rup paginarea în patru (112 împărțit la patru egal 28).

Cu cât aveți mai puține pagini componente în paginare, cu atât mai puține calupuri veți folosi. De exemplu, dacă aveți 10 pagini componente, veți lista link-uri către toate. Dacă aveți 50, veți împărți la 2; 100 va fi împărțit la 4, 200 la 8 și așa mai departe.

Așadar, paginarea poată arăta acum astfel:

Asigurați-vă că navigarea pe fiecare pagină din serie are logică pentru utilizatori.

 

Odată ce ați făcut schimbări la paginare, puteți evalua impactul după o săptămână sau două. În plus, puteți folosi analiza de fișier log de pe server pentru a determina comportamentul Googlebot înainte și după ce ați făcut modificări la paginare.

Metadate duplicate

Deși produsele listate pe paginile 2 la N sunt diferite, foarte des fiecare pagină componentă are același titlu și descriere meta de-a lungul întregii serii. Uneori, chiar copia conținutului SEO este duplicată de-a lungul seriei de paginare, ceea ce înseamnă că pagina index va concura cu paginile componente. În multe cazuri, această duplicare se datorează configurării implicite a CMS-ului.

Luați în calcul următoarele aspecte pentru a îmbunătăți sau evita această situație:

  • Creați titluri și descrieri personalizate, unice, pentru paginile de indexare (pagina 1 din fiecare serie).
  • Scrieți titluri și descrieri șablon (boilerplate) pentru paginile 2-N. De exemplu, puteți folosi titlul paginii 1 cu text șablon anexat la final “{Title Page One} – Page X/Y”.
  • Nu repetați copia SEO (dacă aveți una) de pe pagina index pe paginile componente.

Este posibil ca adăugarea acestui caracter unic titlurilor, descrierilor și copiei pentru întreaga serie să nu aibă un impact uriaș asupra clasărilor pentru paginile 2 la N, dar ajută Google să consolideze relevanța pentru pagina index. În plus, paginile componente vor trimite semnale interne de calitate și nu vor concura cu pagina index.

O altă problemă de conținut duplicat specifică paginării poate apărea când faceți referință la prima pagină din serie (respectiv pagina index) de pe paginile componente:

mysite.com/category/

mysite.com/category?page=1

URL-uri care fac trimitere spre pagina index (pagina 1 din serie) nu ar trebui să includă parametrii de paginare. În schimb, aceste link-uri ar trebui să facă trimitere la URL-ul categoriei de indexare, mysite.com/category/

Dispersia semnalelor de clasificare

Uneori, deoarece paginile componente din seria de paginare primesc link-uri interne (sau de pe site-uri externe), ele pot ajunge în SERP. În astfel de cazuri, semnalele de clasificare sunt dispersate către URL-uri multiple în loc să fie canalizate pe o singură pagină consolidată.

Dacă privim modul în care PageRank este transferat, conform primei lucrări pe acest subiect (publicată în 1998[21], care notează că PageRank se transferă egal prin fiecare link și are un factor de descompunere de 10 – 15%), atunci paginile componente par să fie adevărate găuri negre pentru PageRank – în special cele care nu au link de pe prima pagină din serie).

Să vedem cum PageRank se transferă pe o pagină view-all și pe câteva serii paginate. În scopul demonstrației noastre, vom împărți PageRank doar între paginile componente. Astfel se presupune că toate celelalte link-uri sunt similare pe toate paginile.

În scenariul de paginare de mai sus, produsele listate pe pagina 2 vor primi de aproximativ trei ori mai puțin PageRank decât produsele listate pe o pagină view-all.

 

Scenariul nostru este pentru o listare cu 100 produse pe o pagină cu PageRank 4. Din cauza factorului de descompunere, această pagină de listare va trimite doar 3,4 puncte PageRank către celelalte pagini, 4 x (1-0.15). Fiecare din cele 100 produse listate pe pagina view-all va primi 0.034 puncte PageRank.

Vom împărți aceeași listare în zece pagini dintr-o serie paginată, cu zece produse pe pagină. Vom avea link-uri către paginile 1, 2, 3, 4, 5…10.

Pentru prima pagină din serie vom avea următorii parametri:

  • PageRank-ul său este 4, același ca pe pagina view-all, iar valoarea care poate fi transferată către celelalte link-uri este de 3,4 puncte PageRank.
  • Numărul total de link-uri este 16 (10 link-uri pentru produse plus șase link-uri pentru URL-urile de paginare).
  • Fiecare URL de produs și paginăre primește 0.213 puncte PageRank.

Cele zece produse de pe prima pagină a paginării primesc de aproximativ șase ori mai mult PageRank decât produsele de pe pagina view-all.

A doua pagină are următori parametri:

  • Valoarea sa PageRank este 0.213, iar valoarea care se poate transfera mai departe spre toate celelalte link-uri este 0.181.
  • Numărul total de link-uri este în continuare 16 (10 link-uri pentru produse plus șase link-uri pentru URL-urile de paginare.
  • Fiecare URL de articol și paginare primește 0.011 puncte PageRank.

Cele zece produse de pe a doua pagină primesc de trei ori mai puțin PageRank decât produsele listate pe pagina view-all.

În paginarea de mai sus, pagina 6 din serie nu are link de pe pagina index.

 

Dacă un URL component nu este prezent pe prima pagină din serie (de ex., pagina 6 apare doar când utilizatorii dau click pe pagina 2 din serie, ca în imaginea de mai sus), atunci valoarea PageRank care se transferă produselor care au link de la pagina 6 este incredibil de redusă.

  • PageRank pentru această pagină este 0.011 (de la pagina 2), și valoarea care se poate transfera mai departe este 0.0096.
  • Numărul total de link-uri este 16 (10 link-uri pentru fiecare produs plus șase link-uri pentru URL-urile de paginare).
  • Fiecare URL de produs sau paginare primește 0.0006 puncte PageRank.

Acest lucru înseamnă că produsele de pe astfel de pagini vor primi de aproximativ 56 ori mai puțin PageRank decât produsele listate pe pagina view-all.

Această captură de ecran descrie modul în care PageRank se schimbă când modificați numărul de produse de pe fiecare pagină componentă (de ex. listarea unui număr de 10, 20 sau 25 produse pe pagină).

 

Dacă sunteți interesați în analizarea acestui model, puteți descărca fișierul Excel de aici.

Acest tipar al fluxului PageRank sugerează că:

  • Produsele listate pe prima pagină dintr-o serie de paginare primesc o valoare PageRank semnificativ mai mare decât cele listate pe paginile componente.
  • Cu cât aveți mai puține link-uri pe prima pagină, cu atât acestea sunt mai importante și cu atât mai mult PageRank primesc – nici o surpriză aici.
  • Dacă link-ul spre o pagină paginată nu este listat pe pagina index a seriei, acea pagină primește o valoare PageRank semnificativ redusă.

Produsele listate pe paginile 2-N primesc mai puțin PageRank decât dacă ar fi listate pe o pagină view-all. Excepție fac cazurile când primesc multe link-uri externe. Totuși, în practică PageRank este o metrică, care se transferă în moduri mai complexe. De exemplu, PageRank curge înainte și înapoi între pagini și mai mult PageRank este transferat de pe link-urile contextuale decât de pe link-urile de paginare. Valoarea PageRank care ajunge în paginile de paginare este imposibil de calculat (cu excepția Google).

Dar, acest model supra-simplificat ne arată că puteți transfera o valoare mare a PageRank unui număr redus de produse de pe prima pagină din paginare (și semnificativ mai mică produselor de pe paginile componente) sau puteți transfera o valoare medie de PageRank tuturor produselor, prin intermediul unei pagini view-all.

În ambele cazuri, dacă folosiți paginarea este esențial să plasați produsele cele mai importante în partea de sus a listei, pe prima pagină.

Conținut subțire (thin content)

Paginile de listare au de obicei un conținut redus sau nu au conținut deloc, sau cel puțin nu suficient de mult pentru ca motoarele de căutare să îl considere demn de indexare. Cu excepția numelor produselor și unele informații de bază, nu există prea mult text pe paginile PLP. Ca urmare, Panda a filtrat multe pagini de listare din indexul Google.

Utilitate îndoielnică

Vizitatorii site-ului folosesc paginarea? Aruncați o privire pe datele analitice pentru a afla. Paginile componente servesc ca puncte de intrare, fie de pe motoarele de căutare sau de pe alte referințe? Dacă nu, avantajele SEO și pentru utilizatori oferite de o pagină view-all ar putea fi mult mai mari decât în cazul paginării.

Este posibil ca paginarea să fie un rău necesar dacă arhitectura site-ului a fost deja implementată și este dificil de făcut actualizări, sau dacă un număr mare de produse nu pot fi împărțite și grupate în subcategorii multiple.

Dacă vreți să minimalizați problemele legate de paginare, probabil este mai bine să începeți cu arhitectura website-ului. Puteți evita unele probleme complicate legate de experiența utilizatorilor, IT și SEO făcând acest lucru. Ar trebui să luați în calcul următoarele aspecte:

Înlocuiți listările de produse cu listările de subcategorii

De exemplu, pe pagina de categorii Men’s Clothing din imaginea de mai jos, în loc să listați 2,037 produse, puteți lista subcategorii, precum Athletic Wear, Belts & Suspenders, Casual Shirts, și așa mai departe. Veți avea listări de produse doar în straturile mai profunde ale ierarhiei website-ului.

Pagina de categorie Men’s Clothing listează produse, dar în schimb ar trebui să listeze subcategorii, ca în imaginea de mai jos.

 

Aceasta este doar o simulare pe care am făcut-o pentru a demonstra înlocuirea listării de produse cu listarea de subcategorii.

 

Listarea de categorii în locul produselor va ajuta de asemenea, utilizatorii în a face alegeri mai rapide și bune.[22]

Faceți subcategorii mai mici

Dacă aveți o categorie cu sute sau mii de produse, poate este posibil să o împărțiți în segmente mai mici. Acest lucru va determina o scădere sau chiar va elimina numărul de pagini din serie.

Subcategoria Jeans & Pants poate fi împărțită în două subcategorii separate.

 

Segmentarea în subcategorii multiple poate înlătura complet necesitatea paginării dacă listați un număr rezonabil de produse. Totuși, nu exagerați; este bine să evitați un număr prea mare de subcategorii.

Creșteți numărul de produse din listă

Ideea din spatele acestei abordări este simplă: cu cât afișați mai multe produse pe o pagină de listare, cu atât mai puține pagini componente veți avea în serie. De exemplu, dacă listați 50 produse folosind o grilă 5×10 și aveți 295 produse de listat, veți avea nevoie de șase pagini în seria de paginare. Dacă creșteți numărul de produse la 100 veți avea nevoie doar de trei pagini pentru a le lista pe toate.

Cât de multe produse listați pe fiecare pagină depinde de cât de mult alte link-uri sunt pe pagină, de capacitatea web serverului de a încărca rapid paginile și de tipul de produse din listă. De exemplu, listările cu felicitări pot fi scanate mai încet decât listările de becuri. În general, 100 – 150 produse înseamnă o alegere bună.

Faceți link la mai multe URL-uri de paginare

În loc să săriți pagini din seria de paginare, faceți cât mai multe link-uri de paginare posibil.

Acest tip de paginare prezintă probleme mari de operabilitate.

 

Paginarea din imaginea anterioară cere motoarelor de căutare și utilizatorilor să dea click de șapte ori pe săgeata din dreapta pentru a ajunge la ultima pagină. Acesta este un lucru negativ pentru utilizatori și SEO.

În schimb, ar trebui să faceți link pentru toate URL-urile de paginare și paginarea va arăta astfel:

Cu această abordare este mai ușor pentru utilizatori să meargă la oricare din paginile componente.

 

Adăugarea de link-uri pentru un număr decent de URL-uri de paginare va permite roboților de căutare să ajungă la acele pagini în cât mai puțini pași posibil.

Dacă puteți, faceți inter-link între toate paginile componente. De exemplu, dacă listarea are ca rezultat un număr mai mic de 10 link-uri componente, puteți lista toate link-urile și nu doar 1, 2, 3…10. Dacă listarea generează un număr de URL-uri componente imposibil de gestionat, listați cât mai multe posibil fără a crea o experiență negativă pentru utilizatori.

Ideile menționate mai sus vă vor ajuta să minimalizați impactul paginării asupra SEO. Totuși, în multe cazuri paginarea este necesară în continuare – și va trebui să îi faceți față.

Modul în care abordați paginarea este situațional, ceea ce înseamnă că depinde de factori precum implementarea curentă, saturația indexării (numărul de pagini indexate de motoarele de căutare), media numărului de produse din categorii sau subcategorii și alți factori. Nu există o abordare generală.

În afară de abordarea „nu faceți nimic”, există variate metode SEO de a aborda paginarea:

  • Metoda “noindex, follow”.
  • Metoda view-all.
  • Metoda atributelor paginării, respectiv rel=“prev”, rel=“next”.
  • Metoda AJAX.

O abordare incorectă a paginării este să folosiți rel=“canonical” pentru a lega toate paginile componente dintr-o serie de prima pagină. Google afirmă că:

“Setarea canonical spre prima pagină a unei secvențe fără parametru este considerată utilizare improprie”.[23]

Metoda “noindex, follow”

Această metodă impune adăugarea meta robots “noindex,follow” în elementul <head>) al paginilor 2 – N ale seriei, în timp ce prima pagină va fi indexabilă. În plus, paginile 2 – N pot conține un atribut de auto-referențiere rel=“canonical”.

Din cele trei metode, aceasta este cea mai puțin complicată de implementat, dar efectiv scoate paginile 2-N din indicii motoarelor de căutare. Notați că această metodă nu transferă niciun semnal de indexare de la paginile componente la pagina primară, canonică.

Paginile de la 2 la N nu sunt indexabile pentru că au metaeticheta robots “noindex, follow”.

 

Dacă scopul este să scoateți paginile din index – deoarece ați fost loviți de un filtru legate de conținut subțire – atunce aceasta este cea mai bună abordare. De asemenea, o aplicare bună a acestei metodei de non-indexare este pentru paginile interne de căutare în site, deoarece Google și alte motoare de căutare de top nu vor să afișeze rezultate „căutare în căutare”.[24]

Blocarea accesului roboților de căutare la paginile componente se poate face cu robots.txt și din conturile webmaster. Aceste două opțiuni nu vor scoate paginile din indici; ele doar vor împiedica doar acțiunea viitoare de crawling. Mai mult, deși puteți folosi Google Search Console pentru a împiedica acțiunea de crawling pe paginile componente, este mai ușor să gestionați paginarea dacă le blocați într-un singur loc, fie cu robots.txt, fie cu GSC. Când faceți audit pe probleme de crawling și indexare, nu uitați unde ați blocat conținut.

Pagina “view-all”

Această metodă pare să fie alegerea preferată de Google pentru gestionarea paginării, deoarece

“utilizatorii preferă în general opțiunea view-all în rezultatele căutării”

Și deoarece,

“[Google] va face un efort mai mare de a detecta corect și de a servi această versiune utilizatorilor”.[25]

Această abordare pare să fie susținută de testele efectuate de profesioniști în uzabilitate, precum Jakob Nielsen, care a descoperit că:

“Opțiunea View-all [a fost] utilă pentru unii utilizatori. Mai important, opțiunea View-all nu i-a deranjat pe utilizatorii care nu au folosit-o; când nu a fost oferită, totuși, unii utilizatori s-au plâns de acest lucru”.[26]

Metoda view-all implică doi pași:

1. Crearea unei pagini view-all care listează toate produsele dintr-o categorie, ca în imaginea de mai jos:

Link-ul ”view-all 88 items” listează toate produsele.

 

2. Faceți pagina view-all URL-ul canonic al seriei paginate prin adăugarea atributului rel=“canonical” care face trimitere la URL-ul view-all, de pe fiecare pagină componentă:

Fiecare URL component trimite la pagina view-all.

 

Scopul folosiri rel= “canonical” este să consolideze toate semnalele link-urilor către pagina view-all. Cu abordarea view-all, toate paginile componente își pierd capacitatea de a se clasa în SERP.

Totuși, deși pagina view-all poate fi diferită de pagina index a listării, transformarea paginii view-all în pagină de indexare este posibilă, de asemenea.

Metoda view-all are unele avantaje, precum o operabilitate mai bună, consolidarea semnalului de indexare și implementarea relativ ușoară.

Totuși, există unele provocări pe care trebuie să le luați în calcul înainte de a crea o pagină view-all:

  • Consolidarea a sute sau mii de produse pe o singură pagină poate crește dramatic timpul de încărcare, în special pe paginile de listare produse. Un timp rapid de încărcare este considerat sub patru secunde, dar ar trebui să vă propuneți un timp de sub 2 secunde. Folosiți tehnica de încărcarea progresivă pentru a permite acest lucru.
  • O pagină view-all înseamnă sute sau mii de link-uri pe o singură pagină, deoarece pagina view-all trebuie să afișeze toate produsele de pe paginile componente. Deși o compensare poate fi consolidarea semnalelor de indexare de pe paginile componente pe pagina view-all, nu avem nici o declarație oficială cu privire la modul în care motoarele de căutare vor evalua un număr atât de mare de link-uri pe pagina view-all.
  • Uneori nu vreți să înlăturați toate celelalte pagini componente și să forțați pagina view-all să fie listată în SERP. Dacă doriți să scoateți la suprafață anumite pagini din seria de paginare, trebuie să folosiți rel=“next” și rel=“prev”.
  • Implementarea este puțin mai complexă decât în cazul metodei “noindex”. Totuși, nu este la fel de complexă ca folosirea atributelor de paginare.

Există situații când doriți să implementați pagina view-all doar pentru motive de experiență pentru utilizatori și nu doriți ca motoarele de căutare să o listeze în SERP. În astfel de situați asigurați-vă că paginile componente din serie nu au atributul rel=“canonical” care trimite la pagina view-all, ci spre prima pagină a paginării. De asemenea, marcați pagina view-all cu “noindex”. În plus, puteți face link-ul view-all disponibil doar oamenilor, folosind AJAX sau un conținut pe bază de cookies sau alte metode.

Dacă vă îngrijorează timpii de încărcare a paginilor, există moduri de a livra o versiune simplă a paginii view-all motoarelor de căutare, prezentând în același timp pagina complet randată utilizatorilor, la cerere și fără a crește timpii de încărcare. Aceste implementări trebuie să ia în calcul îmbunătățirea progresivă (progressive enhancement)[27] și experiența pentru utilizatorii pe mobil.

Totuși, în zilele noastre ar trebui să construiți aplicații web progresive (PWA) și aplicații de accelerare mobilă (AMP) pentru a permite o încărcare super-rapidă și nu să complicați lucrurile livrând resurse diferite roboților de căutare versus utilizatorii umani.

Deși de-paginarea poate funcționa pentru website-urile care au un număr rezonabil de mic de produse în listările lor, pentru website-urile cu stocuri mari de produse poate fi mai ușor să mențineți paginarea prietenoasă cu utilizatorul, care limitează numărul de produse. Din punctul de vedere al uzabilității,

“în mod tipic, această limită superioară ar trebui să fie în jur de 100 produse, deși poate fi mai mare sau mai mică, în funcție de cât de ușor este pentru utilizatori să scaneze produsele și cât de mult afectează timpul de răspuns o pagină lungă”.[28]

Atributele de paginare (sau metoda rel=”prev” și rel=”next”)

O altă metodă de gestionare a paginării este folosirea atributelor de paginare (cunoscută, de asemenea, ca metoda rel=“prev” și rel=“next”). Această metodă este, probabil, abordarea care se potrivește cel mai bine website-urilor de e-commerce de astăzi, deoarece pare să genereze rezultate bune fără a înlătura complet capacitatea paginilor de a se clasa în rezultatele de căutare.

În secțiunea <head> a fiecărei pagini componente din serie, folosiți fie atributul rel=“prev” fie rel=“next” (sau ambele) pentru a defini un “lanț” de componente paginate.

Atributele de relaționare prev și next au fost de mult timp standarde HTML,[29] dar au captat atenția doar atunci când Google le-a promovat. Rel=“prev” și rel=”next” sunt doar câteva indicii pentru a sugera paginarea; ele nu sunt directive.

Să spunem că aveți listări de produse paginate în următoarea serie:

http://www.website.com/duvet-covers/

http://www.website.com/duvet-covers?page=2

http://www.website.com/duvet-covers?page=3

http://www.website.com/duvet-covers?page=4

Pe prima pagină (pagina de index a categoriei), includeți acest rând în secțiunea <head>:

<link rel=“next” href=“http://www.website.com/duvet-covers?page=2” />

Prima pagină conține marcajul rel=“next” dar nu și rel=“prev”. În mod normal, prima pagină este pagina din serie care devine hub și este listată în SERP.

Pe cea de-a doua pagină, veți include aceste două rânduri în secțiunea <head> :

<link rel=“prev” href=“http://www.website.com/duvet-covers/” />

<link rel=“next” href=“http://www.website.com/duvet-covers?page=3” />

Paginile 2 până la penultima ar trebui să aibă atât marcajul rel=“next” cât și rel=“prev”.

Notați că pagina 2 face trimitere înapoi la prima pagină din paginare ca /duvet-covers/ în loc de /duvet-covers?page=1. Acesta este modul corect de a face referință la prima pagină din serie și nu rupe lanțul, deoarece:

/duvet-covers/ va trimite spre /duvet-covers?page=2 ca pagina următoare și

/duvet-covers?page=2 va indica spre /duvet-covers/ ca pagină precedentă.

Pe cea de-a treia pagină (http://www.website.com/duvet-covers?page=3) – veți include următorul marcaj în secțiunea <head> :

<link rel=“prev” href=“http://www.website.com/duvet-covers?page=2” />

<link rel=“next” href=“http://www.website.com/duvet-covers?page=4” />

Pe ultima pagină (http://www.website.com/duvet-covers?page=4), veți include următorul atribut de link:

<link rel=“prev” href=“http://www.website.com/duvet-covers?page=3” />

Observați că ultima pagină din serie conține doar marcajul rel=“prev”.

Metoda rel=”prev” rel=”next” are unele avantaje, precum:

  • Paginile componente păstrează și distribuie o cotă de autoritate cu toate celelalte pagini ale seriei.
  • Rezolvă problema paginării fără a trebui să adăugați atributul “noindex” paginilor componente.
  • Consolidează proprietățile de consolidare, precum textul ancoră și PageRank la fel ca în cazul implementării view-all. Acest lucru înseamnă că în majoritatea cazurilor pagina index a seriei va apărea în rezultatele căutării în Google.
  • Factorii SEO de pe pagină, precum titlurile, meta descrierile și URL-urile pot fi păstrate pentru paginile componente individuale, față de consolidarea într-o singură pagină view-all.
  • Dacă listarea poate fi sortată în moduri multiple folosind parametri URL, atunci aceste vizualizări multiple “ordonate după” sunt eligibile pentru a fi listate în SERP. Acest lucru nu este posibil cu abordarea view-all.

Nu este o idee bună să amestecați atribute de paginare cu o pagină de tip view-all. Dacă aveți o pagină view-all, indicați atributul rel=“canonical” pe toate paginile componente către pagina view-all și nu folosiți atribute de paginare. Puteți face, de asemenea, auto-referențiere pe paginile de conținut pentru a evita conținutul duplicat ca urmare a ID-urilor de sesiune și parametrilor de urmărire.

Utilizarea atributului rel=“canonical” în același timp cu rel=“prev” și rel=“next”

Atributele de paginare și rel=“canonical” sunt concepte independente și ambele pot fi folosite pentru a preveni problemele de conținut duplicat.

De exemplu, pagina 2 dintr-o serie ar putea conține un atribut rel=”canonical”, unul rel=“prev” și unul rel=“next”:

<link rel=“canonical” href=“http://www.website.com/duvet-covers?page=2” />

<link rel=“prev” href=“http://www.website.com/duvet-covers?sessionid=1235sfsd” />

<link rel=“next” href=“http://www.website.com/duvet-covers?page=3&sessionid=1235sfsd”/>

Această setare îi spune lui Google că pagina 2 este parte a unei serii de paginare și că versiunea canonică a paginii 2 este URL-ul fără parametrul sessionid. URL-ul canonic ar trebui să facă trimitere la pagina curentă fără nici o sortare, fără filtre, vizualizări sau alți parametri, dar rel=“prev” și rel=“next” ar trebui să includă parametrii.

Rețineți că atributul rel=“canonical” ar trebui folosit doar pentru conținutul duplicat sau aproape duplicat. Folosiți-l la:

  • URL-uri cu ID-uri de sesiune.
  • URL-uri cu parametri interni de urmărire sau referire (referrals).
  • Sortarea care schimbă afișajul pe pagină, dar nu conținutul (de ex., sortarea care se produce pe o singură pagină).
  • Subseturi ale unei pagini canonice (de ex., o pagină view-all).

Puteți folosi, de asemenea, rel=”canonical” pentru variațiile de produse, respectiv pagini PDP aproape duplicat care au aceeași descriere de produs, singura diferență fiind un atribut general al produsului (de ex., același pantof dar mărimi diferite). Trebuie să înțelegeți piața țintă înainte de a aplica atributul canonic și trebuie să puteți selecta, de asemenea, produsul canonic din colecția de SKU.

Parametrii rel=“prev”, rel=“next” și URL

Deși metoda rel=“prev” și rel=“next” pare mai avantajoasă decât metoda view-all din punct de vedere SEO, prezintă câteva probleme de implementare.

În ceea ce privește parametrii URL, regula pe paginile paginate este că atributele de paginare pot face link doar între URL-uri cu parametri similari. Singura excepție este atunci când scoateți parametrul de paginare pentru prima pagină din serie.

Pentru a face atributele de paginare să funcționeze corect, trebuie să vă asigurați că toate paginile din cadrul unei secvențe paginate rel=“prev” și rel=“next” folosesc aceeași parametri.

Paginarea și parametrii de urmărire a utilizării website-ului

Următoarele URL-uri nu sunt considerate parte a aceleași serii, deoarece URL-ul pentru pagina 3 are parametri diferiți și acest lucru ar rupe lanțul de paginare:

http://www.website.com/duvet-covers?page=2

http://www.website.com/duvet-covers?page=3&referrer=twitter

http://www.website.com/duvet-covers?page=4

În acest caz, trebuie să introduceți dinamic perechile valoare-cheie (key-value pairs) pe baza URL-ului solicitat (fetched URL).

Dacă URL-ul solicitat conține parametrul referrer=twitter (http://www.website.com/duvet-covers?page=3&referrer=twitter) atunci URL-urile de paginare ar trebui să includă dinamic și parametrul referrer:

<link rel=“prev” href=“http://www.website.com/duvet-covers?page=2&referrer=twitter”>

<link rel=“next” href=“http://www.website.com/duvet-covers?page=4&referrer=twitter”>

Suplimentar, puteți folosi Google Search Console pentru a indica Google că acest parametru nu schimbă conținutul paginii și să facă crawling doar pe URL-urile reprezentative (URL-uri fără parametrul referrer).

Paginarea și parametri de vizualizare sau sortare

Un alt scenariu frecvent în cazul paginării este sortarea și vizualizarea listărilor care se întind pe mai multe pagini. Deoarece fiecare opțiune de vizualizare generează parametri URL unici, va trebui să creați un set de paginare pentru fiecare vizualizare.

Să spunem că mai jos sunt URL-urile pentru “sortează după cel mai nou”, afișând 20 produse pe pagină:

http://www.website.com/duvet-covers?sort=newest&view=20

http://www.website.com/duvet-covers?sort=newest&view=20&page=2

http://www.website.com/duvet-covers?sort=newest&view=20&page=3

Pe pagina 1 veți avea doar atributul de paginare rel=“next” care indică spre URL-urile cu parametrii de sortare și vizualizare:

<link rel=“next” href=“http://www.website.com/duvet-covers?sort=newest&view=20&page=2”>

Pe pagina 2 veți avea rel=“prev” și rel=”next” care indică, de asemenea, spre URL-urile cu parametrii de sortare și vizualizare:

<link rel=“prev” href=“http://www.website.com/duvet-covers?sort=newest&view=20”>

<link rel=“next” href=“http://www.website.com/duvet-covers?sort=newest&view=20&page=3”>

Pe pagina 3 veți avea doar un atribut rel=”prev” care trimite, de asemenea, la URL-urile cu parametrii de sortare și vizualizare:

<link rel=“prev” href=“http://www.website.com/duvet-covers?sort=newest&view=20&page=2”>

Marcajul de mai sus definește o serie de paginare.

Totuși, dacă utilizatorii pot afișa 100 produse pe pagină, aceasta este o nouă opțiune de vizualizare și va crea o nouă serie de paginare. Noile URL-uri vor arăta ca cele de mai jos; parametrul view este egal acum cu 100.

http://www.website.com/duvet-covers?sort=newest&view=100

http://www.website.com/duvet-covers?sort=newest&view=100&page=2

http://www.website.com/duvet-covers?sort=newest&view=100&page=3

Pe pagina 1 veți avea doar atributul de paginare rel=“next” care indică spre URL-urile cu parametrii de sortare și vizualizare:

<link rel=“next” href=“http://www.website.com/duvet-covers?sort=newest&view=100&page=2”>

Pe pagina 2 veți avea rel=“prev” și rel=”next” care trimit, de asemenea, spre URL-urile cu parametrii de sortare și vizualizare:

<link rel=“prev” href=“http://www.website.com/duvet-covers?sort=newest&view=100”>

<link rel=“next” href=“http://www.website.com/duvet-covers?sort=newest&view=100&page=3”>

Pe pagina 3 veți avea doar un atribut rel=”prev”, care indică de asemenea spre URL-urile cu parametrii de sortare și vizualizare:

<link rel=“prev” href=“http://www.website.com/duvet-covers?sort=newest&view=100&page=2”>

Atunci când lucrați cu URL-uri de sortare, trebuie să împiedicați motoarele de căutare să indexeze opțiunile de sortare bidirecționale, deoarece sortarea după cel mai nou este aceeași cu sortarea după cel mai vechi, dar într-o ordine diferită. Păstrați un mod implicit pentru a face sortarea accesibilă, de ex. “cel mai nou”—și blocați-l pe celălalt, “cel mai vechi”.

De asemenea, adăugarea unei logici parametrilor URL nu doar previne problemele de conținut duplicat, dar poate și:

“ajuta la experiența pentru utilizator păstrând o ordine constantă a parametrului pe baza parametrilor cei mai importanți pentru utilizatori listați primii (așa cum URL-ul poate fi vizibil în rezultatele căutării) și a parametrilor cei mai puțin importanți listați la urmă )de ex., ID sesiune). Evitați example.com/category.php?session-id=123&tracking-id=456&category=gummy-candies&taste=sour”[30]

Asigurați-vă că parametrii care nu schimbă conținutul paginii (precum ID-urile de sesiune), sunt implementați ca perechi standard cheie-valoare, nu ca directoare. Acest lucru este necesar pentru ca motoarele de căutare să înțeleagă ce parametri sunt inutili și ce parametri sunt utili.

Iată câteva alte bune practici în domeniul atributelor de paginare:

  • Deși teoretic ați putea folosi URL-uri relative pentru a face referire la atributele de paginare, trebuie să folosiți URL-uri absolute pentru a evita cazurile în care URL-urile sunt duplicate în mod accidental în alte directoare sau sub-domenii.
  • Nu rupeți lanțul de paginare. Acest lucru înseamnă că pagina N ar trebui să trimită spre N-1 ca pagină anterioară și N+1 ca pagină următoare (cu excepția primei pagini, care nu va avea atributul “prev” și a ultimii pagini, care nu va avea atributul “next”).
  • O pagină nu poate conține atribute multiple rel=“next” sau rel=“prev”.[31]
  • Pagini diferite nu pot avea aceleași atribute rel=“next” sau rel=“prev”.

Probabil cel mai mare dezavantaj al atributelor rel=“prev” și rel=“next” este că sunt dificil de implementat, în special pe URL-urile cu parametri multipli. De asemenea, rețineți că Bing nu tratează relațiile next și prev la fel ca Google. Deși Bing folosește marcajul pentru a înțelege structura website-ului vostru, nu va consolida semnalele de indexare către o singură pagină. Dacă paginarea este o problemă în Bing, luați în calcul blocarea paginilor excesive cu o directivă specifică Bingbot-specific robots.txt directive sau o meta-etichetă noindex.

Metoda link-urilor AJAX sau JavaScript

Cu această metodă creați link-uri de paginare care nu sunt accesibile motoarelor de căutare dar sunt disponibile utilizatorilor, în browser. Compromisul este că utilizatorii care nu au JavaScript nu vor avea acces la paginile componente. Totuși, utilizatorii pot accesa o pagină view-all.

Link-urile de paginare din exemplul de mai sus nu sunt link-uri HTML simple.

 

În această imagine puteți vedea că interfața (1) le permite utilizatorilor să sorteze, precum și să aleagă între vizualizare tip listă și grilă. Permite, de asemenea, accesul la paginare. Totuși, codul sursă (2) dezvăluie o implementare JavaScript pentru paginare. Dacă resursele JavaScript necesare pentru generarea acestor link-uri sunt blocate cu robots.txt, Google nu va avea acces la acele URL-uri de paginare (3).

Această abordare are potențialul de a evita multe complicații legate de conținutul duplicat asociate cu paginarea, sortarea și opțiunile de vizualizare. Totuși, poate introduce probleme de descoperire a URL-urilor.

Dacă preferați această abordare, asigurați-vă că motoarele de căutare au cel puțin un alt mod de a accesa fiecare produs din fiecare listă — folosind, de exemplu:

  • O clasificare mai detaliată a produselor care nu necesită mai mult de 100 – 150 produse în fiecare listă.
  • Linking intern controlat, care leagă toate produsele de celelalte pagini de o manieră prietenoasă SEO.
  • Sitemaps HTML bine structurate, alături de XML Sitemaps.
  • Alte tipuri de link-uri interne.

Scrolling infinit

O alternativă frecventă de design în interfețele website-urilor pentru paginare este scrolling-ul infinit (infinite scrolling).[32] Cunoscut ca și scrolling continuu (continuous scrolling), metoda permite utilizatorilor să vizualizeze conținutul pe măsură ce dau scroll spre partea de jos a paginii, fără a mai fi necesar să dea click pe link-urile de paginare. Vizual, această alternativă pare foarte similară cu afișarea tuturor produselor pe o singură pagină. Totuși, diferența dintre infinite scrolling și o pagină view-all este că în cazul scrolling-ului infinit conținutul este încărcat la cerere (de ex., prin click pe butonul “încarcă mai multe produse” sau când conținutul devine vizibil deasupra liniei de mijloc), în timp ce pe o pagină view-all conținutul este încărcat tot o dată.

Website-urile mobile folosesc scrolling-ul infinit mai mult decât cele desktop, deoarece pe ecranele mici este mai ușor de glisat decât de dat click. Totuși, scrolling-ul infinit se bazează pe încărcarea progresivă cu AJAX,[33] ceea ce înseamnă că va trebui totuși să asigurați link-uri URL-urilor componente pentru motoarele de căutare sau utilizatori fără JavaScript activ. Veți face acest lucru cu ajutorul unei abordări de îmbunătățire progresivă (progressive enhancement).

Cât privește SEO, scrolling-ul infinit nu rezolvă problemele de paginare pentru stocurile mari de produse și acesta este unul din motive pentru care Google sugerează paginarea scroll-urilor infinite.[34]

Sfatul Google este OK, dar nu cred că scrolling-ul continuu are nevoie de paginare dacă nu există prea multe produse în listare; o pagină de tip view-all cu 200 produse este de preferat în multe cazuri. Totuși, paginile care listează mai mult de 200 produse și folosesc scrolling-ul infinit ar trebui să retrogradeze la link-uri de paginare HTML simple pentru utilizatorii non-JavaScript și acest lucru include și roboții motoarelor de căutare.

Retrogradarea la link-uri HTML înseamnă că motoarele de căutare pot întâlni în continuare probleme de paginare, astfel încât va trebui să gestionați paginarea cu una din metodele descrise mai sus.

Această imagine descrie versiunea cache a unei pagini de subcategorii care folosește scrolling infinit și retrogradează la link-uri HTML pentru paginare când utilizatorii nu au pornit JavaScript.

 

Pe pagina din capturile de ecran anterioare există link-uri pentru paginile Previous și Next pentru utilizatorii fără JavaScript activ (sau pentru motoarele de căutare).

Aceasta este o imagine a aceleași pagini, dar de data aceasta JavaScript este activ. Link-urile Previous și Next nu mai apar. Acest lucru a fost posibil prin ascunderea secțiunii de paginare cu CSS și JavaScript. Utilizatorii pot face scroll continuu pentru a vedea toate ceasurile.[35]

 

Scrolling-ul continuu are multe avantaje, precum o experiență mai bună pentru utilizatori pe dispozitivele tactile, parcurgerea mai rapida a site-ului ca urmare a eliminării reîncărcării paginilor, o identificare mai bună a produselor și consolidarea link-urilor externe.

Totuși, există și dezavantaje,[36] iar scrolling-ul infinit nu funcționează bine pe toate website-urile.

De exemplu, pe Etsy – un site de e-commerce pentru produse artizanale și făcute la mână – scrolling-ul infinit nu a avut rezultatul economic dorit, astfel încât Etsy au revenit la paginarea clasică.[37]Scrolling-ul infinit a condus la mai puține click-uri din partea utilizatorilor, deoarece aceștia se simțeau pierduți într-o mare de produse și le era dificil să sorteze între produse relevante și irelevante.

Totuși, pe alte website-uri, scrolling-ul infinit poate funcționa bine, după cum s-a demonstrat în acest studiu.[38]

Așa cum este valabil pentru majoritatea ideilor pentru un website, un test A/B vă poate spune dacă înlăturarea paginării este sau nu utilă pentru utilizatori.

Dacă aveți în plan să testați scrolling-ul infinit, iată câteva idei:

Afișați indicii vizuale când se încarcă mai mult conținut.

Nu toate conexiunile sunt suficient de rapide pentru a încărca conținutul instant. Dacă serverul vostru nu poate face față scrolling-ului rapid al utilizatorilor, sau când browser-ele sunt lente, informați utilizatorul că mai mult conținut urmează să fie afișat.

Observați mesajul Loading More Results din partea de jos a listei. El informează utilizatorii că se încarcă conținut suplimentar.

 

Luați în calcul o soluție hibridă

O soluție hibridă combină atât scrolling-ul, cât și paginarea. Cu această abordare, veți afișa un buton “arată mai multe rezultate” la finalul unei liste pre-încărcate. Pe mobil, faceți acest buton mai mare, pentru a combate sindromul fat fingers[39]. Când este apăsat butonul, o altă serie de produse se încarcă:

În acest exemplu, se încarcă mai multe perechi de pantofi cu AJAX numai când utilizatorii dau click pe butonul “show more results”.

Adăugați repere pentru scrolling

Amazon folosește o paginare orizontală în acest widget pentru produse, pentru a da o idee utilizatorilor cu privire la numărul de pagini care există în carusel:

Puteți vedea paginarea orizontală pentru acest carusel în partea dreaptă sus a imaginii.

 

Pentru scrolling-ul vertical, adăugarea unor repere, precum numere virtuale de pagină, poate oferi utilizatorilor o idee asupra distanței parcurse și poate ajuta la crearea unor referințe mentale (de ex., “Am văzut un produs care mi-a plăcut undeva pe la pagina 6”).

Această captură de ecran a fost modificată pentru a exemplifica un reper de navigare (linia orizontală și textul “Page 2”).

 

Actualizați URL-ul în timp ce utilizatorii dau scroll în josul paginii

Acesta este un concept interesant care merită investigat. Puteți adăuga automat un parametru de paginare în URL când utilizatorii dau scroll în jos dincolo de un anumit număr de rânduri.

Acest concept este explicat cel mai bine cu ajutorul unui material video, prin urmare am făcut o scurtă captură de ecran pentru a îl ilustra în cazul în care pagina originală[40] devine indisponibilă (puteți descărca acest fișier de aici).

Dacă aveți de obicei 200 sau mai puține produse în listări, este mai bine să încărcați toate produsele o dată. Astfel veți expune totul motoarelor de căutare ca o singură pagină de tip view-all. Aceasta este implementarea preferată de Google pentru a evita paginarea.

Utilizatorii pot vedea 10 sau 20 produse o dată și puteți întârzia încărcarea restului de produse în interfață. Totuși, veți folosi date din codul HTML deja încărcat. Acest lucru are potențialul de a evita multe bătăi de cap cu paginarea. În funcție de autoritatea website-ului vostru, puteți avea chiar și mai mult de 200 produse pe listare.

Dacă lista este imensă, probabil ar trebui să paginați. Dar chiar și atunci, puteți lua în calcul o pagină view-all.

Adăugați navigarea fațetată

Seturile mari de paginare ar trebui însoțite de navigarea fațetată (denumită și navigare filtrată), pentru a permite utilizatorilor să reducă produsele din listă pe baza atributelor produselor. De asemenea, folosiți navigarea cu subcategorii pentru a permite utilizatorilor să ajungă mai adânc în ierarhia website-ului.

Filtrele pot reduce produsele dintr-o listă de la sute, la câteva zeci sau mai puține.

 

Pagina de listare anterioară are 116 produse, dar dacă filtrați după marcă (Brand=Samsung), lista se scurtează la 52 produse. Dacă filtrați după Color sau Finish Family, lista se scurtează la 9 produse.

Dacă scrolling-ul infinit produce rezultate mai bune pentru utilizatori și venituri, este probabil o idee bună să îl implementați. Dar faceți-l să funcționeze pentru utilizatorii fără JavaScript, scoateți paginarea de partea clientului și implementați scrolling-ul infinit pentru utilizatorii cu JavaScript activ.

Navigarea secundară

Pe paginile de listare, navigarea primară este întotdeauna suplimentată cu un fel de navigare auxiliară. Numim acest lucru navigare secundară.

Voi face referire la navigarea secundară ca la acea navigare care asigură accesul la categorii, subcategorii și produsele amplasate mai adânc în taxonomie. Pe website-urile de e-commerce, acest tip de navigare este afișat, de regulă, pe bara laterală stângă.

Navigarea secundară poate apărea foarte aproape de cea primară (fie în partea de sus sau pe bara laterală stângă) și oferă informații detaliate din cadrul unei categorii părinte.

 

În multe cazuri, navigarea secundară listează subcategorii, atribute ale produselor și filtre pentru produse.

Navigarea din partea stângă a paginii include subcategorii si valori de filtrare.

 

Întreaga secțiune din stânga din acest exemplu este considerată navigare secundară; include subcategorii precum filtre, nume de filtre și valori ale filtrelor.

Spre deosebire de navigarea primară, etichetele din navigarea secundară se pot schimba de la o pagină la alta pentru a ajuta utilizatorii să navigheze mai adânc în taxonomia website-ului. Această schimbare de link-uri din meniul de navigare este probabil cea mai importantă distincție dintre navigarea primară și cea secundară.

Din punct de vedere SEO, este important să creați o navigare relaționtă cu, categoriile. Astfel, oferiți utilizatorilor informații mai relevante, asigurați trasee de crawling pentru categorii și dați motoarelor de căutare indicii mai bune privind taxonomia.

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

Să luăm Amazon, de exemplu. Când sunteți în departamentul Books al website-ului, întreaga navigare este legată de cărți.

 

Navigarea fațetată (denumită și navigare filtrată, sau aditivă)

Site-urile de e-commerce sunt adesea aglomerate, afișând prea multe informații de procesat și prea multe produse din care utilizatorii trebuie să aleagă. Acest lucru conduce la un exces de informații și induce paralizia alegerii (choice paralysis).[41] Este esențial, prin urmare, să oferiți utilizatorilor un mod mai ușor de a naviga prin cataloagele mari de produse. Aici intervine navigarea fațetată (sau ceea ce Google numește filtrare suplimentară sau additive filtering).

Indiferent dacă vizitatorii caută ceva foarte specific sau doar parcurg website-ul, filtrele pot fi extrem de utile. Ele vor ajuta utilizatorii să localizeze produsele fără a folosi căutarea internă de pe site, sau navigarea primară, care în majoritatea cazurilor arată un număr limitat de opțiuni pentru utilizatori.

Navigarea fațetată permite utilizatorilor să găsească mai ușor ceea ce caută, reducând listările de produse pe baza unor filtre predefinite, sub forma unor link-uri pe care se poate da click. Experții în operabilitate descriu navigarea fațetată drept:

“probabil cea mai semnificativă inovație în domeniul căutării din ultimul deceniu”.[42]

Navigarea fațetată are aproape întotdeauna un impact pozitiv asupra experienței utilizatorilor și a parametrilor afacerii. Un comerciant a observat:

“o creștere cu 76,1% a veniturilor, o creștere cu 26% a conversiilor și o creștere cu 19,76% a accesărilor paginii cu coșul de cumpărături în urma unui test A/B după implementarea filtrării pe paginile sale de listare”.[43]

Această captură de ecran de mai jos ilustrează un design obișnuit pentru navigarea fațetată:

C:\Users\traiann\AppData\Local\Temp\SNAGHTML29552d11.PNG

Un exemplu de interfață pentru navigarea fațetată.

 

Este ceva obișnuit ca navigarea fațetată să fie prezentată în bara laterală stângă, dar poate fi afișată, de asemenea, în partea de sus a listărilor de produse, în funcție de câte filtre are fiecare categorie. În multe cazuri, subcategoriile sunt incluse și ele în navigarea fațetată.

Filtrele, valorile filtrelor și fațetele au un înțeles diferit.

  • Filtrele reprezintă un grup de atribute ale produselor. În această imagine, Styles, Women’s Size, Women’s Width sunt filtrele.
  • Valorile filtrelor sunt opțiunile de sub fiecare filtru. Pentru filtrul Styles, valorile filtrelor sunt Comfort, Pumps, Athletic, și așa mai departe.
  • Fațetele sunt vizualizări generate prin selecția unui filtru sau a unei combinații de valori ale filtrelor. Alegerea unei valori din filtrul Women’s size și a unei valori din filtrul Women’s width creează o așa-numită „fațetă”.

2017-07-21 2-29-07 PM

Alegerea unei valori sau a mai multor valori generează așa-numita fațetă.

 

Navigarea fațetată este o binecuvântare pentru utilizatori și ratele de conversie, dar poate genera un labirint uriaș pentru roboții de căutare. Principalele probleme pe care le generează navigarea fațetată sunt:

  • Conținut duplicat sau aproape duplicat.
  • Capcane de crawling.
  • Conținut non-esențial, subțire.

Dacă ați primit un mesaj pe Google Search Console ca cel de mai sus, navigarea fațetată este una din cauzele posibile.

 

Nu există un exemplu mai bun pentru modul în care filtrarea poate crea probleme decât cel oferit chiar de Google. Navigarea fațetată pe googlestore.com – alături de alte tipuri de navigare, precum opțiunile de sortare și vizualizare – au generat 380.000 URL-uri.[44] Și rețineți că era un site care nu vindea decât 158 produse.

Dacă sunteți curioși să aflați câte URL-uri ar putea genera navigarea fațetată pentru o pagină de listare produse, puteți folosi următoarea formulă pentru a calcula permutările posibile (repetiția nu este permisă):

P = n!/r!(n-r)!

În această formulă, n este numărul total de valori ale filtrelor care pot fi aplicate, iar r este numărul total de filtre. De exemplu, să spunem că aveți două filtre:

  • Filtrul Styles, cu cinci opțiuni de filtrare
  • Filtrul Materials, cu nouă opțiuni de filtrare

În acest caz, n va fi 14, ceea ce înseamnă numărul total de opțiuni de filtrare și r va fi 2 deoarece avem două filtre. Această setare ar putea genera teoretic 91 URL-uri.[45]

Dacă adăugați un al filtru (de ex., filtrul Color), și acest filtru are 15 opțiuni de filtrare, n devine 29 și r este egal cu 3. Această setare va genera 3.654 URL-uri unice.

După cum am menționat, formula de mai sus nu permite URL-uri repetitive. Acest lucru înseamnă că dacă utilizatorii aleg (style = comfort ȘI material = suede) primesc aceleași rezultate ca atunci când aleg (material = suede ȘI style = comfort), la același URL. Dacă nu implementați o ordine pentru parametrii URL, atunci navigarea fațetată va genera 182 link-uri pentru exemplul cu două filtre și 21.924 URL-uri pentru exemplele cu trei filtre aplicate.

Diferența uriașă dintre numărul total de pagini indexate și numărul de pagini pe care s-a făcut vreodată crawling indică o posibilă problemă de crawling sau o problemă gravă de calitate a conținutului.

 

Vedeți câte URL-uri generează parametrul price?!

 

În imaginea anterioară, problema a fost identificată și confirmată prin verificarea raportului de parametri URL din Google Search Console. Numărul mare de URL-uri s-a datorat filtrului Price, care a generat 5,2 milioane URL-uri.

Puteți rezolva parțial problemele legate de conținutul duplicat generat de navigarea fațetată forțând o ordine strictă pentru parametrii URL, indiferent de ordinea în care au fost selectate filtrele. De exemplu, Category ar putea fi filtrul ales primul și Price al doilea. Dacă un utilizator (sau robot) alege filtrul Price prima dată și apoi filtrul Category, faceți în așa fel încât Category apare primul în URL, urmat de Price.

În URL-ul de mai sus, deși valoarea filtrului cherry a fost aleasă după double door, poziția sa din URL este bazată pe o ordine predefinită.

 

Aceeași ordine este reflectată și în breadcrumbs:

Dacă aveți nevoie de un breadcrumb care reflectă ordinea selecției utilizatorului, puteți stoca ordinea într-un cookie de sesiune și nu într-un URL.

 

O altă problemă de conținut aproape duplicat generat de fațete apare atunci când una din opțiunile de filtrare prezintă aproape aceleași produse ca vizualizarea fără filtrare. De exemplu, vizualizarea pentru Ski & Snowboard Racks are un număr total de 15 produse și puteți reduce rezultatele folosind două subcategorii: Hitch Mount and Rooftops.

similar results.jpg

Imaginea de mai sus este pagina de listare produse pentru Ski & Snowboard Racks.

 

Totuși, subcategoria Rooftop Ski Racks & Snowboard Racks include 13 rezultate de pe pagina nefiltrată. Aceasta înseamnă că, cu excepția a două produse, pagina filtrată și cea nefiltrată sunt aproape duplicate.

similar results 2.jpg

Rooftop Ski Racks & Snowboard Racks.

 

Navigarea fațetată prezintă un avantaj semnificativ față de navigarea ierarhică: combinațiile de filtre vor genera pagini care nu ar putea exista într-o ierarhie de tip arbore, deoarece acestea sunt rigide și nu pot acoperi toate combinațiile posibile generate de navigarea fațetată. Structura ierarhică este bună, totuși, pentru deciziile de la un nivel mai înalt.

Să spunem că vindeți bijuterii și ați dori să obțineți o clasare bună pentru căutarea ”pandantive pătrate din platină (“square platinum pendants”). Ierarhia website-ului vostru separă bijuteriile doar după tipul lor, precum pandantive, brățări etc., și apoi permite filtrarea bazată pe filtrul Material, cu valori precum platină, aur etc. Dacă nu există filtrul de formă (Shape) pentru a lista opțiunea pătrat, website nu va avea navigare fațetată pentru “square platinum pendants”.

Totuși, dacă ați introduce filtrul Shape pe pagina de listare a Platinum Pendants, v-ar permite să generați fațeta Square Platinum Pendants, care filtrează inventarul pe baza valorii „pătrat” a filtrului. Această pagină este relevantă pentru utilizatori și pentru motoarele de căutare. Puteți optimiza și mai mult această pagină cu conținut personalizat și aspecte vizuale, pentru a o face și mai atractivă pentru roboții de căutare și utilizatori.

Un filtru suplimentar – Shape – ar permite vizarea mai multor cuvinte cheie de tip torso și long-tail.

 

Dacă nu există un filtru Shape pentru a genera fațeta Square Platinum Pendants și dacă nu există nici o navigare ierarhică pentru a conduce la o astfel de pagină, va trebui să creați manual o pagină care țintește căutarea “square platinum pendants”. Apoi va trebui să faceți link către ea intern și extern, pentru ca motoarele de căutare să o poată descoperi. În funcție de dimensiunea catalogului vostru de produse, ar fi practic imposibil să creați manual mii sau chiar milioane de astfel de pagini.

Filtre esențiale, importante și overhead

Înainte de a discuta modul de abordare a navigării fațetate din perspectivă SEO, este important să clasificăm filtrele și fațetele în trei tipuri: esențiale, importante și overhead (în exces).

Filtre/fațete esențiale

Filtrele esențiale vor genera pagini de destinație care țintesc cuvinte cheie competitive, cu volume mari de căutare, care sunt de obicei termeni de tip „head” sau „torso”. Dacă navigarea voastră fațetată listează subcategorii, aceste fațete sunt esențiale și ele sunt numite subcategorii fațetate.

În acest exemplu, Bags, Wallets, și celelalte subcategorii sunt filtre esențiale. Trebuie să permiteți întotdeauna motoarelor de căutare să facă crawling și să indexeze aceste filtre.

 

Fațetele esențiale pot fi generate, de asemenea, de o combinație de valori ale filtrelor sub Brand + Category—de exemplu, folosind valoarea de filtru “Nokia” pentru Brand și valoarea de filtru “Cameras” pentru Category.

Atât Category cât și Brand pot fi considerate fațete, deoarece funcționează drept filtre pentru seturi mai mari de date.

Puteți alege manual combinațiile de top ale filtrelor esențiale care sunt valoroase pentru utilizatorii și afacerea voastră. Transformați-le în pagini de sine stătătoare, adăugând conținut și optimizându-le așa cum ați proceda cu orice pagină importantă. Acesta este un proces în mare parte manual, deoarece impune crearea de conținut, prin urmare este realizabil doar pentru un număr limitat de pagini.

Totuși, dacă faceți acest lucru în mod regulat și dacă alocați resurse pentru crearea de conținut, veți avea un avantaj față de concurență. Începeți cu cele mai importante 1% din fațete și avansați treptat. Dacă faceți câteva pe zi (aveți nevoie doar de 100 – 150 cuvinte bine alese), într-un an veți fi optimizat sute de pagini de filtrare de produse.

Toate paginile fațetă esențiale ar trebui să aibă titluri și descrieri unice. Ideal, titlurile ar trebui să fie personalizate, în timp ce descrierile pot fi șablon.

Asigurați-vă că motoarele de căutare pot descoperi link-urile către filtrele și fațetele esențiale. De fapt, filtrele esențiale trebuie să aibă link-uri de pe paginile bogate în conținut, precum articolele de blog sau ghidurile de utilizare. Pentru un transfer maxim de autoritate, faceți link din zona conținutului principal a unor astfel de pagini.

Structura URL pentru fațetele esențiale ar trebui să fie curată. Ideal, ar trebui să reflecte, fie parțial fie exact, ierarhia website-ului într-o structură director sau o convenție de denumire a fișierelor:

URL-ul pentru fațeta subcategoriei Bathroom Accessories este fără parametri și reflectă ierarhia website-ului.

 

Filtre/fațete importante

Aceste filtre sau fațete vor conduce utilizatorii și motoarele de căutare către paginile de destinație care pot angrena trafic pentru cuvintele cheie de tip „torso” și „long-tail”.

De exemplu, dacă datele analitice dovedesc faptul că piața țintă caută „pantofi confort roșii”, acest lucru înseamnă că URL-urile generate prin selecția Color + Style sunt fațete importante pentru afacerea voastră. Motoarele de căutare ar trebui să aibă acces la URL-urile fațetelor importante.

Va trebui să vă decideți care fațetă este importantă și care nu, de preferat plecând de la o categorie sau subcategorie. De exemplu, filtrul Color poate fi relevant pentru subcategoria Shoes, dar va fi un filtru overhead pentru subcategoria Fragrances.

Un caz particular în care trebuie să aveți grijă este filtrul Sales sau Clearance. În exemplul de mai jos, comerciantul listează toate fațetele pentru toate produsele în lichidare de stoc.

Filtrele de navigare din stânga de mai sus nu ajută prea mult utilizatorii deoarece Covoarele (Rugs) nu au mâneci (sleeves), Încălțămintea pentru zăpadă (snowshoes) nu au stil cămașă (shirt style), iar Puloverele (Pullovers) nu au stil bețe ski (ski pole style).

 

În loc să listeze produse, acest comerciant ar trebui să listeze doar subcategoriile în navigarea din stânga și zona conținutului principal. Astfel, utilizatorii vor gestiona mai bine natura ambiguă a paginii Lichidări stoc (Clearance) alegând mai întâi o categorie care îi interesează. Odată selectată categoria dorită, comerciantul poate să afișeze filtrele care se aplică acelei categorii.

În funcție de modul în care piața voastră țintă face căutările online, este recomandat să împiedicați motoarele de căutare să acceseze URL-urile generate atunci când s-au aplicat mai mult de două valori de filtrare. Dacă unul din filtrele aplicate este un filtru esențial, veți bloca atunci când au fost aplicate trei filtre.

Acest lucru funcționează cel mai bine cu selecții multiple pe același filtru (de ex., Brand = Acorn AND Brand = Aerosoles) deoarece este mai puțin probabil ca utilizatorii să caute tipare precum “{brand1} {brand2} {category}” (de ex., “Acorn Aerosoles shoes”).

Capacitatea de a selecta valori multiple ale filtrului este utilă pentru utilizatorii care ar putea alege Red ȘI Blue Shirts, dar nu sunt utile pentru motoarele de căutare. Prin urmare, astfel de selecții pot fi blocate pentru roboți.

Un exemplu de selecții multiple pe filtrul Brand.

 

Notați că blocarea accesului la URL-urile navigării fațetate ca setare implicită, ori de câte ori se aplică filtre multiple, va împiedica roboții să descopere paginile create prin selecțiile unei singure valori la filtre diferite (de ex., Color = red ȘI Style = comfort). Veți rata trafic pentru un număr mare de combinații de filtre (dacă nu creați și optimizați manual paginile de destinație pentru toate filtrele și fațetele importante și dacă nu permiteți roboților să facă crawling și să indexeze aceste pagini).

Lăsați datele să fie hotărâtoare atunci când decideți ce fațete trebuie să lăsați deschise pentru motoarele de căutare. Adunați date din surse diferite, apoi înlocuiți programatic cuvintele cheie cu valorile filtrelor lor, când este cazul. Este un proces foarte similar tehnicii de Etichetare și Clasificare descrisă în secțiunea Arhitectura Website-ului. Trebuie să identificați tipare și să vedeți ce fațete sau filtre sunt cel mai des folosite de utilizatorii site-ului. Pe platforma voastră de e-commerce, marcați filtrele importante și permiteți-le indexarea.

Structura URL pentru fațetele importante trebuie să fie cât mai curată posibil. Este OK să păstrați valorile filtrului într-un director sau în structura file path. Este OK, de asemenea, să le păstrați în parametri URL, atât timp cât nu folosiți mai mult de doi sau trei parametri.

Când se aplică un filtru important, valoarea sa este atașată URL-ului, sub forma unui director. În acest URL, valoarea filtrului este kohler, sub filtrul Brand.

 

Ori de câte ori este posibil, evitați folosirea de caractere non-standard în URL (precum virgulele sau parantezele) pentru parametrii URL.[46]

Adesea, motoarele de căutare tratează paginile create de filtre ca pe subseturi ale paginii nefiltrate. Pentru a evita indexarea în indicele suplimentar, trebuie să creați titluri, descrieri, breadcrumbs, antete H1 unice și conținut personalizat pe aceste pagini filtrate. Titlurile și descrierile șablon pot fi în regulă, dar nu repetați titlul vizualizării nefiltrate pe paginile fațetă. Vizualizarea nefiltrată poate fi pe pagina view-all sau pagina index, în cazul în care ați implementat paginarea cu rel=“prev”/next.

Suplimentar, breadcrumb-urile trebuie să se actualizeze pentru a reflecta selecția utilizatorului; la fel și antetele H1. Poate părea evident, dar este incredibil cât de multe website-uri de e-commerce nu fac acest lucru.

O tehnică ce poate fi utilă pentru a crește relevanța fiecărei pagini filtrate, și pentru a scădea problemele legate de conținutul aproape duplicat, este să scrieți descrieri ale produsului care includ valorile filtrului folosite pentru a genera pagina. De exemplu, să spunem că vindeți diamante. Când un utilizator alege o valoare sub filtrul Material, snippet-ul cu descrierea produsului ar include valoarea filtrului.

Pagina PLP de mai sus filtrează produsele după material = white gold. Descrierea celui de-al doilea produs folosește funcționalitatea quick view și include, într-o manieră inteligentă, cuvintele “white” și “gold”.

 

Acest snippet quick view diferă de descrierea produsului de pe pagina cu detalii despre produs:

Secțiunea (1) este snippet-ul quick view, secțiunea(2) descrierea completă a produsului.

 

Secțiunea (1) din imaginea de mai sus ne arată snippet-ul cu descrierea produsului folosind quick view pe pagina de listare produse. După cum puteți vedea, snippet-ul a fost creat atent pentru a include toate valorile importante ale filtrului. Secțiunea (2) prezintă descrierea produsului de pe pagina cu detalii despre produs. Aceste două descrieri de produse sunt diferite.

Scrierea de snippet-uri pentru produse personalizate pentru paginile de listare este o tactică SEO foarte eficientă atunci când prezentați doar 20 – 25 cuvinte pentru fiecare produs. Totuși, este dificil să scrieți astfel de snippet-uri când aveți mii de produse. O variantă ar fi să scrieți descrierile detaliate ale produselor în așa fel să includeți valorile filtrelor celor mai importante la începutul sau sfârșitul descrierii detaliate a produsului, și apoi să extrageți automat și să afișați prima/ultima propoziție pe pagina de listare produse, în quick view.

O altă metodă de a crește relevanța paginilor de listare generate de fațetele importante este să adăugați valorile filtrului selectat pe listarea produsului, din mers. Totuși, se poate ajunge ușor la spam dacă nu sunteți atenți. Dacă alegeți această abordare, asigurați-vă că implementați reguli pentru a evita folosirea în exces a cuvintelor cheie (keyword stuffing).

Filtrele overhead

Aceste filtre generează pagini care au un volum de căutare minim sau zero. Tot ceea ce fac este să risipească bugetul de crawling pe URL-uri irelevante. Un exemplu clasic de filtru overhead este Price; în multe cazuri la fel și filtrul Size. Totuși, rețineți că un filtru poate fi overhead pentru o afacere dar important sau chiar esențial pentru altă afacere.

Împiedicați motoarele de căutare să facă crawling pe URL-urile generate pe baza filtrelor overhead și marcați filtrele ca overhead la nivel de categorie. Ori de câte ori o combinație de filtre include o valoare overhead, adăugați meta tag-ul “noindex, follow” paginii generate și atașați parametrul crawler=no în URL-ul său. Apoi blocați parametrul crawler cu robots.txt.

Directiva din robots.txt va împiedica risipirea bugetului de crawling, în timp ce meta tag-ul noindex va împiedica apariția snippet-urilor goale în SERP. Dacă aveți pagini în index pe care trebuie să le scoateți, implementați mai întâi “noindex, follow” și așteptați ca paginile să fie scoase din index. Odată ce sunt îndepărtate, atașați parametrul de control crawling URL-urilor.

Aveți grijă la combinația de robots.txt și meta tag-ul noindex , deoarece robots.txt nu va permite roboților accesul la directivele la nivel de pagină, iar noindex este o directivă la nivel de pagină. Dacă website-ul nu are o problemă de indexare sau de crawling, puteți lua în calcul implementarea rel=“canonical” în loc de robots.txt.

De asemenea, puteți folosi AJAX pentru a genera conținut pentru fațetele overhead într-un mod în care URL-urile să nu se schimbe, astfel încât motoarele de căutare nu vor solicita conținut inutil. În acest caz, trebuie să blocați scripturile (și toate celelalte resurse necesare pentru apelurile AJAX) cu robots.txt. Acest lucru va împiedica motoarele de căutare să randeze link-urile AJAX.

Dacă vreți să degradați codul pentru utilizatori cu JavaScript oprit, puteți folosi parametri URL, care pot fi plasați fie după semnul (#) fie într-un șir URL blocat cu robots.txt. Totuși, cele mai stringente restricții de crawling se obțin prin blocarea URL-urilor overhead pentru roboți.

Observați cum URL-ul de mai sus conține șirul NCNI-5 la final.

 

Șirul NCNI-5 este folosit pentru controlul roboților, deoarece toate URL-urile care conțin șirul NCNI-5 sunt blocate cu robots.txt:

Disallow: /*NCNI-5*

Pentru a sintetiza, iată cum definește Home Depot URL-urile pentru toate cele trei tipuri de fațete:

Fiecare filtru/fațetă este tratat(ă) diferit, în funcție de importanță.

 

URL-ul pentru fațeta esențială este alcătuit dintr-un nume curat de categorie. URL-ul pentru fațeta importantă include numele categoriei și valoarea filtrului, kohler. URL-ul pentru fațeta overhead – deși include numele categoriei și valoarea filtrului – include, de asemenea, și șirul de control crawling, NCNI-5.

Nu este o idee bună să rescrieți URL-urile pentru a face filtrele overhead să arate ca URL-uri statice. Următorul exemplu de URL include filtrul overhead Price, cu valorile 50 – 100.

http://www.homedepot.com/b/Bath-Bathroom-Accessories-Hardware-Bathroom-Accessories/KOHLER/N-5yc1vZbz99Z1qh/Price/50-100

URL-ul nu există pe website-ul Home Depot; am adăugat partea cu /Price/50-100 doar pentru a exemplifica. Generarea de URL-uri prietenoase cu motoarele de căutare nu schimbă faptul că vor exista milioane de pagini irelevante pe website.

În ceea ce privește capacitate URL-ului de fi descoperit, motoarele de căutare nu trebuie să găsească link-urile care fac trimitere spre filtrele sau fațetele overhead. De fapt, trebuie să împiedicați motoarele de căutare să descopere acest tip de fațete.

Dacă trebuie să permiteți motoarelor de căutare să facă crawling pe fațetele overhead, păstrați filtrele în parametri folosind codarea standard HTML și perechi key=value în loc de directoare. Acest lucru ajută motoarele de căutare să facă diferența între valori utile și valori inutile.

Navigarea fațetată: studiu de caz

Am căutat pe Google “Canon digital cameras” și Overstock a apărut pe prima pagină, OfficeMax pe a cincea, și Target pe a șaptea.

Abordarea Overstock privind navigarea filtrată

Imaginea de mai sus este pagina de sub-subcategorie Digital Cameras filtrată după Brand = Canon. Are un titlu unic, breadcrumbs personalizate și un antet H1 relevant. De asemenea, această pagină folosește o meta descriere bună. Aceste elemente transmit semnale de calitate motoarelor de căutare.

 

Când utilizatorii filtrează SKU-urile după o altă marcă (de ex., Sony), elementele paginii se actualizează. Dacă nu s-ar fi actualizat, pagina Canon Digital Cameras ar avea același H1, titlu, descriere și breadcrumbs, ceea ce nu este de dorit.

În plus, Overstock permite operațiunea de crawling pentru filtrele esențiale și importante și nu creează URL-uri pentru filtrele gray-end (filtre care generează rezultate zero).

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

Valoarea filtrului “10 Megapixels” generează zero rezultate. Prin urmare, nu are hyperlink.

 

Implementarea navigării fațetate de către Overstock este prietenoasă SEO deoarece permite roboților să acceseze diferite pagini filtrate și actualizează elementele de pe pagină pe baza selecției utilizatorului sau a robotului de căutare.

O observație despre valorile filtrelor gray-end. Orice alegeți să faceți cu aceste valori ale filtrelor în interfață (de ex. să nu le arătați deloc, să le arătați la capătul listei de filtrare sau să le ascundeți în spatele link-ului „arată mai mult”), filtrele gray ends nu ar trebui să fie hyperlink. Dacă trebuie să faceți hyperlink, din orice motiv, codul de răspuns pentru paginile cu zero rezultate trebuie să fie 404. Dacă un răspuns 404 nu este posibil, marcați paginile cu “noindex, follow”. Alternativ, puteți folosi robots.txt pentru a bloca URL-urile care generează rezultate zero.

Abordarea OfficeMax față de navigarea fațetată

Imaginea de mai sus descrie pagina PLP Digital Cameras de pe site-ul OfficeMax.

 

Titlul, descrierea și breadcrumb-urile nu se actualizează când utilizatorul alege o valoare de filtru sub filtrul Brand. Aceasta înseamnă că mii de pagini filtrate vor avea elemente SEO pe pagină foarte similare cu pagina nefiltrată. Deși produsele de pe fiecare pagină filtrată se vor schimba, motoarele de căutare vor obține multe semnale meta tag aproape duplicat.

Acest “impas” ar putea face Google să nu indexeze pagina fațetată care rezultă în urma filtrării Canon. Pagina care se clasifică pentru “Canon digital cameras” pe OfficeMax este pagina de categorii Digital Cameras. Aceasta nu este pagina ideală cu care să te clasifici deoarece nu se potrivește cu intenția utilizatorului și a căutării. Filtrarea după Brand=Canon înseamnă că utilizatorii trebuie să facă un pas suplimentar, inutil.

Pe versiunea cache a paginii Digital Cameras observăm că navigarea fațetată nu există. Acest lucru se întâmplă deoarece navigarea fațetată nu este accesibilă motoarelor de căutare.

Navigarea fațetată nu este accesibilă motoarelor de căutare.

 

O scurtă observație aici: dacă link-urile lipsesc din versiunea cache, Google ar putea încă să le găsească când randează pagina așa cum ar face-o un browser.

Poate OfficeMax a încercat să repare unele probleme de supra-indexare sau un posibil filtru Panda pentru paginile cu conținut subțire. Totuși, această implementare a navigării fațetate nu este optimă, deoarece blochează complet accesul la toate paginile filtrate. Dacă OfficeMax nu creează manual pagini de destinație pentru toate paginile filtrate importante, au închis ușa motoarelor de căutare și traficului pe care l-ar putea aduce aceste pagini.

Abordarea Target față de navigarea fațetată

Ca și OfficeMax, Target nu creează semnale de relevanță pentru paginile filtrate.

 

Pe website-ul Target, titlul paginii, breadcrumb, antetul H1, și descrierea pentru pagina Canon Digital Cameras sunt aceleași ca pe pagina nefiltrată, Digital Cameras. De fapt, elementele mai sus menționate vor fi aceleași pe sute sau mii de alte posibile pagini filtrate.

Mai mult, deoarece pagina are o referință canonică spre pagina nefiltrată, capacitatea sa de a se clasifica este (teoretic), zero. Din cauza acestei abordări, am crezut că ar avea o pagină Canon Digital Cameras care poate fi accesată din navigare sau de pe altă pagină. Dacă aveau una, Google nu a reușit să o identifice.

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

Google nu a putut găsi o pagină de categorie (sau măcar un URL de navigare fațetă) relevantă pentru Canon Digital Cameras. Toate rezultatele cele mai relevante erau PDPs.

 

Versiunea Google cache a paginii ne arată că navigarea fațetată nu creează link-uri:

Deoarece Brand este un filtru important și deoarece în exemplul nostru am folosit o singură valoare de filtru, toate valorile filtrului Brand ar trebui să fie link-uri HTML simple.

 

Categoriile în navigarea fațetată

Navigarea ierarhică, bazată pe categorii, este utilă atât timp cât este ușor pentru utilizatori să aleagă între categorii. De exemplu, ar fi mai util pentru utilizatori dacă anumite subcategorii pentru care se poate lua ușor o decizie ar fi listate în zona principală de conținut, față de afișarea ca subcategorii fațetă în bara laterală. Ar trebui folosite pagini de listare a subcategoriilor:

“ori de câte ori este necesară navigarea ulterioară sau definirea sferei dinainte este o idee bună să afișați o listă cu produsele pentru utilizatori, În general, paginile de subcategorie au logica cea mai mare în primul sau primele două straturi ale ierarhiei unde sfera este prea mare pentru a produce o listă utilă de produse”.[47]

Această categorie afișează următorul nivel de categorii din ierarhie în zona principală de conținut.

 

În imaginea anterioară, navigarea fațetată (prezentă de obicei în navigarea din stânga ca opțiuni de filtrare) nu este încă introdusă la acest nivel al ierarhiei (L1) și nici măcar la nivelul L2.

În exemplul următor puteți vedea modul în care navigarea pe bază de categorii se încheie la al treilea nivel al ierarhiei; primul nivel este categoria Décor, al doilea nivel este Blinds & Window Treatments, iar al treilea nivel este Blinds & Shades.

Navigarea fațetată este afișată doar la al treilea nivel al ierarhiei.

Puteți vedea navigarea fațetată afișată în bara laterală din stânga, pentru a ajuta la filtrarea produselor. Puteți observa, de asemenea, că listarea subcategoriilor a fost înlocuită cu listarea produselor.

 

Este important să păstrați ierarhiile relativ de mică adâncime, pentru ca utilizatorii să nu fie nevoiți să dea click mai mult de patru niveluri pentru a ajunge la lista de produse. Motoarele de căutare vor avea aceleași provocări și pot considera că produsele îngropate adânc în ierarhie nu sunt importante.

Deoarece navigarea fațetată este o funcție de segmentare granulară a stocului de produse, generează conținut în exces, în majoritatea implementărilor. Va genera, de asemenea, conținut duplicat – de exemplu dacă nu implementați o ordine strictă pentru filtrele parametrilor din URL-uri.

Prin urmare, ce opțiuni avem pentru a controla navigarea fațetată?

Opțiunea rel=”canonical”

Deși rel=“canonical” trebuie folosit teoretic pentru conținut identic sau aproape identic, poate fi o idee bună să experimentați cu atributul canonical pentru a optimiza conținutul de-a lungul URL-urilor de navigare fațetată.

Vanessa Fox, care a lucrat pentru Google Webmaster Central, a sugerat următoarea abordare în unele cazuri:

“Dacă vizualizarea filtrată este un subset al unei singure pagini non-filtrate (poate vizualizarea=100 opțiune), puteți folosi atributul canonical pentru a referi pagina filtrată spre cea non-filtrată. Totuși, dacă vizualizarea filtrată are ca rezultat conținut paginat, acest lucru poate să nu fie viabil (deoarece fiecare pagină poate să nu fie un subset a ceea ce ați dori să exprimați drept canonic)”.[48]

Rel=“canonical” va consolida semnalele de indexare către pagina canonică și va rezolva unele probleme de conținut duplicat, dar motoarele de căutare pot fi prinse în continuare în capcana de a face crawling pe URL-uri irelevante.

Rel=“canonical” este o opțiune bună pentru website-urile noi, sau pentru a adăuga opțiuni de filtrare website-urilor existente. Totuși, nu ajută dacă încercați să îndepărtați URL-urile existente filtrate din indicii motoarelor de căutare. Dacă nu aveți probleme de indexare și crawling, puteți folosi rel=“canonical”, după cum sugerează Vanessa.

Opțiunea robots.txt

Robots.txt este măsura de control supremă pentru crawling. Rețineți că dacă folosiți robots.txt pentru a bloca URL-uri, veți afecta transferul de PageRank către și de la mii de pagini. Și aceasta deoarece URL-urile listate în robots.txt pot primi PageRank, dar nu pot transfera PageRank.[49] De asemenea, rețineți că robots.txt nu împiedică indexarea paginilor.

Totuși, în unele cazuri, această abordare este necesară – de ex., când aveți un website nou, fără autoritate și cu un număr mare de produse care trebuie descoperite sau când aveți probleme de indexare sau de conținut subțire.

Dacă folosiți parametri în URL-uri și vreți să blocați crawling-ul tuturor URL-urilor generate prin selectarea valorilor de sub filtrul Price, ați adăuga ceva similar în fișierul robots.txt:

User-agent: *

Disallow: *price=

Această directivă înseamnă că orice URL care conține șirul price= nu va fi supus acțiunii de crawling.

Parametru/director URL blocat robots.txt

Această metodă cere să adăugați, selectiv, un parametru URL pentru a controla care pagini filtrate por fi supuse acțiunii de crawling și care nu. Am descris acest lucru în secțiunea Optimizare crawling, dar voi repeta și aici.

Mai întâi, hotărâți ce URL-uri doriți să blocați.

Să spunem că vreți să controlați crawling-ul navigării fațetate nepermițând motoarelor de căutare să facă crawling pe URL-urile generate când se aplică mai mult de o valoare de filtrare în același filtru (cunoscut și ca multi-selecție). În acest caz, veți adăuga parametrul crawler=no pentru toate URL-urile generată la selectarea unei a doua valori de filtrare 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 la selectarea unei a treia valori, indiferent de opțiunile alese sau de ordinea alegerii. Iată un scenariu, drept exemplu:

Robotul de crawling este pe pagina de subcategorii Battery Chargers.

Ierarhia este: Home > Accessories > Battery Chargers

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

Apoi robotul „bifează” una din valorile de filtrare Brands, respectiv Noco. Aceasta este prima valoare de filtrare și, prin urmare, veți permite robotului să analizeze acea pagină.

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

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

Robotul ”bifează” apoi una din valorile de filtrare Style, cables. Deoarece este a doua valoare de filtrare aplicată, veți permite în continuare robotului să acceseze URL-ul.

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

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

Acum, robotul “bifează” una din valorile de filtrare Pricing, numărul 1. Deoarece este cea de-a treia valoare de filtrare, veți atașa crawler=no la URL.

URL-ul devine:

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

Dacă vreț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ă crawling-ul pe URL-urile fațetă atunci când au fost aplicate mai mult de două valori de filtrare, dar nu permite un control specific asupra căror filtre vor fi supuse acțiunii de crawling și care nu. De exemplu, dacă robotul „bifează” mai întâi opțiunile din Pricing, URL-ul care conține parametrul de preț va fi supus acțiunii de crawling.

Notați că blocarea paginilor filtrate doar pe baza numărului de valori de filtrare aplicate ridică unele riscuri. De exemplu, dacă o valoare de filtrare Price este aplicată mai întâi, paginile generate vor fi în continuare indexate, deoarece a fost selectată o singură valoare de filtrare. Ar trebui să aveți reguli mai solide de control al crawling-ului – de ex., dacă a fost aplicată o valoare de filtrare overhead, blocați întotdeauna paginile generate.

Este, de asemenea, o idee bună să limitați numărul de selecții pe care robotul unui motor de căutare le poate descoperi. Vom discuta despre acest lucru puțin mai târziu în cadrul acestei secțiuni, ca opțiunea de control crawling JavaScript/AJAX.

Filtrele sau fațetele importante trebuie să fie link-uri HTML simple. Puteți prezenta filtrele overhead ca text simplu motoarelor de căutare (nu hyperlink-uri), dar ca HTML funcțional pentru utilizatori (hyperlink-uri).

Abordarea directorului blocat cere plasarea URL-urilor nedorite într-un director, apoi blocarea acelui director în robots.txt.

În exemplul nostru de mai sus, când robotul verifică una din opțiunile Pricing plasați URL-ul în directorul /filtered/. Dacă URL normal arată astfel:

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

când controlați roboții, URL-ul va include directorul /filtered/:

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

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

User-agent: *

Disallow: /filtered/

Opțiunea nofollow

Unele website-uri preferă să aplice atributul nofollow pentru filtrele sau fațetele inutile. În mod surprinzător și în contradicție cu recomandarea oficială care ne spune să nu facem nofollow pentru orice link intern, nofollow este una din recomandările Google de gestionare a navigării fațetate[50]. Totuși, nofollow nu garantează că motoarele de căutare nu vor face crawling pe URL-urile inutile sau că acele pagini nu vor fi indexate. În plus, adăugarea atributului nofollow link-urilor interne ar putea trimite motoarelor de căutare semnale greșite, deoarece nofollow se traduce prin „nu avem încredere în aceste link-uri”.

Astfel, nofollow nu rezolvă problemele curente de indexare. Opțiunea dă cele mai bune rezultate în cazul website-urilor noi.

Poate fi o idee bună fie să “suplimentați” opțiunea nofollow cu o altă metodă care împiedică indexarea URL-urilor (de ex., blocarea URL-urilor cu robots.txt) sau să canonicalizați link-ul într-un super-set.

Opțiunea JavaScript/AJAX

Am stabilit că filtrele și fațetele esențiale și importante trebuie să fie întotdeauna accesibile motoarelor de căutare sub formă de link-uri. De preferat link-uri HTML simple. ULR-urile pentru filtrele și fațetele overhead, pe de cealaltă parte, pot fi blocate fără probleme pentru roboții motoarelor de căutare.

Teoretic, puteți ascunde întreaga navigare fațetată de motoarele de căutare, încărcând-o cu JavaScript sau AJAX, care „nu sunt prietenoase” cu motoarele de căutare. Am văzut că OfficeMax a făcut acest lucru. Totuși, nu este o idee bună să excludeți întreaga navigare fațetată și nu ar trebui să faceți acest lucru decât dacă există moduri alternative pentru ca motoarele de căutare să ajungă la paginile create pentru toate fațetele esențiale și importante. În practică, acest lucru nu este nici fezabil, nici recomandat.

O opțiune este să permiteți motoarelor de căutare accesul doar la link-urile fațetelor esențiale și importante, fără a genera link-uri overhead. De exemplu, încărcați doar fațetele și filtrele importante ca HTML simplu, în timp ce filtrele sau fațetele overhead sunt încărcate cu JavaScript sau AJAX. Utilizatorii vor putea da click pe oricare din link-uri, deoarece ele vor fi generate în browser (de ex., folosind link-urile „vezi mai multe opțiuni”).

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

Unele din valorile de filtrare din navigarea fațetată nu au hyperlink-uri.

 

În acest exemplu, utilizatorilor li se arată doar două valori de filtrare pentru Review Rating, cu un link către Show All Review Rating (coloana 1). Când dau click pe acel link, văd toate valorile de filtrare (coloana 2). Totuși, Show All Review Rating nu este un link pentru motoarele de căutare (coloana 3).

Acest lucru va limita eficient numărul de URL-uri pe care motoarele de căutare le pot descoperi, ceea ce poate fi un lucru bun sau rău, în funcție de situația voastră. Dacă piața voastră țintă caută „recenzii 3-stele pardoseli laminate” atunci trebuie să faceți link-ul corespunzător disponibil motoarelor de căutare.

În mod similar, puteți ascunde filtre întregi sau doar anumite valori de filtrare.

De exemplu, eBay prezintă inițial utilizatorilor doar un număr limitat de filtre și valori de filtrare dar, după un click pe “see all” sau “More refinements” se deschid toate filtrele într-o fereastră modală:

Această fereastră modală conține toate link-urile necesare utilizatorilor să detalieze lista de produse.

 

Totuși, conținutul ferestrei modale nu este accesibil motoarelor de căutare, după cum puteți vedea în următoarea imagine, unde “More refinements” nu are hyperlink:

Elementul “More refinements” arată și funcționează ca un link, dar nu este un href normal

 

Un avantaj al încărcării selective de filtre și fațete cu AJAX și JavaScript ascuns roboților de căutare este că acest lucru poate ajuta la transferul unei autorități sporite (PageRank) către celelalte pagini, mai importante. Este un concept foarte similar vechiului concept de modelare a PageRank. Totuși, rețineți că această „modelare” are loc doar dacă motoarele de căutare nu pot executa AJAX pe astfel de pagini. Iar motoarele de căutare se îmbunătățesc de la o zi la alta în execuția JavaScript și AJAX. Pentru a vă asigura că link-urile nu sunt accesibile pentru Googlebot, blocați resursele necesare pentru apelurile JavaScript sau AJAX cu robots.txt, și apoi efectuați o operațiune de „fetch and render” în Google Search Console.

Dacă știți că unele pagini nu sunt valoroase pentru motoarele de căutare și dacă nu doriți ca aceste pagini inutile să fie indexate, de ce să permiteți accesul roboților la ele în primul rând?

Un alt avantaj al încărcării selective de URL-uri este acela că astfel veți împiedica procesul de crawling al link-urilor inutile.

Semnul diez (#)

Puteți adăuga parametrii de filtrare după semnul diez (#) pentru a evita indexarea URL-urilor fațetate. Acest lucru înseamnă că puteți permite navigării fațetate să creeze URL-uri pentru orice combinație posibilă de filtre. Ca observație, rețineți că conținutul AJAX este semnalizat cu semnul hashbang (#!). Totuși, această schemă nu mai este recomandată de Google.

hash bang consolidation

Operatorul de căutare info: arată pagina canonică indexată de Google.

 

Dacă efectuați o căutare “info:” pentru o pagină care include în URL semnul diez, veți vedea că Google prezintă pagina care exclude orice este trecut după semnul diez.

Pentru motoarele de căutare, această pagină:

http://www.modcloth.com/shop/books#?price=28,70&sort=newest&page=1

trimite la conținutul de pe această pagină:

http://www.modcloth.com/shop/books

hash bang consolidation2

Google reține în cache cuprinsul paginii generate înainte de utilizarea semnelor diez.

 

Semnul diez poate consolida, teoretic, semnalele de linking către modcloth.com/shop/books, dar toate paginile generate folosind semnul diez nu vor fi indexate; prin urmare, ele nu se pot apărea in SERPs.

Totuși, puteți plasa doar filtrele overhead după semnul diez. Ori de câte ori este selectată o fațetă esențială sau importantă, includeți-o într-un URL curat, înainte de semnul diez. Se pot adăuga, de asemenea, filtre de selecții multiple după semnul diez.

Puteți controla, de asemenea, roboții folosind instrumentele de gestionare a parametrilor URL oferiți de Bing și Google.

Setarea din imaginea de mai sus sugerează că parametrul mid este folosit pentru reducerea conținutului. Prefer să îi spun lui Google despre efectul pe care fiecare parametru îl are asupra conținutului paginii dar, în cele din urmă, îi vor lăsa pe ei să decidă ce URL-uri să supună procesului de crawling.

 

Această setare prezintă doar un indiciu pentru Google, prin urmare trebuie să rezolvați în continuare problema legată de crawling și de conținutul duplicat folosind o altă metodă (de ex., blocarea fațetelor overhead cu text selectiv robots.txt), sau folosind o combinație de metode.

Opțiunea noindex, follow

Adăugând meta tag-ul “noindex, follow” paginilor generate de filtrele overhead poate ajuta la rezolvarea problemelor de indexare excesivă (“index bloat”) dar nu va împiedica roboții de căutare să fie prinși în capcanele filtrării.

O scurtă observație despre folosirea directivei noindex în același timp cu robots.txt. Teoretic, “noindex,follow” se poate folosi în combinație cu robots.txt pentru a împiedica operațiunea de crawling și indexare a website-urilor noi. Totuși, dacă unele URL-uri nedorite au fost deja parcurse și indexate de roboți, atunci trebuie să adăugați mai întâi atributul “noindex, follow” acelor pagini și să permiteți roboților motoarelor de căutare să facă crawling pe ele. Acest lucru înseamnă că nu veți bloca încă URL-urile cu robots.txt. Blocați URL-urile nedorite cu robots.txt doar după ce URL-urile au fost scoase din index.

Sortarea produselor

Utilizatorilor trebuie să li se permită să sorteze lista de produse pe baza mai multor opțiuni. Unele opțiuni populare de sortare a produselor sunt cele mai vândute, noutăți, ratingul cel mai mare, prețul (de la mic la mare sau de la mare la mic), nume, și chiar procentul de reducere.

Câteva opțiuni populare de sortare.

 

Sortarea doar schimbă ordinea în care este prezentat conținutul, nu și conținutul în sine. Acest lucru va crea probleme de conținut duplicat sau aproape duplicat, în special când sortarea poate fi bidirecțională (de ex., sortare după preț—de la mare la mic și de la mic la mare) sau când întreaga listare încape pe o singură pagină (view-all).

Google ne spune că dacă parametrii de sortare nu există din start în URL-uri, nici măcar nu doresc să facă crawling pe acele URL-uri.

Această captură de ecran este luată din prezentarea oficială Google, “Parametrii URL în Webmaster Tools”.[51]

 

Cea mai bună metodă de abordare a sortării este situațională și depinde de modul în care sunt setate listările.

Folosiți rel=“canonical”

De multe ori, parametrii de sortare sunt păstrați în URL. Când utilizatorii schimbă ordinea de sortare, parametrii de sortare sunt adăugați în URL și pagina se reîncarcă. În acest caz, puteți folosi rel=“canonical” pe paginile sortate pentru a face trimitere la o pagină implicită (de ex., sortată conform celor mai vândute produse).

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

În această imagine, puteți vedea că deși sortarea generează URL-uri unice pentru opțiunile de sortare ascendente și descendente, ambele URL-uri fac trimitere spre același URL canonic.

 

Utilizarea rel=“canonical” este foarte recomandată dacă sortarea se produce pe o singură pagină, deoarece sortarea conținutului va schimba doar modul în care conținutul este afișat, nu și conținutul în sine. Acest lucru înseamnă că, conținutul de pe fiecare pagină, deși poate fi sortat, nu va fi diferit, și pagina generată va fi un duplicat. De exemplu, când sortarea reordonează conținutul pe o pagină view-all, generați duplicate (dat fiind faptul că o pagină view-all listează toate produsele din stoc). Totuși, chiar atunci când conținutul este sortat pagină cu pagină și nu folosind întreaga listare paginată, puteți crea conținut duplicat sau aproape duplicat.

Înlăturarea sau blocarea URL-urilor sortare

Acest lucru impune fie adăugarea atributului rel=“noindex, follow” URL-urilor de sortare, fie blocarea accesului la ele complet, folosind robots.txt sau în cadrul Google Search Console.

A screenshot of a cell phone Description generated with very high confidence

În acest exemplu, lista Ski Boots poate fi sortată în două direcții (preț „de la mare la mic” și preț „de la mic la mare”).

 

Când produsele pot fi sortate în două direcții, primul produs de pe prima pagină sortată „de la mare la mic” devine ultimul produs de pe ultima pagină sortată „de la mic la mare”. Al doilea produs de pe prima pagină devine penultimul de pe ultima pagină și așa mai departe. În funcție de numărul de produse pe care le listați în mod normal și de numărul de produse listate, puteți ajunge să aveți pagini duplicate exacte sau aproape. De exemplu, să spunem că listați 12 produse pe pagină și că există 48 produse în total. Acest lucru înseamnă că ultima pagină din seria de paginare va afișa exact 12 produse. Când listați după preț „de la mare la mic”, produsele de pe prima pagină a paginării vor fi exact aceleași cu produsele de pe ultima pagină când sortați de la ”mic la mare”.

Un mod de a gestiona sortarea bidirecțională este să permiteți motoarelor de căutare să indexeze doar o direcție de sortare și să înlăturați sau să blocați accesul la cealaltă. De exemplu, permiteți crawling-ul și indexarea URL-urilor de sortare a „celor mai vechi” și le blocați pe „cele mai noi”.

Înlăturarea sau blocarea URL-urilor sortare este cea mai ușoară metodă de implementat și poate ajuta la rezolvarea rapidă a problemelor de paginare, până când sunteți pregătiți să avansați cu o soluție mai complexă.

 

Folosiți AJAX pentru a sorta

Cu această abordare, sortați conținutul folosind AJAX și URL-urile nu se schimbă când utilizatorii sau roboții aleg o nouă opțiune de sortare. Toate link-urile externe sunt consolidate natural într-un singur URL, deoarece va exista un singur URL către care se poate face link.

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

Sortarea cu AJAX nu schimbă, de obicei, URL-ul.

 

Observați modul în care URL-ul din imaginea precedentă nu se schimbă atunci când lista este sortată din nou după Best Selling, în imaginea de mai jos:

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

Deși conținutul se actualizează când utilizatorii aleg diferite opțiuni de sortare, URL-ul rămâne același.

 

Deoarece URL-ul nu se actualizează la sortare, această metodă face imposibilă folosirea unui link, distribuirea sau salvarea URL-urilor pentru listările sortate. Dar oamenii chiar fac acest lucru? Chiar dacă o fac, cât de relevantă va fi paginarea sau sortarea într-o săptămână sau o lună de la momentul în care link-ul a fost copiat sau distribuit? Produsele sunt adăugate sau scoase în mod constant de pe listă, schimbând frecvent ordinea produselor. Există șanse ca produsele listate pe orice pagină de sortare să fie parțial sau total diferite de cele listate pe aceeași pagină săptămâna sau luna viitoare.

Prin urmare, capacitatea de distribuție (shareability) și de copiere a link-ului (linkability) nu ar trebui să vă preocupe atunci când decideți să implementați AJAX pentru sortare. Dacă este mai bine pentru utilizatori, faceți-o.

Folosiți semnul diez in URL-uri

Folosirea semnului diez în URL-uri permite distribuirea, marcarea și linking-ul către URL-urile individuale. Un atribut rel=“canonical” care trimite la URL-ul de bază (fără #) va consolida eventualele link-urile către un singur URL.

În această imagine, vizualizarea implicită listează produsele sortate conform SKU-urilor Most Relevant.

 

URL-ul de mai sus va fi pagina canonică. În imaginea de mai jos, veți observa cum URL-ul se schimbă când lista este filtrată după Price, low to high:

URL-ul include semnul diez și valoarea de filtrare ~priceLowToHigh.

 

În prezent, motoarele de căutare ignoră de obicei tot ce se află după semnul diez, doar dacă nu folosiți semnul (#!) pentru a semnaliza conținut AJAX (ceea ce în sine este demodat, de asemenea). Motoarele de căutare ignoră orice există după semnul diez deoarece folosirea sa în URL-uri nu face ca informații suplimentare să fie extrase din serverul web.

Implementarea semnului diez este o soluție elegantă care are în vedere experiența pentru utilizator și posibilele probleme de conținut duplicat.

Opțiunile de vizualizare

La fel cum utilizatorii preferă diferite opțiuni de sortare, unii utilizatori doresc să schimbe modul în care listările sunt afișate. Opțiunile cele mai populare de vizualizare sunt vezi N rezultate pe pagină sau vezi ca listă/tabel. Deși bune pentru utilizatori, opțiunile de vizualizare pot pune probleme motoarelor de căutare.

În exemplul de mai sus, utilizatorii pot alege să vizualizeze pagina ca tabel compact sau listă detaliată; pot alege, de asemenea, numărul de produse afișate pe pagină.

 

Vizualizarea tabel și listă

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

Vizualizarea tabel (stânga) și listă (dreapta).

 

Vizualizarea sun formă de tabel sau sub formă de listă prezintă aceleași SKU, dar vizualizarea în listă beneficiază de mult mai mult spațiu alb.

Acest spațiu poate fi completat cu informații suplimentare despre produs și reprezintă o oportunitate SEO deosebită, deoarece poate fi folosit nu doar pentru a crește cantitatea de conținut de pe pagină, dar și pentru a crea link-uri contextuale interne relevante către produse sau categorii părinte.

Abordarea optimă pentru opțiunile de vizualizare este să încărcați conținutul vizualizare listă în codul sursă într-un mod accesibil motoarelor de căutare apoi să folosiți JavaScript pentru a face trecerea între vizualizări în browser.

Nu este necesar să generați URL-uri separate pentru fiecare vizualizare. În cazul în care generați URL-uri separate, aceste pagini vor conține conținut duplicat, iar modul de a le gestiona este să folosiți atributul rel=“canonical” pentru o vizualizare implicită. Vizualizarea implicită trebuie să fie pagina care încarcă conținutul pentru vizualizarea tip listă.

De exemplu, următoarele două URL-uri indică atributul rel=“canonical” către /French-Door-Refrigerators/products:

/French-Door-Refrigerators/products?style=List

/French-Door-Refrigerators/products?style=Grid

Vezi – N – produse

Multe website-uri de comerț electronic au funcția Vezi – N – produse pe pagină pentru a alege numărul de produse din listare:

Mai sus este am prezentat un meniu vertical tipic (drop-down) pentru opțiunea ”vizualizare N produse” pe pagină.

 

Dacă este posibil, listarea implicită de produse va fi pagina view-all. Dacă implementare view-all nu este posibilă, afișați un număr de produse implicit în listă (să spunem 20) și permiteți utilizatorilor să dea click pe un link view-all.

Opțiunea view-all de la Nike este afișată chiar în meniu.

 

Dacă opțiunea view-all generează o listă imposibil de gestionat, cu mii de produse, permiteți utilizatorilor să aleagă între două numere, unde al doilea număr este substanțial mai mare decât cel implicit (de ex., 60 ș 180). Păstrați preferințele utilizatorilor într-o sesiune sau un cookie persistent[52], nu în parametri URL.

A doua opțiune de vizualizare este substanțial mai mare decât prima.

 

Dintr-o perspectivă SEO, URL-urile de tip vezi-N-produse pe pagină sunt gestionate de obicei cu atributul rel=“canonical” care trimite către paginile de listare implicite (care sunt, de obicei, paginile index pentru paginile de departament, categorie sau subcategorie).

De exemplu, pe o pagină de listare cu 464 produse, opțiunea de vizualizare a 180 produse pe pagină poate fi păstrată în perechea key=value itemsPerPage=180, iar URL-ul poate arăta astfel:

mywebsite.com/seat-covers/10A522.aspx?itemsPerPage=180

URL-ul de mai sus listează 180 produse pe pagină și va conține un atribut rel=“canonical” în antetul <head> care trimite la URL-ul index al categoriei:

mywebsite.com/seat-covers/10A522.aspx

Cu toate acestea, URL-ul canonic listează doar 60 produse pe pagină ca setare implicită și asta vor indexa motoarele de căutare.

Aceasta înseamnă că un subset mai mare (cel care listează 180 SKU) este canonicalizat într-un subset mai mic (cel care listează 60 SKU). Această abordare va crea unele probleme deoarece Google va indexa conținutul de pe pagina canonică (60 produse), ignorând conținutul de pe restul paginilor vezi-N-produse. În acest caz, trebuie să vă asigurați că motoarele de căutare pot accesa cumva fiecare produs din întregul set (464 produse). De exemplu, puteți realiza acest lucru cu conținut paginat care este gestionat cu rel=“prev” și rel=“next”, pentru ca Google să consolideze toate paginile componente către URL-ul canonic.

Utilizarea unui atribut rel=“canonical” pe o pagină vezi-N-produse este corectă dacă atributul canonic face trimitere fie la pagina view-all fie la cel mai mare subset de produse. Prima opțiune nu este de dorit dacă doriți să apară altă pagină în rezultatele căutării (de ex., prima pagină dintr-o serie paginată cu 20 produse listate ca setare implicită).

Abordările pentru controlul paginilor vezi-N-produse sunt similare celor pentru gestionarea sortării: o pagină view-all combinată cu AJAX/JavaScript pentru a schimba afișarea în browser, link-uri AJAX/JavaScript care nu pot fi supuse acțiunii de crawling, URL-uri marcate cu semnul diez, sau folosirea meta tag-ului „noindex”. Am menționat aceste abordări în ordinea preferată de mine, dar rețineți că deși o abordare poate fi bună în anumite condiții pe un website, se poate să nu funcționeze pe altul.

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. Prioritize: Good Content Bubbles to the Top, http://www.nngroup.com/articles/prioritize-good-content-bubbles-to-the-top/ ↑
  2. New snippets for list pages, http://insidesearch.blogspot.fr/2011/08/new-snippets-for-list-pages.html ↑
  3. More rich snippets on their way: G Testing Real Estate Rich Snippets, https://plus.google.com/+MarkNunney/posts/RqzNcKE9NSc ↑
  4. Product – schema.org, http://schema.org/Product ↑
  5. Below the fold, http://en.wikipedia.org/wiki/Above_the_fold#Below_the_fold ↑
  6. Implement the First 1-2 Levels of the E-Commerce Hierarchy as Custom Sub-Category Pages, http://baymard.com/blog/ecommerce-sub-category-pages ↑
  7. Usability is not dead: how left navigation menu increased conversions by 34% for an eCommerce website, https://vwo.com/blog/usability-left-navigation-menu-bar-conversions-ecommerce-website/ ↑
  8. User Mental Models of Breadcrumbs, http://www.angelacolter.com/breadcrumbs/ ↑
  9. Breadcrumb Navigation Increasingly Useful, http://www.nngroup.com/articles/breadcrumb-navigation-useful/ ↑
  10. Breadcrumbs, http://www.bing.com/webmaster/help/markup-breadcrumbs-72419f3f ↑
  11. New site hierarchies display in search results, http://googleblog.blogspot.fr/2009/11/new-site-hierarchies-display-in-search.html ↑
  12. Visualizing Site Structure And Enabling Site Navigation For A Search Result Or Linked Page, http://appft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.html&r=1&f=G&l=50&s1=%2220110276562%22.PGNR.&OS=DN/20110276562&RS=DN/20110276562 ↑
  13. Rich snippets – Breadcrumbs, https://support.google.com/webmasters/answer/185417?hl=en ↑
  14. Can I place multiple breadcrumbs on a page? https://www.youtube.com/watch?v=HXEYryd3eAY ↑
  15. Location, Path & Attribute Breadcrumbs, http://instone.org/files/KEI-Breadcrumbs-IAS.pdf ↑
  16. Taxonomies for E-Commerce, Best practices and design challenges -http://www.hedden-information.com/Taxonomies_for_E-Commerce.pdf ↑
  17. Breadcrumb Navigation Increasingly Useful, http://www.nngroup.com/articles/breadcrumb-navigation-useful/ ↑
  18. HTML Entity List, http://www.freeformatter.com/html-entities.html ↑
  19. Pagination and SEO, https://www.youtube.com/watch?v=njn8uXTWiGg&feature=youtu.be&t=11m ↑
  20. Pagination and Googlebot Visit Efficiency, http://moz.com/ugc/pagination-and-googlebot-visit-efficiency ↑
  21. The Anatomy of a Large-Scale Hypertextual, Web Search Engine, http://infolab.stanford.edu/pub/papers/google.pdf ↑
  22. Implement the First 1-2 Levels of the E-Commerce Hierarchy as Custom Sub-Category Pages, http://baymard.com/blog/ecommerce-sub-category-pages ↑
  23. Five common SEO mistakes (and six good ideas!), http://googlewebmastercentral.blogspot.ca/2012_03_01_archive.html ↑
  24. Search results in search results, http://www.mattcutts.com/blog/search-results-in-search-results/ ↑
  25. View-all in search results, http://googlewebmastercentral.blogspot.ca/2011/09/view-all-in-search-results.html ↑
  26. Users’ Pagination Preferences and ‘View-all’, http://www.nngroup.com/articles/item-list-view-all/ ↑
  27. Progressive enhancement, http://en.wikipedia.org/wiki/Progressive_enhancement ↑
  28. Users’ Pagination Preferences and ‘View-all’, http://www.nngroup.com/articles/item-list-view-all/ ↑
  29. HTML <link> rel Attribute, http://www.w3schools.com/tags/att_link_rel.asp ↑
  30. Faceted navigation best (and 5 of the worst) practices, http://googlewebmastercentral.blogspot.ca/2014/02/faceted-navigation-best-and-5-of-worst.html ↑
  31. Implementing Markup For Paginated And Sequenced Content, https://web.archive.org/web/20140527145918/http://www.bing.com/blogs/site_blogs/b/webmaster/archive/2012/04/13/implementing-markup-for-paginated-and-sequenced-content.aspx ↑
  32. Infinite Scrolling: Let’s Get To The Bottom Of This, http://www.smashingmagazine.com/2013/05/03/infinite-scrolling-lets-get-to-the-bottom-of-this/ ↑
  33. Web application/Progressive loading, http://docforge.com/wiki/Web_application/Progressive_loading ↑
  34. Infinite scroll search-friendly recommendations, http://googlewebmastercentral.blogspot.ca/2014/02/infinite-scroll-search-friendly.html ↑
  35. Infinite Scrolling: Let’s Get To The Bottom Of This, http://www.smashingmagazine.com/2013/05/03/infinite-scrolling-lets-get-to-the-bottom-of-this/ ↑
  36. Infinite Scroll On Ecommerce Websites: The Pros And Cons, http://www.lyonscg.com/insights/infinite-scroll-on-ecommerce-websites-the-pros-and-cons/ ↑
  37. Why did infinite scroll fail at Etsy?, http://danwin.com/2013/01/infinite-scroll-fail-etsy/ ↑
  38. Brazillian Virtual Mall MuccaShop Increases Revenue by 25% with Installment of Infinite Scroll Browsing Feature, https://web.archive.org/web/20131106172124/http://www.ereleases.com/pr/brazillian-virtual-mall-muccashop-increases-revenue-25-installment-infinite-scroll-browsing-feature-135237 ↑
  39. Typographical error, http://en.wikipedia.org/wiki/Typographical_error ↑
  40. Better infinite scrolling, http://scrollsample.appspot.com/items ↑
  41. The Paradox of Choice, http://en.wikipedia.org/wiki/The_Paradox_of_Choice:_Why_More_Is_Less ↑
  42. Search Patterns: Design for Discovery, [page 95] ↑
  43. Adding product filter on eCommerce website boosts revenues by 76%, https://vwo.com/blog/product-filter-ecommerce-ab-testing-revenue/ ↑
  44. Configuring URL Parameters in Webmaster Tools, https://www.youtube.com/watch?v=DiEYcBZ36po&feature=youtu.be&t=1m37s ↑
  45. Permutation, Combination – Calculator, http://easycalculation.com/statistics/permutation-combination.php ↑
  46. Faceted navigation best (and 5 of the worst) practices, http://googlewebmastercentral.blogspot.ca/2014/02/faceted-navigation-best-and-5-of-worst.html ↑
  47. Implement the First 1-2 Levels of the E-Commerce Hierarchy as Custom Sub-Category Pages, http://baymard.com/blog/ecommerce-sub-category-pages ↑
  48. Implementing Pagination Attributes Correctly For Google, http://searchengineland.com/implementing-pagination-attributes-correctly-for-google-114970 ↑
  49. Do URLs in robots.txt pass PageRank? https://productforums.google.com/forum/#!category-topic/webmasters/crawling-indexing–ranking/OTeGqIhJmjo ↑
  50. Faceted navigation best (and 5 of the worst) practices, http://googlewebmastercentral.blogspot.fr/2014/02/faceted-navigation-best-and-5-of-worst.html ↑
  51. URL Parameters in Webmaster Tools, https://docs.google.com/presentation/d/1xWy5TOkB4rwoUHXFPgwVMgl2Op9PayZOWa5wdW7ZB-o/present?pli=1&ueb=true#slide=id.g6205f11_0_28, page 18 ↑
  52. Persistent cookie, http://en.wikipedia.org/wiki/HTTP_cookie#Persistent_cookie