Am vorbit in articolul trecut despre tactici de paginatie la nivel de incepator, haideti sa vedem cum stau lucrurile si la nivel avansat. O data ce stapaniti tacticile pentru incepatori, nu este deloc dificil sa faceti pasul pentru a privi in profunzime acest proces.

Accesul la sever va permite sa vedeti exact cum este parcurs de Google continutul paginilor de paginatie inainte sa incepeti sa implementati tacticile despre care am vorbit mai sus. Inainte sa puneti in aplicare una dintre aceste tehnici, este recomandat sa alegeti o serie de pagini de paginatie din site pentru a vedea cate pagini crawleaza Googlebot .

Efectuati apoi interogari in Google pentru a identifica cate dintre aceste pagini sunt indexate. Aveti astfel posibilitatea sa determinati succesul implementarilor pe care le faceti si sa reveniti dupa ce aceste modificari au fost facute, pentru a vedea daca ratele de crawl si indexare s-au imbunatatit.

Setari de scroll Ajax si Java

Cu totii am intalnit probabil, setari cu scroll infinit, mai ales pe site-urile e-commerce. Aceasta caracteristica este de preferat pentru a imbuntati experienta utilizatorului, iar Ajax si Javascript ar trebui implementate cu ajutorul procesului de Progressive Enhancement.

Astfel, va asigurati ca site-ul functioneaza perfect si pentru cei care nu au Javascript pornit iar voi puteti implementa tacticile de paginatie despre care am vorbit mai sus. Avantajul de necontestat este faptul ca Googlebot acceseaza fara probleme continutul, il parcurge si il indexeaza, iar site-ul ofera functii avansate de navigare JavaScript pentru utilizatori. Aici trebuie sa aveti in vedere si timpul de incarcare al paginii.

View-all page vs rel=”prev”/”next”

View-all page sau rel=’’prev”/’’next”? Care este metode preferata intre cele doua? Google declara ca prefera folosirea View-all page pentru solutionarea problemelor de paginatie, exista situatii in care rel=’’prev’’/’’next’’ este o metoda mai buna, in ceea ce priveste semnalele de relevanta.

Google a declarat ca in ceea ce priveste autoritatea linkurilor, cele doua metode sunt similare, lucru ce ne conduce la urmatoarea intrebare: Cum ramane cu celalalte semnale de relevanta, URL-urile unice, titlurile, descrierile?

In cazul canonicalizarii care apare atunci cand utilizam metoda View-all, Google stie sa identifice aceste elemente pe pagina canonicalizata si se transmite toata autoritatea liunkurilor primii pagini, cea de View-all.

In cazul in care paginile conectate intre ele prin rel=”prev”/”next” contin titluri si URL-uri unice, atunci oricare dintre aceste pagini are posibilitatea sa se pozitioneze in cautari pentru interogari relevante, atunci fiecare pagina are semnalele ei de relevanta fata de cazul in care toate aceste pagini sunt canonicalizate catre prima pagina.

Desi nu putem sti exact modul in care Google trateaza rel=”prev”/”next” in index, cu siguranta pentru cazuri in care pagini de paginatie, exceptand prima pagina, sunt returnate in SERP, URL-ul, titlul si alti factori au un rol definitoriu in determinarea relevantei pentru orice interogare.

Parametri si rel=”prev”/”next”

Cateodata la implementarea rel=”prev”/”next” URL-urile paginilor de paginatie vor contine parametri, cum ar fi ID-ul unic al sesiunii, care nu schimba continutul paginii. Acest lucru poate conduce la probleme de continut duplicat.

Pentru a evita acest lucru, nu trebuie decat sa-i spuneti lui googlebot sa nu crawleze anumite URL-uri, folosind „URL Parameter” in Google Webmaster Tools. Putem pastra insa autoritatea linkurilor de la aceste URL-uri folosind rel=”prev”/”next” impreuna cu tag-urile canonice.

