Write a website brief before you redesign.

A website brief is a shared description of what your site needs to do, what will be included, and who makes the decisions. Use this guide to prepare a new website or a focused redesign. Copy the questions into a document; write “to decide” wherever you do not yet have an answer.

MerkadAgency editorial guide · Updated October 20, 2026. You can print this page using your browser. No form or download is required.

1. Describe the business and the visitor

• What does your business offer today? Which services should not be advertised?
• Who is the primary visitor, and what do they need to know before contacting you?
• What should they be able to do: understand a service, find a location, read instructions or send an inquiry?
• What would make the website useful even if the visitor does not contact you immediately?

Example brief sentence: “We need a website that explains our current services, answers common questions, and gives visitors a clear email contact.” Adapt it to your business rather than treating it as a promised result.

2. Inventory the existing site

For a redesign, list each current URL with its purpose, content owner and proposed action: keep, update, combine or retire. Record any available search or referral evidence without inventing traffic figures. If you do not have access to reporting, mark that evidence unavailable.

• Which pages have accurate information worth keeping?
• Which pages answer the same question and could be combined?
• Which old addresses have useful links pointing to them?
• Where should a moved page redirect? Choose the closest relevant replacement.

Keep a copy of the current URL inventory. A visual redesign and a URL change are separate decisions.

3. Map one purpose to each page

Start with the fewest pages needed to answer real visitor questions. For each proposed page, write its audience, main question, approved evidence and next step. Avoid separate pages that repeat the same service description with only a city or industry name changed.

Example inventory: a homepage introduces the business; a service page explains the work and scope; a contact page gives an approved contact method. Add other pages only when they provide distinct, useful information.

4. Gather content and permissions

• Who will write and approve the service descriptions?
• Which photographs, illustrations and brand assets can you legally use?
• Do you have explicit permission for customer names, logos, quotes and project images?
• Can you substantiate each claim about qualifications, results or capabilities?
• Which claims should be removed or left unpublished until evidence is available?

Do not use placeholder testimonials or invented figures to fill a layout. A clear description of your process can be useful without customer proof.

5. Define functions and ownership

• Is email enough for contact, or is another verified tool necessary?
• Who owns the domain, hosting account and any external accounts?
• Who may publish changes and who will maintain the site after launch?
• What data would a form collect, where would it go, and who would handle it?
• Which features depend on a service or account that is not ready?

List those dependencies separately. Do not let a planned integration appear to be available before it works. Share requirements rather than passwords or customer records.

6. Compare proposals on the same scope

Ask each provider to identify the included pages, content work, design reviews, supported browsers, testing, handover, ongoing costs and exclusions. Discuss your budget and target date, but ask for written confirmation before treating either as agreed.

• What happens when the scope changes?
• Who approves the final content and release?
• Which accounts and files will you receive?
• Which support or maintenance tasks are included, and for how long?

7. Agree launch checks before building

Write a short acceptance list that a person can actually perform:

1. Open key pages on a phone and desktop; read the headings and body text.
2. Use navigation with a keyboard. Check that focus is visible and links make sense.
3. Confirm the contact address and open an email draft without sending a test message.
4. Check old URLs, redirects, titles, canonical URLs and the sitemap.
5. Confirm that private or unapproved material is absent from public files.
6. Name the person who will monitor the release and decide whether to roll back.

Record checks that were not performed. An automated scan does not replace physical-device or screen-reader review.

Send the brief when you are ready

For MerkadAgency’s approach, read website development and project scope. To discuss a project, email Camilo with your brief or the decisions you still need to make.

For further reading: Google’s guidance on helpful content and W3C accessibility Easy Checks. These are planning references, not a guarantee of search performance or an accessibility certification.