Move Nginx Web Root to a New Location

Updated 4 November 2026 · Standard formula, shown below

This guide shows you how to change the directory where Nginx looks for your website files. Youâ€™ll edit the server block configuration, move the files, and reload Nginxâ€”all without downtime.

What You’ll Need

Root or sudo access to your server
Nginx installed and running
Knowledge of your current web root path (e.g., /var/www/html)
Access to the new directory location (create it if needed)
A text editor (nano, vim, or similar)

Step-by-Step

Back up your current configuration. Copy the relevant config file (usually in /etc/nginx/sites-available/ or /etc/nginx/conf.d/) to a safe place: sudo cp /etc/nginx/sites-available/example.com /etc/nginx/sites-available/example.com.bak
Create the new directory. For example, sudo mkdir -p /var/www/newroot. Set ownership to your web user (often www-data): sudo chown -R www-data:www-data /var/www/newroot
Copy your website files to the new location. Use rsync to preserve permissions and avoid downtime: sudo rsync -av /var/www/html/ /var/www/newroot/ (adjust source and destination paths).
Edit the Nginx server block. Open the config file for your site: sudo nano /etc/nginx/sites-available/example.com. Find the root directive inside the server block and change it to the new path. For example, change root /var/www/html; to root /var/www/newroot;.
Check for other references. Look for alias directives or try_files that might reference the old path. Also check any included files (e.g., include /etc/nginx/snippets/php.conf;) for absolute paths.
Test the configuration. Run sudo nginx -t. If it reports syntax is ok and test is successful, proceed. If it fails, review the error messageâ€”it often points to the exact line with the problem.
Reload Nginx. Apply the changes without dropping connections: sudo systemctl reload nginx (or sudo service nginx reload on older systems).
Verify the site works. Visit your domain or IP in a browser. Check that images, CSS, and scripts load correctly. Also test a few dynamic pages (if any).
Remove the old files (optional). Once youâ€™re confident, delete the old directory to free space: sudo rm -rf /var/www/html. Be carefulâ€”this is irreversible.

Common Mistakes

Forgetting to update all root directives. If you have multiple server blocks or a default server, each one that serves the site needs its root changed.
Using the wrong path in alias. Alias directives are separate from root; they need their own path update.
Not preserving file permissions. If you copy with cp instead of rsync -a, ownership and permissions might break, causing 403 errors.
Skipping the config test. Reloading a broken config can take Nginx down. Always run nginx -t first.
Leaving old files in place. If you donâ€™t remove them, you might accidentally edit the old ones later, causing confusion.

Tips

Use rsync instead of mv so the site stays live during the copy. You can then switch the root and reload instantly.
If youâ€™re moving to a different disk or partition, make sure the new location is mounted and has enough space.
For a multi-site server, consider using a variable for the root path (e.g., set $root_path /var/www/site;) to make future changes easier.
After moving, update any cron jobs, backup scripts, or deployment tools that reference the old path.
Test with a staging copy if you have a complex siteâ€”itâ€™s safer than changing production directly.

Troubleshooting

Site returns 404 Not Found. This usually means the root path is wrong or the files arenâ€™t there. Double-check the exact path in the config and that the files exist with ls -la /var/www/newroot.

Site returns 403 Forbidden. Likely a permissions issue. Ensure the web server user (e.g., www-data) has read access to the directory and files: sudo chown -R www-data:www-data /var/www/newroot and sudo chmod -R 755 /var/www/newroot (or use 644 for files).

Nginx fails to reload. Run sudo nginx -t to see the exact error. Common issues: missing semicolon, incorrect path, or a duplicate server block. Fix the reported line and test again.

Images/CSS not loading. This often happens when the new root doesnâ€™t have the same subdirectory structure. Check that relative paths (e.g., /css/style.css) exist in the new location.

PHP files download instead of executing. The fastcgi_param SCRIPT_FILENAME might still point to the old root. Update it in the location block to $document_root$fastcgi_script_name or the new absolute path.

Frequently Asked Questions

Do I need to restart Nginx or just reload?

Reload is sufficient. It gracefully restarts workers and applies the new config without dropping connections. Restart is only needed if you change the Nginx binary or modules.

Can I move the web root to a different userâ€™s home directory?

Yes, but ensure the Nginx user has execute permissions on all parent directories. For example, if the path is /home/user/www, the /home and /home/user directories must be traversable (chmod +x).

What if I have multiple server blocks for the same site (HTTP and HTTPS)?

You need to update the root in each server block that serves the site. Usually, both port 80 and 443 blocks have their own root directive.

Is it safe to delete the old web root after moving?

Yes, once youâ€™ve verified the new location works and youâ€™ve kept a backup (or used version control), deleting the old files is safe. Just double-check no other services use that directory.

How do I move the web root for a site managed by a control panel like CyberPanel or Vestacp?

Control panels often have their own configuration files and may override manual changes. Check the panelâ€™s documentation or use its built-in â€œchange domain directoryâ€� feature if available.

Will moving the web root affect my SSL certificate?

No, SSL certificates are tied to domain names, not file paths. As long as your domain stays the same, the certificate remains valid.

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