It's worth noting up front that the type of attack you're asking about (website defacement) is a relatively infrequent form of attack. Hackers are usually more interested in stealing data and/or hijacking your entire server. It's also relatively easy to counter defacement by simply replacing the website content. Unless you have a determined enemy, that will often hold you over while you track down the vulnerability that led to it.
That said, yes the configuration you describe introduces a larger attack surface than having separate sites, and yes there are things you can do to reduce that surface.
First thing you can do is use standard linux groups and users to completely deny write access to all static website content and source code. You can do that by creating a www-admin user and chown all content to that user. Then have a different user (or users) for the programs and services. A common web-service user is the user nobody, but special-purpose users such as www or http can also work. Put static content and source code in their own directories, owned by www-admin, with permission 755 on directories and 644 on files. That will prevent any changes to your site by a compromised web service or application. You can fine-tune this further with groups if you want for convenience reasons, but for security this ownership set-up will protect your files from web-based defacement and is easy to implement and maintain.
By default, nginx does not accept http TRACE, DELETE, or PUT requests. However, it's a good idea to test this:
curl -v -X TRACE "http://www.example.com"
curl -v -X DELETE "http://www.example.com/dummy-page.html"
echo evil > ./test4evil.txt
curl -v -X PUT "http://www.example.com" -F "file=./test4evil.txt"
You should get 405 (not allowed) responses for these tests.
If you would like site visitors to be able to upload content, create special user-content-only directories for that and narrowly assign write permissions to those directories to the app/s or service/s that do the uploading. By narrowly, I mean avoid giving write permission to users or groups that don't need to write to that directory.
All of this addresses files on disk only. Since your sites generate content dynamically, you should also make sure you address php injection, sql injection, and other potential exploits related to dynamic content. However, that's a different topic and the question here is only about preventing changes to files on disk.