Resumen

  • En febrero de 2009, Google ofreció a los sitios una línea de HTML para señalar la URL preferida entre páginas duplicadas: rel="canonical". La presentó como una pista fuerte, sujeta a otras señales. El editor nominaba; el índice conservaba la decisión.
  • El RFC 6596 advirtió después que enviar la segunda página de un artículo a la primera como canónica podía hacer que su contenido propio se tratara como duplicado. Una etiqueta pensada para ordenar direcciones podía borrar texto de la búsqueda.

Una tienda, demasiadas direcciones

Una ficha de producto podía aparecer con la URL limpia, otra con un parámetro de categoría, otra con seguimiento publicitario y otra con un identificador de sesión. La mercancía era la misma; las direcciones se multiplicaban. Google explicó el problema con una tienda de caramelos en su anuncio del 12 de febrero de 2009. La solución consistía en añadir <link rel="canonical" href="..."> al encabezado HTML de las páginas duplicadas para indicar cuál debía representar al conjunto.

Aquella línea no cambiaba la dirección que el visitante abría ni enviaba una respuesta de redirección. Hablaba con el buscador. Google dijo que las señales de enlaces podían concentrarse en la URL preferida. También respondió a la pregunta que decidía quién mandaba: ¿orden o sugerencia? Una sugerencia fuerte, evaluada junto a otros indicios. El sitio conocía las variantes que había creado; el motor conocía sus rastreos y agrupaciones. El webmaster recibía una papeleta, no la mesa de escrutinio.

El mismo anuncio conserva una frontera temporal. Al principio Google aceptaba la sugerencia entre subdominios, pero no entre dominios completamente distintos; para cambiar de dominio recomendaba una redirección permanente. Una actualización fechada el 17 de diciembre de 2009 anunció después el soporte entre dominios. La ampliación no debe atribuirse al lanzamiento de febrero.

La relación y su coste oculto

En abril de 2012, el RFC 6596 definió canonical como la relación que señala una IRI preferida cuando el contenido es duplicado o la página de destino contiene todo el material de la página de origen. Permitió expresarla en HTML y en una cabecera HTTP Link. Un programa podía concentrar propiedades de enlaces, mostrar la dirección elegida y procesar únicamente el destino. El RFC describía las consecuencias posibles de la relación; no obligaba a cada buscador a obedecer una declaración concreta.

Su ejemplo de un artículo dividido en páginas explica por qué importaba el requisito de contenido. La página dos aporta párrafos ausentes de la primera. Una versión de lectura completa reúne ambas. Si cada página señala a la versión completa, el destino contiene todo lo que promete. Si la segunda señala a la primera, el editor afirma una equivalencia que no existe. El RFC advierte que los párrafos de la segunda podrían descartarse como duplicados. Para un lector la página seguiría abriendo; para el índice, parte de la historia podría haber desaparecido.

El documento recomienda una sola relación canonical por recurso y desaconseja destinos que devuelvan errores, redirijan de forma permanente o formen cadenas. Cuando la indicación es defectuosa, el programa puede ignorarla y aplicar sus propias reglas. La explicación actual de Google mantiene esa separación: agrupa páginas similares y puede elegir una representante distinta de la propuesta por el sitio. La documentación actual no cambia la fecha del origen; muestra que el límite anunciado en 2009 sigue siendo central.