Website Checklist for Clients: What to Prepare, Review and Approve
10/15/2026 · 6 minute read · By Swelik
A client-facing checklist covering the decisions and materials needed before design, during review and at handoff, with a simple readiness tracker.
A useful website checklist for clients explains what you need to provide and what you need to decide. It should not require you to become a designer or developer. Your job is to supply accurate information, identify the right decision owner and review the work against the business goal.
Use this checklist throughout a small website project. Mark each item ready, waiting or not applicable. Add an owner and due date when something is missing. A checklist with responsibilities is more useful than a long list of unchecked boxes that nobody owns.
Before design: agree the purpose
Write a short description of the visitor you want to help and the action you want that person to take. For a local service business, that action might be requesting a quote. For a professional portfolio, it might be booking a conversation. Avoid describing the goal only as making the website look modern.
Agree which pages and features are part of the project. A contact form, an appointment system and an online store have different requirements. Ask which items are included, which depend on outside services and which are planned for later. Record important unknowns instead of letting them become assumptions.
Nominate the decision owner
Choose the person who can consolidate feedback and approve the next step. Other colleagues can contribute information, but the designer needs a clear answer when suggestions conflict. Tell everyone which person will return the combined response.
Also identify the owners of business facts. The person approving the visual design may not know whether a service description, price or location is accurate. Give those checks to someone who does, and bring the confirmed information back into the shared project record.
Prepare the content and brand materials
Provide usable logo files, brand colors if you have them, approved photographs and the latest wording. Label material that is provisional. Do not mix an outdated brochure with new website copy without explaining which information takes priority.
Create a page list and attach the relevant content to each page. For a service page, that may include the service description, audience, process, common questions and next action. A collection of unrelated documents is harder to use than a simple page-by-page content pack. The website content checklist gives a detailed structure.
Confirm practical details early
Check the business name, address, telephone number, public email and opening hours. Decide where contact-form messages should go and who will monitor them. If a booking or payment provider is involved, identify the account owner and the person responsible for setup.
Share access using the provider's invitation or role system where available. Keep passwords and private access links out of public mockup comments. A website review destination is for discussing the work, not for collecting account credentials.
During design: review the agreed questions
When the designer sends a mockup, first confirm what kind of artifact you are seeing. A static image shows appearance. A prototype can demonstrate a planned flow. A staging website shows an implementation. A button in a static image is not expected to submit a real enquiry.
For an early design review, check whether the first screen explains the offer, whether the section order makes sense and whether the primary action is easy to identify. Confirm the factual details separately. Use the client preview guide if you need help distinguishing the review surfaces.
Leave feedback the designer can use
Name the section, describe the problem and explain the outcome you want. “The pricing section does not say whether installation is included” is more useful than “change the pricing.” It allows the designer to solve the actual uncertainty.
Send one consolidated response by the agreed date. If you need input from colleagues, gather it before returning instructions. When opinions conflict, resolve the priority internally rather than asking the designer to guess which comment should win.
Before approval: inspect the current revision
Reload the preview after the designer announces an update. Check the requested changes and note anything still provisional. Record what you are approving: the desktop layout, the copy, the mobile design or another named deliverable.
Swelik lets a designer replace a mockup while keeping its public URL. That makes returning to the review convenient, but the content at the link can change. Include the revision or date in an important decision and retain the approved export in the project archive.
Before launch: review the working site
Check the implemented website on a phone and a desktop. Follow the main visitor journey. Open navigation links, submit a clearly labeled test enquiry and confirm that the right person receives it. Ask the developer which technical checks they have completed and which still need attention.
Visual approval does not establish accessibility or functional quality. W3C's Easy Checks is an introductory resource for reviewing some accessibility concerns, not a complete assessment. Agree the appropriate evaluation for the project rather than treating a pleasing screenshot as proof that everything works.
At handoff: know what you own and maintain
Confirm where the domain, hosting, content system and connected services are managed. Identify the account owners and renewal responsibilities. Ask for the source materials and documentation included in the agreed handoff, plus a demonstration of routine tasks you will perform yourself.
Keep a record of outstanding items and the support arrangement. A handoff is clearer when both parties know how to report a problem and which future changes are new work. See the website handover checklist for a practical handoff inventory.
A compact readiness tracker
Use five fields for each item: item, status, owner, due date and evidence. For example, the contact number may be ready with the office manager as owner and the approved content document as evidence. The team photo may be waiting with the client as owner and a planned delivery date.
Review the waiting items at each milestone. This makes missing inputs visible without turning every conversation into a general reminder. Remove items that genuinely do not apply, and keep the tracker focused on the actual project.
Frequently asked questions
Do I need to write all the website copy myself?
That depends on the agreed scope. Even when someone else writes it, you still need to provide accurate business information and nominate a reviewer. Decide who drafts, checks and approves the copy before the design depends on it.
Can I approve a desktop mockup as the complete website?
Only approve the deliverable you actually inspected. A desktop image does not demonstrate mobile layout, working forms or the completed website. Ask for separate reviews where those decisions are required.
What is the most important item on the checklist?
A clear owner for each decision and missing input. Without that, even a detailed checklist can stall. Prepare the material, review the right artifact and give the team an unambiguous next step.
Put this into practice with Swelik’s mockup sharing and review tools.