Website Publishing Guide
Category: website Sources: website system, voice guide, content strategy, current Guides and Recall Watch Confidence: high Last Updated: 2026-08-08
Purpose
This guide defines how to create a Guide, Field Note or Recall Watch update that feels native to the Trace website.
Read Website, Voice Guide, Banned Words and the relevant technical source material before drafting. Inspect a current built page before writing markup.
Do not publish to fill a calendar. Publish when the piece resolves a real question or improves a real decision.
Shared editorial standard
Every piece must:
- answer one clear reader question
- state the useful answer early
- separate verified fact from Glen's interpretation
- define specialist terms at first use
- explain what the reader should check or do next
- state scope and limitations
- link to primary or authoritative sources where the claim depends on them
- use British English and the Trace voice
- avoid invented facts, urgency, clients, results or statistics
- connect to no more than one relevant service action
Never imply that Trace issues certificates, controls an independent decision or guarantees compliance, certification, approval or market access.
Source standard
Use the strongest available source:
- legislation, regulator or official public record
- current published standard or official standards-body material
- certification-body or test-house documentation for their own process
- verified Trace experience, clearly presented as experience or judgement
- reputable secondary explanation only when no primary source answers the point
For regulations, standards, recalls and current public bodies, verify the source on the day of publication. Record:
- source title
- issuing organisation
- direct URL
- publication or record date
- access date
- what claim the source supports
Do not copy long passages. Quote only where exact wording materially matters, and keep the excerpt short.
Required page metadata
Prepare this before layout:
| Field | Requirement |
|---|---|
| Title | direct, specific, accurate |
| Browser title | title plus Trace Technical Compliance |
| Description | 140 to 160 characters stating the reader benefit |
| Slug | short, lowercase, hyphenated |
| Publication date | ISO date plus readable date |
| Updated date | include when a factual change is made |
| Category | one approved channel category |
| Sources | complete source list |
| Service bridge | one service or none |
| Disclaimer | appropriate to the subject |
Do not use a clever title that hides the question.
Guide
Job
A Guide gives a stable, plain-English answer to a foundational or product-specific question. It should help a reader understand the issue without having to contact Trace.
Structure
- Question-led title.
- Short answer callout. Two or three sentences. Give the answer before background.
- Definition in plain English.
- What puts a product or decision in scope.
- What does not settle the question.
- Decision points or examples.
- Practical check. Something the reader can inspect now.
- Limits. State what depends on the product, claim, market or current rules.
- Sources.
- Next step. One related Guide, service or booking action.
Length
Use the length required to answer the question completely. A typical Guide is 900 to 1,800 words. Do not pad a short answer into a long article.
Design pattern
- quiet-grey page ground
- narrow paper reading surface
- one soft or full Trace-yellow short-answer callout
- clear H2 sections
- restrained lists
- contained ending with sources, related reading, action and disclaimer
- no stock imagery
Quality test
A product manager unfamiliar with the term should be able to explain the answer after one read and know which fact still needs checking for their specific product.
Field Note
Job
A Field Note turns a real recurring situation into practical judgement. It is not a teaser, short blog post or disguised sales story.
Do not publish the provisional notes removed from the site. A Field Note returns only when the full piece is complete and approved.
Approved categories
- How the system actually works
- Avoidable mistakes
- From live to covered
- More hands, not more safety
Add a category only when several future notes genuinely need it.
Structure
- Recognisable situation. Start with what the product team saw or said.
- Why it looked reasonable. Show the understandable assumption.
- Where the chain broke. Product, evidence, certificate or claim.
- What followed. Use the real consequence without exaggeration.
- What would have caught it earlier.
- The decision rule. One sentence worth keeping.
- A practical action.
- Relevant service bridge. One, only where the connection is natural.
- Disclaimer and confidentiality note.
Evidence and confidentiality
- Use a public record, Glen's direct experience or a clearly labelled composite pattern.
- Remove client, product and supplier identifiers unless written permission exists.
- Do not combine details in a way that makes an unnamed client identifiable.
- Do not imply a product was unlawful, unsafe or non-compliant unless an authoritative source says so.
- Record the internal evidence source even when the published note must remain anonymised.
Length
A typical Field Note is 900 to 1,500 words. The piece must be long enough to show the decision, not just the incident.
Design pattern
- paper reading surface on quiet grey
- category and date above the title
- one Trace-yellow consequence or decision callout
- body copy around 65 to 75 characters per line
- contained ending with next reading and one service action
On the hub:
- newest complete note first
- reverse chronological archive
- the newest note may use the one yellow consequence panel
- archive notes remain paper
- do not publish empty cards, invented dates or excerpts from unfinished pieces
Quality test
The reader should leave with a decision they can reuse, not simply the impression that Glen has seen something interesting.
Recall Watch
Job
Recall Watch turns the public record into questions a PPE product team can apply to its own range. It is not a claim that Trace investigated the product or reached an independent legal conclusion.
Entry fields
Every record entry needs:
| Field | Requirement |
|---|---|
| Record date | date shown by the public source |
| Product | public product name or clear description |
| Product group | consistent category label |
| Market | UK, EU or other relevant jurisdiction |
| Public source | issuing authority and direct record link |
| Public finding | careful summary of what the source actually says |
| Pattern | the failure mode or evidence issue the record illustrates |
| Check prompt | one question for the reader's own product or evidence |
| Verified on | date the link and wording were rechecked |
Source rules
- Prefer the official recall, safety alert or market-surveillance record.
- Preserve the authority's level of certainty. Do not strengthen words such as may, could or risk.
- If the record is corrected, withdrawn or moved, update the entry and note the verified date.
- Do not infer the cause of a recall when the record does not state it.
- Link directly to the record, not to a search result.
Annual structure
- current year labelled Running
- completed years retained as separate tabs
- year tabs use Arrow Left, Arrow Right, Home and End
- each year opens with one primary statistic and two context statistics
- definitions and collection limits stay visible
- entries accumulate through the year
- completed years are not silently rewritten to tell a neater story
Design pattern
Desktop uses the existing record table. Mobile converts every row to a labelled card. Never introduce horizontal table scrolling.
Use Trace Yellow for the running or primary statistic, not every number.
Disclaimer
Recall Watch must state that it is general information based on the cited public record. It is not legal advice, a product-specific compliance determination or evidence that an uncited product has the same issue.
Quality test
Every entry should give the reader a defensible source and a useful question without making a stronger claim than the public record.
Writing and design workflow
- Choose the channel based on the reader's job:
- stable explanation: Guide
- reusable judgement from a situation: Field Note
- public-record pattern: Recall Watch
- Gather and record sources.
- Write the one-sentence answer or decision rule.
- Draft in the approved structure.
- Check claims and boundaries.
- Edit into Glen's voice.
- Add the page using the closest approved source page as the template.
- Update the hub and navigation only where required.
- Build and test.
- Publish to a Cloudflare preview before production.
Eleventy implementation
Current source lives in digital-home/digital-home-frontend/src/.
For a Guide:
- duplicate the closest complete Guide HTML file
- rename it to the approved slug
- replace title, description, visible content and current navigation state
- add the new Guide to
src/guides.html
For a Field Note:
- create a complete note page using the long-read and Field Note styles already present in
src/assets/style.css - add it to the Field Notes hub only after approval
- replace the preparation state only when at least one permanent note exists
- add the newest note first
For Recall Watch:
- add the record to the current year's panel in
src/recall-watch.html - keep the table headers and mobile
data-labelvalues aligned - update the current-year statistics only from the verified record set
Source pages may use the existing relative .html links. Eleventy rewrites them to extension-free production URLs. Assets use the existing assets/ paths and receive content hashes during the build.
Run:
npm run build
node scripts/check-approved-links.mjs
Then inspect the production output at desktop, tablet and mobile sizes. Check the new page, its hub card, previous and next reading links, navigation, focus order, console and the 404 path.
Prompt for Codex or Claude
Use this when asking an agent to create a new page:
Create a new Trace website [Guide / Field Note / Recall Watch update / landing page]. Read
brand-wiki/wiki/website/website.md,brand-wiki/wiki/website/publishing-guide.md, the voice guide and the current production source before making changes. Reuse the closest approved page and the existing tokens and components. Do not invent a new visual system, add stock imagery, introduce another font, turn every section into a card or use Trace Yellow beyond the page's one priority. Preserve British English, Trace boundaries and source wording. Verify the built result at 1366x900, 768x1024, 390x844 and 320x800, including keyboard and mobile-menu behaviour.