Basically what you outlined in your question is a standard way to structure such deals. 50 percent up front and 50 percent upon completion is not uncommon. Also common is 1/3 up front, 1/3 at a significant deliverable and 1/3 upon completion. The significant deliverable here could be availability for client review the test site with at least 90 percent functionality.
You are absolutely on track with not turning over source code until you are fully paid. As to access to the site, it is customary to have a test site, which might be on a machine you control, where a client can review and approve the work. It is unreasonable to not let the client see (access) the site until you are fully paid. If the production site is to be hosted on a server that you do not control, then full turnover of the sites files should be with the source code upon final payment.
The number of progress payments (2, 3 or more) is a function of the duration of the project. It makes no sense to break down a week long job into lots of payments; by the same token if the job is expected to take six months it would be perfectly reasonable to have a payment at the end of each month.
What you should also think about, but did not address in your question, are 1) how to price and handle changes? and 2) What are the criteria for acceptance by the client?