Необычные проблемы конфигурации NGINX Wordpress (безголовый Wordpress + интерфейс статического сайта в одном домене)

У меня есть очень специфический вариант использования, когда я использую Wordpress в качестве серверной части CMS (в основном в конфигурации без заголовка), за исключением некоторых URL-адресов, к которым я хочу применить обычную конфигурацию NGNIX/Wordpress. Конкретно:

Большинство URL-запросов к корню NGINX должны обслуживать статические HTML-файлы из подкаталога. Это указано в этом блоке местоположения в блоке server моего файла виртуальных хостов:

location / {
    root /var/www/html/node/website.com/_build;
    index index.html;

    try_files $uri $uri.html $uri/ /404/index.html;
}

Но все файлы, специфичные для Wordpress (т. е. те, которые находятся за URL-адресом /wp-*), по-прежнему должны обслуживаться Wordpress. В конце концов, Wordpress также должен обслуживать несколько конкретных URL-адресов (например, /shop, /my-account), а не статические html-файлы, но я могу поработать над этим позже. В настоящее время у меня есть местоположение, специфичное для WP, определенное как:

location ~* /wp- {
    index index.php;
    try_files $uri $uri/ /index.php?$query_string;

    location ~ \.php$ {
        root /var/www/html/php/website.com;
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
    }
}

Частично это работает. website.com/wp-json работает правильно. Большинство конечных точек URL-адресов обслуживаются из подкаталога _build при условии, что существует соответствующий HTML-файл. Но website.com/wp-admin и website.com/wp-login.php автоматически загружают соответствующие файлы PHP вместо их обработки.

Это говорит мне о том, что возникла проблема с передачей файлов index.php в php-fpm, но я не могу понять, где обрыв. Кстати, я дублирую блок location ~ \.php$ и в блоке server, за пределами блока wp-.

Какие-либо предложения?

Кроме того, если у кого-то есть предложения по правильной настройке конкретных «внешних» URL-адресов (например, /shop, /my-account), которые будут обслуживаться Wordpress, а не HTML-файлов _public, это было бы действительно полезно и здорово.