Информационные блоки, сгруппированные по типам, хранят данные проекта: новости, каталоги и другие деревья/списки. От правильной настройки информационных блоков зависят не только удобство управления системой, но и производительность сайта и стоимость его поддержки и сопровождения. (Чем "прозрачнее" схема данных, тем проще ее поддерживать и развивать.) Неиспользуемые возможности желательно отключать.

Проверяем настройки типов информационных блоков: " Контент > Информационные блоки > Типы информационных блоков".

1. Названия типов должны отражать их роль в проекте. Название "Type12" - неудачное, "Новости регионов" (содержит внутри инфоблоки новостей регионов) - говорит само за себя.
2. В настройках каждого типа на вкладке "Основное" желательно указать названия разделов и элементов данного типа. Если элементами являются, допустим, товары, то название "Новости" для них явно некорректно.
3. На вкладке "Дополнительно" проверяем, чтобы флаг экспорта в RSS был установлен, когда экспорт действительно необходимо выполнять.

Проверяем настройки каждого информационного блока: " Контент > Информационные блоки > Типы информационных блоков > Название инфоблока".

1. Место хранения значений свойств (в общей таблице или отдельной таблице) выбирается в зависимости от решаемых задач и объема данных. Если в списке/дереве ожидается достаточно большой объем данных (сотни тысяч - миллионы элементов), рекомендуется хранить свойства в отдельной таблице. Для повышения эффективности выборок рекомендуется задавать для данных таблиц отдельные индексы на используемые в выборках поля.Однако, если число свойств у объектов может превысить максимальное число столбцов в таблице базы данных или требуются сквозные выборки объектов из множества инфоблоков, то рекомендуется использовать место хранения "в общей таблице".
2. Проверяем, что инфоблок используется только на том сайте, на котором требуется выборка его данных.
3. Индексация разделов и элементов для поиска включается тогда, когда планируется искать по информации в данном инфоблоке. В противном случае для повышения производительности индексацию рекомендуется отключить.
4. Если объекты инфоблока не участвуют в документообороте или бизнес-процессах - рекомендуется отключить участие.
5. Режим просмотра разделов и элементов выбирается исходя из удобства администрирования и ожидаемого объема данных. Если данных ожидается много (сотни тысяч объектов и разделов и больше) - рекомендуется использовать "раздельный" режим просмотра.
6. На вкладке "Поля" проверяем значения свойств объектов по умолчанию. Правильная настройка значений по умолчанию повысит удобство администрирования системы и работы с данными.
7. На вкладке "Свойства" обращаем внимание на удобочитаемые названия, адекватные решаемой задаче типы свойств и читаемые коды. Если для свойства задано название "Prop10" и код свойства "C9" - это легко запутает как менеджера сайта, так и в будущем программиста, осуществляющего доработку системы. Важно подобрать правильный тип свойства: например если требуется хранить дату, то обычно лучше использовать тип "Дата/Время", а не тип "Строка" и т.п.
8. Если требуется фильтрация по свойству элемента инфоблока в административном разделе, целесообразно в настройках свойства разрешить его вывод в фильтре - это сделает работу редактора информации более эффективной (например, список Партнеров необходимо часто фильтровать по дате регистрации Партнера и его типу т.п. - настраиваем эту возможность).
9. Аналогично проверяются настройки на вкладке "Поля разделов".
10. На вкладке "Торговый каталог" значения должны быть установлены только в случае использования данных режимов в проекте. В противном случае, для улучшения производительности, их лучше отключить.
11. На вкладке "Доступ" проверяем адекватность уровней доступа для групп пользователей. Например, инфоблок "Секретные ключи", не должен быть доступен группе "Зарегистрированные пользователи". Уровень доступа группы к инфоблоку также должен соответствовать решаемой группой задаче - например, если группа "Операторы ключей" должны только видеть ключи и не редактировать, то им не нужно предоставлять доступ "излишний" к инфоблоку - "Изменение" или "Полный доступ". Если требуется модерация внесенных данных перед их публикацией, то целесообразно назначить группе право на инфоблок - "Документооборот" (или использовать бизнес-процессы).
12. На вкладке "Подписи" проверяем их логическое соответствие. Например, если в инфоблоке хранятся данные об автомобилях, то подписи не должны описывать апельсины.
13. На вкладке "Журнал событий" можно включить регистрацию в системном журнале фактов модификации данных в инфоблоке. Если регистрация по, допустим, соображениям информационной безопасности, необходима, она должна быть включена.
14. В больших проектах с десятками типов и сотнями инфоблоков рекомендуется составить логическую модель данных с названиями инфоблоков, их свойств и связей между ними (еще лучше ее распечатать и повесить на стену). Это существенно упростит ориентацию в проекте как редакторов сайта, так и разработчиков, сократив время на поиск нужной информации и минимизировав риск логических ошибок. Также модель также поможет ответить на вопрос, можно ли удалить данный элемент инфоблока без последствий (на элемент могут ссылаться другие элементы и при удалении исходного может нарушиться логика работы проекта).