You have three separate, unrelated issues here, which both are opportunities to improve the management of your website team. In order of difficulty for implementation, you need (1) a test server, (2) an improved architecture for your site, and (3) some coding standards your team can be compelled to follow.
(1): Implement a Test Server
If your website is important enough to have more than a single programmer work on it, then it's important enough to create a dedicated test server. The server can be a virtual machine if appropriate, but it SHOULD NOT be administered by your programmers, and it SHOULD be as identical to your production environment as practicable while not being the same machine.
Your developers can program on their desktops or on a third "development" machine, but code that goes on the test server should be there only for testing, and should be in a state such that it can be copied entirely either to or from the production server without any changes beyond perhaps a process reboot.
(2) Improve your site's architecture
It sounds like you may have a serious lack of separation between design, code, and content. Ensuring that your various components all have the same look and feel is NOT the same job as writing sensitive data-handling components, and even if they are performed by the same team they should be written in entirely different work sessions and stored in entirely different files.
Even if that was a miscommunication, your team both thinking that they need to fix problems in a deployment and not being confident on how to make those fixes is a huge red flag that a re-architecture would do. As you make your changes, you can also implement better test practices, such as a full battery of unit, integration, and system tests that can be ran on the test server after each change is committed.
(3) Adopt some mandatory coding standards
While it's absurd to think that you could force everyone to write their code always the same, whomever owns the site should be able to insist that all future work adheres to at least a basic level of standardization and clarity, sufficient that the code will not have to be abandoned if any particular member of the team leaves.
Documentation and comments are a good start, while clean code would be better, and a process of continuous improvement and depersonalized code ownership would be best of all. But, even moreso than the previous, this is a management question and not a programmer question.
Oh, and just in case you're looking for the more concrete answer of "how do i test a website", the best answer is "automatically, by either adopting a framework like QUnit, buying some contractor's test software, or writing your own."
Ideally, your test mechanism would be something that is stored in the website code itself, and can be called even on the production server (when invoked locally).
