Run a Second WordPress Site on a Subdomain with Nginx

Running a second WordPress site on a subdomain lets you keep a separate site, database, and files while using the same server. This guide assumes you already have one WordPress site running on an Nginx server and can edit its configuration; you’ll add a DNS record, create the second installation, configure Nginx, and enable HTTPS.

What You’ll Need

A domain whose DNS you can manage, such as example.com, and a chosen subdomain, such as blog.example.com.
SSH access with permission to create files and edit Nginx configuration, plus a way to reload Nginx.
A working PHP-FPM and database setup compatible with your WordPress version. You’ll need database credentials and, if required, permission to create a database and user.
A backup of the existing site and configuration. Avoid editing the first site’s document root or database for the new installation.

Step-by-Step

Choose the subdomain and add DNS. In your DNS provider’s control panel, create an A record for the subdomain pointing to your server’s IPv4 address. Add an AAAA record only if the server is reachable over IPv6 and Nginx is configured for it. DNS changes can take time to propagate. Check that the hostname resolves to the intended server before proceeding.
Create a separate document root. On the server, make a new directory for the second site, for example /var/www/blog.example.com. Set ownership and permissions to match the approach used by your current site and PHP-FPM process. Do not make the directory world-writable. Keep this root separate from the first WordPress installation.
Create a separate database and user. Using your database server’s administrative tools, create a database for the new site and a dedicated user with permissions limited to that database. Save the database name, username, password, and database host securely. A separate database prevents the two sites’ tables and settings from being mixed.
Install WordPress in the new directory. Download WordPress from its official project site and place its files in the new document root, or use your established deployment method. Set the directory and file ownership appropriately. Avoid copying the old site’s wp-config.php or database tables unless you intentionally want a migration; a fresh installation should use the new database credentials.
Add an Nginx server block. Create a new configuration file using the same layout as your server’s existing site configurations. A typical block looks like this; replace the PHP-FPM socket with the one actually configured on your server:
```
server {
    listen 80;
    listen [::]:80;
    server_name blog.example.com;
    root /var/www/blog.example.com;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php-fpm.sock;
    }

    location ~* /\. {
        deny all;
    }
}
```
The socket path and included snippet vary by distribution and PHP-FPM installation. Check the existing working PHP site or PHP-FPM pool configuration rather than assuming the example path exists. Make sure the new block has its own server_name and document root. Do not add broad PHP handling or access rules without understanding how they interact with the server’s existing configuration.
Enable and validate the configuration. Link or include the new file using the method your Nginx setup already uses. Run sudo nginx -t before reloading. If the test reports an error, correct it first; do not reload a broken configuration. Then run sudo systemctl reload nginx or the equivalent service command for your system. A reload applies valid changes without deliberately stopping the service.
Test the site over HTTP and complete WordPress setup. Visit http://blog.example.com. The WordPress setup screen should appear. Enter the new database details and create the site’s administrator account. If you see the old site, a default Nginx page, or a connection error, pause and check DNS, the selected server block, and the document root before installing.
Enable HTTPS for the subdomain. Use your server’s established certificate process to request a certificate that includes blog.example.com. The DNS record must resolve correctly and the server must be reachable for the selected validation method. Configure Nginx to serve the certificate, test the configuration, and reload it. Then confirm the site loads at https://blog.example.com before setting WordPress to use that address. If your certificate tool offers to configure redirects, review its changes and test them.
Check the finished installation. In the WordPress dashboard, confirm both the WordPress Address and Site Address use the intended HTTPS subdomain. Test the homepage, a page, and a login. Check that the original domain still reaches the original site. Set up backups for the new files and database, and keep WordPress, themes, and plugins updated.

Common Mistakes

Reusing the first site’s document root or database: this can show the wrong site or mix WordPress tables. Give the second installation its own directory and database.
Using the wrong PHP-FPM socket: a made-up or outdated socket path can cause gateway errors. Inspect the active PHP-FPM configuration and existing Nginx blocks.
Forgetting DNS or using the wrong hostname: the DNS record and Nginx server_name must match exactly. Include the subdomain in the HTTPS certificate request.
Skipping configuration tests: always run nginx -t before reloading. A typo can prevent Nginx from loading the new block.
Changing URLs before HTTPS works: changing WordPress to HTTPS too early can make the dashboard inaccessible. Confirm the certificate and HTTPS response first.

Tips

Keep a copy of the original Nginx configuration and note every change so you can roll back safely.
Use the same PHP version and security practices as the existing site, but confirm the new WordPress installation is compatible.
Use a separate database user with only the privileges the new site needs. Store credentials outside public web directories and restrict access to configuration files.
Remember that a subdomain is a separate WordPress installation unless you deliberately configure WordPress Multisite. It does not automatically share users, plugins, or content with the main site.

Troubleshooting

The subdomain does not resolve: check the DNS record’s name and address with your DNS provider or a DNS lookup tool. Allow for propagation, and verify that any proxy or firewall is not sending traffic elsewhere.
You see the old site or a default page: confirm the request’s hostname matches the new block’s server_name, and verify the block points to the intended document root. Check that no duplicate server block is taking precedence.
You get a 502 Bad Gateway: confirm PHP-FPM is running and the fastcgi_pass socket or address is correct and accessible to Nginx. Check the Nginx and PHP-FPM error logs for the specific failure.
You get a 403 or 404: verify the WordPress files exist in the configured root, Nginx can read them, and the index and try_files directives are present. Check directory permissions without making files world-writable.
HTTPS shows a certificate warning or redirect loop: check that the certificate covers the exact subdomain and has not expired. Review Nginx redirect rules and WordPress’s saved site URLs; remove conflicting redirects, then test again.

Frequently Asked Questions

Can I run two WordPress sites on one server?
Yes. Configure a distinct hostname, document root, and database for each site, and ensure the server has enough resources for both.

Does the second site need its own database?
A separate database is the clearest and safest setup for independent sites. At minimum, each installation must use distinct table prefixes if sharing a database, but that requires careful configuration.

Can I use the same SSL certificate for both sites?
Only if the certificate covers both hostnames, for example through multiple subject names or a suitable wildcard certificate. A certificate for the main domain alone does not automatically cover its subdomains.

Will plugins and users be shared?
No. Separate WordPress installations have separate users, plugins, themes, and settings unless you build a deliberate shared or Multisite setup.

Do I need to restart Nginx after editing the configuration?
Usually, a successful configuration test followed by a reload is sufficient. Use the service command appropriate to your operating system.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.

More cards in this drawer

The whole Numbers and Powers drawer →