How to Collect Content for a WordPress Website from a Client
A WordPress build usually stalls waiting on the client for copy, images, and access, not on the build itself — here is what to ask for and in what order.
What a WordPress build actually needs
Break the request into what blocks development, what blocks launch, and what can arrive later. Asking for everything at once, with no ordering, is what makes a client freeze and send nothing.
| Item | Why it's needed | Timing |
|---|---|---|
| Logo (SVG or high-res PNG) | Needed for the header, favicon, and any print use. A resized JPEG will not scale cleanly to a retina header or a favicon. | Before build starts |
| Brand colors (hex codes) | Sets the theme's color palette. Without hex codes, sample from a phone photo of something branded rather than guessing from a screenshot. | Before build starts |
| Per-page copy (headline, body text, CTAs) | Placeholder text can hold a layout, but final copy changes line counts and section heights — build it in once it exists rather than swapping at the end. | Homepage before build; other pages can follow |
| Images per page, with a minimum size stated up front | State the minimum width in the request. A full-resolution phone photo is fine; an image already resized for a social post usually is not. | Before build for hero images; later for the rest |
| wp-admin access to the current site, if one exists | Needed to migrate existing content and see what is already there before replacing it. Request as a credential, not a document. | Before build starts |
| Hosting and DNS access (or a decision to move hosting) | Launch day depends on this. Finding out two days before launch that the client does not control their own DNS is a common, avoidable delay. | Before build starts |
| Plugin licences already in use (page builder, forms, SEO) | A licensed plugin key needs to transfer or be repurchased; finding out at launch which plugins the client is attached to is too late. | Before build starts |
| Legal pages (privacy policy, terms, cookie notice) | These carry legal weight and should come from the client or their lawyer, not be invented for them. | Can come later, but before launch |
| Contact details, business hours, service area | Facts about the business that only the client can supply correctly, and that show up in the footer, contact page, and structured data. | Before build starts |
For a fuller version of this list across project types, not just WordPress, see the website project intake checklist.
The order to ask in
Send the identity and access items first — logo, colors, wp-admin, hosting — because they either block starting or take the client the longest to track down (a DNS login from three developers ago does not surface quickly). Send per-page copy and images in a second request, one the client can work through while the build is already underway. Leave legal pages and anything genuinely optional for a third pass closer to launch. Three requests spread over the project read as reasonable; one request with fourteen items due immediately reads as overwhelming, and a client who feels overwhelmed tends to answer none of it rather than some of it.
Handling the credentials safely
wp-admin, hosting, DNS registrar, and any licensed plugin's account are credentials, not documents, and they deserve different handling than a copy deck or a photo folder. A password sitting in an email thread stays readable in every backup of that inbox indefinitely — it does not become safer once the project is done. Collect access somewhere built for a one-time handoff instead. See how to get client logins securely for the reasoning, and Secrets for how BriefGate's vault handles it: the client's input is sent over HTTPS and sealed on BriefGate's server with a libsodium sealed box before it is ever written to the database, and the value can be decrypted exactly once, by the developer who requested it.
A per-page content worksheet
For any WordPress project with more than four or five pages, structure the copy request per page rather than as one open-ended "send me your content" ask — a request with no shape produces a document with no shape.
For each page, ask for:
- Page title and URL slug, if the client cares about the exact wording (some do, for SEO reasons; most do not).
- Headline and subheadline.
- Body copy, broken into the sections the template actually has — a page built from three content blocks should get three separate text fields, not one paragraph the developer has to split up themselves.
- Images for that page specifically, with the count and minimum dimensions stated (for example, "3–6 photos, minimum 1600px wide, for the services page gallery").
- Any embeds or third-party widgets the page needs — a booking calendar, a map, a review feed — and whether the client already has an account with that service.
A worksheet shaped this way maps directly onto how a page builder actually assembles a page, so the content arrives ready to place instead of needing to be re-chunked by whoever builds the site.
How BriefGate runs this in practice
An AI coding agent working from Cursor, Claude Code, or the dashboard turns each row above into a typed item and calls define_intake() once per stage of the project:
{
"project_name": "Riverside Dental — WordPress Rebuild",
"client": {
"email": "[email protected]",
"name": "Dr. Patel",
"language": "en"
},
"items": [
{"key": "logo", "type": "image", "label": "Practice logo", "required": true, "constraints": {"formats": ["svg", "png"], "min_width": 512}},
{"key": "brand_colors", "type": "color_list", "label": "Brand colors", "required": true},
{"key": "wp_admin", "type": "secret", "label": "Current WordPress admin login", "required": true},
{"key": "hosting_dns_access", "type": "secret", "label": "Hosting or domain registrar login", "required": true},
{"key": "plugin_licences", "type": "longtext", "label": "Licence keys for existing paid plugins, if any", "required": false},
{"key": "homepage_copy", "type": "longtext", "label": "Homepage headline and intro text", "required": true},
{"key": "team_photos", "type": "file_list", "label": "Team photos for the About page", "required": true, "constraints": {"formats": ["jpg", "png", "heic"], "min_count": 2, "max_count": 10}}
],
"chase_schedule": "default"
}See item types for the full set of field types — secret for credentials, structured for anything with a fixed shape like opening hours, file_list for a group of photos — and the MCP tools reference for every parameter define_intake accepts.
BriefGate emails the client a single branded portal for that stage, validates each item as they fill it in (an image that is too small or a licence key in the wrong format is rejected inline, before the developer ever sees it), and the chase engine sends reminders on a schedule so nobody has to track who still owes what. When the client submits everything, the agent calls get_intake_results() and gets back a logo file with real dimensions, colors as hex codes, and the credentials — released once, to the person who asked for them — ready to drop into the build instead of a folder of mismatched attachments and a stalled email thread.