First, let me address your question about what a PM does. The PM:
- Understands cost/scope/schedule/quality
- Defines/plans cost/scope/schedule/quality
- Takes action to preserve cost/scope/schedule/quality
- Alerts relevant stakeholders of any change to cost/scope/schedule quality.
The PM's job is to make sure the project comes in on time, on budget, and is suitable.
So your first job is to define "What is done?" How will you know when the website is finished? (I can use google sites to set up a webpage in 1 minute or less; that won't make your customer happy. What kind of a website does your customer need? What will delight them?) Now you know the scope.
Second job is to plan. Your question asks how you are to know all the technical details; you don't need to know, you need to communicate. You don't need a template for a website; the devs already have that. Meet with the devs and work with them to make sure that everyone understands done. Then ask them what needs to happen to get to done. What are the steps. Break the task down into subtasks (ideally each subtask should be observable). The devs will estimate the time. They will tell you the deadlines. Planning is a lot of work. Frankly based on your question, I'm not sure you have enough knowledge to do it well.
Once there is a schedule, your responsibility changes: at any moment, day or night, you need to be ready to answer "Is the project on schedule? Will the project complete on time? Will the project complete on budget?" The tricky part is that you won't be writing code. You're just tracking devs. If you quizz the devs infrequently, you won't know whether they're on schedule or not. If you quiz them too often, you will be the reason that they are not on schedule. If your plan is well done, you'll be able to tell if they are on schedule/ahead of schedule or behind schedule. You should be ready to report those estimates at all times, but you'll need to work out with your sponsor how often the real reports will be delivered.
Your other obligation is to identify things that threaten scope/schedule/quality/cost and take action. If the head dev gets sick and falls behind in his work, it is your job to figure out whether the other devs can pick up the slack. If the problem will delay the schedule, increase the cost or diminish the quality, you need to understand that impact, and you need to work with whoever you need to come up with one or more options. (delay the project, hire a new programmer, decrease the scope, pray a whole lot). If you and the devs can solve the problem, glorious. If not, you need to involve whoever can solve the problem.
As an intern, your ability to make change is going to be limited. I suspect that the bulk of your work will be analyzing potential problems to understand what impact they could have on the scope/schedule/quality/cost. For any problem, make sure you know how many days delay, how many dollars cost, what capabilities will be diminished (quality).