How to Plan a Website: The Complete Planning Guide
Most website development projects do not run late because the code was hard. They run late because the plan was thin: nobody agreed what the site had to achieve, who would write the text, or what "done" meant.
This guide covers the planning work that happens before design and build, in the order it is actually useful, and the decisions that are expensive to change later.
Start with one job the site has to do#
A website that has to do everything usually does nothing measurably. Before anything else, write down the one action that matters most: a form submission, a phone call, a purchase, a booking, a download.
Everything downstream — page structure, navigation, what goes above the fold, how much you should spend — falls out of that answer. A site whose main job is generating enquiries is a different build from a site whose main job is selling 4,000 products.
- Primary goal: the one action you would keep if you could only keep one.
- Secondary goals: useful but not worth compromising the primary for.
- How you will measure it: a number you can check next quarter, not "more traffic".
- What the site does not need to do: written down, so it stays out of scope.
If two people in your organisation would name different primary goals, that disagreement will surface in week six of the build. Resolve it in week zero, when it costs a meeting instead of a rebuild.
Know who is arriving and what they came for#
Audience research does not need to be a formal exercise. What you need is a short, honest description of the two or three groups who actually visit, what question each one arrives with, and what would make them leave.
| Visitor | Arrives asking | Leaves because |
|---|---|---|
| First-time buyer | Can these people do what I need? | No proof, no prices, no clarity |
| Returning customer | Where is the thing I need now? | The task is buried three clicks deep |
| Someone comparing | How is this different from the others? | Generic copy that could be any competitor |
| A job applicant | What is it like to work here? | No careers page, or one that is stale |
Decide the pages before you decide the design#
Page structure is the cheapest thing to change on paper and one of the most expensive things to change after a design is signed off. List every page, group them into sections, and mark which ones are needed for launch and which can come later.
The common failure is a structure that mirrors your org chart rather than the visitor's task. Nobody arrives looking for your "Solutions Division"; they arrive looking for the thing they need.
- List every page you think you need, one per line, without grouping.
- Mark each as launch-critical or later. Be strict: most sites launch with fewer pages than planned.
- Group the launch-critical ones into no more than five or six top-level sections.
- Write the one sentence each page has to deliver. If you cannot, the page probably should not exist.
- Check the primary goal is reachable in one click from every top-level page.
Content is the critical path — plan it first#
Text, photographs and product data hold up more launches than any technical problem. The build finishes and the site sits in staging for six weeks waiting for an About page.
Decide now who writes each page, who approves it, and when it is due — and treat those dates as seriously as the development milestones. If nobody internally has time, budget for a copywriter; it is cheaper than an idle development team.
- Name an owner and a due date for every page of text, not "marketing".
- Decide what happens to existing content: migrate, rewrite or drop. Most of it should be dropped.
- Book photography early — it has the longest lead time of anything on the list.
- For a store, export and clean the product data before the build starts, not during.
- Agree who has final approval. Two approvers with equal authority is a schedule risk.
A useful test: if the site were finished tomorrow, could you fill it? If the answer is no, content is your real deadline.
Set a budget range and a decision on the build approach#
Planning ends with two numbers and one choice: what you can spend, when you need it live, and whether this is a template build, a CMS build or a custom build. Those three decide who you should even be talking to.
| Approach | Fits when | Main risk |
|---|---|---|
| Website builder | Small brochure site, no unusual requirements | You hit a ceiling and have to start again |
| CMS (e.g. WordPress) | Content-led site, frequent updates by non-developers | Plugin sprawl and ongoing maintenance |
| eCommerce platform | Selling products, standard checkout needs | Platform fees and limited customisation |
| Custom build | The site is the product, or integrations rule others out | Highest cost, and you own the maintenance |
Frequently asked questions
How long should planning take?
For a small business site, one to two weeks of real work — not elapsed time. For a store or an application, three to six weeks, most of it spent on content inventory and product data rather than on documents. If planning is taking months, it usually means the primary goal has not been agreed and the discussion is circling.
Do I need a formal requirements document?
You need something written that both sides can point at, but it does not have to be long. A page structure, a list of features that are in scope, a list of things explicitly out of scope, and a content owner per page will prevent more disputes than a fifty-page specification nobody reads. The out-of-scope list is the part people skip and the part that saves the project.
Should I plan the design at this stage?
Plan the structure, not the look. Deciding what pages exist and what each one has to achieve is planning; choosing colours and typefaces is design, and doing it before the structure exists means the design gets rearranged as soon as the real content arrives. Wireframes are the useful middle ground.
What if the requirements change mid-project?
They will. What matters is that you agreed in advance how changes are handled: who can request one, who prices it, and whether it moves the launch date. A project with a change process runs late in a controlled way; a project without one runs late in an argument.
website planninghow to plan a websitewebsite project planwebsite requirementswebsite structurewebsite development planning
