Михаил Ливач

Проверяем сайт и устраняем ошибки "Mixed Content"
Исправляем визуальные дефекты на сайте

Не пользовался, но предполагаю, что это означает следующее:
у Таймвеба перед реальным сервером с сайтом стоит прокси, который отвечает за сертификаты ( например, у BeGet такая схема, и у Spaceweb вроде бы тоже ). На нём, перед отдачей готового контента браузеру посетителя, отрабатывает middleware, которое на лету заменяет http на https для нужных url. Вероятно, оно позволяет задавать для каждого сайта свой набор дополнительных костылей.
"Визуальные дефекты" - это тоже только то, что связано с незагрузившимся контентом.

Поэтому, когда Вы отключите услугу, то все проблемы от Mixed Content вылезут снова.

Если без динамики, то Pug - отличный шаблонизатор

ichug, вообще не понимаю, почему Вы акцентируетесь на том, что существует коробочная версия. Такое ощущение, что Вы плохо представляете, как устроен Битрикс. Смотрите:
1) есть облачный Битрикс24. Туда можно устанавливать "приложения", которые могут взаимодействовать со сторонними хостами через REST API
2) есть коробочный "Битрикс: корпоративный портал". Туда ровно так же ставятся те же самые приложения.

Если Вы рассматриваете ситуацию, когда коробочный корпортал стоит в закрытом контуре, изолирован от интернета, то в таких случаях Вам придётся договариваться с заказчиком об установке дополнительного сервера с Вашим ПО внутрь контура. Другого пути я не вижу. И тогда коробочный корпортал точно так же будет подключаться к этому доп.серверу.

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

У меня такого не происходит:

1. Зашёл на дзен.ру,
   
2. вбил ту поисковую фразу,
   
3. меня перекинуло на обычную поисковую выдачу Яндекса,
   
4. где-то в выдаче была ссылка на одну страницу Дзена.
   

Но вообще, как понимаю, это делается несложно:

1. мониторите wordstat или как-то иначе собираете релевантные сайту поисковые запросы
   
2. сопоставляете эти запросы со страницами сайта, сохраняете это сопоставление.
   
3. при выводе страницы в форму поиска на сайте выводите сопоставленный поисковый запрос
   

Не уверен, насколько положительно это воспримет SEO оптимизатор - лишние вхождения ключей на страницу.

Нужна бд или нет - это зависит от хотелок заказчика. Вы пишете:

мне посоветовали не заниматься этим, типо нужна будет База данных

Кто посоветовал? Если кто-то со стороны заказчика, вовлечённый в принятие решений, то так и надо сделать, то есть не заниматься не своей работой. А если посторонние для процесса люди, смело шлите их куда подальше. Поговорите с заказчиком, проясните ситуацию. Если фронт готов, а бэкендера ( для натяжки на WP ) ещё не искали, то предлагайте запуститься сейчас с Вашим решением. С сайта пойдёт какой-то фидбэк, будет польза.
А если бэкендера уже нашли, или заказчик настроился ждать результата - то ему Ваш костыль не нужен, и платить за него он не захочет

Подозреваю, 4 тыс. запросов к базе данных в цикле - не рационально, но как это сделать более разумно?

Обновляйте только изменённые, то есть события onAdd/Update/Delete . Только желательно делать это асинхронно, то есть обработчик должен только складывать задание на модификацию данных в очередь.

Если Ваш сайт занимается продажей инструмента, то ответ такой:
организовывать структуру не нужно, так как целевым посетителям подобная возможность не нужна.
Они купить пришли, а не читать 100500-й рерайт "что такое болгарка?".
Если за организацию FAQ ратует SEO-специалист, то делайте строго по его рекомендации; совершенно незачем делать этот функционал удобным, так как он для поисковых роботов, а не для людей.

Если же Ваш сайт - это собрание экспертов по инструменту, то я бы посоветовал опросить этих экспертов, их мнение будет более весомым и аргументированным.

конечно, возможно, например на PHP

header($_SERVER['SERVER_PROTOCOL'] . ' 504 Gateway Timeout', true, 504);
die;

Допил готового решения на Битриксе - это гибельный путь. Основные проблемы:
1) ваши правки могут слететь (полностью или частично) при обновлении решения. Этой проблемы можно избежать, заблокировав обновление модуля с решением.
2) те самые недостающие 15-20% функционала могут плохо состыковываться с решением. И работа над ними по затратам будет как 50% (или более) сборки "с нуля".

Благоприятный вариант: это когда готовое решение покрывает потребности с лихвой. Тогда отламываете лишнее и пользуетесь.

location /resources/ {
    alias /srv/web/split/storage/markets/$host/;
}

У меня нет опыта работы с $host - возможно, вам придется текущую конфигурацию развернуть в 4 отдельных.

С отсутствующим файлом, думаю, надо решить через try_files $uri @named_location