Tengo algunas páginas duplicadas en mi dominio y necesito hacer referencia a la etiqueta canonical de las páginas duplicadas hacia la página original usando JavaScript. (Eliminar las páginas duplicadas no es una opción, ya que tienen un tráfico considerable). ¿Alguien podría sugerir cómo actualizar una etiqueta href usando JavaScript en Discourse?
Aquí tienes, @KranthiKiranGude, así es como puedes cambiar el atributo href en JavaScript. Primero seleccionas el elemento del DOM y luego modificas el atributo.
<script>
var uC = document.querySelectorAll("link[rel='canonical']")[0];
var newURL = "https://my.coolforum.com/newlink";
uC.setAttribute("href", newURL);
</script>
Por supuesto, necesitarás cierta lógica basada en la página en la que quieras operar.
Lógica de ejemplo genérica:
<script>
if("the_actual_page_url_or_id" == "my_interesting_page_url_or_id")
{
var uC = document.querySelectorAll("link[rel='canonical']")[0];
var newURL = "https://my.coolforum.com/newlink";
uC.setAttribute("href", newURL);
}
</script>
Espero que esto ayude.
1 me gusta
Hola @neounix,
He probado tu código, pero en lugar de actualizar el href, se generó una nueva etiqueta script:
He actualizado este script en la sección “/head”.
1 me gusta
Hola @KranthiKiranGude
Por favor, publica el código exacto que utilizaste y dónde exactamente lo agregaste, incluyendo una captura de pantalla de la entrada en la sección </head> que mencionaste.
¡Gracias!
Es normal que se genere nuevo Javascript cuando agregas más Javascript.
Por cierto, necesitarás verificar el DOM en la consola de desarrollo web (los elementos), no en el código fuente de la página.
1 me gusta
1 me gusta
Entiendo.
Por cierto, te falta una comilla de apertura en tu declaración condicional del script…
1 me gusta
Hola @neounix,
Funcionó en la Consola de Desarrollo. Sin embargo, en el Código Fuente de la Página sigue haciendo referencia a la URL real.
Si no estoy equivocado, los motores de búsqueda extraen la información del Código Fuente de la Página, no de los elementos del DOM. Por favor, corrígeme si me equivoco.
1 me gusta
La verdad, no estoy seguro de eso. Antes pensé que los motores de búsqueda modernos (GoogleBot) leían el DOM, pero ahora que lo pienso, tiene sentido que los motores de búsqueda solo lean el código fuente y no el DOM.
Pero… cuando busqué en Google para verificar esto, dice:
Las señales de SEO en el DOM (títulos de página, meta descripciones, etiquetas canónicas, etiquetas meta robots, etc.) son respetadas. El contenido insertado dinámicamente en el DOM también es rastreable e indexable. Además, en ciertos casos, las señales del DOM pueden incluso tener prioridad sobre declaraciones contradictorias en el código fuente HTML. Esto requerirá más trabajo, pero fue el caso en varias de nuestras pruebas.
Referencia:
https://searchengineland.com/tested-googlebot-crawls-javascript-heres-learned-220157
1 me gusta
Hola @neounix,
Muchas gracias por tu ayuda. Déjame investigar también sobre esta parte. Pero, de verdad, te agradezco mucho.
1 me gusta
¡Bienvenido!
Por favor, vuelve a publicar y cuéntanos los resultados de tu investigación.
Otro método, en el que he estado trabajando en mi tiempo libre recientemente, es modificar directamente este archivo de la biblioteca Ruby de Discourse:
Podrías considerar algo en esa línea si la técnica de manipulación del DOM con JS no te da resultados, @KranthiKiranGude
1 me gusta
Hola @neounix,
Probé la página usando la herramienta Inspección de URL; Google está reconociendo la URL actualizada.
2 Me gusta
Perfecto… me alegra saber que funcionó.
Gracias por probar y compartir los resultados.
PD: Ese método de DOM en JS es mucho más fácil que manipular canonical_url.rb 
1 me gusta
No estoy seguro de que sobrescribir el canónico usando JavaScript funcione, ya que esto es algo que ocurre más a nivel de araña (es decir, la parte que recupera y recopila datos) que a nivel de indexador (la parte de un bot que interpreta los datos y los almacena en el índice de búsqueda).
Consejo no solicitado: quizás quieras leer este tema para que puedas colocar esas sobrescrituras en un plugin:
2 Me gusta
Sí, yo tampoco. Aún no hay una conclusión definitiva al respecto.
Sin embargo, las búsquedas de Google sobre este tema arrojan muchos resultados, donde muchas personas lo hacen y muchas afirman que Google respeta los cambios en el DOM (aunque otras dicen que no, por lo que parece no haber un consenso fuerte y abrumador sobre el tema). Por ejemplo, consulta:
Creo que si fuera a hacerlo, (1) eliminaría la etiqueta canonical original del código fuente de la página y luego (2) insertaría una nueva etiqueta canonical en el DOM con JavaScript.
Luego, con el tiempo, simplemente podemos revisar la Consola de búsqueda de Google y ver qué eligió Google como canonical.
También consulta:
1 me gusta
Dado que muchas personas consideran que esto es importante para el SEO, volví a verificarlo a la luz de esta confirmación de @KranthiKiranGude:
Según developers.google.com, Comprende los conceptos básicos de SEO para JavaScript:
Googlebot admite componentes web. Cuando Googlebot renderiza una página, aplana el contenido del DOM sombreado y del DOM ligero. Esto significa que Googlebot solo puede ver el contenido que es visible en el HTML renderizado. Para asegurarte de que Googlebot siga viendo tu contenido después de que se renderice, utiliza la prueba de compatibilidad con móviles o la herramienta de inspección de URL y examina el HTML renderizado.
Dado que (1) @KranthiKiranGude utilizó su herramienta de Inspección de URL en sus pruebas y (2) confirmó que la etiqueta canónica se cambió como se esperaba de esta manera, se deduce que, según Google, GoogleBot sí “ve” y registra este cambio en el contenido del DOM después de que se renderiza la página.
Referencia:
1 me gusta
Sí, apoyo totalmente la idea de que Google aplane el contenido del DOM de esa manera durante la indexación.
Pero algunos/la mayoría de las etiquetas meta tienen su semántica a nivel del protocolo HTTP en lugar de a nivel del protocolo HTML, a pesar de que están presentes en el HTML. Enfatizé ‘durante la indexación’ porque no estoy seguro de que aplane el DOM de esa manera y tenga en cuenta la URL canónica actualizada durante el rastreo.
(Para decirlo de otra manera, no estoy seguro de si el contenido del DOM también incluye ‘metadatos incrustados en el contenido’. Sí, lo ve de esa manera, pero no estoy seguro de si lo usará de esa manera).
Quizás este artículo lo explique mejor: How Google Crawls Your Website and Indexes Your Content
Cuando Google necesita rastrear sitios de JavaScript, se requiere una etapa adicional que el contenido HTML tradicional no necesita. Se conoce como la etapa de renderizado, lo cual toma tiempo adicional. La etapa de indexación y la etapa de renderizado son fases separadas, lo que permite a Google indexar primero el contenido no basado en JavaScript
.
1 me gusta
En realidad no, lo siento. Ese artículo de www.hillwebcreations.com ni siquiera menciona el DOM, cómo inspeccionarlo, etc., y al menos para mí, se lee como “anticuado y subjetivo” (no está actualizado ni es factual).
Personalmente, prefiero estas dos referencias bien redactadas, ambas con más autoridad, factuales y bien referenciadas, en mi opinión:
y la primera, donde realmente realizaron pruebas (y eso fue mucho antes de que GoogleBot cambiara a un núcleo Chromium que podía leer el DOM (JavaScript) incluso mejor):
Probamos cómo Googlebot rastrea JavaScript y esto es lo que aprendimos
Después de mi investigación, tiendo a estar de acuerdo con los desarrolladores de Google en que indexarán (y obtendrán sus señales de SEO) lo que se encuentre utilizando la Herramienta de Inspección de URL, y es a partir de esto que podemos “juzgar” las señales de SEO y el contenido. La discusión de Google es clara, factual, autoritativa y no especulativa.
Dado que @KranthiKiranGude ha confirmado que su enlace canónico se actualizó usando la Herramienta de Inspección de URL, la cual, según Google, la autoridad, es “todo lo que necesitas” para ver cómo Google ve una página desde una perspectiva de SEO.
Resumen técnico
Debido a que Google utiliza señales de SEO de lo que se puede ver en su Herramienta de Inspección de URL; y el hecho de que los Desarrolladores de Google han declarado claramente que sus señales de SEO pueden analizarse directamente mediante la Herramienta de Inspección de URL; y el hecho de que los cambios en JS que @KranthiKiranGude realizó en el DOM son visibles en la Herramienta de Inspección de URL, eso es “más que suficiente”, en mi opinión.
Espero que esto ayude.
1 me gusta
Sí, ese artículo indica claramente que han visto que las etiquetas canónicas insertadas dinámicamente se comportan exactamente igual que si estuvieran en el código fuente. Tienes razón (y debería haberlo leído con más detenimiento la primera vez que lo publicaste).
Aunque tres de las cuatro páginas a las que te referiste en este tema, incluida la que nos dio la respuesta, son incluso más antiguas que ese artículo que publiqué 
Por cierto, @RGJ, perdón por la confusión con lo de “no actual”…
Cuando uso los términos “anticuado” o “no actual”, me refiero a conceptos e ideas, no a la fecha física de ningún artículo.
Algunas personas escriben artículos con fechas de “hoy” y los conceptos son “anticuados” (y erróneos), mientras que otras han escrito artículos hace 10 años que siguen siendo muy relevantes hoy en día.
Eso es lo que quiero decir con “anticuado” o “no actual”: se basa en “conceptos”, no en las fechas físicas escritas en papel o en un artículo web. Perdón por cualquier confusión al usar los términos de esta manera en mi respuesta.
Lo importante, al menos en mi opinión, es que proporcionamos una solución a @KranthiKiranGude, quien confirmó que funciona, y basándonos en tu publicación escéptica, ambos realizamos una investigación adicional sobre este problema.
Verificamos (1) que este método, cambiar el enlace canónico usando JavaScript, es válido; (2) que los desarrolladores de Google lo han confirmado; y (3) que tenemos una forma de confirmarlo como usuarios, utilizando la Herramienta de Inspección de URL (como hizo @KranthiKiranGude y compartió con nosotros).
¡Muchas gracias y lo mejor para todos por este “vaivén” en este tema tan interesante y por ayudar a hacer la solución aún más válida y sólida.
Me voy a otras tareas (aún luchando por aprender Ruby on Rails después de más de una década programando en PHP); ya que este tema está completamente “misión cumplida”
Hasta la próxima… ¡lo mejor para todos!
1 me gusta