Здравствуйте. В настоящее время мы получаем это сообщение в Google Search Console. Я не совсем уверен, что оно означает. Не могли бы вы прояснить эту проблему? Есть ли решение? Кроме того, хочу отметить, что мы пробовали использовать различные темы для платформы, но ошибка сохраняется.
Привет, икляп!
Структурированные данные, по сути, помогают поисковым системам получить больше контекста.
Поиск Google не находит необязательное поле url в этой теме.
Вы можете увидеть на validator.schema.org, что это абсолютно корректно без каких-либо предупреждений.
Волноваться не о чем.
Тем не менее, если Поиск Google подсветит это поле, это станет веской причиной добавить его в Discourse.
Как объяснил выше @Arkshine, это не ошибка, а предложение от Google добавить необязательное поле в схему. Я изучу этот вопрос.
Из другой темы:
Так что да, поле «url» является необязательным, но здесь также есть реальные ошибки.
Атрибут itemprop="url" помогает Google объединять несколько блоков Comment на разных URL, относящихся к одной теме.
Я попытался воспроизвести ошибки, которые вы видите, протестировав мета-темы в Google Rich Results Test, но не обнаружил никаких ошибок.
Можете ли вы предоставить ссылку на тему, для которой Google показывает ошибки?
Первое, на что стоит обратить внимание, — это то, что ссылка, которую вы показали, указывает на отсутствие схемы «Форум обсуждений». Эта ссылка содержит только схему «Хлебные крошки», без какой-либо схемы «Форум обсуждений». Это происходит потому, что вы тестируете ссылку в режиме «смартфон», а не в режиме «десктоп».
https://search.google.com/test/rich-results/result?id=TlLcA6saLMo3BrxbQYnFuw
При переключении на тестирование ссылки в режиме десктоп появляется схема «Форум обсуждений», и система указывает на проблему «отсутствующее поле url».
- https://search.google.com/test/rich-results/result?id=uy3Ub3IwJiIuaMh-7YUu6g
- https://search.google.com/test/rich-results/result/r%2Fdiscussion-forum?id=uy3Ub3IwJiIuaMh-7YUu6g
Чтобы воспроизвести критические ошибки, необходимо протестировать длинную ветку с параметром URL ?page=2, например, как в этом случае:
Я должен отметить, что, на мой взгляд, это важная ошибка в Discourse: схема не отображается в режиме для смартфонов. Google не стал бы помечать это как ошибку (поскольку Google помечает только ошибки в схемах, которые присутствуют), но краулинг и индексация для смартфонов уже много лет являются стандартными для Google, поэтому крайне важно, чтобы любая схема отображалась как в режиме для смартфонов, так и в режиме для настольных компьютеров.
Проблема, описанная в первом сообщении, а также некоторые другие ошибки были исправлены в этом коммите:
Спасибо за предложения здесь, @rrit! 
Это происходит потому, что в режиме просмотра для поисковых роботов первое сообщение не включается со второй страницы и далее. @sam, стоит ли включать первое сообщение на всех страницах в режиме просмотра для роботов, чтобы исправить проблемы со схемой? 
Нет, я так не думаю, дублирование контента никогда не заканчивается хорошо. Есть ли другие варианты?
Другой вариант — заменить микроданные schema на JSON-LD (что рекомендует Google). Это позволит разделить отрисованные данные и структурированные данные, а также обеспечит работу на мобильных устройствах (как отметил Дэн выше).
Мы уже используем схему JSON-LD в плагине solved.
Конечно, это звучит как гораздо более правильное решение.
Не включайте данные/текст первого поста на последующих страницах, но всегда добавляйте itemprop="url", указывающий на первую страницу:
Смотрите Google structured data for forums and profile pages - #9 by rrit
Нет правила без исключений: для DiscussionForumPosting Google рекомендует использовать Microdata, а не JSON-LD.
Технические рекомендации
- В отличие от нашей общей рекомендации по использованию структурированных данных, мы советуем размечать
DiscussionForumPostingс помощью микроданных (или RDFa), если это возможно. Это избавит вас от необходимости дублировать большие текстовые блоки внутри разметки. Однако это лишь рекомендация, и JSON-LD по-прежнему полностью поддерживается.
Этот фикс уже работает на meta.discourse.org?
Пожалуйста, ознакомьтесь с моим комментарием на GitHub:
Весь этот тег link должен определяться только для
post.is_first_post— нет необходимости дублировать его с идентичным URL для каждого элементаComment.На meta.discourse.org кавычки в данный момент отображаются некорректно:
<link itemprop='mainEntityOfPage' href="…">
См. Schema Markup Validator
Да, мы сейчас делаем это согласно недавнему коммиту, но даже после его добавления на последующих страницах (?page=2) отсутствуют некоторые обязательные поля (author, datePublished, text).
Отличное замечание! Исправлено в этом PR:
Да, верно. Это также подтвердил @rrlevering здесь:
Похоже, нам придётся улучшить схему Microdata, убедившись при этом, что мы не будем дублировать контент на последующих страницах.
Спасибо за исправление свойства mainEntityOfPage.
И отличная находка насчёт тега meta против тега link
<link itemprop='url' content='<%= @topic_view.absolute_url %>'>
Ещё лучше:
<link itemprop='url' href='<%= @topic_view.absolute_url %>'>
Смотрите:
– Эта ссылка устарела, но YouTube до сих пор использует <link itemprop='url' href='…'>. –
“[Для] предоставления URL в HTML5 […] [для тега
link] используйте атрибутhref”
“Если вы используете URL в качестве значения атрибутаcontentэлементаmeta, он будет представлять строку (выглядящую как URL), а не URL.”
Я только что перепроверил документацию Google на странице DiscussionForumPosting: свойства:
Обязательные свойства:
authorauthor.namedatePublished- Либо
text, либоimage, либоvideoОсобое примечание: Либо
text, либоimage, либоvideo→ “Это не обязательно, если вы представляете пост на другой странице (с внешним
url), как на последующих страницах форумов или страницах категорий форума.” ←Рекомендуемые свойства
url- […]
Особое примечание:
url“Канонический URL обсуждения. В многостраничных темах установите это свойство в URL первой страницы. Для одного обсуждения это обычно текущий URL.”
Таким образом, я делаю вывод:
- Нам не нужно снова добавлять
textнаpage=2+(СДЕЛАНО) - Мы должны добавить необязательное свойство
url— особенно наpage=2+(СДЕЛАНО)
Необходимо дополнительное исследование:
- Действительно ли эти «обязательные свойства»
author,author.nameиdatePublishedобязательны наpage=2+, или мы можем обойтись без их повторения?
→validator.schema.orgне жалуется на отсутствующие свойства наpage=2+. (СДЕЛАНО)
→ Подождать и проверить «Google Search Console → Отчёт: Улучшения → Форум обсуждений» на наличие новых данных после того, как уже внедрённые исправления какое-то время будут работать вживую. (TODO)
Структурированные данные: инструменты и ресурсы
Schema
schema.org
developers.google.com
Валидаторы
schema.org
- Общий валидатор:
https://validator.schema.org/
Проверяет соответствие структурированных данных определениям Schema и корректность разметки с точки зрения HTML/XML.
→ Проверенные требования следуютStandard™, они довольно общие и не специфичны.
→ Я рекомендую исправлять каждую обнаруженную ошибку.
Google Search Console
- Отчёт: Улучшения → Форум обсуждений:
https://search.google.com/search-console/r/discussion-forum?hl=en
Даёт прямую обратную связь по обработанной информации отGoogle crawler.
→ Эти отчёты в каком-то смысле являются твёрдыми фактами о SEO в Google: если Google объявляет что-то неверным, то Google считает это неверным — даже если это не так.
→ Если что-то помечено как «неверно» или «требует улучшения», я рекомендую сначала подумать над исправлением. И если нет известных побочных эффектов, то всегда внедряйте исправление.
Google: Тест расширенных результатов
- https://search.google.com/test/rich-results?hl=en
Даёт только симулированную обратную связь и не являетсяGoogle crawler.
Мое мнение: маркетинговый инструмент Google, чтобы сказать владельцам сайтов «Сделайте что-нибудь со своими структурированными данными!".
→ Этот инструмент в какой-то степени заброшен Google и не всегда актуален относительно последних технических рекомендаций, предоставляемых самим Google.
→Rich Results Testне всегда выдаёт тот же результат, что иGoogle Search Console— в случае сомнений: лучше доверятьGoogle Search Console.
Давайте составим псевдокод для текущей проверки, отображаемой в Search Console. Я думаю, это сильно поможет в этих обсуждениях. Я мог бы отправить вам спецификации ShEx или SHACL, но они гораздо менее читаемы для человека.
if not (IsDeletedContent() OR IsExternalContent())
then if not ("text" OR "articleBody" OR "sharedContent" OR "image" or "video")
then report(OneOfThreeRequired("text", "image", "video"))
if not ("author")
then Report(Required("author"))
if not("datePublished")
then Report(Required("datePublished")
Суть в следующем: если у записи DiscussionForumPosting (или первого сообщения темы) контент находится на текущей странице, то должно присутствовать какое-либо поле с контентом.
Если DiscussionForumPosting ссылается на контент на другой странице (например, на исходной странице многостраничного материала), то может быть достаточно заглушки, содержащей любую информацию (например, заголовок темы первого сообщения), с последующей ссылкой на URL первой страницы. Именно это проверяет функция IsExternalContent(), которая просто сверяет, что URL не совпадает с URL текущей страницы.
Второй пример в нашей документации должен был в точности моделировать этот случай (14-я страница ссылается на заглушку поста с первой страницы).
Поля author и date в наших правилах валидации в настоящее время обязательны в любом случае. Это сделано в основном для того, чтобы избежать лишнего перехода для поиска этих данных. Вы могли бы хотя бы видеть, как знание даты первого сообщения помогает понять, насколько устарел комментарий. Не могли бы вы просто добавить туда мета-элементы с этими данными? Я не слишком беспокоился по поводу этих полей в контексте раздувания страницы избыточными данными.
Спасибо за контекст и советы, Райан!
Это сделано. Метаданные для последующих страниц (со второй и далее) теперь выглядят хорошо!
Имеет ли смысл добавлять URL author, если его путь заблокирован нашим robots.txt по умолчанию? Стоит ли нам убрать эту блокировку из robots.txt, учитывая, что мы теперь продвигаем такие URL?