Website Copywriting: Why Your Developer Isn't Your Copywriter

Website copywriting is a separate discipline from web development, and the two jobs fail in different ways when one person tries to do both. A developer owns structure, components, performance and the CMS that words live inside. A copywriter owns what those words claim, who they speak to and what action they ask for. A website build consumes eight items of copy, and not one of them is the developer's to invent:

• Page H1 and section headings, written in the client's own language
• Body copy for every section, in the order the argument has to land
• A title tag and a meta description for each page, unique across the site
• Button and link labels that name what happens next
• Form labels, helper text, success and error wording, not only the happy path
• Image alt text for every image that carries meaning
• CMS item names and slugs for the launch content
• Pricing, service scope and legal wording, approved by the client in writing

Hire the developer for the build and a copywriter for the words. When a budget stretches to only one of them, spend it on the copy and ship fewer pages.

Why is a web developer not your website copywriter?

A web developer and a website copywriter answer different questions using different evidence. The developer decides how a page is built, how fast it loads and how a non-technical editor will update it later. The copywriter decides what a visitor must read in order to act.

The split shows up in which parts of a page get finished. The 2025 Web Almanac SEO chapter, published by HTTP Archive from its own crawl, found meta descriptions on 67.7% of desktop pages. The Web Almanac SEO chapter publishes that figure. Derived from it, 32.3% of desktop pages carry no meta description at all, a number I calculated rather than one the Web Almanac states.

What I see agencies get wrong here is treating that gap as a build defect. A field a developer can add in minutes sat empty on a third of the web's desktop pages, which is what a writing gap looks like rather than a building one, and nobody can fill it without knowing what the page is selling. If a build brief lists components but never lists copy deliverables, the copy has not been scoped and the developer will end up guessing.

What website copy does a build actually need, and who writes each piece?

A website build needs eight distinct copy artifacts, and a copywriter writes seven of them outright, co-writes image alt text with the developer, and edits the pricing, scope and legal wording the client owns. The developer's contribution is the inventory of slots, not the words in them. The table below maps each artifact to its owner, the constraint or house rule it has to respect, and the specific failure that follows when a developer fills it in at build time.

Three rows in that table carry a published constraint and five carry a house rule, and the table labels which is which. The published ones are Google's snippet documentation for snippets being built primarily from page content, Webflow's CMS import article for the 256 character cap on Name and Slug columns, and the Web Almanac for the alt attribute median. The rows marked house rule are the standards I hold client projects to, not anybody's documentation, and the rule I apply is that a copy deck has to cover every row before the first page is built.

What goes wrong when the developer writes the copy?

Developer-written copy fails in six recognisable patterns: feature lists in place of offers, one meta description reused across the site, placeholder headings that survive to launch, generic commodity wording, button labels invented at build time, and legal or pricing wording filled in from the brief. Each pattern carries a cost that shows up weeks after launch, and each one I find regularly when auditing a site somebody else shipped.

• Feature lists in place of offers. Consequence: the page explains what the product has and never what the reader gets. Fix: the copywriter rewrites each section around one reader outcome.
• One meta description reused across the site. Consequence: every result in the index describes the company rather than the page, so the service page that should win a search reads exactly like the home page. Fix: write a unique description for every page in the sitemap.
• Placeholder headings that survive to launch. Consequence: the live page carries "Our Services" where an offer should be, and the h1 stops describing the page. Fix: no page is marked done until its H1 is client-approved.
• Generic, commodity wording. Consequence: Google's generative AI guidance describes "commodity content" as content "based on common knowledge, which could originate from anyone", so nothing in the page is worth quoting. Fix: put the practitioner's specifics into the copy.
• Button labels invented at build time. Consequence: visitors cannot tell what a click will do, and conversion tracking groups unrelated actions together. Fix: label every button with its outcome.
• Legal and pricing wording filled in from the brief. Consequence: the client discovers claims they never approved. Fix: route all commercial wording through the client, in writing.

When I audit a Webflow site for this, the first check is whether any two pages share a meta description, because that single symptom reliably predicts the rest of the list. If two pages match, assume the copy was written by whoever was building at the time.

