Блог на Васил Тошков

rel=canonical vs. Content-Location HTTP header

Знам, че заглавието изглежда малко стряскащо, но ще се опитам да обясня всичко простичко в следващите редове.

Историята започва преди няколко години, когато търсачките приеха canonical tag-a с цел да се дава информация на машините кой е каноничният адрес на дадено съдържание, което се повтаря в рамките на един сайт. Примерно, ако имаме страница за принтиране, тя да връща canonical към реалната страница, където се намира съдържанието.

<link src="http://www.example.com/page/" rel="canonical" />

Наричат го canonical tag, въпреки че далеч не е таг, а просто релация на връзка. Идеята за подобен инструмент е наистина добра и върши много работа. Обаче с времето се появиха някои сериозни проблеми, примерно с цел да не се злоупотребява, се наложи тази релация да работи само поставена в <link> таг в <head> частта на документа.

Появи се и друг проблем - тъй като се разчита на HTML таг, canonical не може да се използва за други типове документи, различни от HTML. Примерно ако имаме опция съдържанието на дадена страница да се свали като PDF, то нямаше как да сложим на този PDF canonical таг към оригиналната страница на съдържанието. Тоест, технологията не работи във всички случаи.

От Google веднага реагираха и създадоха HTTP хедър за целта, изглеждащ така:

Link: <http://www.example.com/page/>; rel="canonical"

Не се искат много технически познания, за да види човек, че тук нещо не е наред. Аз съм го видял отдавна и знаех, че този момент ще настъпи един ден. Причината е в това, че още от зората на Интернет има решение на най-ниско ниво за този проблем и то се нарича Content-Location HTTP header. Тоест, има утвърден стандарт и винаги го е имало.

Content-Location: http://www.example.com/page/

Изглежда много по-красиво, нали? И следва да работи на всички системи, защото съществува от създаването на Интернет. Творението на Google би работило само за Google, защото те са си го измислили. Да не говорим колко е труден за интеграция техния вариант с тези скоби и кавички в него. Въобще, за какво им трябваше да изобретяват колелото наново, като то вече е изобретено?

Обяснение от тяхна страна има и то е, че към момента съществували сайтове, които използвали Content-Location по неправилен начин и щели да се счупят. За мен обаче това не е сериозно, защото логиката трябва да е в това да се стимулират добрите практики, а не да се съобразяваме с лошите такива. А и аз честно не го вярвам това, че някои ще използва точно този хедър и то неправилно.

Пиша тази статия просто като един от многото примери, при които Google не спазват стандартите, а се опитват да наложат собствени такива. Това не ми харесва, а и практиката е показала, че с годините подобни неща не успяват да се наложат за сметка на стандарта, просто водят до обърквания и забавяне на развитието на Интернет.

Мога да дам още много примери, но този е най-простият. В негова връзка ще кажа и че самия факт, че rel=canonical трябва да се поставя само в <head> също е нарушение на стандартите. Релациите следва да се поставят на всички възможни връзки. Щом има рискове за сигурността, тогава не е трябвало изобщо да се въвежда canonical, HTTP протоколът би бил достатъчен за тази функционалност.

И други мислят като мен по конкретния въпрос. Интересно ще ми е да чуя и още мнения.