robots.txt - Инструкции и секреты настройки

[Sadorimatsu]

Есть проблемы, поставьте в блоке яндекс:
Disallow: /attachments/
Мне казалось, что в яндексе полезно будет открыть, но когда увидел этот ужас, то лучше закрыть от греха подальше.

Спойлер

Посмотреть вложение 161570

Так же есть подозрение, что правило Disallow: /*?t= влияет на проверку стилей т.к. после, как внёс запрет напрямую в оба блока, мне вебмастер резко начал ругаться, что главная страница не оптимизирована под мобильную версию. Лучше удалите его на оба блока.

Спойлер

Посмотреть вложение 161571

Что тут сказать, методом проб и ошибок, подводим к более продуманным правилам.

Аналогично общему блоку, добавьте в яндекс блок

Allow: /css/
Allow: /js/
Allow: /styles/

До чего же 2.3 версия капризна в индексации, да и ещё кучу лишнего добавлено =_= на 2.2 таких проблем вообще не было.

 

[DreamTails]

Всё ещё считаю сео бякой, которая делает мозги больше, чем всё остальное, и из-за которой люди готовы сломать половину движка, но тема не об этом

До чего же 2.3 версия капризна в индексации, да и ещё кучу лишнего добавлено =_= на 2.2 таких проблем вообще не было.

А почему вы считаете, что 2.3 и 2.2 отличаются в этом плане? Например ни в одной из этих версий нет отдельной папки css как таковой, есть css.php. Даже если вы пощелкаете в инспекторе запросов, то не найдете обращение к этой папке, только если вы сами её не создавали.

Папки js и styles как были, так и остались, почему вдруг с одной версией их нужно индексировать, а с другой этот блок не нужно вставлять? Логика подтягиваний файлов из них та же

 

[Sadorimatsu]

Всё ещё считаю сео бякой, которая делает мозги больше, чем всё остальное, и из-за которой люди готовы сломать половину движка, но тема не об этом

Не мы придумали эти стандарты и от этих стандартов страдаем, если им не следуем. Каждый при своём мнении. Конечно, на это можно забить и публиковаться как есть, учитывая, что с 25 года на это мало влияет и основной приоритет будет поведенческие факторы, а это другая кухня и к теме не относится. Думаю вы и так это понимаете не хуже. Задача подобрать оптимальную настройку robots для XF лишь с той целью, чтобы создать наиболее эффективную живую индексацию в поиске. Иные правила никто не отменял. Так что, в вашем понимании это может и бессмыслено, но для базовой подачи это не менее важно.

А почему вы считаете, что 2.3 и 2.2 отличаются в этом плане? Например ни в одной из этих версий нет отдельной папки css как таковой, есть css.php. Даже если вы пощелкаете в инспекторе запросов, то не найдете обращение к этой папке, только если вы сами её не создавали.

Новые переменные, новые пути. Мой старый шаблон от 2.2 довольно плохо стал работать после обновления, потом приходится проверять и дорабатывать по новой + эксперементировать ничто не мешает. Про /css/ вы правы, этот момент взял с общей методичке гугла, стоило отметить css.php. За правку благодарю.

Папки js и styles как были, так и остались, почему вдруг с одной версией их нужно индексировать, а с другой этот блок не нужно вставлять? Логика подтягиваний файлов из них та же

В принципе, их можно вообще не вставлять, всё равно те файлы, что не указаны в индексации, автоматически доступны, просто в правиле Allow мы сразу тычим боту, что ему разрешено сперва проверить, до всего остального. Но вероятно, эти правила избыточны, потому этот момент пока проверяется. До сего момента никому и дела не было до этих настроек и проверок, так что, смотрим и изучаем.

 

[Sadorimatsu]

Sadorimatsu обновил(а) ресурс robots.txt - Инструкции и секреты настройки новой записью:

Новая стратегия XF 2.3 v4 - Отказ от блока Yandex

Новый шаблон 2.3 v4:

robots.txt - XF 2.3 (v4)

Disallow: /account/
Disallow: /admin.php
Disallow: /attachments/
Disallow: /birthdays/
Disallow: /cdn-cgi/
Disallow: /conversations/
Disallow: /featured/
Disallow: /forums/*/page-*
Disallow: /goto/
Disallow: /help/
Disallow: /lfs/
Disallow: /login/
Disallow: /lost-password/
Disallow: /members/
Disallow: /misc/
Disallow: /online/
Disallow: /posts/*/reactions
Disallow: /register/
Disallow: /resources/*/filters
Disallow...

Узнать больше об этом обновлении...

 

[CHEL74]

