Your client isn't late. Your content request is too vague.
The homepage is designed. The services page is built. Your client still hasn’t sent the copy, and your next email says, “Just checking in on the content.” To get website content from clients, stop asking for “the content” and give them a short, page-by-page list of facts, files, and decisions they can actually supply.
That distinction changes the work. A client can tell you which service brings in the most inquiries. They may not know how to turn that answer into a homepage headline, three service cards, and a call to action. If your request assumes they can, another reminder won’t solve it.
Decide who writes before you request anything
At kickoff, put one sentence in the scope: who provides the facts, who writes the final copy, and who approves it. Those are three separate jobs. When you leave them bundled under “client to provide content,” each side can reasonably think the other side is writing the page.
If your studio writes copy, ask the client for source material: services, prices or pricing approach, locations, credentials, customer questions, and examples of past work. If the client writes copy, give them a page structure and an approximate length for each section. If a copywriter is involved, name who gathers the inputs and who consolidates feedback. Don’t wait until design approval to discover that nobody owns the words.
Choose one client contact to coordinate submissions and one person who can approve them. Those people can be the same, but they don’t have to be. A page isn’t approved because four people commented on a document; it’s approved when the named decision-maker says the current version is ready to use.
Turn the sitemap into a content request
“Send us your website content” is a project-sized assignment with no visible finish line. A page list makes the finish line visible. Start with the agreed sitemap, then break each page into the sections you intend to build. For every section, name the information you need and the format you can use.
For a five-page service business website, the request might look like this:
| Page | What to request from the client | What your team will produce |
|---|---|---|
| Home | Main service, service area, strongest proof, primary action, two suitable photos | Headline, section copy, calls to action |
| About | Founding story, team names and roles, credentials, team photos | Story and bios |
| Services | For each service: who it helps, what’s included, typical process, exclusions, related photo | Service descriptions and page structure |
| Work | Three projects, each with the problem, work done, result, and permission to show images | Case studies |
| Contact | Public phone, email, address or service area, opening hours, form recipient | Contact page and form labels |
This is a starting map, not a form to send unchanged to every client. A restaurant needs menus and opening hours. A consultant may need offer boundaries and booking details. Remove fields that don’t apply, and add the ones that would block your specific build.
Ask for existing material before requesting new writing. The client may already have a brochure with service descriptions, a sales deck with proof points, a booking page with policies, or a folder of original photos. Have them point you to the source and identify what is still accurate. Your team can extract and organize it instead of making the client rewrite it in a new document.
Ask questions a busy client can answer
An empty field labeled “About us copy” invites a blank response. An instruction to “write 300 words about your values” invites generic copy. Ask for information only the client knows, in plain language:
Who calls you most often about this service? What problem do they describe? What do you do first, and what happens after they contact you?
For an About page, ask what changed when the business started, what the team does differently in practice, and which credentials must be shown. For a services page, ask what is included, what isn’t, and what a typical customer needs to know before booking. For testimonials, ask which customers have already agreed to be quoted and who can confirm permission.
Give one example answer where a question could be misunderstood. “Service area: Seattle, Bellevue, and Redmond” is more useful than “Where do you work?” A short example sets the level of detail without making the client copy your words.
Keep the request small enough to finish in one sitting. It’s fine to collect the homepage and contact details first, then move to the remaining pages. The goal isn’t to hide the total amount of work. It’s to make the next action obvious.
Collect files where they’ll be used
Copy is only part of the handoff. A page can have approved words and still be blocked by a missing logo, a blurry image, or an unconfirmed contact address. Put file requests next to the page or section they belong to: the team photo beside the About bios, project images beside their case study, and a service photo beside its description.
Specify what “send the logo” means. Request the original vector file if one exists, plus a transparent PNG if the client has one. Ask for original photo files rather than screenshots or images downloaded from a messaging app. For each image, collect what it shows, where it can appear, and whether the client has permission to use it. If the client can’t find the original, mark that gap now so the design doesn’t depend on a file that may never arrive.
Keep global details in their own short list: business name, public phone and email, address or service area, social profiles, and the destination for contact form messages. These details appear across pages, so one unconfirmed phone number can stall more than the Contact page.
Give each page a status and an owner
You don’t need elaborate project software to track content. You do need a shared answer to “what’s missing?” Give each page a status such as not started, waiting on client, ready for review, changes requested, or approved. Record the next owner beside it. A status without an owner still leaves your team guessing who should move it forward.
Set dates for specific deliverables, not a single deadline for the whole website. For example: homepage facts and global details by Tuesday, service details by Thursday, and client review of the first drafted page on Friday. These dates should fit the client contact’s actual availability. If the owner is away that week, agree on a different owner or move the date before work is scheduled around it.
Tell the client which pages are needed before design can progress and which can follow. You may be able to start layout with a confirmed service list and rough copy, while a case study waits for image permission. Make that dependency explicit. “We can build the homepage after you confirm the services and main call to action” is more actionable than “we can’t proceed until all content is in.”
Review submitted content before it reaches the build
A submitted answer isn’t automatically page-ready. Check it while the client’s context is fresh. Does a service description explain what is included? Is a claimed result supported by a number or a usable example? Are photos large enough for their intended placement? Is the contact form going to a monitored inbox?
When something is missing, request a specific correction on the same page or field. “For the maintenance service, tell us whether emergency visits are included” is a task. “The services copy needs more detail” is another writing assignment with no boundary. Keep a record of the original answer, the requested change, and the final approved version so old text doesn’t slip back into the build.
Approve page by page. A client can sign off on Home while About still needs a team photo, and your team can use the approved homepage copy with confidence. If approval comes through email, quote or link the exact version being approved. “Looks good” in a long thread may refer to a draft from last week.
Follow up on the missing item, not the whole project
Before a due date, send a short reminder that names the remaining item and its effect on the schedule. After the due date, ask for a new delivery date and explain what work is waiting. Don’t send a generic “any update?” message when your tracker can tell you exactly what’s missing.
For example:
Hi Alex, the Home and Contact pages are ready. We’re waiting on the original team photo and confirmation of the two services listed on About. Can you send those by Thursday? If not, tell me a date that works and I’ll update the build schedule.
If the client is stuck because they don’t know what to write, offer a 15-minute call and take notes against the missing fields. If they lack the photo, agree on a different image or a layout that doesn’t need one. If they haven’t answered because three colleagues disagree, return to the named approver. The remedy depends on the blocker; more reminders aren’t a substitute for finding it.
Make the next project easier
After launch, look at the requests that caused the most back-and-forth. Add a clearer example, remove an unnecessary question, or move a request earlier. Keep your page structure as a reusable template, but update it for the next client’s business and the pages you’re actually building.
The repeatable process is simple: assign writing and approval roles, map the sitemap into page-level requests, gather facts and original files, review each submission, and approve a specific version. A website content collection workflow can keep those pieces together. The useful part is the structure: your client knows what to send next, and your team knows which page is ready to build.