How to Plan a Website Project

A website project becomes difficult when design starts before the business has agreed what is being built, who is responsible for each decision and what “finished” means. Planning does not need to become bureaucracy. A concise plan should remove uncertainty, protect the budget and make delays visible early.

This process works for a new small-business website, a redesign and a move to a different platform. It can be used whether you are building the site yourself, working with a freelancer or commissioning an agency.

Step 1: define the result and the boundary

Begin with the website objective, audience and primary action. Then describe the boundary of the first release.

Write down:

• the pages included;
• the functions included;
• the content and media required;
• the systems that must connect to the site;
• the devices and browsers that must be tested;
• what is explicitly outside the project.

“A new website” is not a useful scope. “A 12-page service website with an enquiry form, case studies, migrated blog content and redirects from the existing URLs” is much closer.

Step 2: inventory what already exists

Before replacing anything, identify the assets and accounts the business already owns:

• domain registration and renewal access;
• DNS and hosting;
• business email;
• current website files and database;
• analytics and Search Console;
• logos, fonts, photographs and licences;
• page copy, product data and downloadable documents;
• forms, payment services, booking systems and third-party integrations;
• existing URLs and pages receiving traffic or enquiries.

This prevents a redesign from accidentally interrupting email, losing valuable URLs or recreating assets the business already has.

Step 3: assign responsibilities

Every important deliverable needs one named owner. “The team” is not an owner.

Typical project responsibilities

Responsibility	Questions to settle
Business decisions	Who can approve scope, budget, positioning and final launch?
Content	Who writes, supplies evidence, checks accuracy and approves the final copy?
Design and build	Who produces each deliverable and corrects defects?
Technical access	Who controls the domain, hosting, email, analytics and recovery details?
Testing	Who checks forms, payments, mobile layouts, redirects and accessibility?
Ongoing ownership	Who handles updates, backups, security, licences and future content?

Step 4: organise dependencies before dates

A schedule should reflect dependencies. The home page cannot be approved properly without real content. A booking journey cannot be tested without an account and realistic booking rules. Redirects cannot be prepared without the old URL list.

A practical sequence is:

1. objectives, scope and ownership;
2. content inventory and information architecture;
3. wireframes or page plans;
4. approved content and visual assets;
5. design system and representative templates;
6. development and integrations;
7. content entry and migration;
8. testing and corrections;
9. launch preparation;
10. post-launch verification.

Some stages can overlap, but starting everything at once usually hides blockers rather than saving time.

Step 5: create decision points

Agree when the business will approve:

• the sitemap and page purpose;
• one representative design direction;
• the page templates;
• the working functionality;
• the migrated content;
• the launch version.

Each approval should state what was reviewed and what changes remain. Avoid vague sign-offs such as “looks good” if important content, mobile behaviour or functionality has not been shown.

Step 6: control changes

New ideas are normal. The project needs a simple way to decide whether they belong now or later.

For every change, record:

• what is being requested;
• why it is needed;
• which existing work it affects;
• the additional cost or time;
• whether something else must be removed;
• who approved it.

Keep a “later” list for worthwhile ideas that are not necessary for launch. This protects the first version from becoming an endless build.

Step 7: plan content as a production task

Content delays many website projects because it is treated as something to add at the end. Build a page-level tracker with fields for:

• page owner;
• draft status;
• facts or evidence still required;
• photographs or diagrams;
• legal or specialist review;
• approval;
• entry into the website;
• final proofread.

Use real copy in the layouts as early as possible. Placeholder text hides problems with hierarchy, length and missing information.

Step 8: define acceptance criteria

A project should not be accepted simply because pages appear on a screen. Define what must be true before launch and before final payment.

Examples of acceptance criteria

Area	Example check
Content	Approved copy is present; no placeholder text or invented claims remain.
Mobile	Important journeys work at 320–430 px without page-level horizontal scrolling.
Forms	Valid submissions arrive, errors are understandable and spam protection does not block normal users.
Ownership	The business controls the accounts, licences, recovery methods and administrator access.
Search	Important pages are crawlable, have sensible titles and are included in the intended sitemap.
Recovery	A backup exists and the restoration process is understood.

Step 9: prepare the launch and rollback plan

Decide who performs the launch, when it will happen and what will be checked immediately afterwards. For an existing site, preserve a restorable copy and document how to return to the previous version if a critical problem appears.

The launch plan should cover:

• domain and DNS changes;
• business email protection;
• redirects from old URLs;
• forms, bookings and payments;
• analytics and Search Console;
• backup and rollback;
• the person authorised to stop the launch.

Step 10: schedule the first review

Agree the post-launch review before the project closes. Check technical faults within the first few days and review real user behaviour after enough evidence has accumulated.

Record defects separately from new feature requests. A form that does not submit is a defect. A request for a new customer portal is a new scope.

A compact project plan

A small website can often be controlled with five working documents:

1. the brief and scope;
2. the sitemap and content tracker;
3. the responsibility and access register;
4. the decision and change log;
5. the test and launch checklist.

The next practical step is to create these five documents before approving design work. They are more valuable than a detailed schedule built on unresolved decisions.