Sadorimatsu, User-agent: * забыли в начале и Disallow: /resources/*?field=

 

[Sadorimatsu]

CHEL74, С ним не уверен, у меня в логах вообще переменной field никогда не попадалось, как бы вы не ловите его с какого-то плагина или модификатора. Потому и не стал учитывать. Если появится в логах, то учтем. При попытке проверить, меня просто кидает на общую страницу ресурса. Потому, подтвердить актуальность этого учёта, не могу.

 

[CHEL74]

CHEL74, С ним не уверен, у меня в логах вообще переменной field никогда не попадалось, как бы вы не ловите его с какого-то плагина или модификатора. Потому и не стал учитывать. Если появится в логах, то учтем. При попытке проверить, меня просто кидает на общую страницу ресурса. Потому, подтвердить актуальность этого учёта, не могу.

Я ж писал уже, что стандартный функционал XFRM. Дополнительные поля, отдельная вкладка. Вкладок для дубля должно быть хотя-бы 2 в ресурсе.

 

[Sadorimatsu]

CHEL74, проверю тогда лично, так ли это. Создам для пробы.

 

[Sadorimatsu]

Я ж писал уже, что стандартный функционал XFRM. Дополнительные поля, отдельная вкладка. Вкладок для дубля должно быть хотя-бы 2 в ресурсе.

Проверил и действительно есть такое. URL выглядит с ним так /resources/*/field?field=ИМЯ_ID_ДОП.ПОЛЯ
Чтобы его закрыть, достаточно добавить правило Disallow: /resources/*/field
Но это с тем условием, если у вас есть такая вкладка. Вот в чём нюанс. Без неё и правило не нужно. Предлагаю на него оставить примечание, когда следует добавить.

 

[CHEL74]

Предлагаю на него оставить примечание, когда следует добавить.

Да можно и без примечаний, добавить и пусть будет) Кушать не просит. Всё равно уже поддержка XFRM имеется и раз это стандартный функционал плагина и при этом проблемный, правило для него не помешает.

Но это с тем условием, если у вас есть такая вкладка. Вот в чём нюанс.

Там уже и так достаточно правил, которые могут быть не у всех. Того же XFRM может не быть, может отзывов не быть, может быть вкладка обновлений отключена и т. д.

 

[CHEL74]

Можно вообще комментарии сделать, по типу:

# Запрет индексации страниц плагина XenForo Resource Manager:
Disallow: /resources/*/field                 # дополнительные поля (вкладки)
Disallow: /resources/*/filters               # фильтры
Disallow: /resources/*/history               # история версий
Disallow: /resources/*/reviews               # отзывы
Disallow: /resources/*/update/*/reactions    # реакции
и т. д.

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

А ещё, правило Sitemap: https://ВАШ_ДОМЕН/sitemap.xml предлагаю перенести в самый конец, чтобы было проще обновляться. Можно будет просто копипастить себе всё, что выше этого правила. А то сейчас не удобно обновляться, приходится каждый раз сайт вписывать, либо за 2 захода вставлять обновления. Ну это такое, для лентяев.

 

[Sadorimatsu]

Там уже и так достаточно правил, которые могут быть не у всех. Того же XFRM может не быть, может отзывов не быть, может быть вкладка обновлений отключена и т. д.

Тут с вами соглашусь, раз это входит в коробку, то можно и указать. И в обновленной версии это всё добавлено.

Касаемо ресурсов, то вот список известных путей, которые рекомендуется закрывать из-за проблем дублей:

Disallow: /resources/*/field # Доп. поля (кастомные)
Disallow: /resources/*/filters # Фильтр ресурсов
Disallow: /resources/*/history # История версий ресурсов
Disallow: /resources/*/reviews # Обзоры/Оценки ресурсов
Disallow: /resources/*/update/*/reactions # Реакции на странице обновлений ресурсов
Disallow: /resources/*/updates # Информация по обновлению ресурса
Disallow: /resources/*?prefix_id= # Префиксы ресурсов
Disallow: /resources/authors/*/ # Список ресурсов у автора
Disallow: /resources/categories/*/featured # Рекомендованные ресурсы

Почему их надо закрывать? Потому что не один из них не даёт разные заголовки или мета описание, а где-то мета описания вообще нет. Если это и решать, то на уровне кастомных решений через модификатор шаблона. А надо ли оно вам? Задайте себе сперва этот вопрос.

А ещё, правило Sitemap: https://ВАШ_ДОМЕН/sitemap.xml предлагаю перенести в самый конец, чтобы было проще обновляться.

Указать его можно, хоть в начале, хоть в конце, погоды не делает. Но как-то странно, что вы предпочитаете тупо копировать, не разбираясь, а надо ли он вам.