A website project plan exists for the moments between stages. Projects slip there more often than in the design or the code: they stall while everyone waits for copy, for a sign-off, for a login nobody can find, or for a translation that started before the source text was final.
This guide is for whoever runs the project on the client side, often for the first time. Your provider will have its own process. This is the half that sits with you: what to have ready, who decides and what really sets the timeline.
The short answer
A website project plan sets out the stages of the project, who owns each one, what has to be ready before the next starts and who signs it off. A typical project runs through eight stages:
- Brief and proposal
- Discovery
- Sitemap and content planning
- Design
- Build
- Content entry and translation
- Testing
- Launch and the first weeks after
How long it takes depends mainly on scope, content readiness, the number of approvers and languages, and the systems the site connects to. The timeline should be fixed in the written proposal, with dated milestones for both sides.
The eight stages of a website project plan
Stages overlap in practice, but none can finish without its inputs.
1. Brief and proposal
You describe the problem; the provider responds with a plan and a price. If you’re unsure what the site is for, settle that first with a website strategy: it makes every later decision faster.
Have ready. A written brief covering goals, audiences, key actions, languages, integrations, a budget range, who decides and any deadline that genuinely matters. Our guide on how to write a website brief includes a template.
Watch for. A proposal that gives a price without listing pages, features, revision rounds, exclusions and milestones.
2. Discovery
The provider tests your brief against evidence: stakeholder interviews, analytics and Search Console data, current content and the systems the site must connect to. Simple projects fold this into the proposal conversations; complex ones need a phase of their own, as our guide to the website discovery phase explains.
Have ready. Named user access to Google Analytics, Search Console, hosting and the domain registrar, rather than a shared password wherever the service allows it, plus interview time with key colleagues.
3. Sitemap and content planning
The structure is agreed: which pages exist, how they’re grouped, which templates they need and, on a multilingual site, which pages appear in which language. On a redesign, the list of old URLs to redirect starts here.
Every page also gets an owner, a short brief and a deadline, a step first-time project leads tend to underestimate. Our website content plan guide covers it from inventory to sign-off.
Have ready. A keep, rewrite, merge or cut decision on every current page, and a name against every new one.
4. Design
Key templates come first, such as the homepage and a typical service page, then the rest. Design attracts most of the opinions because it’s the visible part, yet it is one stage of eight: the structure, content, build and testing around it decide just as much about whether the site brings in enquiries.
Have ready. Brand guidelines, logo files, real photography and draft copy for the key pages. Real words expose problems that placeholder text hides.
Watch for. Separate feedback from several colleagues. Resolve the contradictions internally and send one consolidated set per round.
5. Build
The approved designs become a working site on a staging server, a private copy you can review before anything goes live: templates, the editing set-up, forms, integrations and tracking. Speed, mobile layouts and accessibility should be built in from the start, not fixed at the end.
Have ready. An account and a contact person for every connected system, such as a CRM or booking tool. Integrations often wait on those people rather than on the developer; website integrations explained covers what to specify.
6. Content entry and translation
Final copy and images go in page by page, with page titles, meta descriptions and alt text. Translation should start from approved source text, not drafts, and a fluent reviewer should check each language on the page, where awkward line breaks and untranslated button labels show up.
Have ready. Signed-off copy in every language, on the dates in the content plan. This is where many projects stall, because it depends on people whose day job is something else.
7. Testing
The provider checks forms, redirects, speed, browsers, devices and accessibility basics. In parallel, your side runs user acceptance testing: reading every page, submitting every form and confirming each enquiry reaches the right inbox.
Have ready. One shared issue list, each entry with the page address, the device, what you expected and a screenshot, sorted into “must fix before launch” and “can wait”.
8. Launch and the first weeks after
The site goes live, redirects switch on and the handover follows: admin logins, editor training and a named contact for issues. The first weeks matter as much as launch day: watch enquiries, indexing and missing pages, and fix what real visitors reveal. Then move into a continuous-improvement rhythm rather than waiting for the next redesign.
Have ready. A launch date everyone involved can make, and a named owner for the site after handover.
Website project roles and responsibilities
Many delays trace back to a role nobody filled. On a smaller project one person can hold several, as long as each role has a name. On the client side:
- Decision-maker. The final word on scope, design and launch. One person, even if they consult others.
- Project lead. Keeps the plan, consolidates feedback and chases content.
- Content owners. Subject experts, from sales to HR, who write or approve their pages.
- Language reviewers. Fluent speakers who check each language on staging.
- System owners. Whoever manages the domain, email, CRM or booking system.
On the provider side, expect a single point of contact plus the strategy, UX, design, development, content and SEO skills your scope needs. Ask who covers each, and whether the people who plan the site also build it.
| Stage | Client side owns | Provider side owns | Milestone |
|---|---|---|---|
| 1. Brief and proposal | Brief, budget, decision-maker | Written proposal: scope, price, timeline | Proposal signed |
| 2. Discovery | Data and system access, interview time | Interviews, data, content and technical review | Scope confirmed |
| 3. Sitemap and content plan | Page owners, deadlines, keep-or-cut calls | Sitemap, templates, redirect list | Sitemap and content plan approved |
| 4. Design | Brand assets, photos, consolidated feedback | Key templates, then full designs | Designs approved |
| 5. Build | System accounts and contacts | Staging site, forms, integrations, tracking | Staging site reviewed |
| 6. Content and translation | Final copy and translations | Content entry or editor training | Every language approved |
| 7. Testing | User acceptance testing | Technical testing | Sign-off to launch |
| 8. Launch and after | Launch date, issue reports, a named site owner | Go-live, redirects, editor training | Handover complete |
What really sets a website project timeline
You control more of these factors than you might expect.
Scope: templates matter more than page count
For design and build, twenty product pages sharing one layout can be less work than five pages that each look different. For content and translation it’s the reverse, since every page and every language adds work. Integrations are often the least predictable item, because each depends on another system and whoever runs it.
Content readiness
Design can start from draft copy, but testing needs final content and translation needs signed-off source text. Late content pushes every later stage back, which is why content deadlines are set backwards from launch.
Approvers and languages
Each extra approver adds a review. Sequential reviews stack up, and conflicting feedback can trigger rounds beyond those the proposal includes. Each language adds translation, in-context review, its own titles and descriptions, and form testing. Languages only move in parallel if every reviewer is free at the same time. Planning a multilingual website covers the workflow.
Put the timeline in writing
The timeline belongs in the written proposal. A useful one shows:
- dated milestones for both sides, not only the provider’s
- dependencies, such as design starting once the sitemap is approved
- a review window for each round of feedback
- what happens to later dates if either side slips
- a target launch date that depends on sign-off after testing
Where SEO work belongs in the plan
SEO isn’t a final stage. Left until testing, it can no longer shape the structure.
- Discovery: the searches you already appear for, what customers search for and, on a redesign, the pages whose traffic must be protected.
- Sitemap: pages planned around real searches, clean URLs and a redirect map.
- Build: editable titles and descriptions, structured data, an XML sitemap and fast, mobile-friendly templates.
- Content entry: titles, descriptions and headings for each page, in each language.
- Launch: redirects tested and the sitemap submitted in Search Console.
Providers include different amounts of this, so confirm it in writing. Our guide to whether web design includes SEO has a checklist to attach to any quote, and on a redesign the migration SEO checklist belongs in the plan too.
Launch readiness at a glance
Before you confirm a go-live date, every item here should be ticked:
For that last line, use our website launch checklist: run it on staging, then again once the site is live.
Frequently asked questions
How long does a website project take?
There’s no honest single figure without knowing the templates, languages and integrations involved, and how quickly content and approvals will arrive. Ask for dated milestones for both sides, so you can see which dates depend on you.
Who should lead a website project on the client side?
Someone with time to chase content and the authority to settle disagreements, or direct access to whoever has it. The most senior person is often the wrong choice, because they rarely have hours to spare each week.
What if we want to add pages or features halfway through?
Raise it as a change request and ask for the effect on cost and timeline in writing before any work starts. Many additions are better held for a second phase, when real visitor data can show whether they’re needed.
Should we fix the launch date from the start?
Set a target, but confirm go-live only once testing is signed off. If a deadline is fixed, such as a product launch or an event, protect it by launching less on day one, not by cutting testing or content review.
What to do next
A website project plan doesn’t need special software. A shared document with the eight stages, a name against every role and dates for both sides removes much of the waiting that stretches projects out. Start with the brief, because every later stage inherits its gaps, and read why website projects fail for the early warning signs worth watching.
If you’re planning a new site, our website design and development page shows how we run these stages, from the first conversation to handover. Replacing an existing site? Our website redesign service adds what a live site needs: every old URL redirected and a launch without downtime. Or send us your brief: after a free 30-minute consultation, you’ll receive a fixed-price proposal, with scope and timeline in writing, within three business days.