Website Copy From Clients: What to Ask For and How to Get It
Every web project has a moment where the design is ready, the pages exist, and the only thing missing is the words to put in them. That moment lasts a lot longer than anyone plans for, because "send me your copy" is the vaguest request on the whole intake list, and it usually gets treated that way.
What "copy" actually covers
Copy is not one deliverable. It's at least four different kinds of text, and treating them as one request is why the client sends back a single paragraph and calls it done.
- Page copy — the headline, subheadline, and body text for each page: homepage, about, services, contact. This is the one people think of first, and it's also the slowest to arrive.
- SEO title and meta description — the
<title>tag and meta description for each page, shown in search results. Most clients don't know these exist as separate fields from the page text, so they need to be asked for explicitly, not folded into "the copy." - Microcopy — button labels, form field hints, error messages, empty states, confirmation text. Small, easy to skip, and the reason a finished site still feels unpolished when every field says "Submit" and every error says "Something went wrong."
- Legal text — privacy policy, terms of service, cookie notice, any industry-specific disclosure. This one is not a copywriting task at all; it's a compliance document, and it has to come from the client or their lawyer, never invented on their behalf by whoever is building the site.
Splitting the request this way also splits the timeline correctly. Page copy and legal text can take weeks; SEO fields and microcopy can be turned around in a day once someone sits down to do them. Asking for all four under one heading means the fast ones wait on the slow ones for no reason.
Who should actually write it
The client is the only source for anything factual: what the business does, who it's for, what makes it different, the legal documents, the exact wording of a guarantee or a policy. No one else can write this correctly, because no one else knows it.
A copywriter earns their fee on persuasion and structure — turning what the client knows into a homepage that reads well and gets to the point. Worth it on anything client-facing and commercial; usually overkill for an internal tool's microcopy.
The agency or developer should default to writing the small, low-stakes stuff: button labels, form hints, empty states, the boilerplate a site needs to not look broken. Writing the homepage headline on the client's behalf and hoping they'll correct it if it's wrong is a bad bet — most clients accept whatever they're handed rather than push back, and a fabricated fact then ships to production.
AI-drafted copy is a legitimate first pass for structure and phrasing — a starting point that's faster to edit than a blank page. It is not a source of facts. An AI draft that states a founding year, a certification, or a price the writer invented to fill the sentence is worse than a blank field, because a blank field gets noticed and a plausible-sounding wrong fact doesn't. Draft with it, but every factual claim in the draft still needs a client to confirm or correct it before it goes live.
How to ask, so the answer actually shows up
The request that gets ignored is "can you send over your website copy." The one that gets answered names the field, gives a length, gives an example, and gives a date:
- Homepage headline — one sentence, roughly 8–12 words, the thing you'd want someone to read if they only read one line. Example: "Family-run Italian kitchen in the heart of Riverside, open since 2009." Due before the design review.
- About page body — 150–300 words: who you are, how you started, what makes the business different. Due one week after kickoff.
- Service or product descriptions — 40–80 words per item, one paragraph each, written the way you'd describe it to a customer standing in front of you. Due alongside the photos for the same page.
- SEO title and description per page — a title under 60 characters and a description between 120 and 160 characters, or "leave blank and I'll draft one for your review" if that's genuinely easier for the client. Due whenever the page copy is final, not before.
- Legal pages — privacy policy and terms, from the client or their lawyer, or a note that they want a standard template reviewed instead. Due before launch, not before kickoff — this one can run in parallel with everything else.
Each item on that list is answerable in one sitting. A client staring at "send your copy" doesn't know where to start and defers the whole thing; a client staring at "one sentence, 8 to 12 words, by Friday" either writes it in five minutes or replies asking a real question — both are progress.
Structuring copy for a multi-page site
The list above covers the four kinds of copy; on a site with more than a handful of pages, "page copy" itself still needs splitting down to the page level, or it comes back as one undifferentiated document. Ask per page, not per site:
- Page title and URL slug, if the client cares about the exact wording — some do, for SEO reasons; most don't.
- Headline and subheadline for every page past the homepage, same shape as the homepage item above.
- Body copy, broken into the sections the template actually has. A page built from three content blocks should get three separate fields, not one paragraph the developer has to split up themselves — this matters most on page-builder platforms like WordPress, where each block is its own editable region.
- Images for that page specifically, with a minimum count and dimension stated — "3–6 photos, minimum 1600px wide, for the services gallery," not "send some photos."
- 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 the page actually gets assembled, so content arrives ready to place instead of needing to be re-chunked by whoever builds the site.
When it doesn't come in
It won't all arrive on time, and the fix is not one more polite email. Two things work:
Break it smaller and chase what's actually missing. A single "copy" request that's 80% done still shows as one unfinished item; five separate fields that are four-fifths done show as four checked boxes and one specific ask, which is both more honest about progress and easier to follow up on. A scheduled reminder that names the exact missing field lands better than a person having to remember to nag, and it's the kind of thing worth automating rather than carrying in your head across every open project.
Decide, in writing, what a missed deadline does to launch — before you're in one. The two live options are: launch with a clearly-marked placeholder ("Copy coming soon — check back next week") and swap it in once it arrives, or hold the launch until the real text lands. What doesn't work, and happens more often than anyone admits, is shipping lorem ipsum or a copy-pasted competitor's paragraph because nobody wanted to be the one to delay launch — and then it sits there for months because fixing "temporary" text is nobody's job once the site is live and the invoice is paid. Decide which of the two real options applies to this project before the deadline arrives, not after it's already missed.
Where BriefGate fits
Turning the list above into an actual request is the part that usually lives in an email thread instead of a system: someone has to phrase each field, track what came back, and remind the client about the two things still missing without re-explaining the other three that are already done. An AI coding agent — or you, from the dashboard — declares each field as a typed item (text for the SEO title with a character limit, longtext for the about-page copy with a length range, file for the logo) with define_intake, and BriefGate generates one branded, no-account portal link for the client, sends the reminders on the schedule you pick, and hands back validated values instead of a half-finished email thread. Logins collected in the same request go in as secret items, which BriefGate encrypts on its server before they're stored — see Secrets for how that works. A fact with a fixed shape — opening hours, the registered legal business name for the footer and the privacy policy — goes in as a structured or short text item instead of another paragraph to parse, and a vague answer (an FAQ reply that doesn't actually answer the question) gets a `request_revision` call that flags exactly what's missing in the client's own portal, instead of a reply-all nobody reads in full. For the rest of what a website project needs beyond the words — logo, photos, technical access — see the website project intake checklist.
Frequently asked questions
What copy does a website actually need from the client?
At minimum: page-by-page body copy (homepage, about, services), an SEO title and meta description per page, small microcopy (buttons, form hints, error and empty states), and legal text (privacy policy, terms, cookie notice) from the client or their lawyer — not invented by whoever builds the site.
Should a web developer write the client's website copy?
Only the small, low-stakes pieces — button labels, form hints, boilerplate. Anything factual (what the business does, its history, its claims) has to come from the client, because a developer or agency guessing at facts and hoping the client corrects them usually ships wrong information instead.
Is AI-generated website copy safe to use?
As a first draft for structure and phrasing, yes — it's faster to edit than a blank page. Not as a source of facts: an AI will confidently state a founding year, a certification, or a price it invented to complete the sentence, and every factual claim in a draft needs the client to confirm it before publishing.
What if the client never sends their website copy?
Split the request into small, specifically-worded fields instead of one open-ended ask, and decide in advance whether a missed deadline means launching with a clearly-marked placeholder or holding launch — the failure mode to avoid is shipping lorem ipsum or invented text because nobody wanted to delay the site, and then never getting around to replacing it.
How should I structure a copy request for a site with many pages?
Ask per page, not per site: page title and slug if it matters, headline and subheadline, body copy split into the sections the template actually has, and images sized for that specific page. A page built from three content blocks should get three separate fields, not one paragraph to divide up afterward.
Send this request to your client with BriefGate — start free, no card required, and turn the fields above into a branded portal with reminders instead of an email thread.