How to Build a Web Style Guide That Editors Actually Use

The PDF nobody reads

Most organizations have one. A 60-page document created by a communications team three years ago, formatted like a report, stored on a shared drive with a confusing folder path, and referenced exactly never.

The style guide exists. The website doesn't follow it. New editors don't read it. Existing editors forget it's there. The result is inconsistent headings, mixed terminology, different tone on different pages, and a slow accumulation of brand drift that nobody can pin to a single decision.

The problem isn't that the editors are lazy. The problem is that the style guide was built for compliance, not for use.

What makes a web style guide fail

Most web style guides fail for one or more of these reasons:

It's too long. A 60-page document is a policy document, not a reference tool. Editors need to find answers in 30 seconds, not read a chapter.

It covers everything once and nothing clearly. Comprehensive guides try to address every possible scenario, which means no single rule is explained with enough context to be applied confidently.

It's not searchable. A PDF or a Word document on a shared drive is a terrible UX. Editors won't use a reference they have to dig up.

It doesn't match the CMS. A guide that talks about formatting decisions as if editors are writing HTML is useless to someone publishing through a block editor.

It's not maintained. Guides that are out of date create confusion about what the actual current standard is.

What a useful web style guide actually contains

A practical web style guide is short, specific, and organized around the decisions editors make most often. Here's the structure I recommend:

1. Voice and tone principles (1-2 pages max)

Not an abstract mission statement. A practical description of how your organization sounds: the vocabulary range (formal vs. conversational), the perspective (first person? second person?), and what specific behaviors distinguish your voice from the default.

Include three to five annotated examples: real sentences or passages from your site (or from an ideal version of it) that show, not tell, what the voice looks like in practice.

2. Writing mechanics

The specific rules editors need to make consistent decisions day-to-day:

Sentence case vs. title case for headings (specify which, then apply it everywhere)

Oxford comma: yes or no (pick one, document it)

Numerals vs. words (write out one through nine, use numerals for 10+, or your organization's specific rule)

Date formats (January 12, 2024 vs. Jan. 12 vs. 2024-01-12 — pick one)

Capitalization rules for specific terms: your department names, your branded features, your service categories

Link text standards (describe the destination, never "click here")

Punctuation in lists (period at the end of each item? Only the last? Depends on whether items are full sentences?)

3. Content types and their specific rules

Each content type on your site has different conventions. A style guide that treats all content the same misses the cases where editors most need guidance.

Cover:

Page titles: length limits, sentence case, keyword guidance

Meta descriptions / page excerpts: character limits, what to include

Headings: hierarchy rules (H1 = page title, only one per page; H2 for major sections; H3 for sub-points)

Images and alt text: when to use alt text, what to include, decorative image handling

CTAs and button labels: tone, verb-first construction, specificity

Documents and PDFs: when to publish as web content vs. downloadable, naming conventions

4. Terminology and usage reference

A searchable list of your most commonly used terms with guidance on correct usage. Examples:

✅ Use this	❌ Not this	Notes
city	City (lowercase unless part of a proper name)	Reserve capitalization for "City of [Name]"
email	e-mail	No hyphen
website	web site or Web site	One word, lowercase
sign in	log in	Use "sign in" for public-facing interfaces

Build this list based on your most common inconsistencies. Five well-documented terms are worth more than 50 underdocumented ones.

5. Accessibility basics

A one-page summary of the accessibility decisions that content editors own:

Alt text: what to write for informational images vs. decorative images

Heading structure: never skip heading levels, never use headings for visual formatting only

Link text: must make sense out of context (screen readers read links in isolation)

Language: WCAG plain language guidance, reading level targets

This section doesn't replace a full accessibility guide. It gives editors the information they need for their day-to-day decisions.

Format and tooling

The single biggest determinant of whether a style guide gets used is how easy it is to access and search.

Recommended formats (in order of preference):

A page in your CMS or intranet — searchable, always available, easy to update, linkable from editorial workflows

A Notion or Confluence page — searchable, collaborative, updatable

A Google Doc — accessible, searchable within the document, linkable

A PDF — only if you have no other option

If your style guide lives in a Word document on a shared drive, it will not be used. Move it somewhere editors already spend time.

How to maintain it without letting it go stale

Every style guide goes stale without a maintenance process. Build these habits in:

Assign ownership. As with any content governance process, one person is responsible for the style guide. "Everyone" owns it means nobody does.

Schedule a quarterly review. 30 minutes, four times a year, to address anything that's changed or that editors have questioned in the last quarter.

Add a changelog. When rules change, document what changed and when. Editors who learned an old rule need to know when things have shifted.

Collect questions as they arise. When an editor asks a question that isn't in the guide, that's always a signal to add it or improve an unclear existing entry.

A style guide that's actively used generates its own maintenance needs. If nobody's asking questions about it, it's not being read.

If you want to build or overhaul a web style guide that your team will actually use, get in touch and we can design something that fits your CMS and your editorial workflow.

How to Build a Web Style Guide That Editors Actually UseHowtoBuildaWebStyleGuideThatEditorsActuallyUse