Does placeholder copy really affect how a page performs in search?

Placeholder copy affects search performance directly, because a page's own words are the raw material a search engine has to describe it with. A page shipped with stand-in prose gives an engine nothing about the offer to work from, and the slots that were never written stay empty long after launch.

Empty copy slots are common enough to be measurable. The 2025 Web Almanac SEO chapter records an h1 element on 71% of desktop pages while a non-empty h1 reaches only 66%. Both figures are published in the Web Almanac SEO chapter, and the distance between them is the population of pages whose most important heading exists and says nothing.

An empty or placeholder h1 hands a search engine nothing on the one heading meant to describe the page. Webflow's own handling of the title and description fields, including how the two are stored and generated once copy for them exists, is covered in my guide to the Webflow meta description and SEO title setup.

On the projects I lead, the practical consequence is sequencing: a page with real copy can be indexed and judged on the day it goes live, while a page with placeholder prose has to be rewritten and recrawled. If copy is still pending at launch, keep the page unpublished rather than shipping placeholder text into the index.

Can AI write the website copy instead of a copywriter?

AI drafting is useful for raw material and poor at the part clients actually pay for, which is judgement about claims. Google's generative AI guidance is blunt about the risk: it describes "commodity content" as content "based on common knowledge, which could originate from anyone", and notes that "it can be helpful to have a unique viewpoint that stands out".

The real limit is accountability rather than fluency. A model will produce a plausible service page in seconds, and nothing at the other end of it is answerable for what that page promises about turnaround, scope, pricing or guarantees. The rule I apply on client projects is that every sentence committing the client to something has to trace back to a named person who approved it.

In my projects, AI drafts are treated as a first pass that a human then makes specific and accountable. If a sentence could appear on any competitor's site without being false, cut it or replace it with something only this client could say. Answer engine optimization rewards exactly the specificity that generic drafting removes.

How do you brief a website copywriting project so the build stays on schedule?

A website copywriting brief keeps a build on schedule when it is organised by page and by field, not by document. The copywriter needs to know every slot that will need words before writing starts, which means the developer supplies the slot inventory and the copywriter fills it.

The brief I ask for on client projects is built off the Webflow Pages panel page list and the CMS Collection fields, because those two surfaces are the real slot inventory. Against that inventory it names one purpose per page, the single action each page should produce, the proof available for each claim, the voice constraints, and the owner and deadline for each page's approval. For the wider sequence this sits inside, including who prepares what before kickoff, see my website project checklist.

Copywriting effort scales with the number of distinct page types and approvals, not with total page count. Twenty Webflow CMS items built from one Collection template need one set of field patterns written once; five bespoke service pages need five arguments, five approvers and five sets of SEO fields. When judging a copywriter, I ask for a page they wrote where the offer was hard to explain, not a portfolio of headlines.

Review mechanics matter as much as the brief. Copy feedback and design feedback arrive through different channels and get resolved differently, which is why I keep them separate and why giving design feedback to developers is its own process. If a copy round and a design round are open on the same page at the same time, close the copy round first.

How do you know when website copy is ready for the build?

Website copy is ready for a build when all eight copy artifacts have approved text, a named owner and a deadline, measured against the real slots: every page in the Webflow Pages panel, every field in each CMS Collection, and every state of every Webflow form block. The eight checks in this section score that one artifact at a time. Scoring artifact by artifact is what stops a copy deck passing while a whole row of the ownership table is still empty.

A low score is not a reason to delay a project indefinitely. A low score is a reason to assign owners, because the slots in that checklist get filled by somebody either way. If the site is already live and underperforming, my walk-through of a website that is not generating leads starts from the same copy surfaces.

Who should review website copy before a build starts?

The person who reviews website copy before a build starts should be whoever will have to build against it, because they are the one who finds the empty slots. I do that review on incoming projects, and you can bring your page list and whatever copy exists today to a 15 minute call. You leave with a per-page owner list naming which slots are unowned, which pages can be built now, and where a copywriter is needed first, whether or not we work together.