Удаление ссылок /2, /3, /4 и т.д. для каждого ответа в URL темы

Нет, /8 — это не то же самое, что тема. /8 указывает на 8-й пост, и временная метка соответствует времени публикации этого поста.

Если вы сравните вариант ?page=2 с реальным постом, на который он ссылается, то получите одинаковые временные метки.
Например:

wget -q -O - https://meta.discourse.org/t/topic-list-previews-legacy/101646/959|grep published_ti
<meta property="article:published_time" content="2020-05-09T04:29:46+00:00" />
wget -q -O - https://meta.discourse.org/t/topic-list-previews-legacy/101646/?page=2|grep published_ti
<meta property="article:published_time" content="2020-05-09T04:29:46+00:00" />

Похоже, что да: Incorrect or failing oneboxes for links to other discourse instances - #14 by techAPJ

Я не предлагаю удалять информацию о времени, но считаю, что для основного сообщения достаточно отправлять только машиночитаемую временную метку. С точки зрения ранжирования страницы в результатах поиска тема форума по сути является статьёй (основное сообщение) с набором комментариев. Для поисковой системы не имеет значения, когда были написаны комментарии.

Редакция: ещё один способ передать дату комментария (в отличие от всей страницы) в Google — это разметка schema.org.

Конечно, /8 указывает на 8-е сообщение, но с точки зрения бота и Google это абсолютно тот же контент и тот же URL. Если вы хотите, чтобы Google понимал, что /8 должен обрабатываться в результатах поиска точно так же, как и тема, то сайт, вероятно, не должен намеренно подавать сигнал о их различии. Только человеческому пользователю нужно знать, что временные метки отличаются, и эта информация отображается в тексте на странице.

Если сотруднику Google придётся принимать решения о том, когда переопределять канонические URL, заданные сайтом, одним из таких исключений может быть правило: «разные временные метки в намеренно заданных метаданных означают разные страницы — следовательно, переопределить канонический URL».

Программистам часто сложно предусмотреть все крайние случаи, если у них нет опыта столкновения с ними. Поэтому программистам Google может быть невообразимо, что идентичные страницы могут иметь разные временные метки, хотя для пользователей Discourse причины этого вполне понятны.

Ранее я работал в компании, где часть моих обязанностей заключалась в снятии блокировок сайтов в Google. (Они ничего незаконного не делали, просто возникали технические проблемы.) Поскольку никто точно не знал, как работает технология ранжирования Google и как она постоянно меняется, мы начинали с того, что пытались мыслить как инженеры поисковых систем и устраняли всё, что могло быть неоднозначным или запутанным для машин. Я никогда не мог точно сказать, какое именно действие сработало, но после систематического исправления подобных проблем результат всегда наступал со временем.

Это включено. Если вы хотите включить эту экспериментальную функцию, вам нужно изменить значение скрытой настройки сайта SiteSetting.allow_indexing_non_canonical_urls.

Пожалуйста, поделитесь с нами результатами.

Для меня это звучит абсолютно логично.

Да, да и ещё раз да. Очень хорошо сформулировано.

Смотрите:

В настоящее время Google корректно использует канонические URL:
Мы можем отслеживать это через Google Search Console в отчете «Индекс» → «Покрытие» → «Альтернативная страница с правильным каноническим тегом».

О разделе Альтернативная страница с правильным каноническим тегом:
«Эта страница является дубликатом страницы, которую Google считает канонической. Эта страница правильно указывает на каноническую страницу, поэтому вам не нужно предпринимать никаких действий». :slight_smile:

Я понятия не имею, как ссылки /X для каждого ответа влияют на SEO, и в целом стараюсь не подстраиваться под капризы Google. Но с практической точки зрения я вижу, что Google часто не обнаруживает новые ответы во многих долгоживущих темах на моём форуме Discourse, тогда как новые темы он индексирует довольно быстро. А когда он всё же индексирует новый ответ, ссылка ведёт не на конкретный ответ, а на /XXXX?page=YY. Я не знаю, хорошо ли это для SEO, но для людей, ищущих что-то конкретное, это определённо неудобно.

Эта тема уже довольно давно не активна. Мне стало интересно: пробовал ли кто-нибудь эту экспериментальную функцию? Прошло уже более двух лет, и я бы хотел узнать, считается ли она всё ещё экспериментальной, или кто-то может подтвердить, что она решает проблему?

Аналогично тому, что сделал @RGJ ещё в ноябре 2021 года, я нашёл крупный публичный форум (Python), использующий Discourse, и выполнил поиск в Google по теме на их форуме с множеством ответов, чтобы проверить, покажет ли он множество отдельных ответов из одной темы.

К моему удовольствию, Google НЕ показал мне большой список отдельных ответов в результатах! Единственными результатами были сама тема и категория, в которой она находится! Это отличный знак!

Однако, когда я выполняю тот же поиск, который @RGJ делал в ноябре 2021 года, проблема всё ещё существует для этого конкретного запроса.

Я также провёл новый тестовый поиск по другой теме на этом форуме сообщества Discourse и обнаружил похожую проблему: в результатах было несколько записей, пришедших из одной темы.

Отлично видеть, что эта проблема не возникает всегда на всех форумах Discourse… но я не понимаю, почему проблема решается на форуме Python, но всё ещё существует на форуме Discourse.

Есть ли у кого-нибудь идеи, как заставить эту проблему исчезнуть?

Я рассматриваю возможность миграции существующего форума с NodeBB на Discourse, но прежде чем это сделать, мне нужно убедиться, что есть способ решить эту проблему, чтобы она не превратилась в кошмар для SEO нашего домена.

Этот поиск возвращает небольшое количество ссылок на сообщения внутри темы, но поскольку в теме 58 постов, ожидалось бы увидеть 58 отдельных результатов, если бы все URL-адреса в формате /nn были проиндексированы. Возможно, паук видит ссылки на отдельные сообщения темы, размещённые в других постах, и поэтому индексирует эти отдельные страницы?

Тем не менее, отключение /nn стало бы кошмаром для моего форума. Здесь часто ведутся длительные обсуждения по решению проблем, которые могут включать несколько вариантов: сначала пишется «это сработало», а через несколько постов появляется сообщение «о нет, не сработало». Мы часто ссылаемся на реальные посты с решением, когда у кого-то возникает аналогичная проблема в будущем. Если всё, что вы можете сделать, — это направить людей на страницу, где ответ где-то спрятан, и которая, вполне возможно, содержит неверные решения, это никому не поможет.

И да, в Discourse, возможно, есть способы выделять решения, например, с помощью плагина Solved, но на моём форуме есть 22 года постов, из которых только последние 12 месяцев были опубликованы в Discourse.

Привет, Сет!
У меня сейчас возникла та же проблема в моем проекте.
У меня есть несколько URL-адресов для одной страницы, так как она разбита на страницы.

Думаю, этот пост может быть полезен.
Мне удалось использовать этот код, чтобы перенаправить все мои разбитые на страницы версии на их каноническую страницу.

Вы разместили этот код в файле .htaccess для перенаправления страниц в Discourse?

Discourse не использует Apache2. Его можно использовать перед Discourse в качестве обратного прокси, но это далеко не оптимальное решение.

И я вообще не понимаю эту тему. Такая структура URL никак не связана с SEO. Но, возможно, причина в том, что я не понимаю — однако мой форум имеет довольно высокую SEO-ценность, и это благодаря контенту.

Думаю, проблема здесь в бюджете сканирования.

Нет, тоже.