New website

Create a website

A new website should do more than provide a modern appearance. It needs to help first-time visitors understand the activity, find the service that fits their situation, see credible evidence and take the next step without unnecessary friction. We turn your ideas, existing documents and practical knowledge into a coherent set of pages with an obvious opening message, developed service information, useful proof, comfortable mobile reading and a visible contact path. The proposed structure reflects the content you can genuinely provide and maintain. It can begin with a focused foundation and leave room for future services, articles, local pages or features without forcing the entire website to be rebuilt.

The goal is to make the website clearer for visitors, easier to maintain and better organised for search engines, local discovery and AI-assisted answers.

Discuss this need

Photo illustrating the service Create a website

Your situation

Build a useful first version around real visitor tasks.

This service suits an activity that needs a dependable public website, or an organisation replacing scattered profiles and documents with a clear home for its information. The starting point can be modest: an offer, the people it serves, existing proof and a way to make contact. The scope should grow from those needs rather than a preset number of pages.

Decide what each page must answer

List the questions received before a first conversation: what is provided, for whom, where, under what conditions and what happens next. Turn those answers into a small page map. Give every page one primary purpose, a content owner and a route back to the relevant service or contact step.

Prepare content and functions together

A booking button, quote form or product catalogue is only useful when its surrounding explanation is complete. Agree the required fields, confirmation messages, error states and who handles each request. Mark photographs, testimonials, prices and qualifications as approved only after their origin and right of use have been checked.

Accept the site through practical journeys

Before launch, complete the main tasks on a phone and with a keyboard: find an offer, understand its limits and send a valid enquiry. Check the confirmation, navigation, images, language versions and public contact details. Record what the owner can update independently and what will need support. Acceptance uses agreed journeys: reach a service from a search, understand what its price includes and send a complete enquiry. Each journey records its starting point, expected outcome and approver. Domain ownership, access details and update instructions are included in the handover.

What to prepare

Offers, audiences and a sample enquiry to handle at launch.
Available copy and images, with the people approving their publication.
Domain holder, existing services and genuinely required launch deadline.
One person able to approve each published language

How to verify the result

A person finds the relevant offer and its conditions from the home page on a phone.
A synthetic enquiry retains the selected service through to the message actually received.
The team corrects a fact using authorised access and knows which renewals to track.

Continue with the practical guide: Prepare a website brief.

Decision points

Decide the right starting scope

Situation to examine

A first release can be complete with few pages when it explains the offer, audience, conditions, available evidence and contact route. With several services, the page map should reflect real differences in audience, process, coverage and recurring questions.

Choice to make

Start with three plausible visitor tasks and map each to a page and next action. Booking, payment or search belongs in the first release only when its behaviour, owner and error states are clear. Missing content must enter the schedule before layouts are finalised.

Evidence of success

Acceptance can follow those tasks on a phone and with a keyboard, then check the message received and confirmation shown. A content inventory and handover list make the launch useful to its owner.

How to write a website brief that helps decisions →

Steps

A simple, readable and followed progression.

Listen

Understand your need, audience and current difficulties.

Clarify

Choose the pages, messages and priorities that are truly useful.

Build

Produce the required elements and validate progressively.

Support

Help you follow, correct and enrich the website over time.

Read the evidence

A confirmation message does not prove delivery

Fictional teaching example · no client result or live site measurement

Before a fictional site launches, three identifiable enquiries are submitted. Each enquiry is followed through to its recipient rather than stopping at the confirmation screen.

Visitor input
Form processing
Receipt and reply

On a small screen, scroll the table horizontally to read all three columns.

Fictional observations to interpret
Test enquiry	Screen shown	Delivery check
A · desktop	Confirmation displayed	Received in the intended inbox
B · phone	Confirmation displayed	Missing from the inbox and spam folder
C · phone	Error next to the email field	No submission expected until corrected

What can we conclude?

Enquiry A verifies a complete journey under the tested conditions. Enquiry B remains unresolved despite its confirmation. Enquiry C shows explicit input rejection; after correction, another test must reach the recipient.

What should be checked next?

Record the time and a test reference for B, then inspect server processing and email delivery. Do not claim confirmed receipt before that step is established.

What makes this check reusable?

Context to specify : Form version, URL, device, configured recipient and time with time zone.

Evidence to retain : Reference TEST-01, stage reached and exact message; no real personal address.

Decision to prepare : For B, separate server processing, email acceptance and arrival at the recipient.

Explore the check further : Verify that website emails actually arrive

Scope and limits : Three attempts do not cover every device or email provider. Test references should not contain real personal information.

Method reference : W3C WAI · Form notifications. Source consulted 2026-10-22. This reference explains the method; the observations presented are invented.

Frequently asked questions

Detailed answers about scope, decisions and delivery.

The final wording can evolve, but the core offer, audiences, service conditions and next action should be known before choosing page layouts. A short content inventory shows what exists, what must be written and who can approve it. This avoids building polished placeholders that later cannot accommodate the real information.

Yes, if its structure, navigation and content ownership allow growth. It is often better to publish a coherent set of complete pages than many unfinished ones. Later additions can be planned from recurring questions, observed enquiries and the organisation’s ability to maintain them.

Start from distinct audience needs: understand the offer, check conditions, examine evidence and contact the organisation. A new page needs its own useful information and journey. Validate the count after inventorying content and update responsibilities.

Repeat priority tasks on the final domain, confirm receipt of a test enquiry and obtain an inventory of files, services and publishing permissions. Establish domain ownership, renewal responsibilities and how the team edits a page.

Functions that do not underpin the main journey, such as automated booking, an account area or an additional language. The first release still needs a clear offer, conditions and a tested contact route. Record deferred work and the need that would justify it.

Let us be concrete

Where is the main blockage today?

Present the project

Practical checks to prepare

Design a contact form that genuinely helps
Choose necessary fields, make the form accessible, handle errors and verify that enquiries arrive and receive a response.
Verify that website emails actually arrive
Forms, confirmations and newsletters: check senders, authentication, bounces and delivery follow-up.

Related topics

Documented reference points for this topic

Documented reference points for this topic
Reference	Value or syntax	Scope
WCAG 2.2 · 1.4.3	`4.5:1 / 3:1`	Normal / large text (18 pt or 14 pt bold); criterion exceptions apply.
WCAG 2.2 · 2.5.8	`24 × 24 CSS px`	A smaller target can satisfy the criterion through spacing; other exceptions apply.
WCAG 2.2 · 1.4.10	`320 CSS px`	Vertical content without two-dimensional scrolling; exceptions cover inherently two-dimensional content.
Google Search Central · Multilingual sites	`URL · hreflang · links`	Provide separate URLs per language and links for choosing an edition. Redirecting on an assumed language can prevent access to a version. Translating only navigation and footer does not translate the main content.

Sources consulted on 22 October 2026. These points are neither a website audit nor an overall conformance statement.