Tenho algumas páginas duplicadas no meu domínio e preciso referenciar a tag canonical das páginas duplicadas para a página original usando JavaScript. (Excluir as páginas duplicadas não é uma opção, pois elas têm tráfego considerável.)
Alguém poderia sugerir como atualizar uma tag href usando JavaScript no Discourse?
Aqui está, @KranthiKiranGude, é assim que você pode alterar o atributo href em JavaScript. Primeiro, você seleciona o elemento DOM e, em seguida, altera o atributo.
<script>
var uC = document.querySelectorAll("link[rel='canonical']")[0];
var newURL = "https://my.coolforum.com/newlink";
uC.setAttribute("href", newURL);
</script>
Claro, você precisará de alguma lógica baseada na página em que deseja operar.
Exemplo de lógica genérica:
<script>
if("a_url_ou_id_real_da_página" == "url_ou_id_da_página_de_interesse")
{
var uC = document.querySelectorAll("link[rel='canonical']")[0];
var newURL = "https://my.coolforum.com/newlink";
uC.setAttribute("href", newURL);
}
</script>
Espero que isso ajude.
1 curtida
Olá @neounix,
Tentei seu código, mas, em vez de atualizar o href, foi gerada uma nova tag script:
Atualizei esse script na seção “/head”.
1 curtida
Por favor, poste o código exato que você usou e onde exatamente o adicionou, incluindo uma captura de tela da entrada na seção </head> que você mencionou.
Obrigado!
Parece normal que você tenha novo JavaScript gerado quando adiciona mais JavaScript.
Você precisará verificar o DOM no console de desenvolvimento web (os elementos), e não no código-fonte da página, a propósito.
1 curtida
1 curtida
Entendo.
Aliás, você está esquecendo uma aspa de abertura na sua declaração condicional do script…
1 curtida
Olá @neounix,
Funcionou no Dev Console. Mas, na Fonte da Página, ainda há referência à URL real.
Se não estou enganado, os mecanismos de busca pegam a Fonte da Página e não os elementos do DOM. Por favor, corrija-me se estiver errado.
1 curtida
Para ser honesto, não tenho certeza sobre isso. Antes, eu achava que os mecanismos de busca modernos (GoogleBot) leriam o DOM, mas agora que estou pensando, faz sentido que os mecanismos de busca possam ler apenas o código-fonte e não o DOM.
Mas… quando pesquisei no Google para verificar isso, diz:
Sinais de SEO no DOM (títulos de página, meta descrições, tags canônicas, tags meta robots, etc.) são respeitados. O conteúdo inserido dinamicamente no DOM também é rastreável e indexável. Além disso, em certos casos, os sinais do DOM podem até ter precedência sobre declarações contraditórias no código-fonte HTML. Isso exigirá mais trabalho, mas foi o caso em vários de nossos testes.
Referência:
https://searchengineland.com/tested-googlebot-crawls-javascript-heres-learned-220157
1 curtida
Olá @neounix,
Muito obrigado pela sua ajuda. Vou pesquisar também sobre essa parte. Mas, realmente, sou muito grato a você.
1 curtida
Bem-vindo!
Por favor, volte a postar e nos informe os resultados da sua pesquisa.
Outro método, com o qual tenho trabalhado no meu tempo livre recentemente, é modificar diretamente este arquivo da biblioteca Ruby do Discourse:
Você pode considerar algo nessa linha se não tiver sucesso com a técnica de manipulação de DOM em JS, @KranthiKiranGude
1 curtida
Olá @neounix,
Testei a página usando a ferramenta de Inspeção de URL. O Google está reconhecendo a URL atualizada.
2 curtidas
Perfeito… fico feliz em saber que funcionou.
Obrigado por testar e compartilhar o resultado.
PS: O método JS DOM é muito mais fácil do que manipular canonical_url.rb 
1 curtida
Não tenho certeza se sobrescrever o canonical usando JavaScript funcionará, pois isso é algo que ocorre mais no nível do spider (ou seja, a parte que recupera e coleta dados) do que no nível do indexador (a parte do bot que interpreta os dados e os armazena no índice de busca).
Conselho não solicitado: você pode querer ler este tópico para que possa colocar essas sobrescritas em um plugin:
2 curtidas
Sim, eu também. A questão ainda está em aberto.
Mas as pesquisas do Google sobre esse tópico são bastante proveitosas: muitas pessoas fazem isso, e muitas afirmam que o Google respeita as alterações no DOM (embora algumas digam que não, o que indica que não há um consenso forte e esmagador sobre o assunto). Veja, por exemplo:
Acho que, se fosse fazer isso, eu (1) excluiria a tag canonical original do código-fonte da página e, em seguida, (2) inseriria uma nova tag canonical no DOM com JavaScript.
Depois, ao longo do tempo, poderíamos simplesmente verificar o Google Search Console para ver o que o Google selecionou como canonical.
Veja também:
1 curtida
Como muitas pessoas consideram isso importante para SEO, verifiquei isso novamente, à luz dessa confirmação de @KranthiKiranGude.
De acordo com developers.google.com, Entenda os fundamentos de SEO para JavaScript:
O Googlebot suporta componentes web. Quando o Googlebot renderiza uma página, ele achata o conteúdo do Shadow DOM e do Light DOM. Isso significa que o Googlebot só consegue ver o conteúdo que está visível no HTML renderizado. Para garantir que o Googlebot ainda possa ver seu conteúdo após a renderização, use o Teste de Amigabilidade para Celulares ou a Ferramenta de Inspeção de URL e examine o HTML renderizado.
Como (1) @KranthiKiranGude usou sua Ferramenta de Inspeção de URL em seus testes e (2) ele confirmou que o canonical foi alterado conforme esperado dessa maneira, segue-se que, segundo o Google, o GoogleBot realmente “vê” e registra essa alteração de conteúdo do DOM após a página ser renderizada.
Referência:
1 curtida
Sim, eu apoio totalmente a ideia do Google achatar o conteúdo do DOM dessa forma durante a indexação.
Mas alguns/maioria das tags meta têm sua semântica no nível do protocolo HTTP, e não no nível do protocolo HTML, apesar de estarem presentes no HTML. Enfatizei o ‘durante a indexação’ porque não tenho certeza se ele achata o DOM dessa forma e leva em conta a URL canônica atualizada durante a raspagem (crawling).
(Para dizer de outro modo, não tenho certeza se o conteúdo do DOM também significa ‘metadados incorporados ao conteúdo’. Sim, ele vê dessa forma, mas não tenho certeza se ele usará dessa forma).
Talvez este artigo explique melhor: How Google Crawls Your Website and Indexes Your Content
Quando o Google precisa raspar sites JavaScript, é necessária uma etapa adicional que o conteúdo HTML tradicional não precisa. Ela é conhecida como etapa de renderização, o que leva algum tempo adicional. A etapa de indexação e a etapa de renderização são fases separadas, o que permite ao Google indexar primeiro o conteúdo não JavaScript.
1 curtida
Na verdade, não. Desculpe. Esse artigo de www.hillwebcreations.com nem sequer menciona o DOM, como inspecioná-lo, etc., e, pelo menos para mim, parece “datado e opinativo” (não atualizado, nem factual).
Pessoalmente, prefiro estas duas referências bem escritas, ambas com mais autoridade, fatos e referências sólidas, na minha opinião:
e a primeira, onde eles realmente testaram (e isso foi muito antes do GoogleBot mudar para um núcleo Chromium, que consegue ler o DOM (JavaScript) ainda melhor):
Testamos como o Googlebot rastreia JavaScript e eis o que aprendemos
Após minha pesquisa, tendi a concordar com os desenvolvedores do Google de que eles indexarão (e obterão seus sinais de SEO) o que for encontrado ao usar a Ferramenta de Inspeção de URL, e é a partir disso que podemos “julgar” os sinais de SEO e o conteúdo. A discussão do Google é clara, factual, autoritária e não especulativa.
Como @KranthiKiranGude confirmou que seu link canônico foi atualizado usando a Ferramenta de Inspeção de URL, que, segundo o Google, como autoridade, é “tudo o que você precisa” para ver como o Google vê uma página sob a ótica do SEO.
Resumo Técnico
Como o Google usa sinais de SEO do que pode ser visto por meio da Ferramenta de Inspeção de URL; e o fato de que os Desenvolvedores do Google declararam claramente que seus sinais de SEO podem ser analisados diretamente pela Ferramenta de Inspeção de URL; e o fato de que as alterações em JS feitas por @KranthiKiranGude no DOM são visíveis na Ferramenta de Inspeção de URL, isso é “mais do que suficiente”, na minha opinião.
Espero ter ajudado.
1 curtida
Sim, esse artigo afirma claramente que eles viram tags canônicas inseridas dinamicamente se comportarem exatamente da mesma forma que se estivessem no código-fonte. Você tem razão (e eu deveria ter lido isso com mais atenção na primeira vez que você postou).
Embora três das quatro páginas às quais você se referiu neste tópico, incluindo a que nos deu a resposta, sejam ainda mais antigas do que o artigo que eu postei 
A propósito, @RGJ, desculpe pela confusão sobre “não atual”…
Quando uso o termo “datado” ou “não atual”, estou falando de conceitos e ideias, não da data física de qualquer artigo.
Algumas pessoas escrevem artigos com datas de “hoje” e os conceitos são “datados” (e errados), enquanto outras escreveram artigos de 10 anos atrás que ainda são altamente relevantes hoje.
É isso que quero dizer com “datado” ou “não atual”: baseia-se em “conceitos”, não em datas físicas escritas no papel ou em um artigo da web. Desculpe por qualquer confusão causada pelo uso desses termos dessa maneira na minha resposta.
O que é importante, pelo menos na minha opinião, é que fornecemos uma solução para @KranthiKiranGude, e ele confirmou que funciona. Com base na sua postagem cética, nós dois fizemos pesquisas adicionais sobre essa questão.
Verificamos (1) que esse método, alterar o link canônico usando JavaScript, é válido; (2) que os desenvolvedores do Google confirmaram isso; e (3) que temos uma maneira de confirmar isso como usuários, usando a Ferramenta de Inspeção de URL (como @KranthiKiranGude usou e compartilhou conosco).
Desejo tudo de bom e muito obrigado pelo “vai e volta” sobre esse tópico interessante e por ajudar a tornar a solução ainda mais válida e sólida.
Vou para outras tarefas (ainda lutando para aprender Ruby on Rails depois de mais de uma década programando em PHP); já que este tópico está totalmente “missão cumprida”
Até a próxima… tudo de bom!
1 curtida