Here are two possible casues to the problem and the solutions:

1. The site is hosted on WordPress.com

WordPress.com is different from the usual WordPress.org self-hosted sites configuration, for example, the files and folders structure, our plugin is developed based on the WordPress.org platform and currently has not(yet) formally support WordPress.com.

2. The site is on a Nginx server

Nginx has no directory-level configuration file like Apache’s .htaccess or IIS’s web.config files. All configuration has to be done at the server level by an administrator, and WordPress cannot modify the configuration, like it can with Apache or IIS. Please also see this WP doc for more details – https://wordpress.org/support/article/nginx/.

So as described in the doc, on an Nginx server, after creating a site in the subdirectory (a staging site in your case), you will need to go to the Nginx config file to manually add the configuration for the subdirectory, for example, if the subdirectory name(where the staging site is installed)is ybdbfwms(or any name you defined when creating the staging site), you will need to add the following rules to the Nginx config file:

location /ybdbfwms(replace this with your own subdirectory name) {

# First attempt to serve request as file, then

# as directory, then fall back to displaying a 404,

#try_files $uri $uri/ = 404;

try_files $uri $uri/ /ybdbfwms/ index.php?$args;

}

This is actually also because about 99% of websites use Apache servers rather than Nginx, WordPress is much more compatible with Apache than Nginx.

Two more things:

1. After adding the above rules, make sure to restart Nginx server to make the changes effect.

2. For staging sites on Nginx server, make sure to use the same Permalink settings as the live site.

3. Cache, redirect or security plugins settings

It is recommended to temporarily deactivate(once the staging site is created, you can re-activate them) all cache, redirect and security plugins on the live site to rule out possible problems.