const canonical = document.querySelector('link[rel="canonical"]');
if (canonical) {
console.log(`%c Canonical gasit: ${canonical.href}`, 'color: #00ff00; font-weight: bold;');
if (canonical.href !== window.location.href) {
console.warn(`Atentie! Canonical difera de URL-ul curent:\nCanonical: ${canonical.href}\nActual: ${window.location.href}`);
}
} else {
console.error('Eroare: Tag-ul canonical lipseste complet din head!');
}Am văzut prea des tag-ul canonical tratat ca pe o chestie de tipul "lasă că se ocupă framework-ul". Am pățit-o acum trei ani la un proiect cu peste 50k de pagini active, unde setările default ne-au aruncat în aer bugetul de crawling. Google pur și simplu ne ignora paginile importante fiindcă se pierdea în URL-uri cu parametri de filtrare.
Dacă nu ești atent, canonical tag-ul devine o simplă recomandare pe care Google o ignoră cu grație. Hai să vedem cum să-l configurezi corect ca să nu-ți canibalizezi traficul organic.
Parametrii de URL și marea capcană auto-referențială
Cea mai frecventă greșeală pe care o văd în producție este canonical-ul dinamic generat greșit pe paginile cu filtre.
Dacă ai un URL de tipul site.ro/telefoane și utilizatorul filtrează după brand, ajunge pe site.ro/telefoane?brand=apple&sort=price_asc.
Multe CMS-uri au prostul obicei de a genera un canonical auto-referențial, adică pun tag-ul canonical exact către URL-ul curent, cu tot cu parametri. Rezultatul? Google vede mii de pagini "unice" care au de fapt același conținut, doar sortat diferit.
Regula de aur e simplă: URL-ul cu parametri trebuie să aibă canonical către versiunea curată, fără query parameters. Adică spre site.ro/telefoane.
Trade-off sincer: Pierzi indexarea pe niște combinări de filtre foarte specifice (long-tail keywords), dar salvezi bugetul de crawl și autoritatea paginii principale. Dacă ai pagini de filtre care chiar merită indexate (ex: "telefoane apple"), creează URL-uri dedicate, curate (ex: /telefoane/apple), nu te baza pe parametri.
Paginarea: Marea dilemă din SEO
Încă mai văd developeri care pun canonical de pe paginile /blog?page=2, /blog?page=3 către prima pagină /blog. Nu face asta!
Am testat asta pe un site cu 15k vizite lunare. Când am pus canonical spre prima pagină, Google a încetat să mai crawleze paginile de adâncime. Consecința? Articolele mai vechi, care nu mai apăreau pe prima pagină, au dispărut complet din index fiindcă robotul nu mai ajungea la ele.
Cum e corect? Fiecare pagină din paginare trebuie să aibă un canonical auto-referențial (pagina 2 are canonical spre pagina 2). O altă opțiune este să ai o pagină "View All" care încarcă toate produsele/articolele și să pui canonical-ul acolo. Dar asta e nasol pentru viteza de încărcare dacă ai sute de itemi, deși e ideal pentru SEO.
Cross-domain canonical: Când împarți conținutul
Să zicem că scrii un articol tehnic excelent pe blogul tău, dar vrei să-l publici și pe Medium sau pe un site partener cu autoritate mai mare pentru vizibilitate.
Dacă îl lași așa, site-ul mai mare va ranka pe primul loc, iar blogul tău va fi penalizat sau ignorat ca duplicate content. Soluția este să ceri partenerului să pună un tag canonical cross-domain care să trimită spre articolul original de pe site-ul tău.
Merge brici pentru autoritatea ta, dar e nasol pentru partener, pentru că ei nu vor acumula valoare SEO directă din acel trafic. De asta mulți publisheri mari refuză să facă asta.
Cum verifici rapid în consolă?
În loc să dai de fiecare dată "View Source" și să cauți printre sute de linii de cod, poți folosi un snippet simplu în consola browserului ca să vezi rapid ce canonical ai pe pagina curentă.
Voi cum gestionați canonical-ul la aplicațiile de tip Single Page Application (SPA) cu hidratare târzie? Mie mi-a dat mari bătăi de cap pe o arhitectură mai veche cu Angular.