function getCanonicalUrl(currentUrl: string): string {
const url = new URL(currentUrl);
const allowedParams = ['page', 'category']; // Doar parametrii care schimbă conținutul esențial
const keys = Array.from(url.searchParams.keys());
keys.forEach(key => {
if (!allowedParams.includes(key)) {
url.searchParams.delete(key);
}
});
// Scoatem trailing slash pentru consistență
return url.toString().replace(/\/$/, "");
}Hai să vorbim direct despre tagurile canonical, că m-am săturat să văd indexări bușite din cauza unor parametri de tracking sau paginări prost gestionate. Am pățit-o acum doi ani la un e-commerce destul de mare, cu vreo 15.000 de produse active, unde echipa de marketing a umplut netul de linkuri cu parametri UTM. Google a început să indexeze variantele cu UTM, iar crawl budget-ul nostru s-a dus pe apa sâmbetei în doar două săptămâni. Am rezolvat-o relativ simplu, dar am învățat că teoria din documentația Google e una, iar realitatea din producție e alta.
Parametrii din URL: Cum curățăm mizeria
Cea mai mare greșeală pe care o văd este lipsa unui tag canonical self-referential pe paginile curate. Dacă ai URL-ul site.ro/pantofi și utilizatorul vine din newsletter cu site.ro/pantofi?utm_source=newsletter&sort=price_asc, Google s-ar putea să creadă că sunt două pagini diferite dacă nu ești atent.
Soluția e să ai mereu un canonical care arată spre versiunea "curată" (fără parametri de tracking sau de sortare irelevanți).
Aici apare însă un trade-off important. Dacă ai filtre care schimbă complet conținutul paginii (de exemplu, o categorie de haine filtrată doar pentru "bărbați"), acea pagină are valoare de căutare. Nu-i pune canonical către categoria generală. Dacă o faci, Google va ignora pagina filtrată și pierzi trafic organic valoros pe cuvinte cheie de tip "long-tail". Pentru parametrii de sortare sau tracking (sort, page_size, utm), canonical-ul trebuie să arate mereu spre URL-ul de bază.
Paginarea: Mitul lui rel="prev/next"
Mulți încă mai cred că Google folosește rel="prev" și rel="next". Google a anunțat oficial acum câțiva ani că nu le mai folosește deloc pentru indexare. Ce facem atunci cu paginile 2, 3, 4 dintr-o categorie?
Am văzut des recomandarea greșită de a pune canonical de pe pagina 2 direct pe pagina 1. Este o idee proastă. Dacă faci asta, Google nu va mai asocia produsele de pe pagina 2 cu acea categorie și s-ar putea să nu le mai indexeze deloc, pentru că roboții nu vor mai parcurge link-urile din paginare.
Soluția corectă este ca fiecare pagină din paginare să aibă un canonical self-referential (adică pagina 2 să aibă canonical către ea însăși). Alternativ, dacă ai o pagină de tip "View All" care se încarcă rapid (sub 1.5 secunde) și conține toate produsele, poți pune canonical de pe toate paginile de paginare către acea pagină unică. Dar dacă ai mii de produse, "View All" va omorî baza de date și experiența userului, așa că rămâi la self-canonical.
Cross-domain canonicals: Când publici în mai multe locuri
Dacă scrii un articol pe blogul tău și îl republici pe Medium sau pe un site partener, ai nevoie de cross-domain canonical. Practic, îi spui lui Google: "Hei, articolul de pe site-ul X este originalul, dă-i lui toată autoritatea".
Merge excelent pentru link building și expunere, dar există un risc. Dacă site-ul partener are o autoritate imensă (de exemplu, un site de știri mare), s-ar putea ca Google să ignore canonical-ul tău în primele săptămâni și să indexeze totuși versiunea lor mai sus în rezultate. Cu timpul însă, lucrurile se reglează.
Voi cum gestionați filtrele complexe în proiectele voastre? Le blocați direct din robots.txt sau vă bazați exclusiv pe canonical tags?