In primul rand, e nevoie sa va asigurati ca toate paginile din secventa rel=”prev”/”next” folosesc acelasi parametru. In al doilea rand, fiecare URL care contine parametru, trebuie canonicalizat la versiunea sa fara parametru.

Exemplu: avem trei pagini de paginatie accesate prin acelasi SesssionID.

  1. site.ro/pagina1.html?sessionID=10
  2. site.ro/pagina2.html?sessionID=10
  3. site.ro/pagina3.html?sessionID=10

Paginile sunt legate intre ele prin rel=”prev”/”next” ca in exemplul de mai jos:

  1. pagina1.html va avea <link rel=”next” href=”http://www.site.ro/pagina2.html”>
  2. pagina2.html va avea <link rel=”prev” href=”http://www.site.ro/pagina1.html”> si <link rel=”next” href=”http://www.site.ro/pagina2.html”>
  3. pagina3.html va avea <link rel=”prev” href=”http://www.site.ro/pagina2.html”>

Paginile care contin sessionID vor avea implementat tagul canonical catre paginile fara sessionID.

  1. site.ro/pagina1.html?sessionID=10 -> canonical catre site.ro/pagina1.html
  2. site.ro/pagina2.html?sessionID=10 -> canonical catre site.ro/pagina2.html
  3. site.ro/pagina3.html?sessionID=10 -> canonical catre site.ro/pagina3.html

Continut filtrat si rel=”prev”/”nex”

Haideti sa vedem exemple pentru o situatie cu parametrii care filtreaza continutul intr-o secventa de pagini de paginatie. In exemplul urmator, avem un parametru care filtreaza paginile de produs in functie de brand :

Pagina 1: http://www.site.ro/pagina1.html?brand=nike

Continutul de pe fiecare pagina depinde de aceasta variabila, astfel ca:

Pagina 1: http://www.site.ro/pagina1.html?brand=adidas

Pagina 2: http://www.site.ro/pagina2.html?brand=adidas

Va returna un set de produse complet diferit de:

Pagina 1: http://www.site.ro/pagina1.html?brand=reebok

Pagina 2: http://www.site.ro/pagina2.html?brand=reebok

Daca sunteti siguri ca aceste pagini aduc un plus de valoare utilizatorului si vreti ca aceste pagini sa fie prezente in indexul Google, este recomandat sa se creeze secvente separate cu rel=”prev”/”next” pentru fiecare filtru de brand.

Vom avea pentru fiecare brand pagini de paginatie legate intre ele cu rel=”prev”/”next”

  1. pagina1.html?brand=nike
  2. pagina2.html?brand=nike
  3. pagina2.html?brand=nike

Continut sortat si rel=”prev”/”next”

Ultimul tip de parametri din URL de care ne vom ocupa este cel cu sortarea continutului. Desi se gasesc cel mai frecvent intr-un blog sau intr-un forum, poate fi si pe un site e-commerce.

De exemplu:

Pagina 1: http://www.sitestiri.ro/pagina1.html?order=oldest

Poate exista insa o optiune pentru a vedea cele mai noi produse (articole) prima data:

Pagina 1: http://www.sitestiri.ro/pagina1.html?order=newest

Sunt bineintels in comunitatea SEO, dezbateri cu privire la selectarea celei mai bune tactici pentru a trata aceasta situatie. O sugestie din partea unora ar fi o incercare de separare a secventelor rel= „prev”/”next” atat pentru „newest, cat si pentru „oldest”. In acest caz Google ar trebui sa indexeze mai multe pagini de paginatie cu acelasi continut. Lucrul acesta poate duce la probleme mari de continut duplicat.

Sfatul nostru este sa faceti navigarea cat mai simpla si nu dati batai de cap nici utilizatorilor, nici motoarelor de cautare.

Desi multe dintre metodele pot parea complicate la prima vedere, studierea lor si aplicarea pentru fiecare caz in parte va facilita cu siguranta munca specialistilor SEO.

Sursa imagine: blog.platinastudio.com