Надо разделить приложение на фронт и бэк в таком случае.
React, vue, angular, svelte делят приложение на компоненты. Вся страница это один большой компонент (внутри него маленькие) и для переключения этих компонентов используются route библиотеки. Они даже меняют url в адресной строке, но по факту сервер отдаёт один и тот же html, js, css, а какой компонент отобразить решает route библиотека уже на клиенте. Можно рендерить js на сервере с помощью next.js, но это другая история.
PHP здесь уже в связке с каким нибудь symphony отдаёт ТОЛЬКО объекты JSON. Позволяет создать объект, удалить, изменить, получить и прочая логика. Бэк связан с базой данных. Обычно для удобства к нему кидают Swagger или OpenAPI. Я здесь описываю REST API. Можешь реализовать gRPC или GraphQL
Чтобы с бэка получить данные на фронт юзают такие библиотеки как redux (для react), так называемые state менеджеры. Бэк ничего не знает о фронте! Вместо react приложения работающего в браузере можно мобильное или нативное приложение разработать без изменений в бэкенде.
А деплоиться это всё может так:
Берёшь веб-серевр (apache2 как пример). Настраиваешь reverse-proxy. Он обслуживает порт 80 или 443. Задача его перенаправлять запросы, например в docker контейнер, где у тебя задеплоен PHP на порт 3001 например, которые начинаются с domain.com/api. Всё остальное летит на другой docker контейнер с ip 3002 где у тебя задеплоен фронт. Можно конечно ещё запариться. Так как фронт у нас это html, js и css + картинки и это статика, то его можно на CDN закинуть и получать за мгновение из любой точки мира. А бэк это "лёгкий" (в сравнении с фронтом) JSON.
Заметь фронт и бэк разные сущности. Фронт знает о бэке, а бэк о фронте нет.
Так что отдавать react через php ненужно