In plain English
Write the website's core copy before finalising layouts. The message determines which pages, headings, proof, forms and calls to action the design must support. Designers can prototype with partial drafts, but approving polished screens filled with placeholder text often hides missing decisions and creates expensive rework when real content arrives.
Which decisions must be made before drafting pages?
Define the intended audience, problem, offer, suitable fit, operating area, evidence, boundaries and next action before writing polished prose. Collect approved facts from service owners and customer-facing staff, then mark unknowns instead of filling gaps with assumptions. The copy cannot be clearer than the underlying commercial decision, so unresolved scope belongs in a decision log. Agree a vocabulary for services and outcomes as well, so separate contributors do not create conflicting names for the same offer internally.
Give every proposed page one primary question and one job. Google's people-first guidance asks whether content serves an intended audience, demonstrates real expertise and leaves the reader able to achieve a goal. Use those prompts as a brief: identify what the reader must understand, what proof supports it and which next step the business can actually fulfil.
Sources for this section: Creating helpful, reliable, people-first content.
What copy should be drafted before visual design begins?
Draft the page title, direct answer, section headings, essential paragraphs, proof requirements, calls to action, form labels and important error or confirmation messages. The wording can still change, but its approximate hierarchy and volume must be real. A heading that becomes three lines or an explanation that needs a comparison cannot be discovered responsibly from placeholder text.
Write for scanning without reducing every idea to fragments. W3C recommends informative page titles, meaningful headings, descriptive link text, clear instructions and simple language. Create the structure in plain text first and read it aloud. If the argument does not make sense without colour, cards or animation, visual polish will not repair the missing relationship between the ideas. Include alternative text requirements and captions in the draft whenever an image, chart or video carries information for readers.
Sources for this section: Writing for Web Accessibility.
How should copy and design develop together?
Move from the content outline to low-fidelity layouts, then test representative pages and difficult states. Designers can show where grouping, sequence or emphasis is weak; writers can expose where a component forces an important qualification out of view. Resolve the system together and use actual mobile-length headings, labels, errors, quotations and calls to action in the prototypes.
Build reusable components around content roles rather than arbitrary character limits. A service summary, process step, evidence item and boundary have different meanings even when they share a card shape. Maintain a logical heading hierarchy in the final page; W3C notes that headings communicate organisation and support navigation. Visual size alone should not be used to fake that structure. Record exceptions rather than shrinking essential copy to fit a component that was designed around an unrealistically short sample.
Sources for this section: Headings.
When is the copy ready to publish?
Ready does not mean every sentence is permanently frozen. It means factual claims have sources and approval, page purposes are distinct, links and actions are known, legal or technical review is complete where required, and the implemented layout has been proofread at every breakpoint. Replace all placeholders, test truncated states and confirm that hidden or collapsed content remains available appropriately.
Assign a content owner and review trigger after launch. Update a page when the service, evidence, team, process or customer question changes; do not change its date merely to imply freshness. Google's guidance explicitly recommends people-first, maintained content and warns against artificial date changes. A governed revision process lets design and copy evolve without losing factual control. Keep the source and approval beside material claims so future editors can verify a correction without reconstructing the project.
Sources for this section: Creating helpful, reliable, people-first content.
Official references
- Creating helpful, reliable, people-first content (Google Search Central)
- Writing for Web Accessibility (W3C Web Accessibility Initiative)
- Headings (W3C Web Accessibility Initiative)