Canonical URL: rel=canonical, când îl folosești și cum NU îl folosești
rel=canonical declară pagina preferată când există variante duplicate. Când îl folosești, capcanele clasice și cum îl corelezi cu hreflang.
Cuprins
Un canonical URL este URL-ul pe care îl declari drept varianta preferată a unui conținut care apare sub mai multe adrese. Se setează prin tag-ul <link rel="canonical" href="..."> în <head> și spune motoarelor de căutare unde să consolideze semnalele de ranking (linkuri externe, date de indexare, link equity) atunci când același conținut este accesibil pe mai multe URL-uri.
Standardizat în 2009 de Google, Yahoo și Microsoft, tag-ul rezolvă o problemă concretă: parametrii UTM, filtrele de sortare și paginarea produc variante URL care arată ca pagini separate pentru un crawler, chiar dacă sunt același conținut. Canonical consolidează acel conținut pe o singură adresă. Setat greșit, blochează indexarea unor pagini pe care vrei să le indexezi sau pune Google pe o pistă pe care o ignoră complet.
Ce face rel=canonical mai exact?
Tag-ul <link rel="canonical"> este un semnal adresat motorului de căutare, nu utilizatorului. Utilizatorul accesează URL-ul pe care l-a primit (cu parametrii lui, cu filtrele lui); Google citește tag-ul și decide că semnalele de ranking trebuie acumulate pe URL-ul canonic declarat, nu pe varianta curentă.
Câteva proprietăți importante:
- Este un semnal, nu o directivă. Spre deosebire de un redirect 301 sau de
noindex, canonical-ul poate fi ignorat dacă alte semnale îl contrazic. Google respectă canonical-ul consistent, dar nu este obligat să o facă. - Auto-referința este validă și recomandată. Pagina canonică ar trebui să aibă un canonical care indică spre ea însăși. Absența tag-ului pe pagina canonică lasă Google să ghicească.
- Funcționează cross-domain. Poți declara canonical-ul spre un domeniu diferit, util când publici conținut în mod legitim pe două site-uri și vrei să concentrezi autoritatea pe unul singur.
- Nu transmite trafic, doar semnal de indexare. Variantele non-canonice rămân accesibile utilizatorilor; doar Google tratează varianta declarată ca principală.
Care sunt cazurile clasice (duplicate content, paginare, parametri URL)?
Trei situații recurente în care canonical rezolvă o problemă reală de indexare:
- Parametri de urmărire și de sesiune. O pagină de produs accesibilă la
/produse/cizma-pieleapare și la/produse/cizma-piele?utm_source=newsletter&utm_campaign=mai. Fără canonical, Google poate indexa ambele URL-uri ca pagini separate și dilua semnalele de ranking. Canonical pe versiunea fără parametri rezolvă problema; query string-urile UTM dispar din index, conținutul rămâne pe un singur URL. - Parametri de filtrare și sortare. Un magazin online cu sortare după preț, recenzii sau disponibilitate generează sute de URL-uri pentru același set de produse (
/incaltaminte?sort=price_asc,/incaltaminte?sort=reviews). Canonical pe URL-ul fără parametru de sortare menține indexul curat. Atenție: dacă filtrele produc pagini cu conținut distinct și valoros (ex. o categorie de produse filtrată după o marcă), canonical nu e soluția corectă; acele pagini merită indexate pe cont propriu. - Paginare. Paginile 2, 3, 4 dintr-o listă lungă sunt tehnic duplicate parțiale față de pagina 1. Strategia standard este canonical pe fiecare pagină din serie spre ea însăși (nu spre pagina 1), combinat cu link-uri
next/prevîn sitemap sau header HTTP pentru a semnala continuitatea. Canonical spre pagina 1 pe toate paginile din serie a fost o practică veche care astăzi face mai mult rău decât bine.
Un caz adesea neglijat este conținutul sindical: dacă articolul tău apare republiat pe un alt site, poți solicita publicației externe să adauge un canonical spre URL-ul tău original, transmițând link equity-ul spre pagina ta. Nu toate publicațiile acceptă, dar merită cerut.
Cum gestionăm canonical pe crawlerra.com?
Pe crawlerra.com folosim SeoService din Angular SSR pentru a emite hreflang și canonical împreună, evitând conflictul semnalelor între cele două tag-uri. Pentru paginile RO-only (majoritatea conținutului editorial: articole de blog și intrări de dicționar), canonical și hreflang="ro" + hreflang="x-default" trimit toate la aceeași URL în română. Nu declarăm o alternativă en pe aceste pagini, deci nu există risc de canonical care contrazice hreflang-ul1.
Injectarea tag-urilor se face în SSR, nu prin hydration pe client. Asta înseamnă că Googlebot vede canonical-ul corect la prima cerere HTTP, fără să depindă de execuția JavaScript. Pentru contextul tehnic complet al server-side rendering și de ce contează pentru SEO, vezi entry-ul dedicat. Alinierea cu semnalele din sitemap.xml este asigurată de același handler Express care construiește sitemap-ul dinamic.
Care sunt capcanele frecvente (canonical loops, contradicting signals)?
- Canonical loop. Pagina A are canonical spre pagina B, iar pagina B are canonical spre pagina A. Google detectează loopul și poate alege una dintre ele sau poate ignora ambele declarații. Apare cel mai frecvent când template-ul de pagină preia URL-ul curent dinamic și există o regulă de rescriere care transformă URL-ul înainte de randare.
- Canonical care contrazice hreflang. Pagina RO declară canonical spre versiunea EN, dar versiunea EN are hreflang spre versiunea RO. Cele două semnale indică în direcții contrare; Google, confuz, alege singur. Regula simplă: pagina RO are canonical spre URL-ul RO; pagina EN are canonical spre URL-ul EN. hreflang leagă cele două pagini ca alternative lingvistice, nu ca variante canonice una pentru cealaltă.
- Canonical spre o pagină cu noindex. Declari o pagină ca canonică, dar aceea are un tag
noindexsau este blocată în meta robots. Google nu poate indexa URL-ul canonic și poate reveni la varianta non-canonică sau poate renunța complet la indexarea paginii. - Canonical relativ cu base URL greșit. Folosești
<link rel="canonical" href="/articolul-meu">(relativ) în loc de URL absolut. Dacă<base href>este setat greșit sau lipsește, browserul construiește un URL canonic complet greșit. Întotdeauna folosește URL absolut în canonical. - Canonical inconsistent cu sitemap-ul. Sitemap-ul include URL-ul cu parametri, dar pagina declară canonical spre URL-ul fără parametri. Google vede un conflict între două semnale oficiale și poate ignora ambele.
Care e anti-pattern-ul cel mai costisitor (canonical spre o pagină indisponibilă)?
Cel mai grav caz: canonical care indică spre o pagină ce returnează 404, 410 sau este redirecționată. Scenariul clasic este o migrare de URL-uri în care paginile vechi au primit redirect 301 spre URL-urile noi, dar template-ul continuă să emită canonical-ul vechi (preluat dintr-o variabilă neactualizată). Efectul nu este vizibil imediat: paginile noi par indexate, dar semnalele de ranking nu se transferă corect. Recuperarea poate dura luni.
Trei verificări practice după orice migrare de URL-uri:
- Ia un eșantion de 20-30 URL-uri noi și verifică cu
curl -sI <url> | grep -i canonical(sau view source) că tag-ul canonical indică spre URL-ul curent, nu spre cel vechi. - Verifică în Google Search Console, secțiunea „Pagini", că paginile noi apar drept canonice alese de Google, nu cele vechi.
- Asigură-te că sitemap-ul reflectă URL-urile noi și că nu include URL-urile vechi. Un sitemap inconsistent cu canonical-ul este un conflict de semnale pe care Google îl rezolvă în mod imprevizibil. Dacă vrei să înțelegi cât de des îți recrawlează Google paginile și cât de repede preia schimbările de canonical, citește despre crawl budget.
Anti-pattern-ul este costisitor nu pentru că e greu de diagnosticat (Search Console îl arată relativ clar), ci pentru că daunele se acumulează tăcut timp de săptămâni înainte să observi că paginile noi nu urcă în ranking. Canonical-ul spre o pagină indisponibilă este, practic, o gaură prin care link equity-ul se scurge fără urmă.
Dacă vrei să înțelegi cum se leagă canonical cu strategia editorială mai largă, vezi topical authority: consolidarea semnalelor de indexare pe URL-urile canonice corecte este fundația pe care se construiesc clusters tematice coerente. Iar dacă auditezi un site cu probleme istorice de canonical sau de conținut duplicat, E-E-A-T explică de ce Google preferă semnalele clare de autoritate față de arhitecturi de URL-uri ambigue.
- Strategia bilingvă a crawlerra.com folosește
SeoService.applyHome()șiapplyPrivacy()pentru paginile cu ambele versiuni lingvistice (emithreflang="ro",hreflang="en"șihreflang="x-default"), șiapplyArticle()curemoveAlternate("en")pentru conținut RO-only (emit doarhreflang="ro"șihreflang="x-default"spre același URL).[crawlerra.hreflang_strategy]
Întrebări frecvente
rel=canonical e același lucru cu un redirect 301?
Nu. Canonical este un semnal pentru motoarele de căutare, nu o redirecționare pentru utilizatori. Un 301 mută traficul real; utilizatorul aterizează pe URL-ul destinație. Canonical lasă utilizatorul pe URL-ul accesibil, dar spune Google care versiune să indexeze și să consolideze în ranking. Dacă vrei să elimini complet o variantă duplicat, 301 e mai puternic. Dacă varianta trebuie să rămână accesibilă (de exemplu, o pagină de produs cu parametri de urmărire), canonical e soluția corectă.
Google este obligat să respecte canonical-ul?
Nu. rel=canonical este un semnal puternic, nu o directivă absolută. Google poate alege să ignore canonical-ul dacă alte semnale (linkuri interne, sitemap, conținut) contrazic declarația. Un canonical corect, consistent cu restul semnalelor, este respectat în marea majoritate a cazurilor. Un canonical contradictory cu hreflang sau cu sitemap-ul poate fi ignorat fără avertisment.
Pot pune canonical pe o pagină spre o altă pagină cu conținut diferit?
Nu ar trebui. Canonical declară „această pagină este varianta preferată a acelui conținut", nu „vreau ca pagina aceea să preia tot link equity-ul meu". Dacă conținuturile diferă substanțial, Google poate ignora canonical-ul. Folosește canonical numai pentru variante care sunt cu adevărat similare sau identice (parametri URL, sesiuni, paginare).
Canonical afectează indexarea paginilor care nu sunt canonice?
Da. Paginile non-canonice pot fi șterse din index sau consolidate în spatele celei canonice. Aceasta este exact scopul: consolidezi semnalele de ranking pe o singură URL. Paginile pe care le marchezi ca non-canonice pot apărea ca „Pagini duplicate, Google a ales o variantă diferită" în Search Console.
Canonical și noindex pot coexista pe aceeași pagină?
Tehnic da, dar este un anti-pattern cu consecințe imprevizibile. noindex spune Google să nu indexeze pagina. Canonical spune Google că indexarea ar trebui consolidată pe altă URL. Cele două semnale se contrazic: dacă nu trebuie indexată, nu ai de ce să declari o variantă canonică. În practică, Google poate alege să aplice noindex-ul și să ignore canonical-ul.