El empleo del canonical con otras etiquetas
El
canonicales una directiva máquina, trabajada como etiqueta <meta>, que se pone en el campo <head>, apoyada por bing!, Google y Yahoo e concebida para trabajar el contenido duplicado, indicando en ella cuál es el contenido original. Natural de el dos mil nueve en pleno apogeo de la sindicación de contenidos, es una forma de ayudar a los buscadores web a escoger cuál es el contenido original y dejarles identificar correctamente el transmisor original de este.
El canonical y otras etiquetas
El canonical es una directiva de recomendable cumplimiento, pero no es de obligado cumplimiento, porque ya han sobre aviso más de cuando si las señales son claras en otro sentido, mostrarán como contenido principal una URL si bien esta tenga el canonical a otra a su vez… Si necesitas más información,podeis localizarla.
En general, se recomienda el uso del rel canonical ante los próximos escenarios:
- Ante diferentes URLs (sobre todo aquellas que están identificadas con parámetros) decirle a la máquina cuál es la original.
- Ante una sindicación de contenidos, acotar cuál es el dominio emisor del contenido.
- Ante una coexistencia de protocolos diferentes (http, https) o bien errores en la construcción del dominio (www. y sin www) o ante dominios diferentes (senormunoz.es y senormunoz.com, los dos abiertos a indexación y ambos con el mismo contenido)
En este artículo os mostraremos diferentes posibilidades para permitir la coexistencia, o bien no, de una meta etiqueta rel canonical con otras meta etiquetas como son la rel=prev y rel=next, rel=noindex, amphtml, alternate móvil,…
canonical amp alternate rel prev rel next xreflang hreflang
1. Canonical con rel=prev y rel=next
1.1. rel=prev y rel=next
La directiva rel=prev y rel=next es la forma de apuntar al buscador que estamos ante una paginación de contenidos. Es decir: el contenido se dispersa en diversas URLs que tienen un orden específico. El beneficio radica en señalarle al buscador cómo debe administrar el contenido de una página. Tiene dos escenarios:
- una paginación sin URL que tenga todos y cada uno de los contenidos agregados
- una paginación con URL que tenga todos los contenidos agregados.
1.2. rel=prev, rel=next y canonical
1)Si tenemos una paginación sin URL agregadora, solo llevará el rel=prev y el rel=next. No tiene por qué llevar rel=canonical.
rel=canonical con paginación, rel=prev y rel=next
2)El canonical podemos usarlo juntamente con rel=prev y rel=next cuando precisemos establecer la versión canónica de las paginaciones, por servirnos de un ejemplo, cuando hallemos parámetros en estas URLs.
rel=canonical con paginación rel=prev y rel=next y el canonical a sí misma.
Si bien esta opción no es relevante o no está aconsejada de modo expreso en, tampoco está contraindicado, con lo que puedes ponerlo o no.
3)El canonical y la paginación cruzada entre páginas y listados consecutivos debemos apuntar las canonicals desde las URLs con parámetros y paginación a la URL sin parámetros no paginados
Paginaciones y canónicasl con parámetros
4)Sin embargo la siguiente es mucho más normal, donde la paginación con parámetros (en este caso, un parámetro como es numitems, que no precisa de posicionamiento) a la URL sin más parámetros que la pura paginación. Si tenemos una paginación con URL agregadora, las diferentes paginaciones deberán incluir el rel=canonical a la versión agregadora
rel= canonical con paginación rel=prev y rel=next y URL que unifica todo el contenido.
2. Canonical con hreflang
Quizá una de las partes más complicadas, puesto que es interesante ver cómo el canonical y el hreflang, pudiendo coincidir, verdaderamente no trabajan juntos. Ya sabemos que el canonical se inventó para intentar pelear contra los contenidos duplicados, mas veamos ya antes qué es el hreflang.
2.1. hreflang
El hreflang es la forma de indicar al buscador que dos páginas son iguales pero enfocadas a 1) países diferentes dos) idiomas diferentes 3) países y también idiomas diferentes. Se fundamenta en elEl beneficio es claro: puedes orientar a diferentes mercados con exactamente el mismo idioma. El hreflang lo que busca es ayudar a determinar qué URL ranquea por una palabra en un determinado idioma o bien país o país y también idioma. El hreflang tiene dos consideraciones :
- debe tener URL de vuelta (es decir, si url-idioma1.htm apunta a url-idioma2.htm, desde url-idioma2.htm también debe apuntar a url-idioma1.htm
- debe apuntarse a sí mismo (url-idioma1.htm se apuntará con el hreflang correspondiente a url-idioma1.htm)
2.2. hreflang y canonical
- puede no existir el canonical
si existe el canonical
debecoincidir con el hreflang de la versión en la que estemos.
si hay una copia
nolleva hreflang, mas
sicanonical a la versión original.- si hay un parámetro que 1) debe ordenar el contenido (ejemplo: parámetro de ordenación) o bien 2) no varía el contenido (ejemplo: id de sesión) y, además, 3) no es preciso para nuestra indexación por el hecho de que no nos interesa indexar esa URL (ejemplo: en la URL de vehículos enseñar solamente los SEAT podríamos apreciar indexar esa URL para posicionar por “coches SEAT”)
no lleva hreflang, mas
si canonical a la URL sin parámetros.
rel=alternate hreflang de idioma y rel=canonical
3. Canonical con hreflang y xdefault
3.1. x-default
El parámetro x-default va en unión con el hreflang (no puede ir solo) y sirve para señalarle a google dónde nos gustaría que fuera un usuario que no está representado por ninguna de las URLs idiomáticas/paises/ambas. Al principio lo mandábamos a una URL de desambiguación mas con el tiempo se ha admitido también su uso para decirle al buscador: “ey, no tengo para esa combinación, así que muéstrale esta url”.
3.2. x-default y canonical
Como hemos dicho ya antes, siempre debe coincidir la URL canonical con una de las URLs de hreflang (y lo comentó John Mueller en). En este ejemplo el canonical se apunta a sí mismo en cada una de las versiones, ya que la versión UK y US son 2 URLs con contenido trabajado para cada uno de los países marcados y su respectivo idioma (en-UK y en-US).
rel=alternate hreflang x-default y canonical
3.3. hreflang, canonical y la sindicación de contenidos en el mismo idioma entre portales
Sin embargo hay un caso en el que el obvio uso del canonical no es cómo se espera. Esto (os cuento un secreto, ha costado varios días de discusión entre, un servidor y con la ayuda especial de,,,,,y, a los que doy las gracias por aguantarme y hacerme reflexionar)
Antes, un video dehablando del tema
Como íbamos diciendo, estamos en una situación singular, donde tenemos que esclarecer qué hacemos en el caso que sean copias de contenidos en exactamente el mismo idioma. Imaginemos una situación tal que la siguiente: el contenido original lo produce una web en España, que se copia,
exactamente, en las webs de Perú, México y Argentina (es indiferente si es un dominio con subcarpetas idiomáticas, un dominio con subdominios idiomáticos o diferentes dominios para cada uno de ellos de los países). Se ha decidido, además, que la web con el dominio terminado en .com sea la web relevante para cualquier búsqueda fuera de los países indicados (Perú, Mexico y Argentina) por lo que si un buscante hace la búsqueda en google.co (Google Colombia) lo que Google debería mostrarle es el resultado del dominio .com y no el dominio.pe, com.ar o bien com.mx), de ahí que el dominio.com es el que lleva los x-default.
rel=canonical con exactamente el mismo idioma y diferentes paises mas x-default y hreflang
diseño de webs responsive en canet clave está en que, como veis, todos los dominios, de nuevo, se autorenferencian con el canonical (como pasaba en caso de que los contenidos fueran en otros idiomas).
El ensayo de distilled
En la prueba que distilled hizo resultaba que, si poníamos el canonical de todas las webs que copian el contenido de la URL original cara esta URL original, los resultados en las Search Engines Ranking Positions del buscador eran:
- title de la URL original
- description de la URL original
- URL del país en el que se hacía la búsqueda, que tenía canonical a la versión original.
imaginemos un blog post escrito en la versión de España sobre el vehículo de Homer Simpson, el Plymouth Junkerolla de 1986. Como somos un medio distribuido, este contenido se publica, igual al cien por cien en Argentina y México. Cambiamos en los titles y descriptions Homer por Homero y coche por auto o carro. Eso es lo único que se hace.
Siguiendo el ejemplo anterior lo correcto sería que cada una de las versiones hiciese canonical a si misma, además del hreflang respectivo.
Pero en este caso decidimos apuntar con un canonical a la versión de España desde los posts de Argentina y México porque consideramos que es la versión original y el resto copias. Además, así, reforzaríamos la posición del post español, de la página web español, que es la que nos resulta de interés.
Este sería el ejemplo.
Según el ensayo, en este caso se producirían las siguientes opciones.
- Si el buscante está en España, le aparecerá la URL españa.com/coches con su title y su description.
- Si el buscante está en Argentina, le aparecerá el title y la description de la versión española mas la URL de la versión argentina.
- Si el buscante está en México, le aparecerá el title y la description de la versión española mas la URL de la versión mexicana.
Por eso es esencial decidir adecuadamente como se agencia de marketing online en valencia los canonicals.
El ensayo de Sergio Redondo
Así puesto que, mi compañerohizo el mismo test con afines resultados. Se trata de un test donde hemos probado a ver que ocurre cuando en un proyecto multipaís, el canonical no coincide con el hreflang de la versión local en la que estamos (es decir, los canonicals apuntan al contenido original)..
Resultado de la.es:
- Title de la URL que recibe el canonical (URL original)
- Description de la URL que recibe el canonical (URL original)
- URL de la versión local
- La caché que muestra es la caché de la página canónica, la que recibe el canonical
Además,sobre el mismo trabajo: Cuando el hreflang x-default no coincide con la URL canónica nos muestra lo siguiente:
- Title de la URL que recibe el canonical (URL original)
- Description de la URL que recibe el canonical (URL original)
- URL del hrefllang x-default
- La caché que muestra es la caché de la página canónica.
4. Canonical con amp
4.1. amp
AMP (o bien Accelerated Mobile Pages) es una forma de enseñar los contenidos de tu página web de forma más rápida, puesto que su objetivo es mejorar el desempeño de las páginas (performance y velocidad) en el empleo de la página web desde dispositivos móviles. Está montado cerca de 1) AMP HTML (componentes mínimos) dos) AMP JS (código javascript mínimo) y 3) cachés (a través de CDNs). Lo más relevante desde el punto de vista de este artículo es que acostumbras a tener el contenido AMP en tu propio dominio, mas Google tiene su propia URL que es la que aparece en el bloque de news (que te hace un trescientos dos, por cierto)
4.2. Canonical + amp
No hay variación del objetivo, puesto que la directiva canonical debe aplicarse del mismo modo y desde la desktop se debe apuntar a la amp. ¿Qué pasará con el índice mobile first cuando salga? Ni idea.
- versión amp apuntando canonical a la versión desktop
- versión desktop apuntando con directiva rel amphtml a la versión amp
- en caso que google muestre su URL (lo normal) esta, por defecto, tiene un canonical apuntando a la versión amp de nuestra web.
rel=canonical y amp html con la URL de google que aparece por defecto.
En el ejemplo se muestra qué hace la versión de amp de google (que es la que aparece desde las SERPs). Esta hace unaa la URL de canonical. No es relevante, ya que no tenemos control sobre ella.
5. Canonical con versión móvil
5.1. Versión móvil
Podemos tener una versión móvil de nuestra web, donde presentemos nuestro html optimado para servicios móviles. Es una convención (ojo, no escrita, es como el clicar en el logo, que te lleva siempre a la home) que la versión móvil de una web esté en el subdominio m. del dominio principal, pero no es obligatorio (hasta otros dominios hemos visto para la versión móvil). En la versión móvil de la web deberá existir exactamente el mismo contenido, mas nos permiten ciertas licencias que en la versión desktop no:(siempre y cuando estén presentes)
5.2. móvil + canonical
rel alternate mobile y rel=canonical
5.3. Canonical con amp y versión móvil
Una situación difícil de darse hoy en día, mas que si aparece, tiene fácil solución, en tanto que la URL de desktop tendría que apuntar con sus respectivos alternate (versión mobile y versión amp) a las URLs correspondientes y estas versiones, a su vez, apuntar a través de canonical a la desktop, ya que es la principal ¿Por qué no se referencian la versión mobile y la versión amp? Porque verdaderamente la versión que debe tener los alternativos es la desktop. m.coches.html no es la versión opción alternativa móvil a amp.coches.html (ni viceversa).
rel=”canonical”, rel alternate mobille y rel amp html
6. Canonical con noindex
6.1. noindex
El noindex a nivel de meta le solicita a Google que no indexe la URL. Se usa ante determinados contenidos que no nos interesa que se posicione, aquellos que no nos resultan de interés que se indexen o bien frente a una limpieza de URLs por panda, por poner un ejemplo, para marcar aquellas URLs de baja calidad,…
6.2. noindex y canonical:
Entonces ¿Puedo unir la etiqueta noindex y la etiqueta canonical en la misma URL? Cuando unimos las dos etiquetas en exactamente la misma URL, estaremos dando una señal errónea al buscador:
Ey, no me indexes pero, ey, yo soy la URL original. Si quereis pero info podéis comprobar esta entrada del blog donde hablamos sobre qué pasó con la. Al tener un canonical lo que le estás diciendo al buscador es que las 2 URLs son equivalentes (justo lo opuesto del noindex).
El consejo es el siguiente:
que no aparezcan en exactamente la misma URL, elegir una de las dos. Si quieres asegurarte la desindexación de una URL ya indexada,
quítale el canonical y márcala con un noindex. Si tienes urls diferentes (2 o más) y el contenido es cien por cien igual te resulta interesante insertar el canonical y si tienes URLs que no te interesan que se indexen, utiliza el noindex.
7. Canonical con robots.txt
En este tipo de unificación se suele hablar de bloquear a través de el robots.txt determinadas URLs. Esto es, meter en el robots.txt un disallow:/algunaCarpeta
Al igual que en el punto precedente, no se aconseja unir la directiva disallow del robots.txt al canonical. Si debemos poner una directiva canonical en una determinada URL es por el hecho de que presenta una situación de duplicación de contenidos. Pero si impedimos al robot acceder a esa URL, no conseguiremos que sepa que ahí hay un contenido que deseamos “canonicalizar” a alguna URL. Si marcamos la URL con noindex a través de robots.txt o impedimos al buscador acceder a esa URL, esa URL, que puede estar ya indexada por Google, aún ranquee por una determinada palabra clave.
Si bloqueamos algo con robots.txt es porque no deseamos que Google rastree esa URL. La pregunta es
¿Y si deseo que esa URL se indexe?. Ejemplo: imaginemos la URL de aviso legal que tenemos indizada y deseamos sostener en el índice. Esta hace canonical a si misma. Lo que pasa es que la bloqueo a fin de que no se pasee Google por allí, con lo que le pongo el disallow.
7.1. Anexo: ¿Disallow previene de indexación?
Tener una etiqueta noindex no impide a los buscadores web la indexación. En el próximo ejemplo veis una muestra de lo que os estamos contando. Esta URL tiene un noindex marcado, hace un metarefresh y un trescientos dos a la nueva URL, pero está rankeando (probablemente por la autoridad del sitio) Reescribo y actualizo: 20 de Julio del 2017, que en los comentarios (
gracias Christian, gracias Jose María, gracias Kico) están diciendo cosas completamente lógicas. Modifico el título a “Disallow” (antes ponía noindex)
URL con disallow y ranqueando en Google
Esta URL está bloqueada mediante el robots.txt. Es decir: google no puede acceder a ella. Con lo que si quisiéramos utilizar un canonical aquí google no podría verlo.
En el caso que quisieramos canonicalizar esta URL a otra tendríamos que 1) Poner en esta URL la directiva canonical dos) Eliminar el disallow para que Google entre tres) Que google actualice su caché y descubra el canonical a la URL correcta. Y cuando descubramos que google ya muestra la URL original entonces 4) pondríamos nuevamente el disallow.
Y si fuera la original y tuviese que autoreferenciarse con el canonical no conseguiríamos sacarla del índice (porque es la original)
