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 asistir a los motores de búsqueda a seleccionar cuál es el contenido original y dejarles identificar adecuadamente el transmisor original de este.
El canonical y otras etiquetas
El canonical es una directiva de aconsejable cumplimiento, pero no es de obligado cumplimiento, pues ya han avisado más de cuando si las señales son claras en otro sentido, mostrarán como contenido primordial una URL si bien esta tenga el canonical a otra a su vez… Si necesitas más información,podeis localizarla.
En general, se aconseja el uso del rel canonical ante los siguientes 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, definir cuál es el dominio emisor del contenido.
- Ante una coexistencia de protocolos diferentes (http, https) o bien fallos en la construcción del dominio (www. y sin www) o bien ante dominios diferentes (senormunoz.es y senormunoz.com, ambos abiertos a indexación y los dos con el mismo contenido)
En este artículo os vamos a mostrar 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 manera de apuntar al buscador que estamos frente a una paginación de contenidos. Es decir: el contenido se desperdigada en diversas URLs que tienen un orden específico. El beneficio reside en apuntarle al buscador cómo debe gestionar el contenido de una página. Tiene 2 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 emplearlo conjuntamente con rel=prev y rel=next cuando precisemos establecer la versión canónica de las paginaciones, por poner un ejemplo, cuando encontremos 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á desaconsejado, por 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 un caso así, un parámetro como es numitems, que no requiere de posicionamiento) a la URL sin más parámetros que la pura paginación. Si tenemos una paginación con URL agregadora, las distintas 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, en tanto 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, pero veamos antes qué es el hreflang.
2.1. hreflang
El hreflang es la manera de apuntar al buscador que dos páginas son iguales pero enfocadas a 1) países diferentes dos) idiomas diferentes tres) países y también idiomas diferentes. Se basa en elEl beneficio es claro: puedes orientar a diferentes mercados con el mismo idioma. El hreflang lo que busca es ayudar a determinar qué URL ranquea por una palabra en un determinado idioma o país o bien país e idioma. El hreflang tiene dos consideraciones :
- debe tener URL de vuelta (esto es, 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 dos) no varía el contenido (ejemplo: id de sesión) y, además, 3) no es preciso para nuestra indexación porque no nos interesa indexar esa URL (ejemplo: en la URL de turismos enseñar únicamente los SEAT podríamos querer indexar esa URL para posicionar por “coches SEAT”)
no lleva hreflang, pero
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 apuntarle 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 comienzo lo mandábamos a una URL de desambiguación pero con el tiempo se ha aceptado 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 antes, siempre y en toda circunstancia debe coincidir la URL canonical con una de las URLs de hreflang (y lo comentó John Mueller en). En este caso de ejemplo el canonical se apunta a sí mismo en todas y cada una de las versiones, en tanto 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 exactamente 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 recapacitar)
Antes, un vídeo dehablando del tema
Como íbamos diciendo, estamos en una situación especial, donde tenemos que esclarecer qué hacemos en el caso que sean copias de contenidos en el mismo idioma. desarrollo pagina web ibiza una situación tal que la siguiente: el contenido original lo genera 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ú, México y Argentina) con 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 com.mx), de ahí que el dominio.com es el que lleva los x-default.
rel=canonical con el mismo idioma y diferentes paises pero x-default y hreflang
La clave está en que, como veis, todos y cada uno de los dominios, de nuevo, se autorenferencian con el canonical (como pasaba en caso de que los contenidos fuesen 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 coche de Homer Simpson, el Plymouth Junkerolla de mil novecientos ochenta y seis. Como somos un medio distribuido, este contenido se publica, igual al 100 por ciento en Argentina y México. Cambiamos en los titles y descriptions Homer por Homero y coche por auto o bien 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 un caso así decidimos apuntar con un canonical a la versión de España desde los posts de Argentina y México pues consideramos que es la versión original y el resto copias. Además, así, reforzaríamos la posición del artículo español, de la página web español, que es la que nos interesa.
Este sería el ejemplo.
Según el ensayo, en un caso así 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 pero 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 pero la URL de la versión mexicana.
Por eso es esencial decidir correctamente como se establecen los canonicals.
El ensayo de Sergio Redondo
Así puesto que, mi compañerohizo el mismo test con afines resultados. agencia de analítica web madrid 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 (esto es, 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 exactamente 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 Accelerated Mobile Pages) es una forma de enseñar los contenidos de tu página web de manera más rápida, en tanto que su objetivo es prosperar 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 la perspectiva de este artículo es que acostumbras a tener el contenido AMP en tu propio dominio, pero Google tiene su URL que es la que aparece en el bloque de news (que te hace un 302, por cierto)
4.2. Canonical + amp
No hay variación del objetivo, en tanto 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 la más mínima 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 Search Engines Ranking Positions). Esta hace unaa la URL de canonical. No es relevante, puesto que no tenemos nosotros 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 página web, donde presentemos nuestro html optimado para servicios móviles. Es una convención (ojo, no escrita, es como el clicar en el logotipo, que te lleva siempre y en toda circunstancia a la home) que la versión móvil de una web esté en el subdominio m. del dominio primordial, 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 el mismo contenido, pero nos dejan ciertas licencias que en la versión desktop no:(toda vez que 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, pero 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, por su parte, apuntar mediante canonical a la desktop, puesto que es la principal ¿Por qué no se referencian la versión mobile y la versión amp? Pues 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 utiliza ante determinados contenidos que no nos interesa que se posicione, aquellos que no nos interesan que se indexen o ante una limpieza de URLs por panda, por servirnos de 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 la misma URL, vamos a estar dando una señal errónea al buscador:
Ey, no me indexes pero, ey, yo soy la URL original. Si quereis mas info podéis comprobar esta entrada del weblog donde charlamos sobre qué pasó con la. Al tener un canonical lo que le estás diciendo al buscador es que las dos URLs son equivalentes (justo lo opuesto del noindex).
El consejo es el siguiente:
que no aparezcan en la misma URL, elegir una de las dos. Si deseas 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 bien 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 género de unificación se acostumbra a hablar de bloquear a través de el robots.txt determinadas URLs. O sea, 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 porque presenta una situación de duplicación de contenidos. Mas si impedimos al robot acceder a esa URL, no lograremos 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 bien 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 pues 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 ya tenemos indizada y queremos 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 motores de búsqueda 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 lugar) Reescribo y actualizo: veinte de Julio del dos mil diecisiete, que en los comentarios (
gracias Christian, gracias Jose María, gracias Kico) están diciendo cosas absolutamente 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. Por 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) Quitar el disallow para que Google entre 3) 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 de nuevo el disallow.
Y si ella fuera la original y tuviese que autoreferenciarse con el canonical no conseguiríamos sacarla del índice (pues es la original)
