Website content checklist for Kenyan businesses: what to give your designer

Describe what you sell, who buys it and the action the site should support. Include real service areas and limitations. A retailer seeking product orders needs different content from a consultancy seeking scoped project enquiries. Choose one primary outcome and list secondary actions rather than making every section compete for attention.

Provide your recognised business name, approved contact details, opening hours where relevant and account ownership contact. Explain how your team currently receives enquiries and what information it needs. Do not send passwords in the content brief; establish an appropriate account invitation or secure handover process separately.

For each distinct service, supply the audience, problem solved, included work, exclusions, process, timing assumptions and common buying questions. Give examples that staff can substantiate. If cost varies, explain the variables instead of copying an unrelated supplier's price table.

Use actual enquiry questions to structure the page. A school-site buyer might ask about admissions edits; a shop might ask how delivery charges work. Distinct needs justify distinct explanations. Google encourages helpful, people-first information; this does not mean a fixed word count or repeating the same location in every heading. Write naturally and keep the buyer's next decision visible.

Supply real project descriptions, permitted screenshots, approved testimonials and evidence for awards or numerical claims. Record who approved them and any restrictions. If an implementation is a concept, staging preview or release candidate, state that rather than calling it live. Sales outcomes need a measurement method and comparison period before publication.

Photographs should have useful filenames, captions and permission information. Keep genuine staff/client photos separate from stock or AI illustrations. An illustration can establish a topic, but it cannot prove you completed a client's project. Our existing work portfolio shows how projects can be linked from relevant service content; the details still need to match the actual work.

Use these checks to compare proposals against your real workflow. Mark each requirement as included, optional or excluded, and record the person responsible.

For products, use stable codes and separate attributes such as size, colour, pack count and selling unit. Put prices and availability in the agreed system of record instead of scattered design screenshots. Avoid inconsistent abbreviations that make imports and customer comparisons harder. The wholesale guide explains why pack definitions matter.

For downloadable files, confirm the current version, public audience and owner. Remove private information from files before supplying them for publication. A PDF should not be the only place essential contact or service information exists; give the designer readable page content too. If staff frequently changes notices, scope an editing workflow rather than emailing replacement files indefinitely.

Assign one person to collect decisions and reconcile conflicting edits. Define whether copywriting, photography, translation and data cleanup are included in the quote. A developer cannot safely invent business terms simply because content is late. Mark unresolved claims and keep those pages out of the publication scope until approved.

Review content on the actual layouts and a phone, then test the enquiry journey. A typo in the receiving email can matter more than a spacing choice. Use our project brief guide and send the website design team the completed worksheet. The first useful launch can be smaller than the eventual website, provided its public claims and contact routes are complete.