If you are trying to understand how to plan a website, the best time to do it is before installing a theme, opening a page builder, or writing the first line of code.

I have seen the same situation more times than I can count. Someone gets excited about a new project, registers a domain, buys a hosting plan, installs WordPress, and then stops at the blank homepage.

The domain works. The hosting account is ready. WordPress is installed. Technically, everything is fine.

The problem is that nobody decided what the website was supposed to say or what visitors should do once they arrived.

Registering a domain feels like progress. Sitting down with a notebook and working out the purpose of each page does not feel nearly as exciting. Still, that quiet planning session can save days of redesigning later.

If you have not completed the technical setup yet, our guides to domain names, web hosting, and WordPress explain what those parts do. This guide focuses on what should happen before the actual building begins.

First, What Is the Website Supposed to Do?

The first instinct is usually to start listing pages: Home, About, Services, Blog, and Contact.

I would not begin there.

Before choosing pages, I want to know the main job of the website. What is the most useful action a visitor can take before leaving?

Consider an international nonprofit that supports families across several countries. Its website might need to help someone request assistance, explain how donations are used, or encourage a supporter to contribute.

Now compare that with a healthcare clinic serving patients in several locations. Its visitors probably want to check opening hours, review available services, find a doctor, or book an appointment.

The two websites could use similar technology, but they should not be planned in the same way. A donation button is important to the nonprofit. A clearly visible booking option is more important to the clinic.

Everything else should support that primary purpose. The team page, blog, photographs, testimonials, and background story can all be useful, but they should not compete with the action visitors came to complete.

Picture the Person Opening the Website

You do not need a forty-page customer persona document. A short, realistic description is often more useful.

For the clinic, I might write something like this:

A parent is checking the website from a phone in the evening. They want to know whether the clinic is open, whether a suitable doctor is available, and how quickly they can request an appointment.

That one description already influences the homepage. Opening hours should be easy to find. The phone number should be tappable. The booking button should not be hidden after several paragraphs of introductory text.

The nonprofit visitor could be different:

A potential donor has heard about the organization for the first time. They want to understand what it does, see evidence of its work, and confirm that the donation process is trustworthy.

That visitor needs clear impact information, transparent organization details, and a donation path that does not feel suspicious or complicated.

Once you can picture the visitor, deciding what belongs near the top of a page becomes much easier.

The Napkin Sitemap

After defining the purpose and audience, I would sketch the website structure on paper.

It does not need to look professional. Put the homepage at the top and draw the main pages underneath it. Add secondary pages only where they genuinely belong.

A healthcare clinic might begin with Home, Services, Doctors, About, and Contact or Book an Appointment. The nonprofit might need Home, About, Our Work, Impact Stories, Donate, and Contact.

That simple sketch becomes the foundation of the navigation menu. It also reveals problems early. If the structure requires several clicks before a visitor can reach an important service, it probably needs another look.

I also avoid creating empty pages just because other websites have them. A Careers page with no vacancies or useful information does not make an organization look larger. It simply gives the visitor a dead end.

Write the Words Before Choosing the Design

This is the part people skip most often.

It is difficult to design a useful page when every section contains Lorem Ipsum. Dummy text fills space, but it does not tell you how the final page will behave.

A short headline and a long headline create completely different layouts. A service description may need two sentences or six paragraphs. A donation page may require trust information, payment instructions, and answers to common questions.

I do not expect the first draft to be polished. It can be messy. The important thing is having real words available before the layout is finalized.

Write the homepage headline, introductory paragraph, service summaries, calls to action, and important contact information in a document. Then design around that content.

Doing it in the opposite order often leads to awkward compromises. The writer is forced to shorten useful information because the template allowed only three lines, or unnecessary text is added because the design has an empty box that needs filling.

Sketch the Homepage Before Opening the Builder

Starting directly in Elementor, Gutenberg, or another page builder feels faster. In my experience, it often leads to an hour of dragging blocks around without making a real decision.

A rough paper sketch is usually more helpful. Draw a rectangle for the browser window. Mark where the logo, navigation, headline, main button, services, trust information, and footer might appear.

You are not designing the final interface yet. You are deciding the order in which the visitor receives information.

For the nonprofit, the first screen might explain the mission and provide a clear donation or support button. Evidence of its work can appear immediately after that.

For the clinic, the first screen might show its main services, location, opening hours, and appointment option. A long history of the clinic can appear further down or on the About page.

A new visitor should be able to look at the opening section and understand what the organization does and where to go next. If the sketch cannot communicate that clearly, adding colors and animations will not solve the problem.

Do Not Forget the Boring Pages

Planning often focuses on the homepage while smaller but important pages are left until the last moment.

Think about the contact page, privacy policy, terms, cookie information, accessibility details, and any legal disclosures the project requires. An international website may also need to explain which countries it serves, which currencies it accepts, or how personal information is handled.

Forms deserve particular attention. Decide what information you genuinely need before adding fields. A general contact form probably does not need a visitor’s home address. Collecting unnecessary information creates more work and more privacy responsibility.

Error and confirmation messages should also be planned. After someone submits a donation, booking request, or contact form, the website should clearly explain what happened and what they should expect next.

Decide What Must Be Ready for Launch

Website projects can expand forever if nobody defines what “finished” means.

There is always another feature that sounds useful: live chat, multiple languages, a customer dashboard, an advanced search system, or a large content library. Some may be worth adding later. That does not mean they are all required before launch.

For a healthcare clinic, the appointment process, service information, contact details, mobile layout, and essential privacy pages may be required from the first day. Publishing twenty health articles could wait.

For the nonprofit, the donation process, trust information, impact details, and contact options should work properly at launch. A multilingual resource library might belong in a later phase.

I separate the project into two groups:

  • Required for launch: features and content the website cannot perform its main job without.
  • Useful later: improvements that can be added after real visitors begin using the site.

This keeps a useful website from sitting on a staging server for months while everyone debates minor design details.

Check the Plan on a Real Phone

A desktop wireframe can hide problems that become obvious on a smaller screen.

Imagine the homepage stacked vertically on a phone. What appears first? Is the main action still visible? Does a visitor have to scroll through a large photograph and several paragraphs before finding the booking or donation button?

Mobile planning should happen before the design is finished, not after. This is particularly important for international audiences, where many visitors may rely on mobile devices and slower connections.

The plan should also account for image sizes, readable text, simple menus, accessible buttons, and forms that are comfortable to complete on a small screen.

Put the Whole Plan on One Page

Before building, I like to reduce the project to a short planning document. It does not need impressive formatting. It only needs clear answers.

  • What is the website’s main purpose?
  • Who is most likely to use it?
  • What is the primary action visitors should take?
  • Which pages are required?
  • What content is already available?
  • What must work before launch?
  • What can be added later?

If those questions have honest answers, the design and development work becomes much less uncertain. The site has a direction, and every new feature can be judged against that direction.

Planning Is Part of Building

A website plan does not need to predict every future page or feature. It only needs to give the first version a clear purpose, a sensible structure, and a realistic finish line.

Start with the visitor’s problem. Decide what the website should help them do. Map the required pages, draft the real content, and sketch the order of the homepage before opening a builder.

It is not the most exciting part of creating a website, but it prevents a lot of expensive redesigning.

Once the plan is ready, our guide to what a website is and how it works will help you understand how the pages, files, database, hosting server, and visitor’s browser fit together.