Михаил

шаблон, по которому формируются мета-теги прописывается в коде в соответствие с платформой на которой написан ИМ

ни разу не встречал сервиса для кривой верстки
верстак должен знать под что он делает верстку, должен знать структуру cms, а что касается, например, битрикса, ни разу не видел отдельную верстку, которая бы легко без косяков легла бы на сайт.
ничего нет лучше фулстек разработки, когда разделяешь и делаешь все ровненько, так чтобы, в том же битриксе, при включении режима редактирования ничего не сползало. чтобы не надо было городить условий, и чтобы после изменения демо-контента не оставалось куча мусора в стилях и событиях, а сам контент отображался как и положено.

оберни в container

Let's Encrypt это точно такой же сертификат, как и платные (за исключением усиленных)
Разработчики данного сборщика сертификатов выдают на самом деле не бесплатно, если в кратце, то собрались как то большие дядьки из таких компаний как cisco mozilla google и др. и решили перебросить сайты на https, для использования протокола безопасности, если бы они просто сказали людям, что теперь в браузерах будут блокироваться сайты http (а так и хотели сделать), то люди бы послали по дальше google mozill'у и другие браузеры, которые это делали бы, и просели бы акции компаний, и потеряли бы они много лярдов, но есть выход, вложить в одну из компаний, которая будет выдавать сертификаты бесплатно, и пал жребий на ISRG, договорились они что будут платить этой компании, а те в свою очередь, будут выдавать сертификаты на халяву, что теперь и происходит.
Платные сертификаты раньше выдавали много компаний, при данных обстоятельствах эти компании просто оставили свой функционал выдавать сертификаты за деньги, ведь им то не платят за раздачу халявы, а люди не знающие, что разницы нету, покупают их.
Усиленные сертификаты можно только купить и только организациям или ИП, но они по факту используются только платежными системами, на том сервере, где проходят платежи, в других случаях они не используются, т.к. это пустая трата денег компании.

сразу отмечу неправильное видение Битрикса:

проблема в компоненте bitrix:catalog*. По сути весь интернет магазин завязан на нем и поддерживает он только один инфоблок

стандартный компонент - это контроллер, который показывает возможности работы с API Битрикса (модулями).
минус стандартных компонентов: они сделаны под различные задачи, т.е. параметров там много, каждый параметр, это объем данных и обработка. итоговый массив данных содержит много не нужной информации.

Можно создать разделы в ручную, но еще кучу компонентов завязано на этом компоненте.

Компоненты завязаны, когда они являются комплексными. т.е. в одном компоненте вызывается другой. Ничего не мешает вызывать компоненты по раздельности.

Highload блоки, но как понял для этого нужно под себя что-то переписывать, ведь они просто хранят информацию и просто реализовать через них поля нельзя

Highload-блок это отдельная таблица в базе данных и связать их с инфоблоками не состовляет проблем, в инфоблоке есть поле справочник, которое показывает как можно связать, но не обязательно использовать именно его, можно создать свое поле, или проще написать обработку связи в компоненте.
Инфоблоки лучше использовать, когда есть необходимость использования стандартных полей инфоблока или функционал завязанный на них, например модуль торгового каталога (именно модуль), если из стандартных полей используется минимум, и сущность не обрабатывается, а только привязывается куда-либо, то проще использовать HighLoadBlock т.к. они достаются из базы одним запросом.

в ручную делать костыли?

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

Ответ на вопрос "Как лучше спроектировать структуру сайта":
для начала необходимо расписать в тз весь функционал сайта, расписать связи, а затем уже обдумать куда лучше закидывать то или иное поле. 3000 свойств, это свалка, в любом случае есть необходимость раскидать, даже просто для наведения порядка и удобства в редактирование.
Если трафик магазина более 1000 в сутки, рекомендую писать собственные компоненты, на собственных компонентах можно добиться и поддерживать более высокую скорость работы, чем на стандартных.

1. Посмотрите все настройки, правильно ли выставлены слеши site.url/docs/razdel-1/ и site.url/docs/razdel-1 это разные ссылки
2. docs убрать можно, для этого необходимо будет поиграться с urlrewrite.php ручками, а не стандартными настройками, при этом разобравшись и прописав правильные права первый вопрос решится сам собой.

вообще при многосайтовости, если сервер отстроен верно, никаких траблов быть не должно, но попробуйте убрать в настройках #SITE_DIR# и оставить относительную ссылку /services/

p.test {
font-size: 0.9vw;
}

может так:

if ($_SERVER['REQUEST_SCHEME'].'://.'$_SERVER['SERVER_NAME'].'/' == "https://site.ru/" ){
  echo 'Мой' ;
} else {
   echo 'Другой';
  }

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

если событие вешается на элемент, то оно вешается на существующий элемент, и не работает на вновь подгруженном через ajax, необходимо событие повесить на статичный родительский элемент или весь документ.
$({родительский элемент}).on({событие},{элемент события},function(event){...});
Если вешаете на документ, надо учитывать что обрабатываться будут все указанные элементы, если на родительский элемент, то отрабатываются, только те элементы, которые находятся внутри родительского.
В таком варианте события будут работать на новые подгруженные ajax'ом объекты.
Сортировку и прочие параметры проще передавать POST'ом, это как минимум удобнее, особенно когда в обработке учитываете фильтрацию и пагинацию (думаю в дальнейшем с этим столкнетесь)

это не правильно со стороны безопасности предлагать вводить номер платежного счета, какой бы он не был, в итоге сайт может быть заблокирован за подозрение в мошенничестве.
для платежей используются api платежных систем, клиенту предлагается выбрать платежную систему, затем сама оплата(и ввод данных) происходит уже на стороне платежки с усиленным ssl-сертификатом.
но если все-таки вы решили организовать мошенническую схему, то надо изучить по каким признакам можно отличить qiwi от яндекса, возможно в яндексе не используется первая цифра 8.

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