export function getCanonicalUrl(rawUrl: string, allowedParams: string[] = ['page', 'brand']): string {
try {
const url = new URL(rawUrl);
const searchParams = url.searchParams;
const cleanParams = new URLSearchParams();
allowedParams.forEach(param => {
if (searchParams.has(param)) {
cleanParams.set(param, searchParams.get(param)!);
}
});
const query = cleanParams.toString();
url.search = query ? `?${query}` : '';
// Eliminăm slash-ul de la final pentru consistență (opțional)
return url.toString().replace(/\/$/, "");
} catch (e) {
return rawUrl;
}
}Salutare. Hai să vorbim direct despre canonical-uri, tagul ăla din <head> pe care mulți îl pun pe pilot automat și apoi se miră că Google le ignoră paginile importante. Am rezolvat recent problema asta pe un e-commerce destul de mare, unde parametrii de filtrare pur și simplu distruseseră bugetul de crawling. Dacă ai filtre, paginare sau distribui conținut pe mai multe domenii, fii foarte atent cum le configurezi.
Coșmarul parametrilor de URL și soluția self-referential
Cea mai comună greșeală pe care o văd în producție este lipsa tagului canonical de pe paginile curate sau ignorarea completă a parametrilor de tracking (UTM-uri, gclid) și sortare. Dacă ai pagina-produs și pagina-produs?utm_source=facebook, Google vede două URL-uri diferite. Soluția e simplă în teorie: fiecare pagină "curată" trebuie să aibă un tag canonical self-referential, adică să arate spre ea însăși, dar fără query params de tracking.
Dar atenție la trade-off. Dacă elimini prin cod toți parametrii din canonical, s-ar putea să pierzi pagini de aterizare legitime generate prin filtre de căutare (de exemplu, o pagină de categorie filtrată după un brand mare care are volum de căutare organic). Pentru filtrele SEO-friendly, canonical-ul trebuie să rămână pe URL-ul cu parametrul respectiv, în timp ce pentru sortări (ex. ?sort=price_asc) trebuie să trimită la categoria de bază, fără sortare.
Paginarea: Mitul lui page=1
Prin 2019, Google a pensionat oficial suportul pentru rel="prev" și rel="next". De atunci, mulți developeri au început să pună canonical de pe toate paginile de listare (/produse?page=2, /produse?page=3) către prima pagină (/produse).
Asta este o greșeală uriașă. Dacă faci asta, Googlebot nu mai crawlează cum trebuie produsele de pe paginile 2, 3, 4 pentru că consideră paginile respective ca fiind duplicate ale primei pagini. Corect este ca fiecare pagină din paginare să aibă canonical self-referential. /produse?page=2 trebuie să aibă canonical către /produse?page=2. Da, structura paginii seamănă, dar produsele sunt complet diferite, iar Google are nevoie să le acceseze pentru a le indexa individual.
Cross-domain canonicals și syndication
Dacă scrii un articol tehnic bun pe blogul tău și vrei să-l republici pe Medium sau pe un site partener mai mare pentru expunere, ai nevoie de un cross-domain canonical. Tagul din antetul paginii de pe Medium trebuie să arate direct către URL-ul original de pe site-ul tău.
Trade-off-ul aici este destul de dur: platformele mari au o autoritate de domeniu uriașă și, chiar și cu canonical setat corect, uneori Google tot preferă să afișeze în rezultate articolul de pe Medium în detrimentul blogului tău personal. Totuși, setarea tagului te protejează de o penalizare pentru conținut duplicat și garantează că, pe termen lung, semnalele de link-building se consolidează pe domeniul tău.
Cum generăm un canonical curat în cod
Nu te baza niciodată pe window.location.href direct în frontend pentru a genera canonical-ul. Riscă să preia parametri murdari de la useri. Trebuie să filtrezi query string-ul printr-o listă de parametri permiși (cum ar fi paginarea sau filtrele SEO-friendly) și să ignori restul.