---
name: website-copy
description: "Write or revise user-facing website copy: headings, body text, navigation labels, calls to action, form instructions, validation errors, empty states and confirmation messages. Use for website text, not unrelated long-form writing or visual implementation."
---

# Website copy

Write text that helps visitors understand the page and take the next useful step. Match the site's audience, purpose and established voice. Keep a distinctive voice where it helps; clarity comes first when someone must choose, enter information or recover from a problem.

## Establish the job of the text

Read the surrounding page or flow before editing. Identify what the visitor needs to know, what they can do next and what the interface actually does. Use the supplied product facts and existing terminology. If a missing fact would change the meaning, ask for it or leave it explicitly unresolved rather than inventing it.

Keep the requested scope. A copy edit does not by itself authorize changing a flow, adding features or publishing the result.

## Make the meaning easy to find

- Lead with the information or action the visitor needs. Use specific headings that remain useful when scanned on their own.
- Prefer familiar words, active verbs and concrete statements. Explain necessary specialist language for the audience.
- Keep paragraphs focused. Remove repeated promises, decorative introductions and sentences that add no new information. Use lists when the items are genuinely parallel or sequential.
- Use sentence case for interface labels unless the site's established style requires otherwise. Keep the same name for the same thing across the flow.
- State the intended action directly. Avoid unprompted contrasts such as “not just X, but Y,” rhetorical question-and-answer headings, invented compound labels and generic claims such as “seamless,” “effortless” or “game-changing.” Describe the actual benefit instead.
- Keep engineering terms, implementation details and internal project instructions out of visitor-facing text unless they help that visitor make a decision. Developer documentation and developer tools can legitimately use technical language.
- Do not force every page into the same headline, three-benefit list and closing pitch. Let the content and visitor's task determine the structure.

## Write controls and feedback for the action

- Give links a meaningful destination and buttons a clear action. Replace ambiguous labels such as “Click here” or “Submit” with the specific action when the context supports it, such as “Save changes” or “Send request.”
- Describe a setting consistently rather than changing its label to the opposite action when it is toggled.
- Explain required information and unusual formats before the visitor enters it. A placeholder is not a substitute for a field label or essential instructions.
- For an input error, say which value needs attention, what is wrong and how to correct it when known and safe. Do not blame the visitor. Distinguish invalid input from missing permission, a connection problem or a service failure.
- Say what is happening while an operation is pending. Report success only when it is confirmed. If the outcome is unknown, say so rather than inviting a retry that could duplicate an action.
- For an empty state, distinguish a new collection, no search matches and a failed request. Offer a next step only when one is useful and available.
- Before a consequential action, name what will change, who or what is affected and whether recovery is possible. Do not promise Undo unless the implementation can restore the change.

## Keep claims and examples honest

Use only supported facts about pricing, availability, capabilities and outcomes. Do not invent testimonials, customer counts, guarantees, research findings or urgency. Preserve material conditions and exceptions when shortening copy.

Clearly label fictional content in demonstrations. Use dummy names and example.com addresses rather than real personal data. Do not describe a simulated action as a real payment, reservation, message or saved account change.

When the task involves standards, legal obligations or source-based guidance, verify the relevant current primary sources before making a precise claim. Distinguish a requirement from a recommendation or a site's editorial preference.

## Check the text in context

Read the edited copy as a complete journey, including the title, headings, controls, help and feedback. Check that a visitor can tell what is being offered, what the next action does and how to recover if it fails. Keep labels understandable at narrow widths; do not remove essential meaning merely to fit a layout.

Deliver the finished copy or apply the requested edit. Briefly identify assumptions or unresolved facts that materially affect it. Avoid appending a generic sales pitch, duplicate summary or an offer to do the work you were asked to complete.