How to Plan Website Copy Before Hiring a Developer

How to Plan Website Copy Before Hiring a Developer

A developer can turn approved content into a working interface. They cannot safely invent your prices, process, guarantees, customer evidence, or reason for being different.

The useful deliverable before development is not a folder of polished slogans. It is a **copy pack**: a page inventory, factual source material, draft messages, proof, objections, and the next action for each page.

Collect raw material before writing pages

Start with information that already exists inside the business:

• the current service or product list;
• proposals, estimates, onboarding emails, and sales presentations;
• questions prospects ask before buying;
• reasons the business rejects unsuitable work;
• policies, delivery areas, lead times, and exclusions;
• testimonials or case material you have permission to publish;
• contact methods and the person responsible for each one.

Mark each item as **approved**, **needs confirmation**, or **private**. This prevents an internal estimate or casual sales promise from becoming public website copy.

If two team members describe the same service differently, resolve that before writing. A designer cannot solve an unresolved offer by choosing prettier words.

Write a one-page messaging brief

Use plain answers, not brand language:

1. 1Who is the primary customer?
2. 2What situation brings them to the website?
3. 3What do they need to understand before contacting or buying?
4. 4What exactly does the business deliver?
5. 5What is excluded or unsuitable?
6. 6What can the business prove?
7. 7What should the visitor do next?

“Small businesses” is usually too broad. “Owner-managed clinics that need a compliant booking website” gives the writer and developer far more useful constraints.

Do not force several audiences into one hero. If homeowners and commercial facilities managers buy differently, they may need separate paths.

Create the page inventory before the navigation

List every proposed page in a table with these columns:

| Page | Audience | User question | Primary action | Required proof | Owner | | --- | --- | --- | --- | --- | --- | | Home | New prospects | Am I in the right place? | View relevant service | Business identity and selected work | Founder | | Service | Qualified buyer | Is this suitable and what is included? | Request a scoped quote | Process, deliverables, example | Service lead | | About | Trust-checking prospect | Who is accountable? | Continue to service/contact | Real people, history, operating details | Founder | | Contact | Ready prospect | What happens after I enquire? | Submit form or call | Response expectations and privacy note | Sales owner |

This reveals duplicate pages and missing decisions. A page with no distinct user question probably should be combined with another page rather than filled with generic copy.

Build each page from a message hierarchy

Draft in order of importance, not in the order a template happens to contain sections.

For each page, write:

• **Page promise:** the accurate outcome or help offered.
• **Context:** who it is for and when it applies.
• **Deliverables:** what the customer receives.
• **Proof:** why the visitor can believe the claims.
• **Process:** what happens before and after the action.
• **Boundaries:** important exclusions, dependencies, or location limits.
• **Objections:** answers to questions that prevent a suitable buyer acting.
• **Primary CTA:** one explicit next step.

For example, replace “We deliver innovative digital solutions” with a sentence that identifies the actual work: “We redesign service-business websites that have outdated content, slow mobile pages, or unclear enquiry paths.” The second sentence is less glamorous and more useful.

Separate claims from proof

Create a small claims register alongside the copy. For every number, superlative, certification, customer quote, or outcome, record its source and publication permission.

If a claim cannot be verified, qualify it or remove it. “Most trusted,” “guaranteed results,” and unnamed percentage improvements create legal and credibility risks when nobody can show the basis.

Useful proof can be modest:

• a named team member and their role;
• a screenshot of completed work with permission;
• the precise deliverables in a project;
• a customer quotation linked to a real engagement;
• a documented process or support commitment.

Never ask a developer to “add some testimonials for now.” Placeholder evidence is easy to miss at launch.

Decide calls to action and form questions

Choose the action that matches readiness. A complex redesign may need a scoped enquiry; an emergency repair page may need a phone call; a fixed consultation may suit booking.

Define:

• button label;
• destination;
• information requested;
• who receives it;
• expected response time, only if the business can honour it;
• success and error messages.

Ask only for information needed to respond. Test the form content with the person handling leads: if every submission triggers the same follow-up questions, add the most useful qualifying field or answer the question on the page.

Plan SEO without distorting the copy

Assign one search intent to each indexable page. Record a working title, primary topic, related questions, and internal-link targets. Then write naturally for the person with that intent.

Do not create separate pages that only swap a location or keyword. Do not repeat the same exact phrase in every heading. The service definition, examples, boundaries, and local facts should determine whether a dedicated page has real value.

Hand over copy in a buildable format

Use one document or content system with stable section labels. For each page include:

• status and approver;
• page title and URL suggestion;
• headings and body copy;
• CTA text and link destination;
• image filename, alt-text intent, and permission status;
• links to source evidence;
• legal or factual notes that must not be rewritten casually.

Avoid sending competing versions through chat, email, and PDFs. Name unresolved text clearly with markers such as `[CONFIRM SERVICE AREA]`, assign an owner, and set a due date. Lorem ipsum is acceptable for testing a component, but it should never conceal missing business decisions.

What can remain flexible during design

Microcopy, heading length, and section order may change when the real content is placed in responsive layouts. The developer may find that a comparison works better than three paragraphs or that a mobile heading needs tightening.

The underlying promise, proof, qualification, and action should not change without approval. That boundary allows design iteration without accidental fabrication.

Next, use Homepage Structure That Converts Visitors Into Customers, the Local Service Landing Page Wireframe, and Writing Service Pages That Convert to shape particular page types. Browse the full Web Growth Academy for related planning guides.

If the existing copy and page structure both need reconsidering, the website redesign service describes the implementation scope.