1. There will be some business objective that your client is hoping a website will help them with. Try to frame your communication with them in terms of business value and impact. To do that you'll need to understand a few things about them and their business.

Ask your client these questions:
- what does the business do?
- who are their customers?
- what problems are they currently facing because of their current website/lack of a website?
- what goals are they hoping the website will help them meet?
- how will success of the site be measured?

The client is paying you to bring technical expertise that they don't have in house. To do that effectively, you need to understand their business.

At some point you will have to talk to them about the design. If they suggest site designs, ask them what they like about it - this may require comparing to other similar sites as they may not be able to explain why they like a design. Also ask them why they think the design is a good fit for the image of their company. More complicated designs often take more time, and therefore cost more but they aren't necessarily good. Simple is almost always better.

2. I tend not to discuss the technologies used unless the client shows interest. Certain related things will need to be discussed: anything that costs them money (hosting, domain registration, etc) and anything that involves dealing with a third party.

Resist the urge to futureproof. Don't build code to support things that may never happen. This will help kep the code simple which make it easier to maintain and add to in the future if one of those hypothetical requirements becomes a real requirement.

3. This is tricky for everyone but especially hard when you're first starting out.

First I have an initial chat with them to answer the stuff in 1. above. I don't charge for this. Then I respond with a proposal that outlining the core features of the site. This is the minimum set of features that I think will address their most important goals - doing just this stuff will give them the most bang for their buck. I also include outlines for optional features that could be added once the initial feature set is in place. For each core feature, I provide a very high level estimate that covers everything needed to get that feature deployed and running as a live site - design, coding, testing and deployment. Resist the urge to be optimistic in your estimates - things will take longer than whatever number you're thinking of now. It's better to be a bit conservative with the estimate and set expectations early than it is to miss your own deadline.

For optional features, I just give an indication of the relative effort involved compared to other optional features. If this is questioned I explain that by the time we implement those features, the understanding of the problem we're trying to solve will have changed enough that it makes any numbers given now misleading.

As this is your first project, I'd recommend working on a per hour basis rather than a fixed price for the project. Generally, charging based on the value you deliver to your client gives better results than basing the rate off other roles you've had but that kind of requires you proving yourself with a couple of projects first. I'd probably go with $20-25 an hour for this one but revise this for any later projects.

You'll need to establish some kind of contract with your client. The specifics of this can be a bit different in different areas though. Google for developer or website consulting agreement for some samples.

The best thing you can do to make sure your client does not feel like he's being overcharged is to convince him that he's getting good value for money and the best way to do that is to show that you understand his business and that you're helping him solve his problems and reach his goals.

The best thing you can do to make sure that the client does not think that the project is taking too long is to regularly deliver features and communicate your progress to him. Don't go silent then give him everything in one go at the end. Give estimates that you can meet, and then meet them. When it looks like you aren't going to meet an estimate, let him know and recommend how to proceed.

Have fun. You're about to learn a lot.

TLDR: Aside from the technical, freelance consulting is mostly about managing expectations and perceptions.