На моём домене есть несколько дублирующихся страниц. Мне нужно с помощью JavaScript проставить canonical-тег для дублирующихся страниц, указывающий на оригинальную страницу (удаление дубликатов не вариант, так как они получают значительный трафик). Подскажите, пожалуйста, как обновить тег с помощью JavaScript в Discourse.
Вот вам, @KranthiKiranGude, вот как можно изменить атрибут href в JavaScript. Сначала вы выбираете элемент DOM, затем изменяете атрибут.
<script>
var uC = document.querySelectorAll("link[rel='canonical']")[0];
var newURL = "https://my.coolforum.com/newlink";
uC.setAttribute("href", newURL);
</script>
Конечно, вам понадобится какая-то логика в зависимости от страницы, на которой вы хотите работать.
Пример общей логики:
<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>
Надеюсь, это поможет.
Привет, @neounix,
Я попробовал ваш код, но вместо обновления атрибута href был создан новый тег script:
Я обновил этот скрипт в секции “/head”.
Привет, @KranthiKiranGude
Пожалуйста, опубликуйте точный код, который вы использовали, и укажите, куда именно вы его добавили, включая скриншот записи в разделе </head>, о котором вы упоминали.
Спасибо!
Это нормально, что при добавлении нового JavaScript генерируется новый JavaScript.
Кстати, вам нужно проверять DOM в консоли инструментов разработчика (элементы), а не в исходном коде страницы.
Понял.
Кстати, в условном операторе вашего скрипта не хватает открывающей кавычки…
Привет, @neounix,
Это сработало в консоли разработчика. Однако в исходном коде страницы всё ещё ссылается на фактический URL.
Если я не ошибаюсь, поисковые системы берут данные из исходного кода страницы, а не из элементов DOM. Поправьте меня, если я не прав.
Честно говоря, я не уверен насчёт этого. Раньше я думал, что современные поисковые системы (GoogleBot) читают DOM, но теперь, если подумать, имеет смысл, что поисковики могут читать только исходный код, а не DOM.
Но… когда я поискал в Google, чтобы проверить это, оказалось:
Сигналы SEO в DOM (заголовки страниц, мета-описания, канонические теги, мета-теги robots и т. д.) учитываются. Контент, динамически добавленный в DOM, также доступен для индексации и сканирования. Более того, в определённых случаях сигналы DOM могут даже иметь приоритет над противоречащими утверждениями в исходном HTML-коде. Это потребует дальнейшей работы, но именно так было в нескольких наших тестах.
Источник:
https://searchengineland.com/tested-googlebot-crawls-javascript-heres-learned-220157
Привет, @neounix,
Огромное спасибо за вашу помощь. Я тоже изучу этот вопрос. Но, действительно, очень благодарен вам.
Добро пожаловать!
Пожалуйста, вернитесь с ответом и сообщите нам результаты ваших исследований.
Другой метод, над которым я в последнее время работаю в свободное время, — это прямое изменение этого файла библиотеки Ruby для Discourse:
Вы можете рассмотреть что-то в этом духе, если метод манипуляции DOM с помощью JS не принесёт результатов, @KranthiKiranGude
Привет @neounix,
Я протестировал страницу с помощью инструмента инспекции URL, и Google распознаёт обновлённый URL.
Отлично… рад слышать, что всё сработало.
Спасибо за тестирование и обратную связь.
PS: Этот метод JS DOM гораздо проще, чем манипуляции с canonical_url.rb 
Не уверен, что переопределение канонического URL с помощью JavaScript сработает, поскольку это вопрос уровня паука (то есть части, которая извлекает и собирает данные), а не уровня индексатора (части бота, которая интерпретирует данные и сохраняет их в поисковый индекс).
Непрошеный совет: возможно, стоит прочитать эту тему, чтобы вы могли разместить эти переопределения в плагине:
Да, я тоже. Вопрос ещё без окончательного ответа.
Однако поиск Google по этой теме даёт много полезной информации: многие так делают, и многие утверждают, что Google учитывает изменения в DOM (хотя некоторые говорят обратное, так что явного и подавляющего консенсуса по этому вопросу нет). Например:
Я думаю, если бы я собирался это делать, то (1) удалил бы исходный канонический тег из кода страницы, а затем (2) вставил бы новый канонический тег в DOM с помощью JS.
Затем со временем мы могли бы просто заглянуть в Google Search Console и посмотреть, какой канонический тег выбрал Google.
Также см.:
Поскольку многие считают это важным для SEO, я ещё раз проверил этот вопрос, опираясь на подтверждение от @KranthiKiranGude.
Согласно основам SEO для JavaScript на сайте developers.google.com, Googlebot поддерживает веб-компоненты. При рендеринге страницы Googlebot «сглаживает» содержимое shadow DOM и light DOM. Это означает, что Googlebot видит только то содержимое, которое отображается в сформированном HTML. Чтобы убедиться, что Googlebot по-прежнему видит ваш контент после рендеринга, используйте тест «Мобильная адаптация» или инструмент «Проверка URL» и просмотрите сформированный HTML.
Поскольку (1) @KranthiKiranGude использовал свой инструмент «Проверка URL» при тестировании и (2) он подтвердил, что канонический URL был изменён ожидаемым образом, следует, что, согласно данным Google, GoogleBot действительно «видит» и регистрирует это изменение содержимого DOM после рендеринга страницы.
Ссылка:
Да, я полностью поддерживаю идею Google о том, чтобы сглаживать содержимое DOM таким образом во время индексации.
Однако некоторые/большинство тегов meta имеют свою семантику на уровне протокола HTTP, а не на уровне протокола HTML, несмотря на то, что они присутствуют в HTML. Я выделил фразу «во время индексации», потому что не уверен, что Google сглаживает DOM таким образом и учитывает обновлённый канонический URL во время сканирования.
(Иными словами, я не уверен, что под содержимым DOM подразумевается также «метаданные, встроенные в контент». Да, Google видит это таким образом, но не уверен, что будет использовать это таким образом).
Возможно, эта статья объясняет это лучше: How Google Crawls Your Website and Indexes Your Content
Когда Google нужно сканировать сайты на JavaScript, требуется дополнительный этап, который не нужен для традиционного HTML-контента. Он называется этапом рендеринга, на который требуется дополнительное время. Этапы индексации и рендеринга являются отдельными фазами, что позволяет Google сначала индексировать контент без JavaScript.
.
Не совсем, извините. Эта статья от www.hillwebcreations.com даже не упоминает DOM, как его инспектировать и т. д., и, по крайней мере для меня, она звучит как «устаревшая и предвзятая» (не совсем актуальная и не фактическая).
Лично я предпочитаю эти два хорошо написанных источника, которые, на мой взгляд, обладают большим авторитетом, фактологичны и имеют надлежащие ссылки:
и первый из них, где они фактически провели тестирование (и это было задолго до того, как GoogleBot переключился на ядро Chromium, которое могло ещё лучше читать DOM (JavaScript)):
Мы протестировали, как Googlebot сканирует JavaScript, и вот что мы узнали
После моего исследования я склоняюсь к согласию с разработчиками Google в том, что они будут индексировать (и получать свои SEO-сигналы) то, что обнаруживается с помощью инструмента «Инспекция URL», и именно на основе этого мы можем «оценивать» SEO-сигналы и контент. Обсуждение со стороны Google чёткое, фактологичное, авторитетное и не основанное на домыслах.
Поскольку @KranthiKiranGude подтвердил, что его каноническая ссылка была обновлена с помощью инструмента «Инспекция URL», который, по словам Google как авторитета, — это «всё, что нужно», чтобы увидеть, как Google воспринимает страницу с точки зрения SEO.
Техническое резюме
Поскольку Google использует SEO-сигналы из того, что можно увидеть с помощью инструмента «Инспекция URL»; и поскольку разработчики Google чётко заявили, что их SEO-сигналы можно напрямую анализировать с помощью инструмента «Инспекция URL»; и поскольку изменения JS, внесённые @KranthiKiranGude в DOM, видны в инструменте «Инспекция URL», это, на мой взгляд, «более чем достаточно».
Надеюсь, это поможет.
Да, в этой статье действительно чётко сказано, что они видели, как динамически вставленные канонические теги ведут себя точно так же, как если бы они были в исходном коде. Вы правы (и мне следовало прочитать это более внимательно в первый раз, когда вы это опубликовали).
Хотя три из четырёх страниц, на которые вы ссылаетесь в этой теме, включая ту, что дала нам ответ, даже старше той статьи, которую я опубликовал 
Кстати, @RGJ, извините за путаницу с формулировкой «не актуально»…
Когда я использую термины «устаревшие» или «не актуальные», я имею в виду концепции и идеи, а не физическую дату публикации статьи.
Некоторые авторы пишут статьи с датой «сегодня», но их концепции оказываются «устаревшими» (и ошибочными), а другие пишут статьи десятилетней давности, которые по-прежнему высоко актуальны.
Именно это я имею в виду под «устаревшими» или «не актуальными»: речь идёт о концепциях, а не о физических датах, указанных на бумаге или в веб-статье. Приношу извинения за возможную путаницу из-за такого использования терминов в моём ответе.
Что важно, по крайней мере на мой взгляд, так это то, что мы предоставили решение для @KranthiKiranGude, он подтвердил, что оно работает, и, основываясь на вашем скептическом сообщении, мы оба провели дополнительное исследование по этому вопросу.
Мы подтвердили: (1) что данный метод изменения canonical-ссылки с помощью JavaScript является валидным; (2) что разработчики Google это подтвердили; и (3) что у нас есть способ проверить это как пользователям, используя инструмент «Инспекция URL» (как это сделал и поделился с нами @KranthiKiranGude).
Всего наилучшего и большое спасибо за «дискуссию» по этой интересной теме и за то, что помогли сделать решение ещё более обоснованным и надёжным.
Я перехожу к другим задачам (всё ещё с трудом осваиваю Ruby on Rails после более чем десяти лет работы с PHP); так как по этой теме можно поставить галочку «миссия выполнена»
До следующей встречи… всего наилучшего!