Александр Маджугин

Там скорее всего статику отдает nginx так что htaccess не при чем.
Возможно в настройках nginx есть правило запрещающие доступ к этим файлам.
Или сами файлы недоступны для чтения сервером, просто по причине прав на сами файлы/папки (не знаю как это в виндовс работает)

При чем тут битрикс? В смысле причем он как источник проблемы? Вы сделали две одинаковые страницы, а теперь спрашиваете почему они одинаковые? Поразительно.
А собственно почему это страницы отображающей один и тот же товар должны быть разные тайтл и дескрипшин? Это что, разные товары?
Ну то-есть у вас проблемы не с битриксом, с логикой вашего каталога. Приведите в порядок логику и маркетинговый план.
Разберитесь каким должны быть тайтл и дискрипшен у товара.
Обоснуйте почему они у ОДНОГО И ТОГО ЖЕ товара должны быть разные и по каким принципам должны формироваться - дальше будет понятно что делать.


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

На мой взгляд вы выбираете между плохим и ужасным решением.
При этом не очень понятно каким образом 20 000 индексных страниц могут "нагрузить систему". Почему это с технической стороны должно быть хуже/тяжелее?
20 000 индексных страниц нагрузят вас - поддерживать такое превратится в мартышкин труд. Совершенно не понятно почему вы собрались делать на каждый раздел отдельную индексную страницу. Почему не сделать её одну на все разделы?

То есть, что лучше, использовать комплексный компонент или разбивать каталог на раздельные части, размещая разделы инфоблока в разных индексных папках?

Ложная дихотомия тут. Почему вы полагаете что у вас выбор между комплексным компонентом и собственной индексной страницей для каждого раздела?
Сделайте три файла в каталоге - index, section и detail и разместите в них соответственно список разделов, раздел, и детальную страницу элемента.
Т.е. в index - catalog.section.list, в section - catalog.section и в detail соотвественно catalog.element.
Настройте нужным образом urlrewrite и это на мой взгляд лучшее решение. Можно конечно применить и комплексный компонент в одном индексном файле, но на мой взгляд это плохое решение - оно менее прозрачно, громоздко и может привести к ошибка в работе с url, так как перекладывает на вас контроль за настройками путей на сайте.

Добавлю к ответу Андрея (в принципе полностью верному), что вообще не стоит даже пытаться это сделать - используйте API и вы застрахуете себя от многих проблем в будущем.
Если вам необходимо действие как транзакция - этом можно организовать: гуглите "StartTransaction"

Подойдет любая. CentOS удобна только тем что для нее есть скрипт устанавливающий BitrixEnv, что очень удобно. В скрипте есть процедуры для настройки работы сокетов, выпуска сертификата летсэнкрипт и тому подобного.

Если вы сами в состоянии администрировать сервер и знаете что и зачем нужно - пойдет и Ubuntu.

Я использую и то и то.

Но если мы будем переводить проект на реакт, то как мы будем писать php в нем?

Что это вообще может значить? PHP у вас это server side, а React это клиентское приложение.... Блин, я даже не знаю что дальше спросить... вы PHP в браузере собрались исполнять или JS интерпритатором PHP?
Это вот вопрос он лишен смысла чуть более чем полностью.

Ведь синтаксис реакта ( jsx ) не предусматривает php.

Да причем тут синтаксис? Среда исполнения не предусматривает php, а вы про синтаксис.

И мне кажется, так просто взять за неделю и перевести проект на реакт не получится. Наверное будем частями переводить.

Если это сайт среднего размера, то нужно заложить не неделю, а несколько месяцев.

Т.е. получается одна часть проекта будет написана на реакте, а другая - нет? Это вообще как?

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

У кого то есть подобный или близкий к этому опыт? Что посоветуете? Как грамотно перевести проект на реакт в таком случае?

Выше написал:
1 Сначала разрабатываете шаблон для одного раздела сайта на React, так как буд-то других разделов просто не существует.
2 Пишите соотвествующий бэкенд который будет отдавать данные для этого вашего шаблона.
3 Переводите этот раздел сайта на React.
4 Эксплуатируете неделю, подчищая косяки.
5 Выбираете еще один раздел сайта поменьше и переводите его аналогичным образом.
6 В этом месте у вас уже должно быть понимание где вы наложали с архитектурой, какие накопились костыли, и в чем фундаментальные изъяны того что вы сделал. Тут вы должны остановиться и выкинуть всё что сделали раньше. Я не шучу - просто выкинуть и начать перерабатывать эти разделы с нуля...
7 Теперь вы знаете что делать дальше.

1 Битрикс тут совсем не при чем.
2 Нужно как вам нужно. А как вам не нужно - не нужно.
3 Я бы сделал все без www.

Сейчас у вас ничто вообще не убирает www. Просто при входе с http происходит редирект на https://site.ru
Было там www или не было ему решительно все равно. Вы написал - если http - редиректить на https://site.ru, не зависимо от того что было до этого.

Для удаления www нужно добавить что-то вроде:
RewriteCond %{HTTP_HOST} ^www\.(.*)$
RewriteRule ^(.*)$ https://%1/$1 [L,R=301]

(не проверял)

Битрикс тут не при чем. Что вы вводите в свойство - то и он и выводит.

Т.е. допустим если вы ввели yandex.ru, то в href как раз и будет yandex.ru. и это разумеется будет ссылка на http:/site.ru/yandex.ru с главной.

htmlbook.ru/samhtml/ssylki/absolyutnye-i-otnositel...

Измените URL страницы детального просмотра на "#SITE_DIR#/decision/#CODE#/"

Ну если

после загрузки страницы в консоли браузера BX вполне себе определен

, то мне кажется надо разбираться с тем где и как он вызывается. Почему кто-то дергает его еще ДО загрузки библы?
Я бы грешил на какое-нибудь стороннее решение установленное на сайте и работающее в админке.

Делюсь опытом - лучше сделай с нуля сам.

У вас $value - это массив, поэтому его нельзя просто echo.
Сделайте print_r($value) и посмотрите в каком ключе нужное вам значение. Потом
<?=$value['КЛЮЧ']?>

Так с нуля или прикрутить к нему старую БД?
И что вы вообще называете БД?

По сути есть два пути:
1 Взять старый сайт и перепилисть компоненты и их шаблоны. Таким образом вы меняете условно говоря только контроллеры и вьюверы. БД полностью остается прежней, вместе с базой товаров.
2 Сделать полностью новый сайт с нуля, а товары в него перенести с помощью процедур импорта/экспорта, но скорее всего не стандартных (так к как в их случаи получится скорее всего структура БД аналогичная исходному, а в этом случае почему бы не использовать вариант 1), а самописных. Тут вы меняете все вообще.

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

Если текущая архитектура хороша - используйте подоход 1. Если нет - выбирайте подход 2.

Другие варианты есть? Да.
Гибридный подход - вы берете текущий сайт и на его основе и БД создаете новый, используя новые ИБ и сущности для нового сайта. Старые ИБ и сущности вы сохраняете на сайте, а данный в новые переносите с помощью скриптов миграции.
Люблю этот гибридный вариант - старые данные могут оставать на сайте сколь угодно долго и к ним всегда можно обратится. Скрипты переноса данных из одного ИБ в другой как правило сильтно проще чем скрипты импорта/экспорта.
Единственный минус - небольшой бардак в админке, но по завершению работ можно на бою и снести старые ИБ наведя порядок.