Start with decisions, not a list of pages. A five-page site with booking, payments, and staff permissions can carry more complexity than a larger editorial site. If you are about to request a proposal, write down the first action you want a qualified visitor to take. Then describe what happens to that inquiry. That single path exposes the content, integration, privacy, and operations questions that a page-count estimate misses.
What outcome should the site support?
Name one primary business outcome. It may be a qualified inquiry, an appointment request, a purchase, or a member login. Name a secondary outcome only if it serves visitors who are not ready for the first. For each outcome, identify the page where the decision begins, the action that completes it, and the person who responds afterward.
Write the audience in ordinary language. What are they trying to decide when they arrive? What do they already know? What would stop them from trusting the next step? A local service buyer may need coverage and contact details. A wholesale buyer may need product specifications and a separate inquiry route. Those are different requirements even if both sites have an About page.
Which content and functions are essential?
List the content types, not just the initial page titles. Services, team members, projects, locations, products, and articles may each need their own editing fields, archive view, and relationship to other records. Identify who can edit each type and how often it changes. A structured content model keeps a growing catalog from becoming a collection of copied page sections.
Next, describe each function as a user action with a completion state. For a booking flow, note available appointment types, time zones, confirmation messages, cancellation rules, and staff notifications. For a lead form, note required fields, validation, destination, and what visitors see if submission fails. Include accessibility and mobile use as requirements of each flow, not an afterthought.
What systems must exchange information?
Record each current tool that the website must connect to. For every connection, name what data moves, in which direction, who owns the account, and who notices a failure. A CRM connection that only creates contacts differs from one that updates deal stages or suppresses duplicates. A payment tool adds settlement, refund, and reconciliation decisions beyond the checkout screen.
If an integration is still uncertain, describe the outcome it must support rather than choosing a tool too early. Can staff perform the same step manually at first? What volume would make automation worthwhile? This separates a launch requirement from a later enhancement.
Who owns the site after launch?
Identify the owner for domain access, hosting, content editing, analytics, form notifications, backups, and vendor billing. Set an approval path for public content and a person who can answer questions about policies. A launch without ownership leaves routine updates dependent on whoever last touched the builder.
Add acceptance checks that can be observed. Examples include submitting a form on a phone, editing a service record without rebuilding a template, confirming a test event in analytics, and restoring a backup in a safe environment. State what material the project team will receive at handoff. The website pre-handoff QA checklist covers a later verification stage. This page helps you define the work before it starts.
What should you do with this website requirements checklist?
Bring the outcome, audience, content inventory, function list, integrations, and ownership map into a scoping conversation. Mark what is required for launch and what can wait. That makes tradeoffs visible and helps a proposal explain deliverables instead of hiding assumptions inside a single number.
For a site that needs connected features and editable content, see web development. If you want help turning your notes into a practical scope, Talk to a Specialist.
